This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Release schedule
- From: Steven Bosscher <s dot bosscher at student dot tudelft dot nl>
- To: David Edelsohn <dje at watson dot ibm dot com>
- Cc: Mark Mitchell <mark at codesourcery dot com>,Gerald Pfeifer <pfeifer at dbai dot tuwien dot ac dot at>,"gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: 28 Sep 2002 23:21:29 +0200
- Subject: Re: Release schedule
- References: <200209281959.PAA23576@makai.watson.ibm.com>
Op za 28-09-2002, om 21:59 schreef David Edelsohn:
> When do you propose that major, new features be developed? Our
> current schedule does not allocate any time for the extended effort
> required to design and implement major advances. It does provide for
> merging major, new features in Stage 1, but new features cannot be
> developed in three months.
Development branches can exist for more than three months, so the
schedule is only part of the problem.
One other part of the problem is that *too many* separate major
improvements are under development right now, and the GCC project simply
lack the resources to prepare a release-worthy GCC and have so many
development projects at the same time.
If there were only two or three projects, things would be much easier,
and developers would be able to develop major improvements and still
have time to fix bugs.
So apart from a new release schedule, maybe we need a new branching
policy.
> Because of the overlap between releases and development, GCC
> developers are forced to make a choice
Yes, and closing development branches in the weeks before branching
would "help" them make the choice ;-)
> Many developers were unable to
> contribute major improvements they had planned for GCC 3.3 because they
Who had planned to contribute what, then, where is this plan? And why
isn't that part of the release plan?
I've said before that it's a *good* thing to document which improvements
should go in what release.
Greetz
Steven