From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31374 invoked by alias); 4 Mar 2003 19:48:13 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 31062 invoked from network); 4 Mar 2003 19:47:59 -0000 Received: from unknown (HELO fw-cam.cambridge.arm.com) (193.131.176.3) by 172.16.49.205 with SMTP; 4 Mar 2003 19:47:59 -0000 Received: by fw-cam.cambridge.arm.com; id TAA12006; Tue, 4 Mar 2003 19:47:58 GMT Received: from unknown(172.16.1.2) by fw-cam.cambridge.arm.com via smap (V5.5) id xma011995; Tue, 4 Mar 03 19:47:57 GMT Received: from pc960.cambridge.arm.com (pc960.cambridge.arm.com [10.1.205.4]) by cam-admin0.cambridge.arm.com (8.9.3/8.9.3) with ESMTP id TAA11029; Tue, 4 Mar 2003 19:47:54 GMT Received: from pc960.cambridge.arm.com (rearnsha@localhost) by pc960.cambridge.arm.com (8.11.6/8.9.3) with ESMTP id h24Jlu019041; Tue, 4 Mar 2003 19:47:56 GMT Message-Id: <200303041947.h24Jlu019041@pc960.cambridge.arm.com> X-Authentication-Warning: pc960.cambridge.arm.com: rearnsha owned process doing -bs To: Zack Weinberg cc: Nathanael Nerode , gcc@gcc.gnu.org, Richard.Earnshaw@arm.com Reply-To: Richard.Earnshaw@arm.com Organization: ARM Ltd. X-Telephone: +44 1223 400569 (direct+voicemail), +44 1223 400400 (switchbd) X-Fax: +44 1223 400410 X-Address: ARM Ltd., 110 Fulbourn Road, Cherry Hinton, Cambridge CB1 9NJ. Subject: Re: Target deprecation, round four In-reply-to: Your message of "Tue, 04 Mar 2003 11:35:18 PST." <87znobylft.fsf@egil.codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 Mar 2003 19:56:00 -0000 From: Richard Earnshaw X-SW-Source: 2003-03/txt/msg00252.txt.bz2 > Nathanael Nerode 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.