On Mon, Jan 4, 2021 at 12:13 PM Marek Zarychta < zarychtam_at_plan-b.pwste.edu.pl> wrote: > W dniu 04.01.2021 o 19:54, Enji Cooper pisze: > > > >> On Jan 4, 2021, at 10:49 AM, Marek Zarychta < > zarychtam_at_plan-b.pwste.edu.pl> wrote: > > > > … > > > >> Terrible idea IMHO, but I am only the weak voice from the userbase. > >> > >> It's like deprecating old, well-worn hammer in the favour of the nail > >> gun. Why not deprecate biff(1), pom(6), nvi(1) etc.? > > > > Marek, > > I’m curious: have you used etcupdate before instead of > mergemaster? If so when? If you ran into issues (UX as well as functional): > could you please report them on bugs.freebsd.org <http://bugs.freebsd.org/> > ? > > etcupdate is a less fragile tool that’s broken my systems less > when compared with mergemaster. > > Dear Enji, > > to satisfy your curiosity: Yes, I have tried etcupdate(8) a few times > over years. It works fine, but I don't like the idea of editing > conflicted files. > > I won't complain about etcupdate(8), but please leave mergemaster(8) > as is. I believe we need both: solid, fast black boxes driven it auto > mode and fragile tools in the base. mergemaser is rather not a potential > security hole in the system. > mergemaster is on its way out. Formalizing it by deprecating in 13 means you'll be able to use it through the end of life of the 13 branch many years from now. That's plenty of time to move to the new tools and/or develop enhancements that make them easier for you to use. The knock on communicating this well is a fair one, and we'll start taking measures to fix that. WarnerReceived on Mon Jan 04 2021 - 18:16:43 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:26 UTC