This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Radical proposal: skip 3.4
On Sunday 11 January 2004 00:11, Gerald Pfeifer wrote:
> On Fri, 9 Jan 2004, Jim Wilson wrote:
> > There are already so many people working on branches that I don't see
> > much benefit to delaying the creation of the gcc-3.4 release branch.
>
> Creating the release branch (too) early hurts those working on it.
Creating it too late also hurts. And what hurts even more is that
there is no incentive whatsoever for anyone (including myself, to my
shame) to fix bugs assigned to them. That's not trolling, it appears
to be a blunt fact. I mean no offense, but if there are _critial_ bugs
that go untouched for months (my favorite is PR11439), then _perhaps_
we'll have a release branch in the next millenium.
> After the release branch has been created, those hacking on new features
> just have one branch to care about (mainline), while those working on the
> release and trying to fix regressions need to apply and test(!) there
> patches both on the branch and mainline.
At the risk of repeating myself too often, I'll say again: we have
many bugs targeted for 3.4 because we have excelent bug masters.
This is more a problem of assigning/maintaining proper milestones
than a compiler quality issue.
Many regressions are with respect to some ancient compiler, and
these went unnoticed for years. There is absolutely no sense in
requiring those to be fixed for 3.4, more so because we have a six
month release cycle on paper but look at where we stand after 13
months.
> This was one of the major problems with all 3.x releases of GCC so far.
Another major problem for all 3.x releases was that mainline was closed
very often, causing people to work on branches. We have seen that for
3.3, and it's happening again now.
(Also we lack a proper feature plan/roadmap or some kind of effort to
coordinate all the efforts of various contributors, but that's a
different issue...)
> > But this is not really true as some OS companies are really working on
> > a branch and that is it as they do not care for 3.4 at all.
> > [...] but it looks like they are just going to skip 3.4 anyways.
>
> Yup. My guess is that most OS companies and free distributions will skip
> 3.4. Which may be part of the problem we are seeing.
Another real problem we're seeing is that people can/do not finish their
work when their contract ends. And another one (IMO) is that we're over-
pedantic about regressions. There are still many c++ regressions, but
the number of fixed bugs is much higher. We have unit-at-a-time which
has fixed some serious compile time issues and memory problems. PCH is
very useful for some people. Nobody seems to take the _good_ things into
account, only the regressions.
Of course the major regressions are very serious. But regressions like
12978, 13376, 12845, 13577, 12267, and so on, are really minor, more
like enhancement.
Just because we have known bugs does not mean a compiler is not release
worthy (or indeed, ready).
> One reason to get out 3.4 is to give the new C++ parser more exposure
> to users, and developers a chance to fix their codes wrt. standard C++
> in time for 3.5.
Another reason is that we'll probably see the same long release cycle for
3.5 unless we get a proper release plan including a feature plan and
preferably even a crude time line <ducks real deep>.
Gr.
Steven