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

Re: [Xen-devel] Xen 4.4 development update: Code freezing point reached

On Mon, Nov 18, 2013 at 06:19:46PM +0000, George Dunlap wrote:
> This information will be mirrored on the Xen 4.4 Roadmap wiki page:
>  http://wiki.xen.org/wiki/Xen_Roadmap/4.4
> (And I actually updated the wiki this time.)
> The code "freezing point" is today; which means that starting today
> 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 (6 December).  After that, we will only
> accept bug fixes.
> Bug fixes can be checked in without a freeze exception throughout the
> code freeze, unless the maintianer 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.  (Tianocore is something which would probably fall under
> this.)
> 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.

I am wondering in which category the tmem cleanup patches fall?

They aren't bug-fixes, they could be considered a feature. They were
posted before the deadline. I posted the GIT PULL (see
to one of the folks who has write access to the repository (as
documented in http://www.xenproject.org/governance.html)?

> == Open ==
> * qemu-upstream not freeing pirq
>  > http://www.gossamer-threads.com/lists/xen/devel/281498
>  status: patches posted; latest patches need testing

Duan, ping?

> * Race in PV shutdown between tool detection and shutdown watch
>  > http://www.gossamer-threads.com/lists/xen/devel/282467
>  > Nothing to do with ACPI
>  status: Patches posted

I think I am going to slurp that one for v3.13-rc1

> * xend still in tree (x)
>  - xl list -l on a dom0-only system
>  - xl list -l doesn't contain tty console port
>  - xl Alternate transport support for migration*
>  - xl PVSCSI support
>  - xl PVUSB support

Add this one please:
  -xl needs to disallow PoD with PCI passthrough

I believe some of these were tacked by Wei - but he has
been doing other things. And I am busy right now tackling

> * SWIOTLB (kernel side thing)
>   owner: Stefano
>   status: Pull request sent.

In v3.13.

> * Disk: indirect descriptors
>    owner: roger@citrix
>    status: Linux side in 3.11, Xen-side patch posted

I think you can drop this from your list.

Xen-devel mailing list



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