Re: Xen 4.4 development update

["Jan Beulich" <JBeulich@suse.com>]

>>> On 20.08.13 at 11:49, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> On 08/20/2013 08:28 AM, Jan Beulich wrote:
>>>>> On 19.08.13 at 15:09, George Dunlap <george.dunlap@eu.citrix.com> wrote:
>>> I think as release cycles get shorter, we have to move into thinking
>>> more like the Linux "merge windows": you work on your feature, and when
>>> it's ready, you target it for a specific merge window.
>>
>> Which - as expressed before - I dislike.
> 
> But I don't think I ever understood the nature of your dislike -- what 
> is it you like about the longer release cycles, and/or dislike about the 
> shorter ones?

First of all, the dislike above was regarding the merge window model.
That is because I prefer the continuous flow model we got used to,
simply because it allows a more consistent work flow (both from a
developer and from a committer perspective).

As to the shorter release cycles, I'm sure I said before that I see
this problematic wrt stable tree management (resulting in either
shorter stable tree life cycles or more work due to more branches
being maintained) as well as - see above - the worse ratio
between normal development flow and a (partially/mostly) frozen
tree (after all, the merge window concept just is an extreme form
of shortened release cycles, where almost all of the release cycle
is spent in feature frozen state).

Plus to me the argument of more frequent releases allowing
smoother distro adoption doesn't really count: I would
generally expect distros to not ship unpatched versions
anyway, so if they're eager to get a certain feature out to their
users, backporting the feature is always an option.

And just to clarify - don't read into this that I may even be
advocating a significantly longer release cycle. As we learned
with 4.2, anything beyond a year is likely not going to work
out well because of too many changes accumulating.

Jan