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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2013-06-13 at 15:00 +0100, Lars Kurth wrote:
> == 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)

If we do end up going for this model then I think we need to also
inherit the principal from Linux that the merge window is for *merging*
and that the code in question should have already been posted and
reviewed *before* the window opens (i.e. in the other 3 months of the
cycle). 

This would be something of a cultural change because at the minute
people seem to assume that a freeze means that development and review
must stop. Personally I don't think that should be the case anyway,
although I appreciate the need to focus peoples attention on the release
as well.

This could end up with subsystem maintainers queueing patches into their
own tree for merge into mainline during the window (this is what Linux
does). This has its own downsides WRT the merging work during window and
there would need to be a change since we would also have to ask people
to test those trees, which they aren't used to doing.

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

Largely due to Linux having the properties I described above, IMHO.
Although I'm not a Linux maintainer of a large subsystem so what would I
know ;-)

>  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

staging is simply the pre-test branch, I don't think it can serve as a
buffer of the type you seem to be suggesting.

We could encourage people to make more use of personal git trees,
including maintainers. 

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

I think this is simply a normal part of the "train leaves the station"
model. There will always be stuff which misses, but then there is always
the next train, and the one after that.

To some extent I'm not sure how useful it is with the train model to try
and enumerate in advance the things which are going to be in a
particular release .

A list of things which people are working on and their current *target*
release seems more useful, with the knowledge that the targets can and
will change, probably more often than not for bigger items.

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

I would say "submit well in advance of 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.

You have an extra "not" in there.

I consider the "badger and resend" as more of a fallback/backstop rather
than an intentional part of the workflow.

For my own part I do keep an explicit queue of mails containing patches
and I don't think I tend to miss many due to them simply falling through
the cracks, even during busts of activity. That's not to say I always
manage to process the queue in a timely manner though.

That said a little bit of badgering has the secondary effect of
reminding me that I need to look at the patch in my queue as well as the
primary affect of me enqueuing something I may have missed.

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

That's right, we usually fork around the late RCs when we are reaching
the end game.

> [Note] We don't actually have a list of patches that got lost in the 4.3 
> release cycle )-:

If they were on a list they by definition wouldn't be lost ;-)

FWIW I do have a separate queue of mails with patches which were
deferred to 4.4 (but only for stuff that I would have committed myself
had the tree not been frozen).

Ian.


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