[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xen 4.3 development update

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.

* First RC: 6 May 2013
* Release: 17 June 2013

The RCs and release will of course depend on stability and bugs, and
will therefore be fairly unpredictable.  Each new feature will be
considered on a case-by-case basis; but the general rule will be as

* Between feature freeze and code freeze, only features which have had
a v1 posted before the feature freeze, or are on this list, will be
considered for inclusion.

* Between the "code freezing point" and the first RC, any new code
will need to be justified, and it will become progressively more
difficult to get non-bugfix patches accepted.  Critera will include
I am hoping you explain what is meant by 'new code'. Say a patchset is
being posted where only one of the patches is being modified by the
reviewer (case a). Or the reviewers would like new code to be written to
handle a different case (so new code - case b).

The case b) would fall in 'new code will need to be justified'.. But if
the new code does not meet the criteria is the full patchset going to
languish to the next window? Or can parts of it that pass the reviewer's
muster be committed?

The case a) I would think would not be a problem.

I mean "code that does new things", as opposed to code that fixes bugs. Any code that is not already in xen.git and is not fixing a bug is "new code", whether it was posted yesterday or 6 months ago.

The point is that every new bit of functionality introduces the risk of bugs; and each additional bug at this point will risk slipping the release date. So for each new bit of code, we will have to do a risk analysis. Criteria will include:
* Risk of the code having bugs in itself
* Risk of the code introducing bugs in other key functionality
* Cost of bugs
* Value of the new code

The tmem toolstack stuff, for instance, if I understand correctly, is mostly about paths that only tmem users use. If you're not using tmem, the risk of having a bug should be low; and the cost of fixing toolstack bugs in a point release should also be low. So I would think that sometime next week would be fine.

PVH stuff, however, touches a lot of core hypervisor code in really quirky ways. It has a very high risk of introducing bugs in other bits of functionality, which would have a very high cost. Also, since it has a fairly high risk of still being immature itself, we couldn't really recommend that people use it in 4.3; and thus it has low value as a release feature at this point. (Hope that makes sense -- as a mature feature, it's really important; but as a "tech preview only" feature it's not much overall value to customers.) So I doubt that PVH will get in.

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.

Does that give you an idea of what the criteria are and how I'm going to be applying them?

Basically, my job at this point is to make sure that the release only slips:
1. On purpose, because we've considered the benefit worth the cost.
2. Because of completely unforseeable circumstances

If I ACK a patch, thinking that it won't slip, and then it does, and I might reasonably have known that that was a risk, then I have... well, "failed" is kind of a strong word, but yeah, I haven't done the job as well as I should have done. :-)

Does that make sense?

the size of the patch, the importance of the codepath, whether it's
new functionality being added or existing functionality being changed,
and so on.
Sorry about asking these questions - but I am being increasingly pressed
to fix upstream bugs, upstream new material for v3.10, upstream the claim
toolstack changes, and also go on vacation. Hence I am trying to figure out
what I need to focus on to meet these deadlines.

Sure. What patches do you have outstanding, BTW? There's the tmem stuff; the PVH stuff as I said seems pretty unlikely to make it (unless there's an amazing patch series posted in the next day or two). Is there anything else you'd like my opinion on?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.