This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: GCC 3.3, GCC 3.4
- From: "Scott Robert Ladd" <scott at coyotegulch dot com>
- To: "David Edelsohn" <dje at watson dot ibm dot com>, "Mark Mitchell" <mark at codesourcery dot com>
- Cc: "Benjamin Kosnik" <bkoz at redhat dot com>, <tromey at redhat dot com>, <jbuck at synopsys dot com>, <gcc at gcc dot gnu dot org>
- Date: Mon, 3 Feb 2003 17:04:06 -0500
- Subject: RE: GCC 3.3, GCC 3.4
Dave Edelsohn wrote:
> Either extreme of schedule driven or feature driven development
> causes grief. We need to find a flexible middle ground. I think our
> current schedule places developers in a catch-22 situation that is
> discouraging and demoralizing.
Discouraging, in my case.
I am seriously interested in working on gcc -- in fact, I've been active in
the "GOMP" group that has just started working on an OpenMP implementation.
However, I find the current schedule rather daunting; we're talking 3.2.2,
3.3, and 3.4 in (what appears to me) rapid succession. I think there is a
middle ground between Microsoft's "yawn, we'll fix it someday" attitude, and
rabbit-rapid releases.
> Again, accomodating developers both frees up more developers to
> fix bugs in the current release branches and encourages those developers
> to fix bugs in the next release branch so that their improvements are
> available in a release. Currently the development process discourages
> developers and creates the small pool of people fixing bugs, about which
> you have complained. The current policy is part of the problem.
In my experience, the best development process is rapid, small releases
punctuated by occasional major releases. In gcc terms, that might mean (and
this is *only* a suggestion) a 0.0.x release every month or six weeks, with
bug and regression fixes, with major releases (0.x) every four to six
months. This provide stability while also "moving forward."
> GCC releases already are delayed because of regressions and PRs,
> so allowing a longer window for integrating recommended goal features will
> not make it worse if the same developers are able to help with bug fixes.
Moving too quickly in large chunks is a recipe for generating bugs. I've
just slowed one of my commercial projects for that very reason; my client
kept adding or changing major features before we could straighten out bugs
and "refactors." Getting to market is a Good Thing; getting to market with a
troubled product is a Bad Thing.
Writing cool new features is always more fun the debugging -- but debugging
is less onerous and more fun if taken in small bites. And bugs may not
appear as often if we move to a more graduated process.
..Scott
--
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Professional programming for science and engineering;
Interesting and unusual bits of very free code.