A proposal for code removal prior to FreeBSD 13

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

A proposal for code removal prior to FreeBSD 13

George Neville-Neil
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

Best,
George
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for code removal prior to FreeBSD 13

Diane Bruce
On Sun, Dec 16, 2018 at 05:34:05PM +0800, George Neville-Neil 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.

badblocks


--
- [hidden email] [hidden email] http://artemis.db.net/~db
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for code removal prior to FreeBSD 13

Warner Losh
In reply to this post by George Neville-Neil
On Sun, Dec 16, 2018 at 8:27 AM George Neville-Neil <[hidden email]>
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

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.

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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for code removal prior to FreeBSD 13

Rodney W. Grimes-4
In reply to this post by George Neville-Neil
> 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 am going to ask that all parties who want to "deprecate" code
first work with imp@ (Warner) to formalize the policy and procedure
for doing such that was promised by "release 12.0", then start on
this activity of deciding what can and can not go.

The ad hoc history of deprecation, especially without even
following our current model, is not helping the projects
image with users going "wtf, they took out foo???"

timed was removed outside of current procedure, and that should
be corrected ASAP, as one developer has already spoken up that
they are using it.

--
Rod Grimes                                                 [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for code removal prior to FreeBSD 13

Rodney W. Grimes-4
In reply to this post by Warner Losh
> On Sun, Dec 16, 2018 at 8:27 AM George Neville-Neil <[hidden email]>
> 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                                                 [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for code removal prior to FreeBSD 13

Bjoern A. Zeeb
In reply to this post by Rodney W. Grimes-4
On 16 Dec 2018, at 16:45, Rodney W. Grimes wrote:

I’ll ignore the “turning FreeBSD into change-management
procedures” part.

> timed was removed outside of current procedure, and that should
> be corrected ASAP,

No, it should not.  There is a stable branch, with shipping releases,
and support until at least June 30, 2020, possibly longer.

The questions are:
(a) will the request still be relevant then?
(b) do we still want to support it then?
(c) with pkgbase hopefully coming, will it still matter or is it better
off to be “3rd party” software?
(d) if it’s coming back, do we have a developer to care about it and
take care of the original reason that triggered the removal?


> as one developer has already spoken up that
> they are using it.

s/developer/user/  ; whether he is a developer as well is not the point.


/bz
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for code removal prior to FreeBSD 13

Rodney W. Grimes-4
> On 16 Dec 2018, at 16:45, Rodney W. Grimes wrote:
>
> I?ll ignore the ?turning FreeBSD into change-management
> procedures? part.
>
> > timed was removed outside of current procedure, and that should
> > be corrected ASAP,
>
> No, it should not.  There is a stable branch, with shipping releases,
> and support until at least June 30, 2020, possibly longer.

Your confusing "correcting the lack of deprecation notice" with
"reverting the removal".   As it stands now no deprecation notice
has been made per 17.4 of the handbook, that is bad and wrong.

The "corrections" needed are to stable/12 now, as direct commits,
since it wasnt done correctly in head:

1)  timed needs to spit out a message when it is invoked.
2)  timed(8) needs a deprecation notice added.
3)  The above should be flagged with relnotes: yes so
    that the 12.1 release notes can state that timed
    is going away in 13.

>
> The questions are:
> (a) will the request still be relevant then?
> (b) do we still want to support it then?
> (c) with pkgbase hopefully coming, will it still matter or is it better
> off to be ?3rd party? software?
> (d) if it?s coming back, do we have a developer to care about it and
> take care of the original reason that triggered the removal?

I would say it was removed without proper due process and
could ask for a revert, but at this time I am not, I am only
asking that the proper procedures be minimally adbered to.

>
> > as one developer has already spoken up that
> > they are using it.
>
> s/developer/user/  ; whether he is a developer as well is not the point.

It can be, as often developers are speaking for much more than
just a user, any of the develoeprs who support a large deployed
base have far more pull in my book than a loan user off in the
corner.

>
>
> /bz
>

