[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
Lists.xenproject.org is hosted with RackSpace, monitoring our