Re: [RFC] Our release cycles are getting longer

["François-Xavier Coudert" <fxcoudert at gmail dot com>]

[sorry for breaking the thread; stupid gmail doesn't want to add
custom References headers]

> It may be that not too many people pick up 4.2.0.  But, if 4.3 isn't
> looking very stable, there will be a point when people decide that 4.2.0
> is looking very attractive.  The worst outcome of trying to do a 4.2.0
> release is that we'll fix some things that are also bugs in 4.3; most
> 4.2 bugs are also in 4.3.

> From the Fortran point of view, and however limited it might be,
skipping the 4.2.0 release would be very unfortunate. We've been
working hard on it, and especially in recent time, many bug fixes have
been deemed to risky to backport to the 4.1 branch. 4.3 is still a
long way down the road, and the 4.2 branch has interesting features
even from the non-Fortran point of view.

About the other points of the discussion, maybe getting more exposure
for the mainline branch (4.3.0) could get us more feedback? People are
more involved in fixing bugs when they come just after their patch
commit than when the report comes one month after. (and I can thing of
examples in our bugzilla that confort this view :)

Now, how to get greater exposure? We (some of the gfortran
maintainers) have been making available regular binaries of the
compiler for common archs; most of the bug reports are made from
people using these binaries, so I suppose it's a way that works for
us. There are a few people that help with gfortran development, not by
patching, but by testing/filing detailed bug reports/writing
testcases/etc. (They even tend to get involved in gfortran patching at
some point :)

Can it work for GCC as a whole? Maybe not for all types of bugs and
users (the Fortran users mostly have mainstream archs), but we could
nonetheless use more feedback and maybe have more people testing their
apps with the latest mainline state.

Sorry for being so long, but maybe the gfortran experience can help here,
FX