From: Geoffrey Keating <geoffk@apple.com>
To: "'gcc@gcc.gnu.org'" <gcc@gcc.gnu.org>
Cc: Caroline Tice <ctice@apple.com>
Subject: gcc 3.5 integration branch proposal
Date: Sat, 10 Jan 2004 00:11:00 -0000 [thread overview]
Message-ID: <90200277-4301-11D8-BDBD-000A95B1F520@apple.com> (raw)
It looks like it's going to be quite some time before 3.4 branches and
the mainline is opened up for general work. There are also a number of
projects which are completed, or partially completed, and are waiting
in branches and in people's private trees for 3.5 to open up to be
committed. This has a number of bad effects:
1. People are having to maintain their own patches and/or branches and
keep them up-to-date.
2. These patches and branches are not getting as much testing as they
might, because the available testing effort is being spread over many
places.
3. These patches and branches are not being tested with each other.
I am concerned that this will cause great instability in the initial
development of GCC 3.5, and will lead to delays in the release of GCC
3.5. I therefore propose to create a gcc-3.5-integration-branch. It
will be similar in some ways to the 'basic-improvement' branch in the
GCC 3.4 timeframe, but will have some significant differences. The
proposed 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.
2. The intention is that immediately after GCC 3.4 branches, this
branch will be merged back to mainline.
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.
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.
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.
Any objections to this proposal? If not, I'll create the branch in the
next few days.
next reply other threads:[~2004-01-10 0:11 UTC|newest]
Thread overview: 185+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-10 0:11 Geoffrey Keating [this message]
2004-01-10 0:25 ` Phil Edwards
2004-01-10 0:47 ` Geoffrey Keating
2004-01-10 15:41 ` Phil Edwards
2004-01-12 18:47 ` Geoffrey Keating
2004-01-12 19:22 ` Mark Mitchell
2004-01-12 23:42 ` Geoff Keating
2004-01-12 23:48 ` Zack Weinberg
2004-01-12 23:49 ` Mark Mitchell
2004-01-13 0:06 ` Daniel Jacobowitz
2004-01-13 0:16 ` Daniel Jacobowitz
2004-01-13 0:22 ` Steven Bosscher
2004-01-13 19:48 ` Gerald Pfeifer
2004-01-13 0:28 ` Joe Buck
2004-01-13 0:46 ` Daniel Jacobowitz
2004-01-13 1:13 ` Jan Hubicka
2004-01-13 0:11 ` Ziemowit Laski
2004-01-13 0:15 ` Steven Bosscher
2004-01-13 0:23 ` Ziemowit Laski
2004-01-13 0:37 ` Steven Bosscher
2004-01-13 0:45 ` Jan Hubicka
2004-01-13 0:55 ` Ziemowit Laski
2004-01-13 0:54 ` Ziemowit Laski
2004-01-13 1:01 ` Mark Mitchell
2004-01-13 1:16 ` Ziemowit Laski
2004-01-13 1:26 ` Mark Mitchell
2004-01-13 1:33 ` Gabriel Dos Reis
2004-01-13 1:19 ` Gabriel Dos Reis
2004-01-13 0:47 ` Daniel Jacobowitz
2004-01-13 0:59 ` Altivec (Re: gcc 3.5 integration branch proposal) Matt Austern
2004-01-13 0:16 ` gcc 3.5 integration branch proposal Mark Mitchell
2004-01-13 0:54 ` Gabriel Dos Reis
2004-01-13 21:31 ` Geoff Keating
2004-01-13 22:41 ` David Edelsohn
2004-01-13 23:13 ` Daniel Berlin
2004-01-13 23:24 ` Paul Koning
2004-01-14 0:01 ` Geoff Keating
2004-01-14 0:26 ` Gabriel Dos Reis
2004-01-14 8:35 ` Laurent GUERBY
2004-01-14 14:58 ` Paul Koning
2004-01-13 23:29 ` Mike Stump
2004-01-14 0:47 ` Andrew Pinski
2004-01-14 1:05 ` Andrew Pinski
2004-01-14 1:36 ` Joe Buck
2004-01-14 19:47 ` Mike Stump
2004-01-13 23:51 ` Eric Christopher
2004-01-13 23:53 ` Daniel Berlin
2004-01-14 6:13 ` Mark Mitchell
2004-01-14 8:39 ` Laurent GUERBY
2004-01-14 8:48 ` Steven Bosscher
2004-01-14 20:59 ` Laurent GUERBY
2004-01-14 21:02 ` Andrew Haley
2004-01-19 1:31 ` Marc Espie
2004-01-19 1:51 ` Gabriel Dos Reis
2004-01-19 10:40 ` Nick Burrett
2004-01-19 13:55 ` Robert Dewar
2004-01-19 15:49 ` Gabriel Dos Reis
2004-01-19 16:09 ` Scott Robert Ladd
2004-01-19 16:24 ` Marc Espie
2004-01-19 17:07 ` Scott Robert Ladd
2004-01-19 17:54 ` Robert Dewar
2004-01-19 18:03 ` Gabriel Dos Reis
2004-01-19 17:41 ` Robert Dewar
2004-01-19 18:08 ` Scott Robert Ladd
2004-01-19 18:09 ` Scott Robert Ladd
2004-01-19 18:34 ` Marc Espie
2004-01-19 19:06 ` Robert Dewar
2004-01-19 20:22 ` Eric Botcazou
2004-01-19 20:38 ` Robert Dewar
2004-01-19 21:09 ` Eric Botcazou
2004-01-19 21:18 ` Eric Christopher
2004-01-19 21:46 ` Eric Botcazou
2004-01-19 22:09 ` Laurent GUERBY
2004-01-19 22:29 ` Marc Espie
2004-01-19 23:04 ` Laurent GUERBY
2004-01-20 3:45 ` Robert Dewar
2004-01-20 7:46 ` Marc Espie
2004-01-20 23:22 ` Gerald Pfeifer
2004-01-20 23:28 ` Zack Winkles
2004-01-19 23:53 ` Mark Hahn
2004-01-20 0:17 ` Gabriel Dos Reis
2004-01-20 14:27 ` Scott Robert Ladd
2004-01-22 14:50 ` Geoffrey Furnish
2004-01-20 6:27 ` gcc compilation speed Matt Austern
2004-01-20 7:23 ` Steven Bosscher
2004-01-20 7:40 ` Karel Gardas
2004-01-20 8:25 ` gcc 3.5 integration branch proposal Karel Gardas
2004-01-20 12:07 ` Laurent GUERBY
2004-01-20 14:41 ` Karel Gardas
2004-01-20 14:52 ` Daniel Berlin
2004-01-20 14:55 ` Karel Gardas
2004-01-20 15:16 ` Daniel Jacobowitz
2004-01-20 15:21 ` Karel Gardas
2004-01-20 16:16 ` Comparison of compilation speed of GCC 3.4.0 040114, ICC 8.0 and COMO 4.3.3 on MICO ORB core sources (C++) Karel Gardas
2004-01-20 15:08 ` gcc 3.5 integration branch proposal Paul Koning
2004-01-19 21:20 ` Robert Dewar
2004-01-20 2:05 ` Mike Stump
2004-01-20 14:25 ` Scott Robert Ladd
2004-01-19 21:34 ` Geoff Keating
2004-01-19 22:03 ` Eric Botcazou
2004-01-19 22:22 ` Geoff Keating
2004-01-19 22:38 ` Eric Botcazou
2004-01-20 3:53 ` Robert Dewar
2004-01-20 4:52 ` Eric Botcazou
2004-01-20 2:44 ` Alexandre Oliva
2004-01-20 3:04 ` Mike Stump
2004-01-20 19:03 ` Alexandre Oliva
2004-01-20 20:41 ` Mike Stump
2004-01-20 22:06 ` Alexandre Oliva
2004-01-20 22:59 ` Mike Stump
2004-01-20 18:52 ` Geoffrey Keating
2004-01-20 22:12 ` Alexandre Oliva
2004-01-20 22:30 ` Geoffrey Keating
2004-01-21 0:02 ` Alexandre Oliva
2004-01-21 12:12 ` Richard Earnshaw
2004-01-22 6:37 ` Segher Boessenkool
2004-01-22 10:38 ` Richard Earnshaw
2004-01-22 6:27 ` Segher Boessenkool
2004-01-26 18:55 ` compile speed [was: gcc 3.5 integration branch proposal] Per Bothner
2004-01-26 19:34 ` Alexandre Oliva
2004-01-20 0:01 ` GCC's hardware requirements - Where is the freedom? [was: " Matthias Benkmann
2004-01-20 3:13 ` Andrew Pinski
2004-01-20 3:17 ` Andrew Pinski
2004-01-20 9:23 ` Bernd Jendrissek
2004-01-20 21:38 ` Mike Stump
2004-01-20 22:50 ` Toon Moene
2004-01-20 8:12 ` Laurent GUERBY
2004-01-20 9:09 ` Eric Botcazou
2004-01-19 17:27 ` gcc 3.5 integration branch proposal Robert Dewar
2004-01-19 16:26 ` Per Bothner
2004-01-20 2:14 ` Mike Stump
2004-01-20 3:49 ` Zack Weinberg
2004-01-20 10:08 ` Jan Hubicka
2004-01-20 15:13 ` Daniel Jacobowitz
2004-01-20 18:04 ` Zack Weinberg
2004-01-20 18:48 ` Geoffrey Keating
2004-01-20 19:01 ` Zack Weinberg
2004-01-20 22:04 ` Geoff Keating
2004-01-21 2:23 ` Zack Weinberg
2004-01-22 6:27 ` Segher Boessenkool
2004-01-19 20:51 ` Dale Johannesen
2004-01-19 23:01 ` Gabriel Dos Reis
2004-01-19 3:42 ` Marc Espie
2004-01-19 3:47 ` Robert McNulty Junior
2004-01-19 3:49 ` David Edelsohn
2004-01-19 13:28 ` Marc Espie
2004-01-19 13:35 ` Diego Novillo
2004-01-19 13:35 ` Jan Hubicka
2004-01-19 19:10 ` Marc Espie
2004-01-19 19:15 ` Marc Espie
2004-01-19 20:49 ` Diego Novillo
2004-01-19 19:39 ` Jan Hubicka
2004-01-19 13:39 ` Jan Hubicka
2004-01-19 17:58 ` Jan Hubicka
2004-01-19 3:59 ` Zack Weinberg
2004-01-19 8:19 ` Steven Bosscher
2004-01-19 11:29 ` Jan Hubicka
2004-01-19 13:18 ` Jan Hubicka
2004-01-19 14:13 ` Robert Dewar
2004-01-19 14:18 ` Jan Hubicka
2004-01-19 14:48 ` Vladimir Makarov
2004-01-19 17:04 ` Jan Hubicka
2004-01-20 2:46 ` Alexandre Oliva
2004-01-19 4:37 ` Giovanni Bajo
2004-01-19 4:46 ` Gabriel Dos Reis
2004-01-19 7:04 ` Eric Botcazou
2004-01-19 7:10 ` Andreas Jaeger
2004-01-19 8:12 ` Steven Bosscher
2004-01-19 8:38 ` Gabriel Dos Reis
2004-01-19 8:45 ` Steven Bosscher
2004-01-19 9:35 ` Gabriel Dos Reis
2004-01-12 22:40 ` Mike Stump
2004-01-13 23:31 Michael Elizabeth Chastain
2004-01-19 16:24 Paul Koning
2004-01-19 17:46 ` Robert Dewar
2004-01-19 17:51 ` Gabriel Dos Reis
2004-01-19 18:12 ` Scott Robert Ladd
2004-01-19 18:20 ` Gabriel Dos Reis
2004-01-19 18:29 ` Giovanni Bajo
2004-01-19 18:22 ` Robert Dewar
2004-01-19 18:30 ` Paul Koning
2004-01-20 10:46 ` Russ Allbery
2004-01-20 3:00 D. Starner
2004-01-20 3:14 ` Andrew Pinski
2004-01-20 5:19 D. Starner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=90200277-4301-11D8-BDBD-000A95B1F520@apple.com \
--to=geoffk@apple.com \
--cc=ctice@apple.com \
--cc=gcc@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).