)]}'
{"resolutions/20181024-python-update-process.rst":[{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"ebe459d8281cba316b1b229999b0c6e0fa846f89","unresolved":false,"context_lines":[{"line_number":25,"context_line":""},{"line_number":26,"context_line":"* The maximum version should be the latest released version of Python 3 that is"},{"line_number":27,"context_line":"  available in *any* distribution we can feasibly use for testing. It need not"},{"line_number":28,"context_line":"  be a long-term-supported release, but could be an non-LTS version of Ubuntu,"},{"line_number":29,"context_line":"  Fedora, OpenSUSE Leap, or even a rolling release distribution (such as Debian"},{"line_number":30,"context_line":"  Testing or OpenSUSE Tumbleweed) if necessary."},{"line_number":31,"context_line":"* The minimum version should be the earliest Python 3 version that is the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_7a9c83bd","line":28,"range":{"start_line":28,"start_character":49,"end_line":28,"end_character":51},"updated":"2018-10-25 10:40:35.000000000","message":"nit: a ?","commit_id":"b459a3ddba4d90d445d114a02ef53dae74c48592"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"137f0d5ec03ac67d6d4d883ed678f85a7200551b","unresolved":false,"context_lines":[{"line_number":25,"context_line":""},{"line_number":26,"context_line":"* The maximum version should be the latest released version of Python 3 that is"},{"line_number":27,"context_line":"  available in *any* distribution we can feasibly use for testing. It need not"},{"line_number":28,"context_line":"  be a long-term-supported release, but could be an non-LTS version of Ubuntu,"},{"line_number":29,"context_line":"  Fedora, OpenSUSE Leap, or even a rolling release distribution (such as Debian"},{"line_number":30,"context_line":"  Testing or OpenSUSE Tumbleweed) if necessary."},{"line_number":31,"context_line":"* The minimum version should be the earliest Python 3 version that is the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_d7f9e5c5","line":28,"range":{"start_line":28,"start_character":49,"end_line":28,"end_character":51},"in_reply_to":"3f79a3b5_7a9c83bd","updated":"2018-10-25 16:48:09.000000000","message":"I guess this originally said \"an Ubuntu release that is not LTS\" or something. Will fix if there\u0027s another patchset.","commit_id":"b459a3ddba4d90d445d114a02ef53dae74c48592"},{"author":{"_account_id":11805,"name":"Corey Bryant","email":"corey.bryant@canonical.com","username":"coreycb"},"change_message_id":"cc108c1c5fd02d44a503ff1da90e3038ebb86ab9","unresolved":false,"context_lines":[{"line_number":27,"context_line":"  available in *any* distribution we can feasibly use for testing. It need not"},{"line_number":28,"context_line":"  be a long-term-supported release, but could be an non-LTS version of Ubuntu,"},{"line_number":29,"context_line":"  Fedora, OpenSUSE Leap, or even a rolling release distribution (such as Debian"},{"line_number":30,"context_line":"  Testing or OpenSUSE Tumbleweed) if necessary."},{"line_number":31,"context_line":"* The minimum version should be the earliest Python 3 version that is the"},{"line_number":32,"context_line":"  default in any of the :ref:`Linux distributions specifically identified in"},{"line_number":33,"context_line":"  the Project Testing Interface \u003cpti-linux-distros\u003e`, including any older"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_6037f44c","line":30,"updated":"2018-10-25 12:36:06.000000000","message":"I think this is great. Something to consider though is that support will be stated for a max Python version that very well may not get integration tested for a few more releases. For example, integration testing will be performed on 18.04 until 20.04 is available (available prior to the beginning of a release cycle). So integration testing will be on a 2+ year old release until the openstack release that starts in ~sept 2020.","commit_id":"b459a3ddba4d90d445d114a02ef53dae74c48592"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"137f0d5ec03ac67d6d4d883ed678f85a7200551b","unresolved":false,"context_lines":[{"line_number":27,"context_line":"  available in *any* distribution we can feasibly use for testing. It need not"},{"line_number":28,"context_line":"  be a long-term-supported release, but could be an non-LTS version of Ubuntu,"},{"line_number":29,"context_line":"  Fedora, OpenSUSE Leap, or even a rolling release distribution (such as Debian"},{"line_number":30,"context_line":"  Testing or OpenSUSE Tumbleweed) if necessary."},{"line_number":31,"context_line":"* The minimum version should be the earliest Python 3 version that is the"},{"line_number":32,"context_line":"  default in any of the :ref:`Linux distributions specifically identified in"},{"line_number":33,"context_line":"  the Project Testing Interface \u003cpti-linux-distros\u003e`, including any older"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_f7e4210d","line":30,"in_reply_to":"3f79a3b5_6037f44c","updated":"2018-10-25 16:48:09.000000000","message":"Yes, this is true and has also been our past practice. (We\u0027ve done integration tests only on Precise, Trusty, and Xenial in my recollection, and we\u0027re hoping to switch to Bionic ~now).\n\nChanging that would mean a change to our testing philosophy, which up until now has been focused on stable distros. I\u0027m not ruling that out, but it would need to happen by updating the PTI doc. I\u0027ve attempted to write this resolution so that it works independently of which distros we choose to support in the PTI.","commit_id":"b459a3ddba4d90d445d114a02ef53dae74c48592"},{"author":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"change_message_id":"d73f73e4bd3db6c1fd9f411de5231cfc4a73d83f","unresolved":false,"context_lines":[{"line_number":29,"context_line":"  Fedora, OpenSUSE Leap, or even a rolling release distribution (such as Debian"},{"line_number":30,"context_line":"  Testing or OpenSUSE Tumbleweed) if necessary."},{"line_number":31,"context_line":"* The minimum version should be the earliest Python 3 version that is the"},{"line_number":32,"context_line":"  default in any of the :ref:`Linux distributions specifically identified in"},{"line_number":33,"context_line":"  the Project Testing Interface \u003cpti-linux-distros\u003e`, including any older"},{"line_number":34,"context_line":"  releases of those distributions that were still used in integration tests at"},{"line_number":35,"context_line":"  the beginning of the cycle."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_2cf00b66","line":32,"updated":"2018-10-25 22:29:01.000000000","message":"This is great if the PTI is updated to cover Ubuntu 16.04, but otherwise I\u0027m concerned that this will mean no more py35 and therefore no more Ubuntu 16.04, which is very widely used and not going away any time soon. Are we consciously making that decision?","commit_id":"b459a3ddba4d90d445d114a02ef53dae74c48592"},{"author":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"change_message_id":"d73f73e4bd3db6c1fd9f411de5231cfc4a73d83f","unresolved":false,"context_lines":[{"line_number":32,"context_line":"  default in any of the :ref:`Linux distributions specifically identified in"},{"line_number":33,"context_line":"  the Project Testing Interface \u003cpti-linux-distros\u003e`, including any older"},{"line_number":34,"context_line":"  releases of those distributions that were still used in integration tests at"},{"line_number":35,"context_line":"  the beginning of the cycle."},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"To reduce test load, only the maximum and minimum Python 3 versions will be"},{"line_number":38,"context_line":"tested in the gate. Intermediate versions will be tested only with periodic"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_8c735fe8","line":35,"updated":"2018-10-25 22:29:01.000000000","message":"Ubuntu 16.04 was still used at the beginning of Stein, right? So am I reading this correctly that we would have to support py35 at least Stein but it would go away in Train?","commit_id":"b459a3ddba4d90d445d114a02ef53dae74c48592"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"6fbf9950deec25df3298a762202c5f65c7d4e82e","unresolved":false,"context_lines":[{"line_number":32,"context_line":"  default in any of the :ref:`Linux distributions specifically identified in"},{"line_number":33,"context_line":"  the Project Testing Interface \u003cpti-linux-distros\u003e`, including any older"},{"line_number":34,"context_line":"  releases of those distributions that were still used in integration tests at"},{"line_number":35,"context_line":"  the beginning of the cycle."},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"To reduce test load, only the maximum and minimum Python 3 versions will be"},{"line_number":38,"context_line":"tested in the gate. Intermediate versions will be tested only with periodic"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_939ff3f4","line":35,"in_reply_to":"3f79a3b5_75e7a2d8","updated":"2018-10-26 08:37:38.000000000","message":"\u003e Whether py35 will go away in T is difficult to say, because we\u0027re\n \u003e in an unusual situation: there will be a CentOS 8 and it will not\n \u003e include 2.7, but we don\u0027t know which minor version of 3 it will use\n \u003e (nor when we\u0027ll find out). My personal opinion is that we shouldn\u0027t\n \u003e drop anything we already support now until we know that we won\u0027t\n \u003e need it, but other folks have suggested dropping it in Stein. So\n \u003e we\u0027ll see.\n\nSince these conversations are going on in so many different places at once, I\u0027m not sure, but I suspect I\u0027m one of those people who suggested dropping py35. This was largely based on wanting to save some resources but clarkb (if I recall correctly) suggested that it wouldn\u0027t actually make that much difference in queue length (which surprised me).\n\nBut part of it was based on a desire to change our approach to testing: I think we should be testing the future so that we are ahead of changes, rather than reacting to them. If we are in a situation of limited resource (which based on the above perhaps we are not) \"slow\" distros like CentOS and RHEL should not be our responsibility: we should focus on what today is the future but at actual use time (post-release) is the norm.","commit_id":"b459a3ddba4d90d445d114a02ef53dae74c48592"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"3c1e24322e2f1818474c1e2718972ce9d123ed4f","unresolved":false,"context_lines":[{"line_number":32,"context_line":"  default in any of the :ref:`Linux distributions specifically identified in"},{"line_number":33,"context_line":"  the Project Testing Interface \u003cpti-linux-distros\u003e`, including any older"},{"line_number":34,"context_line":"  releases of those distributions that were still used in integration tests at"},{"line_number":35,"context_line":"  the beginning of the cycle."},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"To reduce test load, only the maximum and minimum Python 3 versions will be"},{"line_number":38,"context_line":"tested in the gate. Intermediate versions will be tested only with periodic"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_75e7a2d8","line":35,"in_reply_to":"3f79a3b5_8c735fe8","updated":"2018-10-26 02:05:19.000000000","message":"I hadn\u0027t thought it through for Stein, but now you mention it yes.\n\nI don\u0027t think we can start removing py35 jobs while there are still people testing on 16.04, because doing so would allow them to introduce py36-only code (f-strings for everything!) that could then break other projects\u0027 integration tests. That was the general principle I was trying to hit with this paragraph.\n\nWhether py35 will go away in T is difficult to say, because we\u0027re in an unusual situation: there will be a CentOS 8 and it will not include 2.7, but we don\u0027t know which minor version of 3 it will use (nor when we\u0027ll find out). My personal opinion is that we shouldn\u0027t drop anything we already support now until we know that we won\u0027t need it, but other folks have suggested dropping it in Stein. So we\u0027ll see.","commit_id":"b459a3ddba4d90d445d114a02ef53dae74c48592"},{"author":{"_account_id":19298,"name":"Nicolas Bock","email":"nicolas.bock@canonical.com","username":"nicolasbock"},"change_message_id":"f93bb6a0ac7b10c5053e2a3d641e094268471aa3","unresolved":false,"context_lines":[{"line_number":37,"context_line":"To reduce test load, only the maximum and minimum Python 3 versions will be"},{"line_number":38,"context_line":"tested in the gate. Intermediate versions will be tested only with periodic"},{"line_number":39,"context_line":"jobs."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"This decision will be encoded in a Zuul template for unit tests named"},{"line_number":42,"context_line":"``openstack-python3-\u003creleasename\u003e-jobs``, containing:"},{"line_number":43,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_00bde0b0","line":40,"updated":"2018-10-25 12:12:09.000000000","message":"What defines the set of \"intermediate versions\"?","commit_id":"b459a3ddba4d90d445d114a02ef53dae74c48592"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"137f0d5ec03ac67d6d4d883ed678f85a7200551b","unresolved":false,"context_lines":[{"line_number":37,"context_line":"To reduce test load, only the maximum and minimum Python 3 versions will be"},{"line_number":38,"context_line":"tested in the gate. Intermediate versions will be tested only with periodic"},{"line_number":39,"context_line":"jobs."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"This decision will be encoded in a Zuul template for unit tests named"},{"line_number":42,"context_line":"``openstack-python3-\u003creleasename\u003e-jobs``, containing:"},{"line_number":43,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_c4be1563","line":40,"in_reply_to":"3f79a3b5_00bde0b0","updated":"2018-10-25 16:48:09.000000000","message":"A full minor release between the minimum and maximum versions. So e.g. if the range we wanted was 3.5-3.7, there would be a periodic job for 3.6.","commit_id":"b459a3ddba4d90d445d114a02ef53dae74c48592"},{"author":{"_account_id":11805,"name":"Corey Bryant","email":"corey.bryant@canonical.com","username":"coreycb"},"change_message_id":"cc108c1c5fd02d44a503ff1da90e3038ebb86ab9","unresolved":false,"context_lines":[{"line_number":54,"context_line":"* declare support for the tested version range in its PyPI package; and"},{"line_number":55,"context_line":"* update tox\u0027s default environment list."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"If the maximum version has increased, the goal champion(s) may choose to update"},{"line_number":58,"context_line":"the *previous* release\u0027s template to add a non-voting check job running on the"},{"line_number":59,"context_line":"upcoming maximum version. If they choose to do so, this job should be limited"},{"line_number":60,"context_line":"to the ``master`` branch, so that it does not continue to run on the stable"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_809c90be","line":57,"updated":"2018-10-25 12:36:06.000000000","message":"Should this say \"has increased during a release cycle\"?","commit_id":"b459a3ddba4d90d445d114a02ef53dae74c48592"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"137f0d5ec03ac67d6d4d883ed678f85a7200551b","unresolved":false,"context_lines":[{"line_number":54,"context_line":"* declare support for the tested version range in its PyPI package; and"},{"line_number":55,"context_line":"* update tox\u0027s default environment list."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"If the maximum version has increased, the goal champion(s) may choose to update"},{"line_number":58,"context_line":"the *previous* release\u0027s template to add a non-voting check job running on the"},{"line_number":59,"context_line":"upcoming maximum version. If they choose to do so, this job should be limited"},{"line_number":60,"context_line":"to the ``master`` branch, so that it does not continue to run on the stable"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_37d5b947","line":57,"in_reply_to":"3f79a3b5_809c90be","updated":"2018-10-25 16:48:09.000000000","message":"It\u0027s if it has increased since the last zuul template, but I elided that because it didn\u0027t seem to actually add any extra information.","commit_id":"b459a3ddba4d90d445d114a02ef53dae74c48592"},{"author":{"_account_id":11805,"name":"Corey Bryant","email":"corey.bryant@canonical.com","username":"coreycb"},"change_message_id":"cc108c1c5fd02d44a503ff1da90e3038ebb86ab9","unresolved":false,"context_lines":[{"line_number":55,"context_line":"* update tox\u0027s default environment list."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"If the maximum version has increased, the goal champion(s) may choose to update"},{"line_number":58,"context_line":"the *previous* release\u0027s template to add a non-voting check job running on the"},{"line_number":59,"context_line":"upcoming maximum version. If they choose to do so, this job should be limited"},{"line_number":60,"context_line":"to the ``master`` branch, so that it does not continue to run on the stable"},{"line_number":61,"context_line":"branch once it forks."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_e03784ae","line":58,"updated":"2018-10-25 12:36:06.000000000","message":"\"previous release\" is confusing me if it should be limited to master as it says below","commit_id":"b459a3ddba4d90d445d114a02ef53dae74c48592"},{"author":{"_account_id":11805,"name":"Corey Bryant","email":"corey.bryant@canonical.com","username":"coreycb"},"change_message_id":"4a4004c8641f738f2b9a46e47b68b364b5c534cc","unresolved":false,"context_lines":[{"line_number":55,"context_line":"* update tox\u0027s default environment list."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"If the maximum version has increased, the goal champion(s) may choose to update"},{"line_number":58,"context_line":"the *previous* release\u0027s template to add a non-voting check job running on the"},{"line_number":59,"context_line":"upcoming maximum version. If they choose to do so, this job should be limited"},{"line_number":60,"context_line":"to the ``master`` branch, so that it does not continue to run on the stable"},{"line_number":61,"context_line":"branch once it forks."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_a743c996","line":58,"in_reply_to":"3f79a3b5_2c1a4b7b","updated":"2018-10-26 12:36:20.000000000","message":"I imagine it makes sense as is to folks more familiar with zuul, but agreed would be nice to clarify.","commit_id":"b459a3ddba4d90d445d114a02ef53dae74c48592"},{"author":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"change_message_id":"d73f73e4bd3db6c1fd9f411de5231cfc4a73d83f","unresolved":false,"context_lines":[{"line_number":55,"context_line":"* update tox\u0027s default environment list."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"If the maximum version has increased, the goal champion(s) may choose to update"},{"line_number":58,"context_line":"the *previous* release\u0027s template to add a non-voting check job running on the"},{"line_number":59,"context_line":"upcoming maximum version. If they choose to do so, this job should be limited"},{"line_number":60,"context_line":"to the ``master`` branch, so that it does not continue to run on the stable"},{"line_number":61,"context_line":"branch once it forks."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_2c1a4b7b","line":58,"in_reply_to":"3f79a3b5_376299da","updated":"2018-10-25 22:29:01.000000000","message":"oi... I see what you mean, but... that\u0027s downright confusing. I highly suggest adding your example to the text to clarify.","commit_id":"b459a3ddba4d90d445d114a02ef53dae74c48592"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"137f0d5ec03ac67d6d4d883ed678f85a7200551b","unresolved":false,"context_lines":[{"line_number":55,"context_line":"* update tox\u0027s default environment list."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"If the maximum version has increased, the goal champion(s) may choose to update"},{"line_number":58,"context_line":"the *previous* release\u0027s template to add a non-voting check job running on the"},{"line_number":59,"context_line":"upcoming maximum version. If they choose to do so, this job should be limited"},{"line_number":60,"context_line":"to the ``master`` branch, so that it does not continue to run on the stable"},{"line_number":61,"context_line":"branch once it forks."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_376299da","line":58,"in_reply_to":"3f79a3b5_e03784ae","updated":"2018-10-25 16:48:09.000000000","message":"It\u0027s the previous release\u0027s *template*. So any repos that haven\u0027t updated their Zuul config yet will see it on master, because they\u0027ll still be using the old template even though the previous release has branched.\n\nTo take a hypothetical historical example, when updating the maximum version in Stein to 3.6, we\u0027d have added a non-voting py36 job to openstack-py3-rocky-jobs, but limit it to master so it doesn\u0027t run against stable/rocky: I668f32093185bd9b4210fd5125aa21766e55d052","commit_id":"b459a3ddba4d90d445d114a02ef53dae74c48592"},{"author":{"_account_id":11805,"name":"Corey Bryant","email":"corey.bryant@canonical.com","username":"coreycb"},"change_message_id":"cc108c1c5fd02d44a503ff1da90e3038ebb86ab9","unresolved":false,"context_lines":[{"line_number":58,"context_line":"the *previous* release\u0027s template to add a non-voting check job running on the"},{"line_number":59,"context_line":"upcoming maximum version. If they choose to do so, this job should be limited"},{"line_number":60,"context_line":"to the ``master`` branch, so that it does not continue to run on the stable"},{"line_number":61,"context_line":"branch once it forks."},{"line_number":62,"context_line":""},{"line_number":63,"context_line":"Integration Tests"},{"line_number":64,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_20bedccd","line":61,"updated":"2018-10-25 12:36:06.000000000","message":"It seems like we\u0027d want to continue running this test on the stable branch once it is cut. What we were testing on master, even though it was non-voting, may have been successful and could get regressed once in stable if removed. Granted it is still non-voting so would not prevent a merge.","commit_id":"b459a3ddba4d90d445d114a02ef53dae74c48592"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"137f0d5ec03ac67d6d4d883ed678f85a7200551b","unresolved":false,"context_lines":[{"line_number":58,"context_line":"the *previous* release\u0027s template to add a non-voting check job running on the"},{"line_number":59,"context_line":"upcoming maximum version. If they choose to do so, this job should be limited"},{"line_number":60,"context_line":"to the ``master`` branch, so that it does not continue to run on the stable"},{"line_number":61,"context_line":"branch once it forks."},{"line_number":62,"context_line":""},{"line_number":63,"context_line":"Integration Tests"},{"line_number":64,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_b7e9c919","line":61,"in_reply_to":"3f79a3b5_20bedccd","updated":"2018-10-25 16:48:09.000000000","message":"We\u0027d only be adding this right at the end of the cycle at the earliest anyway. The point is to prepare for the future (when everyone switches to the next release\u0027s zuul template and it becomes voting). There\u0027s no value in running non-voting jobs on dead-end branches IMHO, because they may break and nobody will care.\n\nNote that this is a different question to the one you answered in http://lists.openstack.org/pipermail/openstack-dev/2018-October/135929.html (which was about tightening up the maximum version on the stable branch after it is released - that is not part of this resolution).","commit_id":"b459a3ddba4d90d445d114a02ef53dae74c48592"},{"author":{"_account_id":11805,"name":"Corey Bryant","email":"corey.bryant@canonical.com","username":"coreycb"},"change_message_id":"4a4004c8641f738f2b9a46e47b68b364b5c534cc","unresolved":false,"context_lines":[{"line_number":58,"context_line":"the *previous* release\u0027s template to add a non-voting check job running on the"},{"line_number":59,"context_line":"upcoming maximum version. If they choose to do so, this job should be limited"},{"line_number":60,"context_line":"to the ``master`` branch, so that it does not continue to run on the stable"},{"line_number":61,"context_line":"branch once it forks."},{"line_number":62,"context_line":""},{"line_number":63,"context_line":"Integration Tests"},{"line_number":64,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_27cd792e","line":61,"in_reply_to":"3f79a3b5_b7e9c919","updated":"2018-10-26 12:36:20.000000000","message":"Got it, thanks for the explanation.","commit_id":"b459a3ddba4d90d445d114a02ef53dae74c48592"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"ebe459d8281cba316b1b229999b0c6e0fa846f89","unresolved":false,"context_lines":[{"line_number":70,"context_line":"update any integration tests running on an older version of that distribution"},{"line_number":71,"context_line":"to run on the new release."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"The goal champion(s) may choose to make a hard cut-over of any unconverted test"},{"line_number":74,"context_line":"jobs at some point during the release cycle, to ensure that all OpenStack"},{"line_number":75,"context_line":"components are usable on a single version of a distribution prior to the"},{"line_number":76,"context_line":"OpenStack release. The schedule for any such cut-over must be publicised in"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_3ad84b7e","line":73,"range":{"start_line":73,"start_character":35,"end_line":73,"end_character":55},"updated":"2018-10-25 10:40:35.000000000","message":"You may wish to define what \"hard cut-over\" is more explicitly.","commit_id":"b459a3ddba4d90d445d114a02ef53dae74c48592"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"137f0d5ec03ac67d6d4d883ed678f85a7200551b","unresolved":false,"context_lines":[{"line_number":70,"context_line":"update any integration tests running on an older version of that distribution"},{"line_number":71,"context_line":"to run on the new release."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"The goal champion(s) may choose to make a hard cut-over of any unconverted test"},{"line_number":74,"context_line":"jobs at some point during the release cycle, to ensure that all OpenStack"},{"line_number":75,"context_line":"components are usable on a single version of a distribution prior to the"},{"line_number":76,"context_line":"OpenStack release. The schedule for any such cut-over must be publicised in"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_04a08d35","line":73,"range":{"start_line":73,"start_character":35,"end_line":73,"end_character":55},"in_reply_to":"3f79a3b5_3ad84b7e","updated":"2018-10-25 16:48:09.000000000","message":"I was afraid somebody would say that.","commit_id":"b459a3ddba4d90d445d114a02ef53dae74c48592"},{"author":{"_account_id":6547,"name":"Andreas Jaeger","email":"jaegerandi@gmail.com","username":"jaegerandi"},"change_message_id":"8ca60a9b2b02f296dc236a0d7c2bc89d8e9ee6f9","unresolved":false,"context_lines":[{"line_number":26,"context_line":"* The maximum version should be the latest released version of Python 3 that is"},{"line_number":27,"context_line":"  available in *any* distribution we can feasibly use for testing. It need not"},{"line_number":28,"context_line":"  be a long-term-supported release, but could be a non-LTS version of Ubuntu,"},{"line_number":29,"context_line":"  Fedora, OpenSUSE Leap, or even a rolling release distribution (such as Debian"},{"line_number":30,"context_line":"  Testing or OpenSUSE Tumbleweed) if necessary."},{"line_number":31,"context_line":"* The minimum version should be the earliest Python 3 version that is the"},{"line_number":32,"context_line":"  default in any of the :ref:`Linux distributions specifically identified in"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_2adf6e67","line":29,"updated":"2018-10-27 14:55:49.000000000","message":"nit: It\u0027s openSUSE with lowercase \"o\" here and next line.","commit_id":"b2c83c4513e7d3413400ed81098503786a3cd6b3"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"e3841f78678d7192abea27b93284fbc3b4fbe0c1","unresolved":false,"context_lines":[{"line_number":36,"context_line":""},{"line_number":37,"context_line":"To reduce test load, only the maximum and minimum Python 3 minor versions will"},{"line_number":38,"context_line":"be tested in the gate. Any intermediate minor versions will be tested only with"},{"line_number":39,"context_line":"periodic jobs."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"This decision will be encoded in a Zuul template for unit tests named"},{"line_number":42,"context_line":"``openstack-python3-\u003creleasename\u003e-jobs``, containing:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_9bfcac0c","line":39,"updated":"2018-10-30 16:23:26.000000000","message":"This may mean not running regular tests against versions that will be available in the actual distributions, and assumes that there are no differences between the min and max that might cause issues.\n\nRather than focusing on a min and max, we should specify the list of versions. That gives us the flexibility to make the call each cycle of which versions make sense and which are potentially redundant.","commit_id":"b2c83c4513e7d3413400ed81098503786a3cd6b3"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"fa7f9d3663d20f5b171cba090c101eaeee5eea70","unresolved":false,"context_lines":[{"line_number":36,"context_line":""},{"line_number":37,"context_line":"To reduce test load, only the maximum and minimum Python 3 minor versions will"},{"line_number":38,"context_line":"be tested in the gate. Any intermediate minor versions will be tested only with"},{"line_number":39,"context_line":"periodic jobs."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"This decision will be encoded in a Zuul template for unit tests named"},{"line_number":42,"context_line":"``openstack-python3-\u003creleasename\u003e-jobs``, containing:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_2f1af27f","line":39,"in_reply_to":"3f79a3b5_949239fb","updated":"2018-10-30 20:00:00.000000000","message":"\u003e \u003e assumes that there are no differences between the min and max\n \u003e that might cause issues.\n \u003e \n \u003e Yes, we\u0027re making that assumption here - essentially that changes\n \u003e are monotonic across the range of Python versions we care about.\n \u003e It\u0027s clearly a risk, but so far nobody has identified a scenario\n \u003e that appears to make the risk unacceptably high.\n\nI thought we did know about differences between 3.6 and 3.7. Maybe I misunderstood, and those came up in 3.7, and so would still be caught by testing (for the sake of argument) only 3.5 and 3.7?\n\n \u003e We\u0027ll also have integration tests running on the distros named in\n \u003e the PTI, so it\u0027s not like they\u0027re _never_ tested.\n \u003e \n \u003e \u003e Rather than focusing on a min and max, we should specify the list\n \u003e of versions.\n \u003e \n \u003e I\u0027m not against that, but...\n \u003e \n \u003e \u003e That gives us the flexibility to make the call each cycle\n \u003e \n \u003e This has the potential to degenerate into a lot of debate. The\n\nI think making the decision is the responsibility of the technical leadership for the project, and the TC is going to have to make the best call we can based on all of the data and input we can get.\n\n \u003e feedback I got on the ML thread was that people wanted the criteria\n \u003e to be as objective as possible. It could work if we said the latest\n \u003e python.org version plus the default versions from all of the\n \u003e distros listed in the PTI.\n\nIs it realistic to test the latest python.org version? Do we have someone signed up to keep up with building that and ensuring we have a good image that includes it?\n\nOne reason we\u0027ve always targeted LTS releases, in addition to the fact that we expect users to use them for deployments, is that they come with relatively stable packaged versions of python. Forward testing is a good goal, but I don\u0027t think we need to feel guilty for making the trade-off based on where people are willing to spend time and energy.\n\n \u003e \u003e of which versions make sense and which are potentially redundant.\n \u003e \n \u003e One issue with this is that today\u0027s redundant intermediate version\n \u003e is going to have a habit of turning into tomorrow\u0027s\n \u003e PTI-distro-default hard requirement. (Not to mention there may be\n \u003e other Linux distros using those intermediate versions.) So if we\n \u003e don\u0027t believe that min/max testing is sufficient then I\u0027m not sure\n \u003e that a list solves our problem. Maybe we should just test every\n \u003e intermediate version if we don\u0027t think min/max is enough?\n\nIf we pick the versions that we anticipate distros having and supporting running OpenStack on, then we still have a limited set of versions to worry about.","commit_id":"b2c83c4513e7d3413400ed81098503786a3cd6b3"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"b26cc67d3776930bd67fe4a6d9e6fe3c4962800a","unresolved":false,"context_lines":[{"line_number":36,"context_line":""},{"line_number":37,"context_line":"To reduce test load, only the maximum and minimum Python 3 minor versions will"},{"line_number":38,"context_line":"be tested in the gate. Any intermediate minor versions will be tested only with"},{"line_number":39,"context_line":"periodic jobs."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"This decision will be encoded in a Zuul template for unit tests named"},{"line_number":42,"context_line":"``openstack-python3-\u003creleasename\u003e-jobs``, containing:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_949239fb","line":39,"in_reply_to":"3f79a3b5_9bfcac0c","updated":"2018-10-30 19:07:50.000000000","message":"\u003e assumes that there are no differences between the min and max that might cause issues.\n\nYes, we\u0027re making that assumption here - essentially that changes are monotonic across the range of Python versions we care about. It\u0027s clearly a risk, but so far nobody has identified a scenario that appears to make the risk unacceptably high.\n\nWe\u0027ll also have integration tests running on the distros named in the PTI, so it\u0027s not like they\u0027re _never_ tested.\n\n\u003e Rather than focusing on a min and max, we should specify the list of versions.\n\nI\u0027m not against that, but...\n\n\u003e That gives us the flexibility to make the call each cycle\n\nThis has the potential to degenerate into a lot of debate. The feedback I got on the ML thread was that people wanted the criteria to be as objective as possible. It could work if we said the latest python.org version plus the default versions from all of the distros listed in the PTI.\n\n\u003e of which versions make sense and which are potentially redundant.\n\nOne issue with this is that today\u0027s redundant intermediate version is going to have a habit of turning into tomorrow\u0027s PTI-distro-default hard requirement. (Not to mention there may be other Linux distros using those intermediate versions.) So if we don\u0027t believe that min/max testing is sufficient then I\u0027m not sure that a list solves our problem. Maybe we should just test every intermediate version if we don\u0027t think min/max is enough?","commit_id":"b2c83c4513e7d3413400ed81098503786a3cd6b3"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"e3841f78678d7192abea27b93284fbc3b4fbe0c1","unresolved":false,"context_lines":[{"line_number":45,"context_line":"  supports"},{"line_number":46,"context_line":"* Voting check and gate jobs for the minimum minor version of py3 the release"},{"line_number":47,"context_line":"  supports"},{"line_number":48,"context_line":"* A periodic job for each intermediate minor version of py3, if any exist"},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"The TC will set an :doc:`OpenStack-wide goal \u003c../goals/index\u003e` for each repo,"},{"line_number":51,"context_line":"prior to the end of the release, to:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_bb140844","line":48,"updated":"2018-10-30 16:23:26.000000000","message":"Which team is responsible for setting up this new template each cycle?","commit_id":"b2c83c4513e7d3413400ed81098503786a3cd6b3"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"9374a550b3e5d0428c0e0d8ed6373917c10b021b","unresolved":false,"context_lines":[{"line_number":45,"context_line":"  supports"},{"line_number":46,"context_line":"* Voting check and gate jobs for the minimum minor version of py3 the release"},{"line_number":47,"context_line":"  supports"},{"line_number":48,"context_line":"* A periodic job for each intermediate minor version of py3, if any exist"},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"The TC will set an :doc:`OpenStack-wide goal \u003c../goals/index\u003e` for each repo,"},{"line_number":51,"context_line":"prior to the end of the release, to:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_b9ab426f","line":48,"in_reply_to":"3f79a3b5_8e83ba06","updated":"2018-11-05 16:44:43.000000000","message":"I would say it\u0027s up to the TC to decide case-by-case. But I imagine in many cases it\u0027ll be simple enough that we could still have 2 other goals. Other times (particularly when there\u0027s a new Ubuntu LTS) I could imagine the TC deciding there\u0027s only time for one other goal.\n\nAFAIK we don\u0027t actually explicitly state anywhere that there should be 2 goals per cycle, it\u0027s just something that the TC has repeatedly decided feels about right.","commit_id":"b2c83c4513e7d3413400ed81098503786a3cd6b3"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"875e51cbd1455eee8f8daec84882538eed2b4e2c","unresolved":false,"context_lines":[{"line_number":45,"context_line":"  supports"},{"line_number":46,"context_line":"* Voting check and gate jobs for the minimum minor version of py3 the release"},{"line_number":47,"context_line":"  supports"},{"line_number":48,"context_line":"* A periodic job for each intermediate minor version of py3, if any exist"},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"The TC will set an :doc:`OpenStack-wide goal \u003c../goals/index\u003e` for each repo,"},{"line_number":51,"context_line":"prior to the end of the release, to:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_8e83ba06","line":48,"in_reply_to":"3f79a3b5_94cf99b1","updated":"2018-11-02 19:26:54.000000000","message":"Does this imply that we\u0027ll have three goals each release? Or will one of the goals always be a reoccurring python3 goal?","commit_id":"b2c83c4513e7d3413400ed81098503786a3cd6b3"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"b26cc67d3776930bd67fe4a6d9e6fe3c4962800a","unresolved":false,"context_lines":[{"line_number":45,"context_line":"  supports"},{"line_number":46,"context_line":"* Voting check and gate jobs for the minimum minor version of py3 the release"},{"line_number":47,"context_line":"  supports"},{"line_number":48,"context_line":"* A periodic job for each intermediate minor version of py3, if any exist"},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"The TC will set an :doc:`OpenStack-wide goal \u003c../goals/index\u003e` for each repo,"},{"line_number":51,"context_line":"prior to the end of the release, to:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_94cf99b1","line":48,"in_reply_to":"3f79a3b5_bb140844","updated":"2018-10-30 19:07:50.000000000","message":"I\u0027d assume the goal champions would have ultimate responsibility.","commit_id":"b2c83c4513e7d3413400ed81098503786a3cd6b3"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"e3841f78678d7192abea27b93284fbc3b4fbe0c1","unresolved":false,"context_lines":[{"line_number":70,"context_line":"specifically identified in the Project Testing Interface \u003cpti-linux-distros\u003e`."},{"line_number":71,"context_line":"If there have, it will set an :doc:`OpenStack-wide goal \u003c../goals/index\u003e` to"},{"line_number":72,"context_line":"update any integration tests running on an older version of that distribution"},{"line_number":73,"context_line":"to run on the new release."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"The goal champion(s) may choose to make a hard cut-over (i.e. a"},{"line_number":76,"context_line":"non-self-testing change to the Zuul job/template definitions that may break any"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_fb8fe074","line":73,"updated":"2018-10-30 16:23:26.000000000","message":"Should we specify which team is responsible for creating the new images from the new versions of the OSes? Is that the goal champion, or someone else?","commit_id":"b2c83c4513e7d3413400ed81098503786a3cd6b3"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"fa7f9d3663d20f5b171cba090c101eaeee5eea70","unresolved":false,"context_lines":[{"line_number":70,"context_line":"specifically identified in the Project Testing Interface \u003cpti-linux-distros\u003e`."},{"line_number":71,"context_line":"If there have, it will set an :doc:`OpenStack-wide goal \u003c../goals/index\u003e` to"},{"line_number":72,"context_line":"update any integration tests running on an older version of that distribution"},{"line_number":73,"context_line":"to run on the new release."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"The goal champion(s) may choose to make a hard cut-over (i.e. a"},{"line_number":76,"context_line":"non-self-testing change to the Zuul job/template definitions that may break any"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_af17e253","line":73,"in_reply_to":"3f79a3b5_3407a5cb","updated":"2018-10-30 20:00:00.000000000","message":"We need to say something about who we expect to do the work, though. Otherwise we\u0027re just writing down wishes. If it\u0027s going to be the responsibility of the goal champions, those folks need to know that before they sign up for the job.","commit_id":"b2c83c4513e7d3413400ed81098503786a3cd6b3"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"8f6c31b9f2721f8ae7aa29e67ad4bfcee16d4c2d","unresolved":false,"context_lines":[{"line_number":70,"context_line":"specifically identified in the Project Testing Interface \u003cpti-linux-distros\u003e`."},{"line_number":71,"context_line":"If there have, it will set an :doc:`OpenStack-wide goal \u003c../goals/index\u003e` to"},{"line_number":72,"context_line":"update any integration tests running on an older version of that distribution"},{"line_number":73,"context_line":"to run on the new release."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"The goal champion(s) may choose to make a hard cut-over (i.e. a"},{"line_number":76,"context_line":"non-self-testing change to the Zuul job/template definitions that may break any"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_34277769","line":73,"in_reply_to":"3f79a3b5_af17e253","updated":"2018-11-01 17:58:25.000000000","message":"Agreed. My question is, do we need to say it now, or can we say it at the time we set the goal? I\u0027d expect things to evolve over time, and TC resolutions are hard to change once they\u0027re approved.","commit_id":"b2c83c4513e7d3413400ed81098503786a3cd6b3"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"b26cc67d3776930bd67fe4a6d9e6fe3c4962800a","unresolved":false,"context_lines":[{"line_number":70,"context_line":"specifically identified in the Project Testing Interface \u003cpti-linux-distros\u003e`."},{"line_number":71,"context_line":"If there have, it will set an :doc:`OpenStack-wide goal \u003c../goals/index\u003e` to"},{"line_number":72,"context_line":"update any integration tests running on an older version of that distribution"},{"line_number":73,"context_line":"to run on the new release."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"The goal champion(s) may choose to make a hard cut-over (i.e. a"},{"line_number":76,"context_line":"non-self-testing change to the Zuul job/template definitions that may break any"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f79a3b5_3407a5cb","line":73,"in_reply_to":"3f79a3b5_fb8fe074","updated":"2018-10-30 19:07:50.000000000","message":"I don\u0027t think the goal champion(s) would necessarily have to personally build the images, but it would be up to them to project-manage in whatever way they see fit (and I\u0027d prefer to avoid being too prescriptive here, since they will likely have more information than we currently do).","commit_id":"b2c83c4513e7d3413400ed81098503786a3cd6b3"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"55c2380699f38a8faa11fe92a9c4d2ba4900ced3","unresolved":false,"context_lines":[{"line_number":31,"context_line":"* Each Python 3 version that is the default in any of the :ref:`Linux"},{"line_number":32,"context_line":"  distributions specifically identified in the Project Testing Interface"},{"line_number":33,"context_line":"  \u003cpti-linux-distros\u003e`, including any older releases of those distributions"},{"line_number":34,"context_line":"  that were still used in integration tests at the beginning of the cycle."},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"Where the supported versions are not contiguous, any intermediate minor"},{"line_number":37,"context_line":"versions may be tested if the TC judges it likely that they may need to be"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_73f57751","line":34,"updated":"2018-11-08 16:25:56.000000000","message":"This sounds like we might end up supporting 2 versions of a distro for a cycle.","commit_id":"fdc8d034ca1f06af816d3f987ef3c6334abda9e3"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"040c32a2f2561a01000f5175a7172053383cd03a","unresolved":false,"context_lines":[{"line_number":31,"context_line":"* Each Python 3 version that is the default in any of the :ref:`Linux"},{"line_number":32,"context_line":"  distributions specifically identified in the Project Testing Interface"},{"line_number":33,"context_line":"  \u003cpti-linux-distros\u003e`, including any older releases of those distributions"},{"line_number":34,"context_line":"  that were still used in integration tests at the beginning of the cycle."},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"Where the supported versions are not contiguous, any intermediate minor"},{"line_number":37,"context_line":"versions may be tested if the TC judges it likely that they may need to be"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_d63799da","line":34,"in_reply_to":"3f79a3b5_73f57751","updated":"2018-11-08 16:39:12.000000000","message":"Unfortunately I think this is inevitable.\n\ne.g. right now we have a bunch of integration tests running on py35 (Xenial). If projects were to drop py35 support and only run py36 and py37 unit tests, and upgrade their own integration tests to py36 (Bionic), then they could break other projects that are still running tests on Xenial.\n\nThis time around there\u0027s no possibility of introducing py36-only syntax because of the existence of py27 jobs, but that won\u0027t be the case in future, and there are other potential subtleties: http://lists.openstack.org/pipermail/openstack-dev/2018-October/135772.html\n\nI can\u0027t think of a mechanism that could ensure that all integration jobs get converted before the unit test templates flip over - and in fact in general I think we will want to get the new unit tests running first (since they\u0027re easier to debug). I\u0027m open to ideas if I\u0027ve missed something though.","commit_id":"fdc8d034ca1f06af816d3f987ef3c6334abda9e3"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"ad04db518ad89ad15d3b9df4b53570ecb804c87c","unresolved":false,"context_lines":[{"line_number":31,"context_line":"* Each Python 3 version that is the default in any of the :ref:`Linux"},{"line_number":32,"context_line":"  distributions specifically identified in the Project Testing Interface"},{"line_number":33,"context_line":"  \u003cpti-linux-distros\u003e`, including any older releases of those distributions"},{"line_number":34,"context_line":"  that were still used in integration tests at the beginning of the cycle."},{"line_number":35,"context_line":""},{"line_number":36,"context_line":"Where the supported versions are not contiguous, any intermediate minor"},{"line_number":37,"context_line":"versions may be tested if the TC judges it likely that they may need to be"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_0c366402","line":34,"in_reply_to":"3f79a3b5_d63799da","updated":"2018-11-08 18:28:02.000000000","message":"I think I agree with your reasoning. It would be good to include that in the body of the document somewhere for easier reference in the future.","commit_id":"fdc8d034ca1f06af816d3f987ef3c6334abda9e3"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"55c2380699f38a8faa11fe92a9c4d2ba4900ced3","unresolved":false,"context_lines":[{"line_number":35,"context_line":""},{"line_number":36,"context_line":"Where the supported versions are not contiguous, any intermediate minor"},{"line_number":37,"context_line":"versions may be tested if the TC judges it likely that they may need to be"},{"line_number":38,"context_line":"supported in a future release, but only with periodic jobs."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"This decision will be encoded in a Zuul template for unit tests named"},{"line_number":41,"context_line":"``openstack-python3-\u003creleasename\u003e-jobs``, containing:"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_13e523a3","line":38,"range":{"start_line":38,"start_character":31,"end_line":38,"end_character":59},"updated":"2018-11-08 16:25:56.000000000","message":"Does this mean those versions \"may only be tested with periodic jobs\" or that they may be tested, but don\u0027t have to use gate jobs and can use periodic jobs?","commit_id":"fdc8d034ca1f06af816d3f987ef3c6334abda9e3"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"040c32a2f2561a01000f5175a7172053383cd03a","unresolved":false,"context_lines":[{"line_number":35,"context_line":""},{"line_number":36,"context_line":"Where the supported versions are not contiguous, any intermediate minor"},{"line_number":37,"context_line":"versions may be tested if the TC judges it likely that they may need to be"},{"line_number":38,"context_line":"supported in a future release, but only with periodic jobs."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"This decision will be encoded in a Zuul template for unit tests named"},{"line_number":41,"context_line":"``openstack-python3-\u003creleasename\u003e-jobs``, containing:"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_1652f111","line":38,"range":{"start_line":38,"start_character":31,"end_line":38,"end_character":59},"in_reply_to":"3f79a3b5_13e523a3","updated":"2018-11-08 16:39:12.000000000","message":"* We\u0027ll only test them if we think we might need to support them in future\n* If we test them, we\u0027ll only use periodic jobs, not check or gate jobs\n\nll. 43-45 hopefully makes this clearer.\n\nWould changing \"may be tested if...\" to \"should be tested if...\" remove the ambiguity?","commit_id":"fdc8d034ca1f06af816d3f987ef3c6334abda9e3"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"ad04db518ad89ad15d3b9df4b53570ecb804c87c","unresolved":false,"context_lines":[{"line_number":35,"context_line":""},{"line_number":36,"context_line":"Where the supported versions are not contiguous, any intermediate minor"},{"line_number":37,"context_line":"versions may be tested if the TC judges it likely that they may need to be"},{"line_number":38,"context_line":"supported in a future release, but only with periodic jobs."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"This decision will be encoded in a Zuul template for unit tests named"},{"line_number":41,"context_line":"``openstack-python3-\u003creleasename\u003e-jobs``, containing:"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f79a3b5_472435b2","line":38,"range":{"start_line":38,"start_character":31,"end_line":38,"end_character":59},"in_reply_to":"3f79a3b5_1652f111","updated":"2018-11-08 18:28:02.000000000","message":"I think the \"may be tested\" is fine. Expanding on the \"only with periodic jobs\" part would clarify. Maybe:\n\n  supported in a future release. Only periodic jobs need to be used\n  for any such tests.\n\nThat leaves open the option for a team to decide to do more, without requiring it.","commit_id":"fdc8d034ca1f06af816d3f987ef3c6334abda9e3"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"c9c0975f8591582339afc23efe357e25f40c63b5","unresolved":false,"context_lines":[{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Prior to the beginning of each release cycle, the TC will designate the minor"},{"line_number":23,"context_line":"versions of Python 3 that will be supported in that release using the following"},{"line_number":24,"context_line":"criteria:"},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"* The latest released version of Python 3 that is available in *any*"},{"line_number":27,"context_line":"  distribution we can feasibly use for testing. It need not be a"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_ea69c1be","line":24,"updated":"2018-12-06 01:51:13.000000000","message":"Thanks, yeah, there is an inconsistency there that I have been trying to avoid commenting on ;)\n\nI think part of it is that there\u0027s general agreement that it\u0027s too late to apply the first bullet point (forward-looking releases) to Stein.\n\nBut the other part is that handling the third bullet point is kind of awkward - we\u0027re only testing it to give other projects time to migrate their integration test, so it\u0027s not something we plan to \u0027support\u0027 in the release, but at the same time it needs to be in the Zuul template. I\u0027ll add some comments in that review.\n\nI modified the follow-up patch to this one to replace the word \u0027supported\u0027 with \u0027tested\u0027, to avoid clearing all the votes here since it\u0027s not a substantive change.","commit_id":"8d822a0447ced4295868e996fd8362f764eca2d2"},{"author":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"change_message_id":"8b9a0cf2156df33b4f8a4e1500b9272806737104","unresolved":false,"context_lines":[{"line_number":19,"context_line":"Unit Tests"},{"line_number":20,"context_line":"----------"},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Prior to the beginning of each release cycle, the TC will designate the minor"},{"line_number":23,"context_line":"versions of Python 3 that will be supported in that release using the following"},{"line_number":24,"context_line":"criteria:"},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"* The latest released version of Python 3 that is available in *any*"},{"line_number":27,"context_line":"  distribution we can feasibly use for testing. It need not be a"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_56fc220d","line":24,"range":{"start_line":22,"start_character":0,"end_line":24,"end_character":9},"updated":"2018-12-05 22:00:15.000000000","message":"This is not the criteria used in the proposal for Stein [1], which only currently considers 1 of these 3 bullets (the second).\n\nI think the other commit is intended to cover what will be supported, and despite the use of that word here what we\u0027re really talking about in this commit is how we\u0027ll go about handling python versions in our testing, which will be a superset of what we actually end up supporting in a given release, since we want to do some forward-looking testing (bullet 1) and will need to transition away from our previous testing during the course of the release cycle (bullet 3).\n\n[1] https://review.openstack.org/611080","commit_id":"8d822a0447ced4295868e996fd8362f764eca2d2"},{"author":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"change_message_id":"97672714cc328b6d73a49e660bec6a8aca919c35","unresolved":false,"context_lines":[{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Prior to the beginning of each release cycle, the TC will designate the minor"},{"line_number":23,"context_line":"versions of Python 3 that will be supported in that release using the following"},{"line_number":24,"context_line":"criteria:"},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"* The latest released version of Python 3 that is available in *any*"},{"line_number":27,"context_line":"  distribution we can feasibly use for testing. It need not be a"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_f2dbe148","line":24,"in_reply_to":"3f79a3b5_ea69c1be","updated":"2018-12-06 22:58:02.000000000","message":"yep, the followup LGTM, so I\u0027ll remove my -1.","commit_id":"8d822a0447ced4295868e996fd8362f764eca2d2"},{"author":{"_account_id":5263,"name":"Jeremy Stanley","display_name":"fungi","email":"fungi@yuggoth.org","username":"fungi","status":"missing, presumed fed"},"change_message_id":"a6bdb7fac6cfc6dd9f9a82d765d1179d947ead90","unresolved":false,"context_lines":[{"line_number":27,"context_line":"  distribution we can feasibly use for testing. It need not be a"},{"line_number":28,"context_line":"  long-term-supported release, but could be a non-LTS version of Ubuntu,"},{"line_number":29,"context_line":"  Fedora, openSUSE Leap, or even a rolling release distribution (such as Debian"},{"line_number":30,"context_line":"  Testing or openSUSE Tumbleweed) if necessary."},{"line_number":31,"context_line":"* Each Python 3 version that is the default in any of the :ref:`Linux"},{"line_number":32,"context_line":"  distributions specifically identified in the Project Testing Interface"},{"line_number":33,"context_line":"  \u003cpti-linux-distros\u003e` at the beginning of the development cycle."}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_45ddcd10","line":30,"updated":"2018-11-29 15:30:10.000000000","message":"Do we need to make it clear that this is only for testing changes on master, and that we\u0027ll drop this from stable branches? Keep in mind that in most cases the distros we\u0027d use for this purpose have significantly shorter support lifetimes than the stable branches we want to test, so using only LTS versions of server distributions would be necessary to maintain stability of testing on those branches.","commit_id":"8d822a0447ced4295868e996fd8362f764eca2d2"},{"author":{"_account_id":5263,"name":"Jeremy Stanley","display_name":"fungi","email":"fungi@yuggoth.org","username":"fungi","status":"missing, presumed fed"},"change_message_id":"5551ce6419647ed02cc6c982f53ab0f3142b9a15","unresolved":false,"context_lines":[{"line_number":27,"context_line":"  distribution we can feasibly use for testing. It need not be a"},{"line_number":28,"context_line":"  long-term-supported release, but could be a non-LTS version of Ubuntu,"},{"line_number":29,"context_line":"  Fedora, openSUSE Leap, or even a rolling release distribution (such as Debian"},{"line_number":30,"context_line":"  Testing or openSUSE Tumbleweed) if necessary."},{"line_number":31,"context_line":"* Each Python 3 version that is the default in any of the :ref:`Linux"},{"line_number":32,"context_line":"  distributions specifically identified in the Project Testing Interface"},{"line_number":33,"context_line":"  \u003cpti-linux-distros\u003e` at the beginning of the development cycle."}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_8aeec2b3","line":30,"updated":"2018-12-10 15:40:19.000000000","message":"Well, getting stable branch dependencies working on newer distros than are contemporary can present significant challenges. Take for example a dependency which relies on build-time linking against libssl 1.0 and a newer distro release which drops that library version. Our choices are to try to upfit the stable branch source to work with a newer dep (that rabbit hole can be a deep one) or drop the job. Over time the need to address situations like this becomes increasingly likely as the age of our non-pure-Python dependencies diverges further and further from the age of the platforms on which we want to be able to install them. I think we at least need to acknowledge that it\u0027s probable we\u0027ll need to drop stable branch jobs for some Python versions which were run on non-LTS distros as those become unavailable to us, and I\u0027d prefer to see us just drop them as soon as the stable branch is created so as not to create unrealistic expectations for our users.","commit_id":"8d822a0447ced4295868e996fd8362f764eca2d2"},{"author":{"_account_id":5263,"name":"Jeremy Stanley","display_name":"fungi","email":"fungi@yuggoth.org","username":"fungi","status":"missing, presumed fed"},"change_message_id":"e3776d0fef2e5f9be50d7e348ec47801e2e6a52d","unresolved":false,"context_lines":[{"line_number":27,"context_line":"  distribution we can feasibly use for testing. It need not be a"},{"line_number":28,"context_line":"  long-term-supported release, but could be a non-LTS version of Ubuntu,"},{"line_number":29,"context_line":"  Fedora, openSUSE Leap, or even a rolling release distribution (such as Debian"},{"line_number":30,"context_line":"  Testing or openSUSE Tumbleweed) if necessary."},{"line_number":31,"context_line":"* Each Python 3 version that is the default in any of the :ref:`Linux"},{"line_number":32,"context_line":"  distributions specifically identified in the Project Testing Interface"},{"line_number":33,"context_line":"  \u003cpti-linux-distros\u003e` at the beginning of the development cycle."}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_e63e6026","line":30,"updated":"2018-11-29 17:14:33.000000000","message":"Well, it\u0027s that and also we don\u0027t want to put ourselves in a position where we have to get stable branches testable on newer and newer distro releases over time. Better to limit testing of stable branch changes to platforms we know will be around for the entire duration.","commit_id":"8d822a0447ced4295868e996fd8362f764eca2d2"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"8e39ab1775b711205fbcb5209b7655625a620737","unresolved":false,"context_lines":[{"line_number":27,"context_line":"  distribution we can feasibly use for testing. It need not be a"},{"line_number":28,"context_line":"  long-term-supported release, but could be a non-LTS version of Ubuntu,"},{"line_number":29,"context_line":"  Fedora, openSUSE Leap, or even a rolling release distribution (such as Debian"},{"line_number":30,"context_line":"  Testing or openSUSE Tumbleweed) if necessary."},{"line_number":31,"context_line":"* Each Python 3 version that is the default in any of the :ref:`Linux"},{"line_number":32,"context_line":"  distributions specifically identified in the Project Testing Interface"},{"line_number":33,"context_line":"  \u003cpti-linux-distros\u003e` at the beginning of the development cycle."}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_46bf14ac","line":30,"in_reply_to":"3f79a3b5_45ddcd10","updated":"2018-11-29 17:11:33.000000000","message":"I think that saying \"that we can feasibly use for testing\" covers us there, but we could be more explicit about saying that we won\u0027t go to extraordinary lengths to maintain images for testing on stable branches over time.","commit_id":"8d822a0447ced4295868e996fd8362f764eca2d2"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"fa7326f8f8d32a4b87ad6e936a8d5323dca0c087","unresolved":false,"context_lines":[{"line_number":27,"context_line":"  distribution we can feasibly use for testing. It need not be a"},{"line_number":28,"context_line":"  long-term-supported release, but could be a non-LTS version of Ubuntu,"},{"line_number":29,"context_line":"  Fedora, openSUSE Leap, or even a rolling release distribution (such as Debian"},{"line_number":30,"context_line":"  Testing or openSUSE Tumbleweed) if necessary."},{"line_number":31,"context_line":"* Each Python 3 version that is the default in any of the :ref:`Linux"},{"line_number":32,"context_line":"  distributions specifically identified in the Project Testing Interface"},{"line_number":33,"context_line":"  \u003cpti-linux-distros\u003e` at the beginning of the development cycle."}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_65a21b43","line":30,"in_reply_to":"3f79a3b5_e63e6026","updated":"2018-12-02 22:52:55.000000000","message":"I think for the unit tests specifically, there should be fairly good separation of concerns between projects themselves and infra. i.e. the important thing for the project is that it has the right py3x jobs in its Zuul config. It doesn\u0027t know what distro that\u0027s running on and it shouldn\u0027t care (developers are already running the unit tests locally on a variety of distros). So if we need to switch out the distro that is running the job, that should be completely transparent. Generally we\u0027re going to need to do this anyway (when that version of Python shows up in an TLS distro, we\u0027ll want to switch the job over to that in order to run those tests on master), so I don\u0027t think it should be a lot of extra work for infra beyond the inital setup.\n\nThe main problem I can anticipate here is a version of Python that comes and goes without ever being included in an LTS distro (i.e. all the distros end up skipping right over it for their LTS releases). Python releases are not so frequent that I expect this to happen often though, and it certainly shouldn\u0027t be an issue for the next couple so we should see the problem coming with time to adjust course if necessary.\n\nOf course none of this applies to the integration tests (which also test integration with the OS), which is why we are still only proposing to run integration tests on the default versions of Python in LTS distros.","commit_id":"8d822a0447ced4295868e996fd8362f764eca2d2"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"0874962fa013e697e6e6e88d9596c7f1e1b14032","unresolved":false,"context_lines":[{"line_number":30,"context_line":"  Testing or openSUSE Tumbleweed) if necessary."},{"line_number":31,"context_line":"* Each Python 3 version that is the default in any of the :ref:`Linux"},{"line_number":32,"context_line":"  distributions specifically identified in the Project Testing Interface"},{"line_number":33,"context_line":"  \u003cpti-linux-distros\u003e` at the beginning of the development cycle."},{"line_number":34,"context_line":"* Each Python 3 version that was still used in any integration tests at the"},{"line_number":35,"context_line":"  beginning of the development cycle. (This category is neccessary to ensure"},{"line_number":36,"context_line":"  that projects don\u0027t break other projects\u0027 integration tests before those"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_396f322a","line":33,"updated":"2018-11-20 22:03:22.000000000","message":"I wonder if we want to be more detailed about setting a deadline for knowing what the versions are. For example, during Stein we didn\u0027t know what RHEL would include and so delayed our decision about what to support and what to drop. Should we be more clear about saying we do not want to do that again and that if distros want to ensure we\u0027re testing the version of python they\u0027re shipping, they need to tell us before the cycle starts?","commit_id":"8d822a0447ced4295868e996fd8362f764eca2d2"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"e0cef276a654c1bf8d92f715f799e0991ae8db5a","unresolved":false,"context_lines":[{"line_number":30,"context_line":"  Testing or openSUSE Tumbleweed) if necessary."},{"line_number":31,"context_line":"* Each Python 3 version that is the default in any of the :ref:`Linux"},{"line_number":32,"context_line":"  distributions specifically identified in the Project Testing Interface"},{"line_number":33,"context_line":"  \u003cpti-linux-distros\u003e` at the beginning of the development cycle."},{"line_number":34,"context_line":"* Each Python 3 version that was still used in any integration tests at the"},{"line_number":35,"context_line":"  beginning of the development cycle. (This category is neccessary to ensure"},{"line_number":36,"context_line":"  that projects don\u0027t break other projects\u0027 integration tests before those"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_39a4124c","line":33,"in_reply_to":"3f79a3b5_396f322a","updated":"2018-11-20 22:15:13.000000000","message":"We could take \"beginning\" literally here to mean \"the day it starts\"?","commit_id":"8d822a0447ced4295868e996fd8362f764eca2d2"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"63f91c30847224d182b5d633af65a486ddee9f4b","unresolved":false,"context_lines":[{"line_number":30,"context_line":"  Testing or openSUSE Tumbleweed) if necessary."},{"line_number":31,"context_line":"* Each Python 3 version that is the default in any of the :ref:`Linux"},{"line_number":32,"context_line":"  distributions specifically identified in the Project Testing Interface"},{"line_number":33,"context_line":"  \u003cpti-linux-distros\u003e` at the beginning of the development cycle."},{"line_number":34,"context_line":"* Each Python 3 version that was still used in any integration tests at the"},{"line_number":35,"context_line":"  beginning of the development cycle. (This category is neccessary to ensure"},{"line_number":36,"context_line":"  that projects don\u0027t break other projects\u0027 integration tests before those"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_3c43a042","line":33,"in_reply_to":"3f79a3b5_39a4124c","updated":"2018-11-20 22:28:00.000000000","message":"True. After thinking about how to define it I realized that we usually mark the end of a cycle with more emphasis than the start, so perhaps we should express it in terms of the end of the previous cycle. That has the added benefit of letting us add it as a deadline on the schedule maintained by the release team.","commit_id":"8d822a0447ced4295868e996fd8362f764eca2d2"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"a0edb0340b503da5992bf924c5115086f2cff12d","unresolved":false,"context_lines":[{"line_number":30,"context_line":"  Testing or openSUSE Tumbleweed) if necessary."},{"line_number":31,"context_line":"* Each Python 3 version that is the default in any of the :ref:`Linux"},{"line_number":32,"context_line":"  distributions specifically identified in the Project Testing Interface"},{"line_number":33,"context_line":"  \u003cpti-linux-distros\u003e` at the beginning of the development cycle."},{"line_number":34,"context_line":"* Each Python 3 version that was still used in any integration tests at the"},{"line_number":35,"context_line":"  beginning of the development cycle. (This category is neccessary to ensure"},{"line_number":36,"context_line":"  that projects don\u0027t break other projects\u0027 integration tests before those"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_fe82f150","line":33,"in_reply_to":"3f79a3b5_3c43a042","updated":"2018-11-21 14:30:02.000000000","message":"In practice the deadline is probably going to be when we\u0027re setting the release goals.\n\nI think the RHEL 8 situation was possibly unique because it was the first release with Python 3... there was no question at the beginning of the cycle that we would still have to support 2.7.","commit_id":"8d822a0447ced4295868e996fd8362f764eca2d2"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"d7be3e7e0f71d433ab81175fe242f9b9a57b2d93","unresolved":false,"context_lines":[{"line_number":30,"context_line":"  Testing or openSUSE Tumbleweed) if necessary."},{"line_number":31,"context_line":"* Each Python 3 version that is the default in any of the :ref:`Linux"},{"line_number":32,"context_line":"  distributions specifically identified in the Project Testing Interface"},{"line_number":33,"context_line":"  \u003cpti-linux-distros\u003e` at the beginning of the development cycle."},{"line_number":34,"context_line":"* Each Python 3 version that was still used in any integration tests at the"},{"line_number":35,"context_line":"  beginning of the development cycle. (This category is neccessary to ensure"},{"line_number":36,"context_line":"  that projects don\u0027t break other projects\u0027 integration tests before those"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_85852505","line":33,"in_reply_to":"3f79a3b5_7ec26137","updated":"2018-11-29 15:29:48.000000000","message":"On further reflection, I think having a \"loose\" deadline is probably just as well. It gives us flexibility to declare a decision point for each dev cycle based on our needs, rather than forcing us to follow the same process each time.","commit_id":"8d822a0447ced4295868e996fd8362f764eca2d2"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"d87ac105f3758eeed4ad6dd6494276edce246996","unresolved":false,"context_lines":[{"line_number":30,"context_line":"  Testing or openSUSE Tumbleweed) if necessary."},{"line_number":31,"context_line":"* Each Python 3 version that is the default in any of the :ref:`Linux"},{"line_number":32,"context_line":"  distributions specifically identified in the Project Testing Interface"},{"line_number":33,"context_line":"  \u003cpti-linux-distros\u003e` at the beginning of the development cycle."},{"line_number":34,"context_line":"* Each Python 3 version that was still used in any integration tests at the"},{"line_number":35,"context_line":"  beginning of the development cycle. (This category is neccessary to ensure"},{"line_number":36,"context_line":"  that projects don\u0027t break other projects\u0027 integration tests before those"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_7ec26137","line":33,"in_reply_to":"3f79a3b5_fe82f150","updated":"2018-11-21 14:53:01.000000000","message":"This may have been a unique case. I seem to remember that we had similar issues in the past when moving from 2.6 to 2.7 and not knowing exactly when we would be able to drop 2.6 support.\n\nYour point about the goals selection date being the deadline is reasonable. I don\u0027t think we have a formal date set for choosing those right now, though. Perhaps the thing to do is set the deadline when we know (or anticipate) needing to update versions.","commit_id":"8d822a0447ced4295868e996fd8362f764eca2d2"},{"author":{"_account_id":10608,"name":"Matthew Edmonds","email":"edmondsw@us.ibm.com","username":"edmondsw"},"change_message_id":"8b9a0cf2156df33b4f8a4e1500b9272806737104","unresolved":false,"context_lines":[{"line_number":32,"context_line":"  distributions specifically identified in the Project Testing Interface"},{"line_number":33,"context_line":"  \u003cpti-linux-distros\u003e` at the beginning of the development cycle."},{"line_number":34,"context_line":"* Each Python 3 version that was still used in any integration tests at the"},{"line_number":35,"context_line":"  beginning of the development cycle. (This category is neccessary to ensure"},{"line_number":36,"context_line":"  that projects don\u0027t break other projects\u0027 integration tests before those"},{"line_number":37,"context_line":"  tests have completely migrated to newer distributions.) Support for these"},{"line_number":38,"context_line":"  versions can be dropped once all integration tests have migrated."}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_76d6fec3","line":35,"range":{"start_line":35,"start_character":56,"end_line":35,"end_character":66},"updated":"2018-12-05 22:00:15.000000000","message":"necessary*","commit_id":"8d822a0447ced4295868e996fd8362f764eca2d2"},{"author":{"_account_id":5263,"name":"Jeremy Stanley","display_name":"fungi","email":"fungi@yuggoth.org","username":"fungi","status":"missing, presumed fed"},"change_message_id":"5551ce6419647ed02cc6c982f53ab0f3142b9a15","unresolved":false,"context_lines":[{"line_number":35,"context_line":"  beginning of the development cycle. (This category is neccessary to ensure"},{"line_number":36,"context_line":"  that projects don\u0027t break other projects\u0027 integration tests before those"},{"line_number":37,"context_line":"  tests have completely migrated to newer distributions.) Support for these"},{"line_number":38,"context_line":"  versions can be dropped once all integration tests have migrated."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"Where the supported versions are not contiguous, any intermediate minor"},{"line_number":41,"context_line":"versions may be tested if the TC judges it likely that they may need to be"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_2ae9aeaa","line":38,"updated":"2018-12-10 15:40:19.000000000","message":"(...and by the end of the release cycle at the absolute latest? I\u0027d rather see projects which have dragged their heels and failed to complete transition break on the older no-longer-targeted interpreter than force all projects to support that well into their stable branches.)","commit_id":"8d822a0447ced4295868e996fd8362f764eca2d2"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"25179e4899e1b4b2a09603661e22b349e93288e3","unresolved":false,"context_lines":[{"line_number":35,"context_line":"  beginning of the development cycle. (This category is neccessary to ensure"},{"line_number":36,"context_line":"  that projects don\u0027t break other projects\u0027 integration tests before those"},{"line_number":37,"context_line":"  tests have completely migrated to newer distributions.) Support for these"},{"line_number":38,"context_line":"  versions can be dropped once all integration tests have migrated."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"Where the supported versions are not contiguous, any intermediate minor"},{"line_number":41,"context_line":"versions may be tested if the TC judges it likely that they may need to be"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_a6d64bf7","line":38,"in_reply_to":"3f79a3b5_2ae9aeaa","updated":"2018-12-11 03:57:23.000000000","message":"We kind of punted the decision of what do do about projects dragging their feet on migrating integration tests to the goal champions in the last paragraph of this resolution. So maybe this needs to be something that\u0027s considered as part of that process? Or just limit it to the master branch at the time we set up the template?\n\nI do tend to agree with you that all bets should be off as far as other projects doing stuff to keep their integration tests working if they don\u0027t meet the release goals.","commit_id":"8d822a0447ced4295868e996fd8362f764eca2d2"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"4679f8bc552c66bbf53416815f5d20c76e3bbb79","unresolved":false,"context_lines":[{"line_number":35,"context_line":"  beginning of the development cycle. (This category is neccessary to ensure"},{"line_number":36,"context_line":"  that projects don\u0027t break other projects\u0027 integration tests before those"},{"line_number":37,"context_line":"  tests have completely migrated to newer distributions.) Support for these"},{"line_number":38,"context_line":"  versions can be dropped once all integration tests have migrated."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"Where the supported versions are not contiguous, any intermediate minor"},{"line_number":41,"context_line":"versions may be tested if the TC judges it likely that they may need to be"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_6cffaa68","line":38,"in_reply_to":"3f79a3b5_a6d64bf7","updated":"2018-12-11 14:34:01.000000000","message":"This seems like the sort of thing we might want to decide on a case-by-case basis. If we end up with a version that\u0027s a tough transition, we might need to give teams more than a cycle to make the change. So rather than encoding the deadlines here, maybe we should say that the champions should lay out those deadlines for each transition as it comes up.","commit_id":"8d822a0447ced4295868e996fd8362f764eca2d2"},{"author":{"_account_id":5263,"name":"Jeremy Stanley","display_name":"fungi","email":"fungi@yuggoth.org","username":"fungi","status":"missing, presumed fed"},"change_message_id":"5551ce6419647ed02cc6c982f53ab0f3142b9a15","unresolved":false,"context_lines":[{"line_number":38,"context_line":"  versions can be dropped once all integration tests have migrated."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"Where the supported versions are not contiguous, any intermediate minor"},{"line_number":41,"context_line":"versions may be tested if the TC judges it likely that they may need to be"},{"line_number":42,"context_line":"supported in a future release. However only periodic jobs (not check or gate"},{"line_number":43,"context_line":"jobs) are needed for these versions."},{"line_number":44,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_4ae42ad3","line":41,"updated":"2018-12-10 15:40:19.000000000","message":"Grenade\u0027s assumption about upgrading OpenStack services has always been that you\u0027re running the old version of the code on your old distro/interpreter and the new version of the code on your new distro/interpreter. We\u0027ve failed to reflect that sort of transition with our jobs in the past mainly because multi-node jobs with different distros on each node really only became possible in Zuul v3, and in-place distro upgrades would significantly extend the runtime of a single-node job attempting this.","commit_id":"8d822a0447ced4295868e996fd8362f764eca2d2"},{"author":{"_account_id":6593,"name":"Dirk Mueller","email":"dirk@dmllr.de","username":"dmllr"},"change_message_id":"e3d686453b1411d2e6fe271bef701edd7cf5f7ec","unresolved":false,"context_lines":[{"line_number":38,"context_line":"  versions can be dropped once all integration tests have migrated."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"Where the supported versions are not contiguous, any intermediate minor"},{"line_number":41,"context_line":"versions may be tested if the TC judges it likely that they may need to be"},{"line_number":42,"context_line":"supported in a future release. However only periodic jobs (not check or gate"},{"line_number":43,"context_line":"jobs) are needed for these versions."},{"line_number":44,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_5acd2a59","line":41,"range":{"start_line":41,"start_character":0,"end_line":41,"end_character":8},"updated":"2018-11-21 20:57:41.000000000","message":"I wonder if this should specify how to handle grenade tests. Ideally I\u0027d think that for the purpose of grenade testing it should be possible to begin and end on a single python3 minor version? Should we write down that a switchover can only be done after the previous release is fully runable with the same minor version?","commit_id":"8d822a0447ced4295868e996fd8362f764eca2d2"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"d1618d61304ca888b733b8557fcb5ee5efeaa060","unresolved":false,"context_lines":[{"line_number":38,"context_line":"  versions can be dropped once all integration tests have migrated."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"Where the supported versions are not contiguous, any intermediate minor"},{"line_number":41,"context_line":"versions may be tested if the TC judges it likely that they may need to be"},{"line_number":42,"context_line":"supported in a future release. However only periodic jobs (not check or gate"},{"line_number":43,"context_line":"jobs) are needed for these versions."},{"line_number":44,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_7ad73f23","line":41,"in_reply_to":"3f79a3b5_2ec67b16","updated":"2018-12-12 14:02:21.000000000","message":"OK, so I think we have a reasonable amount of coverage for upstream testing of upgrades.","commit_id":"8d822a0447ced4295868e996fd8362f764eca2d2"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"4679f8bc552c66bbf53416815f5d20c76e3bbb79","unresolved":false,"context_lines":[{"line_number":38,"context_line":"  versions can be dropped once all integration tests have migrated."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"Where the supported versions are not contiguous, any intermediate minor"},{"line_number":41,"context_line":"versions may be tested if the TC judges it likely that they may need to be"},{"line_number":42,"context_line":"supported in a future release. However only periodic jobs (not check or gate"},{"line_number":43,"context_line":"jobs) are needed for these versions."},{"line_number":44,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_ec209afb","line":41,"in_reply_to":"3f79a3b5_4ae42ad3","updated":"2018-12-11 14:34:01.000000000","message":"As long as we have test jobs that run tempest on the old and new python and a grenade job that runs an upgrade test using the new python then I don\u0027t see any reason to worry about having an upstream test that changes python versions. Any dependency management issues around that sort of change are OS-level things that downstream distros can and should test on their own.","commit_id":"8d822a0447ced4295868e996fd8362f764eca2d2"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"e88a65dc3d8629bf64e893ea9104bd0502a2f82a","unresolved":false,"context_lines":[{"line_number":38,"context_line":"  versions can be dropped once all integration tests have migrated."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"Where the supported versions are not contiguous, any intermediate minor"},{"line_number":41,"context_line":"versions may be tested if the TC judges it likely that they may need to be"},{"line_number":42,"context_line":"supported in a future release. However only periodic jobs (not check or gate"},{"line_number":43,"context_line":"jobs) are needed for these versions."},{"line_number":44,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_9bcaaf6c","line":41,"range":{"start_line":41,"start_character":0,"end_line":41,"end_character":8},"in_reply_to":"3f79a3b5_5acd2a59","updated":"2018-11-26 17:36:26.000000000","message":"This is a good point. I guess we probably have always run grenade on py27 and never had to account for this issue before. Thinking about it, running the unit tests for the previously supported Python version is definitely not sufficient to prevent grenade breakage (to do that we\u0027d probably also have to double up on integration tests for a release after the supported version changes, which I don\u0027t think we want to do). And it\u0027s probably not strictly necessary either, because any problems should block grenade in the project\u0027s own gate, so the change won\u0027t land and block other projects gates. It probably would make it easier on developers by detecting problems quicker, though.\n\nI think that the stuff on line 34-38 effectively covers this already anyway. i.e. given that Rocky supported py35 then Stein has to continue unit tests against py35 even though we only need to support py36, so that integration tests in other projects that haven\u0027t been updated from Xenial-\u003eBionic yet don\u0027t break; and this also helps ensure you can run a grenade test going from Rocky-\u003eStein on py35. If this is indeed another justification for line 34-38 then we should definitely document it there.","commit_id":"8d822a0447ced4295868e996fd8362f764eca2d2"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"9d96b1f99dafb7b7df0057dbc805bdf586336d69","unresolved":false,"context_lines":[{"line_number":38,"context_line":"  versions can be dropped once all integration tests have migrated."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"Where the supported versions are not contiguous, any intermediate minor"},{"line_number":41,"context_line":"versions may be tested if the TC judges it likely that they may need to be"},{"line_number":42,"context_line":"supported in a future release. However only periodic jobs (not check or gate"},{"line_number":43,"context_line":"jobs) are needed for these versions."},{"line_number":44,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_2ec67b16","line":41,"in_reply_to":"3f79a3b5_ec209afb","updated":"2018-12-12 01:24:14.000000000","message":"we do started the grenade-py3 job also along with py27 job. And yes, we can always have new 3X version based on source and target branch support. \n\nas Jeremy mentioned about upgrading with old to new distro/interpreter, we are also moving grenade job to zuulv3 so that we can judge such cases easily.","commit_id":"8d822a0447ced4295868e996fd8362f764eca2d2"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"e0cef276a654c1bf8d92f715f799e0991ae8db5a","unresolved":false,"context_lines":[{"line_number":50,"context_line":"  supported in a future release, if any exist"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"The TC will set an :doc:`OpenStack-wide goal \u003c../goals/index\u003e` for each repo,"},{"line_number":53,"context_line":"prior to the end of the release, to:"},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"* update its Zuul config to the template for that release;"},{"line_number":56,"context_line":"* declare support for the tested versions in its PyPI package; and"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_59746ecd","line":53,"range":{"start_line":53,"start_character":0,"end_line":53,"end_character":31},"updated":"2018-11-20 22:15:13.000000000","message":"this sounds like the goal is going to make prior to the end of the release. Do you mean \"to be completed before the end of the release\"? Or something else?","commit_id":"8d822a0447ced4295868e996fd8362f764eca2d2"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"a0edb0340b503da5992bf924c5115086f2cff12d","unresolved":false,"context_lines":[{"line_number":50,"context_line":"  supported in a future release, if any exist"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"The TC will set an :doc:`OpenStack-wide goal \u003c../goals/index\u003e` for each repo,"},{"line_number":53,"context_line":"prior to the end of the release, to:"},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"* update its Zuul config to the template for that release;"},{"line_number":56,"context_line":"* declare support for the tested versions in its PyPI package; and"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_5ed68556","line":53,"range":{"start_line":53,"start_character":0,"end_line":53,"end_character":31},"in_reply_to":"3f79a3b5_59746ecd","updated":"2018-11-21 14:30:02.000000000","message":"Yes, the goal is for each repo to do something prior to the end of the release; we\u0027re not waiting to the end of the release to set the goal. Perhaps it would be less ambiguous if this phrase were after the \u0027to\u0027.","commit_id":"8d822a0447ced4295868e996fd8362f764eca2d2"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"d87ac105f3758eeed4ad6dd6494276edce246996","unresolved":false,"context_lines":[{"line_number":50,"context_line":"  supported in a future release, if any exist"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"The TC will set an :doc:`OpenStack-wide goal \u003c../goals/index\u003e` for each repo,"},{"line_number":53,"context_line":"prior to the end of the release, to:"},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"* update its Zuul config to the template for that release;"},{"line_number":56,"context_line":"* declare support for the tested versions in its PyPI package; and"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_de0db592","line":53,"range":{"start_line":53,"start_character":0,"end_line":53,"end_character":31},"in_reply_to":"3f79a3b5_5ed68556","updated":"2018-11-21 14:53:01.000000000","message":"Goals are always implicitly meant to be done by the end of the cycle, so maybe we don\u0027t need to specify that here at all.","commit_id":"8d822a0447ced4295868e996fd8362f764eca2d2"},{"author":{"_account_id":4257,"name":"Zane Bitter","email":"zbitter@redhat.com","username":"zaneb"},"change_message_id":"fa7326f8f8d32a4b87ad6e936a8d5323dca0c087","unresolved":false,"context_lines":[{"line_number":50,"context_line":"  supported in a future release, if any exist"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"The TC will set an :doc:`OpenStack-wide goal \u003c../goals/index\u003e` for each repo,"},{"line_number":53,"context_line":"prior to the end of the release, to:"},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"* update its Zuul config to the template for that release;"},{"line_number":56,"context_line":"* declare support for the tested versions in its PyPI package; and"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_859f37f5","line":53,"range":{"start_line":53,"start_character":0,"end_line":53,"end_character":31},"in_reply_to":"3f79a3b5_65ad6982","updated":"2018-12-02 22:52:55.000000000","message":"Ack, will submit one.","commit_id":"8d822a0447ced4295868e996fd8362f764eca2d2"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"d7be3e7e0f71d433ab81175fe242f9b9a57b2d93","unresolved":false,"context_lines":[{"line_number":50,"context_line":"  supported in a future release, if any exist"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"The TC will set an :doc:`OpenStack-wide goal \u003c../goals/index\u003e` for each repo,"},{"line_number":53,"context_line":"prior to the end of the release, to:"},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"* update its Zuul config to the template for that release;"},{"line_number":56,"context_line":"* declare support for the tested versions in its PyPI package; and"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_65ad6982","line":53,"range":{"start_line":53,"start_character":0,"end_line":53,"end_character":31},"in_reply_to":"3f79a3b5_de0db592","updated":"2018-11-29 15:29:48.000000000","message":"I\u0027d be happy for us to change this wording in a follow-up.","commit_id":"8d822a0447ced4295868e996fd8362f764eca2d2"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"16cfeb562a65f5e4037ec904f4941c65d8a236a9","unresolved":false,"context_lines":[{"line_number":75,"context_line":"update any integration tests running on an older version of that distribution"},{"line_number":76,"context_line":"to run on the new release."},{"line_number":77,"context_line":""},{"line_number":78,"context_line":"The goal champion(s) may choose to make a hard cut-over (i.e. a"},{"line_number":79,"context_line":"non-self-testing change to the Zuul job/template definitions that may break any"},{"line_number":80,"context_line":"jobs that have not had incompatibilities fixed) of any unconverted test jobs at"},{"line_number":81,"context_line":"some point during the release cycle, to ensure that all OpenStack components"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_962a562b","line":78,"range":{"start_line":78,"start_character":4,"end_line":78,"end_character":19},"updated":"2018-12-11 10:49:34.000000000","message":"will we identify the goal champion at runtime ? or any specific team we identify well in advance. For example, QA team is doing integration testing jobs migration from xenial to bionic.\n\nOr in other word, these kind of py or distro updates are has to be done at start of release cycle so if we do not find goal champion on time then, it is always risk to finish the work on time. how about listing some horizontal team (infra, QA etc) as backup plan.","commit_id":"8d822a0447ced4295868e996fd8362f764eca2d2"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"9d96b1f99dafb7b7df0057dbc805bdf586336d69","unresolved":false,"context_lines":[{"line_number":75,"context_line":"update any integration tests running on an older version of that distribution"},{"line_number":76,"context_line":"to run on the new release."},{"line_number":77,"context_line":""},{"line_number":78,"context_line":"The goal champion(s) may choose to make a hard cut-over (i.e. a"},{"line_number":79,"context_line":"non-self-testing change to the Zuul job/template definitions that may break any"},{"line_number":80,"context_line":"jobs that have not had incompatibilities fixed) of any unconverted test jobs at"},{"line_number":81,"context_line":"some point during the release cycle, to ensure that all OpenStack components"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_4ecbb71b","line":78,"range":{"start_line":78,"start_character":4,"end_line":78,"end_character":19},"in_reply_to":"3f79a3b5_2c3bf2f2","updated":"2018-12-12 01:24:14.000000000","message":"ok, make sense. we can always reach to QA team if we do not find any. +1","commit_id":"8d822a0447ced4295868e996fd8362f764eca2d2"},{"author":{"_account_id":2472,"name":"Doug Hellmann","email":"dhellmann@redhat.com","username":"doug-hellmann"},"change_message_id":"4679f8bc552c66bbf53416815f5d20c76e3bbb79","unresolved":false,"context_lines":[{"line_number":75,"context_line":"update any integration tests running on an older version of that distribution"},{"line_number":76,"context_line":"to run on the new release."},{"line_number":77,"context_line":""},{"line_number":78,"context_line":"The goal champion(s) may choose to make a hard cut-over (i.e. a"},{"line_number":79,"context_line":"non-self-testing change to the Zuul job/template definitions that may break any"},{"line_number":80,"context_line":"jobs that have not had incompatibilities fixed) of any unconverted test jobs at"},{"line_number":81,"context_line":"some point during the release cycle, to ensure that all OpenStack components"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3f79a3b5_2c3bf2f2","line":78,"range":{"start_line":78,"start_character":4,"end_line":78,"end_character":19},"in_reply_to":"3f79a3b5_962a562b","updated":"2018-12-11 14:34:01.000000000","message":"If we can\u0027t find a champion by the start of the cycle, then the work is unlikely to happen, right? I would be happy to have the QA team helping and would certainly expect QA team members to be candidates for champions, but I\u0027m not sure it buys us much to say the QA team will do the work if we can\u0027t identify an individual to act as champion.","commit_id":"8d822a0447ced4295868e996fd8362f764eca2d2"}]}