A smarter mergemaster

[Yar Tikhiy]

On Thu, Sep 29, 2005 at 11:41:57PM -0700, Doug Barton wrote:
> 
> First let me say that you've obviously put a lot of work into this, and you
> have some very interesting ideas here that are worthy of further discussion.
> Please don't let any of my comments here be understood as criticism, or an
> attempt to discourage you.

Thanks!

> Second, I'd like to point out that it's generally a bad idea to cross post
> to more than one list. I've set a reply-to for hackers@, if you'd rather
> have the discussion on current@ that's fine too, but please pick one.

Well, I just couldn't decide between the two lists because I thought
that -current was much devoted to reporting LORs and panics while
discussions on -hackers tended to be rather theoretic unless they
were about LORs and panics :-)  Let's stick to -hackers now.

> Finally, please be aware that in src/MAINTAINERS I have requested pre-commit
> approval on changes to mergemaster. I hope that you'll respect that. I have
> some more specific comments below.

No problem with that, I'm by no means going to violate your
maintainership over mergemaster.  And yes, I should have peeked in
src/MAINTAINERS earlier :-)

> Yar Tikhiy wrote:
> | Folks,
> |
> | I've got tired of dumb default choices mergemaster(8) offers and modified
> | it to be a bit smarter.
> 
> While I can appreciate your frustration, the way you've phrased this departs
> from the project's tradition of respect for fellow developers and their
> work. A better way for you to deal with your frustration here would have
> been to send me, or alternatively, one of the mailing lists, a post which
> stated your frustrations and asked for an explanation of the reasons for the
> defaults.
> 
> I am sure that you meant no actual insult here, so I'll not say anything
> more about this topic.

I beg your pardon.  Let's say I was over-excited with having mm
work the way I always wanted it to :-)

And, not being a native English speaker, I didn't imagine that the
word "dumb" could be insulting after I had seen so much references
to the illustrious Dumb Terminals of the Golden Era of Computing ;-)

> | Upgrading /etc often, as when following CURRENT, is much less pain to me
> | now.
> 
> One of the design decisions that you need to be aware of for this project
> since day one was to try and balance intelligent behavior and configuration
> options that would be useful for the very small percentage of the FreeBSD
> user community that constitutes our developers, versus the needs of the vast
> majority of "regular" users who need to be able to use the tool without
> becoming experts in either our build system, or the tool itself. That is why
> every single default for mergemaster is to do nothing. It was a purposeful
> decision to require the user to examine change requests, and make an
> affirmative choice to approve them.

In fact, following CURRENT is not the only case when "expert" mode
of mm could be desired.  People following STABLE branches on their
production machines use mm, too, and yours truly is among them.
Their case is even more calling for "expert" mode because numerous
machines usually need upgrading in a row.  The admins study all the
peculiarities of mm as soon as they run it a dozen times, but they
still need to run it after that.  Our /etc is well-suited for staying
just slightly modified in the most common cases, so there is little
need in turning each mm session into a school class to the admin.
Of course, the admins will be responsible for the massive destruction
their errors can cause when using mm in expert mode, but most admins
are used to this kind of responsibility :-)

> I find your idea of an "expert" mode for mm to be an interesting one, and I
> think that enough time has gone by so that it will be "safe" to add this.
> However I'd like to add a big, hairy warning message that says that users
> who enable this option do so at their own risk, etc. I need to think more
> about this.

I'm unsure if it is hairy enough, but it's on the manpage already,
as well as on the help screen, in my version.

> | The fruitiest features are as follows:
> |
> | - mergemaster no longer teases you with pauses in -v mode. Use -N (novice
> | mode) if you still want the pauses.
> 
> I'm inclined to alter this to hide the pauses behind an expert mode flag,
> but I need to study your patch more before I give a more firm opinion on
> this. Do you have another strong reason for adding this mode?

I just liked mm -v for it showing the list of files added locally,
but I wasn't happy with the pauses obviously intended for novices,
especially when I had to upgrade several machines in a row.

> | - "Stale" rc.d files can be rm'ed or kept on individual basis.
> 
> I think this is a good compromise for those who insist on "polluting"
> /etc/rc.d with non-system stuff. :) If you're so inclined, could you add a
> knob to specify a list of files to exclude from consideration? If not, I'll
> take a look at it.

Done and doc'ed in my p4 branch as LOCAL_RC_FILES, which can
be a list of names and wildcards.

> It should also be noted that I have a plan (and a POC) that will allow us to
> migrate to full rcorder treatment for both /etc/rc.d/ and
> /usr/local/etc/rc.d/ scripts, but I'm waiting for 6.0-RELEASE to get out the
> door before starting that bikeshed.

I appreciate your plan greatly.  The main reasoning behind this
particular change to mm was having to keep rc.d scripts for 3rd
party apps that should start earlier that localpkg and use rcorder,
e.g., routing daemons.

> | - There is expert mode, -E.  In this mode,
> | mergemaster offers more dangerous defaults, mostly [install] or [delete]
> | depending on the question.  So you can just keep hitting Enter most of
> | the time if your /etc is just slightly modified.  In addition, you get
> | the 's' choice when in a subdirectory: auto-install all files from this
> | subdirectory -- much useful to deal with sweeping changes to rc.d or
> | periodic.
> 
> Hrrrm ... this is partially in violation of one of my other design goals,
> which is to have admins actually SEE the changes to the things that they're
> installing, but this is also one of the least popular aspects of the thing,
> so I'm inclined to lean into the wind on this one. I would like to consider
> /etc/defaults/ exempt from this treatment however. I still feel strongly
> that admins should see what is being changed there since those changes are
> much more likely to introduce a problem than any other directory.

I think this feature of expert mode can be justified by having to
run mm on more than one machine when upgrading a whole herd of them
from version A to version B.  Then the admins can look at the changes
once, but they won't have to browse through them a dozen times.

> | Feedback is welcome.  And please please don't skip making a backup of
> | your /etc before running mergemaster!  I can't be responsible for its
> | loss due to bugs in my code or whatever.
> 
> While on the one hand I certainly appreciate and agree with this sentiment,
> not introducing changes that violate POLA, or are very dangerous to
> unsophisticated users, is one of the reason I request pre-commit approval.

Well, it can hardly be more dangerous than having "rm -rf" in the base
system, so there is little reason in over-protecting the humble users ;-)
Of course, I won't commit anything to the stock mm w/o your approval.
And thank you for your suggestions!

-- 
Yar