This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: 3.5 integration branch created
- From: Andrew Pinski <pinskia at physics dot uc dot edu>
- To: Geoffrey Keating <geoffk at apple dot com>
- Cc: Caroline Tice <ctice at apple dot com>, Andrew Pinski <pinskia at physics dot uc dot edu>, "'gcc at gcc dot gnu dot org'" <gcc at gcc dot gnu dot org>
- Date: Tue, 13 Jan 2004 18:52:05 -0800
- Subject: Re: 3.5 integration branch created
- References: <F31EE8E4-462E-11D8-9DF9-000A95B1F520@apple.com>
On Jan 13, 2004, at 17:14, Geoffrey Keating wrote:
I have created the gcc-3.5-integration-branch. It is similar in some
ways to the 'basic-improvement' branch in the GCC 3.4 timeframe, but
has some significant differences. The rules for the branch are:
1. This branch is for fully-tested, approved patches. The rules for
committing to it are the same as the rules that apply during Stage 1
of GCC development. Experimental or incomplete work should not be put
on the branch.
Well then you should not be accepting patches that usually go in for
Stage1 then.
2. The intention is that immediately after GCC 3.4 branches, this
branch will be merged back to mainline.
What happens if no one uses this as it having branches is a pain in the
neck.
Also fixing bugs in any code even if the bug is in the new one is
needed every where.
3. I will be making regular (probably weekly) merges from mainline
onto this branch. I will be testing these merges with a
powerpc-darwin native bootstrap. Anyone who commits anything to the
branch that can't be fully tested with a powerpc-darwin native
bootstrap should watch for the mail I send out saying the merge is
done, and then run a test on their own platform and send the results
to gcc-testresults.
Well if that is the case no one is going to use the branch as they
should be more focused
towards 3.4. Also are you going to merges where the source has changed
so much that you cannot do a merge within one week?
4. Anyone who commits to the branch is still responsible for
maintaining the patch on the branch: fixing regressions that it
causes, and sometimes updating or reintegrating it after merges. I
expect that for most patches, this will be much less work than
maintaining the patch on their own.
Well this just makes this branch to hard to use and no one is going to
use it.
5. I may back a patch out of the branch if it (a) causes bootstrap
failure or significant regressions on any platform and the author
doesn't appear to be able to fix it quickly, or (b) don't appear to
have followed Rule 1 or Rule 3.
What about compile time regressions also, are you going to test speed
of the compiler too?
I'll update the web pages tomorrow...
Thanks,
Andrew Pinski