This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Beyond GCC 3.0: Summing Up


<<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!


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]