15:01:43 <smcginnis> #startmeeting releaseteam
15:01:44 <openstack> Meeting started Fri Oct 26 15:01:43 2018 UTC and is due to finish in 60 minutes.  The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:47 <openstack> The meeting name has been set to 'releaseteam'
15:01:49 <fungi> howdy!
15:01:57 <smcginnis> Morning fungi
15:02:21 <diablo_rojo> Hello :)
15:02:26 <smcginnis> #link https://etherpad.openstack.org/p/stein-relmgt-tracking Agenda - R-24, ~line 113
15:02:34 <smcginnis> Hey diablo_rojo, long time no see.
15:02:38 <ttx> o/
15:03:00 <armstrong> Hello
15:03:21 <smcginnis> OK, that's probably everyone for today.
15:03:27 <smcginnis> #topic
15:03:28 <smcginnis> Mark Ocata as extended maintenance
15:03:31 <smcginnis> Grr
15:03:39 <smcginnis> #topic Mark Ocata as extended maintenance
15:03:46 <smcginnis> #link https://review.openstack.org/#/c/598164/
15:03:55 <smcginnis> ttx: I think you added this?
15:04:04 <ttx> yes for some reason that one does not appear on the dashboard so we did not approve it
15:04:15 <ttx> any reason we should not approve it?
15:04:32 <smcginnis> I don't think so. THere was some question of teams making that extended-maintenance decision,
15:04:48 <smcginnis> But as far as the official release page, I think it should reflect that that release is now in e-m mode.
15:05:06 <ttx> ok approving now
15:05:19 <smcginnis> Yay, one more out my queue.
15:05:43 <fungi> speaking of em, there's an interesting thread going on the debian-devel ml at the moment about user confusion over their choice to call "lts" what we decided against referring to as "lts" (for the very same reasons)
15:05:57 <smcginnis> Anything more we need to do as the release team for that? Or leave it to tonyb for any follow up.
15:06:07 <ttx> nothing
15:06:10 <smcginnis> fungi: Oh, interesting. They're coming to the same conclusions on wording?
15:06:35 <fungi> yeah, specifically that "lts" in the linux kernel and ubuntu communities means specific releases that get longer official maintenance
15:07:01 <fungi> whereas debian lts is that after a release reaches what would be eol a separate team takes over care and feeding of it for as long as they can muster the resources to do so
15:07:50 <smcginnis> I wasn't initially a fan of the em phrasing, but I've grown to like it now and think it better descibes what to expect from the community.
15:07:52 <fungi> so users are installing debian "lts" releases thinking that means longer support, when it actually means they're just installing outdated versions
15:08:07 <smcginnis> Makes sense.
15:08:15 <smcginnis> Anyway...
15:08:20 <smcginnis> #topic stein-1 requests
15:08:30 <smcginnis> ttx: Yours again...
15:08:33 <fungi> so if we'd started calling ocata "lts" now, users might be incentivised to choose ocata over, say, rocky
15:08:43 <smcginnis> Let's hope not.
15:08:57 <ttx> yes, wanted to discuss how to handle stein-1 requests... there are basically two types
15:09:13 <ttx> ones we triggered (the library refreshes posted by Sean)
15:09:25 <ttx> ones that were proposed (milestone releases)
15:09:41 <ttx> For the former we said we'd finally approve them on the 1st
15:10:09 <ttx> For the latter, there are cases where people submit them because they assume they have to
15:10:11 <smcginnis> For the ones I've seen where folks have requested b1 releases, I've just asked on the review if they actually need that and make sure they've seen the ML thread.
15:10:21 <ttx> right
15:10:21 <smcginnis> Not too surprisingly, a lot have not.
15:10:42 <smcginnis> e0ne had a good reason with horizon, and there's probably others that may still want to do a milestone release.
15:11:01 <smcginnis> But I just want to make sure they are doing it on purpose and not because they think they have to.
15:11:10 <ttx> ok, so the process for those is to ask for confirmation, and if confirmed just approve them without waiting for Nov 1
15:11:16 * e0ne is reading meeting log...
15:11:25 <smcginnis> e0ne: Sorry, not important.
15:11:32 <smcginnis> Just saying how awesome you are. :)
15:11:39 <smcginnis> ttx: Yeah, I think that makes sense.
15:12:22 <e0ne> smcginnis: :)
15:12:23 <ttx> ok, are you going to do that for the recently-posted ones ?
15:12:35 <smcginnis> Did I miss some new one?
15:12:38 <smcginnis> *ones
15:12:42 <ttx> https://review.openstack.org/#/c/613444/
15:13:12 <ttx> oh that's the only one missing
15:13:20 <ttx> i can copypaste your blurb
15:13:28 <e0ne> smcginnis, ttx: I had to cut stein-1 mostly because we haven't something like horizon-lib and other projects (plugins) use horizon as a library
15:13:32 <smcginnis> Hmm, they are cycle-with-rc, but he is proposing a full version number.
15:13:38 <diablo_rojo> to clairfy for my new to releases brain- by confirmation you mean +1ed by a release liaison or PTL? Or that they intended to do a release for some reason despite not having to?
15:13:55 <smcginnis> e0ne: Yeah, that made sense. We might have some similar cases with neutron I think.
15:14:10 <ttx> smcginnis: uh yes
15:14:12 <e0ne> AFAIR, we've got neutron-lib
15:14:36 <smcginnis> diablo_rojo: Yeah, for the ones where they are proposing a x.x.x.0b1, we just want to check with them that they are creating a milestone "beta" release on purpose.
15:14:39 <ttx> smcginnis: weird that it passes tests (final without rc)
15:14:51 <smcginnis> That there's actually a need for some downstream consumer or something for doing it.
15:14:58 <smcginnis> Otherwise there's not really a need.
15:15:02 * ttx digs deeper
15:15:07 <diablo_rojo> smcginnis, got it
15:15:21 <smcginnis> ttx: I'm guessing we're missing some previous validation logic for -rc that we did for -milestones.
15:15:38 <smcginnis> Or maybe we just never did and it was up to reviews to catch that.
15:16:47 <smcginnis> amotoki: Did you need milestone-1 deliverables for all of those? And if so, did you mean to have b1 release versioning?
15:17:14 <smcginnis> #link http://lists.openstack.org/pipermail/openstack-dev/2018-September/135088.html
15:17:31 <smcginnis> So we have another breadcrumb somewhere to increase odds more folks have seen that. ^
15:18:33 <smcginnis> Anyway, we can follow up later.
15:18:36 <ttx> ok
15:18:41 <smcginnis> ttx: Anything more on stein-1 we should discuss?
15:18:47 <ttx> no
15:18:59 <smcginnis> #topic cycle-with-intermediary changes
15:19:23 <smcginnis> So we kind of just discussed this (ttx's first type) but wanted to still point out there are patches out there.
15:19:50 <smcginnis> I skipped libs that only had <5 commits or only had zuul related commits.
15:20:17 <smcginnis> I need to cleanup/rewrite my script for doing that and push that up for future use.
15:20:26 <smcginnis> But it's way too hacky in its current state.
15:21:09 <smcginnis> So far, most feedback has been positive and I got a lot of PTL/liaison +1s.
15:21:16 <ttx> (no-rc is actually considered a valid case)
15:21:28 <smcginnis> ttx: Odd
15:21:47 <smcginnis> I suppose we didn't want to paint ourselves into a corner for some odd case.
15:22:19 <ttx> (only tested as part of the pre-release progression checks)
15:22:23 <smcginnis> In the commit messages for the lib releases I said we would approve them by next Thursday unless we hear yay or nay otherwise.
15:22:35 <ttx> ++
15:22:54 <smcginnis> A few commit hash updates, but so far it's been smoother than I had expected.
15:23:12 <smcginnis> #topic sem-ver patches
15:23:16 <smcginnis> #link https://review.openstack.org/#/q/topic:sem-ver
15:23:30 <smcginnis> Background on this for those that hadn't seen -
15:23:58 <smcginnis> With not requiring milestone releases, downstream distro packaging that works on upgrades had an issue.
15:24:24 <smcginnis> Previously they could wait until milestone 1, but with getting rid of that, waiting until RC was too long.
15:24:43 <smcginnis> The issue being the package versions need to be incremented.
15:25:00 <smcginnis> Which does happen with a beta 1 release/
15:25:31 <smcginnis> So to get the version incremented without doing a release, we can use a PBR feature where it will see the tag in the commit and calculate a higher version.
15:25:52 <smcginnis> That will now be automated for cycle-with-rc deliverables when stable branches are created.
15:26:19 <smcginnis> We normally would generate patches to update the release notes, .gitreview, etc. This will be included now.
15:26:59 <diablo_rojo> Handy
15:27:00 <smcginnis> So this one time for stein, since we didn't have that automated when the stable branch for rocky was created, we needed to manually propose these patches to get them bumped.
15:27:04 <fungi> i'm still mildly concerned people will see those in the commit history and think it's a safe feature to rely on more generally without realizing the down-sides
15:27:18 <smcginnis> Definitely a concern.
15:27:29 <smcginnis> I added a little note in the commit messages to hopefully help prevent that.
15:27:38 <fungi> also very easy for those to slip through review in projects when people aren't paying super close attention to commit message footers
15:28:21 <fungi> it's happened before anyway (though at least you can still push a conflicting tag and i _think_ pbr does the right thing afterward?)
15:28:22 <smcginnis> I wonder if we can have some kind of automated check across all python projects to flag those or something.
15:28:46 <smcginnis> Maybe we need to add a sem-unver to pbr. :)
15:29:25 <fungi> yeah, it's mostly that you end up with a non-increasing version break to fix it via tags
15:29:58 <fungi> which could get confusing, especially in continuous deployment scenarios
15:30:17 <fungi> where your deployment automation breaks because the version number is jumping backwards
15:30:49 <smcginnis> Hopefully this will never happen. The sem-ver approach was the least impacting option we came up with for handling this for distros.
15:31:56 <fungi> in the past we deemed it not a huge risk to just ignore the low version number problem after release because master branches generally accrue commits faster than stable branches and so will outpace them quickly enough that when someone switches from stable to master the "dev" version number increment is higher anyway
15:33:23 <fungi> oh, right, this is because we broke that assumption by no longer merging release tags back into master
15:33:38 <fungi> to work around shortcomings in reno's matching logic
15:34:09 <smcginnis> Red Hat at least seemed to need this to happen for their work.
15:34:27 <fungi> so, yeah, i guess that's inevitable that we need to work around it somehow unless reno can be fixed to not get confused when we merge release tags into the master branch
15:34:44 <smcginnis> We can discuss more next week when Doug is back.
15:34:57 <smcginnis> Since he has insight both on reno and on Red Hat's needs.
15:35:21 <smcginnis> #topic Governance / Releases mismatches review
15:35:24 <smcginnis> #link https://etherpad.openstack.org/p/UChiqxElUV
15:35:46 <smcginnis> #link https://review.openstack.org/#/c/613268/
15:35:58 <smcginnis> ttx: Want to take this?
15:36:28 <ttx> yes
15:37:24 <ttx> So... officially we are doing release management for everything official
15:37:40 <ttx> But we haven't really been checking that we actually did that
15:38:04 <ttx> There are exceptions, and it's been traditionally difficult for us to know which repos are exceptions
15:38:17 <ttx> I've been introducing a change to governance to track which repos are exceptions
15:38:34 <ttx> #link https://review.openstack.org/#/c/613268/
15:38:38 <ttx> BUT there is a gap
15:38:48 <ttx> things that are under governance but are not really standing exceptions
15:38:57 <ttx> and that we do not handle release for
15:39:09 <ttx> That is what is listed on https://etherpad.openstack.org/p/UChiqxElUV
15:39:35 <ttx> In a lot of cases it's just recent repos, for which we should probably have a skeleton deliverable file in openstack/releases
15:40:00 <ttx> In some other cases it's an abandoned repo, for which we might want to add another keyword ("abandoned"
15:40:12 <ttx> in order to track them as well
15:40:45 <ttx> In yet other cases it's just things that are cycle-independent and released EXTREMELY rarely
15:41:00 <ttx> as in were never released since we created the openstack/releases repo
15:41:16 <ttx> That still leaves corner cases, for which I could use help investigating
15:41:51 <ttx> Like openstackclient, sounds like something we should release, but we do not, and I'm sure there is a good explanation for it
15:41:55 <smcginnis> For the abandoned ones, it might make sense to just get those repos removed as "official". They can always be added back later if the team picks them up again.
15:42:29 <ttx> I bet we'll uncover dead things that need to be removed.
15:42:35 <smcginnis> Not sure, but I think there was a plan to migrate python-openstackclient to openstackclient?
15:42:41 <ttx> Like some of those xstatic repos were never tagged
15:42:42 <smcginnis> Maybe another "abandoned" case?
15:43:28 <ttx> I have a script to generate that list, it has exceptions (like all of Infra repos), but would like to get most of the list categorized otherwise
15:44:01 <ttx> I bet a lot of them are just release-management:none cases but that would be good to document them once and for all
15:44:19 <smcginnis> Agree completely.
15:44:46 <smcginnis> And having it in an easily consumable place like this makes a lot of sense to me. We can build scripting around it and validation checks.
15:44:48 <ttx> because I'm pretty sure I asked about heat-cfnclient before and got an answer and just forgot about it
15:45:04 <fungi> the infra repo exceptions at least should be able to go away once we separate those repos out with namespace reorg or whatever
15:45:22 <fungi> (as part of opendev migration)
15:45:38 <ttx> Also we might uncover real offenders (things that are official and yet not under openstack/releases) which we should definitely fix, if only so that those appear on releases.o.o
15:45:57 <ttx> fungi: yes that's why I wildcarded them out
15:46:00 <smcginnis> Tangential, but what ever happened to the namespace flattening talk? Are we just going to recategorize things more appropriately now?
15:46:59 <fungi> smcginnis: the spec is still out there, but we may want to reintroduce namespacing to separate repos for different communities under opendev now
15:47:18 <ttx> good question, it's been put in hold pattern while we do opendev
15:47:33 <fungi> unfortunately it would be yet another major project renaming for unofficial projects
15:47:37 <smcginnis> Yeah, I think things have evolved somewhat.
15:47:58 <fungi> but might actually eventually become that being in the "openstack" namespace really means what people thought it meant
15:48:32 <ttx> back on topic, I'd welcome help on that categorization etherpad, so if you end up talking to one of those PTLs, be sure to ask them about their repos if listed
15:48:35 <smcginnis> With random libs being pushed on the oslo team, it might make sense to have a neutral zone territory for some common libs and unofficial things.
15:48:39 <smcginnis> ttx: Sorry
15:49:02 <fungi> because to do things like handing over management of github org/replication and white-labeling services like the git server farm means our viable options are either run separate gerrits and find a way to move projects between them (really messy) or just make renames less painful
15:49:06 <smcginnis> ttx: Should we send that to the ML to try to get more input?
15:49:48 <ttx> smcginnis: it's tricky because those are all corner cases. I'd rather engage individually. It's not really that urgent
15:49:58 <smcginnis> True, good point.
15:51:02 <ttx> Also it's all exceptions to a TC rule (which is that the RelMgt team handles releases of official things), so it's good to document that on a file that is approved by TC members
15:51:42 <smcginnis> Very good point. And I think if any new exceptions are added, then it is appropriate for that to have to go through a TC vote to happen.
15:52:02 <smcginnis> We also need to clean up more project ACLs, but that will be a side effect output from this.
15:52:24 <ttx> yes, knowing where we are alloed to step in and where we should just let go will be very useful
15:52:42 <smcginnis> And cause less friction.
15:52:46 <smcginnis> Hopefully.
15:53:08 <ttx> I did add the etherpad review to next week's tasks
15:54:26 <smcginnis> OK, great.
15:54:30 <smcginnis> Anything else to discuss today?
15:54:51 <ttx> I'll cover the bulk of it, but if you talk to PTLs, just ask them about their repos in that file
15:55:04 <ttx> nothing else
15:55:18 <smcginnis> Sounds like a good plan to me.
15:55:40 <smcginnis> OK, most of the hour used. Let's wrap it up.
15:55:42 <smcginnis> Thanks everyone.
15:55:50 <diablo_rojo> Thanks smcginnis :)
15:55:51 <smcginnis> #endmeeting