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

[Mike Stump]

On Jun 14, 2006, at 11:51 AM, Joe Buck wrote:
> There have been a number of proposals that basically amount to  
> threatening
> the patch reviewers with negative consequences, but I'm not for that.

I too think that would be the wrong direction to go.

> I'm not sure I *want* GCC to start changing much more rapidly than  
> it changes today.

But, is change alone the basis to drive decisions?  I hope not.  gcc  
has always been driven by users.  Fewer users, less change.  More  
users, more change.  I think there are ways to manage it and still  
keep the quality up.

> But will the quality level be maintained?

Yes, we ensure the observable quality in part by the testsuite, this  
gets us a generally monotonic baseline and from the user's  
perspective, this is an important part of quality.  This helps us  
scale in terms of the change load.  I think there are other  
opportunities to help scale that have a beneficial impact on  
quality.  For example, would be nice to have a batch tester that  
would bootstrap and regression test on 2-5 platforms for all patch  
submitters post approval but pre-checkin.  If any regressions, dump  
all patches and move on to the next set, repeat as fast as possible.   
If they all pass the entire regression suite, all languages, then put  
them all in.  In this fashion, at all points, for all the tested  
platforms, there could never be any regressions.  This lends to  
stability for the developers in general and edges the quality up.   
This also can lesson the testing burden on individual contributers  
and free them of that task more often.

> That's the whole reason we insist on patch review, so any process  
> that speeds it up has to guarantee that will still get a decent  
> review of all patches (other than the truly obvious ones).

When the patches are to fix regressions and bugs in the compiler, one  
can argue that quality isn't served by not fixing the problem.  By  
making the process more efficient, we enable more bugs to be fixed  
and we further encourage more people to send in patches to fix more  
bugs, more often.  I feel being responsive to patch submitters is  
being responsive to users, and being responsive to users it one way  
to get more users and a better reputation.  More users, means in  
part, more testers and more diversity in testing.  Discouraging patch  
submitters, and in the end that discourages users, and that results  
in less testing and less diverse code.

I'm not advocating a free for all, but I do think we need to ensure  
that there are enough maintainers to ensure timely reviews.  I'd  
argue that 1 month indicates that we don't have enough reviewer  
bandwidth.  I'd argue that 10 months indicates the same thing, only  
more.  The SC could ask for volunteers to be patch reviewers in areas  
where we have a backlog.  If the existing maintainers don't want the  
help, this can motivate them to never have a backlog.