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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Thu, Jun 13, 2013 at 03:31:27PM +0100, Ian Campbell wrote:
> 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). 

Which would imply that if we use this for Xen 4.4, we would have 
almost no patches ready :-)

That would be a painless release - just fixing the carryover bugs
from Xen 4.3.

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

That in the Linux ecosystem was solved with the linux-next which would
take all of the subsystems's tree.

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

This is also b/c of the down-time - those three months can be used
to thrash out bugs and be pedantic about peoples patches. A nice Linux release
is when at rc1 there are no regressions that I know of and I can concentrate
on developing a feature or clear some of my backlog.

But that would imply that the maintainer (release maintainer?) of Xen would 
now be primarily responsible for chasing down folks to fix bugs.

And if one does not have bugs, then there are nice three months to develop
that killer feature.

But that does not solve the problem of various bugs that exists or
are detected by users and chasing those down. They unfortunatly take
more time to troubleshoot and figure out than I personally would like.

Perhaps the way to think about this is what we need to make sure
works 100% between releases. There are a lot of pieces in it.

I appreciate very much that there are folks who are willing to test it out
during that time, report and bear with us trying to figure what got
broken.

But it would also help to have a regression test. I am very excited
about the 'extensive testing framework', but it is not ready yet.

The osstest is pretty awesome too - is there other things we can add
in to the testing framework to be able to do more of the regression tests?
More OS-es?


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