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? 2. Ask volunteers to fill in the field. Independent of what you may think of my philosophical statements above, this is useful data. One of the first things many of us do when trying to debug a new problem is figure out what changed to cause it. And, this is work that even a volunteer without great knowledge of the compiler's internals can help with, perhaps using Janis' scripts to help with testing. 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. I will volunteer to work on this part of things, but hopefully I can get some help from our SVN and Bugzilla experts. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713