[CRIU] [RFC] Future CRIU releases

[Saied Kazemi]

On Fri, Dec 18, 2015 at 10:12 AM, Pavel Emelyanov <xemul at parallels.com>
wrote:

> On 12/18/2015 08:43 PM, Saied Kazemi wrote:
> > On Fri, Dec 18, 2015 at 9:05 AM, Pavel Emelyanov <xemul at parallels.com
> <mailto:xemul at parallels.com>> wrote:
> >
> >     On 12/17/2015 09:18 PM, Saied Kazemi wrote:
> >     > I also agree that having fixed dates for stable releases is good
> and we
> >     > should continue doing it.
> >
> >     OK :)
> >
> >     > Regarding faster access to newly implemented features, how about a
> separate
> >     > "channel" called beta or dev that releases weekly (or at will)?
> New features
> >     > are introduced in this channel and, after they've been qualified
> for a few
> >     > weeks, move to the stable channel.  This is like what OS distros
> such as
> >     > CoreOS do (they actually have three channels: alpha, beta, stable;
> visit
> >     > https://coreos.com/releases/).
> >
> >     Hm... Do you know whether they do those releases from one repo, or
> constantly
> >     move only the good stuff from alfa to beta and then to stable?
> >
> >
> > I'm pretty sure all releases come from the same repo, but different
> branches.  New
> > features are committed to master and then cherry picked onto alpha,
> beta, and stable.
>
> Ah, I see. My question was whether they just tag master branch with next
> alfa/bete
> release and after stabilization period tag the stable one, but now it's
> clear that
> they migrate features between branches.
>
> > Does a two-branch scheme (dev and stable) work for CRIU?
>
> That's a good question which I'm trying to figure out :) So far I've seen
> that it
> was not that easy to distinguish one feature from another in terms of
> commit IDs,
> so cherry-picking a feature from master/dev branch into stable one would
> be quite
> a challenge.
>
> Back-porting the tempting stuff from HEAD to "v1.${latest}-stable" branch
> could be
> done with the help of feature owner, though.
>

I'm not a release engineering expert, so this is just a suggestion.  There
are two ways to go.  One would be to create the dev and stable branches,
keep them forever, cherry pick onto them, and tag milestones in those
branches.  The other would be to create a dev branch that gets promoted
(renamed) to the stable branch after qualification period.  The old stable
branch can be deleted or renamed and frozen.

This way you'd minimize the task of cherry picking because each time you
create a new dev branch from master, it includes all the commits up to that
point.  Cherry picking onto the stable branch should generally be avoided
unless there is a major security patch.

--Saied
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20151218/4f9e8868/attachment.html>