This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Target deprecation, round four
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Zack Weinberg <zack at codesourcery dot com>
- Cc: Nathanael Nerode <neroden at twcny dot rr dot com>, gcc at gcc dot gnu dot org, Richard dot Earnshaw at arm dot com
- Date: Tue, 04 Mar 2003 19:47:56 +0000
- Subject: Re: Target deprecation, round four
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> Nathanael Nerode <neroden at twcny dot rr dot 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.