Date: Sun, 16 Dec 2018 08:59:55 -0800 (PST) From: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> To: Warner Losh <imp@bsdimp.com> Cc: George Neville-Neil <gnn@neville-neil.com>, freebsd- <arch@freebsd.org> Subject: Re: A proposal for code removal prior to FreeBSD 13 Message-ID: <201812161659.wBGGxtSi092108@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <CANCZdfoosE0PhatmKAr9h6qTDSkBwqKo5F32BuapgbHyrrb6Ow@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. 4. The option, utility, or interface is removed and no longer documented. It is now obsolete. 5. Note its removal in the release notes. (Again, made this non-optional, removals must have release notes entries) > > I also hope that there's sufficient public discussion of the proposed > removals individually. While you can't always get 100% agreement, you still > need to have the discussions to make sure that you aren't blind to data > that would stay your hand on deletion (or maybe even hasten it). > > Warner -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201812161659.wBGGxtSi092108>