[oslo] Single approve py37 patches
As the subject says, let's single approve the py37 job addition patches. They're machine-generated and part of a broader effort that has already been agreed upon, so as long as they're passing CI they should be fine.
-Ben
On Tue, Feb 19, 2019 at 09:31:30AM -0600, Ben Nemec wrote:
As the subject says, let's single approve the py37 job addition patches. They're machine-generated and part of a broader effort that has already been agreed upon, so as long as they're passing CI they should be fine.
-Ben
Somewhat related - I submitted this patch today:
https://review.openstack.org/#/c/637866/
The idea with this would be to control which Python versions would be run through a set of templates that makes it clear per-release cycle what is expected to be run.
It's maybe a little late to get all folks using this for stein, but I've added a template for it just in case we want to use it once we have stable/stein branches. We can also get some projects switched over before then on a best effort basis.
We would try to do some automation in Train to get everyone on that template right from the start.
For Stein, I have added py37 as a non-voting job since that was not our declared runtime. But we probably want to make sure there are no surprises once we switch to Train and it becomes the required Python 3 runtime.
It probably makes sense, especially for common libraries like oslo, to get these jobs now so we know they are ready ahead of Train. If/when we switch to using these templates we can clean up any now-redundant individual jobs.
Sean
On Tue, 2019-02-19 at 10:46 -0600, Sean McGinnis wrote:
On Tue, Feb 19, 2019 at 09:31:30AM -0600, Ben Nemec wrote:
As the subject says, let's single approve the py37 job addition patches. They're machine-generated and part of a broader effort that has already been agreed upon, so as long as they're passing CI they should be fine.
-Ben
Somewhat related - I submitted this patch today:
https://review.openstack.org/#/c/637866/
The idea with this would be to control which Python versions would be run through a set of templates that makes it clear per-release cycle what is expected to be run.
It's maybe a little late to get all folks using this for stein, but I've added a template for it just in case we want to use it once we have stable/stein branches. We can also get some projects switched over before then on a best effort basis.
We would try to do some automation in Train to get everyone on that template right from the start.
For Stein, I have added py37 as a non-voting job since that was not our declared runtime. But we probably want to make sure there are no surprises once we switch to Train and it becomes the required Python 3 runtime.
It probably makes sense, especially for common libraries like oslo, to get these jobs now so we know they are ready ahead of Train. If/when we switch to using these templates we can clean up any now-redundant individual jobs.
so ill approve https://review.openstack.org/#/c/610068/ once it passes ci to swap over os-vif to enable the python 3.7 jobs. but the question i have is the non clinet lib fereeze is next week. should i quickly sub a patch to swap to the stein template once https://review.openstack.org/#/c/637866/ merges? i can also submit a follow up to swap over to the the train template and -w it until RC1. is that the intention of https://review.openstack.org/#/c/637866/. or should i wait for automated proposals to use the templates?
Sean
Somewhat related - I submitted this patch today:
It's maybe a little late to get all folks using this for stein, but I've added a template for it just in case we want to use it once we have stable/stein branches. We can also get some projects switched over before then on a best effort basis.
We would try to do some automation in Train to get everyone on that template right from the start.
so ill approve https://review.openstack.org/#/c/610068/ once it passes ci to swap over os-vif to enable the python 3.7 jobs. but the question i have is the non clinet lib fereeze is next week. should i quickly sub a patch to swap to the stein template once https://review.openstack.org/#/c/637866/ merges? i can also submit a follow up to swap over to the the train template and -w it until RC1. is that the intention of https://review.openstack.org/#/c/637866/. or should i wait for automated proposals to use the templates?
Great questions!
I'm waiting to get more feedback from the community on the template approach. I (obviously) think it would be a good way to go, but I'd like to see that there's a little broader consensus on that approach.
Which all means, nothing should be held up at this point waiting for that to be approved. If it gets approved quickly - great, we can start switching over to it if we still can and the teams want to yet in Stein. If it doesn't get approved, then hopefully there is no impact on any current in-flight plans.
As far as the lib freeze and releasing goes, this shouldn't really have an impact on that. Since it is a non-functional change (as in, it does not change how any of the libraries work, it just impacts which tests are run against them) it could still be merged after the lib freeze and would not need another release to be done just for its own sake.
Thanks! Sean
participants (3)
-
Ben Nemec
-
Sean McGinnis
-
Sean Mooney