Date: Mon, 04 Jan 2021 11:15:15 -0800 (PST) From: "Jeffrey Bouquet" <jbtakk@iherebuywisely.com> To: "Marek Zarychta" <zarychtam@plan-b.pwste.edu.pl> Cc: "Enji Cooper" <yaneurabeya@gmail.com>, "FreeBSD Current" <current@freebsd.org>, "FreeBSD CURRENT" <freebsd-current@freebsd.org> Subject: Re: CURRENT, usr/src on git, howto "mergemaster"? Message-ID: <E1kwVJz-0001q4-AS@rmmprod05.runbox> In-Reply-To: <ffdb5ba7-537d-166b-1eb6-3628f51cf8ac@plan-b.pwste.edu.pl>
index | next in thread | previous in thread | raw e-mail
On Mon, 4 Jan 2021 20:13:03 +0100, Marek Zarychta <zarychtam@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@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. > > With kind regards, > > -- > Marek Zarychta +1help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1kwVJz-0001q4-AS>