Re: [Xen-devel] Xen 4.5 development update (September update). Feature freeze slip by two weeks.

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 10 Sep 2014, konrad.wilk@xxxxxxxxxx wrote:
> The feature freeze has moved by two weeks. That means it is scheduled
> to be on September 24th.
> 
> If you think you will need a feature freeze exception, read below.
> 
> In terms of Linux I am keeping the 'fair' ones as by the Xen 4.6 release
> it could be v3.19, which means there is still an upcoming merge window
> for those.
> 
> The "prognosis" is now the likelihood of completion in the 4.5 timeframe.
> A bunch of items had moved to the completed phase which is fantastic.
> 
> none - nothing yet
> fair - still working on it, patches are prototypes or RFC
> ok   - patches posted, acting on review
> good - some last minute pieces
> done - all done, might have bugs
> 
> For items involving code hosted on the Xen.org site (including qemu-xen),
> that means a likelihood of having the feature code-complete and mostly
> working by the feature freeze.  (It's OK if there are still bugs to be
> worked out.)  For items in Linux, it would mean having items on track
> to make it into the kernel released just after the scheduled 4.5 time frame.
> 
> In terms of libvirt it has monthly releases. As such not going to track
> every release - but closer to when RCs are out.
> 
> = Timeline =
> 
> We are planning on a 9-month release cycle.  Based on that, below are
> our estimated dates:
> 
> 
> * Feature Freeze: 24th September 2014
> * First RC: 15th October
> * Release: 10th December 2014
> 
> The RCs and release will of course depend on stability and bugs, and
> will therefore be fairly unpredictable.  The feature freeze may be
> slipped for especially important features which are near completion.
> 
> If you think your patchset MUST go in Xen 4.5 I will post the procedure
> for requesting an exception to get them in past the feature freeze next
> week.
> 
> = Prognosis =
> 
> The states are: none -> fair -> ok -> good -> done
> 
> none - nothing yet
> fair - still working on it, patches are prototypes or RFC
> ok   - patches posted, acting on review
> good - some last minute pieces
> done - all done, might have bugs
> 
> = Feature freeze exception =
> 
> When we get to September 24th, the code "freezing point" will commence;
> which means that starting on that day non-bug fixes need a freeze exception
> to be included.
> 
> Remember our goal for the release:
>   1. A bug-free release
>   2. An awesome release
>   3. An on-time release
> 
> Accepting a new feature may make Xen more awesome; but it also
> introduces a risk that it will introduce more bugs.  That bug may be
> found before the release (threatening #3), or it may not be found
> until after the release (threatening #1).  Each freeze exception
> request will attempt to balance the benefits (how awesome the
> exception is) vs the risks (will it cause the release to slip, or
> worse, cause a bug which goes un-noticed into the final release).
> 
> The idea is that today we will be pretty permissive, but that we will
> become progressively more conservative until the first RC, which is
> scheduled for 3 weeks' time (October 15).  After that, we will only
> accept bug fixes.
> 
> Bug fixes can be checked in without a freeze exception throughout the
> code freeze, unless the maintainer thinks they are particularly high
> risk.  In later RC's, we may even begin rejecting bug fixes if the
> broken functionality is small and the risk to other functionality is
> high.
> 
> Features which are currently marked "experimental" or do not at the
> moment work at all cannot be broken really; so changes to code only
> used by those features should be able to get a freeze exception
> easily.
> 
> Features which change or add new interfaces which will need to be
> supported in a backwards-compatible way (for instance, vNUMA) will
> need freeze exceptions to make sure that the interface itself has
> enough time to be considered stable.
> 
> These are guidelines and principles to give you an idea where we're
> coming from; if you think there's a good reason why making an
> exception for you will help us achieve goals 1-3 above better than not
> doing so, feel free to make your case.
> 
> = Open =
> 
> == ARM == 
> 
> *  ARM Xen UEFI booting on ARM (fair/ok)
>    v4
>   -  Roy Franz
> 
> *  ARM GICv3 support (ok)
>    v10 posted
>   -  Vijay Kilari
> 
> *  ARM - VGIC emulation (ok)
>    Reposted as gic and vgic fixes and improvements
>    v12
>   -  Stefano Stabellini
> 
> *  ARM - Add Odroid-XU (Exynos5410) support (ok)
>    v6
>   -  Suriyan Ramasami
> 
> *  ARM implement mem_access (ok)
>    v5
>    https://github.com/tklengyel/xen/tree/arm_memaccess5
>   -  Tamas K Lengyel

QEMU userspace PV backends on ARM fell off the list:

http://marc.info/?l=xen-devel&m=140690717224942

I think it is still good for 4.5. IanJ what do you think?

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