*** Guest0 is now known as prometheanfire | 00:29 | |
*** dviroel|afk is now known as dviroel|out | 01:26 | |
*** diablo_rojo is now known as Guest43 | 06:49 | |
*** jpodivin_ is now known as jpodivin | 07:15 | |
*** lajoskatona_ is now known as lajoskatona | 07:42 | |
opendevreview | Wenping Song proposed openstack/releases master: Update python testing as per zed cycle testing runtime https://review.opendev.org/c/openstack/releases/+/841703 | 09:34 |
---|---|---|
*** marios is now known as marios|afk | 10:10 | |
*** marios|afk is now known as marios | 10:45 | |
*** dviroel|out is now known as dviroel | 11:00 | |
opendevreview | Hervé Beraud proposed openstack/releases master: Release oslo.log 4.8.1 to fix bugs https://review.opendev.org/c/openstack/releases/+/841717 | 11:09 |
elodilles | hberaud: i've added a question to that one ^^^ | 13:17 |
* hberaud look | 13:17 | |
elodilles | also, can i get a 2nd core review for this one? >>> https://review.opendev.org/c/openstack/releases/+/841086 | 13:18 |
elodilles | oh, ttx , i guess we can merge this now, right? >>> https://review.opendev.org/c/openstack/releases/+/819329 | 13:19 |
hberaud | elodilles: I replied to your question | 13:20 |
elodilles | hberaud: 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 |
hberaud | good question | 13:23 |
hberaud | I don't think it will build | 13:23 |
hberaud | then I think you are right a major version could be required | 13:24 |
opendevreview | Merged openstack/releases master: Create pike-eol tag for Networking projects https://review.opendev.org/c/openstack/releases/+/841086 | 13:31 |
opendevreview | Hervé Beraud proposed openstack/releases master: Release oslo.log 5.0.0 to fix bugs https://review.opendev.org/c/openstack/releases/+/841717 | 13:32 |
hberaud | elodilles: updated ^ | 13:34 |
elodilles | hberaud: 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 |
elodilles | :S | 13:34 |
elodilles | but still it drops some kind of visible support | 13:35 |
hberaud | if it will become not visible into pypi and not installable by using pip3.6 then I'd suggest to release a major version | 13:35 |
elodilles | hberaud: ack, that's true | 13:35 |
hberaud | That was not clear to me when I released it at the first time | 13:36 |
ttx | o/ | 14:00 |
elodilles | oh, meeting time? | 14:00 |
ttx | yep | 14:00 |
elodilles | let's start then! | 14:00 |
ttx | and +1 on https://review.opendev.org/c/openstack/releases/+/819329 | 14:00 |
elodilles | #startmeeting releaseteam | 14:00 |
opendevmeet | Meeting 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 http://wiki.debian.org/MeetBot. | 14:00 |
opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:00 |
opendevmeet | The meeting name has been set to 'releaseteam' | 14:00 |
hberaud | o/ | 14:00 |
ttx | I'll just +A it for you | 14:00 |
armstrong | o/ | 14:01 |
elodilles | Ping list: armstrong ttx hberaud | 14:01 |
elodilles | #link https://etherpad.opendev.org/p/zed-relmgt-tracking | 14:01 |
elodilles | hello everyone \o/ | 14:01 |
armstrong | Hello | 14:01 |
elodilles | we are @ line 84 | 14:02 |
elodilles | let's start | 14:02 |
elodilles | #topic Review task completion | 14:02 |
elodilles | just a heads-up from R-23 that Victoria transitioned to Extended Maintenance | 14:03 |
hberaud | ack | 14:03 |
elodilles | from 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 |
elodilles | i've sent out the reminder: http://lists.openstack.org/pipermail/openstack-discuss/2022-May/028522.html | 14:04 |
elodilles | so this is done | 14:04 |
elodilles | and that was all tasks for now | 14:05 |
elodilles | we can continue to next topic | 14:05 |
ttx | ++ | 14:05 |
elodilles | #topic Assign R-20 tasks | 14:05 |
elodilles | I see that you added your name already to some of the tasks | 14:06 |
elodilles | i've added my name to the last remaining one :) | 14:07 |
elodilles | thanks for the volunteers! | 14:07 |
opendevreview | Merged openstack/releases master: Document how to fix release circular dependencies https://review.opendev.org/c/openstack/releases/+/819329 | 14:07 |
elodilles | let's move on to next topic then | 14:08 |
elodilles | #topic Review countdown email contents | 14:08 |
elodilles | #link https://etherpad.opendev.org/p/relmgmt-weekly-emails | 14:08 |
elodilles | please review ^^^ | 14:08 |
ttx | Looks good to me! | 14:09 |
armstrong | “At the end of the week…” can we be more specific about which week? | 14:11 |
armstrong | Just an opinion | 14:11 |
hberaud | LGTM | 14:11 |
hberaud | armstrong: these mails speak about the current week and the date is indicated in the topic of the mail | 14:12 |
armstrong | Ok thanks hberaud | 14:12 |
hberaud | np | 14:13 |
elodilles | yepp, i think that's good as it is | 14:13 |
elodilles | thanks for the reviews! | 14:13 |
elodilles | #topic Release naming/SLURP impact (ttx) | 14:14 |
elodilles | ttx: any suggestion for this? :) | 14:14 |
elodilles | i might not have the latest state of the naming (there were some discussion about tick-tock from legal side) | 14:15 |
ttx | yes sorry | 14:15 |
ttx | So the TC met yesterday | 14:15 |
ttx | and made two decisions | 14:16 |
ttx | One is to rename the tick-tock release cadence into SLURP | 14:16 |
ttx | for Skip Level Upgrade Release process | 14:16 |
elodilles | sounds nice :) | 14:16 |
ttx | So the .1 release will be the SLURP release, which will be upgradeable every year in addition to every 6 months | 14:17 |
elodilles | I thought it's just a nickname :) | 14:17 |
ttx | unfortunately, not | 14:17 |
elodilles | :) | 14:17 |
ttx | so we might need to put some SLURP mention on the releases index page | 14:17 |
ttx | so that it's clearer which one is SLURPable | 14:17 |
elodilles | i see | 14:18 |
fungi | so 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 |
ttx | The second decision is to delegate the release naming process to the foundation | 14:18 |
elodilles | we 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 |
hberaud | that could be done by uupgrading the series status https://opendev.org/openstack/releases/src/branch/master/data/series_status.yaml | 14:18 |
elodilles | so 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 |
ttx | So the Foundation will be responsible for giving us the release name. | 14:18 |
ttx | Since the TC is no longer involved I think it will make sense to make it part of the release process | 14:19 |
ttx | since we are the first ones to need taht name | 14:19 |
hberaud | +1 | 14:19 |
ttx | We have two options there | 14:19 |
* diablo_rojo_phone lurks | 14:19 | |
ttx | We can use the release version as the directory name in openstack/releases, and call stable branches stable/2022.1 | 14:20 |
ttx | in that case we don;t really need the release name until late | 14:20 |
fungi | yeah, makes the timing of getting a release name from the foundation staff less critical/blocking | 14:20 |
ttx | Or we can continue to name the branches after the release name, in which case we'd have to ask it early | 14:20 |
ttx | personally I think it's easier to refer to the cycle by name than by number, at least while it's not released yet | 14:21 |
hberaud | I prefer 2) | 14:21 |
ttx | so I would not mind staying on stable/NAME branches | 14:21 |
elodilles | hmmm. yepp, in case the release name we need it latest R-11 | 14:21 |
ttx | If we pick (2) we would probably want the cycle name to be picked in the middle of the previous cycle | 14:22 |
elodilles | i'm also OK with staying with stable/NAME branches | 14:22 |
fungi | that assumes you no longer use release names in the release schedule planning though | 14:22 |
ttx | so that it can be referred to in usual convos | 14:22 |
fungi | yes, middle of the previous cycle if you want to use it in scheduling | 14:22 |
ttx | I find "aardvark-1 milestone" a lot clearer than "2023.1-1 milestone" | 14:23 |
fungi | by week r11 of the current cycle if you don't use it in scheduling | 14:23 |
ttx | In both cases we'll have to call the release by its number once it's released | 14:23 |
elodilles | ttx: yepp, it looks more clear | 14:23 |
ttx | so display something like "2023.1 (Aardvark)" prominently | 14:24 |
ttx | so the index page will need some work | 14:24 |
fungi | in 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 planning | 14:24 |
ttx | Yes... I would actually place it in the early days of the previous cycle when we have nothing else to do | 14:24 |
ttx | BUt the Foundation marketing team may also have a preferred timing to do that community exercise | 14:25 |
ttx | naming the "next" while one is being worked on is always a bit confusing | 14:26 |
fungi | makes 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 date | 14:26 |
ttx | yep | 14:26 |
elodilles | currently we had a task in the tracking page, | 14:26 |
elodilles | at 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 |
fungi | and that gives them the flexibility to decide when they start whatever process they're going to follow, as long as they know the hard deadline | 14:26 |
elodilles | (line 140) | 14:26 |
elodilles | so is that late? what do you think? | 14:27 |
ttx | hmm, maybe we shouould have something like "At R-18, renmind the Foundation to do it" | 14:27 |
ttx | In addition to "at R-16 check that it's under way" | 14:27 |
elodilles | ttx: ++ | 14:28 |
ttx | R-11 is when we post the schedule ? | 14:28 |
elodilles | ttx: yes | 14:29 |
elodilles | there we have the task: 'Plan the next release cycle schedule' | 14:29 |
ttx | ok makes sense | 14:29 |
ttx | I'm pretty convinced that we should keep using the NAME in the milestone names (aardvark-1) | 14:29 |
fungi | so 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 |
ttx | i think the name also makes more sense in the stable breanch names, (stable/aardvark) but that may be a bit contentious | 14:30 |
elodilles | fungi: ++ | 14:30 |
ttx | since the TC wants the release to be primarily designed under its release number | 14:30 |
ttx | stable branches are created around release time so I guess both work | 14:31 |
elodilles | ttx: well, it's created for libraries some weeks earlier | 14:31 |
ttx | and that might actually facilitate ordering (a-z first, then numbers) | 14:31 |
elodilles | (but we well have stable/zed for this cycle) | 14:32 |
ttx | I just find it a lot easier to "see" to use names, but meh | 14:32 |
ttx | like I clearly see the difference between stable/yoga and stable/aardvark, not so much between stable/2022.1 and stable/2023.1 | 14:32 |
elodilles | ttx: ++ | 14:33 |
ttx | maybe I have numberlexia | 14:33 |
elodilles | and TC is OK with stable/aardvark instead of stable/2023.1? | 14:33 |
ttx | elodilles: that may be contentious with the TC though so you might want to doublecheck on that | 14:33 |
ttx | they want the RELEASE to be primarily designed under its number, but maybe they don;t care about branch names | 14:34 |
ttx | something to doublecheck before we edit all the process | 14:35 |
ttx | (calling it under the name would definitely limit the impact on us) | 14:35 |
elodilles | this needs to be checked with TC i think then :S i'm not sure they are OK with stable/NAME branch :S | 14:35 |
ttx | I'm not sure either | 14:36 |
ttx | I'm tempted to ask the person who came up with the numbers idea to submit the release process changes :) | 14:36 |
elodilles | so an action like this? >>> Reach out to TC whether stable/NAME branch name (what release team prefers) is acceptable for them | 14:37 |
ttx | yeah.. | 14:37 |
ttx | it's probably ok if they prefer the opposite | 14:37 |
ttx | as long as we can use the name in milestones | 14:38 |
ttx | (which are a release team construct) | 14:38 |
ttx | 2023.1-1 lol | 14:38 |
elodilles | :) | 14:38 |
ttx | alright that is all | 14:39 |
elodilles | #action elod to Reach out to TC whether stable/NAME branch name (what release team prefers) is acceptable for them | 14:39 |
ttx | #action ttx to check with Foundation staff if timing for naming process between R-18 and R-11 is ok | 14:39 |
elodilles | ttx: thanks ^^^ | 14:39 |
ttx | just in time for the new season! | 14:40 |
elodilles | :) | 14:40 |
ttx | wondering if we could make it a summit activity | 14:40 |
elodilles | ttx: yepp, that sounds fun :) | 14:40 |
ttx | elodilles: 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_phone | I feel like some logical order is good? | 14:42 |
ttx | Some Celine Dion fan suggested to name all releases "Celine" and be done with it, too | 14:42 |
elodilles | ttx: well, i haven't thought about it, but i guess alphabetical order would be a clear thing | 14:42 |
ttx | yeah I think the alpha order is a nice constraint to have | 14:42 |
diablo_rojo_phone | It was totally ttx ;) | 14:42 |
elodilles | ttx: :D | 14:42 |
ttx | NO IT WAS NOT | 14:42 |
diablo_rojo_phone | No? | 14:43 |
ttx | I proposed they should all be named Adele | 14:43 |
elodilles | :D | 14:43 |
* diablo_rojo_phone whispers to elodilles all about ttx being a closet Celine Dion fan. | 14:43 | |
ttx | but I digress | 14:43 |
diablo_rojo_phone | ..his heart definitely goes on. | 14:43 |
elodilles | :DDD | 14:44 |
ttx | that's the Way it Is | 14:44 |
diablo_rojo_phone | :D | 14:44 |
ttx | I surrender | 14:44 |
elodilles | are these all song names still? :D | 14:44 |
ttx | Love doesn't ask why | 14:45 |
diablo_rojo_phone | Its All Coming Back to me now ;) | 14:45 |
diablo_rojo_phone | Just Walk Away ;) | 14:45 |
elodilles | :D | 14:46 |
diablo_rojo_phone | Okay I'll stop. | 14:46 |
ttx | Goodbye's (the saddest word) | 14:46 |
elodilles | :) | 14:46 |
elodilles | that was nice :) but let's get back to our topic | 14:47 |
elodilles | :) | 14:47 |
elodilles | is 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 |
ttx | nope | 14:50 |
elodilles | ++ | 14:50 |
elodilles | we didn't get to our last topic yet, so here it comes | 14:51 |
elodilles | #topic Open Discussion | 14:51 |
elodilles | so anything else? | 14:51 |
aprice | is this where Celine fans convene? | 14:51 |
ttx | aprice: I did my best to represent with google's help | 14:52 |
fungi | all one of you? ;) | 14:52 |
elodilles | :D | 14:52 |
aprice | ttx: i think you did an admirable job. looks like release naming is done for the next few cycles | 14:52 |
ttx | All By Myself | 14:52 |
ttx | (fungi begged for it) | 14:52 |
* fungi sighs | 14:52 | |
diablo_rojo_phone | Lololol | 14:53 |
elodilles | good :) i'll end the meeting now, but feel free to continue the singing :D | 14:54 |
ttx | ++ | 14:55 |
elodilles | thanks every Celine Dion fan for joining! | 14:55 |
elodilles | #endmeeting | 14:55 |
opendevmeet | Meeting ended Fri May 13 14:55:27 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:55 |
opendevmeet | Minutes: https://meetings.opendev.org/meetings/releaseteam/2022/releaseteam.2022-05-13-14.00.html | 14:55 |
opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/releaseteam/2022/releaseteam.2022-05-13-14.00.txt | 14:55 |
opendevmeet | Log: https://meetings.opendev.org/meetings/releaseteam/2022/releaseteam.2022-05-13-14.00.log.html | 14:55 |
aprice | hahah there are more of us! | 14:55 |
elodilles | :D | 14:55 |
aprice | I just havent found them yet :) | 14:55 |
diablo_rojo_phone | Isn't it required for all Canadians? | 14:56 |
aprice | mnaser: do you agree? | 14:56 |
hberaud | elodilles: thanks | 14:57 |
elodilles | hberaud: thanks too :) | 14:58 |
*** ykarel_ is now known as ykarel | 15:05 | |
*** dviroel is now known as dviroel|lunch | 15:12 | |
*** dviroel|lunch is now known as dviroel | 16:00 | |
*** marios is now known as marios|out | 16:06 | |
opendevreview | Merged openstack/releases master: [Puppet OpenStack] Transition stein to EOL https://review.opendev.org/c/openstack/releases/+/819632 | 16:11 |
*** gibi is now known as gibi_pto | 16:39 | |
mnaser | aprice: yep, canadian approved alright :p | 18:56 |
*** dviroel is now known as dviroel|out | 21:57 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!