From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Xen 4.3 development update Date: Thu, 11 Apr 2013 10:43:31 +0100 Message-ID: <516685C3.9070209@eu.citrix.com> References: <20130410164155.GB6946@phenom.dumpdata.com> <5166822D.90506@eu.citrix.com> <1365672828.8036.31.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1365672828.8036.31.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org On 11/04/13 10:33, Ian Campbell wrote: > On Thu, 2013-04-11 at 10:28 +0100, George Dunlap wrote: >> On 10/04/13 17:41, Konrad Rzeszutek Wilk wrote: >>>> = Timeline = >>>> >>>> We are planning on a 9-month release cycle. Based on that, below are >>>> our estimated dates: >>>> * Feature freeze: 25 March 2013 >>>> * Code freezing point: 15 April 2013 >>> Is it possible to extend this? One of the reviewers (Ian) is just >>> now able to look at code and review. That means the developers have >>> only 3 business days to repost the changes. >> So when I said "freezing point", I meant, "we will start rejecting >> features". Each feature will need to be considered individually. I >> think, for example, that PVH is not going to make it -- it touches too >> much code, and is just not in good enough shape to get in as it is. But >> AFAICT the TMEM stuff should be fine next week. >> >> IanC knows that he's on the hot path, and so will be working double-time >> over the next few days to review / commit patches. > FWIW for the tmem stuff specifically IanJ seems to have a handle on the > review so it's not high in my queue. > >> We had a talk yesterday about the Linux stubdomain stuff -- that's a bit >> less clear. Changes to libxl should be in "linux-stubdom-only" paths, >> so little risk of breaking libxl functionality. On the other hand, it >> makes a lot of changes to the build system, adding moderate risk to an >> important component; and it hasn't had wide public testing yet, so >> there's no telling how reliable it will be. On the other other hand, >> it's a blocker for being able to switch to qemu-upstream by default, >> which was one of our key goals for 4.3; that may or may not be worth >> risking slipping the release a bit for. > I think we switched the default for the non-stubdom case already (or > were planning too!). I think this is sufficient for 4.3. I've been thinking about this -- wouldn't this mean that if you do the "default" thing and just install a Windows guest in an HVM domain (not thinking about qemu or whatever), that now I"m stuck and I *can't* use stubdoms (because Windows doesn't like the hardware changing that much under its feet)? That doesn't sound like a very good user experience to me. -George