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

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

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 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
>     (see 
> http://xen.1045712.n5.nabble.com/PATCH-VT-d-Dis-allow-PCI-device-assignment-if-PoD-is-enabled-td2547788.html)
Done.

> I believe some of these were tacked by Wei - but he has
> been doing other things. And I am busy right now tackling
> bugs.
>
> > * SWIOTLB (kernel side thing)
> >    owner: Stefano
> >    status: Pull request sent.
> In v3.13.
Sweet!

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

Thanks!
 -George

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