| stephenfin | clarkb: to the best of my knowledge, yes | 10:59 |
|---|---|---|
| stephenfin | and yes, we should cut a release now. The pyproject.toml work is not tied to the same deadline so we can take our time fleshing that out and testing it | 11:00 |
| clarkb | stephenfin: sounds good. Were you going to propose the change to openstack releases? | 13:55 |
| dmsimard[m] | clarkb, fungi: o/ following up on french OVH emails, I may not be looking in the right place but the emails I do see that have been sent in the last couple months are in english. I'd like to fix it if it's still an issue. Could you forward me one ? | 13:58 |
| clarkb | dmsimard[m]: thank you for following up! I've just checked and I think you are right that the most recent emails (including the one about missing payment info) was sent in english. Some emails are sent with both french and english (which is fine). The last email I see in only french appears to be a marketing email on June 6 about swift | 14:03 |
| clarkb | dmsimard[m]: I think we're actually ok as is with that situation | 14:03 |
| dmsimard[m] | alright, thanks :D | 14:04 |
| fungi | yeah, i think the billing notifications may have gotten fixed maybe a year or so ago | 14:06 |
| fungi | clarkb: stephenfin: tkajinam: looking at releasing pbr now, the most recent version we have is 7.0.1 and there are 12 new changes in master but they're all test changes, refactoring, or non-user-facing (easy_install and pkg_resources removals) so 7.0.2 is probably fine? | 14:48 |
| fungi | no new features or backward-incompatible breaks that i can see | 14:48 |
| fungi | https://paste.opendev.org/show/b44rFGPCIHDt3GP5x4Sw/ | 14:48 |
| clarkb | fungi: yes my understanding is that all of the impactful changes are actually on the setuptools side of things and pbr aims to be compatible with as large a range of setuptools as possible | 14:49 |
| stephenfin | fungi: I would release it at 7.1.0 purely because we remove the pbr.core module. Nothing should affect that but it had non-private functions in it | 14:51 |
| stephenfin | *should be affected | 14:51 |
| stephenfin | We also remove some methods, albeit unused internal methods | 14:52 |
| fungi | okay, fair, we can treat that as an api change, but then should it be 8.0.0 instead? | 14:52 |
| fungi | if we removed public functions from the api then that's effectively backward-incompatible when treating it as a supported interface | 14:52 |
| clarkb | was it ever an actual itnerface or just maybe so based on loose python conventions? | 14:53 |
| clarkb | I expect that setup hooks are where we'd run into problems if it was ever used as an interface so we could spot check those if we like. I'm happy with just using 8.0 though | 14:54 |
| fungi | yeah, it feels like either it's not a supported api in which case this is not a backward-compatibility break so it's 7.0.2, or it's treated as a break in a public api which then warrants 8.0.0 | 14:55 |
| clarkb | I spot checked zuul's setup hook and I think we are clear there. I'm not sure what other projects use them | 14:55 |
| clarkb | https://codesearch.opendev.org/?q=setup_hooks&i=nope&literal=nope&files=&excludeFiles=&repos= the list within opendev is actually quite small | 14:56 |
| clarkb | huh only zuul appears to supply a custom hook. The others explicitly list the default hook in PBR | 14:57 |
| clarkb | but that lives at pbr.hooks and I don't think that changed so we should be good | 14:57 |
| fungi | and i guess we should merge a change with a release note about that module going away if our concern is that we need a minor or major version increase to signal it | 14:59 |
| fungi | currently there are no release notes pending for the release | 15:00 |
| fungi | so to me it's either not a concern (7.0.2), or it's an api break (8.0.0) and we need to include a release note acknowledging that | 15:01 |
| fungi | every past major version increase has included at least one release note back to 4.0.0 when we started using them | 15:02 |
| clarkb | My read on the way opendev hosted projects use PBR is that this shouldnt' be a problem. That doesn't rule out someone hooking into it in a weird weird way (like maybe if somethin uses pbr like pbr uses setuptools) but I haven't heard of anyone doing that | 15:03 |
| stephenfin | Yeah, I think 7.0.2 since we don't provide a programmatic API. The 7.1.0 just felt "stronger" | 15:03 |
| stephenfin | since it's not purely bug fixes, and there are some tweaks to how we do things (like not using pkg_resources anywhere if we have packaging available) | 15:04 |
| fungi | since it's not user-facing i don't think it rises to the level of a feature addition though | 15:04 |
| clarkb | I think the release note would just say something like "Code from setuptools is vendored to avoid breakage when setuptools deletes that code. Internal refactoring has been performed as well to prepare PBR for setup.pyless pyproject.toml usage. Anyone relying on PBR internals may need to update." | 15:05 |
| fungi | it's basically a bug fix for a bug that doesn't exist yet but will very soon | 15:05 |
| fungi | okay, i proposed 7.0.2 in https://review.opendev.org/c/openstack/releases/+/965245 | 15:08 |
| fungi | if people want to argue for a different number, we can move the discussion to review comments | 15:08 |
| opendevreview | Stephen Finucane proposed openstack/pbr master: Misc fixes https://review.opendev.org/c/openstack/pbr/+/965313 | 18:25 |
| opendevreview | Stephen Finucane proposed openstack/pbr master: tests: Rework integration tests https://review.opendev.org/c/openstack/pbr/+/965314 | 18:25 |
| opendevreview | Stephen Finucane proposed openstack/pbr master: DNM: Enable build isolation https://review.opendev.org/c/openstack/pbr/+/965315 | 18:25 |
| clarkb | I'd like for us to start moving off of bionic so that when zuul drops support for bionic (due to ansible updates) it isn't a shock to the system | 22:08 |
| clarkb | https://opendev.org/openstack/openstack-zuul-jobs/src/branch/master/zuul.d/jobs.yaml#L81-L104 stands out to me since we can run python 2.7 jobs on a platform other than bionic (it should work up to jammy) | 22:08 |
| clarkb | do you think we can just update that job to run on jammy? | 22:08 |
| clarkb | Then separately the openstack-tox-py36 and 37 jobs are probably just going to need to be deleted. I don't know how many things are running those jobs today | 22:09 |
| clarkb | pbr runs all three of them so maybe we wait for the release and setuptoosl changes before we really start hacking away at this | 22:09 |
| clarkb | openstack-python3-$release-jobs include python36 for wallaby, xena, and yoga | 22:11 |
| clarkb | gmaan: ^ do you think we can update those templates to only run 38 and newer? | 22:12 |
| clarkb | elodilles: ^ you may have thoughts too as those are all unmaintained branches | 22:15 |
| clarkb | The rough idea I've got is starting in ozj we can update the py27 job to run on a newer platform. At the same time remove 36 and 37 jobs from any templates. Then we need to go and start removign the jobs from their explicit inclusion elsewhere (for example in pbr) | 22:22 |
| clarkb | that will probably get us about 80% of the way there. | 22:23 |
| clarkb | but then at that point maybe we go ahead and drop the bionic nodeset from opendev/base-jobs and see what happens | 22:28 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!