PROPOSAL: Policy for obsoleting targets

[Zack Weinberg <zack at codesourcery dot com>]

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