Re: CURRENT, usr/src on git, howto "mergemaster"?

From: Warner Losh <imp_at_bsdimp.com>
Date: Mon, 4 Jan 2021 12:16:30 -0700
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.

Warner
Received 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