Re: GCC 3.3, GCC 3.4

[Mark Mitchell <mark at codesourcery dot com>]

> 	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.
We have already modified the schedule to eliminate the release/freeze
overlap that we had; they are now offset by a month.  I've already asked
what branches people want to get in to 3.4, and when they're likely to
be ready.

The biggest real problem is that our developers are overbooked.

As soon as they implement one feature so that it mostly works, they are
off to implement another, often due to constraints from management.  As
a result, they don't have time to fix bugs, even bugs in the work they
just did.  We often get many of the regressions out, but a few hard ones
linger.

In a "traditional" release process, we'd all implement some stuff, and
then fix bugs for a while, and then do a release.  Or maybe some of us
would implement and some of us would fix.  In either case, someone would
supervise and tell us what was most important and move some fixers to
help implement and some implementors to help fix and so forth.

We have nobody that can fill that supervisory role.  It is simply not
possible; the players have very divergent interests.

In some other free software projects, people do fill that supervisory
role.  Linus is the ultimate authority for Linux, for example.  We
have a different structure.

I am very willing to consider other alternative ways of accomplishing
what I consider the basic goal: making high-quality releases on a
frequent enough basis that most development is focused on the FSF
versions of GCC, rather than on various forks.

I suggest the following:

- Rather than free-form discussion on this mailing list, let's
 write up complete proposal(s) and post them on our web site.

 - What methodology to you have in mind?

   - When do release branches get made?
   - When do releases get made?
   - Are there development stages?  If so, what are they, and
     how are the transitions managed?

 - Who will make decisions?

 - How will conflicts and disagreements be dealt with?

 - How will this be an improvement over our current system?

   - What primary problems are you trying to solve?  How are
     they solved?

   - What new problems do you forsee?  How will they be dealt
     with?

 I'd expect these to be 3-5 page proposals.  When we've got one
 or two ready, let's talk about them a bit, present them to the
 SC, and decide.

- Let's take this off the table for 3.4.  Consider it a 3.5 and
 beyond project.  Any discussion of this magnitude takes a *lot*
 of time and effort.

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