A proposal for code removal prior to FreeBSD 13

[George Neville-Neil]

On 17 Dec 2018, at 12:58, Warner Losh wrote:

> On Sun, Dec 16, 2018, 9:49 PM George Neville-Neil 
> <gnn at 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 at 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