Daniel Berlin wrote:
On 4/15/07, Mark Mitchell <[EMAIL PROTECTED]> 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....
