Re: A smarter mergemaster

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yar,

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.

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_at_, if you'd rather
have the discussion on current_at_ that's fine too, but please pick one.

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.

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.

| 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.

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.

| 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?

| - "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.

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.

| - 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.

| 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.

Thanks again for your work on this,

Doug

- --

~    This .signature sanitized for your protection

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)

iD8DBQFDPN41yIakK9Wy8PsRAoA4AKC2X04Xnok/nj+nIdEpN7r8Z2/b/wCgtoQE
Wov5z1ozZ9tLGFY+VwTTMdQ=
=JMsn
-----END PGP SIGNATURE-----