Re: PROPOSAL: Policy for obsoleting targets

[Jan Vroonhof <jan dot vroonhof at ntlworld dot com>]

Zack Weinberg <zack@codesourcery.com> writes:

> 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.

Personally I think this far too aggressive. Just from what compilers I
come across during my work and hobbies the adoption rate is much lower than 
this schedule suggest.

In practice people went

2.9.3
egcs 1.1
gcc 2.95
possibly some 2.96/2.97 hack
gcc 3.2

Note the absence of any work with 3.0. Even the x86-Linux
distributions did that and that are probably the most important target
nowadays.

This is not entirely due to inertia. One should just accept that GCC
releases have been of varying quality. Especially from an Embedded
point of view gcc 3.2 is 2.95.3's real successor and not 3.0. I still
see more projects using 2.95.x then 3.x!

So I would like to see

1.  The above process modified to not use version numbers directly but
where the steps are releases that have obviously high adoptions rates.

2. The process in step 1 only marks them as "obsoletable". I don't see
why wholesale removal of target stuff is doing much good if the target
isn't really increasing general maintenance costs by requiring other
unnecessary features of the shared code. Surely there are lots of
targets that sit happily in their little corner with a few files and
can easily be kept up to date by grep, sed and friends. They might rot
a bit, maybe even stop building, but resurrecting them is a lot easier
than starting from scratch.

Just my 2p.

Jan