This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Beyond GCC 3.0: Summing Up
- To: kenner at vlsi1 dot ultra dot nyu dot edu, mark at codesourcery dot com
- Subject: Re: Beyond GCC 3.0: Summing Up
- From: dewar at gnat dot com
- Date: Mon, 9 Jul 2001 23:11:20 -0400 (EDT)
- Cc: gcc at gcc dot gnu dot org
<<I do agree with your key comment that all we have are volunteers.
That's why I'm concerned about making it too hard for them. If we do,
we'll either have less volunteers, or they will go off and make their
own playpen, as has happened before.
>>
The only way that shared development works (and this comment is true for
volunteers, or paid professional programmers) is if everyone cooperates
closely and works very hard not to break things. If someone carelessly
breaks things, and does not immediately work very hard to repair the
damage, then *thats* when people get frustrated and don't feel
like working on the system any more.
It's all the more important that volunteers make a special effort to
keep things in good shape, precisely because there is less management
control to deal with a mess.
<<That's why it's important to carefully figure out what's "buggy code":
the new patch or some latent bug.
>>
Richard has always made a very big deal of this distinction, and taken
the viewpoint that if the breakage is due to a latent bug then there is
no good reason to back things out, but I don't think this view is
realistic. A bug is a bug, and a failure is a failure. If your patch
causes things to fail that did not fail before, then your patch is
ultimately at fault!