15:00:32 <smcginnis> #startmeeting releaseteam
15:00:33 <openstack> Meeting started Fri Apr 27 15:00:32 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:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:36 <openstack> The meeting name has been set to 'releaseteam'
15:00:41 <dhellmann> o/
15:00:43 <smcginnis> Courtesy ping: dhellmann, dims, fungi, tonyb, lbragstad, ttx, armstrong, annabelleB
15:00:51 <fungi> howdy
15:00:51 <annabelleB> o/
15:01:06 <smcginnis> Wow, everyone is prompt today. :)
15:01:08 <jungleboyj> @!
15:01:08 <_pewp_> jungleboyj ( ・_・)ノ
15:01:29 * fungi blushes at being called "prompt"
15:01:53 <smcginnis> Hah!
15:02:04 <ttx> o/
15:02:11 <smcginnis> There he is. :)
15:02:16 <smcginnis> #agenda https://etherpad.openstack.org/p/rocky-relmgt-tracking
15:02:31 <smcginnis> Around line 138 it appears.
15:02:36 <ttx> As always, ttx gets distracted picking background photos for his next presentation
15:02:57 <smcginnis> It does take a lot of thought and searching!
15:02:59 <armstrong> Hello
15:03:12 <armstrong> I have been so busy with final exams
15:03:29 <ttx> I did add a bunch of items
15:03:32 <smcginnis> Good to see you armstrong
15:03:47 <smcginnis> ttx: Thanks. As usual, I went to add something and saw you already covered it all.
15:03:53 <ttx> armstrong: hi!
15:03:59 <smcginnis> #topic Rocky-1 postmortem
15:04:16 <ttx> smcginnis: the curse of living ahead of you on the globe
15:04:17 <smcginnis> Well, it went a heck of a lot better than queens-1, I'll say that.
15:04:27 <smcginnis> ttx, man of the future
15:05:02 <smcginnis> Has anyone run the report to see what we ended up missing for r-1?
15:05:02 <dhellmann> that explains the jumpsuit
15:05:13 <dhellmann> I just did, and only searchlight showed up
15:05:19 * smcginnis pictures ttx in a Devo costunme
15:05:20 <dhellmann> both of their deliverables
15:05:36 <smcginnis> dhellmann: I think we had them on the list last cycle, IIRC.
15:05:49 <dhellmann> yeah, was there a response to the email thread you started? I didn't see one...
15:05:53 <smcginnis> And in Denver (part I) I think we discussed how they were "stable".
15:06:02 <smcginnis> dhellmann: I did not see a response.
15:06:13 <dhellmann> perhaps we should move them over to independent if they don't release anything this cycle?
15:06:18 <smcginnis> Which makes me wonder if any of them are engaged.
15:06:26 <smcginnis> That makes sense.
15:06:40 <smcginnis> Maybe wait to Rocky-2 and if we don't see anything, move them over then?
15:06:51 <dhellmann> they have a few unreleased changes
15:07:27 <dhellmann> let me paste that report...
15:07:51 <dhellmann> http://paste.openstack.org/show/720022/
15:07:57 <dhellmann> not much
15:08:37 <smcginnis> Yeah, doesn't really look like anything functionally needed.
15:08:53 <smcginnis> Translations would be good, but not critical.
15:09:00 <ttx> I'm not sure we should move them to independent... in the hypothesis new things are written against it you'd still want that to be released in sync
15:09:13 <smcginnis> Maybe as part of moving to independent we can force a release just to have something there.
15:09:20 <ttx> Like if it's forever stable then yes (but nothing is)
15:09:42 <smcginnis> ttx: So keep cycle based knowing they may skip a cycle or two?
15:09:47 <smcginnis> Or just plan on forcing releases for them?
15:10:10 <ttx> Yeah.. if the only reason to movethen is so that we don't have to force a release every 6 months it sounds like a bad reason
15:10:19 <dhellmann> so change the release model?
15:10:19 <ttx> move them
15:10:52 <dhellmann> or maybe we need a new release model for "infrequent" releases or something
15:10:53 <dhellmann> some way to not have to remember this as a special case
15:11:07 <ttx> dhellmann: basically I wonder if moving then to independent will not make it MORE difficult for them to be picked up and adopted
15:11:07 <smcginnis> cycle-optional
15:11:07 <dhellmann> especially since I expect it to be come less of a special case over time
15:11:16 <smcginnis> dhellmann: Agree
15:11:18 <dhellmann> we have that task about figuring out what to do with oslo libraries in the same state
15:11:38 <ttx> so I think it's part of a wider discussion
15:11:52 <smcginnis> Forum or PTG topic maybe?
15:12:02 <ttx> about how we want to align releases with activity / consumption models
15:12:24 <ttx> well my session on maintenance / release cycles / consumption models could tackle that
15:12:40 <dhellmann> not that I object to including more people, but do we expect anyone else to have given this much thought?
15:13:02 <smcginnis> Maybe of interest to the wider TC.
15:13:03 <ttx> It's definitely about discussing tweaks to release cycles or models based on the evolution of openstack toward more mature pieces
15:13:21 <dhellmann> ok, I can see that
15:13:37 <smcginnis> ttx: That does seem like a good place to discuss it, if just to share our thoughts from the release management perspective.
15:14:00 <ttx> dhellmann: dhellmann I'm not saying we should NOT use independent for that case... I'm just saying we should not rush the decision and reframe it in a more general frame
15:14:07 <dhellmann> sure
15:14:40 <ttx> rather than narrow it to "what do we do with that particular project for Rocky
15:14:44 <ttx> "
15:14:47 <dhellmann> I think from a distro perspective, a component that isn't releasing every cycle isn't that much different than a component from outside of openstack
15:14:53 <smcginnis> Since I'm sure there will be more in this state than searchlight, probably worth stepping back and thinking of the policy as a whole.
15:14:57 <dhellmann> but I'm sure there are other perspectives to consider
15:15:17 <dhellmann> now that we don't sync dependency changes automatically, I expect quite a few of the oslo libraries to enter this state
15:15:23 <ttx> making it release-independent is half-kicking it out of the "product"
15:15:23 <smcginnis> It looks and smells independent to me, but willing to discuss it to see if there are other takes on it.
15:15:27 <dhellmann> I don't know about services
15:15:37 <ttx> Also I liked to have all the components in the "main" box in the map under the same release model
15:15:41 <dhellmann> cycle-infrequent may be a better way to frame it
15:15:54 <smcginnis> cycle-when-we-get-around-to-it
15:16:02 <dhellmann> cycle-as-needed?
15:16:09 <ttx> i.e. make then all part of "openstack-the-deliverable-released-every-6-month"
15:16:17 <smcginnis> Comes back around to sounding like "independent" :)
15:16:25 <dhellmann> it feels a bit odd to say that if there isn't actually a new release, though
15:16:42 <ttx> basically I'd rather support making it unofficial than making it independent
15:17:10 <dhellmann> I guess the question then is whether it's "done" or "unmaintained"
15:17:17 <ttx> (and have pieces of "openstack the IaaS framework" released on two difefrent models
15:17:21 <smcginnis> I see unofficial as dead or orphaned vs projects that are mostly "code complete"
15:17:27 <fungi> the infrequency of releasable changs to searchlight is probably only part of the picture in their particular case
15:17:40 <fungi> er, releasable changes
15:18:02 <ttx> I need 10 minutes to explain my thought on this
15:18:12 <ttx> we can do it now or at Forum or...
15:18:24 <smcginnis> Hmm, looks like they do have patches pending that aren't being reviewed: https://review.openstack.org/#/q/project:openstack/searchlight+status:open
15:18:33 <fungi> it's possible that there's really no further improvement needed/warranted, but it _can_ also of course be a sign that interest has waned and development thus stagnated
15:18:35 <smcginnis> Forum does seem like the right place.
15:19:17 <ttx> Basically, we release "OpenStack" (the framework of IaaS services) every 6 months.
15:19:35 <ttx> Searchlight is a component of that framework
15:19:58 <ttx> It's even a low-level service
15:20:09 <smcginnis> OK, let's table that for the forum. I think we could probably spend a good part of the hour talking, and I think face to face will make that easier.
15:20:16 <smcginnis> No immediate action is really needed at this point.
15:20:19 <ttx> providing search indexing capabilities to other components
15:20:23 <ttx> ack
15:20:33 <smcginnis> Anything else as far as Rocky-1?
15:20:55 <smcginnis> #topic Update on recent release failures
15:21:12 <smcginnis> We worked out the recent failures that I'm aware of.
15:21:15 <ttx> Have been trying to catch up every morning and it seemed under control
15:21:21 <ttx> just wanted to be sure
15:21:21 <smcginnis> dhellmann: Want to give a quick summary?
15:21:52 * dhellmann tries to remember what caused the first couple of failures
15:22:05 <smcginnis> I think it was updates to the xstatic version checking script.
15:22:16 <smcginnis> And incomplete changes to the job moving things around.
15:22:23 <dhellmann> oh, those were the ones that missed the xstatic_check_version.py -- I wasn't really involved in that until the very end
15:22:42 <smcginnis> I seem to remember one other issue, but blanking it now.
15:22:47 <dhellmann> I did add a task to our backlog to incorporate that same version checking into our validation
15:22:58 <dhellmann> the other issue was with the announce job
15:23:13 <smcginnis> But anyway, I think all identified issues are resolved and we should be in good shape.
15:23:16 <smcginnis> Oh right.
15:23:16 <dhellmann> as part of resolving that we also took the opportunity to move announce.sh into the releases repo
15:23:30 <smcginnis> Yay for less duplication.
15:23:41 <dhellmann> there are a couple of other tools still in the release-tools repo; I will look into moving those over, too
15:23:53 <dhellmann> and then release-tools won't be needed any more
15:24:16 <smcginnis> #topic Unassigned tasks on the Rocky plan
15:24:23 <smcginnis> We have a few...
15:24:30 <smcginnis> https://storyboard.openstack.org/#!/story/2001831
15:24:36 <smcginnis> https://storyboard.openstack.org/#!/story/2001816
15:24:43 <smcginnis> https://storyboard.openstack.org/#!/story/2001688
15:24:48 <smcginnis> https://storyboard.openstack.org/#!/story/2001691
15:25:07 <smcginnis> I have made 0 progress on any of mine due to external distractions the last few weeks.
15:25:15 <ttx> yeah, I fear those will fall between the cracks
15:25:21 <smcginnis> I'm hoping to be able to focus on some of that soon.
15:25:38 <ttx> I can take all the ones under 2001831
15:25:40 <fungi> i too haven't really started on mine yet
15:25:48 <ttx> but won't be able to take the others then
15:25:53 <smcginnis> 2001688 looks like a timely one.
15:25:53 <fungi> other than pondering what the automation will need to look like
15:26:05 <fungi> i can pretend that's "planning" ;)
15:26:21 <smcginnis> fungi: Works for me. :)
15:26:42 <fungi> should be quick to knock out once i set aside some time to focus on it, at least
15:26:46 <smcginnis> At least none of these seem to be too critical. Really really good to have, but not blocking anything.
15:27:00 <ttx> Anyone objecting to me owning all tasks on https://storyboard.openstack.org/#!/story/2001831 (for now) ?
15:27:20 <dhellmann> I took https://storyboard.openstack.org/#!/story/2001816 and https://storyboard.openstack.org/#!/story/2001691
15:27:21 <smcginnis> ttx: Own all you want. ;)
15:27:56 <dhellmann> ttx: go for it
15:28:17 <ttx> https://storyboard.openstack.org/#!/story/2001688 I guess is part of that discussion we need to have
15:28:25 <dhellmann> right
15:28:26 <smcginnis> Yep
15:28:38 <smcginnis> At least we're tracking that (and all of these) now.
15:28:40 <ttx> Looks more and more like we need to brainstorm that one before Forumizing it
15:28:59 <ttx> How about we set aside some time together to discuss it in Vancouver ?
15:29:13 <dhellmann> sounds good
15:29:17 <ttx> rather than throw the holy handgrenade in a session
15:29:37 <ttx> I can take the task to be sure I ermember to work on it
15:29:56 <fungi> three shall be the number of the counting, and the number of the counting shall be three
15:30:06 <smcginnis> Sounds good to me. We should be able to find some time before the Forum kicks off.
15:30:12 <smcginnis> :)
15:30:56 <ttx> OK all tasks assigned
15:31:01 <smcginnis> Nice
15:31:12 <smcginnis> #topic Review backlog
15:31:22 <smcginnis> #link https://storyboard.openstack.org/#!/board/64
15:31:35 <ttx> Just to make sure we don't need to move those to the TODO column
15:32:03 <ttx> Anything in there we NEED to do this cycle ?
15:32:38 <smcginnis> Doesn't look like it to me. Again, all good things to have, but nothing blocking.
15:32:48 <ttx> (is the Backlog manually generated or do all stories automatically end up in there ?)
15:33:14 <dhellmann> the backlog is manually updated
15:33:42 <ttx> should we just use the releases repo then ?
15:33:57 <ttx> Like consider anything not assigned in the openstack/releases stories to be backlog ?
15:33:59 <dhellmann> you can't move a task from an automatic query list to a manual list and if a thing appears in an automatic list on a board it won't appear when you search for it to add it
15:34:09 <dhellmann> we could do that, sure
15:34:29 <dhellmann> the backlog has things that aren't part of the releases repo (like https://storyboard.openstack.org/#!/story/1520096)
15:34:53 <dhellmann> although it doesn't have to have that, we could have added that to the todo list if we considered it important
15:35:38 <ttx> we could add a token task affecting openstack/releases just to flag it as a release team thing
15:35:41 <dhellmann> it looks like there are several items filed that are not on the backlog, so maybe it would be safer to do that
15:35:48 <dhellmann> (use the repo)
15:36:02 <dhellmann> sure
15:36:09 <fungi> could also use a story tag as a means of identifying stories with only non-releases tasks which we want to appear in an automatically managed backlog lane
15:36:30 <dhellmann> fungi : see my earlier comment about mixing automatic and manually managed lanes on 1 board
15:36:30 <fungi> i think
15:36:44 <ttx> smcginnis: I think the last task on https://storyboard.openstack.org/#!/story/2001793 can be considered merged
15:37:08 <fungi> dhellmann: right, i meant if the query was something like unassigned for releases or releases-backlog
15:37:11 <smcginnis> Oh, yep. Thanks to Doug I think.
15:37:23 <fungi> but that also might be mixing a task query and a story query, which is also a challenge at the moment
15:37:33 <smcginnis> OK, grumble time. No matter how many times I've done it and know it doesn't work, I still want to click on individual tasks.
15:38:05 <ttx> to do what?
15:38:16 <smcginnis> In this case, to be told I need to log in.
15:38:19 <fungi> smcginnis: should the task name/id do the same thing as the little expansion arrow icon to its left?
15:38:29 <fungi> oh, not authenticated
15:38:53 <smcginnis> fungi: I just expect it to pop up a detail dialog or something, and redirect me to log in if I want to do anything.
15:38:58 <ttx> the UX pain shall soon reach my "itch" level
15:38:59 <smcginnis> I just need to train my brain.
15:39:02 <fungi> there are probably more webclient actions which could get added to the read-only/unauthenticated whitelist
15:39:29 <dhellmann> I moved the story about setting up the board to the done column
15:40:03 <ttx> so.. OK if I remove the "Backlog" column ? Maybe check if any story needs a release task to stay in our scope first ?
15:40:04 <smcginnis> Anyone see any other tasks in the Backlog that need more attention?
15:40:50 <dhellmann> we could use https://storyboard.openstack.org/#!/project_group/73 as the backlog
15:41:29 <ttx> we could, indeed
15:41:40 <ttx> would avoid adding releases tasks on reno stories
15:41:43 <dhellmann> right
15:41:51 * dhellmann just re-learned about storyboard groups today
15:42:10 <smcginnis> Looks like that lists things that are still active but Merged for openstack/releases.
15:42:11 <ttx> It's still a good idea to add a releases task when the story affects a completely different repo
15:42:17 <ttx> so that it shows up here
15:42:21 * dhellmann wonders why the specs-cookiecutter template is a release team thing
15:42:33 <dhellmann> yes, definitely
15:42:41 <ttx> dhellmann: want me to remove it ?
15:43:18 <dhellmann> I just did it, and added a link to that group page to the description to make it easy to find
15:43:43 <dhellmann> do we need the "high" column or should we use the order of items in the todo list for priority?
15:44:03 <ttx> still shows specs-cookiecutter here
15:44:14 <dhellmann> oh, sorry, no, I removed the backlog column
15:44:19 <ttx> heh
15:44:24 <dhellmann> I don't know how to remove a project from the group; I think that's a project-config patch
15:44:35 <ttx> I can see the UI lets me do it
15:44:46 <dhellmann> will it be re-added the next time some job runs?
15:44:49 <ttx> but then I might have inherited superpowers from the dark days
15:45:13 <ttx> I have no idea how those are seeded
15:45:41 <ttx> OK, it's gone for now
15:45:46 <ttx> let's see what happens
15:45:52 <smcginnis> Gone
15:46:47 <smcginnis> Anything else for SB for now?
15:46:53 <ttx> Alright, next topic. We solved backlog review by just making it disappear
15:46:57 <fungi> it's managed in openstack-infra/project-config gerrit/projects.yaml
15:47:05 <fungi> i'll throw a patch up
15:47:09 <smcginnis> fungi: Thanks
15:47:17 <smcginnis> #topic Skipping next week meeting
15:47:19 <ttx> fungi: still weird that I can "fix" it
15:47:35 <ttx> I'll be in a plane at meeting time
15:47:37 <fungi> ttx: yeah, we have automation driven from project-config to add project groups and put projects in them
15:47:38 <smcginnis> So at least ttx and I are travelling next week.
15:47:56 <ttx> fungi: ah!
15:47:57 <annabelleB_> also gone (but mostly just a Stage 0 lurker still)
15:47:58 <smcginnis> I should be on solid ground. Just not sure if I will be distraction free.
15:48:05 <smcginnis> annabelleB_: :)
15:48:11 <dhellmann> it doesn't look like we expect next week to be significant in terms of the cycle schedule
15:48:24 <ttx> dhellmann: yes, hence my proposal to just skip
15:48:29 <dhellmann> wfm
15:48:32 <smcginnis> I'm fine skipping.
15:48:36 <ttx> deal
15:48:47 <smcginnis> If anything comes up, we can just quick discuss in #openstack-release
15:49:10 <smcginnis> #topic Open discussion
15:49:21 <smcginnis> Anything else?
15:49:29 <dhellmann> we have a backlog item to verify library releases at each milestone: https://storyboard.openstack.org/#!/story/2001846
15:49:34 <fungi> ttx: smcginnis: dhellmann: as for the reason _why_ we originally configured that repo to be in the releases group, it's because it's tracked as a release team deliverable in governance. is that intentional? https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml#n3217
15:49:52 <smcginnis> Huh
15:50:02 <ttx> huh huh
15:50:09 <dhellmann> I'm preparing that list now
15:50:17 <ttx> probably a leftover of when release = ttx = governance
15:50:24 <fungi> heh
15:50:30 <dhellmann> quite a few (46) : http://paste.openstack.org/show/720027/
15:50:52 <smcginnis> dhellmann: Those are libraries that have patches merged?
15:50:58 <ttx> dhellmann: that's all the ones withuot a single rocky release ?
15:51:23 <dhellmann> those are the deliverables with type library or client-library and without a release
15:51:31 <dhellmann> I did not check the patches yet, let me run that
15:51:42 <smcginnis> I can include that in next week's countdown email.
15:52:13 <dhellmann> oslosphinx is deprecated so I can just remove that deliverable file
15:52:49 <dhellmann> this report takes a while to run
15:53:29 <dhellmann> http://paste.openstack.org/show/720029/
15:54:25 <dhellmann> there's lots of good stuff in there
15:54:51 <smcginnis> Most at least have requirements updates.
15:55:03 <ttx> fungi: so now we need to find a home for it
15:55:13 <fungi> yeah
15:55:22 <dhellmann> ttx, fungi : it can stay here if that's where we thought we wanted it; I just didn't remember that
15:55:34 <smcginnis> I'll just include the list in the countdown and mention that they should check what has been merged to see if they should do a release.
15:55:50 <dhellmann> yeah, you can link to that paste so they have the same info we do
15:55:58 <fungi> maybe infra would be willing to adopt it (very low-churn and ostensibly related to the specs.o.o site publication and hosting i suppose)
15:56:04 <fungi> clarkb could probably weigh in
15:56:28 <smcginnis> That does seem at least a slightly better fit.
15:56:43 <fungi> i agree specs-cookiecutter doesn't seem particularly release team-ish
15:56:46 <smcginnis> Not that I want infra to be the dumping ground for misfits.
15:56:52 <fungi> right
15:57:09 <fungi> also maybe the docs team?
15:57:23 <fungi> anyway, this is low-priority, doesn't need meeting time to hash out
15:57:50 <smcginnis> I'm fine leaving it with releases too.
15:57:56 <clarkb> weren't a lot of the cookiecutter repos oslo?
15:58:15 <fungi> i thought just the libs cookiecutter was
15:58:19 <clarkb> ah
15:58:29 <fungi> but could be wrong
15:58:38 <dhellmann> yeah, ones for code make sense there
15:59:18 <fungi> basically if there's a team who has an interest in consistency across newly-created specs repos, then that's who should maintain it. if there isn't... why do we have that again?
15:59:39 <smcginnis> OK, out of time. We can discuss out of meeting.
15:59:42 <smcginnis> Should it be the TC?
16:00:10 <smcginnis> #endmeeting