Re: Beyond GCC 3.0

[Nathan Sidwell <nathan at codesourcery dot com>]

I'm responding to several messages here, hopefully the attributions
will be correct.

Mark Mitchell wrote:
> [stuff]

In general, good - we currently have too long between releases &
too much last minute effort.

> I think that we need a new method, one that gives better
> predictability for all:
> 
>   - Do a new release every six months.
I think this is ambitious - but why not give it a go.

>   - Do bug fix releases two and four months after the major
>     releases, as required.
'major release'? Is each 6-monthly release a major release, or only
some of them? (I presume the next major release in this context
will be before gcc 4.0?)

Richard Kenner wrote:
> 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.
Disagree, as Joe Myers said, we're in more than one timezone.
a) any global write person can revert the patch, so the patch's author
need not be present.
b) never check in a patch on Friday night, just before you're off on
a break ;-)

Richard Kenner wrote:
> 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.
Looking at the egcs timeline, historically there's been 9 months between
egcs releases 1.0->1.1->2.95, then a huge gap of 2 years til 3.0.
If you miss the 2 month window, then the longest you wait til a release is
out is an additional 6 months. This is better than has historically
been acheived.

Richard Kenner wrote:
> 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 
I think this is bad. One source of error is not back applying patches
from release branch to mainline. Having only the mainline to deal
with for stabalization should be a win.

> 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.
A (non-version controlled) summary file? Something like
   allocator-branch	A new register allocator touching things in the
backend code generator, mainly in foo.c, bar.c and baz.c

H . J . Lu wrote:
> >   - Do bug fix releases two and four months after the major
> >     releases, as required.
> 
> Unless I am mistaken, I don't think there should be a time constraint
> on the bug fix releases. We know any gcc releaases can't be bug-free
> for everyone. Every gcc release has bugs, some of which are critial to
> some people. If we can make the bug fix branch relatively stable, what
> is wrong to make a bug fix release everytime when there are enough bug
> fixes checked in? Sure, it may have new bugs. But it does fix some old
If we do have releases every six months and the monotonic improvement
goal is achieved, the release N+1 will have all the fixes you'd want to
have in release N's third bug fix release. If that doesn't happen, then
we've messed up. Two exceptions,
1) Release N accepted some ill-formed construct that release N+1 rejects.
User's production code uses that construct.
2) Release N+1 deprecates some extension that release N implemented.
User's production code uses that extension. If user == lots of users, we
may well have messed up.

Barring our errors on these 2 senarios, the user has locked themselves
into release N. They have a financial decision to make -- commit resource
to (a) alter their code base, (b) maintain their own bugfix release N.
That is their choice.

I'm all for a regular cycle, no doubt this one will need tweaking
after the first iteration, but is looks like a good start.

nathan

-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org