Weekly status report (27th May)

[Robert Watson]

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.
>> 
>> 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.
> 
> Is that means it could be merge to next release, but it cannot
> backport to older release, am I correct?
> 
> # 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