qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: John Snow <jsnow@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: "Fam Zheng" <fam@euphon.net>, "Kevin Wolf" <kwolf@redhat.com>,
	"Daniel P. Berrange" <berrange@redhat.com>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>,
	qemu-devel@nongnu.org, "Cleber Rosa" <crosa@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: Debian support lifetime (was Re: [PATCH] docker: move tests from python2 to python3)
Date: Mon, 23 Sep 2019 17:32:44 -0400	[thread overview]
Message-ID: <0f7e2e17-73cd-5c44-f758-00d4d1156a58@redhat.com> (raw)
In-Reply-To: <20190923190533.GR5035@habkost.net>



On 9/23/19 3:05 PM, Eduardo Habkost wrote:
> On Mon, Sep 23, 2019 at 01:19:41PM -0400, John Snow wrote:
>> On 9/23/19 10:50 AM, Cleber Rosa wrote:
> [...]
>>>> diff --git a/tests/docker/dockerfiles/debian-xtensa-cross.docker b/tests/docker/dockerfiles/debian-xtensa-cross.docker
>>>> index b9c2e2e531..e6f93f65ee 100644
>>>> --- a/tests/docker/dockerfiles/debian-xtensa-cross.docker
>>>> +++ b/tests/docker/dockerfiles/debian-xtensa-cross.docker
>>>> @@ -18,7 +18,7 @@ RUN apt-get update && \
>>>>          flex \
>>>>          gettext \
>>>>          git \
>>>> -        python-minimal
>>>> +        python3-minimal
>>>
>>> I'm getting Python 3.5.3-1+deb9u1 here, so it LGTM.
>>>
>>
>> Oh, that's actually a bit of a problem. I tested on 3.5+, but I think
>> some people want 3.6+.
>>
>> I don't know much about Debian, but we either need to guarantee 3.6+ or
>> backtrack our plans to 3.5+.
> 
> Good catch.  I forgot we were going to keep 3.5 support because
> of Debian 9.
> 
> Now, I'd like to clarify what the wording on our supported build
> platforms documentation is supposed to mean for Debian.
> 
> The document says:
> 
> ] For distributions with frequent, short-lifetime releases, the project will
> ] aim to support all versions that are not end of life by their respective
> ] vendors. For the purposes of identifying supported software versions, the
> ] project will look at Fedora, Ubuntu, and openSUSE distros. Other short-
> ] lifetime distros will be assumed to ship similar software versions.
> ] 

Fedora has a release every 6-9 months, and averages a support lifetime
of a little over a year, and never more than two years.

Debian releases once every two years since 2005, and has a support cycle
that averages about 3 years. (Notably, this means a release reaches EOL
one year after the next release.)

Ubuntu releases every six months, with support for just eight months.

OpenSUSE has a release about every year or so; support is presently 18
months.

> ] For distributions with long-lifetime releases, the project will aim to support
> ] the most recent major version at all times. Support for the previous major
> ] version will be dropped 2 years after the new major version is released. For
> ] the purposes of identifying supported software versions, the project will look
> ] at RHEL, Debian, Ubuntu LTS, and SLES distros. Other long-lifetime distros will
> ] be assumed to ship similar software versions.
> 

Here's an enumeration of supported long-lifetime build platforms as
interpreted from the above text; using standard end-of-service dates
(EOS) when available in preference to EOL dates for special support
contracts.

RHEL6: 2010 - 2016 [EOS: 2021]
RHEL7: 2014 - 2021 [EOS: 2024+]
RHEL8: 2019 - ??   [EOS: 2029+]

Ubuntu 14.04 LTS: 2014-04 -- 2018-04 [EOS: 2019-04]
Ubuntu 16.04 LTS: 2016-04 -- 2020-04 [EOS: 2021-04]
Ubuntu 18.04 LTS: 2018-04 -- 2022-04 [EOS: 2023-04]
Ubuntu 20.04 LTS: 2020-04 -- 2024-04 [EOS: 2025?]

SLES 11: 2009 - 2016 [EOS: 2019]
SLES 12: 2014 - 2020 [EOS: 2024]
SLES 15: 2018 - ~2024? [EOS: 2028]

Debian 8: 2015 - 2019 [EOL: 2018]
Debian 9: 2017 - 2021 [EOL: ~2020]
Debian 10: 2019 - ~2023? [EOL: ~2022]

Whoops, our proclaimed support for Debian indeed carries on after its
EOL by an entire year.

> Debian 10 was released in July 2019.  Are we really willing to
> support Debian 9 as a supported build platform until July 2021?
> The Debian Project itself won't support Debian 9 after July 2020.
> 
> Even for other long-lifetime distros, I really think "2 years
> after the new major version is released" is too long, and I'd
> like to shorten this to 1 year.
> 

Two years for Debian feels too long, but one year for things like RHEL
feels too short.

We could treat Debian more like a "short cycle" distro in terms of our
policy -- it stands out amongst the other long-term distros with its
relatively short support lifespans.


I'd recommend something like the following:

For both enterprise distributions (Ubuntu LTS, RHEL, SLES) AND community
distributions (Ubuntu Interim, Debian Stable, Fedora, OpenSUSE); QEMU
will support previous releases for two years, until the end of standard
service, or until EOL, whichever occurs first.

In practice: this means 2 years for old versions of SLES, RHEL and
Ubuntu LTS, but we expire alongside EOL for Debian, Fedora, Ubuntu
(Interim), and OpenSUSE.

... Or, more or less, it would be like treating Debian as a short-cycle
project instead of a long-cycle one under our current rules.

--js


  reply	other threads:[~2019-09-23 21:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-20 20:00 [PATCH] docker: move tests from python2 to python3 John Snow
2019-09-20 21:29 ` Eduardo Habkost
2019-09-23 14:50 ` Cleber Rosa
2019-09-23 14:57   ` Philippe Mathieu-Daudé
2019-09-23 15:19     ` Cleber Rosa
2019-09-23 17:19   ` John Snow
2019-09-23 19:05     ` Debian support lifetime (was Re: [PATCH] docker: move tests from python2 to python3) Eduardo Habkost
2019-09-23 21:32       ` John Snow [this message]
2019-09-24  7:35       ` Daniel P. Berrangé
2019-09-24  9:06         ` Daniel P. Berrangé
2019-09-25 20:04         ` Eduardo Habkost
2019-09-26 11:58           ` Daniel P. Berrangé
2019-09-26 12:18             ` Peter Maydell
2019-09-26 12:44               ` Daniel P. Berrangé
2019-09-26 17:43             ` John Snow

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=0f7e2e17-73cd-5c44-f758-00d4d1156a58@redhat.com \
    --to=jsnow@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=berrange@redhat.com \
    --cc=crosa@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=fam@euphon.net \
    --cc=kwolf@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.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).