Re: Target deprecation, round four

[Richard Earnshaw <rearnsha@arm.com>]

> Nathanael Nerode <neroden@twcny.rr.com> writes:
> 
> >Richard Earnshaw said:
> >>Surely a release containing the deprecation announcement should be
> >>made *before* we start removing the code...  As it stands you are
> >>proposing to delete the code from the mainline before most of the
> >>world is even aware of this.
> >
> > I deprecated vax-vms for 3.3 and promptly deleted it from mainline.
> > But this is because vax-vms (a) wasn't working, (b) hadn't been for
> > a long time, and (c) had over 10,000 lines of code devoted to it.  I
> > would agree that deletions of *working* targets be delayed until the
> > version with the deprecation has been released.  But deletions of
> > *non-working* targets, I think, can take place as soon as possible.
> 
> The trouble with this otherwise reasonable suggestion is, (a) I have
> no way to tell whether the majority of the targets on the list are
> still working; (b) we have no schedule for the 3.3 release.  Also, I
> am holding off on several performance patches that will involve
> touching lots of back-end code, because I don't want to waste time on
> targets that will be deleted in short order.  And it's not hard to
> pull a deleted target back from CVS if someone does turn up expressing
> interest.

Recovering the files is the easy part.  Knowing what has been changed in 
the interim is *significantly* harder.

> 
> But a wider announcement should happen.  How about I send the list to
> gcc-announce now, and wait another week before making any actual
> changes?

That at least would be an improvement.

In general I think I'd like to see a two release approach to this issue.  
In stage one a target is denoted "at risk", then at stage two it is 
deprecated on the branch and removed from the mainline.

That gives some time for a user to object and maybe find a maintainer.  Of 
course an objection with no maintainer is no objection (if they really 
care they'll sponsor a maintainer).

R.