15:00:39 <smcginnis> #startmeeting releaseteam
15:00:40 <openstack> Meeting started Fri Aug  3 15:00:39 2018 UTC and is due to finish in 60 minutes.  The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:43 <openstack> The meeting name has been set to 'releaseteam'
15:00:48 * fungi was just about to ask
15:00:49 <dhellmann> o/
15:01:05 <ttx> o/
15:01:25 <smcginnis> Word on the street is ping lists look like spam and you get kicked, so I'm not going to do that.
15:01:32 <fungi> smart man
15:01:40 <dhellmann> oh, that's new
15:01:44 <smcginnis> #link https://etherpad.openstack.org/p/rocky-relmgt-tracking Agenda, currently line 427
15:02:27 <smcginnis> Looks like all the usual suspects are here, so that's good.
15:02:33 <smcginnis> #topic Release status update
15:02:45 <fungi> during freenode spam floods their spam detecting bot we invite into a lot of official channels gets cranky when it sees someone mention lots of other nicks from the same channel
15:02:52 <ttx> I did dump a bit there
15:02:57 <smcginnis> ttx: Did you just run that missing client release list today?
15:03:06 <ttx> yes this morning
15:03:14 <ttx> So Libraries are all set
15:03:19 <smcginnis> Great, then that should be up to date.
15:03:32 <ttx> Client libraries, a bunch are missing, the others are waiting for a stable branch
15:03:55 <ttx> I suspect we have a decision to take there
15:04:21 <smcginnis> I have a process.rst change queued to tweak how we approach those stable branches based on experiences this week and a quick conversation with dhellmann.
15:04:29 <smcginnis> So look for that and see if it makes sense to you.
15:04:58 <smcginnis> dhellmann: Are you looking at outstanding commits on those?
15:05:06 <dhellmann> smcginnis : yeah
15:05:16 <dhellmann> let me see if I can pull that into a single report
15:05:21 <smcginnis> "rewrite of the client" sounds kind of significant.
15:05:29 <ttx> should we trigger releases for those ?
15:05:39 <smcginnis> I think so.
15:05:51 <smcginnis> We can send out a reminder that that is our policy.
15:05:59 <ttx> and do it Monday
15:06:02 <dhellmann> yeah, they rewrote that whole client to use cliff
15:06:08 <smcginnis> Or send out a notification that said policy has been enforced and do it now.
15:06:16 <ttx> Fridays are bad
15:06:25 <smcginnis> Yeah, that's my thinking too.
15:06:25 <dhellmann> changes: http://paste.openstack.org/show/727235/
15:06:31 <smcginnis> dhellmann: Thanks
15:06:34 <ttx> But I'll be off and oblivious of IRC so your call :)
15:06:51 <smcginnis> :)
15:07:17 <smcginnis> I'll send something to the ML after the meeting listing these and explaining the plan. Then Monday we can enforce it.
15:07:44 <armstrong> @ttx: why are Fridays bad?
15:07:57 <ttx> Skipping the Client libraries missing stable branch since you seem to have it under control
15:08:12 <ttx> armstrong: potentially gets in the way of enjoying your week end
15:08:27 <ttx> Services missing milestone 3...
15:08:40 <armstrong> @ttx: haha ok got it now
15:08:40 <smcginnis> Cinder missed?
15:08:57 <ttx> looks like it
15:09:12 <smcginnis> Dang. I'll have to berate jungleboyj later.
15:09:17 <dhellmann> I would be afraid to guess at a version number for cloudkittyclient
15:09:27 <jungleboyj> What did I do wrong?
15:09:37 <smcginnis> Missed milestone-3 release for cinder.
15:09:57 <ttx> Do we need to force those ?
15:10:01 <jungleboyj> Oy.  Totally forgot that with everything else going on.  I am sorry.
15:10:02 <smcginnis> dhellmann: I think it would have to be a major version bump based on the changes there.
15:10:05 <ttx> (rocky-3)
15:10:11 <jungleboyj> smcginnis:  Should I go do that now?
15:10:14 <dhellmann> let's drop cinder from governance ;-)
15:10:15 <smcginnis> jungleboyj: We got the first two, so not the end of the world.
15:10:18 <smcginnis> Hehe
15:10:24 <ttx> dhellmann: no they only missed one
15:10:29 <dhellmann> drat
15:10:31 * jungleboyj glares at dhellmann
15:10:36 <ttx> BUT now that you mention it
15:10:39 * dhellmann smiles sweetly at jungleboyj
15:10:46 <ttx> freezer and searchlight did miss 2
15:10:47 <jungleboyj> Hey now ttx
15:11:00 <dhellmann> freezer also had no ptl candidate
15:11:02 <armstrong> are projects currently following the cycle-with-milestones?
15:11:05 <ttx> so we kind of need to decide what to do there
15:11:08 <smcginnis> Yeah, we have two that do not meet our requirements to be included.
15:11:10 <dhellmann> and searchlight, I think?
15:11:17 <smcginnis> Not too surprisingly, the two that also do not have a PTL.
15:11:25 <ttx> dhellmann: freezer also had no team meeting over the past year
15:11:36 <ttx> I sent an email this morning to get a bit of status
15:11:38 <smcginnis> armstrong: Most of the service projects are.
15:11:52 <armstrong> ok
15:12:25 <smcginnis> My post the ML can include both the missing client libs and the missing services.
15:12:26 <ttx> dhellmann: as top contibrutor you know more about freezer than all of us combined right
15:12:30 <smcginnis> :D
15:12:47 <dhellmann> if you put me in charge I think you can guess what I'd do with it
15:12:50 <smcginnis> ttx: I think we have a default PTL to appoint for that, right? ;)
15:13:08 <dhellmann> "I will not seek, and will not accept, my party's nomination..."
15:13:45 <smcginnis> So based on PTL and missing releases, I think we need a larger conversation about those two with the TC.
15:13:57 <dhellmann> *will*shall
15:14:01 * dhellmann tries to get his quotes right
15:14:09 <smcginnis> And based on our policy, I think we need to exclude them from part of the coordinated release.
15:14:09 <dhellmann> smcginnis : I agree
15:14:12 <jungleboyj> Seriously though, sorry for missing that.  Thanks for undestanding.
15:14:16 <dhellmann> smcginnis : I also agree on that
15:14:26 <ttx> I understand that some components may be feature complete, but I think having one person signed up to ensure minimal responses and releases is not too high of a bar
15:14:33 <dhellmann> jungleboyj : we'll find a way for you to make it up ;-)
15:14:45 <jungleboyj> dhellmann:  Sounds like a plan.
15:14:47 <dhellmann> ttx: I think that is the lowest possible bar
15:15:05 <ttx> and dropping those off "
15:15:08 <smcginnis> So I will call out the missing client releases, the missing milestone-3 service projects, and that the two (searchlight and freezer) will not be considered official rocky deliverables.
15:15:09 <ttx> the release"
15:15:33 <ttx> or the official set of projects is not killing them, it's just reflective of what we are ready to associate the openstack name with
15:15:50 <dhellmann> smcginnis : yes. An email to the -dev list would be a good way to record that formally, and then we can take the TC action of deciding what to do next.
15:15:58 <smcginnis> ++
15:16:27 <dhellmann> does the release team want to make a recommendation there? or do we just want to highlight the situation?
15:16:28 <ttx> basically asd a community we need to decide whether openstack rocky should include Freezer and Searchlight
15:16:42 <ttx> and frankly, if nobody cares enough about those to sign up to request releases...
15:16:52 <smcginnis> FOr the cycle-w-i unreleased ones, I will just mention that without calling out all of them. Since it will already be a big list of projects.
15:17:09 <ttx> they could continue their lives as an unofficial thing
15:17:10 <fungi> i don't think the release team needs to make any recommendation. simply following the outlined policy and then making the tc aware of what has transpired is plenty
15:17:49 <smcginnis> ttx: I don't know, we have a written policy in place about that. I'm always flexible, but seems kind off wrong to not meet criteria but then have a community decision to still do it anyway.
15:17:49 <fungi> pretty sure the tc consensus will be ~ the same as what the release team would have recommended, but that avoids making the release team out to be the "bad guys"
15:18:01 <ttx> I'm all for cutting some slack to small teams, but at some point keeping some teams alive is just perpetuating useless pain
15:18:02 * dhellmann puts away his black hat
15:18:27 * fungi fears a black hat
15:18:48 <smcginnis> ttx: Are you saying whether they get listed as part of the official rocky deliverables, or whether they continue on as official OpenStack projects?
15:18:49 <ttx> smcginnis: agreed
15:19:13 <dhellmann> smcginnis : for the release team the former; for the tc the latter
15:19:19 <fungi> the first is the purview of the release team, the second of the tc
15:19:38 <ttx> smcginnis: as release team, we have the policy and apply it to define what is included in release. But as TC we should decide whether the project team still belongs. And missing release is a pretty significant miss
15:20:12 <smcginnis> OK good, that's my sentiment as well.
15:20:39 <ttx> the TC /could/ decide to keep them anyway
15:20:46 <ttx> althoug that would be a bit weird
15:20:48 <smcginnis> I just misinterpreted the earlier statement as leaving it up to the community whether to include them in rocky.
15:20:55 <smcginnis> Agreed
15:21:03 <dhellmann> if they were still active in the community (had PTLs) I could consider keeping them as "independent" projects, but that doesn't feel like the case here. but we can discuss that within the tc.
15:21:11 <ttx> since releasing is one of the requirements to be official
15:21:21 <ttx> ack
15:21:44 <ttx> dhellmann: we have a policy that openstack "main" components have to follow a cycle-based model
15:22:00 <dhellmann> true
15:22:03 <ttx> so that "openstack" can be released on a cadence
15:22:13 <ttx> we cut some slack to peripheral deliverables
15:22:29 <ttx> but those are really  not part of the "openstack" release
15:22:40 <smcginnis> Is that a clear delineation in your map?
15:22:45 <ttx> yes
15:22:50 <smcginnis> Perfect
15:22:52 <ttx> and part of the release model doc
15:23:22 <ttx> basically everything in the "openstack" bucket on the map is released in a cycle-based fashion
15:23:52 <ttx> it is "the openstack release" which we say is released every 6 months
15:24:06 <ttx> anyway, that was a diversion
15:24:20 <ttx> we have a couple other components missing milestone3
15:24:25 <dhellmann> so the next step there is for smcginnis to send that email to the -dev list?
15:24:32 <ttx> mostly confirming the other list
15:24:51 <smcginnis> dhellmann: I believe so.
15:24:56 <dhellmann> ok, noted
15:25:02 <dhellmann> and for the others, do we want to force tags?
15:25:07 * dhellmann goes to find that policy again
15:25:18 <smcginnis> I think we said we would do that at RC time?
15:25:19 <ttx> smcginnis: maybe no point in forcing a python-searchlightclient release if we do not include searchlight
15:25:37 <smcginnis> Right, we can probably skip that one.
15:25:43 <dhellmann> "The release team will remind projects that miss the first milestone, and create tags on any later milestones for the project team by tagging HEAD at the time of the deadline."
15:25:48 <smcginnis> Unless we want to have one final release to get what is out there.
15:25:49 <dhellmann> form https://releases.openstack.org/reference/release_models.html#cycle-with-milestones
15:26:06 <ttx> The policy is weird in that we save intermediary-released things that did not do a single release over cycle but drop things that are on a milestone-base and did release one
15:26:34 <dhellmann> perhaps we should address that discrepancy for stein
15:26:39 <ttx> if freezer and searchlight were cycle-with-intermediary we would have saved them
15:26:47 <smcginnis> Yeah, that doesn't really feel right to me, but I guess at least we have the expectations documented.
15:26:51 <dhellmann> in the mean time, it sounds like we said we *would* for tag things
15:26:57 <dhellmann> *force
15:27:12 <dhellmann> I can prepare that patch if you want
15:27:13 <smcginnis> The wording does imply that.
15:27:21 <ttx> I would still raise those who haven't done a single release and that we force... and ask the TC to review them
15:27:36 <ttx> potentially dropping them too
15:28:05 <ttx> Some are active and just planning to do a release for all the cycle
15:28:09 <fungi> that makes a lot of sense to me
15:28:12 <ttx> but some others might just be dead
15:28:19 <dhellmann> was jungleboyj going to do cinder, or should I?
15:28:22 <smcginnis> We do have the force flag in the deliverable now, so at least it will be easy to pull out a list of "concerns".
15:28:25 <ttx> we'll see which ones ask for a release next week
15:28:43 <fungi> if the release team regularly has to force releases of deliverables because the team responsible isn't requesting them on schedule, that's a problem regardless of release model
15:28:44 <jungleboyj> dhellmann:  Still cut the milestone?
15:28:44 <smcginnis> dhellmann: I guess if we are going to go ahead and tag those, we might as well do them in one batch.
15:28:49 <ttx> cinder is fine, it missed only one
15:29:06 <smcginnis> fungi: ++
15:29:08 <dhellmann> ttx: the policy we documented says we would do all of the others
15:29:15 <dhellmann> I will include cinder in this patch I'm working on
15:29:27 <ttx> ah ok
15:29:29 <jungleboyj> dhellmann:  Thank you.
15:29:42 <smcginnis> I suppose at least then we reduce the chance of surprises next week at RC time.
15:29:51 <dhellmann> I won't include freezer or searchlight, since we're going to drop those
15:29:54 <dhellmann> I'll make that a separate patch
15:30:03 <ttx> smcginnis: basically, I would strongly recommend that those intermediary-released not-yet released actually DO a release asap
15:30:03 <smcginnis> Works for me.
15:30:24 <ttx> those we have to force will get questioned
15:30:33 <smcginnis> ttx: I will note that in my post.
15:31:07 <dhellmann> https://review.openstack.org/588604 add rocky-3 milestone tags for projects that missed
15:32:53 <smcginnis> Thanks dhellmann
15:33:08 <smcginnis> Looking ahead at the RC1 tasks, we are otherwise in good shape I think.
15:33:21 <ttx> there are a bunch of tempest plugins that will likely just need a forced release
15:34:03 <smcginnis> I need to go back in re-read that long thread. Was the conclusion that those tempest plugins should be published to pypi??
15:34:16 <smcginnis> I have not seen much activity with getting that set up.
15:34:39 <ttx> smcginnis: for intermediary-released stuff that did not do a single release, it's almost as if we should ask the TC wonder we should force releases or drop
15:34:48 <ttx> s/wonder/whether
15:34:57 <dhellmann> should I remove all of the freezer and searchlight deliverables, or just the service?
15:35:11 <ttx> I'd say all
15:35:11 <smcginnis> That would make sense. It's kind of like the cycle-with-milestones missing the deadlines.
15:35:11 <dhellmann> it feels weird to include the clients and not the services
15:35:23 <smcginnis> Yeah, drop the clients I think.
15:35:34 <dhellmann> https://review.openstack.org/588605 remove freezer and searchlight from rocky series
15:35:37 <ttx> and -uis
15:37:11 <smcginnis> OK, so with my calling out cycle-with-intermediary release recommendation, I will also state that projects that do not do one by RC will be dropped from rocky.
15:37:18 <smcginnis> ttx: Sound right?
15:37:20 <dhellmann> ++
15:37:42 <dhellmann> I was distracted there for a second while I wrote those patches; should I tag designate-dashboard, too?
15:38:04 <smcginnis> Hmm, probably.
15:38:05 <ttx> I'd say "could be dropped" since that's not in our policy yet (we said we would force release)
15:38:15 <smcginnis> ttx: OK
15:38:26 <ttx> basically that will be a TC decision
15:38:44 <ttx> and one where the health info will prove useful
15:38:56 <dhellmann> ok, I updated https://review.openstack.org/588604 to include designate-dashboard
15:39:00 <fungi> i feel like it's the release team's choice whether they force tag a deliverable or not. i wouldn't wait for the tc to tell you it's unnecessary unless you really just want to save yourself the trouble of tagging something which ends up not included in the coordinated release deliverable set
15:39:06 <smcginnis> I think we should amend the release documentation so that it is a release team decision going forward, but since we do not state that now, probably best to make it a TC decision.
15:39:25 <ttx> fungi: I'm happy with the TC formally saying that
15:39:44 <ttx> but I don;t think it's been stating that as clearly in the past
15:39:46 <dhellmann> do we need a resolution?
15:40:01 <smcginnis> fungi: It does seem like it should be this group's choice, but I think the gotcha is we had not previously stated that.
15:40:28 <ttx> I would keep the TC in the loop the first time, then document as policy
15:40:40 <fungi> does the tc already have policy around this which needs alternig? if not, seems like it's well within the release team's jurisdiction (though i do support the tc adding policy or a resolution to back up the release team's decision in such matters)
15:40:43 <ttx> (same as the two milestones missed, out policy
15:41:32 <dhellmann> ok, ttx's approach works for me
15:41:50 <smcginnis> Maybe a second ML post with the [TC] tag explaining the situation, then we can discuss in the -tc channel.
15:42:01 <dhellmann> or even on the mailing list :-)
15:42:03 <dhellmann> but yeah
15:42:09 <fungi> just worried that the tc explicitly delegating this choice to the release team sets a precedent that similar sorts of choices have to be explicitly delegated to teams in the future
15:42:27 <ttx> fungi: it's more of a timing issue
15:42:28 <dhellmann> that's reasonable
15:42:46 <ttx> if we had set that policy clearly months ago, it would feel less like sudden powergrab
15:43:05 <ttx> so keeping the TC in the loop of the first time sounds like a reasonable approach
15:43:05 <fungi> 100% in favor of keeping the tc in the loop and asking them for input. as to whether we need to delegate it at the tc level, i suppose that's a topic for another venue
15:43:19 <dhellmann> I suspect that the teams affected are going to be surprised no matter how much notice they have.
15:43:23 <ttx> ah, no... was not askign for a reolsution ofr anything
15:43:31 <ttx> more for forgiveness
15:43:49 <fungi> makes sense
15:44:03 <ttx> And I would definitely want the input of whoever did the health check for that team
15:44:34 <ttx> since the situation is often unique
15:45:06 <smcginnis> Going forward I think we can say the rule is the rule, but this is a little different.
15:46:38 <fungi> seems fine to be careful this round as it's the first time it's being potentially enforced and there could be backlash/confusion
15:46:43 <ttx> next topic?
15:46:45 <smcginnis> OK, I think we're probably good with that for now. I want to make sure we have some time for a few other things.
15:46:51 <smcginnis> #topic ACLs
15:47:03 <ttx> I'll process those next week
15:47:06 <smcginnis> I wanted to at least discuss the ajutant ones.
15:47:29 <ttx> I'll keep them unifixed for them to fix before next milestone
15:47:36 <ttx> since they are not in Rocky
15:47:40 <smcginnis> They just became official, so wondering if we need to set a policy that new projects that are too late for the current cycle don't get their ACLs changed until the next cycle opens up.
15:47:46 <smcginnis> ttx: ++
15:47:47 <ttx> yap
15:48:24 <smcginnis> I think those are the only ones out of the list that had any kind of issue. The rest seem pretty straight forward.
15:49:09 <smcginnis> Anything else on ACLs?
15:49:13 <ttx> nope
15:49:22 <smcginnis> #topic Open Discussion
15:49:29 <smcginnis> Oh, PTG.
15:49:34 <ttx> I had a topic
15:49:38 <ttx> Review next week work
15:49:50 <smcginnis> I was going to say, not sure if we need a planning etherpad. We can just find some time at the PTG like we've done before.
15:50:03 <ttx> ack
15:50:09 <smcginnis> #topic Review next week work
15:50:20 <ttx> #link https://releases.openstack.org/reference/process.html#rc1
15:50:30 * jungleboyj feels like he should pay attention to this so I know what to do.  :-)
15:51:01 <ttx> It's relatively easy until you hit the end
15:51:23 <ttx> but then we usually hit 7 so late in the week it's called the week after
15:51:42 <ttx> or even 2
15:51:47 <armstrong> scmginnis the PTG is in Denver right?
15:51:55 <ttx> "minimum set of projects used by devstack have been branched"
15:52:06 <smcginnis> I think we've also had late critical things that caused requirements thaw to be late.
15:52:10 <smcginnis> armstrong: Correct
15:52:15 <ttx> do we ahve a list we can track ?
15:52:19 <dhellmann> ttx: I think we just usually wait for everything there
15:52:28 <dhellmann> they all tend to come in around the same time anyway
15:52:44 <ttx> yeah
15:52:48 <dhellmann> but I think the intent of that phrasing was the starter-kit projects
15:53:02 <dhellmann> so we would wait for glance but not freezer
15:53:30 <ttx> since we are not really ahead, i expect next week will be all about chasing those RC1s, releases and branches
15:53:37 <dhellmann> we should coordinate with gmann on those branches
15:54:21 <smcginnis> I think I proposed them last cycle, but would be good to at least give gmann a heads up they are coming.
15:54:22 <dhellmann> ttx: I expect so, yeah
15:54:24 <ttx> and we'll likely hit 2-9 the week after
15:55:25 <ttx> Do we want to use some kind of tracking to see progress ?
15:55:55 <ttx> we traditionally used etherpad dump in the tracking doc
15:55:58 <dhellmann> we've had quite a few changes to the validation code this cycle; it wouldn't hurt to have some WIP patches for some of these branches to make sure we didn't break the validation for branching without tags
15:56:12 <dhellmann> ttx: yeah, either the etherpad like we've done before or a story with tasks would be good
15:56:13 <ttx> and a spreadsheet at one point
15:56:41 <smcginnis> Let's start with the etherpad and see if we need more.
15:56:42 <ttx> the per-week format of https://etherpad.openstack.org/p/rocky-relmgt-tracking makes it a bit painful to use as release tracker
15:56:55 <smcginnis> Maybe an ethercalc then?
15:56:57 <ttx> maybe track at the bottom ?
15:56:59 <dhellmann> ttx: the spreadsheet was more useful before we could use list-deliverables to see what hadn't been done
15:57:15 <ttx> true
15:57:30 <smcginnis> At the bottom of the tracking etherpad sounds good to me.
15:57:51 <ttx> it's just me and my visual completion hints... I like to cross lines and add checkmarks
15:58:02 <ttx> makes it feel like progress
15:58:06 <smcginnis> :)
15:58:08 <dhellmann> sure, having a list like that works for me
15:58:14 <ttx> but a watch on list-deliverables probably works too
15:58:21 <dhellmann> it's a bit more to do manually, but *shrug*
15:59:02 <dhellmann> I think last time we waited to create a short list of things to watch when we were starting to see what might come in late
15:59:06 <dhellmann> or be blocked on bugs
16:00:14 <ttx> ok I added a header for a Release candidate 1 / proposed intermediary release / branching tracker  at the bottom of the doc
16:01:01 <ttx> i suspect there are a bunch of OLD intermedary releases that need a refresh before branching too
16:01:13 * ttx looks that
16:01:51 <ttx> like swift 2.18.0 is two-months old and might want a refresh
16:02:18 <smcginnis> OK, we're actually over time. Anything else we should make sure to cover?
16:02:39 <ttx> no
16:02:42 <dhellmann> not from me
16:02:51 <ttx> I need to run and immerse myself in cold water
16:03:03 <ttx> it's pretty hot here
16:03:05 <smcginnis> OK, thanks everyone.
16:03:11 <smcginnis> ttx: So I hear. Stay cool.
16:03:15 <armstrong> thanks
16:03:18 <smcginnis> #endmeeting