Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 1 Jun 2011 10:43:22 +0100
From:      Robert Watson <rwatson@freebsd.org>
To:        Takuya ASADA <syuu@dokukino.com>
Cc:        George Neville-Neil <gnn@freebsd.org>, "soc-status@freebsd.org" <soc-status@freebsd.org>, Kazuya Goda <gockzy@gmail.com>
Subject:   Re: Weekly status report (27th May)
Message-ID:  <09CF0C54-41F7-49A8-B92C-3BEF4FBF7A36@freebsd.org>
In-Reply-To: <5054184174934880962@unknownmsgid>
References:  <BANLkTim=zeRhwGajksbX2fBY9snkcj1h0g@mail.gmail.com> <8259CBF7-B2E6-49C6-A7C4-6682ECBDBB9F@freebsd.org> <5054184174934880962@unknownmsgid>

next in thread | previous in thread | raw e-mail | index | archive | help

On 1 Jun 2011, at 10:02, Takuya ASADA wrote:

>> When I get some time, probably next week,
>> I'll want to run some of this code myself.
>>=20
>> Also, though it's probably required, the changes to the mbuf mean =
that you cannot
>> MFC (merge from current) this code to any older FreeBSD release.  If =
and when the work
>> is done it would only be able to go forwards.
>=20
> Is that means it could be merge to next release, but it cannot
> backport to older release, am I correct?
>=20
> # Is it usual thing to backport new features for older releases
> anyway? Probably I don't get understand FreeBSD's developing cycle yet

We can probably figure out a way to make required mbuf changes =
mergeable, as well as driver KPI changes. However, let's focus on =
functionality for now and get to the rest in due course.

On the release model thing: yes, it's fairly normal to developer a =
feature in -CURRENT, and then merge to a -STABLE branch so that it hits =
a point release sooner. We enforce a trickle-back model in almost all =
cases though: it's not OK to ship a new feature in 8.4, for example, if =
it hasn't gone through 9-CURRENT. (There are some rare exceptions that =
arise when you have quite an old -STABLE branch and -CURRENT has =
diverged significantly that the proposed enhancements to -STABLE simply =
don't apply at all to -CURRENT. For example, when -CURRENT has a new USB =
stack and the enhancement is to the old stack). However, when things are =
merged back to a -STABLE branch, there are quite tight constraints on =
binary compatibility for both userspace and the kernel, so as to avoid =
breaking binary-only third-party applications, device drivers, etc.

Robert=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?09CF0C54-41F7-49A8-B92C-3BEF4FBF7A36>