[CRIU] CRIU release schedule proposal

[Serge Hallyn]

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,
-serge