Re: release scheduler?

[David Edelsohn <dje at watson dot ibm dot com>]

>>>>> Tom Tromey writes:

> I would have expected the 3.3 branch to have been created on October 15.
> If someone can tell me the current plan, I'll make a patch for that page.

> I want to know because we're trying to do some planning in java land.
> The question is whether to put active development on a temporary branch,
> or whether to just hold off on certain commits until the 3.3 branch is
> cut.

	The first priority has been generating the gcc-3.2.1 release.  The
next priority is preparing for the gcc-3.3 release.  I believe that
address regressions on the trunk before making the branch is a current
goal. 

	The conventional wisdom appears to be that best way to encourage
developers to devote resources to fixing the trunk is to delay the gcc-3.3
branch so that the developers will not be distracted by new features.  I
am not convinced that this method is entirely effective because developers
can develop new features on a branch or in their own trees.  Developers
will make their own determination whether fixing bugs will prevent them
from completing their new feature by the end of Stage 1 development.

	One could consider GNU/Linux and *BSD distributions and GCC
toolchain companies as GCC's direct "customers".  When their business
requires a release and/or can benefit from the new features in GCC, they
will devote the resources necessary to make a release.  This is why I
prefer to focus on technology goals for GCC instead of dates on a
schedule, within limits.  If GCC makes enough of a technology leap in each
development cycle, then the various GCC distributors will have a large
motivation to assist with a formal GCC release that can make those
features available to their customers.

David