[Ksummit-2012-discuss] [ATTEND or not ATTEND] That's the question!

[Dave Chinner]

On Sat, Jun 16, 2012 at 04:43:05PM +0000, Myklebust, Trond wrote:
> On Sat, 2012-06-16 at 12:30 +0100, Alan Cox wrote:
> > On Fri, 15 Jun 2012 16:34:13 -0700
> > Greg KH <greg at kroah.com> wrote:
> > > On Sat, Jun 16, 2012 at 12:56:36AM +0200, Thomas Gleixner wrote:
> > > > So the main questions I want to raise on Kernel Summit are:
> > > > 
> > > >    - How do we cope with the need to review the increasing amount of
> > > >      (insane) patches and their potential integration?
> > One thing that seems to be working well are all the areas that have two
> > or more maintainers. As a simple statistical fault tolerance they don't
> > generally both have newborns, get the flu, change job or get yanked into
> > a critical customer problem by their employer on the same week.
> >
> > Right now we are doing it for real in some areas, and via the "screw
> > this, mail Andrew Morton" process for others, plus Linus fields some of
> > the really dumb ones. We could formalise some of that a bit more and
> > encourage more maintainers to actual team up with one of the other
> > contributors they trust.
> 
> If by "maintainer" you mean "patch reviewer", then I agree. Teaming up
> for the review process is the right thing to do, and is (as far as I
> know) what we were trying to resolve with the "Reviewed-by" tag.
> Formalising the review process and raising the status of developers that
> commit to reviewing patches is entirely the right thing to do. Actually
> maintaining trees of reviewed patches is the trivial part of the
> operation.
> 
> Perhaps the right thing to do is to start demanding that all patches
> that are submitted to the maintainer contain at least one "Reviewed-by:"
> tag?

The upside of this is that people who regularly review patches
(note: review, not ack) are more likely to have their patches
reviewed promptly by other people. i.e. this often devolves to a "I
scratch your back, you scratch mine" kind of arrangement.

In turn, this encourages prompt code review because it makes it more
likely that code is going to be reviewed quickly by others because
the others remember who reviewed their last patch-bomb quickly.

And the maintainer quickly learns whose reviews can be trusted, too,
which then leads to less load on the maintainer as reviewed-by tags
grow in trust value....

Cheers,

Dave.
-- 
Dave Chinner
david at fromorbit.com