Schedule for releases

Robert Watson rwatson at
Tue Dec 21 22:28:01 UTC 2010

On Tue, 21 Dec 2010, John Baldwin wrote:

> I'm not entirely sure what the right answer is, but this is something that 
> has worried me for a while.

I see a few specific tensions to worry about, but they're not new ones.  The 
questions, really, are whether significant downstreams run into the following 

(1) Is our rate of change too great to allow useful upstreaming?  (Regardless
     of "releases")

(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?

(3) Do old -STABLE branches stagnate too quickly with respect to device driver
     support such that they can't be used?

(4) Are our point releases (.1 -> .2 -> .3) too large for downstreams to roll
     out as incremental point releases of their own products, extending their

(5) Do ports/packages stop supporting a branch before the useful lifetime of a
     -STABLE-based branch, such that a derived produt has to locally maintain
     versions of {Apache, ...} rather than rely on project infrastructure?

Looking at recent events, it strikes me that (3) is actually the most 
significant problem from the perspective of many vendors.  They'd like new 
device drivers to keep going back to 7.4, 7.5, and 7.6, perhaps without 
significant software changes, so that they can keep shipping a product that 
has to run on new hardware, but doesn't require new OS features otherwise. 
Our improvements in thinking about KPI have helped there, as well, but there's 
more to do.

I think there's also a potential confusion among some of our downstreams 
relating to our point releases.  As Colin has pointed out, they're really best 
thought of as "service packs", not OS releases in a recent sense.  Anyone 
building an embedded product/appliance should probably take the perspective 
that they will align delivery of an initial major release of their product 
with the .1/.2 of a FreeBSD branch, and that they will then ship occasional OS 
baseline updates to pick up new device drivers, bug fixes, minor software 
features, etc, at intervals after that.

Looking at 7.x, I'm struck by how much it has slowed down.  There's a 
significant user community, but not a significant developer community.  There 
was a non-trivial discussion of whether a 7.4 should be cut at all, given its 
potential to product secteam (etc) support commitments for three major 
branches for an extended period.  One thing we could do is better engage our 
downstream communities into helping to extend the lifetime of -STABLE branches 
by contributing to driver backports, long-term security maintenance, etc.  If 
(random vendor handwave, no insult to Intel meant) Intel isn't interested in 
doing the backports of, say, {em, igb, ...} to 7.x, then that needs to be 
pushed by someone with a product or environment that requires them to be 
interested.  We need to ensure that there are continuing developer communities 
reflecting the continuance of user communities.


More information about the freebsd-arch mailing list