Date: Mon, 17 Dec 2018 12:49:17 +0800 From: "George Neville-Neil" <gnn@neville-neil.com> To: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> Cc: "Warner Losh" <imp@bsdimp.com>, freebsd- <arch@freebsd.org> Subject: Re: A proposal for code removal prior to FreeBSD 13 Message-ID: <F2189239-2EE7-4C22-9B6C-05FC453CCF8B@neville-neil.com> In-Reply-To: <201812161659.wBGGxtSi092108@pdx.rh.CN85.dnsmgr.net> References: <201812161659.wBGGxtSi092108@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Best, George
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F2189239-2EE7-4C22-9B6C-05FC453CCF8B>