[CRIU] CRIU release schedule proposal

[Pavel Emelyanov]

On 09/02/2014 05:52 PM, Serge Hallyn wrote:
> Quoting Kir Kolyshkin (kir at openvz.org):
>> Pavel,
>>
>> You asked me to share my view on how to produce CRIU releases.
>>
>> Basically there can be two strategies: feature-driven and time-driven.
>> Most software projects that don't do a lot of planning make feature-driven
>> releases, and it seems natural and logical. But there are a few bad things
>> about it, which can be brought down to these two things:
>>
>> 1. Next release time is not predictable by users. It can happen in a week,
>> in a month, or in a year.
>>
>> 2. A release can be delayed for a long time because a new feature
>> might seem not polished enough.
>>
>> CRIU release process was free of such deficiencies because its releases
>> were tied to appropriate kernel releases adding new features needed
>> for CRIU.
>>
>> As this is no longer the case, there's no reason to be tied to
>> kernel releases,
>> but there is a need to have some other scheme.
>>
>> My simple suggestion is to target for 3-4 releases a year, in other words,
>> having a "relaxed quarterly" release schedule -- plan for a release each 3
>> months, but it's OK if a release will be delayed by up to a month.
>>
>> Another thing I'd like to add. From my experience, rc releases make little
>> sense, as no one uses those. What makes sense is hotfixes -- once you
>> made a release, you should be ready to fix regressions and critical bugs
>> quickly, and to release a hot fix update within days if needed. Again,
>> nothing new here, this is essentially a model used by the Linux kernel
>> (although you don't have to support older releases for now, I guess,
>> just a latest one).
>>
>> Hope that makes sense.
> 
> Hi,
> 
> I'm not a project manager, so you might want to ignore my input, but
> I've been around the block, and I've been very positively impressed by
> the Ubuntu release process, so wanted to just provide a slight
> alternative:  As you said, 3-4 releases a year, but with very strict (to
> the day) deadlines.  For a period of time before the release, a feature
> freeze.  For a maybe a week before the release, a complete freeze for
> all but critical bug-fixes.  Then as you say, after release take a few
> hot fix updates (only) to the release, while opening up to the new
> development release.
> 
> I know one could argue that "delays up to a month" have worked for the
> kernel community, but frankly I don't think they do really work, and it's
> more that they get away with it because, well, it's the kernel.  The
> kernel releases become unreliable, and planning on a kernel to include
> and test in a distro becomes a black art.  It would be awesome if criu
> release could be more reliable.  As other examples, I love the
> reliability of (recent) libvirt releases - always the first week of the
> month, and I'd prefer for lxc release to be much stricter.
> 
> my 2c.

Thanks for the info, Kir and Serge! I think I've got the point.


I like the idea of strictly-planned releases, so let's try to go with 4 
releases per-year. This fits well with having autumn, winter, spring and
summer ones :) Not to clash with popular holidays it's worth doing them
in the beginning of Sep, Dec, Mar and Jun, and to make sure we don't hit
weekends and Fridays, let's stick to the 1st Monday of the month.

Thus for the nearest releases we'll have dates

1.4  --  1 Dec 2014
1.5  --  2 Mar 2015
1.6  --  1 Jun 2015
1.7  --  7 Sep 2015
1.8  --  7 Dec 2015

Feature freeze is also great thing. Let's define one to be about 2 weeks
before release. Exact date would depend on the amount of problems we'll
see while things go.


As far as stable releases are concerned. It looks like all current users
of CRIU (not much :) ) are fine with waiting for the next stable one. So
I propose to postpone this question for now.

Thanks,
Pavel