From owner-freebsd-arch@freebsd.org Mon Dec 17 05:38:32 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 F0C9C132D20F for ; Mon, 17 Dec 2018 05:38:31 +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 32F3183CB3 for ; Mon, 17 Dec 2018 05:38:31 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: by mailman.ysv.freebsd.org (Postfix) id EB07A132D20E; Mon, 17 Dec 2018 05:38:30 +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 C8768132D20D for ; Mon, 17 Dec 2018 05:38:30 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (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 4438383CB2 for ; Mon, 17 Dec 2018 05:38:30 +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 relay5-d.mail.gandi.net (Postfix) with ESMTPSA id E92451C0005; Mon, 17 Dec 2018 05:38:20 +0000 (UTC) From: "George Neville-Neil" To: "Warner Losh" Cc: "Rodney W. Grimes" , freebsd- Subject: Re: A proposal for code removal prior to FreeBSD 13 Date: Mon, 17 Dec 2018 13:38:15 +0800 X-Mailer: MailMate (1.12.3r5579) Message-ID: In-Reply-To: References: <201812161659.wBGGxtSi092108@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Rspamd-Queue-Id: 4438383CB2 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 05:38:32 -0000 On 17 Dec 2018, at 12:58, Warner Losh wrote: > On Sun, Dec 16, 2018, 9:49 PM George Neville-Neil > wrote: > >> >> >> 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. >> > > If it's old, we should remove it. The one major release thing is nice > to > have in the steady state where you are caught up and retire things > just in > time. For the backlog we have, though, it will just get in the way. > But in > this case all we need to do is a direct commit to fix the man page in > 12 to > say it is gone in 13.... > Works for me. Thanks, George