[Hackathon Minutes] Xen 4.4 Planning

[Lars Kurth <lars.kurth@xen.org>]

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)?