Re: Beyond GCC 3.0: Summing Up

[Marc Espie <espie at quatramaran dot ens dot fr>]

In article <185530000.994713895@warlock.codesourcery.com> you write:
>
>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.

Not really. You could have one or two members of the steering committee
in charge. Then there are all kinds of levers they can use to force
focus to happen (regression bad. better code good).


For instance, a fairly large subset of  the gcc developers have addresses
that obviously imply they are doing this for a living and just threatening
to not accept anything from them until they cleaned up a mess they did
somewhere ought to be largely enough.

Note that not all open software projects work under a benevolent 
management. It isn't a pre-requisite of the model, and I might even
say it's not necessarily the most succesfull way to make things work.
In fact, I do work in an open project with a clear Leader. I'm not
even alone. And even though we sometimes chaffe at some of his decisions,
it's overall a very good thing: stuff advances much faster with an arbitrer,
and quality gets higher when you've got someone worrying over the release
process and downright telling you when you f*ed up and committed buggy code.

Well... BTW, when do I get feedback on my [GCC 3.0] posts ?