Date: Tue, 21 Dec 2010 22:28:00 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: John Baldwin <jhb@freebsd.org> Cc: mdf@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Schedule for releases Message-ID: <alpine.BSF.2.00.1012212215320.36028@fledge.watson.org> In-Reply-To: <201012211500.16131.jhb@freebsd.org> References: <AANLkTi=_mHDz3LZ1SAuCsz6kmvqCdZBx3Q5ZTyQQO1%2BP@mail.gmail.com> <201012211500.16131.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
problems:
(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
lifetimes?
(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.
Robert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1012212215320.36028>