Page MenuHomeFreeBSD

add mergemaster(8) deprecation notice
ClosedPublic

Authored by emaste on Jan 22 2020, 9:03 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Feb 22, 7:19 PM
Unknown Object (File)
Wed, Feb 14, 7:28 PM
Unknown Object (File)
Jan 12 2024, 1:51 PM
Unknown Object (File)
Jan 3 2024, 6:09 AM
Unknown Object (File)
Dec 21 2023, 5:13 AM
Unknown Object (File)
Dec 10 2023, 8:49 PM
Unknown Object (File)
Dec 7 2023, 10:06 AM
Unknown Object (File)
Dec 3 2023, 2:00 PM

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

emaste added a subscriber: rgrimes.
rgrimes requested changes to this revision.Jan 23 2020, 2:42 AM

Relnotes: Y and RELNOTES entry possible too, and with a slight language change MFC to 11 and 12.

usr.sbin/mergemaster/mergemaster.8
49

utility is being deprecated at .Fx 13.0.
Then this can be merged to stable/11 and stable/12?

This revision now requires changes to proceed.Jan 23 2020, 2:42 AM
usr.sbin/mergemaster/mergemaster.8
49

Do you suggest we indicate it's deprecated in 13 and then remove it before 14, or remove in 13?

i.e., what about one of these:

The
.Nm
utility is deprecated and will not be available in
.Fx 13.0.
The
.Nm
utility is deprecated and will not be available in
.Fx 14.0.

etcupdate is available in all supported releases

The timing is flexible I think, but my recollection of the current depricaiton policy is since no notice went out in 12.0 the first notice of deprecation should be in the 13 branch and the code is removed in 14. But as I said history has shown us to be pretty flexible especially if we get notice MFC'ed and it goes out in 12.2. So up to you which path you choose.

I do like the text you used.

Further note, you should make the utility itself spit out a notice when executed.

Some further discussion has turned up a preference for removing in 13.0, and I'm happy enough with that plan assuming we get the notice in 12.2 and 11.4.

Add a few others who have touched mergemaster as subscribers.

I guess take this acceptance lightly- I've only modified work by Allan, but etcupdate and/or pkg are clearly an improvement based on what I've seen.

I think removing in 13.0 might be a bit aggressive. I've certainly run into several developers who still use this instead of etcupdate. We also haven't updated any of our docs in the handbook to mention etcupdate (wblock@ tried but gave up when he ran into issues I didn't understand when trying to use etcupdate). I do think a runtime warning might also be warranted, though likely to be lost in the noise that mergemaster generates. Making sure the handbook documents etcupdate is probably a prerequisite for deprecating it.

I agree with @jhb on the update of the handbook should hapoen first

Why though? Plenty of users still use it. What's the argument for forcing etcupdate over mergemaster? IMHO it's a large burden to users to convert things that use mergemaster fine to etcupdate.

What unsolved problem warrants removal? I assume the argument is "not maintained" which is why I ask what problem exists.

@emaste, do you plan on picking this up again? Removal in 14 seems reasonable. Handbook and UPDATING have been updated since.

Why though? Plenty of users still use it. What's the argument for forcing etcupdate over mergemaster? IMHO it's a large burden to users to convert things that use mergemaster fine to etcupdate.

What unsolved problem warrants removal? I assume the argument is "not maintained" which is why I ask what problem exists.

As far as I know biggest reasons are included in some PR's (252054).
mergemaster does not work nicely with VCid's being removed because of the git transition (13-release and higher).

https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=mergemaster&list_id=468358

Perhaps bump .Dd, too, when you are ready to commit.

This revision was not accepted when it landed; it landed in state Needs Review.Mar 3 2023, 1:44 AM
This revision was automatically updated to reflect the committed changes.