From owner-svn-src-head@FreeBSD.ORG Sat Jan 3 03:55:28 2009 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34518106566B; Sat, 3 Jan 2009 03:55:28 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-bw0-f19.google.com (mail-bw0-f19.google.com [209.85.218.19]) by mx1.freebsd.org (Postfix) with ESMTP id 1C8B08FC17; Sat, 3 Jan 2009 03:55:26 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by bwz12 with SMTP id 12so17815458bwz.19 for ; Fri, 02 Jan 2009 19:55:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=TCHBHijlDDuyQ0EETIuC36mYDtNz6KxmiJcU4cnNTSA=; b=QOudIvx1KAGHSEWdVFtTlHHZnxSJBuXCpI1WvxczKFFXnwZayaYoYCjCW/puFxlfpV x3GOv5dXAkYlUjYPtWOA+E5tXktJfdIPCFxG43JPooTnCV3l+cchqgYPNwz/idETcT2E 4p9AT+5/3rvAzKPUQ9NAySDbFnH51CCjo1Rec= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=ArAf51vjfzqy7kMK2W17ObG24De228OdaM9uflYDEAkZeEwDKAuWNyoeuxTj/snih0 Vpzbeu+qcfbNj6TpAmwg/zfXwBcMUwL7cteA2SmhJVrynhEVjNMj5BP9C9Zo8a8cVGpU PsK4hh2KTSf8M2tQcNy720yMoK+DJtU/Ipyn4= Received: by 10.181.20.13 with SMTP id x13mr7105229bki.164.1230954925635; Fri, 02 Jan 2009 19:55:25 -0800 (PST) Received: by 10.180.208.17 with HTTP; Fri, 2 Jan 2009 19:55:25 -0800 (PST) Message-ID: <9bbcef730901021955s254b2eb5j24f93127e84fb5ee@mail.gmail.com> Date: Sat, 3 Jan 2009 04:55:25 +0100 From: "Ivan Voras" Sender: ivoras@gmail.com To: "Doug Barton" In-Reply-To: <495E9E4B.8030905@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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> X-Google-Sender-Auth: 8b0cee11fb6713c2 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Garrett Wollman Subject: Re: svn: head/usr.sbin/mergemaster X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 03:55:28 -0000 2009/1/3 Doug Barton : > Garrett Wollman wrote: >> < 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, " (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.).