This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: 3.1 branch check-in policy questions
- From: Jan Hubicka <jh at suse dot cz>
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: mark at codesourcery dot com, gcc at gcc dot gnu dot org
- Date: Wed, 27 Feb 2002 15:59:46 +0100
- Subject: Re: 3.1 branch check-in policy questions
- References: <10202271156.AA20022@vlsi1.ultra.nyu.edu>
> I have two areas where I wanted to ask if check-ins to the 3.1 branch
> are appropriate. I believe they both are, but wanted to confirm:
>
> (1) I'd like treat Alpha/VMS support the same way as we're treating Ada: since
> it's a new feature, changes just to files for it should be permitted to fix
> bugs that are not necessarily regressions.
If I understnd properly, the ADA, like Java, can be fixed because it is
not part of release criteria. Similary the Alpha/VMS is not (or x86-64/Linux
that interest me), so I interpret it as falling to same category - Alpha/VMS
specific changes are OK as long as they do not affect Alpha ports in the
release criterias.
Honza
>
> (2) I'd like to clarify that "regression" means not just something that
> worked in 3.0, but things that used to work in the top-of-tree, but now
> don't. I'm thinking specifically of the Sparc bootstrap sitation (it now
> fails in the Ada part of the bootstrap, but used to work) and the situation
> with RTH's change of February 21, which caused some regressions, but on
> things that didn't used to work (Alpha/VMS and an Ada test) with 3.0, but
> worked a few weeks ago.
>
> Do you agree?