[lkml]   [2007]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: How to improve the quality of the kernel?
    Al Boldi wrote:
    > Adrian Bunk wrote:
    >> On Mon, Jun 18, 2007 at 06:55:47AM +0300, Al Boldi wrote:
    >> > Michal Piotrowski wrote:
    >> > > On 18/06/07, Al Boldi <> wrote:
    >> > > > Bartlomiej Zolnierkiewicz wrote:

    [on the tracking of review status of patches]

    >> > > > > however we need to educate each and every developer
    >> > > > > about importance of the code review and proper recognition of
    >> > > > > reviewers.
    >> > > >
    >> > > > That's as easy to manage as is currently done with rc-regressions.
    >> > >
    >> > > Are you a volunteer?
    >> >
    >> > Probably not, as this task requires a real PRO!
    >> >...
    >> That's wrong.
    >> We are talking about _tracking_.
    >> I'm not sure whether it makes much sense, and it would cost an enormous
    >> amount of time, but tracking patches should be possible without any
    >> knowledge of the kernel.

    I suspect you are...

    > If that's really true, which I can't imagine, then the proper way forward
    > would probably involve a fully automated system.

    ...both wrong --- because patches have varying requirements WRT review
    and testing.

    What you discuss here under the label "patch tracking" blends into, how
    shall I call it, "patch handling" as done by maintainers. Neither a
    layman nor an automaton is able to
    1. measure required vs. accomplished review and testing of a patch,
    2. recruit reviewers and testers.

    And IMO *these* two are the points where we typically fail. We
    occasionally underestimate the required amount of review and testing,
    but more importantly, we are chronically short of reviewers and
    partially of testers. (Hmm, I think Adrian and one or another guy
    already said as much.)

    A "Reviewed-by" tag in a patch is not a simple hard fact. Neither a
    layman nor an automaton can draw appropriate conclusions from it. That
    doesn't mean I'm against such tags, on the contrary. They may help us
    to (a) look harder for review, (b) have a better picture of actual lack
    of review, patch by patch, subsystem by subsystem, and (c) get more
    volunteer reviewers by emphasizing the merits of code review. Alas,
    experience and broad knowledge in kernel development are certainly
    prerequisites to become a good reviewer, so don't get high hopes that
    reviewers will suddenly come in droves when we appropriately credit
    their work.
    Stefan Richter
    -=====-=-=== -==- =-=-=
    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-06-21 17:51    [W:0.022 / U:1.792 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site