This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Volunteer for bug summaries?
On 22/05/07, Joe Buck <Joe.Buck@synopsys.com> wrote:
On Tue, May 22, 2007 at 06:13:58PM +0200, François-Xavier Coudert wrote:
> >CCing the person who caused the regression is more appropriate. Assigning
> >bugs to them detracts others from fixing the bug.
>
> We already do that, and in lots of cases it doesn't work. CCing is not
> coercive enough, you only receive a few more mails (and some people
> don't even read their bugzilla mail).
Coercion isn't an option that is available to us.
That is why they may unassign themselves from the bug without fear of
reprisal ;-). Generally the list of bugs assigned to one person is
much smaller than the her list of copied bugs. Better than "coercive",
I would say, informative. The point is that you may add to the CC list
a bunch of people that may be interested in the bug but there is a
person that is expected to take some action, even if that action is
washing her hands (=unassigning themselves).
> Take PR31095, for example. It's a 4.3 regression on x86 and x86_64
> that is triggered on the GCC testsuite, it has been known for more
> than 2 months, Janis kindly did a reghunt a month ago to attribute it,
> the patch author was added in the CC list. Since then, nothing
> happened.
This implies that you think it is the patch author's job to fix the
problem. And if the patch were incorrect, you'd have an argument.
But in this case, it seems that the patch is correct, but it exposes
a problem elsewhere in the compiler (one of Kenner's famous "latent bugs").
So it would be fair for the author to say so and unassign himself. Or
perhaps the author has some idea of what is going on and could assign
to someone else. This is not "blaming", it is just a way to deal with
the issue of people believing that it is someone else's turn to take
action.
Andrew's comment suggests that the real bug is elsewhere, and I don't get
why the author of the above patch is responsible for fixing that other
breakage. Reverting the patch is an option, but that would re-open
whatever problems the patch fixed.
You got to this conclusion because you took the time to analyse the
patch and to realise that it wasn't the cause of the problem. The
point is that we may hope the patch author to do that work (unless
someone does it before) and then take whatever action seems
appropriate (assign to other person or just to nobody). I think that
is a fair hope and may solve the issue that Mark raised.
Cheers,
Manuel.