Re: Beyond GCC 3.0

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

I have a few comments here.

A minor issue is that I think the "48 hours" period for fixing bad changes
should be modified to at least take into account weekends and holidays and
perhaps to have a range (say 36-72 hours) depending on the importance of the
change in question, the severity of the breakage, and the stage of development.

A major concern relates to the issue of major development in the mainline
during four of each six months.  The proposal you've made means that if a
window is just missed, it will be four months until a development branch can
be merged in.  This is a long time and causes two problems, first that it
will be frustrating to the developers on that branch to wait that long to
have their work be seen more widely and second that the work involved in
doing the merge will be high.

Instead, I'd suggest that the release branch be made at the end of month 4
and the mainline be reopened at that point.  So what we have in the
steady-state are the following periods, each of which have two simultaneous
development processes:

- months 1 & 2
    stability fixes on the release branch from the last release
    same as your proposal ("free for all") on the mainline
- months 3 & 4
    possibility of a second "dot" release on the release branch
    same as your proposal ("hack on") on mainline
- months 5 & 6
    new release branch fork for stabilization
    "free for all" on the mainline

I also do not like the idea of suggesting that major development projects
ever be done in local trees.  People will tend to do this anyway, but I think
that stating it in this way "validates" the idea, which is I think is poor.
Instead, I'd simply say that major development must be done in branches.

Another concern of mine here is how many such development branches we are
going to get, how long they'll be active, and concerns about conflicts
between the branches.

After all, if somebody does (to use one example) a new register allocator
that may well affect the heuristics used in, say, loop optimization.  So if
somebody else is doing work on a new loop optimizer, should they be doing
that work with the mainline or the new register allocator?  Are we going to
get into "branches within branches"? 

Here I don't have any concrete suggestions, but I fear the number of branches
and subsequent merging work may become unwieldly large unless some procedures
are put into place from the start to deal with this issue.

Finally, I want to remind people that the fork of the EGCS project in the
first place started because of concerns about an overly-conservative checkin
policy regarding major developments.  We don't want to react to stability
issues by going too far back in that direction for fear of a similar event
happening again.