[lkml]   [2007]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Who wants to maintain KR list for stable releases?
    Natalie Protasevich wrote:
    > On 8/30/07, Stefan Richter <> 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



    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-08-31 00:17    [W:0.023 / U:0.252 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site