From: George Dunlap <george.dunlap@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>, xen-devel@lists.xenproject.org
Cc: jgross@suse.com, Lars Kurth <lars.kurth@citrix.com>,
netwiz@crc.id.au, Ian Campbell <ian.campbell@citrix.com>,
George Dunlap <george.dunlap@eu.citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Ian Jackson <Ian.Jackson@eu.citrix.com>,
Jan Beulich <JBeulich@suse.com>,
cardoe@cardoe.com
Subject: Re: RFC: LTS and stable release scheme
Date: Tue, 6 Oct 2015 13:57:26 +0100 [thread overview]
Message-ID: <5613C536.9030104@citrix.com> (raw)
In-Reply-To: <20151006110758.GV29124@zion.uk.xensource.com>
On 06/10/15 12:07, Wei Liu wrote:
> 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.
Could we just keep the same general scheme of "maintain 3 releases"?
If the most recent release was *not* an LTS, we'd have one release + 2
LTSes. If the most recent release *was* an LTS, we'd have 3 LTSes --
the last one supported until a non-LTS release came out. If LTSes
happen every 4 releases, then we'd get an LTS release every 2 years,
giving is 4.5 years support (54 months).
-George
next prev parent reply other threads:[~2015-10-06 12:57 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-06 11:07 RFC: LTS and stable release scheme Wei Liu
2015-10-06 12:57 ` George Dunlap [this message]
2015-10-06 13:10 ` Ian Campbell
2015-10-06 16:25 ` Wei Liu
2015-10-06 16:30 ` Ian Campbell
2015-10-06 13:15 ` Wei Liu
2015-10-06 13:38 ` Jan Beulich
2015-10-06 14:09 ` Wei Liu
2015-10-06 14:52 ` Jan Beulich
2015-10-06 15:01 ` Wei Liu
2015-10-07 17:45 ` George Dunlap
2015-10-08 8:05 ` Jan Beulich
2015-10-08 10:39 ` George Dunlap
2015-10-08 11:48 ` Jan Beulich
2015-10-08 10:59 ` Ian Jackson
2015-10-08 11:34 ` Jan Beulich
[not found] ` <561670CD02000078000A94AA@suse.com>
2015-10-08 11:49 ` Juergen Gross
2015-10-08 12:22 ` Jan Beulich
[not found] ` <56167C0802000078000A953E@suse.com>
2015-10-08 12:39 ` Juergen Gross
2015-10-08 13:52 ` Wei Liu
2015-10-08 11:10 ` Wei Liu
2015-10-08 12:13 ` Jan Beulich
2015-10-08 14:23 ` Wei Liu
2015-10-08 15:01 ` Jan Beulich
2015-10-08 11:10 ` George Dunlap
2015-10-06 14:12 ` George Dunlap
2015-10-06 14:49 ` Jan Beulich
2015-10-07 17:56 ` George Dunlap
2015-10-08 8:15 ` Jan Beulich
2015-10-06 15:27 ` Dario Faggioli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5613C536.9030104@citrix.com \
--to=george.dunlap@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=cardoe@cardoe.com \
--cc=george.dunlap@eu.citrix.com \
--cc=ian.campbell@citrix.com \
--cc=jgross@suse.com \
--cc=lars.kurth@citrix.com \
--cc=netwiz@crc.id.au \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).