QEMU-Devel Archive on lore.kernel.org
 help / color / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: John Snow <jsnow@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	thuth@redhat.com, Eduardo Habkost <ehabkost@redhat.com>,
	Cleber Rosa <cleber@redhat.com>,
	qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com
Subject: Re: [PATCH] qapi: Fix code generation with Python 3.5
Date: Sat, 18 Jan 2020 07:54:18 +0100
Message-ID: <87lfq5s19h.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <a6ea59a5-0877-fdeb-5b37-9ec3f31074a4@redhat.com> (John Snow's message of "Fri, 17 Jan 2020 14:41:06 -0500")

John Snow <jsnow@redhat.com> writes:

> On 1/17/20 2:07 AM, Markus Armbruster wrote:
>> John Snow <jsnow@redhat.com> writes:
>> 
>>> On 1/16/20 3:25 PM, Markus Armbruster wrote:
>>>> Recent commit 3e7fb5811b "qapi: Fix code generation for empty modules"
>>>> modules" switched QAPISchema.visit() from
>>>>
>>>>     for entity in self._entity_list:
>>>>
>>>> effectively to
>>>>
>>>>     for mod in self._module_dict.values():
>>>>         for entity in mod._entity_list:
>>>>
>>>> Visits in the same order as long as .values() is in insertion order.
>>>> That's the case only for Python 3.6 and later.  Before, it's in some
>>>> arbitrary order, which results in broken generated code.
>>>>
>>>> Fix by making self._module_dict an OrderedDict rather than a dict.
>>>>
>>>> Fixes: 3e7fb5811baab213dcc7149c3aa69442d683c26c
>>>> Signed-off-by: Markus Armbruster <armbru@redhat.com>
>>>> ---
>>>>  scripts/qapi/schema.py | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/scripts/qapi/schema.py b/scripts/qapi/schema.py
>>>> index 0bfc5256fb..5100110fa2 100644
>>>> --- a/scripts/qapi/schema.py
>>>> +++ b/scripts/qapi/schema.py
>>>> @@ -795,7 +795,7 @@ class QAPISchema(object):
>>>>          self.docs = parser.docs
>>>>          self._entity_list = []
>>>>          self._entity_dict = {}
>>>> -        self._module_dict = {}
>>>> +        self._module_dict = OrderedDict()
>>>>          self._schema_dir = os.path.dirname(fname)
>>>>          self._make_module(None) # built-ins
>>>>          self._make_module(fname)
>>>>
>>>
>>> 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.

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.

> In this specific case, do we trust that Debian 9 LTS will continue to
> patch Python3.5 all the way up until July 2021?

June 2022 even.

We use Python at compile time with trusted input.  The need for security
maintenance is relatively low there.  I'm not ready to vouch for "and we
don't use Python for anything else".



  reply index

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-16 20:25 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 [this message]
2020-02-07 21:54         ` Eduardo Habkost
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 publically 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=87lfq5s19h.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=cleber@redhat.com \
    --cc=ehabkost@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

QEMU-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/qemu-devel/0 qemu-devel/git/0.git
	git clone --mirror https://lore.kernel.org/qemu-devel/1 qemu-devel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 qemu-devel qemu-devel/ https://lore.kernel.org/qemu-devel \
		qemu-devel@nongnu.org
	public-inbox-index qemu-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.nongnu.qemu-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git