[Xen-devel] RFC: LTS and stable release scheme

[Wei Liu <wei.liu2@xxxxxxxxxx>]

Hi all

A majority of developers express interests in trying a shorter release
cycle -- to change from 9 months to 6 months [0]. There are, however,
repercussions on how we manage stable and possible LTS releases.

I start this thread hoping it's clearer that downstream consumers like
distributions and individual packagers can voice their opinions. I've
CC'ed some people I can think of who might be interested in this topic.
Feel free to CC more people.

We don't have LTS scheme at the moment. Let me start with current
scheme for stable releases.

 - Release from xen-unstable every 9 months.
 - Maintain last 3 releases as stable releases.

So in effect, every stable release is maintained for at least 27
months.

When we switch to 6 months release cycle, if we stick with the same
scheme (last 3 releases as stable releases), every stable release is
only maintained for 18 months. It's too short for downstream
consumers.

Ian proposed a scheme [1] in reply to [0]. In short, that scheme
proposes we pick every Nth release as LTS. He also proposed N=4 in the
case of 6 months release cycle.

(FWIW I think N=4 is a sensible suggestion.)

I can think of some open questions.

1. How long should each LTS release be maintained?

Here are my two cents, there are two fundamental criteria for deciding
how long a LTS is supported: a) it can't be shorter than what we
already have (27 months); b) at any given time there must be at least
one LTS release available to downstream.

With these in mind and N=4, I would say supporting LTS for at least
2.5 years (5 release cycles) should be the minimal requirement. As for
the upper limit, I don't know. Linux has LTS supports ranging from 2.5
years to 5.5 years [2]. Another data point is Debian LTS is supported
for 5 years [3].

Steven would like to see LTS be supported for 4 year full support + 1
year security fix only [4]. I'm not sure how feasible this is with
current set of maintainers (in fact, only Jan and Ian at the
moment). But in the end there is nothing that prevents other people
from stepping up and taking over the tree. We saw that with Xen 3.4
already.

2. What to do with the non-LTS releases?

I think they should still be considered stable releases for some
time. I'm just not sure for how long they should receive updates. One
way of looking at them is to use the same concept as Linux -- they
receive updates until next stable kernel is out. We can tweak this, of
course.

3. How to make maintenance effort scale?

Depending on how long each LTS and stable release is supported, at any
given time the number of trees may vary. It might be necessary to have
more stable tree maintainers to share the burden.

The current model for requesting backports is designed for single
maintainer for multiple trees. There are two ways to request
backports, one is to reply to Jan's preparation poll email, the other
is to embed backport request in patches. My personal experience is
that backport request via second way falls through the crack
sometimes, and as a *developer* I don't normally keep track of whether
the patches I requested ends up in stable trees.

Luckily I do see technical and procedural solution this is issue -- we
can setup stable@ alias to keep track of requests [5]. With that all
backport requests embedded in patches won't get lost. Downstream
consumers can also benefit from this because they then easily know
which patches are backport candidates.

We may also want to create aliases for LTS maintenance teams if there
are such teams.

Feel free to add more items and comments are welcome!

Wei.

[0]: <20151002174356.GA3577@xxxxxxxxxxxxxxxxxxxxx>
[1]: <1444045497.11707.195.camel@xxxxxxxxxx>
[2]: https://www.kernel.org/category/releases.html
[3]: https://wiki.debian.org/LTS
[4]: <5612794E.8090700@xxxxxxxxx>
[5]: <20151005125233.GD29124@xxxxxxxxxxxxxxxxxxxxx>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel