Date: Tue, 21 Dec 2010 17:28:14 -0800 From: Julian Elischer <julian@freebsd.org> To: Robert Watson <rwatson@freebsd.org> Cc: mdf@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Schedule for releases Message-ID: <4D11542E.8020402@freebsd.org> In-Reply-To: <alpine.BSF.2.00.1012212215320.36028@fledge.watson.org> References: <AANLkTi=_mHDz3LZ1SAuCsz6kmvqCdZBx3Q5ZTyQQO1%2BP@mail.gmail.com> <201012211500.16131.jhb@freebsd.org> <alpine.BSF.2.00.1012212215320.36028@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/21/10 2:28 PM, Robert Watson wrote:
> 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?
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.
>
> (3) Do old -STABLE branches stagnate too quickly with respect to
> device driver
> support such that they can't be used?
it does happen new motherboards with new devices can be a problem, but
don't forget that
the motherboards have to be certified too so that adds a lag there too.
>
> (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.
out developer community is really suffering from the global economic
slowdown.. people are more pushed at work and have other
items pressing on their time. Just saying "I'm not supporting 7.x" is
one way to lose some of the load.
>
> Robert
> _______________________________________________
> freebsd-arch@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D11542E.8020402>