Date: Thu, 23 Dec 2010 11:35:44 -0800 From: Garrett Cooper <yanegomi@gmail.com> To: Giorgos Keramidas <keramida@ceid.upatras.gr> Cc: =?utf-8?Q?Ulrich_Sp=C3=B6rlein?= <uqs@spoerlein.net>, Oliver Fromme <olli@lurza.secnetix.de>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: Schedule for releases Message-ID: <49D0851F-3145-43E4-BA22-24E4201BE496@gmail.com> In-Reply-To: <xeiabp4cygmb.fsf@kobe.laptop> References: <DB4D8AC7-25D6-4901-BBF9-77BEB956840B@cederstrand.dk> <201012220852.oBM8q2Qi039123@lurza.secnetix.de> <20101222123834.GN23098@acme.spoerlein.net> <201012220942.26579.jhb@freebsd.org> <xeiabp4cygmb.fsf@kobe.laptop>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 23, 2010, at 1:37 AM, Giorgos Keramidas <keramida@ceid.upatras.gr> wr= ote: > On Wed, 22 Dec 2010 09:42:26 -0500, John Baldwin <jhb@freebsd.org> wrote: >> On Wednesday, December 22, 2010 7:38:34 am Ulrich Sp=C3=B6rlein 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. >>>=20 >>> We should not try to have two stable branches overlap for that >>> long. We are spreading our resources too thin here. >>>=20 >>> 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. >>=20 >> 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. >=20 > 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. >=20 > 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. For some groups, they are not dev resource limited, but QA resource limited,= so getting all of the core OS changes qualified and into a set of mature pr= oducts can be a real chore. This is one of the pain points for my group. -Garrett=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49D0851F-3145-43E4-BA22-24E4201BE496>