Date: Wed, 22 Dec 2010 10:01:21 +0000 From: "Robert N. M. Watson" <rwatson@freebsd.org> To: Julian Elischer <julian@FreeBSD.org> Cc: mdf@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Schedule for releases Message-ID: <EC0B2C3E-1973-4ED5-823A-49638D7DE520@freebsd.org> In-Reply-To: <4D11542E.8020402@freebsd.org> References: <AANLkTi=_mHDz3LZ1SAuCsz6kmvqCdZBx3Q5ZTyQQO1%2BP@mail.gmail.com> <201012211500.16131.jhb@freebsd.org> <alpine.BSF.2.00.1012212215320.36028@fledge.watson.org> <4D11542E.8020402@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EC0B2C3E-1973-4ED5-823A-49638D7DE520>