Re: Patch queue and reviewing (Was Re: Generator programs can only be built with optimization enabled?)

[Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>]

Diego Novillo said:
> I don't really have a good idea on how to address the core problem,
> other than to encourage adding more maintainers.  A couple of Summits
> ago I think we discussed the idea of having secondary maintainers: folks
> who may not feel fully confident about an area, but may want to chime in
> with an initial review which the primary maintainer could then use to
> help with the final review.
What's the purpose of that?  Encouraging people to voluntarily review 
patches?  Or more people to blame?

If that's just the first (as I idealistically hope), that does not need 
to be formalized.  Ralf Wildenhues which does not even have write access 
to the repository did a *wonderful* job of reviewing my bashjar patch, 
and I am sure Tom Tromey took that into account when giving his final 
approval.

People sometimes write reviews, stating clearly that they have no 
approval authority.  If their review is dismissed by a primary 
maintainer, that's ok because then they learn something, and that's also 
valuable.  The problem is those "no big deal" patches, maybe including 
cleanups or small improvements or fixes for strange configurations, that 
tend to slip through the cracks, only to come back when a maintainer 
experiences the same itch.  That's precisely the cause with Eric's patch 
in this thread.

Richard Guenther said:
> Some time ago I invented the obvious-because-nobody-cares rule under 
> which
> you can apply a patch as obvious if nobody objected after two weeks.
ISTR that was for a bootstrap failure.  Two weeks of turnaround for 
bootstrap failures are indeed bad enough that such a bandaid may be 
worthwhile.  But I think that this should absolutely *not* be formalized 
and left for emergencies, lest it would cause more problems than it 
would solve.

Paolo