Friday, 2022-05-13

*** Guest0 is now known as prometheanfire00:29
*** dviroel|afk is now known as dviroel|out01:26
*** diablo_rojo is now known as Guest4306:49
*** jpodivin_ is now known as jpodivin07:15
*** lajoskatona_ is now known as lajoskatona07:42
opendevreviewWenping Song proposed openstack/releases master: Update python testing as per zed cycle testing runtime
*** marios is now known as marios|afk10:10
*** marios|afk is now known as marios10:45
*** dviroel|out is now known as dviroel11:00
opendevreviewHervé Beraud proposed openstack/releases master: Release oslo.log 4.8.1 to fix bugs
elodilleshberaud: i've added a question to that one ^^^13:17
* hberaud look13:17
elodillesalso, can i get a 2nd core review for this one? >>>
elodillesoh, ttx , i guess we can merge this now, right? >>>
hberaudelodilles: I replied to your question13:20
elodilleshberaud: can we build py36 package out of oslo.log without the classifiers? (i know that in zed we have >=py3.8 as default, but oslo.log is 'independent', that's why i'm asking)13:22
hberaudgood question13:23
hberaudI don't think it will build13:23
hberaudthen I think you are right a major version could be required13:24
opendevreviewMerged openstack/releases master: Create pike-eol tag for Networking projects
opendevreviewHervé Beraud proposed openstack/releases master: Release oslo.log 5.0.0 to fix bugs
hberaudelodilles: updated ^13:34
elodilleshberaud: well, i double checked now and it still builds with py36 as well, despite the classifier is not added... (though it won't be visible amongst pypi's py3.6 packages)13:34
elodillesbut still it drops some kind of visible support13:35
hberaudif it will become not visible into pypi and not installable by using pip3.6 then I'd suggest to release a major version13:35
elodilleshberaud: ack, that's true13:35
hberaudThat was not clear to me when I released it at the first time13:36
elodillesoh, meeting time?14:00
elodilleslet's start then!14:00
ttxand +1 on
elodilles#startmeeting releaseteam14:00
opendevmeetMeeting started Fri May 13 14:00:32 2022 UTC and is due to finish in 60 minutes.  The chair is elodilles. Information about MeetBot at
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:00
opendevmeetThe meeting name has been set to 'releaseteam'14:00
ttxI'll just +A it for you14:00
elodillesPing list: armstrong ttx hberaud14:01
elodilleshello everyone \o/14:01
elodilleswe are @ line 8414:02
elodilleslet's start14:02
elodilles#topic Review task completion14:02
elodillesjust a heads-up from R-23 that Victoria transitioned to Extended Maintenance14:03
elodillesfrom R-21, 1st task: "Review cycle-trailing projects to check which haven’t released yet. Ask them to prepare their releases, if they haven’t already."14:04
elodillesi've sent out the reminder:
elodillesso this is done14:04
elodillesand that was all tasks for now14:05
elodilleswe can continue to next topic14:05
elodilles#topic Assign R-20 tasks14:05
elodillesI see that you added your name already to some of the tasks14:06
elodillesi've added my name to the last remaining one :)14:07
elodillesthanks for the volunteers!14:07
opendevreviewMerged openstack/releases master: Document how to fix release circular dependencies
elodilleslet's move on to next topic then14:08
elodilles#topic Review countdown email contents14:08
elodillesplease review ^^^14:08
ttxLooks good to me!14:09
armstrong“At the end of the week…” can we be more specific about which week?14:11
armstrongJust an opinion14:11
hberaudarmstrong: these mails speak about the current week and the date is indicated in the topic of the mail14:12
armstrongOk thanks hberaud14:12
elodillesyepp, i think that's good as it is14:13
elodillesthanks for the reviews!14:13
elodilles#topic Release naming/SLURP impact (ttx)14:14
elodillesttx: any suggestion for this? :)14:14
elodillesi might not have the latest state of the naming (there were some discussion about tick-tock from legal side)14:15
ttxyes sorry14:15
ttxSo the TC met yesterday14:15
ttxand made two decisions14:16
ttxOne is to rename the tick-tock release cadence into SLURP14:16
ttxfor Skip Level Upgrade Release process14:16
elodillessounds nice :)14:16
ttxSo the .1 release will be the SLURP release, which will be upgradeable every year in addition to every 6 months14:17
elodillesI thought it's just a nickname :)14:17
ttxunfortunately, not14:17
ttxso we might need to put some SLURP mention on the releases index page14:17
ttxso that it's clearer which one is SLURPable14:17
elodillesi see14:18
fungiso probably just a matter of adding some extra identifier on the releases site to differentiate slurp cycles from non-slurp? switching from using cycle names to using release numbers in the releases repo seems like it will entail a bit more work (though probably still mostly just some stream replacements and file renames?)14:18
ttxThe second decision is to delegate the release naming process to the foundation14:18
elodilleswe had this Action Point from PTG: "change is needed in releases.o.o page (data/series_status.yaml) to add some kind of 'Tick' & 'Tock' marking for the new releases"14:18
hberaudthat could be done by uupgrading the series status
elodillesso it is now the same but instead of Tick-tock, we need SLURP for .1 releases to be marked on the page i guess 14:18
ttxSo the Foundation will be responsible for giving us the release name.14:18
ttxSince the TC is no longer involved I think it will make sense to make it part of the release process14:19
ttxsince we are the first ones to need taht name14:19
ttxWe have two options there14:19
* diablo_rojo_phone lurks14:19
ttxWe can use the release version as the directory name in openstack/releases, and call stable branches stable/2022.114:20
ttxin that case we don;t really need the release name until late14:20
fungiyeah, makes the timing of getting a release name from the foundation staff less critical/blocking14:20
ttxOr we can continue to name the branches after the release name, in which case we'd have to ask it early14:20
ttxpersonally I think it's easier to refer to the cycle by name than by number, at least while it's not released yet14:21
hberaudI prefer 2)14:21
ttxso I would not mind staying on stable/NAME branches14:21
elodilleshmmm. yepp, in case the release name we need it latest R-1114:21
ttxIf we pick (2) we would probably want the cycle name to be picked in the middle of the previous cycle14:22
elodillesi'm also OK with staying with stable/NAME branches14:22
fungithat assumes you no longer use release names in the release schedule planning though14:22
ttxso that it can be referred to in usual convos14:22
fungiyes, middle of the previous cycle if you want to use it in scheduling14:22
ttxI find "aardvark-1 milestone" a lot clearer than "2023.1-1 milestone"14:23
fungiby week r11 of the current cycle if you don't use it in scheduling14:23
ttxIn both cases we'll have to call the release by its number once it's released14:23
elodillesttx: yepp, it looks more clear14:23
ttxso display something like "2023.1 (Aardvark)" prominently14:24
ttxso the index page will need some work14:24
fungiin order to determine how far in advance to notify the foundation staff to begin the name selection process, we probably need to know how long the responsible parties expect that process to take to come to a conclusion, and count backwards from when you expect to start schedule planning14:24
ttxYes... I would actually place it in the early days of the previous cycle when we have nothing else to do14:24
ttxBUt the Foundation marketing team may also have a preferred timing to do that community exercise14:25
ttxnaming the "next" while one is being worked on is always a bit confusing14:26
fungimakes sense. so a prompt at one of the first weeks of the cycle which says to remind the foundation staff that we need the next cycle's name finalized by x date14:26
elodillescurrently we had a task in the tracking page,14:26
elodillesat R-16,14:26
elodilles"Check with TC that the next Release Name selection process has been started. Release name should be available by R-11."14:26
fungiand that gives them the flexibility to decide when they start whatever process they're going to follow, as long as they know the hard deadline14:26
elodilles(line 140)14:26
elodillesso is that late? what do you think?14:27
ttxhmm, maybe we shouould have something like "At R-18, renmind the Foundation to do it"14:27
ttxIn addition to  "at R-16 check that it's under way"14:27
elodillesttx: ++14:28
ttxR-11 is when we post the schedule ?14:28
elodillesttx: yes14:29
elodillesthere we have the task: 'Plan the next release cycle schedule'14:29
ttxok makes sense14:29
ttxI'm pretty convinced that we should keep using the NAME in the milestone names (aardvark-1)14:29
fungiso notifying them at r18 to have the name by r12 (6 weeks for the name selection process) so you can post the schedule at r11?14:30
ttxi think the name also makes more sense in the stable breanch names, (stable/aardvark) but that may be a bit contentious14:30
elodillesfungi: ++14:30
ttxsince the TC wants the release to be primarily designed under its release number14:30
ttxstable branches are created around release time so I guess both work14:31
elodillesttx: well, it's created for libraries some weeks earlier14:31
ttxand that might actually facilitate ordering (a-z first, then numbers)14:31
elodilles(but we well have stable/zed for this cycle)14:32
ttxI just find it a lot easier to "see" to use names, but meh14:32
ttxlike I clearly see the difference between stable/yoga and stable/aardvark, not so much between stable/2022.1 and stable/2023.114:32
elodillesttx: ++14:33
ttxmaybe I have numberlexia14:33
elodillesand TC is OK with stable/aardvark instead of stable/2023.1?14:33
ttxelodilles: that may be contentious with the TC though so you might want to doublecheck on that14:33
ttxthey want the RELEASE to be primarily designed under its number, but maybe they don;t care about branch names14:34
ttxsomething to doublecheck before we edit all the process14:35
ttx(calling it under the name would definitely limit the impact on us)14:35
elodillesthis needs to be checked with TC i think then :S i'm not sure they are OK with stable/NAME branch :S14:35
ttxI'm not sure either14:36
ttxI'm tempted to ask the person who came up with the numbers idea to submit the release process changes :)14:36
elodillesso an action like this? >>> Reach out to TC whether stable/NAME branch name (what release team prefers) is acceptable for them14:37
ttxit's probably ok if they prefer the opposite14:37
ttxas long as we can use the name in milestones14:38
ttx(which are a release team construct)14:38
ttx2023.1-1 lol14:38
ttxalright that is all14:39
elodilles#action elod to Reach out to TC whether stable/NAME branch name (what release team prefers) is acceptable for them14:39
ttx#action ttx to check with Foundation staff if timing for naming process between R-18 and R-11 is ok14:39
elodillesttx: thanks ^^^14:39
ttxjust in time for the new season!14:40
ttxwondering if we could make it a summit activity14:40
elodillesttx: yepp, that sounds fun :)14:40
ttxelodilles: do you have a preference for keeping alpha ordering?14:41
ttx(one option for the new namign process is to waive the A...B...C... requirement)14:41
diablo_rojo_phoneI feel like some logical order is good? 14:42
ttxSome Celine Dion fan suggested to name all releases "Celine" and be done with it, too14:42
elodillesttx: well, i haven't thought about it, but i guess alphabetical order would be a clear thing14:42
ttxyeah I think the alpha order is a nice constraint to have14:42
diablo_rojo_phoneIt was totally ttx ;) 14:42
elodillesttx: :D14:42
ttxNO IT WAS NOT14:42
diablo_rojo_phoneNo? 14:43
ttxI proposed they should all be named Adele14:43
* diablo_rojo_phone whispers to elodilles all about ttx being a closet Celine Dion fan. 14:43
ttxbut I digress14:43
diablo_rojo_phone..his heart definitely goes on. 14:43
ttxthat's the Way it Is14:44
ttxI surrender14:44
elodillesare these all song names still? :D14:44
ttxLove doesn't ask why14:45
diablo_rojo_phoneIts All Coming Back to me now ;)14:45
diablo_rojo_phoneJust Walk Away ;) 14:45
diablo_rojo_phoneOkay I'll stop. 14:46
ttxGoodbye's (the saddest word)14:46
elodillesthat was nice :) but let's get back to our topic14:47
elodillesis there something else we need to discuss, or agree on?14:47
elodilles(are everyone looking for a song title that fits for the above question? O.o)14:49
elodilleswe didn't get to our last topic yet, so here it comes14:51
elodilles#topic Open Discussion14:51
elodillesso anything else?14:51
apriceis this where Celine fans convene?14:51
ttxaprice: I did my best to represent with google's help14:52
fungiall one of you? ;)14:52
apricettx: i think you did an admirable job. looks like release naming is done for the next few cycles14:52
ttxAll By Myself14:52
ttx(fungi begged for it)14:52
* fungi sighs14:52
elodillesgood :) i'll end the meeting now, but feel free to continue the singing :D14:54
elodillesthanks every Celine Dion fan for joining!14:55
opendevmeetMeeting ended Fri May 13 14:55:27 2022 UTC.  Information about MeetBot at . (v 0.1.4)14:55
opendevmeetMinutes (text):
apricehahah there are more of us! 14:55
apriceI just havent found them yet :) 14:55
diablo_rojo_phoneIsn't it required for all Canadians? 14:56
apricemnaser: do you agree?14:56
hberaudelodilles: thanks14:57
elodilleshberaud: thanks too :)14:58
*** ykarel_ is now known as ykarel15:05
*** dviroel is now known as dviroel|lunch15:12
*** dviroel|lunch is now known as dviroel16:00
*** marios is now known as marios|out16:06
opendevreviewMerged openstack/releases master: [Puppet OpenStack] Transition stein to EOL
*** gibi is now known as gibi_pto16:39
mnaseraprice: yep, canadian approved alright :p18:56
*** dviroel is now known as dviroel|out21:57

Generated by 2.17.3 by Marius Gedminas - find it at!