[CRIU] CRIU release schedule proposal

[Serge Hallyn]

Quoting Pavel Emelyanov (xemul at parallels.com):
> 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
> 

Sounds excellent to me!