From owner-freebsd-stable@FreeBSD.ORG Mon Sep 22 23:18:21 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E715106564A for ; Mon, 22 Sep 2008 23:18:21 +0000 (UTC) (envelope-from heliocentric@gmail.com) Received: from mail-gx0-f17.google.com (mail-gx0-f17.google.com [209.85.217.17]) by mx1.freebsd.org (Postfix) with ESMTP id 0AB648FC0C for ; Mon, 22 Sep 2008 23:18:20 +0000 (UTC) (envelope-from heliocentric@gmail.com) Received: by gxk10 with SMTP id 10so3621151gxk.19 for ; Mon, 22 Sep 2008 16:18:20 -0700 (PDT) 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:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=D9nOmOdCFMX4iufT7KL4+j1eHd//vmLBDavA7nnhBnw=; b=j7bJ/tFtsJVKmnJ0StYbfjGXIUf5VUjRASRN5eUBjmzzXUvab3gHWr+BggKeKx6i2F o9wDttEHQT8BRqQvrczrLV3X+48qRX/wWZv4YL62p9moXfnCkqPEgJAgeiELEEKpggbj LPuJKODJzXQ7fZ8TvHDU2dYs97+Vx3y9nEIOY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=RqLbTPB/sPjjb6x9kMI9oJXvZKBtvz/lXlsuYBcbu1moBilcnuJvMyYP/EH/jOtVof CRY34AbIsYbjooOI2owfazCyKD0hHzEV3GXQqyzaZ0GVnZq/Z0paNeeoWjIesT3Ji9pm GE+LTxuHs1VOsdjlg5JcWYcmWvU4eUEQzXu3g= Received: by 10.90.33.5 with SMTP id g5mr5416389agg.50.1222125500231; Mon, 22 Sep 2008 16:18:20 -0700 (PDT) Received: by 10.90.80.14 with HTTP; Mon, 22 Sep 2008 16:18:20 -0700 (PDT) Message-ID: Date: Mon, 22 Sep 2008 19:18:20 -0400 From: "Dylan Cochran" Sender: heliocentric@gmail.com To: freebsd-stable@freebsd.org In-Reply-To: <48D81034.6080607@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <48D81034.6080607@FreeBSD.org> X-Google-Sender-Auth: 0e7e1cc5df7cf699 Subject: Re: Benefits of multiple release branches (Was: Re: Upcoming Releases Schedule...) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2008 23:18:21 -0000 On Mon, Sep 22, 2008 at 5:37 PM, Doug Barton wrote: > Dylan Cochran wrote: >> One of the biggest (and most prominent, though not obviously so) >> issues is the lack of concurrency with regards to releases. With the >> default system, having multiple freebsd releases side by side (both >> different versions, and different architectures) is infeasible. This >> makes the choice more critical, while hindering flexibility. The >> necessity of long support schedules is one of the symptoms. > > While on the one hand I can understand the users' frustration on this > point, IMO having at least 2 release branches is necessary. We are > trying to walk the fine line between pleasing those who want new > features (including new drivers), better performance, etc. that a newer > release branch offers (in this case 7.x) and those that want long-term > API stability, and other forms of stability that an "established" > release offers. The only practical way to accomplish both of those goals > is with 2 release branches. I agree completely. My point is that as of right now, there is a large degree of collisions that take place, that prevent an install of 6.3-RELEASE and 7.0-RELEASE from existing at the same time on the same drive, and being trivial to switch between the two if need be. Same as with i386/amd64. This is an artificial construct, and doesn't /have/ to continue existing. Which imo, will be far more useful then expecting a large amount of time expended to dead-end branches of code that are well past their expiration date, and begin suffering from massive bitrot. At the very least, it will make the default system more robust by moving the majority of the upgrade procedure from being /replacements/ of files, to creating new files coupled with an atomic activation 'switch'. Please don't misinterpret my ideas as being supporting his viewpoint, merely pointing out a perspective to the problem which hasn't been mentioned.