linux-kernel - Re: Who wants to maintain KR list for stable releases?

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-Id: <200708310111.32132.a1426z@gawab.com>
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/