Thursday, 2022-05-19

*** ykarel_ is now known as ykarel04:51
*** akekane_ is now known as abhishekk06:46
hberaudelodilles: o/ what do you think if we move this deliverable file into the independent directory? . 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
fricklerhberaud: 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 possible07:33
opendevreviewLajos Katona proposed openstack/releases master: Release os-ken for Zed-1 milestone
fricklerI see I had a comment prepared to that respect yesterday, but didn't send it out, did it now07:42
opendevreviewMerged openstack/releases master: puppet-watcher: Create a new stable/yoga release
elodilleshberaud frickler : i thought you want to achive to change the release model to independent, not cycle-with-rc08:19
fricklerelodilles: 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 '': Version looks like a pre-release and the release model does not allow for it08:22
fricklertested locally, but I can put up that patch as alternative if you want to see it in CI08:23
elodillesfrickler: yes, why would you want an rc1 at all?08:24
fricklerbecause this is a breaking release and we want to have a low-impact way of people being able to test it08:25
fricklerbut we can discuss that point with gtema, maybe over in #-sdks?08:26
elodillesMAJOR version bump is just for a (api-)breaking changes in my understanding08:26
elodillesi don't feel that rc1 release would be a better approach08:27
elodilleshi 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
gtemathe idea here is to really have a pre-release08:32
gtemaand we were thinking about smth like 0.99.0, but then thought that 1.0.0rc1 should be also possible08:33
gtemacause that would make it possible to cap from py requirements as <1.008:33
gtemayes, this is about breaking change, but we really want to test ourselves and let others test08:33
elodillesgtema: 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
elodilleshberaud ttx : any idea regarding this? ^^^08:34
fricklerthe ansible-collection-openstack could use that, they are the main known consumer which will break08:34
gtemaI 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
ttxcatching up08:36
elodillesthere 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-intermediary08:37
ttxelodilles: what's the context?08:37
ttxI'm confused08:37
elodillesopenstacksdk wants to release something like a beta because of a breaking change08:38
gtemayes, right08:38
elodillesand the question is how can they do that? :)08:38
elodilleseither with cycle-with-intermediary or as _independent release model08:39
ttxhmm as i remember doing RCs for libraries creates all sorts of problems08:39
elodillesttx: our validator does not allow, so probably that's the root cause :)08:39
ttxwell beyond that it creates issues with all the requirements systems08:40
ttxthe requirements and constraints stuff can only parse "real" versions iirc08:40
gtemaI 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
ttxbasically libraries cannot use RCs, is my point08:41
gtemauhm, that's sad08:41
ttxIt's either released and used or not released and not used08:41
ttxMay I ask what a RC would help with?08:41
ttxcompared to a "real" release?08:42
gtemahave a chance to test it widely with possibility to cap easily08:43
ttxIt's not the release model that does not support free versioning... it's the way openstack consumes libraries that only supports full library releases08:44
ttxtrying to see if tere is a way around it08:46
ttxthe 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 damned08:47
gtemaokay, but with that having multiple sequential major version due to breaking compatibility is not really great thing08:48
ttxcapping will basically not work with RCs08:48
ttxgtema: 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
gtemaokay, 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
ttxThe closest to protecting the user from abusive number bumps would be to release a 0.99 and if it works bump it to 1.008:50
ttxor if it breaks fix it with a 1.008:51
gtemathen users eventually need to cap now for <0.99, and not <1.0.008:51
ttxgtema: if you want to switch to independent you can just move the openstacksdk.yaml file to _independent folder and remove/adjust the release-model line08:52
gtemaokay, thks08:52
ttxI guess you want to change to independent for reasons that are disconnected from the version issue right08:54
ttx(makes sense for an SDK anyway)08:55
gtemayes, right08:56
gtemareason for indepent was discussed during PTG also with release team08:56
ttxah right I remember08:56
elodillesmaybe 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
elodillesso i would still bump to next version (0.62.0?) and if that is causing unfixable break then restrict it via requirements branch08:59
elodillesor is my thinking wrong?08:59
gtema0.62 will definitely break some things and that is what we initially want to prevent09:00
gtemaand the point was exactly to give time to everybody who rely on sdk to adapt and report back issues before making real R1.009:00
elodillesin 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
gtemaI would then still make it 0.99 and not 0.6209:03
elodillesand 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
gtema0.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 R109:06
ttxyeah in theory semver rules kick in at 1.0... anythign below it is fair game in terms of breaking changes09:07
ttxso there is some flexibility there09:08
elodillesmeanwhile i've found examples of beta releases with release-model: cycle-with-intermediary09:08
elodilleslike, version:
ttxprobably dating back from before the current requirements constraints system?09:09
elodillesso that's a possibility ^^^09:09
ttx(or not libraries)09:10
elodilleshmmm, it seems those are cycle-with-intermediary but not libraries09:10
ttxyeah as long as they don;t appear in global-requirements I think it's fine09:11
ttxI mean we could just try a 0b1, worst case scenario it will not be tested/used09:12
ttxI'm just not sure of the value compared to doing a 0.99, which in my opinion signals "might not be ready" just the same09:13
elodillesok, it seems it needs to be 0.99.0 anyway, as cycle-with-intermediary not even allows 0b1 for libraries :)09:19
fricklerwould b1 in any way be better than rc1?09:20
gtemaI would say we do not care how exactly it is going to me named09:21
fricklermaybe 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
elodillesfrickler: 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
fricklerand capping < 0.99 isn't much worse than < 1.009:23
elodillesanyway, i agree then with ttx, 0.99 is good09:24
fricklerelodilles: ... could not validate version '': Version looks like a pre-release ...09:24
elodillesfrickler: yepp, that was the error message for me, too :)09:25
opendevreviewMerged openstack/releases master: Release ovsdbapp for Zed-1 milestone
opendevreviewMerged openstack/releases master: puppet-zaqar: Create a new stable/yoga release
opendevreviewMerged openstack/releases master: Release oslo.log 5.0.0 to fix bugs
fricklergtema: what do you think? should I update the release patch with 0.99.0 or do you want to do it yourself?09:38
gtemapls do it, cause I am stuck in a meeting (therefore being mostly passive)09:38
opendevreviewMerged openstack/releases master: Update python testing as per zed cycle testing runtime
opendevreviewDr. Jens Harbott proposed openstack/releases master: Release openstacksdk for Zed-1 milestone
opendevreviewMerged openstack/releases master: Release os-ken for Zed-1 milestone
*** dviroel|out is now known as dviroel11:26
opendevreviewErno Kuvaja proposed openstack/releases master: Remove Erno Kuvaja from Glance liaison
opendevreviewJacob Anders proposed openstack/releases master: Release sushy 3.12.2 for Xena
opendevreviewJacob Anders proposed openstack/releases master: Release sushy 3.7.5 for Wallaby
gmannelodilles: ttx : we will discuss the release naming in development process things in TC meeting today starting in an 13 min from now. 14:48
elodillesgmann: ack14:56
*** dviroel is now known as dviroel|lunch15:26
ttxelodilles: ultimately, the TC decides. We can just express preferences15:58
elodillesttx: ++15:58
ttxI'll continue to call milestones celine-116:03
elodillesnow that yeti is released, right? :D16:08
*** marios is now known as marios|out16:14
*** dviroel|lunch is now known as dviroel16:25
iurygregoryrelease team contains a fix for regressions we found when using the latest release in wallaby / xena =) tks! o/16:26
elodillesiurygregory: they look OK to me, +2'd them16:34
iurygregoryelodilles, 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 branches16: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
clarkbdmendiza[m]: if you look at it shows you who the group owner is. The group owner can add you. In this case stable-maint-core17:17
dmendiza[m]clarkb: thanks!  I'll try to ping the members of,members directly.17:18
elodillesdmendiza[m]: hi17:25
elodillesdmendiza[m]: if you are not familiar with stable policy, then please read it first: :)17:26
elodillesdmendiza[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
elodillesdmendiza[m]: so i'll add you in a minute :)17:27
elodillesdmendiza[m]: there you go:,members17:29
dmendiza[m]elodilles: Thank you! 😄17:32
elodillesdmendiza[m]: np :) i've replied on ML, too ;)17:35
elodillesdmendiza[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
*** dviroel is now known as dviroel|out20:45
jandersHi openstack-release team. I'm after second +2s for and 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 2.17.3 by Marius Gedminas - find it at!