This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch to generate gcc.1 from invoke.texi
- To: Mark Mitchell <mark at codesourcery dot com>
- Subject: Re: Patch to generate gcc.1 from invoke.texi
- From: Richard Earnshaw <rearnsha at arm dot com>
- Date: Sat, 13 Jan 2001 22:15:54 +0000
- Cc: toon at moene dot indiv dot nluug dot nl, jsm28 at cam dot ac dot uk, gcc-patches at gcc dot gnu dot org
- Cc: rearnsha at arm dot com
- Organization: ARM Ltd.
- Reply-To: rearnsha at arm dot com
mark@codesourcery.com said:
> The primary problem is that people are busy doing other things, which
> isn't their fault. I think that this stems to some extent from the
> fact that, while many organizations are paying for GCC support and
> development, very few are paying explicitly for work in the FSF
> development tree. That means that other trees are regularly
> stabilized towards a release, but that happens less often in FSF tree,
> because the same resources are not available there.
It's not for me to tell you how to manage the project, but I'm a little
surprised you haven't explicitly called a feature freeze (or even a
stabilization freeze).
My biggest concern about open-source projects is that as soon as the
branch is made everyone will ignore it and concentrate on getting their
latest cool idea into the code-base; given that we can't force people to
work only on stabilizing the branch we can encourage them to do so by
preventing the new sexy features from being added until after some of the
existing problems have been sorted out. A bit of the carrot and stick
approach.
I'm not advocating that we should spend months in a feature freeze
(probably just a few days), but if it would help to concentrate minds I'd
be all for it. A reasonable (and measurable) goal that could be set would
be that all primary and secondary platforms should at least survive a make
bootstrap at the time the branch is made.
Just adding my 2c worth.
R.