lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 31 Aug 2007 01:11:32 +0300 From: Al Boldi <a1426z@...ab.com> To: "Natalie Protasevich" <protasnb@...il.com>, "Stefan Richter" <stefanr@...6.in-berlin.de> Cc: "Adrian Bunk" <bunk@...nel.org>, "David Rees" <drees76@...il.com>, "Daniel Walker" <dwalker@...sta.com>, "Michal Piotrowski" <michal.k.k.piotrowski@...il.com>, "Andrew Morton" <akpm@...ux-foundation.org>, "Björn Steinbrink" <B.Steinbrink@....de>, eranian@....hp.com, ak@...e.de, linux-kernel@...r.kernel.org Subject: Re: Who wants to maintain KR list for stable releases? Natalie Protasevich wrote: > On 8/30/07, Stefan Richter <stefanr@...6.in-berlin.de> wrote: > > Al Boldi wrote in "Designers and Builders (was: Who wants to maintain KR > > list for stable releases?)": > > | So, what's wrong with tapping into people's design suggestions, and > > | allowing others to implement it? > > > > Design suggestions should really come from people who also know a lot > > about the how-to. This is even true to some degree about feature > > requests. Besides, I've got a feeling that regardless of the field of > > τεχνη one works in, someone can only be a truly good designer if she or > > he has also been a builder. > > Sometimes you can feel that the suggestion comes from Unix veteran, or > one who does a lot of linux programming in user land. Their opinion is > often valuable. Exactly right. The important part in designing isn't the how-to but rather understanding the concepts involved. Once you have the concepts straight, implementation becomes a matter of which path to take. > > But back to the discussion. A tracker is not a good tool for > > brainstorming sessions, except perhaps for capturing conclusions after > > the brainstorm, as far as they are suitable as input for actual work. > > > > Also, "*allowing* others to implement it" has a strange ring to me. > > Where I am around, there are always far too few people who fix things > > and build things. But very, very occasionally there is someone new who > > wonders if there is an interesting TODO item which is perhaps in the > > reach of his abilities. Contributing a cleanup or an actual feature is > > typically much easier than fixing an open, tracked bug. (The bugs which > > end up in the bugtracker are usually the difficult ones.) The > > contributor learns something and, in a rare turn of events, may > > eventually become able and willing to join the bugfixing. > > Yes, indeed, one should really know the code in and out to do things > right. OTOH, not everyone has time to fix bugs in his department, or > it's just single person trying to handle all work. I suggest that in > this case our masters could first outline what needs to be done and > write it down in the bugzilla. This will 1) give a warm feeling to > reporter and everyone else that the problem is noticed and not taken > lightly and 2) give people with active and curious minds chance to try > solving a problem (my guess that would be many reporters themselves, > they often ask "what can I do and how can I fix this" and some more > junior developers looking for useful exercise and just need > directions.) At least some good debugging will come out of it, and no > harm... Agreed. But when I responded to this thread by changing the subject, because I felt it was somewhat OT to tracking, I meant to question the mentality of trying to nullify design suggestions for the mere reason of not submitting a prototype. Now, prototyping is a great way to refine your end-product, but it's a terrible waste of time in terms of articulating design-goals. IMHO, in the interest of keeping ahead of the competition, we should encourage people to express their design suggestions instead of discouraging them. Thanks! -- Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists