| *** ykarel_ is now known as ykarel | 04:51 | |
| *** akekane_ is now known as abhishekk | 06:46 | |
| hberaud | elodilles: o/ what do you think if we move this deliverable file into the independent directory? https://review.opendev.org/c/openstack/releases/+/841844/ . This deliverable isn't present and I'd suggest to set back the "release-model" field to "independent". | 07:29 |
|---|---|---|
| hberaud | (not present in the independent dir) | 07:30 |
| frickler | hberaud: the problem is that the validator currently doesn't allow an rc1 release for independent. if you are willing to change that check, I think we'd prefer to move, but currently this isn't possible | 07:33 |
| opendevreview | Lajos Katona proposed openstack/releases master: Release os-ken for Zed-1 milestone https://review.opendev.org/c/openstack/releases/+/842376 | 07:35 |
| frickler | I see I had a comment prepared to that respect yesterday, but didn't send it out, did it now | 07:42 |
| opendevreview | Merged openstack/releases master: puppet-watcher: Create a new stable/yoga release https://review.opendev.org/c/openstack/releases/+/842331 | 08:18 |
| elodilles | hberaud frickler : i thought you want to achive to change the release model to independent, not cycle-with-rc | 08:19 |
| frickler | elodilles: yes, that was the first idea, but the validator doesn't allow to have an rc1 release for independent: deliverables/_independent/openstacksdk.yaml: validate_version_numbers: could not validate version '1.0.0.0rc1': Version 1.0.0.0rc1 looks like a pre-release and the release model does not allow for it | 08:22 |
| frickler | tested locally, but I can put up that patch as alternative if you want to see it in CI | 08:23 |
| elodilles | frickler: yes, why would you want an rc1 at all? | 08:24 |
| frickler | because this is a breaking release and we want to have a low-impact way of people being able to test it | 08:25 |
| frickler | but we can discuss that point with gtema, maybe over in #-sdks? | 08:26 |
| elodilles | MAJOR version bump is just for a (api-)breaking changes in my understanding | 08:26 |
| elodilles | i don't feel that rc1 release would be a better approach | 08:27 |
| elodilles | hi gtema , so i think if the concern is the breaking change, then i still would not use rc1 for that (which is only available for cycle-with-rc) | 08:32 |
| gtema | the idea here is to really have a pre-release | 08:32 |
| gtema | and we were thinking about smth like 0.99.0, but then thought that 1.0.0rc1 should be also possible | 08:33 |
| gtema | cause that would make it possible to cap from py requirements as <1.0 | 08:33 |
| gtema | yes, this is about breaking change, but we really want to test ourselves and let others test | 08:33 |
| elodilles | gtema: but would other teams use that? if we don't fail fast maybe it will be worse in the future, am i wrong with that? :/ | 08:34 |
| elodilles | hberaud ttx : any idea regarding this? ^^^ | 08:34 |
| frickler | the ansible-collection-openstack could use that, they are the main known consumer which will break | 08:34 |
| gtema | I would say this is only a one-time event to have rc release (maybe we will need to have few of them now, but not for future) | 08:35 |
| elodilles | (we are at early state in the cycle, so that at least good) | 08:35 |
| ttx | catching up | 08:36 |
| elodilles | there were beta releases as well (1.0.0b1 or sg like that) but that is maybe also for rc model? have to check whether it works with cycle-with-intermediary | 08:37 |
| ttx | elodilles: what's the context? | 08:37 |
| ttx | I'm confused | 08:37 |
| elodilles | openstacksdk wants to release something like a beta because of a breaking change | 08:38 |
| gtema | yes, right | 08:38 |
| elodilles | and the question is how can they do that? :) | 08:38 |
| elodilles | either with cycle-with-intermediary or as _independent release model | 08:39 |
| ttx | hmm as i remember doing RCs for libraries creates all sorts of problems | 08:39 |
| elodilles | ttx: our validator does not allow, so probably that's the root cause :) | 08:39 |
| ttx | well beyond that it creates issues with all the requirements systems | 08:40 |
| ttx | the requirements and constraints stuff can only parse "real" versions iirc | 08:40 |
| gtema | I would say in that case we should now switch to -with-rc and then once we are through go further to independent. Would this work? | 08:40 |
| ttx | basically libraries cannot use RCs, is my point | 08:41 |
| gtema | uhm, that's sad | 08:41 |
| ttx | It's either released and used or not released and not used | 08:41 |
| ttx | May I ask what a RC would help with? | 08:41 |
| ttx | compared to a "real" release? | 08:42 |
| gtema | have a chance to test it widely with possibility to cap easily | 08:43 |
| ttx | It's not the release model that does not support free versioning... it's the way openstack consumes libraries that only supports full library releases | 08:44 |
| gtema | ugh | 08:45 |
| ttx | trying to see if tere is a way around it | 08:46 |
| ttx | the choice was made originally to build a system around fully-semver libraries. you break a thing, you just fix it by incrementing the release version, numbers psychological impact be damned | 08:47 |
| gtema | okay, but with that having multiple sequential major version due to breaking compatibility is not really great thing | 08:48 |
| ttx | capping will basically not work with RCs | 08:48 |
| ttx | gtema: yeah that's the (arguably questionable) choice that was made. You break in 1.0.0, well you just release 2.0.0 with the fix, it's just numbers etc. | 08:49 |
| gtema | okay, got it. with that in mind, how do we only switch to independent model without making release (so that I will try in the meanwhile to move remaining things for major release)? | 08:50 |
| ttx | The closest to protecting the user from abusive number bumps would be to release a 0.99 and if it works bump it to 1.0 | 08:50 |
| ttx | or if it breaks fix it with a 1.0 | 08:51 |
| gtema | then users eventually need to cap now for <0.99, and not <1.0.0 | 08:51 |
| ttx | gtema: if you want to switch to independent you can just move the openstacksdk.yaml file to _independent folder and remove/adjust the release-model line | 08:52 |
| gtema | okay, thks | 08:52 |
| ttx | I guess you want to change to independent for reasons that are disconnected from the version issue right | 08:54 |
| ttx | (makes sense for an SDK anyway) | 08:55 |
| gtema | yes, right | 08:56 |
| gtema | reason for indepent was discussed during PTG also with release team | 08:56 |
| ttx | ah right I remember | 08:56 |
| elodilles | maybe i am wrong, but 1) 0.x releases are kind of "unstable" releases, so until 1.0.0 is not released, the MAJOR version bump is not a must. on the other hand 2) if a release is so unconsumable, then we have to restrict it in requirements branch. | 08:58 |
| elodilles | so i would still bump to next version (0.62.0?) and if that is causing unfixable break then restrict it via requirements branch | 08:59 |
| elodilles | or is my thinking wrong? | 08:59 |
| gtema | 0.62 will definitely break some things and that is what we initially want to prevent | 09:00 |
| gtema | and the point was exactly to give time to everybody who rely on sdk to adapt and report back issues before making real R1.0 | 09:00 |
| elodilles | in my understanding if 0.62 is released, we can just advertise it to teams that, 'hey you can temporarily set !=0.62, but please adapt to the new code as soon as possible' | 09:02 |
| gtema | I would then still make it 0.99 and not 0.62 | 09:03 |
| elodilles | and will there be a 0.62 if some projects cannot use 0.99? or just for the sake of show that there is a 'bigger' change? | 09:05 |
| gtema | 0.61 was last release which is definitely compatible. what we have in master now is already breaking and we wanted to test and see whether there is something else to fix before doing real R1 | 09:06 |
| ttx | yeah in theory semver rules kick in at 1.0... anythign below it is fair game in terms of breaking changes | 09:07 |
| ttx | so there is some flexibility there | 09:08 |
| elodilles | meanwhile i've found examples of beta releases with release-model: cycle-with-intermediary | 09:08 |
| elodilles | like, version: 1.0.0.0b1 | 09:08 |
| ttx | probably dating back from before the current requirements constraints system? | 09:09 |
| elodilles | so that's a possibility ^^^ | 09:09 |
| ttx | (or not libraries) | 09:10 |
| elodilles | hmmm, it seems those are cycle-with-intermediary but not libraries | 09:10 |
| ttx | yeah as long as they don;t appear in global-requirements I think it's fine | 09:11 |
| ttx | I mean we could just try a 0b1, worst case scenario it will not be tested/used | 09:12 |
| ttx | I'm just not sure of the value compared to doing a 0.99, which in my opinion signals "might not be ready" just the same | 09:13 |
| elodilles | ok, it seems it needs to be 0.99.0 anyway, as cycle-with-intermediary not even allows 0b1 for libraries :) | 09:19 |
| frickler | would b1 in any way be better than rc1? | 09:20 |
| gtema | I would say we do not care how exactly it is going to me named | 09:21 |
| frickler | maybe going for 0.99.0 is really the best option after all this discussion. we can then still iterate with 0.99.x before doing 1.0.0 if needed. | 09:23 |
| elodilles | frickler: we knew that rc1 is not accepted by the validator and i thought b1 is accepted :) otherwise it is not better, not even a single bit :) | 09:23 |
| frickler | and capping < 0.99 isn't much worse than < 1.0 | 09:23 |
| elodilles | anyway, i agree then with ttx, 0.99 is good | 09:24 |
| frickler | elodilles: ... could not validate version '1.0.0.0b1': Version 1.0.0.0b1 looks like a pre-release ... | 09:24 |
| elodilles | frickler: yepp, that was the error message for me, too :) | 09:25 |
| opendevreview | Merged openstack/releases master: Release ovsdbapp for Zed-1 milestone https://review.opendev.org/c/openstack/releases/+/842358 | 09:35 |
| opendevreview | Merged openstack/releases master: puppet-zaqar: Create a new stable/yoga release https://review.opendev.org/c/openstack/releases/+/842309 | 09:35 |
| opendevreview | Merged openstack/releases master: Release oslo.log 5.0.0 to fix bugs https://review.opendev.org/c/openstack/releases/+/841717 | 09:37 |
| frickler | gtema: what do you think? should I update the release patch with 0.99.0 or do you want to do it yourself? | 09:38 |
| gtema | pls do it, cause I am stuck in a meeting (therefore being mostly passive) | 09:38 |
| opendevreview | Merged openstack/releases master: Update python testing as per zed cycle testing runtime https://review.opendev.org/c/openstack/releases/+/841703 | 09:40 |
| opendevreview | Dr. Jens Harbott proposed openstack/releases master: Release openstacksdk for Zed-1 milestone https://review.opendev.org/c/openstack/releases/+/841844 | 09:53 |
| opendevreview | Merged openstack/releases master: Release os-ken for Zed-1 milestone https://review.opendev.org/c/openstack/releases/+/842376 | 10:30 |
| *** dviroel|out is now known as dviroel | 11:26 | |
| opendevreview | Erno Kuvaja proposed openstack/releases master: Remove Erno Kuvaja from Glance liaison https://review.opendev.org/c/openstack/releases/+/842535 | 12:22 |
| opendevreview | Jacob Anders proposed openstack/releases master: Release sushy 3.12.2 for Xena https://review.opendev.org/c/openstack/releases/+/842539 | 13:25 |
| opendevreview | Jacob Anders proposed openstack/releases master: Release sushy 3.7.5 for Wallaby https://review.opendev.org/c/openstack/releases/+/842544 | 13:31 |
| gmann | elodilles: ttx : we will discuss the release naming in development process things in TC meeting today starting in an 13 min from now. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting | 14:48 |
| elodilles | gmann: ack | 14:56 |
| *** dviroel is now known as dviroel|lunch | 15:26 | |
| ttx | elodilles: ultimately, the TC decides. We can just express preferences | 15:58 |
| elodilles | ttx: ++ | 15:58 |
| ttx | I'll continue to call milestones celine-1 | 16:03 |
| ttx | :P | 16:04 |
| elodilles | now that yeti is released, right? :D | 16:08 |
| *** marios is now known as marios|out | 16:14 | |
| *** dviroel|lunch is now known as dviroel | 16:25 | |
| iurygregory | release team https://review.opendev.org/c/openstack/releases/+/842544 https://review.opendev.org/c/openstack/releases/+/842539 contains a fix for regressions we found when using the latest release in wallaby / xena =) tks! o/ | 16:26 |
| elodilles | iurygregory: they look OK to me, +2'd them | 16:34 |
| iurygregory | elodilles, ty! | 16:36 |
| dmendiza[m] | Hi friends! | 16:53 |
| dmendiza[m] | I'm not sure if this is the right place to ask, but I am looking to update the Gerrit group that is handling keystone stable branches | 16:53 |
| dmendiza[m] | https://review.opendev.org/admin/groups/ed7e98cd14f0ec4dfd09d10bbb64e1bd3ac1fa15,members | 16:53 |
| dmendiza[m] | As the current PTL for Keystone I'd like to be added to the group. | 16:54 |
| dmendiza[m] | maybe elodilles or smcginnis could help me out? 🤔 | 17:02 |
| clarkb | dmendiza[m]: if you look at https://review.opendev.org/admin/groups/ed7e98cd14f0ec4dfd09d10bbb64e1bd3ac1fa15 it shows you who the group owner is. The group owner can add you. In this case stable-maint-core | 17:17 |
| dmendiza[m] | clarkb: thanks! I'll try to ping the members of https://review.opendev.org/admin/groups/2267a5998d4224dd0acf1081eb2ee7b11573b7ea,members directly. | 17:18 |
| elodilles | dmendiza[m]: hi | 17:25 |
| elodilles | dmendiza[m]: if you are not familiar with stable policy, then please read it first: https://docs.openstack.org/project-team-guide/stable-branches.html#appropriate-fixes :) | 17:26 |
| elodilles | dmendiza[m]: since TC agreed that teams can manage their own stable core team, it's really enough that you are the PTL of the team :) | 17:27 |
| elodilles | dmendiza[m]: so i'll add you in a minute :) | 17:27 |
| elodilles | dmendiza[m]: there you go: https://review.opendev.org/admin/groups/ed7e98cd14f0ec4dfd09d10bbb64e1bd3ac1fa15,members | 17:29 |
| dmendiza[m] | elodilles: Thank you! 😄 | 17:32 |
| elodilles | dmendiza[m]: np :) i've replied on ML, too ;) | 17:35 |
| elodilles | dmendiza[m]: if anytime you are unsure about a patch whether to appropriate on a stable branch, then feel free to ping me and I'll try to help :) | 17:37 |
| dmendiza[m] | elodilles: sounds good, thank you! | 17:37 |
| elodilles | np | 17:37 |
| *** dviroel is now known as dviroel|out | 20:45 | |
| janders | Hi openstack-release team. I'm after second +2s for https://review.opendev.org/c/openstack/releases/+/842544 and https://review.opendev.org/c/openstack/releases/+/842539 if you're still around (@iurygregory posted these here earlier on my behalf). Apologies for a rush - these are needed for a high-priority bugfix. Thank you! | 23:41 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!