xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
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

  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).