Re: PROPOSAL: Policy for obsoleting targets

[Marc Espie <espie at quatramaran dot ens dot fr>]

In article <874r3u27sm.fsf@egil.codesourcery.com> you write:
>
>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.

I'm completely against this.

For various reasons, me and other OpenBSD folks tend to lag behind gcc
releases quite a bit. For instance, having the compiler slowing down more
and more doesn't help.  Plus, we have other changes to test that very
often conflict with gcc issues.

We also have totally different release schedules and demands compared to
the gcc mainlines.

If you look closely at recent gcc releases, you might be surprised to
discover that almost *none* of them build cleanly on any OpenBSD systems.
However, this doesn't prevent us from having a functional port of gcc 3.2
(soon to be updated to gcc 3.3, now that the i386 switch to elf is complete),
and to have various running targets, including vax and hppa ports (that
currently use gcc 2.95.x, but gcc 3.2/3.3 has been somewhat tested since).

Simply put, we don't have the manpower, nor the energy, to follow test
results very carefully.  Writing patches that will be accepted by the SC
is often tedious, or downright impossible, because of conflicting policies.
It's also one small item in our busy agenda (I'm probably the chief OpenBSD
contributor to gcc of late, but by no means the only person working on it...
but gcc is definitely not the only thing I'm working on).

So, your `automated' policy will very likely put most OpenBSD platform on
the obsoletion list very quickly, even though those are quite alive and
kicking.