Date: Mon, 17 Dec 2018 17:09:40 -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" <arch@freebsd.org> Subject: Re: A proposal for code removal prior to FreeBSD 13 Message-ID: <201812180109.wBI19eaK098408@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <CANCZdfqkh7eAbSn45cUW0LMtrz85rny_qX_xOEAp7CZ%2B8=3Y0g@mail.gmail.com>
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. I didn't say it was in use, I said "Age is not the correct metric". In use or not in use would be a correct metric. > 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. Change is probably a marginal metric, things that work well tend to just keep working, without fuss or change. timed works, works very well, and has no reason to be mucked with, so I would not expect any change to that code. Your drawing, IMHO, very bad conclusions from a poor metic. > 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. Your "not so much" is very subjective. ntpd may or maynot be actively maintained as pointed out by others. Change != used, unchanged != unused, please stop drawing conclusions that are marginal at best. > > 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 FFS, age is a totally incorrect metric, if you cant see that then maybe you should realized that much of our code is VERY old and has ages beyond timed, should we axe it? Age has 0 bearing on usefull, used, etc. > 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. I did not object to it going, you do not have to make a case for that, BUT I do object to the "reason" being "it is old", that is an incorrect reason. The reasons are more correctly: 1) It is only used by a small group of people (we should define what the size of that group is that makes things deprecatable.) The non existant data we have that leads us to think it is ok to remove timed may be wrong, and the 17.4 commiters procedure is designed to help catch that. 2) It has a reasonable replacement in ntpd 3) It has a small, but perhaps measurable maintance cost. (Though this well now be born by who ever if anyone bothers to maintain your git version) > > > > 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. It is not only a daemon, it has an interactive command component called timedc, and even then we *must* address this daemon issue for deprecating. To rely on a note in a man page is not a good plan. Daemons often can and do spit out startup messages, these are not "blasting random bits" and your hyperbola is not helping you make a good case. And if our skill levels are so low we can not add a startup message to timed and a message to timedc I hate to think of the state of the more complex code. > > A direct commit to the man page is all we need do here. We disagree, and stated procedure bears weight to my side. > > > 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. Sadly true. -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201812180109.wBI19eaK098408>