From: George Dunlap <george.dunlap@eu.citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: zhenzhong.duan@oracle.com,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: Xen 4.4 development update: Code freezing point reached
Date: Tue, 19 Nov 2013 17:52:39 +0000 [thread overview]
Message-ID: <528BA567.1020101@eu.citrix.com> (raw)
In-Reply-To: <20131119144026.GA5728@phenom.dumpdata.com>
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
next prev parent reply other threads:[~2013-11-19 17:52 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-18 18:19 Xen 4.4 development update: Code freezing point reached George Dunlap
2013-11-18 18:52 ` Dario Faggioli
2013-11-18 19:22 ` Pasi Kärkkäinen
2013-11-19 16:18 ` George Dunlap
2013-11-19 0:59 ` Don Slutz
2013-11-19 17:46 ` George Dunlap
2013-11-19 10:50 ` Roger Pau Monné
2013-11-19 11:06 ` George Dunlap
2013-11-19 11:31 ` Roger Pau Monné
2013-11-19 14:00 ` Ian Campbell
2013-11-19 14:40 ` Konrad Rzeszutek Wilk
2013-11-19 14:54 ` Jan Beulich
2013-11-19 15:11 ` Konrad Rzeszutek Wilk
2013-11-19 17:52 ` George Dunlap [this message]
2013-11-19 19:40 ` Konrad Rzeszutek Wilk
2013-11-20 3:17 ` Zhenzhong Duan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=528BA567.1020101@eu.citrix.com \
--to=george.dunlap@eu.citrix.com \
--cc=konrad.wilk@oracle.com \
--cc=xen-devel@lists.xen.org \
--cc=zhenzhong.duan@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.