Date: Sat, 3 Jan 2009 04:55:25 +0100 From: "Ivan Voras" <ivoras@freebsd.org> To: "Doug Barton" <dougb@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Garrett Wollman <wollman@bimajority.org> Subject: Re: svn: head/usr.sbin/mergemaster Message-ID: <9bbcef730901021955s254b2eb5j24f93127e84fb5ee@mail.gmail.com> In-Reply-To: <495E9E4B.8030905@FreeBSD.org> References: <200901011055.n01AtQaN052763@svn.freebsd.org> <495DB15B.8040908@FreeBSD.org> <495DB9B6.4030801@FreeBSD.org> <495DC5AF.3050908@FreeBSD.org> <495E91F8.3010706@FreeBSD.org> <18782.37537.775290.682466@hergotha.csail.mit.edu> <495E9E4B.8030905@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
2009/1/3 Doug Barton <dougb@freebsd.org>: > Garrett Wollman wrote: >> <<On Fri, 02 Jan 2009 14:15:20 -0800, Doug Barton <dougb@FreeBSD.org> said: >> >>> As I said in my first post, if there is overwhelming demand for this >>> down the road that is not met by the existing solutions I'll consider >>> adding a better implementation as an option, off by default. >> >> It would be much better if the options that *nearly every user will >> want to use* are set correctly by default. > > 1. Past experience indicates that your average _developer_ is not very > good at estimating what the average _user_ will want as the default. > 2. The needs of developers are considerably different than the needs > of the average user. And just how can upgrading all the non-user-modified files cause serious damage here (serious=system not bootable, login not possible, etc)? Please explain with examples, since from this and the old current@ thread I only got the impression that "it's baaaad, m'kay". Note that regular users will not upgrade -CURRENT, and most won't even upgrade -STABLE, but will go from one -RELEASE to another. Speaking for myself, mergemaster is a source of constant irritation because it doesn't do auto-upgrades by default, and I'm often tempted to just not start it rather than going through 15 minutes of "q, i, <enter>" (my pages is less, thus the "q"). If you're so against this option, may I propose something that could satisfy both camps: make a symlink to mergemaster, call it "auto-mergemaster", detect the called name from within the script, then enable autoupgrades if it matches "auto-mergemaster" (as well as possibly other features that make it less verbose and less user-input intensive). Do this as a service to the community and create yourself the possibility of telling us "I told you so"! I'm pretty much sure that users will eventually forget there's a manual "mergemaster" but it will still be available for users used to the old semantics. Your response, please? > 4. I have said literally from day 1 that mergemaster should not ever > change a file on a user's system without them taking an affirmative > step for it to do so. Whether you agree with that idea or not, it is > an expectation that I do not want to mess with. Please consider that the user climate has changed from "day 1". > Given the number of help requests I get for mergemaster that are > already answered in the man page, I do not regard this as all that big > of a problem. :) But seriously folks, have you read all the way down > to the part about the ability to use an rc file to store your commonly > used options? Thanks for this, I didn't know about the rc file, but I see two problems with it: 1) The example in the man page doesn't say how to enable "-U" mode (reading on 7.1-stable) 2) This means I have to copy yet another file to my newly installed systems, and I think I'm not the only one who does this and would like to avoid another file. I install new systems from CDs fairly often, and the list currently includes about a dozen files (tcsh rc files, cvsup files, vim rc, etc.).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9bbcef730901021955s254b2eb5j24f93127e84fb5ee>