[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 11/19/2013 02:40 PM, Konrad Rzeszutek Wilk wrote:
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:

(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

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

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)?

But it's still marked "experimental", right? As long as it only touches tmem code, it should be OK until fairly late.

== 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

Cool, let me know when it's in.

* 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.

I've moved it to the "completed" section.


Xen-devel mailing list



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