Re: Beyond GCC 3.0: Summing Up

[Alexandre Oliva <aoliva at redhat dot com>]

On Jul 10, 2001, Mark Mitchell <mark@codesourcery.com> wrote:

> or two, but made process invocation faster?  Or if the new version of
> X displayed bitmaps faster, but occasionally locked up when running
> GNOME?

You're comparing apples and oranges here: trading correctness for
speed is not generally reasonable.

> Or if a new web-browser had support for animated GIFs, but all
> JavaScript pages that used to work stopped working?

I wouldn't care too much about Javascript.  But then, I don't care too
much about animated GIFs either :-)

Abstracting this fact away, if I were to make a call, I'd certainly
choose to have both features working as soon as possible.  I claim
that leaving the patch in that exposes the latent bug, with a failing
testcase in the testsuite, or even a bootstrap failure, would make
sure the bug gets fixed faster than reverting the patch that fixes the
other problem.

Now, if I had to choose between one feature or another, I'd love to
have the choice.  Putting myself on the position of someone whose code
used to work, but now breaks because of the patch, I'd obviously
prefer to have the patch reverted.  But putting myself on the position
of someone whose code wouldn't work previously, because of the bug
fixed in the patch, I'd obviously prefer to have the patch kept in.  I
don't think it's as simple as ``it breaks something, so it must be
reverted.''  We must give people the option.  Keeping a database of
patches that are in, but that are known to expose latent bugs, so that
people have the option to revert the patch in case they have to, but
still keeping the patch in for everybody else, is, IMHO, the best way
to get both problems fixed, instead of getting both ignored.

> When that kind of thing happens, it is very frustruating.  As a user,
> I've sometimes had two of something -- and used one version for some
> things and the other for other things.  That drives me crazy in a
> hurry.

Would you prefer to have only ``one version'', and not be able to do
the ``other things?''

> This argument is common -- but seems to be refuted by the fact that
> literally hundreds of regressions were fixed on the 3.0 branch, and
> that many more remain.  Why weren't they fixed earlier?

Because they were not testcases that the regression tester would
complain about?  Gnats bug reports are a good thing, but unless
someone goes over them and converts them to something that can be
automatically tested, odds are that the bug reports are going to
remain unfixed until someone enters release mode and goes desperately
attempting to fix as many problems as they can.

>> Reverting the patch so as to return to the
>> previous broken state is just papering over the problem.  If we reject

> But there was no problem for the user.

No.  There was no problem in the testsuite.  The bug was there.  It
just happened to not be exposed by the existing testcases.  Well, ok,
there may be cases in which it was absolutely impossible for the bug
to show up, and, in these cases it's probably reasonable to revert the
patch.  But I don't think these cases are the majority.

>> patches that paper over problems, which we do, why should we encourage
>> patches that revert patches that exposed latent bugs?

> We'd be encouraging the poster to take responsibility for fixing the
> latent bug as well.

But by keeping the patch in, we'd be encouraging everybody to take
responsibility for fixing it.  Why place the burden on the very person
who's already done us the favor of fixing one bug?

> The poster would want to get her patch checked
> in, so she would either fix the latent bug, or lean on other people
> to fix it.

And if the patch remained in, more people would be leaning other
people to fix it :-)

> It's just an ordering thing: if we can't get anyone to fix the
> latent bug before checking in the patch, or as soon as the problem
> is noticed, why do we think we can get someone to fix it afterwards?

I believe my point still holds: why would we approve a patch that
introduced a regression in a test case (reverting the patch that fixes
a bug)?

> That shifts the burden to people who had nothing to do with the patch;

Precisely.  People who are running into the problem are far more
likely to spend time fixing it than the poster, who probably doesn't
even have access to the platform on which the problem shows up.  Of
course, the poster of the patch should be willing to cooperate to get
the bug fixed, but I propose that his/her only obligation should be to
maintain the gnats PR that describes the latent bugs exposed by
his/her patch.  If people who run into the problem have time to
investigate and try to fix the problem, they will.  If not, all they
have to do is look up the problem they're observing among the open PRs
in a certain gnats category created specifically for the purpose of
holding this kind of PR, and install the patch.  Yes, it's less
convenient that simply leaving the latent bug and the breakage fixed
by the patch there.  But that's the very point.

> And, *all* such people must do the work of reverting the patches
> locally to make progress.

Only if they don't care about fixing the bug.  Why shouldn't they
share part of the burden?  The other person has already provided them
with a patch that fixes a bug.  Unfortunately, it also exposes a
feature; they'll have the choice between helping the community get the
latent bug fixed or spending a little bit of time reverting the
patch.  I bet a number of people will prefer to go the first route, so
that we'll get the bug fixed; this will be the more likely the more
serious the problem is.

After all, getting the formerly-latent bug is also making progress.
But reverting a patch that fixes an actual bug isn't.

> Since, under my proposal, reversion only occurs if nobody is working
> on a fix in the short term, we are, by hypothesis, going to be
> saddled with the breakage for a longish period of time.

The more serious the breakage, the more likely people will work on
fixing it.  So we'd only remain with a breakage for a longish period
of time if nobody cares about it.  In this case, the breakage can't
possibly be serious.

> Why not simply revert the patch, and/or put it on a branch, so that
> people can work on fixing the latent bug without interfering with
> everyone else?

Because reverting the patch will also introduce a regression, and
reverting the patch has a strong potential of having the bug (and the
fix) end up forgotten, so we'd remain with two bugs, instead of one.
Then, eventually, someone will notice the bug again, attempt to fix
it, and possibly come up with a solution that, again, exposes the
latent bug.  So the time of these two people will have been wasted.
The second person might very well have spent the time fixing the
latent bug.  Or fixing some other bug, because someone else had
already fixed the latent bug.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me