From owner-freebsd-arch@FreeBSD.ORG Thu Dec 23 09:37:50 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 433F0106566C; Thu, 23 Dec 2010 09:37:50 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 901E98FC12; Thu, 23 Dec 2010 09:37:49 +0000 (UTC) X-Spam-Status: No X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.2, required 5, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_50 0.80) X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-ID: oBN9bXv5012517 Received: from gkeramidas-glaptop.linux.gr ([74.125.57.36]) (authenticated bits=0) by igloo.linux.gr (8.14.3/8.14.3/Debian-9.4) with ESMTP id oBN9bXv5012517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Dec 2010 11:37:43 +0200 From: Giorgos Keramidas To: John Baldwin References: <201012220852.oBM8q2Qi039123@lurza.secnetix.de> <20101222123834.GN23098@acme.spoerlein.net> <201012220942.26579.jhb@freebsd.org> Date: Thu, 23 Dec 2010 10:37:32 +0100 In-Reply-To: <201012220942.26579.jhb@freebsd.org> (John Baldwin's message of "Wed, 22 Dec 2010 09:42:26 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ulrich =?iso-8859-1?Q?Sp=F6rlein?= , Oliver Fromme , freebsd-arch@freebsd.org Subject: Re: Schedule for releases 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: Thu, 23 Dec 2010 09:37:50 -0000 On Wed, 22 Dec 2010 09:42:26 -0500, John Baldwin wrote: > On Wednesday, December 22, 2010 7:38:34 am Ulrich Sp=F6rlein wrote: >> I think this is the core "problem". Statistics[1] show, that most >> developers run some form of -CURRENT and also have some machines >> running the latest -STABLE tree. So, naturally, no-one is too >> thrilled about testing stuff for the pre-latest -STABLE tree. >> >> We should not try to have two stable branches overlap for that >> long. We are spreading our resources too thin here. >> >> CURRENT+STABLE makes sense, always. CURRENT+STABLE+STABLE might be >> nice for vendors, but in the end it's the developers doing the work, >> and they mostly only care about the one of the STABLES. We should not >> delude ourselves into thinking we can easily support two STABLE >> branches, that's just not happening. > > Actually, CURRENT+STABLE+STABLE doesn't really work for the vendors > either versus a CURRENT+STABLE where STABLE branches were created less > often and lasted longer. Exactly! My intuition says that vendors don't really care if there are two, three, or any number or 'old stable' branches. All they care is that the stable branch they just baselined their source tree on will live long enough for their product to ship at least a couple of GA versions. I've worked at companies where we built products on Solaris 8, for example, long after the GA of Solaris 10. The fact that we had to jump forward across two major versions was slightly painful and required a non-negligible amount of manpower to pull it off. The fact that Solaris 9 was also 'supported' never really played much of a role in the decision to move to the latest release version. It was always a feature-based decision and not a time-based one.