[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [Hackathon Minutes] Xen 4.4 Planning



This took me a while to post, but given that we are not starting 4.4 just yet, this may be appropriate now. I may have misrepresented some stuff as it has been 4 weeks since I wrote these.
Cheers
Lars

= Purpose of Roadmap =
* Set a vision for interesting features
* Track items
* Help consumers of Xen with their planning

= Release Models that work well =
There was a brief discussion on two different release models
* Train leaves the station (Linux)
* Release when ready (Debian)

== Stefano's Proposal ==
We should aim to reduce the release cycle to 4 months (or maybe 6 months as an intermediate step) from the current 9 months. A 4 months relase cycle should help accelerate development and lead to fewer patches being queued up. The implications are that we would have to operate a 2-3 weeks merge window.

To do this, we would need to resolve a number of issues
* It is likely that code reviews for such a short merge window would become a bottleneck. We are not sure whether this would be a major issue : the review bandwith would depend on the patches submitted (and their complexity) * [I can't remember who raised this] The concern was raised that we would not have enough x86 Xen reviewers got a 2-3 weeks merge window * [Konrad] Stated that in PVOPS for Linux contributions we don't have a review bottleneck, but we should make sure that the Xen and PVOPS/Linux merge window don't overlap (as this would require the same set of people to review patches in two projects) * The rest of the time (approx 3 months) would be used for stabilizing the release * If we had a more extensive testing framework, and thus better testing, we could tighten the RC period (making this happen is also being discussed by the Advisory Board)

Additional conerns raised:
* [Matt Wilson]: if we had shorter merge windows, there is a risk that we would end up with unnused code (uncompleted features) in mainline. Something which we'd rather not have * [I can't remember who raised this] But we already have a buffer via staging : we could make more use of this

[Conclusion] We aLL agreed, that a release cycle of less than 9 months is desirable. Maybe we can go to 6 months for Xen 4.4 (before being more aggressive).

= 4.3 Release cycle : what worked well / didn't work well =
* The 4.3 release updates and criteria went well
* BUT :  50% of what was supposed to be in 4.3 didn't make it
** In some cases, we simply underestimated the effort that is needed. Concrete example : QEMU/stubdomain was a combination of under-estimating the size and over-estimating the development bandwidth that was available ** Some of the high-impact features (e.g. PVH) came in too late in the dev cycle. Mitigation : break contributions into smaller parts and submit earlier in the merge window. The same applies to changes to generic code. * BUT : Some patches were lost (i.e. when there are spikes of activity it becomes hard for some maintainers/committers to keep on top of their queue). ** [Ian Campell] said that we should rely on submitter to resend the patch: the assumption is that if the patch is not important, the submitter will badger and resend. ** [Lars] raised the point that this can alienate contributors and get them to look at other projects instead. ** [Can't remember who said this] Maybe use patchwork (http://jk.ozlabs.org/projects/patchwork/) to track patches ** [Ian Campbell]: patchwork looks like a good idea, but may not work well in practice [Note] We should probably have a discussion or some sort of trial. It may also be possible to use the http://bugs.xenproject.org prototype (or add a "deferred patch" attribute) [Note] We typically start opening the dev branch at RC5/6 (not sure I quite got this) [Note] We don't actually have a list of patches that got lost in the 4.3 release cycle )-:

[ACTION]: George write up a proposal for the beginning of the 4.4 release cycle

= 4.4 Content =
George volunteers to be the Release co-ordinator for Xen 4.4 (to apply what he learned)

* Big features that did not make it in 4.3

* PVH? What will make it into 4.4

* Missed patches (don't have a list)

* "User" features that look interesting

** Network effects

** We shouldn't have broken feature

** What about XenClient / VirtualComputer being able to help out in adding mopre support for PCI / VGA cards

** Other features: Sharing dom0 keyboard / mouse


* GPU passthrough
** We have an issue with graphics card support
** A lot of users care about GPU passthrough (but not many vendors)
** Maybe we could mentor somebody about GPU passthrough?

** Maybe we could get XenClient, VirtualComputer or Qubes to pick this up (or partly do so)?



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.