--
Rod Grimes                                                 [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for code removal prior to FreeBSD 13

Poul-Henning Kamp
In reply to this post by Bjoern A. Zeeb
--------
In message <[hidden email]>, "Bjoern A
. Zeeb" writes:

>> timed was removed outside of current procedure, and that should
>> be corrected ASAP,
>
>No, it should not.  There is a stable branch, with shipping releases,
>and support until at least June 30, 2020, possibly longer.
>
>The questions are:
>[...]
(e) Has anybody ever run timed(8) on FreeBSD in the first place ?
(f) What was wrong with them ?

--
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[hidden email]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for code removal prior to FreeBSD 13

Warner Losh
On Sun, Dec 16, 2018, 1:55 PM Poul-Henning Kamp <[hidden email] wrote:

> --------
> In message <[hidden email]>,
> "Bjoern A
> . Zeeb" writes:
>
> >> timed was removed outside of current procedure, and that should
> >> be corrected ASAP,
> >
> >No, it should not.  There is a stable branch, with shipping releases,
> >and support until at least June 30, 2020, possibly longer.
>

This is a bit of a specious argument. While I agree we have time to correct
any lack, arguing stable branch lifetimes in prior discussions hasn't been
helpful to getting consensus. It's basically telling at someone rather than
offering a useful arguement.

In this case, we can trivially extract timed into a port and we'd be done.
Since the remedy is easy, and this is current, we have the luxury of time
needed for rational discourse.

>The questions are:
> >[...]
> (e) Has anybody ever run timed(8) on FreeBSD in the first place ?
> (f) What was wrong with them ?
>

They have. However, the numbers are low. This should not be in base. I'll
extract into a github repo (since that has been trivial in the past and
preserves history), but someone else will have to do the port.

Again, this borders on an ad hominem attack, which history has shown to be
not useful in reaching consensus.

Warner

>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for code removal prior to FreeBSD 13

freebsd-arch mailing list
In reply to this post by George Neville-Neil
Warner Losh imp at bsdimp.com wrote on
Sun Dec 16 16:32:35 UTC 2018 :

> 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
>
> . . .

Given discussions such as the one for -r341682 ( one message being
https://lists.freebsd.org/pipermail/svn-src-head/2018-December/120994.html ),
is a requirement for 64-bit atomics in order to support SMP
going to potentially eliminate platforms like the multi-processor
32-bit powerpc support (some old PowerMac models are examples)?
Should it be an example in WhatsGoing and a new ProjectPolicy?

(While I sometimes have access to a couple of such old PowerMacs and
experiment with FreeBSD on them, there is no reason FreeBSD should
consider that in any way. I'm just referencing an existing example
context.)


Separately:

Is there a fairly complete list of the Project Policies someplace?
Each possibly with the matching MD requirements implications (when
there are some)?


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for code removal prior to FreeBSD 13

Warner Losh
In reply to this post by Bjoern A. Zeeb
On Sun, Dec 16, 2018 at 1:45 PM Bjoern A. Zeeb <
[hidden email]> wrote:

> I’ll ignore the “turning FreeBSD into change-management
> procedures” part.
>

OK. I can't let that  slide by without comment.

What we've had for the past 10 years hasn't worked. Evidence: there's a lot
of junk in the tree. People have been afraid to deprecate because there's
too much friction.

Why's that? Because when people just got a bug up their butt and deleted
stuff, people complained (and rightly so). So we, as a project, have been
afraid to do anything.

I started breaking that log-jam about 6 or 9 months ago when I started the
ball rolling on getting rid of the really old arm bits. I learned a lot
from that. We learned a lot from the 10/100 stuff. I've learned from other
things big and small. That's why I wrote up the evaluation criteria: to try
to move to a data-driven process. Sadly, we have no telemetry in our
systems due to longly held notions that it's too invasive to do it, so we
didn't have it, even on an opt-in basis. We have very little usage data.
Absent, that we have to guess.

Every single set of guesses I made in my deprecation quest has had at least
one flaw in it. These flaws, however, have often been brought to light by
socializing the plan widely and letting people comment. In some cases, the
comments were addressed as "you don't understand, let me explain it" and in
other cases it was "I didn't understand, let me amend my proposal". In both
cases the proposal was better after the review.

But it's tricky... without the proper guidance, these discussions can go
off into the weeds quickly (so people have been reluctant to do them).  The
key, imho, is making them of small enough scope that all the issues that
arise can be dealt with, yet big enough to make it worth the other costs.
Honestly, it's gone much more smoothly than I feared when I started. The
more I've talked to people (not just developers, or the echo chamber of
people I talk to a lot), the more I find the weird places FreeBSD is in
use, the more data I gather, the more that I can understand what's going
on. And the more I've talked to people about what I'd like to do, the more
they are understanding when things don't go like they'd hoped because they
know they have had their say fairly considered.

So what I've started writing up isn't some mandatory straight jacket for
the project, but instead a set of best practices. This has worked well in
the past, that hasn't worked, etc. Everybody wants to do their job,
including deprecation, with a minimum of friction. But that doesn't
necessarily mean "just do it": that path just back loads the friction to
after the commit and leaves too much hard feelings. And we don't want to
talk it to death before the commit: nobody wants that either. And we've
been stuck, as a project, for a long time. I'm hoping to break the log jam
and find some guidelines that will help us, as a project talk to all the
stakeholders about the issues in a productive way that lets us move forward.

So this isn't at all about process for process sake, nor about creating a
new straight jacket to replace the old one of fear that we've worn for too
long. It's about using an open approach to hopefully solve this problem
once and for all so we can remove what we need to in a healthy and
functional way.

Sorry for the bit of a rant, but I've been working on this now for a while
and don't want to see us return to the bad-old-days.

Warner
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for code removal prior to FreeBSD 13

Warner Losh
In reply to this post by freebsd-arch mailing list
On Sun, Dec 16, 2018 at 5:34 PM Mark Millard via freebsd-arch <
[hidden email]> wrote:

> Given discussions such as the one for -r341682 ( one message being
> https://lists.freebsd.org/pipermail/svn-src-head/2018-December/120994.html
> ),
> is a requirement for 64-bit atomics in order to support SMP
> going to potentially eliminate platforms like the multi-processor
> 32-bit powerpc support (some old PowerMac models are examples)?
> Should it be an example in WhatsGoing and a new ProjectPolicy?
>

Maybe. That's not a terrible idea, but we have a lot of things that are
currently just unwritten rules, and I'm not keen to write them all down. I
don't have the time. I do have the time to toss together something for
mips, and see what the implications are, so I'm limiting myself to that.


> Is there a fairly complete list of the Project Policies someplace?
> Each possibly with the matching MD requirements implications (when
> there are some)?
>

There should be a list, but there isn't. Some are well documented, others
no doubt live just in a few people's heads. I'd love to see it, but that
windmill is too large for me to tilt at. It's hard to reconstruct a list we
should have maintained incrementally over the last 25 years.

It might also not be bad to manage longer-term transitions via some kind of
roadmap that looks out a release or three. But before we can get to that
point, we need to clean up the accumulated technical debt wrt obsolescence
in the code base today.

Warner
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

RE: A proposal for code removal prior to FreeBSD 13

Cy Schubert-4
In reply to this post by George Neville-Neil
Picking a random email to reply to, the process should also include determination whether to migrate the software /feature to ports is required.

---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.
Also, this old phone only supports top post. Apologies.

Cy Schubert
<[hidden email]> or <[hidden email]>
The need of the many outweighs the greed of the few.
---

-----Original Message-----
From: Mark Millard via freebsd-arch
Sent: 16/12/2018 16:34
To: [hidden email]
Subject: Re: A proposal for code removal prior to FreeBSD 13

Warner Losh imp at bsdimp.com wrote on
Sun Dec 16 16:32:35 UTC 2018 :

> 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
>
> . . .

Given discussions such as the one for -r341682 ( one message being
https://lists.freebsd.org/pipermail/svn-src-head/2018-December/120994.html ),
is a requirement for 64-bit atomics in order to support SMP
going to potentially eliminate platforms like the multi-processor
32-bit powerpc support (some old PowerMac models are examples)?
Should it be an example in WhatsGoing and a new ProjectPolicy?

(While I sometimes have access to a couple of such old PowerMacs and
experiment with FreeBSD on them, there is no reason FreeBSD should
consider that in any way. I'm just referencing an existing example
context.)


Separately:

Is there a fairly complete list of the Project Policies someplace?
Each possibly with the matching MD requirements implications (when
there are some)?


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for code removal prior to FreeBSD 13

George Neville-Neil
In reply to this post by Rodney W. Grimes-4


On 17 Dec 2018, at 0:59, Rodney W. Grimes wrote:

>> On Sun, Dec 16, 2018 at 8:27 AM George Neville-Neil
>> <[hidden email]>
>> 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for code removal prior to FreeBSD 13

Warner Losh
On Sun, Dec 16, 2018, 9:49 PM George Neville-Neil <[hidden email]
wrote:

>
>
> On 17 Dec 2018, at 0:59, Rodney W. Grimes wrote:
>
> >> On Sun, Dec 16, 2018 at 8:27 AM George Neville-Neil
> >> <[hidden email]>
> >> 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....

Warner

>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: 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
> <[hidden email]
> wrote:
>
>>
>>
>> On 17 Dec 2018, at 0:59, Rodney W. Grimes wrote:
>>
>>>> On Sun, Dec 16, 2018 at 8:27 AM George Neville-Neil
>>>> <[hidden email]>
>>>> 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

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for code removal prior to FreeBSD 13

Rodney W. Grimes-4
In reply to this post by Warner Losh
> On Sun, Dec 16, 2018, 9:49 PM George Neville-Neil <[hidden email]
> wrote:
>
> >
> >
> > On 17 Dec 2018, at 0:59, Rodney W. Grimes wrote:
> >
> > >> On Sun, Dec 16, 2018 at 8:27 AM George Neville-Neil
> > >> <[hidden email]>
> > >> 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.

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.

> >
>
> 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.

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.

--
Rod Grimes                                                 [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

RE: A proposal for code removal prior to FreeBSD 13

Cy Schubert-4
In reply to this post by George Neville-Neil
A couple of points:

Yes, I don't recall amd(8) or timed(8) ever having CVEs against them -- we cannot predict the future though. Ntp is another matter. Hardly a year goes by when we receive yet another update due to a CVE, sometimes more. (Sadly ntp is maintained only for security patches, all other development has ceased.)

---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.
Also, this old phone only supports top post. Apologies.

Cy Schubert
<[hidden email]> or <[hidden email]>
The need of the many outweighs the greed of the few.
---

-----Original Message-----
From: Rodney W. Grimes
Sent: 16/12/2018 23:23
To: Warner Losh
Cc: [hidden email]; George Neville-Neil
Subject: Re: A proposal for code removal prior to FreeBSD 13

> On Sun, Dec 16, 2018, 9:49 PM George Neville-Neil <[hidden email]
> wrote:
>
> >
> >
> > On 17 Dec 2018, at 0:59, Rodney W. Grimes wrote:
> >
> > >> On Sun, Dec 16, 2018 at 8:27 AM George Neville-Neil
> > >> <[hidden email]>
> > >> 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.

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.

> >
>
> 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.

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.

--
Rod Grimes                                                 [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for code removal prior to FreeBSD 13

Julian H. Stacey-3
In reply to this post by Rodney W. Grimes-4
"Rodney W. Grimes" 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 am going to ask that all parties who want to "deprecate" code
> first work with imp@ (Warner) to formalize the policy and procedure
> for doing such that was promised by "release 12.0", then start on
> this activity of deciding what can and can not go.

Good idea.


> The ad hoc history of deprecation, especially without even
> following our current model, is not helping the projects
> image with users going "wtf, they took out foo???"

Yes.


> timed was removed outside of current procedure, and that should
> be corrected ASAP, as one developer has already spoken up that
> they are using it.

Yes


Warner wrote:
> In this case, we can trivially extract timed into a port and we'd be done.

If the demolisher won't write a port please revert it to src/


I followed https://wiki.freebsd.org/WhatsGoing/FreeBSD13 Timed
links, i didnt find why removed or what should replace it to continue
support of timed protocol.  There'll be lots of old heregenous nets
in the world, some behind firewalls, still using timed.


"Poul-Henning Kamp" <[hidden email]> wrote:
> (e) Has anybody ever run timed(8) on FreeBSD in the first place ?
> (f) What was wrong with them ?

My net first used timed for a Symmetric 375 "Half a Vax" designed by Bill J.
UCB 4.2, with src/ , sys/ failed  http://www.berklix.com/~jhs/symmetric/
timed is still useful behind a wall.

Cheers,
Julian
--
Julian Stacey, Computer Consultant Sys.Eng. BSD Linux Unix, Munich Aachen Kent
 First referendum stole 700,000 votes from Brits in EU;  3,700,000 globaly.
 Lies criminal funded; jobs pound & markets down. 1.9M new voters 1.3M dead.
 Email your MP: "New referendum fast!"  http://berklix.org/brexit/#mp
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for code removal prior to FreeBSD 13

Kurt Lidl-2
In reply to this post by George Neville-Neil
I would like to request that rarpd remain in the system, or if it must
go, a port needs be made of the code.

I have old hardware, that gets boots periodically to check exact system
behaviour, that requires rarpd to netboot.  This hardware has been at
the basis of some surprising "prior art" type discoveries.  So it's
essential to me that FreeBSD still be able to act as its netbooting
server and NFS server.

Thanks.

-Kurt

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
12