xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).