On 5/22/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Ian Lance Taylor wrote:
[Danny, please see below for a request for your help.]
> It's a reasonable idea, but overall it would have a negative effect.
> People tend to ignore PRs that are assigned to somebody else; they
> assume that person is actually working on them. Conversely, people
> won't work on a bug simply because it is assigned to them.
Right.
I'm going to back up and try to explain a bit more about what I'm trying
to accomplish.
One of the problems I've faced in recent releases is that developers
seem not to care too much about fixing bugs, even bugs that they've
caused. On the other hand, I know from talking to users that they care
a lot about bugs. There's a large class of users whose basic goal from
a new version of GCC is to get better run-time performance from their
code, without having to change their code. Bugs, and regressions in
particular, are a serious problem for these users.
I think GCC developers are well-intentioned, but busy. Many of us are
working on GCC at least partially as volunteers, and relatively few of
us are particularly incentivized to worry about problems we may have
caused on systems we don't use, or codebases we don't compile. But, I
think that many of us would respond to being nagged about relatively
high-priority regressions, and that if we begin to address these
problems earlier in the release cycle, that will help the project overall.
I also think that a fundamental responsibility for those of us with
check-in privileges is to clean up after ourselves. That's why we've
said -- correctly, in my opinion -- that the "latent bug" excuse is no
excuse at all; it's each contributor's responsibility to try to ensure
that their contributions make the compiler monotonically better. One
would hope that once a contributor tracks down a bug as being a latent
bug that an appropriate maintainer would help fix the latent bug, but
there's only one person who has the obvious responsibility to
investigate/fix the problem: the person who contributed the change that
caused/exposed it.
One of the reasons that we have bug priorities is so that we can ignore
unimportant bugs. That's also why I've established a procedure to allow
people beside me to flag PRs for downgrading. If you contribute a great
new optimization, and it causes us to generate an inferior error message
for some obscure test case, then that's a regression -- but we should
mark it P4, and you shouldn't have to worry about it. On the other
hand, if your great new optimization causes wrong code on a major
platform, then you should figure out why, and arrange to fix the problem.
In any case, theory aside, here is what I would like to do:
1. Add a field to bugzilla for the SVN revision at which a particular
regression was introduced. Display that in bugzilla as a link to the
online SVN history browser so that clicking on a link takes us from the
PR straight to the checkin. This field value ought to be the most
recent revision to the GCC trunk such that the bug did not occur in the
previous revision, but does occur in all subsequent revisions.
Danny B., would you be willing to do this?
Sure.
I have to look into bugzilla 3.0 migration first though. Bugzilla 3.0
introduces a custom fields mechanism, and i'd rather at least store
our data using that, than editing the schema wholesale like we do now
(which is *much* harder to port between versions of bugzilla, and one
of the reason we've had trouble keeping up).
So this may take a few weeks.
3. Set up a cron job to generate mail to people whose name is in the
ChangeLog entries for P3 and higher regressions, with the SVN field
filled in.
Bugzilla 3.0 also has a nice query api that can be used to do this,
without having to muck around with knowing lot about the internals of
how bugzilla stores data in it's sql database :)