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

[manish jaggi <manishjaggi.oss@xxxxxxxxx>]

What about PCI passthrough, is it targeted for 4.6 ?

On 11 September 2014 23:17, Stefano Stabellini
<stefano.stabellini@xxxxxxxxxxxxx> wrote:
> 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

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