Beyond GCC 3.0: Summing Up

[Mark Mitchell <mark at codesourcery dot com>]

Many people commented on the proposal I posted about how to change
our development process going forward.  I appreciate all of the
comments and feedback.  Now that the discussion has settled down,
I'm going to post a summary, my own personal responses, and then
refer the matter to the SC for a final decision.  Note that the
responses here are my own opinions, not those of the SC.

First, your comments made me realize that there are serveral different,
and somewhat orthogonal, thrusts in my proposal.  We can make
independent decisions about these different aspects.  Here are the
major thrusts:

1. We should do certain kinds of development at certain times
   in the release cycle, and we should try to make our releases
   according to a schedule.

   This was the part of the proposal that talked about doing a release
   every six months, and having periods exclusively for bug-fixing, etc.

2. We should do dot-releases on a schedule as well.

   This was the part of the proposal that talked about when to do
   X.Y.Z (as opposed to X.Y) releases.

3. We should have a policy that prohibits regressions on the trunk
   by reverting offending patches, unless the poster is actively
   working on a fix.

I will treat these different sections in order.

Scheduled Development
=====================

Most people were enthusiastic about this part of the proposal,
which is arguably the most novel aspect, relative to our current
process.  I was thrilled to see that there was widespread support.

Many people commented that every six months was somewhat ambitious.
I agree -- but I think it's a good target.  I fully expect that
we will be fine-tuning this process as we go forward, as we see
exactly how things work.

Some people commented that the schedule would require people to
maintain large changes for long periods of time.  That is true --
if those people finish up their large changes at innoportune points.
Frankly, I don't think that this is a bad thing.  If it is not
worth the effort to merge the work a few months later, it was probably
not that valuable in the first place.  I know that I have maintained
large patches for months, bordering on years; I know that many others
have done the same.

Dot Release Schedule
====================

Some people argued for making dot releases very quickly when "critical"
bugs were noticed.  I think this is a mistake.  The problem is that
making a release takes a lot of effort, and so we are not doing something
else.  Nothing about a GCC release requires a "critical" fix -- nobody
has to use the new release.  Waiting a month or two to make a dot release,
and thereby incorporating more fixes and testing the fixes better, is
much better.  Predictability is important, and reducing the number
of versions in use is important.

Still, perhaps doing a dot release after one month, instead of two, or
every six weeks would be better.  Again, we can tune the process.

Reversions
==========

Some people thought we should revert things more aggressively than
I suggested; others less aggressively.  Overall, people agreed that 
reverting offending patches was reasonable.  Gerald pointed out that
people with write privileges to the offending area of the code should
be allowed to do reversions, not just people with global write
privileges.

Overall
=======

In general, people raised some questions about corner cases and
definitions.  Exactly what counts as something that needs to be done
on a branch, and therefore can't go in during the second phase of
development?  Exactly what qualifies as a regression?  Exactly when
does the clock start for reverting patches?

My opinion is that we will work these things out as we go along, and
that they don't need to be specified exactly.  We will need to develop
a common understanding, and there is no point in running GCC development
with military precision.  I, for one, do not like forms that must be
filled out in triplicate.  The point is simply to introduce some
additional order.

People also mentioned that more automated testing would be useful,
as would a better patch-review process.  I agree on both counts, but
I think that those kinds of changes are outside the scope of my
proposal.  The underlying thrust of my proposal is that we must aim
for incremental progress: each release of GCC is better than the one
before.  Similarly, we must aim for incremental progress with respect
to our development process: each process change should make development
better than it was before.

I will ask the SC to vote on the proposal, and I will let you all
know how it comes out.

Thank you,

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