Re: Radical proposal: skip 3.4

[Gerald Pfeifer <pfeifer at dbai dot tuwien dot ac dot at>]

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.

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.

This was one of the major problems with all 3.x releases of GCC so far.

On Fri, 9 Jan 2004, Andrew Pinski wrote:
> I think anyone who is working on the branches should spent at least an
> hour for every four hours they spend on the branch.  This will help get
> regressions fixed faster.

That would be great. Unfortunately, it may not be feasible for those
working under contracts; fortunately, several developers are now mostly
focusing on fixing regressions, which is great.

> 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.

On Sat, 10 Jan 2004, Jan Hubicka wrote:
> There are only 38 bugs marked as critical, I plan to iterate over them
> this week.  Last two weeks I was fixing bugs assigned dirrectly to me
> and fixed about 5 or 6 of them with not very concentrated effort.
> Assume that it is realistic to fix 10 bugs per week, so 4 developers
> together can do it.  (well, this is probably little bit optimistic, but
> lets see)

:-)

> I also think that GCC 3.4 is important especially if we take into
> account possible delays and usability problems with GCC 3.5 having
> even more radical changes than 3.4 has.

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.

Gerald