Date: Tue, 23 Oct 2018 14:21:47 -0600 From: Warner Losh <imp@bsdimp.com> To: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.cn85.dnsmgr.net> Cc: "Julian H. Stacey" <jhs@berklix.com>, Stefan Esser <se@freebsd.org>, "Montgomery-Smith, Stephen" <stephen@missouri.edu>, ctm-users@freebsd.org, Poul-Henning Kamp <phk@phk.freebsd.dk>, FreeBSD Current <freebsd-current@freebsd.org>, Ed Maste <emaste@freebsd.org> Subject: Re: ctm(1) deprecation in the FreeBSD base system? Message-ID: <CANCZdfp3n7GhuNtYjYU0w4nMH-39C34HtARivvgwsQCvvw_j1A@mail.gmail.com> In-Reply-To: <201810232013.w9NKDOQC023342@pdx.rh.CN85.dnsmgr.net> References: <201810231948.w9NJmYlC078288@fire.js.berklix.net> <201810232013.w9NKDOQC023342@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 23, 2018 at 2:13 PM Rodney W. Grimes < freebsd-rwg@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfp3n7GhuNtYjYU0w4nMH-39C34HtARivvgwsQCvvw_j1A>