From owner-freebsd-arch@FreeBSD.ORG Wed Dec 22 10:01:26 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 671B2106566B; Wed, 22 Dec 2010 10:01:26 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 218F88FC12; Wed, 22 Dec 2010 10:01:26 +0000 (UTC) Received: from [192.168.2.104] (host86-163-246-141.range86-163.btcentralplus.com [86.163.246.141]) by cyrus.watson.org (Postfix) with ESMTPSA id 12BC046B32; Wed, 22 Dec 2010 05:01:23 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <4D11542E.8020402@freebsd.org> Date: Wed, 22 Dec 2010 10:01:21 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201012211500.16131.jhb@freebsd.org> <4D11542E.8020402@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.1082) Cc: mdf@freebsd.org, 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: Wed, 22 Dec 2010 10:01:26 -0000 On 22 Dec 2010, at 01:28, Julian Elischer wrote: >> (2) Is our security support lifetime for -STABLE branches too short = to allow >> major products to be built on them and have the downstream product >> lifetime largely live within our lifetime? >=20 > I think so.. places I have worked tend to need about a year to get a = new release of their > product out the door in practice, and if we jump to a new release = every year, > then as they jump, so do we, so they are 2 revisions back "again". > Generally a company wouldn't want to go through the pain of an OS = upgrade more than > about once in three years and often it's longer.. It IS a pain for = them. > they have to actually retool all their testing and they have to = re-certify tons of > stuff, such as their build procedures. ALSO, with a new release comes = a new set of ports. > and THEY have to be re-certified too. The extended support release model was introduced to address these = specific concerns, providing non-".0" releases that had a guarantee of a = minimum of two years security support from the day of release. It would = be interesting to know if this has in fact led to a preference for = building products and providing services on extended support releases. Looking at our current supported release table, I see that all but one = of the releases on the table is an extended support release, including = all non-".0" 7.x releases to date. For example, 7.1-RELEASE was shipped = 4 January 2009, and will go out of support on 31 January, 2011. That's = not a bad run. And if vendors slide along 7-STABLE, then they'll get two = years from the final release of 7.4, likely supporting them through = early 2013. We also now provide binary updates and binary upgrades -- less valuable = to appliance builders, but it would appear widely used by = service-oriented consumers. Feedback from vendors / consumers who are = using extended releases in preference to regular releases would be = welcome -- is the current balance there right? Most of the feedback I'm getting suggests that our policy and technology = changes in the last few years, bringing in extended support releases and = binary updates, have addressed those problem areas. Instead the concern = is more that -STABLE branches wrap up too quickly: if you start building = a product against .0, and ship with .1, then you may find yourself = trying to continue to support the product several years past our last .x = release, causing problems running on contemporary hardware due to stale = hardware support. And I worry a lot about the upstream problem: vendors = who have significant local changes that never go upstream because HEAD = is two major releases ahead. But I think we need vendors to tell us specific stories about exactly = where and how things have gone wrong -- Matthew's post is valuable in = that sense, as sometimes we just hear "grumble grumble releases too = fast", or "running into device driver problems with 6.x!". I did some = work with a customer recently in which it was almost impossible to test = the changes we made upstream on their actual product release version on = the basis of a lack of device driver support in 6.x, which no longer = supports ethernet and storage chipsets on many current motherboards. Robert