Re: Beyond GCC 3.0: Summing Up

[Mark Mitchell <mark at codesourcery dot com>]

--On Monday, July 09, 2001 05:38:03 PM +0000 Richard Kenner 
<kenner@vlsi1.ultra.nyu.edu> wrote:

>     > But a key point is who are the "users" here?  I'd argue that the
>     > "users" are in fact the set of developers since they are the people
>     > who mainly use the top-of-tree sources.  So what we're doing with
> the     > proposed approach is frustrating one group of users in favor of
> another.
>
>     Yes, but if, say, IRIX 6.5 is broken, and a developer who works on the
>     Java front-end on an IRIX box cannot work without manually reverting a
>     bunch of patches, and who may not even known what has gone wrong, then
>     you've frustruated GCC developers too.
>
> It sounds like you're agreeing with me.

No, not really.

Situations where people don't know which tests pass and which don't,
or where they can build, but not bootstrap, are not conducive to being
able to make progress.

In a company, it might be reasonable for the reload guy to check in
his stuff and expose a latent bug in the SPARC back end, since
management would then make the SPARC guy fix the bug there right away.
That does not, and cannot, happen in our environment.  We don't really
even have maintainers for all the back ends, for example.  The only
obvious person to make responsible for the breakage is the guy that
checked in the change.

Note that my proposal explicitly indicated that if you are working on
fixing the problem, your patch would not be reverted.  So, as long as
the reload guy, when seeing the problem report, is willing to say
"oh, OK, the SPARC back end is broken, I see what's wrong, I'll have
a patch tomorrowish" we leave things be.  That should be extended to
the case where somebody else says the same thing.  The point is that
the fix is being actively worked on with a very immediate time frame.

The point is that before the next release the latent bug needs to get
fixed, if we're going to have the new functionality.  We either fix
one problem first, and then the other, or both at once.  Both at once
is OK.  The latent bug first is OK.  The problematic case is that we
fix the latent bug later than applying the patch.

It is not really that hard to fix, or get someone to fix, the latent
bug *before* applying your patch.  If it *is* that hard, then we have
a problem -- applying your patch is likely to lead to a regression in
the next release, and that is bad.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com