This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Our release cycles are getting longer
- From: "Steven Bosscher" <stevenb dot gcc at gmail dot com>
- To: "Diego Novillo" <dnovillo at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 24 Jan 2007 00:55:29 +0100
- Subject: Re: [RFC] Our release cycles are getting longer
- References: <45B69212.10903@redhat.com>
On 1/23/07, Diego Novillo <dnovillo@redhat.com> wrote:
So, I was doing some archeology on past releases and we seem to be
getting into longer release cycles. With 4.2 we have already crossed
the 1 year barrier.
Heh.
Maybe part of the problem here is that the release manager isn't very
actively persuing a release. The latest GCC 4.2 status report is from
October 17, 2006, according to the web site. That is already more
than 100 days ago.
For 4.3 we have already added quite a bit of infrastructure that is all
good in paper but still needs some amount of TLC.
And the entire backend dataflow engine is about to be replaced, too.
GCC 4.3 is probably going to be the most experimental release since
GCC 4.0...
There was some discussion on IRC that I would like to move to the
mailing list so that we get a wider discussion. There's been thoughts
about skipping 4.2 completely, or going to an extended Stage 3, etc.
Has there ever been a discussion about releasing "on demand"? Almost
all recent Linux and BSD distributions appear to converge on GCC 4.1
as the system compiler, so maybe there just isn't a "market" for GCC
4.2.
I don't see any point in an extended Stage 3. People work on what
they care about, and we see time and again that developers just work
on branches instead of on bug fixes for the trunk when it is in Stage
3.
IMHO the real issue with the GCC release plan, is that there is no way
for the RM to make people fix bugs. I know the volunteer blah-blah,
but at the end of the day many bugs are caused by the people who work
on new projects on a branch when the trunk is in Stage 3.
Maybe there should just be some rules about accepting projects for the
next release cycle. Like, folks with many bugs assigned to them, or in
their area of expertise, are not allowed to merge a branch or big
patches into the trunk during Stage 1.
Not that I *really* believe that would work... But skipping releases
is IMHO not really a better idea.
Gr.
Steven