This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Beyond GCC 3.0
- To: Nathan Sidwell <nathan at codesourcery dot com>
- Subject: Re: Beyond GCC 3.0
- From: "H . J . Lu" <hjl at lucon dot org>
- Date: Fri, 29 Jun 2001 11:03:59 -0700
- Cc: Mark Mitchell <mark at codesourcery dot com>,Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>, gcc at gcc dot gnu dot org
- References: <339710000.993708666@warlock.codesourcery.com> <3B3C42FC.2420732@codesourcery.com>
On Fri, Jun 29, 2001 at 09:57:32AM +0100, Nathan Sidwell wrote:
>
> H . J . Lu wrote:
> > > - Do bug fix releases two and four months after the major
> > > releases, as required.
> >
> > Unless I am mistaken, I don't think there should be a time constraint
> > on the bug fix releases. We know any gcc releaases can't be bug-free
> > for everyone. Every gcc release has bugs, some of which are critial to
> > some people. If we can make the bug fix branch relatively stable, what
> > is wrong to make a bug fix release everytime when there are enough bug
> > fixes checked in? Sure, it may have new bugs. But it does fix some old
> If we do have releases every six months and the monotonic improvement
> goal is achieved, the release N+1 will have all the fixes you'd want to
> have in release N's third bug fix release. If that doesn't happen, then
> we've messed up. Two exceptions,
Assuming release N you talked about is a major release, I don't
think the first version of release N will ever have no regressions
and bugs without workaround. All I said was we should make
release N with no regressions/bugs without workaround by making
frequent, incremental bug fix releases against release N.
H.J.