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

[Ben Guthro <ben@xxxxxxxxxx>]

On Thu, Jun 13, 2013 at 10:00 AM, Lars Kurth <lars.kurth@xxxxxxx> wrote:
> 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
>

Did you have any more info on this bullet, and the other one below Re:
XenClient / VirtualComputer?

FWIW, the XenClient Enterprise product (what was VirtualComputer
NxTop) doesn't currently do PCI / VGA passthrough, in an attempt to
get a larger HCL.
The XenClient XT product (developed primarily in Citrix Cambridge)
does rely on this functionality, however.

It is a subtle (but sizable) architectural difference, that made each
team come to some different conclusions when solving similar problems.
As such, this is an area that the two teams have remained separate,
despite sharing a XenClient moniker.

There may be some areas that we may be able to help out, but we'd need
to enumerate the issues, and work with management to get it properly
staffed - naturally balancing against the product delivery
requirements.


> ** 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

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