This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Release schedule
- From: Stan Shebs <shebs at apple dot com>
- To: Joe Buck <Joe dot Buck at synopsys dot com>
- Cc: "S. Bosscher" <S dot Bosscher at student dot tudelft dot nl>, "'Mike Stump '" <mrs at apple dot com>, "'David Edelsohn '" <dje at watson dot ibm dot com>, "'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: Tue, 01 Oct 2002 15:32:18 -0700
- Subject: Re: Release schedule
- References: <200209302306.QAA24648@atrus.synopsys.com>
Joe Buck wrote:
Steven Bosscher wrote:
FWIW I am all *against* freezing dev branches. GCC developers are
volunteers, and taking away their fun projects is a bad thing.
Still I also think there are too many development projects right now, and I
also believe that it would be good to plan when these major improvements
should be finished, no matter how hard that may be in a project that depends
on the time of volunteers.
I think it's reasonable to *request* folks working on fun projects to
consider turning their attention back to trying to stabilize the release
at critical times in the development cycle, but that it's fruitless to try
to bludgeon them into doing so.
I agree; the current system of restricting the trunk probably forces
things about as much as one can get away with. The current system
*does* make a difference; I can tell my mgmt that the compiler is in
a bugfixing phase and they're OK with me working on bugs in FSF GCC
during that phase.
I also note that some of those "fun" projects are actually development
work being paid for by various people, and the funders would justifiably
feel cheated if they found that they were paying for release stabilization
instead. GCC release activity must always come after contractual
obligations.
Thinking about the problem, one thing I see is that there is not a lot
of visibility into PRs that might be especially relevant to particular
communities. For instance, Apple has multiple people that could be put
onto PRs that are known to cause bad codegen for Darwin apps, but for
the PRs that are about compiling Linux kernels on ia64, it's harder to
justify giving those as much priority.
How about a sort of bulletin board where some people post interest
in particular kinds of bugs, and where either the original PR
reporter or somebody else knowledgeable could say, "you should be
interested in this one because it affects all PowerPC, or all pic
code".
Stan