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.
Hum, I checked the Merriam-Webster dictionary, and clearly "coercive"
was stronger than I thought it was :( I only mean to say: things can
get fixed by *gentling* pressuring people responsible for it, while
also accepting the pressure when it is applied to yourself.
This implies that you think it is the patch author's job to fix the
problem.
I think it was the patch author's job to either (a) fix the problem or
(b) identify it clearly, and hand it over to the responsible
maintainer.
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").
[...]
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.
My first problem with your reasoning is with "suggests": someone has
to do the analysis so that the bug can be correctly assigned and
fixed. If noone is deemed responsible for doing this, then that
regression might stay for years. It sounds not unreasonable to me to
ask the person who committed the patch to do this analysis. After all,
if he had seen it during his regtesting (in that particular case,
testing with Fortran would have probably shown the regression), I
don't think the patch would have been approved, would it?
Reverting the patch is an option, but that would re-open
whatever problems the patch fixed.
And the second issue I see is: unless the patch was actually fixing a
more important regression, which is not the most common case (and not
the case here), you have actually traded a bug (or sometimes, even
only a missed-optimization) for a regression.
FX
