16:03:30 <smcginnis_> #startmeeting releaseteam
16:03:30 <openstack> Meeting started Thu Dec 12 16:03:30 2019 UTC and is due to finish in 60 minutes.  The chair is smcginnis_. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:30 <diablo_rojo_phon> smcginnis: we can just wait till you're not busy :)
16:03:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:03:34 <openstack> The meeting name has been set to 'releaseteam'
16:03:34 <smcginnis_> #chair ttx
16:03:35 <openstack> Current chairs: smcginnis_ ttx
16:03:35 <diablo_rojo_phon> Or not.
16:03:39 <smcginnis_> :)
16:03:39 <hberaud> o/
16:03:49 <diablo_rojo_phon> o/
16:04:03 <smcginnis_> I'm just waiting for someone to come back and call me up, so we'll see how this goes.
16:04:09 <smcginnis_> #link https://etherpad.openstack.org/p/ussuri-relmgt-tracking
16:04:21 <fungi> chairing is sharing!
16:04:22 <smcginnis_> Line 120
16:04:33 <smcginnis_> #chair fungi
16:04:33 <openstack> Current chairs: fungi smcginnis_ ttx
16:04:38 <smcginnis_> #chair diablo_rojo_phon
16:04:39 <openstack> Current chairs: diablo_rojo_phon fungi smcginnis_ ttx
16:04:40 <fungi> hah
16:04:55 <smcginnis_> You get a chair, you get a chair, you get a chair (in my best Oprah voice)
16:05:10 <diablo_rojo_phon> Full disclosure, I did not get my homework from last week done, but am currently working on it.
16:05:20 <diablo_rojo_phon> LOL
16:05:25 <smcginnis_> #topic Countdown email
16:05:29 * fungi is a musical chair
16:05:30 <smcginnis_> diablo_rojo_phon: I think I got it all.
16:05:40 <smcginnis_> fungi: First chair?
16:05:57 <ttx> #link https://etherpad.openstack.org/p/relmgmt-weekly-emails
16:06:03 <fungi> first chair triangle
16:06:18 <smcginnis_> Line 57 or so.
16:06:51 <smcginnis_> ttx: Looks good. The only thing I was thinking of adding is a mention of the V name poll.
16:07:05 <smcginnis_> Even though that is technically done by what this countdown week covers.
16:07:14 <smcginnis_> But might get a couple more folks.
16:07:33 <ttx> yeah... also it's not a releasemanagement thing that much
16:07:33 <smcginnis_> Any other feedback from anyone on the countdown email content?
16:07:41 <ttx> feel free to add though :)
16:07:49 <fungi> this was the cutoff for services dropping python2 testing, since libraries will be clear to start doing so next week. worth a mention?
16:07:51 <smcginnis_> Yeah, just thought it was a convenient place to add it.
16:08:00 <smcginnis_> fungi: Oh, good point!
16:08:19 <smcginnis_> That one is release related.
16:08:31 <smcginnis_> ttx: Want to add a mention about that?
16:08:56 <ttx> sure
16:08:59 <smcginnis_> Thanks!
16:09:06 <smcginnis_> Anything more on the countdown email?
16:09:27 <diablo_rojo_phon> None from me.
16:09:37 <smcginnis_> #topic Review list of stuff in releases but not in governance
16:10:08 <ttx> fungi: please review my proposed wording for correctness
16:10:27 <ttx> OK, so I ran an analysis and uncovered ancient artifacts as always
16:10:40 <ttx> I'm the Indiana Jones of Governance
16:10:48 <fungi> lookin
16:10:49 <smcginnis_> :)
16:11:06 <smcginnis_> It does look like maybe we need an exceptions list.
16:11:14 <smcginnis_> Another yaml file for the data directory maybe?
16:11:35 <ttx> I think we can evolve the tool we use to check to add some of the corner cases
16:11:51 <ttx> Like if a repo is in technical-committee-repos.yaml it's OK
16:11:51 <fungi> refstack and python-tempestconf were under the refstack team before it was dissolved
16:12:04 <fungi> and the interop wg adopted it
16:12:11 <fungi> er, adopted those
16:12:34 <smcginnis_> We have some SIG and WG owned deliverables. And maybe some board owned ones too.
16:12:36 <ttx> Refstack and the SIGs are another case
16:12:47 <ttx> Our current stance on those is that they should be released manually
16:13:04 <fungi> where's the ossa repo? should presumably be under sigs
16:13:23 * fungi might just be blind
16:13:23 <ttx> But that uncovered another issue... which is that deliverable files in _independent are never really cleaned up
16:13:34 <ttx> fungi: it's in SIG repos alright
16:13:36 <fungi> oh, right, this is just stuff in releases
16:13:38 <ttx> Just not in releases
16:13:44 <fungi> sorry :/
16:13:59 <ttx> So for old stale _independent deliverable files we have two options
16:14:16 <ttx> We can somehow mark them deprecated, so that we don;t accidentally add to them
16:14:18 <smcginnis_> I do kind of like the historical aspect of those. But I could see either removing them, or adding a new flag that explicitly says active-status: historical or something like that.
16:14:24 <fungi> i think the infra repos there should probably be treated like another sig, since it likely will be one in the not too distant future
16:14:29 <ttx> but they would still appear in the releases.o.o site
16:14:35 <ttx> Or we can aggressively clean them up
16:14:55 <ttx> For now I think we can add a flag to those
16:15:03 <smcginnis_> They probably should still be shown on releases.o.o, since they were official releases at the time, right?
16:15:07 <ttx> which I can use in my tool to filter them out
16:15:28 <ttx> smcginnis_: For old series sure... Independent things are another beast though
16:15:42 <ttx> They very much look like an openstack deliverable still, while they are not
16:16:06 <ttx> I guess we can use that same flag to show them as legacy on the website
16:16:09 <smcginnis_> Maybe we could update the sphinx extension to recognize this new flag and display them differently?
16:16:18 <ttx> jinx
16:16:23 <smcginnis_> ;)
16:16:32 <ttx> ok next.. indfra things
16:16:33 <smcginnis_> Doesn't seem like that would be too difficult.
16:16:41 <fungi> i think the infra repos there should probably be treated like another sig, since it likely will be one in the not too distant future
16:16:55 <ttx> We have three repos that are in Infra (which traditionally does not use openstack/releases)
16:17:08 <ttx> but those do
16:17:14 <ttx> yaml2ical
16:17:16 <ttx> python-storyboardclient
16:17:18 <ttx> diskimage-builder
16:17:22 <fungi> at least one of those didn't start out as an infra project, which is part of the reason it's that way
16:17:31 <ttx> I think the solution is to make sure they are directly released, for consitency
16:17:34 <fungi> infra adopted dib away from tripleo
16:18:07 <fungi> yeah, i'm fine removing them from the releases repo, but the teams managing them are somewhat independent entitles too
16:18:08 <ttx> then I would remove them from the releases.o.o website since they never really belonged there imho
16:18:34 <ttx> or at least not more than any other infra repo
16:18:40 <fungi> the dib maintainers may appreciate relying on openstack releases, but i expect they can adapt
16:19:00 <ttx> ok, will handle on case-by-case basis anyway
16:19:04 <fungi> the storyboardclient lib is mostly dead, because storyboard's rest api is arguably more usable
16:19:07 <smcginnis_> Can we add docs to somewhere to make easier for them to know what to do without using this team?
16:19:30 <ttx> smcginnis_: it's documented in infra docs alright
16:19:30 <openstackgerrit> Vishal Manchanda proposed openstack/releases master: [doc]Correcting broken link  https://review.opendev.org/698751
16:19:38 <fungi> yaml2ical is also somewhat independent of the infra team as a whole, but again could probably tag their own releases or ask for help from the rest of the infra folks
16:19:47 <ttx> Next category is stuff in legacy
16:20:00 <ttx> I think we can handle them the same way as SIG stuff
16:20:22 <ttx> and keep them around for now
16:20:33 <smcginnis_> Some of those are retired.
16:20:43 <smcginnis_> But no harm keeping them around somewhere.
16:20:59 <fungi> i think they're all retired? thus why they're in legacy.yaml
16:21:00 <ttx> smcginnis_: I guess one question is... should we stop at x/ things
16:21:19 <ttx> I feel bad having x/ things appear in releases.o.o
16:21:54 <smcginnis_> Yeah. We really shouldn't since that was a move to explicitly separate out the "non-OpenStack" things.
16:22:09 <smcginnis_> Though they were at one point.
16:22:43 <ttx> so what would you recommend?
16:23:10 <smcginnis_> All of them were official at one point, right?
16:23:29 <fungi> if they're listed in legacy.yaml then yes
16:23:46 <smcginnis_> I guess independent ones should have this new flag and be reflected right on releases.o.o.
16:23:58 <smcginnis_> If we still have any placeholders for cycle based ones, those should be removed.
16:23:58 <ttx> smcginnis_: there is no "all" in this game. Always corner cases
16:24:09 <fungi> that file is purely a list of teams and deliverables which were once in reference/projects.yaml, so formerly official openstack deliverables
16:24:13 <ttx> Like... sqlalchemy-migrate
16:24:14 <smcginnis_> And past cycles, they should probably stay for historical reference.
16:24:54 <ttx> But yeah, those in legacy I feel like we should keep in
16:24:58 <ttx> Should not be x/ things now
16:25:14 <ttx> OK next.. alignment issues
16:25:15 <smcginnis_> sqlalchemy-migrate is technically deprecated I believe.
16:25:43 <ttx> Those are things where the deliverable in governance does not exactly match the deliverable in releases
16:25:53 <ttx> Probably need to be aligned on a case-by-case basis
16:26:10 <smcginnis_> They need to be grouped? Or they are grouped but should be separated out?
16:26:29 <fungi> i'm still unconvinced of the deliverable model allowing multiple repositories per deliverable, especially if they get released at different times
16:26:31 <ttx> first two.. used to be separate deliverables
16:27:04 <ttx> Last one... has releases while being marked "release-management:none"
16:27:19 <ttx> I need to check what "current" means for each though
16:27:41 <smcginnis_> I do prefer separating out in most cases. There are a few that are always released as a whole, but we seem to run into cases where they are grouped but then need to be individually released more often. Easy enough to release a group of separate deliverables.
16:27:58 <ttx> Last category... things that are not in governance, not in legacy, and now in x/
16:28:01 <smcginnis_> Hmm, what was release-management:none?
16:28:18 <ttx> smcginnis_: for deliverables that are not meant to be released
16:28:20 <fungi> ironic-python-agent-builder
16:28:24 <ttx> like nova-specs
16:28:37 <smcginnis_> Why are they even listed in the releases repo then?
16:28:51 <ttx> smcginnis_: that is the question
16:29:08 <fungi> i agree things which are not meant to be released probably have limited utility for entries in release management
16:29:10 <ttx> I'm not sure if the egg is before the chicken though
16:29:17 <smcginnis_> I would be for cleaning those up. It feels odd to me, but maybe I'm missing some reasoning behind it.
16:29:22 <ttx> Like there were releases but they don;t want any anymore
16:29:31 <smcginnis_> Could be.
16:29:34 <ttx> Or they did not want releases but after all did some
16:29:36 <fungi> ahh, so could treat them the same as retired
16:29:45 <fungi> from a historical release listing standpoint
16:29:46 <smcginnis_> That could work.
16:29:50 <ttx> Like I said, a whole forest of corner cases
16:29:56 <smcginnis_> If that is indeed the case.
16:30:17 <ttx> Si fir the last category, are we OK with cleaning them up ? Those are the ones appearing as x/
16:30:26 <smcginnis_> Thierry "Maze Runner" Carrez
16:30:49 <ttx> or pointing to an no-longer existant repo, like https://releases.openstack.org/independent.html#none-python-tuskarclient
16:31:01 <smcginnis_> Yeah, I think I'm good with just cleaning those up.
16:31:52 <smcginnis_> doc8 is the only one that I have some concern about since it's widely used, but whether it is active and released outside of here, that's a different discussion than whether it should be present in the releases repo.
16:31:54 <fungi> i think those are probably (in at least some cases) examples of where the tc has failed to properly review retirements
16:32:02 <fungi> and/or removals from governance
16:32:08 <ttx> is it widely used?
16:32:09 <smcginnis_> We really didnt have that process well documented for awhile.
16:32:14 <smcginnis_> doc8?
16:32:20 <ttx> yes
16:32:35 <smcginnis_> Yeah, at least several use it to lint their rst docs.
16:32:49 <smcginnis_> Cinder for sure, but I'm pretty sure many of the others I've looked at.
16:32:53 <ttx> hmm, it should probably be adopted somwhere then
16:33:14 <smcginnis_> I didn't even realize it was out of this community. I thought it was just a tool we used.
16:33:20 <ttx> x/ is really for things that are not maintained or depended on
16:33:30 <fungi> some quick spelunking says we started tracking governance removals that way in september 2015 with the retirement of magnetodb
16:33:38 <ttx> Same for sqlalchemy-migrate really
16:33:42 <smcginnis_> I'd say it would be a good openstack-manuals deliverable, but I need to get over that. :]
16:34:14 <fungi> it might be good to get the governance data corrected for any of those which were formerly official
16:34:19 <ttx> OK, let me move doc8 to the category just above then. Active non-legacy non-governance stuff
16:34:38 <smcginnis_> Should we present this list to the TC and let them discuss whether they should be official or not?
16:35:02 <fungi> or whether their retirement should be recorded at least
16:35:16 <fungi> retirement and/or removal recorded
16:35:19 <ttx> Yeah, we should open a larger discussion for those two
16:35:28 <smcginnis_> Yeah, that would be a good outcome of the review to finalize any retirements.
16:35:46 <smcginnis_> Someone want to take that action? diablo_rojo_phon ?
16:35:48 <fungi> it leaves gaps in teh historical record otherwise, is my concern
16:36:01 <ttx> I can take it
16:36:07 <smcginnis_> Great, thanks ttx
16:36:12 <ttx> Have to follow-up on most of those really
16:36:32 * diablo_rojo_phon was about to take it but nevermind :)
16:36:42 <smcginnis_> Teamwork!
16:36:54 <fungi> i feel bad advocating for it and not volunteering, but i wouldn't be able to pick it up until early 2020 at this point
16:36:55 <ttx> I'll introduce a "legacy" flag for things that have _independent files but are now legacy
16:37:06 <ttx> I'll push infra things to be handled like other infra things
16:37:15 <fungi> wfm
16:37:16 <ttx> I'll aggressively remove the x/ old inactive things
16:37:24 <smcginnis_> Love it when a plan comes together.
16:37:40 <smcginnis_> Maybe make a note some time in January to follow up on the progress?
16:37:48 <ttx> For SIG things what did we say?
16:37:57 <smcginnis_> Exception list?
16:37:57 <ttx> Treat them like legacy things?
16:38:28 <fungi> in most cases those are ~abandonware which got carried over from dissolved teams, or are otherwise not being released formally anyway
16:38:46 <smcginnis_> Those can definitely be treated as legacy.
16:38:54 <smcginnis_> There are a few that are current with active SIGs though.
16:39:02 <fungi> might be a good idea to remind their corresponding sigs to think about whether they need them kept around or should retire them properly
16:39:10 <ttx> ok, I'll make slow progress on this, handle low-hanging fruit first
16:39:18 <smcginnis_> I see those as quasi-official, even though they may not be under governance.
16:39:28 <fungi> like, security sig has talked about retiring syntribos
16:39:40 <ttx> Thanks for humoring my classification brain
16:39:41 <smcginnis_> That sounds good. Once we get this cleaned up a bit, we can focus on some of the more interesting corner cases.
16:40:00 <fungi> i guess the others in the sigs list are probably actually active
16:40:01 <smcginnis_> It's good to review and get things cleaned up. Otherwise things eventually snowball.
16:40:07 <fungi> so i take back what i said about most being abandonware
16:40:13 <fungi> it's really just syntribos
16:40:21 <smcginnis_> There's always a mix.
16:40:30 <smcginnis_> OK, better move on for now.
16:40:31 <ttx> a forest I tell you
16:40:35 <smcginnis_> #topic Review availablility / action / meetings plan until Ussuri-2
16:40:51 <smcginnis_> M-2 is the week of Feb 10.
16:41:01 <ttx> I set up actions and meetings and emails for the coming weeks
16:41:09 <ttx> Please review, add your availability etc
16:41:25 <ttx> I have all covered until R-12
16:41:37 <ttx> Lots of skips
16:41:49 <smcginnis_> Just looking at the skips. I think those make sense for those weeks.
16:42:53 <smcginnis_> Yeah, looking through, looks like a good plan to me.
16:42:57 <diablo_rojo_phon> Will do.
16:43:10 <ttx> Just added a Ussuri-1 topic
16:43:30 <ttx> so taht we discuss how we finalize processing it tomorrow and Monday
16:43:51 <smcginnis_> Finalizing would just be processing any milestone-1 releases?
16:44:08 <ttx> In theory we do:
16:44:09 <smcginnis_> #topic Ussuri-1 status
16:44:20 <ttx> -- Tue-Thu approve as soon as they get a +1
16:44:29 <ttx> -- Fri approve the ones with no feedback at all
16:44:37 <ttx> -- Mon discuss remaining -1 posted
16:45:02 <ttx> Looking up the list we have...
16:45:14 <smcginnis_> I do think we need to change process a little. We state we will propose those releases at the beginning of the week, then process by the end of the week if we don't get the ack before then.
16:45:18 <smcginnis_> We never seem to be able to do that.
16:45:45 <ttx> I don;t agree... I feel like we managed to do that
16:45:48 <smcginnis_> Might be better to leave the deadline week up to the teams, then do our auto-proposed releases later in the week and follow through the next week like currently proposed.
16:46:08 <smcginnis_> Well, we say propose on Monday. I don't think we've ever done it before Wednesday.
16:46:14 <ttx> hah! ok
16:46:18 <smcginnis_> So maybe we just need to get better about that.
16:46:45 <smcginnis_> Tooling will definitely help once we get that in place.
16:46:46 <ttx> sure. I was thinking we seem to be able to approve non-feedback ones on Friday amd process exceptions early the week after
16:46:55 <smcginnis_> Still a bit of a manual process in parts
16:47:17 <ttx> So we have a couple of -1s
16:47:42 <ttx> a couple of shy +1s which I did not feel comfortable single-approving just yet
16:47:53 <ttx> and a bunch of non-feedback
16:47:59 <smcginnis_> According to what we have written, we should have them all processed by tomorrow if no negative feedback.
16:48:11 <ttx> yes. Who will be around to do that?
16:48:31 <diablo_rojo_phon> ..I will if we are okay with me doing that.
16:48:46 <diablo_rojo_phon> I haven't +W anything yet I don't think.
16:48:57 <smcginnis_> Sounds good. I should be around if we need any triaging of issues.
16:49:06 <diablo_rojo_phon> Kk
16:49:17 <smcginnis_> Just check comments on any of them to make sure there are no questions or issues raised without leaving a -1.
16:49:23 <ttx> just a note... I feel like we did not ping people enough on those
16:49:27 <smcginnis_> Those we can wait on and make sure the teams are actually ready.
16:49:30 <ttx> a bunch of them have no cc or anything
16:49:33 <diablo_rojo_phon> Tomorrow I'll go though and +w anything without questions/-1s
16:49:49 <smcginnis_> ttx: I thought all of them had PTLs and liaison added.
16:49:54 <smcginnis_> Were there some that I missed?
16:49:58 <ttx> https://review.opendev.org/#/c/698498/
16:50:20 <smcginnis_> Apparently I did indeed miss some.
16:50:28 <ttx> https://review.opendev.org/#/c/698497/
16:50:37 <ttx> https://review.opendev.org/#/c/698501/
16:50:48 <ttx> https://review.opendev.org/#/c/698500/
16:51:16 <ttx> So we should add a CC today to give them a chance before approving tomorrow
16:51:46 <smcginnis_> Definitely.
16:52:03 <ttx> even consider waiting until Monday for those, I don;t know
16:52:59 <smcginnis_> diablo_rojo_phon: Can you take note of those and wait if there is no response?
16:53:21 <diablo_rojo_phon> Yeah definitely.
16:53:42 <smcginnis_> OK, I think we're good there then.
16:53:56 <smcginnis_> I've added everyone to the reviews.
16:54:09 <diablo_rojo_phon> Cool. Was just about to ask if I should do that.
16:54:15 <smcginnis_> So hopefully we do get feedback by tomorrow and it's a non-issue.
16:54:30 <smcginnis_> OK, I should probably get out of here. Anything else for today?
16:54:37 <fungi> just a heads-up, i'm likely to be pretty much entirely unreachable between the 18th and 30th, so reach out to others on the infra team if you need something in that timeframe (hopefully you're all enjoying some much-deserved rest around then though)
16:54:48 <smcginnis_> OK, thanks fungi.
16:55:01 <diablo_rojo_phon> Enjoy fungi!
16:55:06 <fungi> thanks!
16:55:13 <smcginnis_> Hoping it is quiet around here the next few weeks.
16:55:29 <fungi> internet is tough to come by on the high seas, otherwise i'd try to check in periodically
16:55:36 <smcginnis_> OK, I gotta run. I'll be back around soon.
16:55:41 <fungi> thanks smcginnis_!
16:55:42 <smcginnis_> ooh, a cruise?
16:55:50 <smcginnis_> #endmeeting