From owner-freebsd-arch@FreeBSD.ORG Mon Sep 17 21:52:26 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12DCC106564A for ; Mon, 17 Sep 2012 21:52:26 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id C03148FC1C for ; Mon, 17 Sep 2012 21:52:25 +0000 (UTC) Received: by iea17 with SMTP id 17so7858692iea.13 for ; Mon, 17 Sep 2012 14:52:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=ppGmbqHkkZYtL6+9hl2U8kcIerM96HnNTLclm3I75yU=; b=USs61fFRogJUlqwhFp8r0ALhSaeE9Y2HzQRGn8j8W8b/zwwEIAl6wc/O37mWRtPjof U5qmCT7Uv+750P6tWZGZbFzEPlyu5Lp6cOmE3SxulZY+r0SZUOdgnodhQgi5Olw/gWf1 Qurj4Qllimxh9TsnShUgExGEGUScAkKqrdbp1oSEAEF+9H8APWpkkpSemUCcVvPzLWD4 Aw5mlk2KBijyM/YYLy+2TZ3WmPdwCML59BhTCj9fPhjjAnR7lR2XOncpm+ZSSc7rmSWC W/BrlWOEntfD2I9MkGfsjQZPIxVxQsj6dxjdXHPv467rNyM2xOZcDlCpAvzexeL2oPCj 4k/g== Received: by 10.50.88.194 with SMTP id bi2mr8438121igb.47.1347918745372; Mon, 17 Sep 2012 14:52:25 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id 10sm19777642igf.11.2012.09.17.14.52.21 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Sep 2012 14:52:23 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <50578D98.7080902@FreeBSD.org> Date: Mon, 17 Sep 2012 15:52:20 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3649BB84-30A9-4765-8BB6-2484B4B88343@bsdimp.com> References: <20120916053523.GJ37286@deviant.kiev.zoral.com.ua> <51B48339-D1FA-49CD-B582-1C58855B024E@bsdimp.com> <50563EA6.1050908@FreeBSD.org> <99E30CDE-AC9D-4615-8830-5EC511EE1BBB@bsdimp.com> <50578D98.7080902@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmdChpzcsoyfbrA0TSH1OWwItYl2vvoSq/xB/n4/xGX1v5WY3KXO10aPZMv98GqHQUXxsSL Cc: Konstantin Belousov , Eitan Adler , arch@freebsd.org Subject: Re: Fallout from the CVS discussion X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 21:52:26 -0000 On Sep 17, 2012, at 2:52 PM, Doug Barton wrote: > On 09/16/2012 14:45, Warner Losh wrote: >>=20 >> On Sep 16, 2012, at 3:03 PM, Doug Barton wrote: >>=20 >>> On 09/16/2012 09:03, Warner Losh wrote: >>>> One of the things we are trying to move towards is that current can = be cut into a release branch on short notice. We need to keep it as = close to production ready as possible. People >>>=20 >>> I find your response here interesting Warner, given that when I have >>> opposed what I felt were too-drastic changes in HEAD (such as = removing >>> sysinstall before a post-install configuration solution was ready) = your >>> response has been, "It's HEAD, we can break things ... let's see = what >>> happens!" >>=20 >> sysinstall replacement was a different discussion, with differing = technical criteria. >=20 > Right... in the sysinstall case we had a mainline system tool that was > actively being used, with no replacement in sight. It should not have > been removed until we had a viable replacement in the base. sysinstall's primary purpose was to install the system. It was also = useful for configuration, and that auxiliary part was missing. Given the = extreme barrier to entry for the replacement, it seemed wise at the time = to let bsdinstall in without the bsdconfig part. Given the bumps we've = had in bsdinstall, I think the push to get it in was premature from the = functionality it provided at the time. We've since mostly fixed it. > In the CVS case we have something that was _formerly_ in a similar > category, but is not any longer. cvs is still being used, but not in a primary role. I want to make sure = that the transition is fully documented with the new info before we cut = cvs loose. >> Also, using it against me now for consistency likely isn't so good. = I think we moved too quickly, in retrospect, on that. That experience = suggests we be more cautious in the future, including for things like = this. >=20 > Careful! You're coming dangerously close to saying I was right about > something. :) You were right, but for the wrong reasons. :) Nah, I'll give you this = one. >>> Now that you are the one opposed to the change, we need to >>> keep HEAD "close to production ready." >>=20 >> Look at bz's push in this area.=20 >=20 > Yes, I think it's awesome that someone else has finally taken up the > "plz 2 stop brking teh head, kplztks" banner. Too bad it's still being > ignored. Lots of people say it, until they want something in the system that is = unstable... :) >> Also, I'm not opposed to this change, just opposed to this change = today, as explained elsewhere. >=20 > Doing it now has a lot of benefits, but ... >=20 >>> There is a compromise solution here that I have been hesitant to = offer >>> because I was really hoping that sanity would prevail. But why not >>> switch the default MK_CVS knob over to "no" now? That will give us = an >>> opportunity to see if there really will be any fallout, and easily = fix >>> it if there is. >>=20 >> I believe that's already been done. >=20 > It isn't now, but it sounds to me like you're saying that you're not > opposed to doing so? MK_CVS moving to 'no' by default is something we can do right away, = since it is easy to figure out what went wrong for the people using cvs = and putting it back w/o needing to download anything new. Living behind = firewalls can make downloads a pita. I have had systems with very = specific holes that made it a PITA to download anything to them, and it = is a common occurrence. > Eitan, if you're listening, I'd strike while the iron is hot. :) Since I thought that had already been done, please do so. Please make = sure that ObsoleteFiles does the right thing too :) Oh, and make sure = UPDATING is updated. Warner=