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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.