)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"8dca947a71b4fb0e689ebc4c54867f9733706daa","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"04bad874_f0b06597","updated":"2022-02-13 13:31:41.000000000","message":"I was thinking about this, and now I am completely confused.\n\n1. We also need to handle python 3.10; there\u0027s a proposal to add it to the yoga template as a nonvoting job so we get a heads-up on potential issues [0,1].\n\n2. I thought upper-constraints had a dual role of (a) limiting projects to using known good versions of dependencies that work across all projects, and (b) using versions of dependencies that work with all the versions of python that we support.  If we have separate 3.6 and 3.8 caps, then when i do my development work in 3.8 (since 3.6 is EOL), everything is fine until I run the 3.6 tests, and then I have to go back and make changes to work under both 3.6 and 3.8.  So why aren\u0027t we setting the u-c at the 3.6 version of dependencies, since that\u0027s basically what we have to work with?\n\n\n[0] http://lists.openstack.org/pipermail/openstack-discuss/2021-December/026164.html\n[1] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/821863","commit_id":"c21959ee6842d7e9f3cecbdf0ed02dcd20eb4340"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"b7bb7d1c33ab1710cacdb71c65d079460e495a07","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"2f586f79_9e8d5d6a","updated":"2022-02-11 23:23:30.000000000","message":"We should merge this quickly -- the nonclient library release is coming up soon (17 Feb), and packages that have only python_version\u003d\u003d\u00273.6\u0027 and python_version\u003d\u003d\u00273.8\u0027 don\u0027t have an upper constraint for python 3.9.","commit_id":"c21959ee6842d7e9f3cecbdf0ed02dcd20eb4340"},{"author":{"_account_id":14288,"name":"Matthew Thode","display_name":"prometheanfire","email":"mthode@mthode.org","username":"prometheanfire"},"change_message_id":"c7e4a6b8ff8543ef54b8fc6dc5a2034af6137e2e","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"eef8c457_fec19fcb","in_reply_to":"04bad874_f0b06597","updated":"2022-02-13 17:05:51.000000000","message":"this worked ok when projects supported all versions of python, but has gone out the door over the last year because more and more deps are not supporting old versions that openstack still states support for.  It\u0027d be easy(er) if we only support py38 and above but since we need py36.  Also, setting to py36 only would basically put us in a worse version of the py2.7 migration situation, what happens when libs come out requiring a new version, or a security update isn\u0027t backported (because just about no one back ports fixes or maintains more than one dev branch.\n\nMy suggestion is to:\n- drop py36\n- support py39\n- test with py310 using sed to change instances that state py39 to py310 (this is only supposed to be a canary)","commit_id":"c21959ee6842d7e9f3cecbdf0ed02dcd20eb4340"},{"author":{"_account_id":14288,"name":"Matthew Thode","display_name":"prometheanfire","email":"mthode@mthode.org","username":"prometheanfire"},"change_message_id":"ebb4b14582101c8b0de20137e2ebd282c6d50f2f","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"b5ed72c5_5389e588","in_reply_to":"eef8c457_fec19fcb","updated":"2022-02-13 17:06:45.000000000","message":"also, iirc the main problem supporting py36 is setuptools stopped supporting it.","commit_id":"c21959ee6842d7e9f3cecbdf0ed02dcd20eb4340"}]}