Re: [Xen-devel] Xen 4.3 development update

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel