Date: Mon, 17 Dec 2018 13:38:15 +0800 From: "George Neville-Neil" <gnn@neville-neil.com> To: "Warner Losh" <imp@bsdimp.com> Cc: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.cn85.dnsmgr.net>, freebsd- <arch@freebsd.org> Subject: Re: A proposal for code removal prior to FreeBSD 13 Message-ID: <F0B272A1-1173-4DFC-9234-D4510AB5A293@neville-neil.com> In-Reply-To: <CANCZdfoAViZL1n_RN0F-2JPT6vggKAUGJ8ia%2BHhNkVZDSK5Mig@mail.gmail.com> References: <201812161659.wBGGxtSi092108@pdx.rh.CN85.dnsmgr.net> <F2189239-2EE7-4C22-9B6C-05FC453CCF8B@neville-neil.com> <CANCZdfoAViZL1n_RN0F-2JPT6vggKAUGJ8ia%2BHhNkVZDSK5Mig@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 17 Dec 2018, at 12:58, Warner Losh wrote: > On Sun, Dec 16, 2018, 9:49 PM George Neville-Neil > <gnn@neville-neil.com > wrote: > >> >> >> On 17 Dec 2018, at 0:59, Rodney W. Grimes wrote: >> >>>> On Sun, Dec 16, 2018 at 8:27 AM George Neville-Neil >>>> <gnn@neville-neil.com> >>>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F0B272A1-1173-4DFC-9234-D4510AB5A293>