From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: xen patches are in 2.6.37 Date: Fri, 29 Oct 2010 09:49:57 -0700 Message-ID: <4CCAFB35.6030505@goop.org> References: <20101029094641.GL2804@reaktio.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20101029094641.GL2804@reaktio.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= Cc: xen-devel@lists.xensource.com, M A Young List-Id: xen-devel@lists.xenproject.org On 10/29/2010 02:46 AM, Pasi K=E4rkk=E4inen wrote: > On Fri, Oct 29, 2010 at 08:36:54AM +0100, M A Young wrote: >> Linus has merged branch 'stable/xen-pcifront-0.8.2' of =20 >> git://git./linux/kernel/git/konrad/xen >> and branch 'for-linus' of =20 >> git://xenbits.xen.org/people/sstabellini/linux-pvhvm at >> http://git.kernel.org/?p=3Dlinux/kernel/git/stable/linux-2.6-stable.gi= t;a=3Dcommit;h=3D18cb657ca1bafe635f368346a1676fb04c512edf >> > Congratulations to everyone involved!! Great job. > > So what's the next step for dom0 upstreaming? backend drivers?=20 Yes, we need to come up with a set of backends that are upstreamable. There's also a bunch of auxillary things like ACPI power management, CPU hotplug, etc which need to be adapted and put through the upstreaming wringer. My thoughts about development from now are: Main Xen development will migrate to the (newly created) xen/next-2.6.37 branch. At the moment this is more or less exactly upstream, with a couple of little fixes added. xen/next-2.6.32 (=3D xen/stable-2.6.32.x) will move to a more maintenance state. They'll be maintained for as long as kernel.org maintains 2.6.32, but the bar for including patches will be higher (definitely bugfixes, new features if they're not too intrusive, etc). Therefore the development model will tend towards developing on current kernels and backporting where necessary, rather than working on old kernels and forward-porting. J