Re: GCC 4.2.0 Status Report (2007-04-15)

[Brooks Moses <brooks dot moses at codesourcery dot com>]

Daniel Berlin wrote:
> On 4/15/07, Mark Mitchell <mark@codesourcery.com> wrote:
> > However, I would consider asking the SC for permission to institute a
> > rule that would prevent contributors responsible for P1 bugs (in the
> > only possible bright-line sense: that the bug appeared as a result of
> > their patch) from checking in changes on mainline until the P1 bug was
> > resolved.  This would provide an individual incentive for each of us to
> > clean up our own mess.
>
> And how exactly would we plan on tracking this?
> At least to me, it seems like adding more administrative overhead and
> i don't see it fixing the underlying problem.
> You want more bugs fixed, it would seem a better way would be to build
> a better sense of community (Have bugfix-only days, etc) and encourage
> it through good behavior, not through negative reinforcement.   You
> can't fix behavior in a volunteer community by beating people into
> submission.  There will always be those who don't get it, or who
> everyone believes isn't doing a good job, and it's not just because
> they are committing patches and leaving messes.  The reality is we
> just don't want people like this in our community, and they shouldn't
> have write access, TBQH[1].

It seems to me that having the support infrastructure for this would 
potentially be quite useful.  However, I agree with Daniel that I'm not 
so sure how much actually having the policy on top of that will help.

We have 124 regression PRs of P3 or above against 4.2.0, and 7 of P1. 
For how many of those do we know which commit caused the regression?

My personal feeling is that it's entirely possible that I might make a 
mistake in some code that doesn't show up in the regression testing and 
nobody notices in the code review, and a P1 regression might come out of 
that mistake a few months later when someone notices the consequences. 
I hope this won't happen, and I try hard to keep it from happening, and 
we've got a lot of process in place to try to prevent it, but with the 
number of commits we have, statistical anomalies will happen.  At that 
point, if I don't see the bug report (or don't recognize that it's a 
consequence of my code when I'm looking at the list of regressions), 
then I'll have no idea that I'm responsible for it.

However, if we had some sort of infrastructure in place that would 
produce a message to me saying "Your commit number #123456 introduced 
this P1 regression", I'm likely going to say, "Oh, bother," and do my 
best to fix it.  I suspect that the people who had the poor luck to 
cause the PRs on Mark's current hit list would feel exactly the same way.

Also, beyond that, I would strongly suspect that these PRs haven't been 
fixed in large part because they're difficult to track down, and 
possibly if we knew what commit had introduced them, we'd be a good bit 
farther along in fixing them, even without having the help of whoever 
introduced them.  This is, after all, a large part of why we try to have 
the "one idea per patch" rule.

- Brooks, who is also wondering who'd get to decide whether a regression 
qualified as a P1 under this proposal....