Date: Mon, 17 Dec 2018 14:15:00 -0700 From: Warner Losh <imp@bsdimp.com> To: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.cn85.dnsmgr.net> Cc: George Neville-Neil <gnn@neville-neil.com>, "freebsd-arch@freebsd.org" <arch@freebsd.org> Subject: Re: A proposal for code removal prior to FreeBSD 13 Message-ID: <CANCZdfqkh7eAbSn45cUW0LMtrz85rny_qX_xOEAp7CZ%2B8=3Y0g@mail.gmail.com> In-Reply-To: <201812170722.wBH7MRhO094818@pdx.rh.CN85.dnsmgr.net> References: <CANCZdfoAViZL1n_RN0F-2JPT6vggKAUGJ8ia%2BHhNkVZDSK5Mig@mail.gmail.com> <201812170722.wBH7MRhO094818@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 17, 2018 at 12:22 AM Rodney W. Grimes < freebsd-rwg@pdx.rh.cn85.dnsmgr.net> 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. > > Not giving the users proper and adaquate notification is asking > for problems as well. > > In the case of amd(8) at least the man page has had a obsolete > notice in it with a pointer to autofs for some time (my 11.1 > systems have such notice, not sure how far back that goes.) > > And again, age is not the correct metric, BSD is near 40 years > old, I think the word you want is obsolete, which is more correct. > Also timed appears to be in use, so what might be dead to you > is useful to someone else. > You can't say it's in use, other than one person saying they have it up and running. That's not data, but an anecdote. We have no data to show one way or another. However, given how little it's changed in the last 25 years since it was imported to the tree, it's not unreasonable to conclude that it's not in active use. Couple with that the significant technical issues with the method of timekeeping its trying to do, and it's easy to see why people wouldn't want to use it. > I would also argue that the attack surface of timed is much > smaller than the attack surface of ntpd, shall we remove ntpd > to reduce our attack surface? I can not recall any cve against > timed, I can recall many against ntpd. > ntpd is useful. timed, not so much. ntpd is widely deployed, timed not so much. ntpd is actively maintained, timed hasn't changed in 30 years in any meaningful way. Etc. On all these factors, timed should go. The rest doesn't matter. So few people use timed that it's not worth having in the tree. It's age is but one factor as is lack of meaningful maintenance, but it too militates against. In fact, all the commits after its import have been make-work for the most part. This is a poster child for why software in the tree needlessly creates friction: At least 5 different people had to spend time on this bit of code making sure it was up to whatever tree-wide thing they were doing. Individually, this isn't so bad, but with enough of these it becomes a real problem. So it's not just any one of these factors, before you try to argue one point I might have overstated. It's that the cost of having it in the tree, all things considered, outweighs the benefit it gives to the project when viewed as a whole over all these factors. There's a general consensus that's true, with a tiny number of people holding a contrary view. That qualifies as "rough consensus" in my book. that was the old standard before we filibustered things to death with the mistaken notion that even on decenter is enough to keep something around. It's time to come up with some clear guidelines that embody the "rough consensus" standard of old, while recognizing that with a larger audience of stakeholders we'll see more of the 'long tail' than we ever did when the group was smaller (the law of large numbers tells us to expect this). We've not made that transition, and we need to do so. We have to find some useful way to talk about retirement of features, architectures, platforms, etc because we don't have enough manpower to maintain everything that ever entered the tree forever. We have to make sure that the burden things place on other developers are, on the whole, out weighted by the benefit to the project. Since both of these factors lack hard data to back-up assertions, we must instead substitute our collective wisdom. There will be differences of opinion as to the cost and worth of things, but the average of those opinions generally have been shown to be good so long as the sample size is large and diverse enough. > > 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.... > > Yes, we can short circuit the process, but we should not just skip > the process. Need to fix both the man page and the binary to output > a message when it is invoked, and that needs to be commited to both > stable/11 and stable/12. > It's a daemon. We should not have it blast random bits. There's no need for it and the bits would get lost anyway. Also, changes to the could break things in unanticipated ways if they can't be meaningfully tested. A direct commit to the man page is all we need do here. > The prefered method would of been to do the notification stuff in > head, then merge that back to stable/11 and /12, then do the remove > in head. > True, but that wasn't done here. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqkh7eAbSn45cUW0LMtrz85rny_qX_xOEAp7CZ%2B8=3Y0g>