Date: Fri, 24 Nov 2023 15:00:00 -0700 From: Warner Losh <imp@bsdimp.com> To: Brooks Davis <brooks@freebsd.org> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: Time to remove sccs tags Message-ID: <CANCZdfoFBbW4AYJe-zLB5gSORWsq_MrvWRh0Gj6-HmNd9OP_Ww@mail.gmail.com> In-Reply-To: <ZVzw7UknA_qq2FK6@spindle.one-eyed-alien.net> References: <CANCZdfo5Pj=AWmd5ftZ6OmMXBrkFAbZnYZt8EC8EqRqoi9csHw@mail.gmail.com> <ZVzw7UknA_qq2FK6@spindle.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000887243060aed1393 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable OK. I've pushed a branch to github for commenting. https://github.com/bsdimp/freebsd/tree/sccs I've broken it up in a couple of ways. First, one commit per directory for the SCCS removal. I did this for Brooks to see if that's what he wanted. Then I have one final sccs removal commit for the whole tree for what I had to do by hand. I can recreate the first 12 by script (plus two fixups) Then I have a 'remove all the copyright strings prefixed by @(#) that were ifdef'd out' commit which also did minor touchup of files. I did this mostly by hand since there was just a smidge too much variation. And then a whole lot of automatic removal of sys/defs.h that had filtered through the prior removal of FreeBSD, sccs, and copyrights. This is 100% scripted with me spot checking the diffs for sanity. I'm looking for feedback on the changes, of course, but also on whether I should fold back the last two commits into the first dozen or so done by directory (total of about 35 commits)... Or should I break them up by directory as well. I'm leaning towards folding back all but the manual changes and doing it all per directory (so 12 commits plus the one manial). Once I get initial feedback, I'll either go with my lean (if there's none) or adjust course as needed. I plan to MFC these to stable/14 on a best effort basis (eg, if it doesn't apply, I'll skip that chunk, but otherwise git cherry-pick -x). I have no plans ot merge this back to 13. diffstat says for this whole series: 7893 files changed, 125 insertions(+), 18138 deletions(-) I'm plowing through a tinderbox build right now, but amd64 builds both world and kernel. Since changes like this tend to go stale quickly, I wanted to do these two steps in parallel (any breakage is trivially different, usually adding back a sys/cdefs.h include). Finally, I have a number of sys/cdefs.h changes queued as well. These are cleaning up that file. I plan on batching it with this set of changes so that there's only one 'rebuild everything' event for most people... That is, unless the sccs series turns into a long discussion... Comments? Warner On Tue, Nov 21, 2023 at 11:03=E2=80=AFAM Brooks Davis <brooks@freebsd.org> = wrote: > On Tue, Nov 21, 2023 at 09:12:48AM -0700, Warner Losh wrote: > > It's been 30 odd years since the last csrg release. They are no more. > > > > At this point I think we can safely remove the few sccs tags that remai= n > in > > the tree. The data will be there in git if we ever need it. > > > > Comments? > > Yes please. The history is there in there repo(s) and there's so much > blind copying where the context is entirely lost. > > From my perspective it would be nice to have fewer commits per-subtree > than with $FreeBSD removal. In recent spelunking I've found that for low > traffic sub-trees I'm seeing a full screen (~50 lines for me) or more of > those > logs before getting to commits with content changes due to inconsistent > formatting leading to multiple removal commits. > > -- Brooks > --000000000000887243060aed1393 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>OK. I've pushed a branch=C2=A0to github for comme= nting.</div><div><br></div><div><a href=3D"https://github.com/bsdimp/freebs= d/tree/sccs">https://github.com/bsdimp/freebsd/tree/sccs</a><br></div><div>= <br></div><div>I've broken it up in a couple of ways.</div><div><br></d= iv><div>First, one commit per directory=C2=A0for the SCCS removal. I did th= is for Brooks to see if that's what he wanted.</div><div><br></div><div= >Then I have one final sccs removal commit for the whole tree for what I ha= d to do by hand. I can recreate the first 12 by script (plus two fixups)</d= iv><div><br></div><div>Then I have a 'remove all the copyright strings = prefixed by=C2=A0@(#) that were ifdef'd=C2=A0out' commit which also= did minor touchup of files. I did this mostly by hand since there was just= a smidge too much variation.</div><div><br></div><div>And then a whole lot= of automatic removal of sys/defs.h that had filtered through the prior rem= oval of FreeBSD, sccs, and copyrights. This is 100% scripted with me spot c= hecking the diffs for sanity.</div><div><br></div><div>I'm looking for = feedback on the changes, of course, but also on whether I should fold back = the last two commits into the first dozen or so done by directory=C2=A0(tot= al of about 35 commits)...=C2=A0 Or should I break them up by directory as = well. I'm leaning towards folding back all but the manual changes and d= oing it all per directory (so 12 commits plus the one manial).</div><div><b= r></div><div>Once I get initial feedback, I'll either go with my lean (= if there's none) or adjust course as needed.</div><div><br></div><div>I= plan to MFC these to stable/14 on a best effort basis (eg, if it doesn'= ;t apply, I'll skip that chunk, but otherwise git cherry-pick -x). I ha= ve no plans ot merge this back to 13.</div><div><br></div><div>diffstat say= s for this whole series:</div><div>=C2=A07893 files changed, 125 insertions= (+), 18138 deletions(-)<br></div><div><br></div><div>I'm plowing throug= h a tinderbox build right now, but amd64 builds both world and kernel. Sinc= e changes like this tend to go stale quickly, I wanted to do these two step= s in parallel (any breakage is trivially different, usually adding back a s= ys/cdefs.h include).</div><div><br></div><div>Finally, I have a number of s= ys/cdefs.h changes queued as well. These are cleaning up that file. I plan = on batching it with this set of changes so that there's only one 'r= ebuild everything' event for most people...=C2=A0 That is, unless the s= ccs series turns into a long discussion...</div><div><br></div><div>Comment= s?</div><div><br></div><div>Warner<br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Tue, Nov 21, 2023 at 11:03=E2=80= =AFAM Brooks Davis <<a href=3D"mailto:brooks@freebsd.org">brooks@freebsd= .org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar= gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1= ex">On Tue, Nov 21, 2023 at 09:12:48AM -0700, Warner Losh wrote:<br> > It's been 30 odd years since the last csrg release. They are no mo= re.<br> > <br> > At this point I think we can safely remove the few sccs tags that rema= in in<br> > the tree. The data will be there in git if we ever need it.<br> > <br> > Comments?<br> <br> Yes please.=C2=A0 The history is there in there repo(s) and there's so = much<br> blind copying where the context is entirely lost.<br> <br> >From my perspective it would be nice to have fewer commits per-subtree<br> than with $FreeBSD removal.=C2=A0 In recent spelunking I've found that = for low<br> traffic sub-trees I'm seeing a full screen (~50 lines for me) or more o= f those<br> logs before getting to commits with content changes due to inconsistent<br> formatting leading to multiple removal commits.<br> <br> -- Brooks<br> </blockquote></div></div> --000000000000887243060aed1393--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoFBbW4AYJe-zLB5gSORWsq_MrvWRh0Gj6-HmNd9OP_Ww>