From owner-freebsd-arch@freebsd.org Mon Dec 17 04:49:54 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1F9D13258B7 for ; Mon, 17 Dec 2018 04:49:54 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 20CD08235E for ; Mon, 17 Dec 2018 04:49:54 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: by mailman.ysv.freebsd.org (Postfix) id D8A2013258B6; Mon, 17 Dec 2018 04:49:53 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B604F13258B5 for ; Mon, 17 Dec 2018 04:49:53 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 348C98235D for ; Mon, 17 Dec 2018 04:49:53 +0000 (UTC) (envelope-from gnn@neville-neil.com) X-Originating-IP: 118.169.45.207 Received: from [10.37.129.2] (118-169-45-207.dynamic-ip.hinet.net [118.169.45.207]) (Authenticated sender: gnn@neville-neil.com) by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id 9E4A720006; Mon, 17 Dec 2018 04:49:21 +0000 (UTC) From: "George Neville-Neil" To: "Rodney W. Grimes" Cc: "Warner Losh" , freebsd- Subject: Re: A proposal for code removal prior to FreeBSD 13 Date: Mon, 17 Dec 2018 12:49:17 +0800 X-Mailer: MailMate (1.12.3r5579) Message-ID: In-Reply-To: <201812161659.wBGGxtSi092108@pdx.rh.CN85.dnsmgr.net> References: <201812161659.wBGGxtSi092108@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Rspamd-Queue-Id: 348C98235D X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-7.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-1.00)[-0.997,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2018 04:49:55 -0000 On 17 Dec 2018, at 0:59, Rodney W. Grimes wrote: >> On Sun, Dec 16, 2018 at 8:27 AM George Neville-Neil >> >> wrote: >> >>> Howdy, >>> >>> A few of us are working on a list of programs and other code that >>> we'd >>> like to remove before FreeBSD 13. If others with to collaborate on >>> this >>> removal, or discuss it, please do so here. >>> >>> The list is being maintained on the project WIki: >>> https://wiki.freebsd.org/WhatsGoing/FreeBSD13 >> >> >> I'm in the process of writing some of the criteria I've been using to >> drive >> discussions. I've promised a formal policy for a long time, but >> that's >> turning out to be harder than I thought to write and have just >> documented >> the criteria I look at to do the cost / benefit analysis for things. >> It's >> skewed a bit towards old drivers and old architectures (or platforms >> within >> those architectures), but it's likely a useful snowman to work >> towards >> something better. https://wiki.freebsd.org/ObsoleteCriteria > > THANK YOU!!! > >> This doesn't get into the process at all of who to have the >> conversation >> with, what steps you go through to ensure that there's a transition >> plan >> for current users (if there's enough to warrant it), etc. It's just a >> set >> of things I've found useful to think about and that I think the >> project >> should adopt (with refinement) as a standard template to use when >> making >> these calls. > > Can you also draft a short proposal on the "process" of deprecation? > Based I guess on our current model, with the addition of some of the > macros and other stuff you and Brooks worked on, the gone_in stuff > is what I am thinking. How to do the head commit with the deprecation > notices, merge that back if applicable, then do the remove when > appropriate. Basically a more complete flushed out version of: > https://www.freebsd.org/doc/en/articles/committers-guide/article.html#rules > @ 17.4. We should also IMHO do some work smithing and rearrangement > to > make this read much more as steps, some of the steps as listed have > substeps that appear to be overlooked often. > > Something like this: > 17.4. Deprecating Features > > When it is necessary to remove functionality from software in > the base system, follow these guidelines whenever possible: > > 1. Use of the deprecated feature generates a warning. > 2. Mention is made in the manual page and the release > notes that the option, utility, or interface is deprecated. > (I removed the word possible here, we should always > mention deprecation of features in the release notes) > 3. The option, utility, or interface is preserved until > the next major (point zero) release. Given the age of some of the things in our tree, of which timed was a classic example, I hardly think that this rule will work in our favor. Removing old code reduces our attack surface, and keeping something that's been dead for years, for another 2 years, seems problematic at the very least. Some of the software now on the proposed removal list should have been gone by 11 or 12. Best, George