16:00:29 <smcginnis> #startmeeting releaseteam
16:00:31 <openstack> Meeting started Thu Feb  6 16:00:29 2020 UTC and is due to finish in 60 minutes.  The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:34 <smcginnis> Ping list: ttx armstrong diablo_rojo, diablo_rojo_phon
16:00:35 <armstrong> o/
16:00:35 <openstack> The meeting name has been set to 'releaseteam'
16:00:41 <smcginnis> #link https://etherpad.openstack.org/p/ussuri-relmgt-tracking Agenda
16:00:45 <hberaud> o/
16:00:48 <elod> o/
16:00:57 <smcginnis> Line 278
16:01:11 <elod> hi, i'm here if there's anything regarding Rocky EM :]
16:01:19 <smcginnis> Great, thanks elod!
16:01:26 <smcginnis> #topic Analyze MembershipFreeze test results
16:01:47 <smcginnis> ttx: All yours. :)
16:02:09 <ttx> ohai
16:02:27 <ttx> So basically this is the list of things that are in governance, but have no deliverable file
16:02:49 <ttx> In theory, if those are to be included in Ussuri, they need to be declared (and releases at least once) by u2
16:02:56 <ttx> ussuri-2 I mean
16:03:06 <ttx> Some are very recent additions
16:03:24 <ttx> like sushy-cli (Ironic)
16:03:28 <ttx> ovn-octavia-provider (Neutron)
16:03:33 <ttx> js-openstack-lib (OpenStackSDK)
16:03:37 <ttx> tripleo-operator-ansible (TripleO)
16:03:52 <ttx> For those we need to reach out to teh PTLs/liaisons and ask what's their goal here
16:03:59 <smcginnis> From what I know of them, I wouldn't be surprised if they aren't ready until Victoria.
16:04:10 <ttx> Some others have been around for a while
16:04:19 <smcginnis> Anyone want to volunteer to check in with the PTLs?
16:04:22 <ttx> smcginnis: that would be fine. We just need to know for sure
16:04:27 <smcginnis> Yep
16:04:41 <ttx> For OpenStack-Helm I opened a review to clarify
16:05:10 <ttx> Adjutant, I think eiether shoudl publish in Ussuri or be removed from official projectteams, we've been waiting for some time now
16:05:27 <ttx> barbican-ui -- looks like a stillborn project
16:05:37 <smcginnis> They did want to release something for train, but after the deadline.
16:05:43 <smcginnis> Ajutant that was. ^
16:05:48 <ttx> oh, ok
16:05:56 <ttx> So maybe we should just propose the deliverable files
16:06:00 <ttx> and have them confirm
16:06:04 <ttx> (Adjutant)
16:06:10 <smcginnis> That sounds good to me.
16:06:33 <ttx> One way to reach out to PTLs on the first 4 would be to propose files as well
16:06:45 <ttx> Makes it easier to track status
16:06:54 <smcginnis> Maybe that would be best. Then if they +1, we're ready to go.
16:07:00 <smcginnis> And it's all captured in the review.
16:07:00 <ttx> like +1 if you'll release in Ussuri, -1 if Victoria material;
16:07:21 <ttx> and we can help with pinging as needed if the review lingers
16:07:46 <ttx> Would not mind someone else taking it up from here, I sunk a lot of hours into relmgt this week :)
16:08:23 <smcginnis> I'm still struggling to catch up on work things since coming back from FOSDEM. Anyone else want to take the action to submit these patches?
16:09:49 <smcginnis> We can put it on the task list for next week and whoever has the time can try to get to it I suppose.
16:10:08 <ttx> ok
16:10:37 <ttx> adding
16:10:48 <smcginnis> For the "things that have been there awhile" - there is no deliverable file in U yet? Or there is but we keep needing to punt them?
16:11:18 <ttx> there is none
16:11:27 <ttx> just that the question was asked a few cycles before too
16:11:28 <smcginnis> OK, good.
16:12:10 <ttx> ok next topic
16:12:30 <smcginnis> #topic Validate countdown email content
16:12:35 <smcginnis> #link https://etherpad.openstack.org/p/relmgmt-weekly-emails
16:12:46 <ttx> scroll to ~111
16:13:30 <ttx> so... the proposed wording here is to use the weekly release countdown instead of a review
16:13:40 <ttx> to ping those projects
16:13:41 <smcginnis> Good, you added the list of projects missing there.
16:13:46 <smcginnis> That looks good.
16:14:35 <ttx> hmm
16:14:52 <ttx> so in theory they need to do a release, not just approving a skeleton file
16:15:01 <smcginnis> "if you plan on releasing in Ussuri, or -1 if you need one more cycle to be ready"?
16:15:09 <smcginnis> True
16:15:46 <ttx> where do we want to set the line
16:15:47 <smcginnis> Please update the skeleton deliverable to add an actual release before the milestone-2 deadline to be included in Usurri.
16:15:50 <smcginnis> ?
16:16:02 <smcginnis> Ah, that's basically what you wrote. :)
16:16:08 <ttx> yeah...
16:16:45 <smcginnis> Yeah, I think sticking with the milestone-2 deadline is best.
16:16:59 <smcginnis> If they need a few days to get things in order, I'm fine being a little lenient on that.
16:17:12 <smcginnis> But hopefully they will be responsive.
16:17:38 <ttx> yeah and in some cases people just say "depends what will happen in the next months"
16:18:00 <smcginnis> Days or week seem OK, months I would be a little concerned about at this point in the cycle.
16:18:30 <ttx> ok, you can refine the wording before sending
16:18:46 <ttx> just post it on the etherpad so that I copy the right one in process
16:18:46 <smcginnis> Maybe we should change "have been posted" to "will be posted" so sending the countdown email isn't blocked by needing someone to get those patches up right away.
16:18:58 <smcginnis> I can try to get to them, but I can't make any promises at this point.
16:19:03 <ttx> ++
16:19:33 <ttx> I trust you to find the right nuance
16:20:06 <smcginnis> OK, then that all looks good.
16:20:20 <smcginnis> #topic What to do with things defined in deliverable files but no longer in governance, and not "release-model:abandoned" (yet)
16:20:33 <ttx> yeah so
16:21:01 <ttx> Those are the ones that have deliverable files (in independent generally) but are not under governance anymore
16:21:24 <ttx> We pushed a bunch out by adding release-model:abandoned to them
16:21:44 <ttx> but that applies well to things that were official but weer abandoned.
16:22:02 <ttx> Not so well to things that never really were a part of openstack but which used relmgt
16:22:05 <smcginnis> Things like refstack, doc8, and bandit all seem important enough to keep around.
16:22:25 <ttx> or things that used to be lodged in a project team, and are still alive and kicking under a sig
16:22:57 <ttx> In theory, project teams = openstack = releases.openstack.org content
16:23:16 <ttx> So we have things coming from now-SIGs
16:23:32 <ttx> and legacy stuff
16:23:48 <ttx> Legacy stuff I'm tempted to just mark release-model:abandoned
16:24:06 <smcginnis> Yeah, that's what I was thinking.
16:24:21 <ttx> (the difference with others is that those were removed from governance rather than abandoned by their (still standing) project team
16:24:40 <smcginnis> For the SIGs and WGs, I'm tempted to treat those as official. Kind of the benefit of forming an official SIG.
16:25:21 <ttx> One issue is taht it's actually what marks the line between a SIG and a project team
16:25:40 <ttx> Project teams (udner the TC) are under the bylaws responsible for producing openstack
16:25:56 <ttx> so that is why there is the equality above
16:26:28 <ttx> Like refstack, for example, is clearly not a part of openstack software
16:26:43 <ttx> So, multiple options
16:26:54 <ttx> Solution 1
16:27:26 <ttx> we remove all the deliverable files for those, and add direct tagging rights so that they can just release by themselves directly
16:27:32 <ttx> Solution 2
16:27:58 <ttx> We grandfather things that we used to manage, but add some flag so that they don't appear on releases.o.o
16:28:34 <ttx> In some cases (like bandit) we actually only have part of the releases as development continued elsewhere
16:28:53 <ttx> i fgeel like removing the file makes more sense in that case
16:29:11 <smcginnis> I was all in favor of 2 at first, but I'm starting to think 1 is the right option.
16:29:22 <smcginnis> This isn't saying these things aren't important and are no longer useful.
16:29:31 <ttx> It's certainly the simplest
16:29:42 <smcginnis> It's just making clear the line between what is OpenStack and what is a useful tool created by the OpenStack community.
16:30:06 <smcginnis> And if they have the rights to push tags, they can still do releases, just not through us.
16:30:16 <ttx> yes
16:30:35 <ttx> basically, relmgt only works if we have exclusive rights to tagging
16:30:47 <ttx> otherwise people pushing direct releases can screw the automation
16:31:18 <ttx> and it's difficult to justify the openstack relmgt project team having full control on a SIG's production
16:31:32 <smcginnis> OK, so for each one in the SIG/WG list, two patches, one to remove the deliverable files and one to update the Gerrit ACLs.
16:31:33 <ttx> especially if the idea is NOT to show it on releases.o.o
16:31:41 <smcginnis> And for the legacy stuff, just one patch to drop the files.
16:31:46 <smcginnis> Sound right?
16:31:52 <ttx> Generally they already have ACL
16:32:04 <ttx> since we could not assert authority over them
16:32:05 <smcginnis> Even easier then. We can just drop them all.
16:32:14 <ttx> yes. I bet nobody would notice
16:32:29 <smcginnis> ttx: Even the ones that were under openstack-docs and moved to the SIG?
16:32:41 <ttx> smcginnis: example?
16:32:53 <smcginnis> I suppose it's not time critical if they don't have the right ACLs. They can always be updated if and when needed.
16:33:07 <smcginnis> No example, just thinking that transition might have not included changing ACLs.
16:33:10 <smcginnis> I haven't looked.
16:33:19 <ttx> doc8 says This project is no longer maintained in OpenStack.
16:33:52 <ttx> openstack-manuals does not release really
16:34:21 <smcginnis> OK, then let's just drop the files in openstack/releases.
16:34:31 <ttx> the most sensitive one is probably  *-powervm
16:34:45 <ttx> since they were a project team and included and all until recently
16:35:02 <ttx> but we weer clear that they would get tag power and do their own releasing
16:35:17 <smcginnis> OK, shouldn't be a problem then.
16:35:30 <ttx> but still, sounds like rewriting history
16:35:34 <smcginnis> We might just have to help them if they have any questions about how releasing should work now.
16:35:46 * ttx checks something
16:36:36 <ttx> yeah, so...
16:36:56 <ttx> The problem with *-powervm is... they were included in cycle releases in the past
16:37:07 <ttx> so if we remove the file, we rewrite history a bit
16:37:27 <ttx> If we mark it "abanonded" it's inaccurate, since development (I suppose) continues
16:37:39 <ttx> We don;t have a good solution in that case
16:38:02 <smcginnis> I suppose we could add yet another tag, but I'd reallly rather not.
16:38:36 <ttx> hmmm, if we mark it "abandoned", would that show in a cycle-based page?
16:38:36 <smcginnis> Maybe that one we just add a comment in the YAML file.
16:38:46 <smcginnis> No, I don't think so.
16:39:10 <ttx> might be the solution. What we want is it to show in old releases, and no longer trigger alarms in recent ones
16:39:28 <ttx> but without saying in the website that it is end-of-life
16:40:02 <ttx> We can certainly make sure the "end of life" mention does not show on cycle pages, only in independent
16:40:12 <ttx> then it's an accurate reporting
16:40:20 <smcginnis> That seems reasonable.
16:40:32 <ttx> ok writing that down in the etherpad
16:40:36 <smcginnis> Or we just add a comment on the top of the file saying don't use this anymore and leave it at that. :)
16:42:04 <ttx> smcginnis: that would still trigger my scripts
16:42:18 <ttx> they need a "nothing to see there anymore" flag :)
16:42:24 <smcginnis> Oh, right.
16:42:35 <smcginnis> OK, what you added in the etherpad looks good to me.
16:42:43 <smcginnis> Move along?
16:42:47 <ttx> yes
16:42:51 <ttx> I think I have what I need
16:42:54 <ttx> Will push those
16:42:57 <smcginnis> Thanks
16:43:06 <smcginnis> #topic release-approval job
16:43:14 <smcginnis> Just wanted to make sure we did a quick check on this.
16:43:22 <smcginnis> I saw you proposed updates. The job update merged.
16:43:34 <ttx> we should reenable it! I like looping jobs
16:43:38 <smcginnis> So after this, I think the zuul config patch can be restored.
16:43:41 <ttx> yes
16:44:10 <smcginnis> That would make our activity stats look amazing. :D
16:44:25 <smcginnis> Anything else we need to discuss about that, or move along?
16:45:02 <ttx> I'll watch it
16:45:08 <smcginnis> #topic Validate plan toward ussuri-3, add availability
16:45:20 <smcginnis> Heh, availability. Yeah. So about that.
16:45:24 <ttx> Ok so I spent some time organizing the tasks
16:45:28 <ttx> leading up to u3
16:45:29 <smcginnis> I'll be on the road pretty much most of March and part of April.
16:45:37 <smcginnis> I need to add that to the etherpad.
16:45:47 <smcginnis> Not entirely disconnected at least, just distracted.
16:45:51 <smcginnis> Thanks for adding the tasks.
16:46:02 <ttx> that will be... interesting
16:46:19 <smcginnis> I will pray for good hotel wifi. :)
16:46:37 <ttx> good new is March is relatively calm
16:46:40 <ttx> news
16:46:45 <ttx> April, less o
16:48:16 <smcginnis> The final lib release should be fine.
16:49:20 <smcginnis> OK, I will make sure to set aside time. This will really help with the tasks all spelled out in the etherpad.
16:51:15 <smcginnis> All the tasks look fine to me.
16:51:19 <smcginnis> Anything to discuss on those?
16:51:41 <ttx> nope
16:52:07 <smcginnis> #topic PTG space needs
16:52:26 <smcginnis> An email went out asking for space needs at the upcoming PTG in Vancouver.
16:52:38 <smcginnis> We can ask for a room, or we can just plan to meet in the hallway again.
16:52:47 <smcginnis> Not sure if we need a full room to ourselves or not.
16:52:58 <fungi> not sure how big the hallways are either ;)
16:53:02 <smcginnis> ttx: Any idea on space restrictions? Are there expected to be extra rooms?
16:53:16 <smcginnis> fungi: I would be fine on the waterfront "hallway" :)
16:53:24 <fungi> oh, me^2
16:53:28 <smcginnis> Or maybe the water plane hallway.
16:53:42 <ttx> fungi: looks like the check-approval thing is now running as intended. Is there a reason why it's
16:53:43 <smcginnis> Or pub hallway. I'm flexible. :D
16:53:54 <ttx> not (yet) pushing the new label ? https://review.opendev.org/#/c/705991/2
16:54:12 <ttx> No need for room, we can use a corner
16:54:20 <fungi> i'll take a look
16:54:30 <smcginnis> Good, I will respond to the email with that.
16:54:35 <smcginnis> #topic AOB
16:54:37 <smcginnis> Anything else?
16:55:21 <diablo_rojo> nope
16:55:37 <elod> maybe one thing worth to mention about Rocky EM: tempest is now blocking it
16:55:50 <smcginnis> Temptest py2 issues?
16:55:55 <elod> yes, that one
16:56:17 <elod> actually tempest >=3.6
16:56:21 <prometheanfire> smcginnis: we were talking about that a little in -infra
16:56:32 <fungi> there was a time when we stopped supporting year-old releases once we hit challenges testing them
16:56:56 <smcginnis> It would be nice to get a final release out before the end, but that makes it hard if the gate is blocked.
16:57:14 <smcginnis> I know gmann was looking at another option to get tempest to work right, so hopefully he gets that figured out.
16:57:15 <fungi> can always remove tempest jobs from them
16:57:24 <smcginnis> True
16:57:30 <smcginnis> Risky though.
16:58:10 <elod> i see WIP patches, but maybe this will have some effect on the final releases
16:58:32 <smcginnis> Thinking maybe we need to push back the deadline if things don't get cleared up soon?
16:59:07 <smcginnis> We'll have to see how things go.
16:59:16 <smcginnis> Sorry, I need to get on another meeting.
16:59:19 <ttx> me too
16:59:28 <smcginnis> Let's continue any discussions out of meeting in the channel.
16:59:29 <ttx> Thanks smcginnis
16:59:31 <smcginnis> #endmeeting