This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]