Re: [PATCH] qapi: Fix code generation with Python 3.5

[Philippe Mathieu-Daudé]

On 1/17/20 8:41 PM, John Snow wrote:
> On 1/17/20 2:07 AM, Markus Armbruster wrote:
> > John Snow <address@hidden> 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 <address@hidden>
> > > > ---
> > > >   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."
>
> For Debian, is end of support three years after it comes out, or is it
> when the LTS is EOL?
>
> In this specific case, do we trust that Debian 9 LTS will continue to
> patch Python3.5 all the way up until July 2021?

This broke 29 of the 32 Travis jobs we have:

https://travis-ci.org/qemu/qemu/builds/637999366

Since we started to use Travis CI, it catched quite some bugs...

I think it is important to add in the equation we also depend of our CIs.