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.
