From owner-freebsd-arch@FreeBSD.ORG Sun Sep 16 16:03:25 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F81C106566B for ; Sun, 16 Sep 2012 16:03:24 +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 3CE198FC08 for ; Sun, 16 Sep 2012 16:03:24 +0000 (UTC) Received: by iea17 with SMTP id 17so5616203iea.13 for ; Sun, 16 Sep 2012 09:03:23 -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=mtJdZ1Oz2SpJKUzy/J+2a65K+zKSqTtkvrVmcer7c7c=; b=A5/U6+8iWvbV8KkCDCC6g01UlOA0ksItsla3bWRr6X8sidtvMTuYERXAUTP+Ivdrx2 ry7xwtD6n3Gq5c1MZcVvJZlLoyLw0sZFhhMJRdxqvoP65BY0YlYBPNSSD68GMGfXT9w8 2IXRtkrUeLhRPDa67KR1D9+nHVl+zE7JyVKgMceoHG6FP1GpRt1fX/85sLiynGZR0Xgs DX562B8Ien/u4ES9HCJtDogLJ+qULUh2qJgD8Y2NhK3Fu8fWXzsSHRX+ScN0Y43zo5LV ad+2GIV9J+H+y/HWMHFjhh0VbViaR74gKC8PnHA5WYQYy5YvyXmTCK8lMaC7cartvvLc dgfg== Received: by 10.50.12.138 with SMTP id y10mr4397174igb.53.1347811403811; Sun, 16 Sep 2012 09:03:23 -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 d19sm4514252igp.6.2012.09.16.09.03.21 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 16 Sep 2012 09:03:22 -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: Date: Sun, 16 Sep 2012 10:03:20 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <51B48339-D1FA-49CD-B582-1C58855B024E@bsdimp.com> References: <20120916053523.GJ37286@deviant.kiev.zoral.com.ua> To: Eitan Adler X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkY0jY95203dtYT/QL5reUJIDvCBe7ppoOX4JCnnfPZMnRupdwtYobYONKNR0/f3MzQqiDH Cc: Konstantin Belousov , 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: Sun, 16 Sep 2012 16:03:25 -0000 On Sep 16, 2012, at 6:34 AM, Eitan Adler wrote: > On 16 September 2012 01:35, Konstantin Belousov = wrote: >> On Sat, Sep 15, 2012 at 04:37:49PM -0400, Eitan Adler wrote: >>> However, -CURRENT is not meant to be a production system. >>=20 >> It is simply not true. >=20 > My statement was true, but does not disagree with the content below. > Production system !=3D Production Grade. 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 do put -current systems into = production for testing purposes, or because they have made the = evaluation and know what they are doing. Discouraging production = systems from current, the present project policy, doesn't mean the = project doesn't appreciate the people that do put current systems into = production and the data that generates. Put another way: saying that current isn't meant for production systems = as a justification to slash things out before we are quite ready isn't = something people in general want to encourage, since it is close to = attitudes in the past that got us into a lot of trouble. Sure, in this = case the reaction is a bit of hyperbole, but there's long, historically = lingering wounds that put people on a hair trigger. >> CURRENT shall never be knowingly put into a state >> where it cannot be used for the 'production-grade' use, whatever it >> means. >=20 > Agreed. >=20 >> We do accept changes are so disruptive that some unknown fallout >> is expected, since otherwise developers cannot make any significant >> progress. >=20 > The point of my statement is that it perfectly acceptable to change > behavior in HEAD in a non-backwards compatible way. Some behaviors, yes. Most behaviors need to remain the same for a = variety of reasons. > In particular no > systems running -CURRENT are expected to be "critical functioning". Yes, they often are. > People that track -HEAD are expected to be able to deal with the sorts > of problems that occur from "drastic change." Generally yes. However, we do try to cushion the blows that are = delivered in -current. The reason we have the separation isn't so we = can do whatever we want in -current, it is so that when somebody messes = up, the damage is more limited. >> But introducing known breakage is simply not acceptable. Doing so = shrinks >> the already limited testing base we have for HEAD. >=20 > Agreed. Ditto. Sorry to be so pedantic on pushing the point in this meta-discussion, = but I don't want to see us slide back into the 'wild west' that current = was in the 5-current time frame. The CVS thing, by itself, wouldn't do = that, but we must have the proper attitudes for getting change done, and = when we pull the trigger on change. Warner