Date: Thu, 29 Sep 2005 23:41:57 -0700 From: Doug Barton <dougb@FreeBSD.org> To: Yar Tikhiy <yar@comp.chem.msu.su> Cc: hackers@freebsd.org, current@freebsd.org Subject: Re: A smarter mergemaster Message-ID: <433CDE35.7040801@FreeBSD.org> In-Reply-To: <20050929224548.GB3035@comp.chem.msu.su> References: <20050929224548.GB3035@comp.chem.msu.su>
next in thread | previous in thread | raw e-mail | index | archive | help
-----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@, if you'd rather have the discussion on current@ 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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?433CDE35.7040801>