| *** diablo_rojo is now known as Guest6733 | 01:00 | |
| *** amoralej|off is now known as amoralej | 06:48 | |
| *** ysandeep|out is now known as ysandeep | 07:00 | |
| opendevreview | Slawek Kaplonski proposed openstack/releases master: New releases of the Neutron stable versions https://review.opendev.org/c/openstack/releases/+/808012 | 07:12 |
|---|---|---|
| *** ysandeep is now known as ysandeep|lunch | 07:52 | |
| *** ysandeep|lunch is now known as ysandeep | 08:18 | |
| opendevreview | Merged openstack/releases master: [Glance] Xena milestone 3 release https://review.opendev.org/c/openstack/releases/+/807820 | 09:02 |
| opendevreview | Merged openstack/releases master: [oslo independent] release oslo.concurrency https://review.opendev.org/c/openstack/releases/+/807072 | 09:04 |
| opendevreview | Martin Kopec proposed openstack/releases master: Release Tempest 29.0.0 as Xena final release https://review.opendev.org/c/openstack/releases/+/808035 | 09:44 |
| *** ysandeep is now known as ysandeep|afk | 09:48 | |
| opendevreview | Martin Kopec proposed openstack/releases master: Add releasenotes link for Tempest 29.0.0 https://review.opendev.org/c/openstack/releases/+/808039 | 09:54 |
| *** ysandeep|afk is now known as ysandeep | 11:28 | |
| fungi | hberaud: where did you have in mind for reviewing a design specification about a release metadata api? (ongoing the ml thread) | 12:09 |
| *** amoralej is now known as amoralej|lunch | 12:13 | |
| *** amoralej|lunch is now known as amoralej | 13:13 | |
| hberaud | fungi: I was thinking about doing that design through an openstack goal or something like that | 13:16 |
| fungi | goals are usually for when many projects need to be involved in implementing something | 13:18 |
| fungi | i don't know that we need that level of cross-project coordination if the goal is to just serve release metadata in a more downstream-consumable manner | 13:19 |
| hberaud | you are surely right this was more a suggestion, as I didn't see example of this kind of specification during my carreer on the release team | 13:20 |
| hberaud | I was thinking that the goal could be a good place to open the discussion | 13:21 |
| fungi | right, usually we've talked through things in irc/ml or ptg sessions and then started working on a prototype to review wherever it would be implemented | 13:21 |
| hberaud | "the goals" | 13:21 |
| hberaud | I see | 13:22 |
| fungi | as far as release automation or features of the releases site are concerned | 13:22 |
| hberaud | yes, I think this is the case there (release feature) | 13:22 |
| fungi | i do agree it would be good to gather some input from package maintainers of multiple distros to find out what specific information would be useful to them | 13:23 |
| hberaud | the "goals". | 13:28 |
| hberaud | ? | 13:28 |
| hberaud | sorry ignore my previous question | 13:29 |
| hberaud | yes, it would be good to see the needs from the different sides | 13:29 |
| fungi | hberaud: yes, in an informal sense we need to know what goals people have for the implementation. in the sense of formal https://governance.openstack.org/tc/goals/ i don't think it's a fit | 13:43 |
| fungi | as the openstack-wide goals are about implementing or fixing things across many projects and teams | 13:44 |
| hberaud | I see | 13:44 |
| fungi | the openstack-wide goals process is also cumbersome, and a lot of overhead, useful when trying to coordinate and prioritize work across dozens of teams and hundreds of contributors/reviewers, but for something where we'd just be adding a looking with some release info in a central place that seems like extreme process overkill | 13:45 |
| hberaud | You are right | 13:46 |
| fungi | s/looking/lookup/ | 13:46 |
| hberaud | fungi: Thank you for all your useful thoughts. Let's wait a bit for their reply on your last email. After this point I'll summarize our discussion (^) to reorient the specification if needed. | 14:23 |
| opendevreview | Martin Kopec proposed openstack/releases master: Release bashate 3.0.0 https://review.opendev.org/c/openstack/releases/+/808086 | 14:29 |
| opendevreview | Martin Kopec proposed openstack/releases master: Release devstack-tools 1.3.0 https://review.opendev.org/c/openstack/releases/+/808087 | 14:33 |
| fungi | hberaud: sure, i've also been talking to them in #debian-openstack which is what prompted my question (they were asking me where they should post a spec) | 14:35 |
| hberaud | Ah I see :) | 14:37 |
| hberaud | np | 14:37 |
| opendevreview | Martin Kopec proposed openstack/releases master: Release os-testr 3.0.0 https://review.opendev.org/c/openstack/releases/+/808094 | 14:48 |
| tosky | a new os-testr O.o | 14:52 |
| *** ysandeep is now known as ysandeep|mtg | 15:04 | |
| clarkb | hberaud: fungi: I was thinking about that a bit and realized that if openstack used semver properly that should be a sufficent amount of info? unforatunetly that doesn't happen today aiui | 15:21 |
| fungi | clarkb: well, you can infer from semver whether a release after the cycle breaks backward compatibility or has explicit dependency version changes, but you can't easily differentiate those from "breaking" changes during the development cycle without some timeline mapping between independent releases and coordinated releases | 15:24 |
| fungi | it's most useful to consider the specific example from earlier in the thread: how do you know which version of taskflow should be used with openstack wallaby? | 15:25 |
| fungi | my argument is that independent release deliverables are effectively no different than external dependencies, in that regard | 15:25 |
| clarkb | right that is my argument too and I'm saying if you semver then its any version within the major release range set by upper constraints | 15:26 |
| fungi | and that the underlying question is how to know what version of openstack's (transitive) dependency set is recommended to be used for a given coordinated release of openstack | 15:26 |
| clarkb | unfortunately I don't think we are that disciplined about semver | 15:27 |
| fungi | well, even if we're disciplined about semver, not all our external dependencies are | 15:27 |
| clarkb | that is true though it seems zigos specific complaint is for libs we do control | 15:27 |
| *** ysandeep|mtg is now known as ysandeep | 15:28 | |
| tkajinam | hi. may I ask somebody from release team to remove old branches in storlets repo ? there are couple of patches merged recently to retire these branches | 15:32 |
| tkajinam | Newton and Ocata: https://review.opendev.org/c/openstack/releases/+/804512/ | 15:32 |
| tkajinam | P, Q, R and S https://review.opendev.org/c/openstack/releases/+/804562/ | 15:32 |
| clarkb | fungi: I'm slightly concerned that by creating a new API for this we're overlooking the tools that have existed for a long time to solve this simply because we don't use those tools properly | 15:32 |
| clarkb | tkajinam: I think elodilles_pto has been handling those. | 15:32 |
| fungi | yes, after the release change to tag those branches eol merges, elodilles_pto occasionally runs a batch script to delete the branches | 15:33 |
| tkajinam | ah thanks. seems he is taking off now so I'll check with him once he comes back | 15:34 |
| fungi | clarkb: well, right that's more or less been my point as well. if you want to know what version of taskflow we recommend for wallaby, that's the version we test stable/wallaby changes with, and it's encoded in the upper-constraints.txt file in the stable/wallaby branch of openstack/requirements | 15:35 |
| tkajinam | clarkb, fungi, thanks, both | 15:35 |
| fungi | clarkb: in theory newer versions of taskflow should be usable with stable/wallaby so long as they're patchlevel version increases, but since we treat independent deliverables the same as external dependencies, we basically freeze them in stable branch constraints lists | 15:40 |
| clarkb | fungi: but debian could give it a whirl and it would be a bug (that might not be fixed I guess) if a newer version that semver indicates is compat is not compat | 15:41 |
| clarkb | maybe the underlying problem is "the bug might not be fixed" | 15:41 |
| clarkb | and ya I don't have a good answer for that | 15:41 |
| fungi | anyway, it seems like the "easy" solution would be when updating the releases site, one of the things we publish is a mashup of the latest versions from the structured data for the cycle-based deliverables and the upper constraints list for that branch | 15:44 |
| fungi | i think part of what's not so easy to match up at the moment is the discrepancy between repository names and python package names. we have that info, so should include it along with the version numbers | 15:45 |
| fungi | that's probably one of the bigger headaches for distro package maintainers | 15:45 |
| *** abhishekk is now known as abhishekk|afk | 15:45 | |
| clarkb | because all of the control records are python centric ? | 15:47 |
| fungi | that's the impression i got at least | 15:57 |
| *** marios is now known as marios|out | 15:57 | |
| *** ysandeep is now known as ysandeep|dinner | 16:10 | |
| *** amoralej is now known as amoralej|off | 16:11 | |
| *** ysandeep|dinner is now known as ysandeep | 16:38 | |
| hberaud | fungi, clarkb: The API seems a flexible solution where each distros can use it and transform the results by applying their internal rules. As both you said semver interpretation is at the discretion of the different teams (openstack requirements, third party requirements, etc...), nothing is fully uniformized, and semver won't help so much there. So, flexibility and personal | 16:51 |
| hberaud | representation and interpretation is a key element to manage this point. The API (the mashup) provide a flexible and consummable representation of the state of art at a precise moment. | 16:51 |
| clarkb | the problem is that semver intends to fix this and we use tooling to do semver. We just don't actually do it. Maybe this is an indication we should | 16:53 |
| hberaud | indeed | 17:00 |
| fungi | that seems like a longer-term effort to achieve (perhaps even a never-ending struggle), so some means of summarizing the set of things which make up "openstack wallaby" (including the versions of cycle-independent and external dependencies we've tested with) would probably be useful much sooner | 17:09 |
| hberaud | agree | 17:15 |
| *** akekane__ is now known as abhishekk | 17:39 | |
| *** ysandeep is now known as ysandeep|out | 18:08 | |
| *** slaweq1 is now known as slaweq | 19:19 | |
| opendevreview | Goutham Pacha Ravi proposed openstack/releases master: [manila] Add Xena cycle highlights https://review.opendev.org/c/openstack/releases/+/807391 | 19:28 |
| gouthamr | hi sorta noob question that i asked on https://review.opendev.org/c/openstack/releases/+/807627 | 19:31 |
| gouthamr | i was wondering if we can request a newer client release before we branch off stable/xena, or would that not be advised? | 19:32 |
| gouthamr | smcginnis: ^ would you be able to help with this question? | 19:38 |
| fungi | gouthamr: probably the biggest risk is if the new client destabilizes testing for projects which are interfacing with it. we generally try to freeze releases for shared libraries (which python-manilaclient is one, in addition to being a cli tool) earlier in the cycle than the services which import them, so that they don't need to worry about internals changing out from under them when | 19:38 |
| fungi | they're trying to close in on release candidates | 19:38 |
| fungi | gouthamr: it looks from the commit message on the change you linked that the expected solution is to -1 it and propose a different commit to tag before tomorrow | 19:40 |
| gouthamr | fungi: ah, yes, the commit message made me think that was a possibility | 19:41 |
| fungi | i won't speak for the release managers as to whether they'll consider an extension past tomorrow's deadline, and it's kindof late in the day for most of them now | 19:42 |
| gouthamr | fungi: thanks for clarifying - i agree there's a risk; but projects importing this sdk/cli are still testing with the main branch afaict | 19:42 |
| gouthamr | ack i'll propose a release right away, and soft -1 this :) | 19:43 |
| opendevreview | Goutham Pacha Ravi proposed openstack/releases master: Release python-manilaclient 3.1.0 https://review.opendev.org/c/openstack/releases/+/808130 | 19:51 |
| smcginnis | gouthamr: It's past client lib freeze and requirements freeze, so you would have to request a freeze exception on the mailing list. | 19:53 |
| smcginnis | RC1 is next week, so it really should be a stabilization period to make sure things are ready for that. | 19:54 |
| smcginnis | But if there is a bug that needs to be addressed without a lot of other changes, then that may be fine. | 19:54 |
| gouthamr | smcginnis: ah i see - that makes sense | 19:54 |
| gouthamr | smcginnis: thanks for explaining this, smcginnis | 19:55 |
| smcginnis | gouthamr: Some notes about requesting a requirements freeze exception here: http://lists.openstack.org/pipermail/openstack-discuss/2021-September/024647.html | 19:55 |
| smcginnis | No problem! | 19:55 |
| opendevreview | Ghanshyam proposed openstack/releases master: Release Tempest 29.0.0 as Xena final release https://review.opendev.org/c/openstack/releases/+/808035 | 21:21 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!