Date: Thu, 6 Feb 2020 10:26:33 -0800 (PST) From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> To: Warner Losh <imp@bsdimp.com> Cc: "Rodney W. Grimes" <rgrimes@freebsd.org>, Warner Losh <imp@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r357624 - in head/sbin: . sunlabel Message-ID: <202002061826.016IQXI8003476@gndrsh.dnsmgr.net> In-Reply-To: <CANCZdfqPX756AzSMoNrynnikmJ-xPwjwxvaf18y-VR2d-WwA3Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Thu, Feb 6, 2020 at 10:57 AM Rodney W. Grimes <freebsd@gndrsh.dnsmgr.net> > wrote: > > > > Author: imp > > > Date: Thu Feb 6 17:52:02 2020 > > > New Revision: 357624 > > > URL: https://svnweb.freebsd.org/changeset/base/357624 > > > > > > Log: > > > No need to make sunlabel anymore > > > > > > It was only built on sparc64. Since it wasn't a general tool on other > > > architectures, no need to keep it around for another release. > > > > > > Reviewed by: emaste > > > Differential Revision: https://reviews.freebsd.org/D23524 > > > > Should not this whole sparc64 removal have had some deprecation notices > > put in and merged back to 11 and 12 to give users a pro-active notice > > that it is gone_in(13)? > > > > We should definitely put it in the 11 and 12 release notes. That's a good > idea. Random thought, dont pay it too much attention but: DEPRECATED sitting next to RELNOTES? Or even a specific section in RELNOTES? Thought that is not suppose to be MFC'ed. > We can put a printf in the kernel so everybody sees it on boot. I'll make > that change, though I don't think gone_in is quite right there (I'll check > before I commit). This should cover all bases. > > For all the utilities that are installed on all the platforms I'll do it > (like I did for elf2aout), but for utilities that are only on sparc64, I > have no plans to do it. They are covered by the general 'sparc64 is removed > in FreeBSD 13.0'. I think this is a reasonable compromise that catches the > corner cases where people are using a utility not on sparc64, but that > we're removing it while saving a little bit of work which is rather tedious > and error prone for a utility that one could not reasonably expect to be in > 13. That seems a reasonble best effort to me. > It's the MFC bit that makes this somewhat tedious because we normally > do those days later... That shouldnt effect it as long as the MFC'able commit is done first, then the removal commit. > Warner -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202002061826.016IQXI8003476>