14:01:14 <ttx> #startmeeting releaseteam
14:01:14 <opendevmeet> Meeting started Fri Dec  2 14:01:14 2022 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:14 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:14 <opendevmeet> The meeting name has been set to 'releaseteam'
14:01:24 <ttx> Ping list: hberaud armstrong elodilles
14:01:34 <ttx> #link https://etherpad.opendev.org/p/antelope-relmgt-tracking
14:01:46 <ttx> Down to line 131 or so
14:02:32 <ttx> waiting a couple of minutes to see if hberaud joins
14:02:45 <hberaud> o/
14:02:55 <ttx> alright let's go!
14:03:00 <ttx> #topic Check/force Extended Maintenance transitioning patches for stable/wallaby
14:03:16 <ttx> #link https://review.opendev.org/q/topic:wallaby-em
14:03:28 <ttx> looks like all merged
14:03:31 <elodilles> yepp, everything merged \o/
14:03:42 <ttx> which brings us to next topic I guess...
14:03:50 <ttx> #topic Approve 'Set Wallaby status to Extended Maintenance' patch
14:03:56 <ttx> #link https://review.opendev.org/c/openstack/releases/+/862393
14:04:18 <ttx> well that was merged too
14:04:27 <ttx> https://review.opendev.org/c/openstack/openstack-manuals/+/862395
14:04:37 <ttx> same here
14:04:51 <ttx> elodilles: anything to add?
14:05:02 <elodilles> Wallaby transitioned to Extended Maintenance completely \o/
14:05:09 <elodilles> nothing else to add :)
14:05:12 <ttx> #topic Assign next week tasks
14:05:40 <elodilles> (I'll chair the meeting so I've added my name to the countdown mail)
14:05:54 <ttx> i can take the friendly reminder
14:06:28 <elodilles> ack, i guess that is the real task here as all the patches have -1-ACKs from teams
14:06:48 <hberaud> tge trailing patch is already done
14:06:50 <hberaud> the
14:07:04 <hberaud> 2 weeks ago
14:07:10 <ttx> ok so the real task is probably an (all) task pushing them on reviews
14:07:17 <hberaud> https://review.opendev.org/q/topic:zed-trailing-branch-cut
14:07:20 <elodilles> anyway, I've added my name to the 'patch proposing' task but i think there won't be anything else that reaquires a patch
14:07:27 <hberaud> ok
14:07:29 <elodilles> ttx: ++
14:07:29 <hberaud> wfm
14:07:46 <ttx> when should the friendly reminder be sent ? Would Monday work?
14:08:02 <elodilles> I think yes
14:08:14 <ttx> ok will do
14:08:33 <ttx> all assigned, moving on
14:08:38 <ttx> #topic Removing the mistral-extra deliverable
14:08:38 <elodilles> trailing deadline is in 2 weeks, so...
14:09:11 <hberaud> https://review.opendev.org/c/openstack/releases/+/864524
14:09:29 <hberaud> yeah I added this topic because I think elod is right
14:09:49 <hberaud> see his comment on the gerrit patch
14:10:30 <ttx> hmm, should that be posted and discussed on the governance repo first?
14:10:40 <hberaud> https://review.opendev.org/c/openstack/releases/+/865577
14:11:06 <hberaud> yes can't hurt
14:11:28 <ttx> because they are the ones deciding what's in and what's not
14:11:42 <ttx> we can flag issues to them, but otherwise should reflect their decision
14:12:01 <hberaud> elodilles: do you want to socialize your patch toward the governance team?
14:12:14 <ttx> or just propose the change
14:12:14 <elodilles> i see. i thought it can be in governance reference, but without being in the 'antelope release'
14:12:38 <ttx> i think that's not a determination we can make by ourselves
14:12:41 <elodilles> i can propose the change to governance repository + send a mail to ML
14:12:46 <ttx> that would be perfect
14:12:53 <hberaud> elodilles++
14:12:56 <ttx> It might trigger a spark of activity
14:13:07 <ttx> and if not it's a clear TC decision
14:13:18 <elodilles> ++
14:13:32 <ttx> A bunch of users rely on Mistral
14:14:00 <ttx> Like I saw a presentation on Tuesday about how the OVHCloud self-healing robot is using it
14:14:15 <elodilles> yeah, i remember some mails about mistral, but it's really not maintained
14:14:28 <ttx> probably becuase it just works
14:14:29 <elodilles> ttx: :-o
14:14:47 <elodilles> ttx: i have the same feeling
14:14:54 <ttx> so it might decide someone to step up and do this minimal work
14:15:30 <ttx> it's the perfect timing to have that discussion
14:16:06 <ttx> ok, moving on?
14:16:12 <elodilles> ++
14:16:29 <ttx> added a task to track that next week\
14:16:48 <elodilles> cool, thx!
14:16:53 <ttx> #topic Stuck reviews discussion
14:17:12 <ttx> I have a bunch of old stale things in my review log and figured we could use this meeting to review them
14:17:20 <ttx> Add testing task to avoid broken releases https://review.opendev.org/c/openstack/releases/+/853618
14:17:30 <ttx> this one has a bunch of open questions
14:18:51 <ttx> and we discussed next steps at PTG
14:18:56 <ttx> should we drop the patch
14:19:10 <elodilles> yes, we can drop, as things changed
14:19:19 <elodilles> sorry for not abandoning earlier
14:19:28 <ttx> I'll let you abandon it
14:19:33 <hberaud> np
14:19:40 <ttx> Add SLURP mark for Releases page template https://review.opendev.org/c/openstack/releases/+/843623
14:19:54 <ttx> this one has a merge conflict and needs to be refreshed
14:20:03 <ttx> and was
14:20:25 <ttx> lgtm now
14:20:39 <ttx> Fix stable branch naming validation https://review.opendev.org/c/openstack/releases/+/862927
14:20:59 <ttx> sot his one is vblocked on another open question, which is how we should name stable branches going forward
14:21:07 <ttx> i.e. stable/2023.1 or stable/antelope
14:21:20 <ttx> Did the TC make a chocie there, or is it up to us?
14:21:44 <elodilles> it is decided and described in TC resolution
14:21:58 * ttx reads
14:22:35 <ttx> alright
14:22:49 <elodilles> it said stable/2023.1 should be the branch name
14:23:04 <elodilles> (though i haven't found now the resolution)
14:23:22 <ttx> I just read it
14:23:30 <ttx> +2 it is
14:23:36 <elodilles> https://governance.openstack.org/tc/reference/release-naming.html
14:23:46 <ttx> [manila][zed] Add project tracking schedule https://review.opendev.org/c/openstack/releases/+/864313
14:23:46 <elodilles> this one i guess ^^^
14:23:56 <ttx> this one merged
14:24:05 <ttx> Add stable-only tag to generated stable patches https://review.opendev.org/c/openstack/project-config/+/810287
14:25:10 <ttx> this one does not depend on us, but wanted to check that it was current before pushing infra to review it
14:26:00 <elodilles> oh, that's a long forgotten thing
14:27:50 <ttx> forgotten and irrelevant?
14:28:24 <ttx> still looks like a god thing
14:28:31 <ttx> good*
14:28:52 <ttx> but not worth the effort probably
14:29:03 <ttx> shoudl we kill it?
14:29:21 <elodilles> well, i'll read again the doc update patch as I have a -1 from fungi there :)
14:30:00 <ttx> the other stale things are properly marked WIP or W-1 so I'm inclined to let them sleep
14:30:40 <elodilles> maybe I'll mark this as WIP, too, until there is some result with the doc patch :]
14:30:46 <ttx> ++
14:30:59 <ttx> #topic Open Discussion
14:31:04 <ttx> Anything else?
14:31:11 <fungi> elodilles: that -1 is from frickler
14:31:36 <fungi> i haven't reviewed 810287 (yet anyway)
14:32:07 <ttx> I think he's talking about a doc patch related to this
14:32:18 <elodilles> fungi: https://review.opendev.org/c/openstack/project-team-guide/+/810661
14:32:22 <fungi> oh, 810661 has a -1 from me, yes
14:32:28 <fungi> which is related to it
14:34:04 <fungi> my concern being taking up a rather significant chunk of the available real estate in the commit subject line (more than 50% of the typical 50-character limit)
14:35:10 <fungi> in addition to commit footer lines (which can be as long as you like since they get dedicated lines), we also have the option of using and filtering on gerrit hashtag metadata now for things like this
14:36:08 <fungi> er, taking up more than a quarter of the 50 character recommended limit
14:37:02 <opendevreview> Merged openstack/releases master: Add SLURP mark for Releases page template  https://review.opendev.org/c/openstack/releases/+/843623
14:37:05 <opendevreview> Merged openstack/releases master: Fix stable branch naming validation  https://review.opendev.org/c/openstack/releases/+/862927
14:37:05 <fungi> anyway, i'm only -1 on that proposal, not -2, so open to being overridden by other core reviewers
14:37:38 <elodilles> fungi: i don't have strong feeling to tell you the truth :)
14:37:56 <ttx> how about dropping it if nobody is convinced
14:37:56 <elodilles> fungi: we have this 'process' working in nova
14:38:00 <fungi> but i do think overloading the commit subject line with metadata is suboptimal when gerrit has more extensible metadata options
14:38:21 <fungi> elodilles: has nova considered improving their process?
14:38:35 <elodilles> fungi: it was not a topic there
14:39:17 <fungi> blindly copying the behavior of one team because "it works" when there could be better options which they too could take advantage of seems like a risk of encoding suboptimal process as recommendation
14:39:57 <elodilles> fungi: i think it is not that big of a problem than the discussion it caused 1 yr ago
14:41:02 <fungi> yeah, when this originally came up, i don't think gerrit hashtags were available (or they had only just become so)
14:41:07 <elodilles> fungi: so i can live without the 'stable-only' tag in the bot generated patches (involving that i update 2-4 patches every 6 months)
14:41:48 <elodilles> fungi: gerrit hashtags is a good idea, though
14:42:08 <hberaud> agree
14:42:11 <fungi> you can add as many of those as you like, and gerrit can filter on them
14:42:25 <fungi> and make dashboards around them
14:42:27 <fungi> and if it helps, we can teach gerritbot about them too
14:42:43 <hberaud> good idea
14:42:46 <fungi> so it can include hashtag info in its change proposed/merged announcements and stuff
14:43:01 <fungi> also they're included on the e-mail notifications gerrit sends, so you can filter based on them in your mua too
14:44:00 <elodilles> all sound good to me :)
14:44:28 <elodilles> nova scripts needs to be updated for that, too, but i guess that is the least problematic part
14:44:33 <fungi> if there's an interest in using them for something like this, we should probably restart the discussion about allowing them for all users, or at least doing so in all official openstack  projects (can just be an acl update to the inherited openstack/meta-config  acl)
14:45:20 <fungi> right now  i think only a few projects have updated their acls to allow them, and some may have restricted their use to core review groups initially, but are probably open to revisiting that
14:45:25 <elodilles> that would be needed, as committers should set these hashtags
14:45:33 <fungi> right
14:46:42 <ttx> ok maybe we can continue that offline
14:46:48 <ttx> Any other topic to discuss?
14:46:52 <elodilles> ttx: ack
14:47:00 <hberaud> nope
14:47:10 <elodilles> nothing from me
14:47:44 <opendevreview> Merged openstack/releases master: Release and branch cut test for 2023.1 Antelope  https://review.opendev.org/c/openstack/releases/+/860869
14:48:04 <elodilles> let's see the 1st stable/2023.1 branch cut ^^^
14:48:20 <fungi> exciting!
14:50:12 <ttx> alright... closing the meeting then
14:50:16 <ttx> #endmeeting