Volunteer for bug summaries?

[Daniel Berlin]

On 5/22/07, Mark Mitchell <mark@codesourcery.com> 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 :)