From: Zack Weinberg <zack@codesourcery.com>
To: gcc@gcc.gnu.org
Subject: PROPOSAL: Policy for obsoleting targets
Date: Fri, 16 May 2003 16:08:00 -0000 [thread overview]
Message-ID: <874r3u27sm.fsf@egil.codesourcery.com> (raw)
The last two times we've been round the release cycle, obsolete target
lists have been assembled ad-hoc. I would post a list based on
intuitive impressions of what was no longer in use, then lots of
people would object to it and it would get pruned.
In the future I would like to do this more objectively. To that end I
am proposing:
At the time GCC version 3.n is released, all targets which have not
had a successful build and test report posted to gcc-testresults
for prereleases of minor version n, or releases n-1 and n-2, go on
the obsoletion list for version n+1. "Successful" means minimum
useful functionality: it's okay if only the C compiler works.
At any time during the development cycle of version n+1, anyone can
request the removal of a target from the obsoletion list, but they
must first post a successful build and test report to gcc-testresults.
Version n-2 is not acceptable anymore for this; it has to be n+1,
n, or n-1. If they needed to make changes to get the target to
work, they must also post the patch to gcc-patches, but it does not
have to get approved.
When 3.(n+1) is released, the targets still on the obsoletion list
are deleted from the mainline, and another sweep of gcc-testresults
is made to establish the list for 3.(n+2).
We're in an unusual situation right now, because the 3.2 release
series came off the 3.1 release branch. Therefore, for the 3.4
release I would count test results as far back as 3.1.0. 3.5,
however, will jump to 3.3 as the minimum.
Comments?
zw
next reply other threads:[~2003-05-16 16:08 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-16 16:08 Zack Weinberg [this message]
2003-05-16 16:31 ` Peter Barada
2003-05-16 17:42 ` Joel Sherrill
2003-05-16 18:30 ` DJ Delorie
2003-05-16 19:19 ` E. Weddington
2003-05-16 22:09 ` Joel Sherrill
2003-05-16 20:16 ` Janis Johnson
2003-05-16 22:10 ` Joel Sherrill
2003-05-16 22:51 ` Janis Johnson
2003-05-16 22:25 ` Paul Koning
2003-05-16 22:34 ` Joel Sherrill
2003-05-16 22:56 ` Alexandre Oliva
2003-05-17 0:02 ` Joe Buck
2003-05-18 6:16 ` Daniel Jacobowitz
2003-05-21 16:46 ` Jason Thorpe
2003-05-19 22:51 ` Michael S. Zick
2003-05-19 23:46 ` Dan Kegel
2003-05-20 0:08 ` Joe Buck
2003-05-22 2:31 ` Ben Elliston
2003-05-22 5:42 ` Dan Kegel
2003-05-22 12:22 ` Michael S. Zick
2003-05-19 2:28 ` Peter Barada
2003-05-19 13:20 ` Paul Koning
2003-05-16 16:34 ` Joe Buck
2003-05-16 17:04 ` Joseph S. Myers
2003-05-16 21:12 ` Joe Buck
2003-05-16 21:21 ` Joseph S. Myers
2003-05-21 16:35 ` Jason Thorpe
2003-05-21 22:02 ` Michael S. Zick
2003-05-16 19:29 ` Daniel Jacobowitz
2003-05-16 16:59 ` Jan Vroonhof
2003-05-18 14:22 ` Marc Espie
2003-05-19 18:28 ` Joe Buck
2003-05-21 17:12 ` Jason Thorpe
2003-05-21 17:49 ` Dan Kegel
2003-05-21 5:25 ` Zack Weinberg
2003-05-21 14:01 ` Michael S. Zick
2003-05-21 16:56 ` Dan Kegel
2003-05-19 18:49 Karim Yaghmour
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=874r3u27sm.fsf@egil.codesourcery.com \
--to=zack@codesourcery.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).