Re: ctm(1) deprecation in the FreeBSD base system?

On Tue, Oct 23, 2018 at 2:13 PM Rodney W. Grimes <
freebsd-rwg_at_pdx.rh.cn85.dnsmgr.net> wrote:

> > A cost(=time)/benefit look on moving ctm from src/ to ports/ :
> > - No tangible architecture benefit (its not like purging an old driver
> >   to makes kernel support simpler, or avoiding clashing libs etc)
> > - FreeBSD would shrink 0.028 % of the size of src/
> >       cd /pub/FreeBSD/branches/-current/src
> >       du -s -k .      # 1223922
> >       du -s -k `find . -type d -name \*ctm\*`
> >               196     ./usr.sbin/ctm
> >               74      ./usr.sbin/ctm/ctm
> >               12      ./usr.sbin/ctm/ctm_dequeue
> >               44      ./usr.sbin/ctm/ctm_rmail
> >               18      ./usr.sbin/ctm/ctm_smail
> >       dc 196 74 12 44 18 + + + + p 344
> >       dc 344000000000 1223922 / p 281063      # then move 9 points
> >       xcalc 344 / 1223922     # 0.0002810636
> >
> > Those who would do the work might want to ponder if 0.028 % is best use
> of
> > their time, or if more fun & benefit to work on some other part of
> FreeBSD ?
>
> At the most/least we should not go very far,
> the only thing that needs done soon is a gonein(13) commited
> to head and MFC'ed to stable/12 by thursday.
>
> All the other details should wait until a depreication policy
> revision is completed that includes how to deal with this.
>

There's no reason at all to wait. We can create the port. We can create the
github repo. We can move the history there. We won't  be removing it before
we have a chance to socialize the removal and give people a chance to cut
over. None of this requires a new policy. Everybody agrees we should do it.
We shouldn't let some perceived policy get in the way of just moving
forward.

Warner