Re: Xen 4.4 development update: Code freezing point reached

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Tue, Nov 19, 2013 at 05:52:39PM +0000, George Dunlap wrote:
> 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:
> >>  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
> >http://article.gmane.org/gmane.comp.emulators.xen.devel/178043)
> >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

No idea what it is marked as. You have to use 'tmem=1' to actually
enable it - so it is no by default enabled.
> touches tmem code, it should be OK until fairly late.

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

Will do.