qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eduardo Habkost <ehabkost@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	thuth@redhat.com, Cleber Rosa <cleber@redhat.com>,
	mdroth@linux.vnet.ibm.com, qemu-devel@nongnu.org,
	John Snow <jsnow@redhat.com>
Subject: Re: [PATCH] qapi: Fix code generation with Python 3.5
Date: Fri, 7 Feb 2020 16:54:59 -0500	[thread overview]
Message-ID: <20200207215459.GJ412524@habkost.net> (raw)
In-Reply-To: <87lfq5s19h.fsf@dusky.pond.sub.org>

On Sat, Jan 18, 2020 at 07:54:18AM +0100, Markus Armbruster wrote:
> John Snow <jsnow@redhat.com> writes:
> > On 1/17/20 2:07 AM, Markus Armbruster wrote:
> >> John Snow <jsnow@redhat.com> writes:
[...]
> >>> This problem has bitten me *many* times. I'm wondering if there's a
> >>> prescription that isn't just "Wait until we can stipulate 3.6+".
> >> 
> >> No clue.
> >> 
> >> 3.5 EOL is scheduled for 2020-09-13.
> >> https://devguide.python.org/#status-of-python-branches
> >> 
> >> We support 3.5 because we support Debian 9.
> >> 
> >> We'd normally drop support for Debian 9 two years after Debian 10,
> >> i.e. July 2021.  Assuming Debian supports it that far.  Whether they can
> >> truly support Python 3.5 after uptstream EOL seems doubtful.
> >> 
> >
> > We should decide whether we consider Debian LTS to be adequately
> > supported, yes-or-no.
> >
> > We should use a rule of "two years after successor, or End-of-Support,
> > whichever comes first."
> 
> Yes.
> 
> > For Debian, is end of support three years after it comes out, or is it
> > when the LTS is EOL?
> 
> We need to define end-of-support for Debian: is it Debian proper or is
> it Debian LTS?
> 
> <https://wiki.debian.org/DebianOldStable>:
> 
>     Q) How long will security updates be provided?
> 
>     The security team tries to support a stable distribution for about
>     one year after the next stable distribution has been released,
>     except when another stable distribution is released within this
>     year.  It is not possible to support three distributions; supporting
>     two simultaneously is already difficult enough.
> 
> <https://wiki.debian.org/LTS>:
> 
>     Debian Long Term Support (LTS) is a project to extend the lifetime
>     of all Debian stable releases to (at least) 5 years.  Debian LTS is
>     not handled by the Debian security team, but by a separate group of
>     volunteers and companies interested in making it a success.
> 
>     Thus the Debian LTS team takes over security maintenance of the
>     various releases once the Debian Security team stops its work.

As Debian LTS is maintained by a separate group, I interpret
"Debian EOL" as not including LTS.

Supporting Debian 9 in 2020 is already being a burden.
Supporting it until mid-2021 seems pointless.


> 
> Debian 10 "Buster" was released in July 2019.  Debian 9 "Stretch" will
> receive security updates from Debian until mid 2020, i.e. just about
> when Python 3.5 reaches EOL.  LTS will attempt to support it until June
> 2022.
> 
> I think we should give ourselves a bit more flexibility than the
> categorical "Support for the previous major version will be dropped 2
> years after the new major version is released."  At some point, the cost
> of supporting old hosts exceeds the utility.  We should face this
> tradeoff.

Agreed.

-- 
Eduardo



  reply	other threads:[~2020-02-07 21:55 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-16 20:25 [PATCH] qapi: Fix code generation with Python 3.5 Markus Armbruster
2020-01-16 21:17 ` John Snow
2020-01-17  7:07   ` Markus Armbruster
2020-01-17 19:41     ` John Snow
2020-01-18  6:54       ` Markus Armbruster
2020-02-07 21:54         ` Eduardo Habkost [this message]
2020-01-18  8:29       ` Philippe Mathieu-Daudé
2020-01-20  5:46         ` [Qemu-devel] Xenial in Travis (was: qapi: Fix code generation with Python 3.5) Thomas Huth
2020-01-17  9:34 ` [PATCH] qapi: Fix code generation with Python 3.5 Thomas Huth
2020-01-17 10:49   ` Markus Armbruster
2020-01-18  8:33     ` Philippe Mathieu-Daudé
2020-01-19 11:23       ` Philippe Mathieu-Daudé
2020-01-20 10:52 ` Alex Bennée
2020-01-20 12:53 ` Peter Maydell

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=20200207215459.GJ412524@habkost.net \
    --to=ehabkost@redhat.com \
    --cc=armbru@redhat.com \
    --cc=cleber@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    /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).