From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Xen 4.4 development update: Code freezing point reached Date: Tue, 19 Nov 2013 17:52:39 +0000 Message-ID: <528BA567.1020101@eu.citrix.com> References: <20131119144026.GA5728@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20131119144026.GA5728@phenom.dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Konrad Rzeszutek Wilk Cc: zhenzhong.duan@oracle.com, "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org 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