From owner-soc-status@FreeBSD.ORG Wed Jun 1 09:43:26 2011 Return-Path: Delivered-To: soc-status@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55265106564A; Wed, 1 Jun 2011 09:43:26 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2F33C8FC13; Wed, 1 Jun 2011 09:43:26 +0000 (UTC) Received: from [192.168.2.100] (host86-148-228-76.range86-148.btcentralplus.com [86.148.228.76]) by cyrus.watson.org (Postfix) with ESMTPSA id D136C46B09; Wed, 1 Jun 2011 05:43:24 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Robert Watson In-Reply-To: <5054184174934880962@unknownmsgid> Date: Wed, 1 Jun 2011 10:43:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <09CF0C54-41F7-49A8-B92C-3BEF4FBF7A36@freebsd.org> References: <8259CBF7-B2E6-49C6-A7C4-6682ECBDBB9F@freebsd.org> <5054184174934880962@unknownmsgid> To: Takuya ASADA X-Mailer: Apple Mail (2.1084) Cc: George Neville-Neil , "soc-status@freebsd.org" , Kazuya Goda Subject: Re: Weekly status report (27th May) X-BeenThere: soc-status@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Summer of Code Status Reports and Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 09:43:26 -0000 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=