15:00:21 <dhellmann> #startmeeting releaseteam
15:00:22 <openstack> Meeting started Fri Nov 18 15:00:21 2016 UTC and is due to finish in 60 minutes.  The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:25 <openstack> The meeting name has been set to 'releaseteam'
15:00:29 <dhellmann> courtesy ping: ttx, dims, sigmavirus, tonyb, fungi
15:00:30 <sigmavirus> Good morning!
15:00:39 <dhellmann> sigmavirus : o/
15:00:45 <sigmavirus> \o
15:00:45 <dims> o/
15:00:57 <dhellmann> this is week R-14, and our agenda is in the etherpad as usual
15:00:59 <dhellmann> #link https://etherpad.openstack.org/p/ocata-relmgt-tracking
15:01:20 <ttx> o/
15:01:30 <dhellmann> #topic late ocata-1 milestone tags
15:01:45 <ttx> just added that to decide what to do with in-flight
15:02:04 <ttx> and have an idea of who missed the call
15:02:08 <dhellmann> I'm comfortable approving all of the requests that are up now (assuming they look ok)
15:02:08 <ttx> (even vague)
15:02:20 * ttx looks them up
15:02:24 <dhellmann> I can make the list of who hasn't proposed a tag at all
15:02:45 <dhellmann> unless someone else has time to do that today?
15:02:57 <ttx> no hurry
15:02:58 <sigmavirus> dhellmann: how does one do it? I could do it during the meeting perhaps
15:03:04 <ttx> +1 on approving the in-flight stuff
15:03:27 <dhellmann> sigmavirus : it's a manual review of deliverables with cycle-milestone against what has been tagged or proposed
15:03:43 <dims> dhellmann : am booked solid for a few days...
15:04:01 <dhellmann> unfortunately, the fact that we moved the tag info out of governance makes it harder to get the list of cycle-with-milestones projects, because I haven't fixed the list-projects command yet
15:04:27 <ttx> we could do that sometimes next week
15:04:27 <dhellmann> maybe that's what I'll work on this afternoon
15:04:34 <dhellmann> yeah, no rush
15:04:35 <ttx> like I said, no hurtry
15:04:38 <ttx> hurry*
15:04:55 <ttx> just that it might hide a deeper problem within those teams
15:05:06 <dhellmann> were there any proposals that looked bad for any reason? the monasca folks have responded to the goal so I removed my -2 there
15:05:18 <ttx> dhellmann: all lgtm
15:05:25 <dhellmann> I haven't had a chance to review the others yet
15:05:25 <dhellmann> good
15:05:28 <ttx> adding +2 as we speak
15:05:37 <dhellmann> cool
15:05:38 <ttx> hrm
15:05:42 <dhellmann> anything else on this topic?
15:05:47 <ttx> 1.4.0.b1
15:05:57 <dhellmann> did that pass validation?
15:06:03 <ttx> apparently yes
15:06:07 <dhellmann> that's a bug
15:06:54 <dhellmann> ok, well, they proposed it on time. let's see if they can turn around a fix quickly.
15:07:29 <dhellmann> anything else?
15:07:43 <ttx> lpuppet is not realty ocata-1 so no hurry
15:08:04 <dhellmann> ah, yeah
15:08:06 <ttx> zaqar lgtm
15:08:14 <ttx> same for zaqar-ui
15:08:20 <dhellmann> the puppet modules are an issue, because they have to land a patch to put the version inside their modules before we can tag it
15:09:01 <ttx> mon,asca no hurry
15:09:10 <ttx> since it's not ocata-1 either
15:09:57 <ttx> was fooled by commit messages
15:10:08 <ttx> I'm pretty sure they don't want it 'released'
15:10:17 <ttx> and submitted ocata-1 by accident
15:10:21 <dhellmann> it would be good to get some other input on the python-keystoneclient release, since we've gone back and forth on that one
15:10:23 <dhellmann> I told stevemar I'd let them make the call, but I haven't seen an update
15:10:57 <stevemar> yeah, been a busy week. its still on my list
15:10:59 <dhellmann> oh, yeah, monasca is cycle-with-intermediary not cycle-with-milestones
15:11:16 <ttx> I bet they just got confused with ocata-1 messaging
15:11:21 <dhellmann> probably
15:11:48 <fungi> and i guess the monasca licensing clarifications are satisfactory from the release team's perspective now
15:11:50 <dhellmann> I stopped reviewing when I saw they hadn't responded to the goals. I probably should have done the more thorough read-through
15:12:22 <dhellmann> fungi : I thought that was resolved. we did release new newton versions with their updated license info.
15:12:32 <fungi> yep, i saw. just confirming
15:12:41 <ttx> I propose we move on
15:12:43 <dhellmann> yep
15:12:50 <dhellmann> #topic goals progress report
15:13:04 <ttx> approved the zaqar ones
15:13:08 <dhellmann> I wanted to do a quick check on where some of our higher priority goals for this cycle stand
15:13:40 <dhellmann> #info "move release tags from governance" is mostly done, except for cleaning up a few of our tools and coordinating with the project navigator team
15:13:57 <dhellmann> #info "branch automation" spec has been approved, but coding has not started
15:14:04 <dhellmann> I'm going to try to start that next week
15:14:07 * dhellmann crosses fingers
15:14:42 <dhellmann> #info "new announcement mailing list" needs the infra change approved
15:14:47 <dhellmann> ttx, anything else to report there?
15:14:54 <dhellmann> #link https://review.openstack.org/#/c/394418/
15:15:02 <ttx> blocked on ML creation
15:15:18 <ttx> fungi: would appreciate review @ https://review.openstack.org/#/c/394418/
15:15:26 <ttx> then I can configure the list and unblock the rest of the patch chain
15:15:29 <fungi> thanks, just pulled it up
15:16:02 <ttx> I just workflow-1ed the rest of the patch chain since it got approved and should not merge until the ML is confiugured
15:16:10 <ttx> (not just created but configured)
15:16:20 <fungi> lgtm, approved
15:16:32 <ttx> cool, ~30min until it's active ?
15:16:51 <dhellmann> thanks, fungi
15:16:54 <fungi> roughly. you should receive an admin e-mail to the specified address when it gets created
15:17:03 <dhellmann> nice
15:17:07 <dhellmann> I haven't looked at adding the signing key info to the newton or ocata pages of releases.o.o. Should I just add the key ID and fingerprint? Is there some way to link to the key?
15:17:35 <fungi> dhellmann: it's still high on my to do list, if you want to hold off
15:17:51 <fungi> or i can filter you the urls and stuff if you're in a hurry
15:18:03 <dhellmann> fungi : oh, I thought adding the historical data was on my list. I'm happy to have you do it. :-)_
15:18:36 <dhellmann> dims said he was slammed this week, so I'm guessing that means he hasn't had time to start looking at adding links to signature files
15:19:01 <dims> dhellmann : yep. i expect one more week like this...
15:19:10 <dhellmann> dims : ack, no worries, we have plenty of time
15:19:29 <fungi> i think the plan was just to add them for all tarballs from this cycle onward, and ignore the ones from last cycle since we'd have to figure out how to pin the earliest date they started getting created
15:19:51 <fungi> but if there's sufficient date metadata in there, maybe that's not hard
15:19:56 <dhellmann> fungi : yes, that's what I remember
15:20:23 <dhellmann> I think we could get the date of a given release, but it would be relatively expensive to do that many git operations while building the site
15:21:06 <fungi> i'll be switching the newton signing key out for the ocata one today. it's got enough infra-root signatures on it i'm comfortable. though if you want to wait the newton key isn't set to expire for another couple weeks
15:21:43 <fungi> #link https://sks-keyservers.net/pks/lookup?op=vindex&search=0xd47bab1b7dc2e262a4f6171e8b1b03fd54e2ac07&fingerprint=on
15:22:47 <dhellmann> I think it's fine to go ahead and switch now
15:23:11 <dhellmann> although maybe wait until we finish tagging the first milestone, so they are all signed with the same key?
15:23:13 <fungi> but anyway, feel free to follow the attestation instructions if you also want to sign it now
15:23:17 <fungi> #link http://docs.openstack.org/infra/system-config/signing.html#attestation
15:23:25 <dhellmann> ++
15:23:31 <fungi> dhellmann: i'm happy to wait if you let me know when you want that done
15:23:41 <dhellmann> monday?
15:23:48 <fungi> monday it is. setting myself a reminder now
15:24:01 <ttx> I'll probably flip the switch on announcements on Monday too
15:24:14 <ttx> i.e. announce new list before we start processing releases on it
15:24:17 <dhellmann> great, thanks
15:24:18 <dhellmann> excellent
15:24:20 <ttx> rather than now
15:24:26 <dhellmann> yes, we want folks to have time to subscribe
15:24:41 <ttx> time being "1 day" but yes :)
15:24:49 <dims> :)
15:24:56 <dhellmann> 1 > 0
15:25:04 <fungi> meh, there are archives too ;)
15:25:14 <ttx> and digest by default !
15:25:20 <ttx> so at least 23 hours more
15:25:22 <sigmavirus> fungi: I might ping you after the meeting to talk about twine uploads and signing them and such
15:25:41 <dhellmann> I've added a reminder to include the new mailing list info in the countdown email for next week, so that will be 2 messages about it
15:25:44 <fungi> sigmavirus: yeah, i have a nice long story for you about why we're not going to bother
15:26:06 <fungi> (dstufft says he's ripping that feature out entirely with warehouse because it's useless)
15:26:07 <sigmavirus> fungi: okay, there's a feature request over there that I wanted to discuss but, if you're not going to bother then it is moot :)
15:26:16 <sigmavirus> fungi: that is correct
15:26:19 <dhellmann> ttx, it looks like your patch to validate pre-version number use has landed. maybe recheck the monasca patch to trigger that?
15:26:22 <sigmavirus> fungi: also off topic for here :)
15:26:36 <sigmavirus> (and entirely my fault it came up ;) )
15:26:42 <ttx> dhellmann:  on it
15:26:44 <fungi> sigmavirus: sure, get up with me in #-infra if you have news on that front, thanks!
15:27:11 <dhellmann> apevec pointed out that one of the puppet releases was tagged on the wrong branch recently, so if someone has time to look into validating that a release from a given branch is actually on that branch it would be good. I think we used to have logic for that, but it was buggy?
15:27:26 <dhellmann> the puppet team will be proposing a new tag, if they haven't already
15:28:03 <ttx> write me down on that. Might have time to work on it next week
15:28:17 <dhellmann> thanks
15:28:26 <ttx> add it to the ocata plan with my name
15:28:30 <dhellmann> are there any other updates on tasks we've started?
15:28:40 <dhellmann> ttx: I'll do that after the meeting
15:29:00 <ttx> dhellmann: pointers to review which should have failed would be useful
15:29:11 <dhellmann> ttx: ack, I'll pull that info together
15:29:30 <dhellmann> moving on then
15:29:35 <dhellmann> #topic migration to storyboard
15:29:49 <ttx> I have to get something to do on Thanksgiving day after all
15:30:15 <dhellmann> diablo_rojo contacted PTLs recently asking for info about what storyboard lacks that would let us move over to it
15:31:02 <dhellmann> I've had a hard time with the UI myself in the past, through lack of time invested in learning it, but I wanted to see if anyone else had experimented and knew of things we would need that it doesn't have right now?
15:31:48 <dhellmann> for tracking our own work it seems fairly straightforward
15:31:58 <ttx> the only "tasklist" we have is the ocata-plan
15:32:07 <ttx> In /theory/ we could turn it into a set of stories
15:32:08 <dhellmann> I'm also interested to see if we could use it to track the work project teams have to do during a cycle
15:32:18 <ttx> and use boards and all to get fancy
15:32:21 <dhellmann> for example, a story or task or whatever for each milestone tag
15:32:26 <dhellmann> and for the final release steps
15:33:03 <sigmavirus> that would be helpful for me
15:33:05 <ttx> I'll readily admit than despite having created the damn thing I'm not a primary user
15:33:07 <dhellmann> on the other hand, the spreadsheet dashboard we use for the final release work gives an easy to consume UI
15:33:29 <dhellmann> and I'm not sure that special case is the sort of thing the storyboard team is interested in building
15:33:33 <sigmavirus> I haven't seen the spreadsheet so that may be better :)
15:33:43 <fungi> up side is that the api is pretty robust, so could autocreate and associate all those stories/tasks/worklists with a script
15:33:55 <ttx> I think SToryboard is most useful once you have tasks that are shared with other teams
15:33:58 <dhellmann> perhaps the biggest thing lacking is documentation about how to use it, though maybe that has been improved since the last time I looked
15:34:09 <dhellmann> fungi : yes, that's definitely a nice feature
15:34:26 <ttx> i.e. if we would have an ocata-1 story and create tasks in every -with-milestones project task lists for them to tag it... I could see that as useful
15:34:39 <dhellmann> ttx: I'm still having trouble fitting a list of work to the data model of the app. What's a story? What's a board? What's a task?
15:34:43 <fungi> there has been a lot of documentation work going on, though one of the design concepts is that for the webui it should be self-documenting rather than relying on a separate external prose manual
15:34:45 <ttx> then you have a way to "push" work to them and track completion
15:34:56 <ttx> story = Bug in LP
15:35:00 <ttx> task = BugTask in LP
15:35:19 <dhellmann> fungi : the search box is still too magic for me to feel like I can get it to do what I want. I'm thinking docs like gerrit has for its search features.
15:35:30 <ttx> Board are a way to list tasks (think like tags/milestones in LP)
15:35:38 <dhellmann> although maybe the search is less powerful, and I'm expecting more than is implemented
15:35:50 <ttx> (those are actually tasklists, and then you can arrange several tasklists in a Trelmlo-like kanban board
15:35:51 <fungi> story also can be a (more flexible) equivalent of a blueprint in lp
15:36:17 <ttx> to be fair, it's difficult for us to use it unless everyone else uses it
15:36:22 <dhellmann> ttx: right, so for your milestone example I could see implementing that both as a story and as a board. it's not clear how to choose.
15:36:32 <fungi> dhellmann: right, i believe the search box shares its syntax with the search api, so maybe we could link to that part of the api socumentation
15:36:34 <fungi> documentation
15:36:58 <ttx> We'd use it as a coordination tool, and you can't get coordination until everyone uses it
15:37:10 <dhellmann> right
15:37:14 <ttx> so we are not the best group to convince first
15:37:22 <dhellmann> well, we could theoretically put our own tasks into it
15:37:43 <ttx> I'd say that Ocata-1 is a story for us and a milestone for others.
15:37:52 <fungi> on the flip side, we would want to make sure that if all other teams moved from lp to sb, the release team wouldn't find itself unable to operate
15:38:14 <ttx> i.e. we'd crrate a "Publish Ocata-1" story, with tasks for every project that need a tag created
15:38:18 <dhellmann> the thing I'm afraid of, given my bad experiences with search, is "losing" a task if we decide to deprioritize it
15:38:19 <dhellmann> so it's not in a board or whatever we're using for tracking
15:38:21 <dhellmann> fungi : this team doesn't use lp at all right now, so I think that wouldn't be an issue
15:38:27 <dhellmann> we really just use the -plan and -tracking etherpads
15:38:30 <ttx> then projects are free to use that task in any board they use to organize work
15:38:38 <dhellmann> and then the dashboard for final release
15:38:49 <fungi> yeah, given that all the milestone tracking moved out of lp for your purposes, it's likely a non-issue
15:38:58 <dhellmann> ttx: ok, I did not realize that tasks could be associated with individual projects
15:39:02 <ttx> FOr final release you would have multiple stories for each step and we'd organize them as a board of our own
15:39:06 <dhellmann> ttx: does storyboard know about deliverables or just repos?
15:39:14 <fungi> dhellmann: well, tasks are associated with repos
15:39:16 <ttx> dhellmann: like LP BugTasks
15:39:28 <fungi> you can create "groups" however
15:39:41 <fungi> which are arbitrary many-to-many groupings of repos
15:39:56 <dhellmann> the release team doesn't think in terms of repos, though. we focus on the deliverable level.
15:40:03 <dhellmann> so maybe groups are what we'd want
15:40:17 <ttx> dhellmann: probably yes
15:40:32 <ttx> I don't think we have a "must-have" to communicate at this stage
15:40:41 <dhellmann> maybe as an experiment we can set up an ocata-2 story with the relevant tasks for a couple of project teams
15:40:52 <dhellmann> that would let me see what it would look like
15:40:58 <ttx> dhellmann: difficult to do unless that project has migrated though
15:41:02 <fungi> or i guess i should clarify, what storyboard calls "projects" are currently being mapped to individual git repos, and we have some expectations from a change-to-task mapping that it will be that way
15:41:16 <ttx> which points back to what I said about us being the last to migrate :)
15:41:17 <dhellmann> but yeah, my only need is some instructions for using it
15:41:42 <ttx> The good side is that it has a good api
15:41:43 <dhellmann> yes, that seems likely, though I wouldn't want to lag
15:41:56 <ttx> so we could create all we need automatically (like Ocata-1 stories)
15:42:08 <dhellmann> that would be useful
15:42:18 <ttx> so my take is:
15:42:36 <ttx> we don't have a must-have gap to communicate
15:42:51 <ttx> when all teams have migrated we'll use it for some tracking
15:43:05 <ttx> if at that point we realize we are still missing something, I'd expect us to contribute it
15:43:25 <dhellmann> yes, probably
15:43:31 <ttx> because the largest problem (getting everyone to use it) would be behind us
15:43:45 <fungi> and it's in python+javascript, following a similar design model to horizon, so there is already some expertise in our wider community for hacking on it
15:43:55 <ttx> but exploring it is definitely useful
15:44:15 <dhellmann> given my experience contributing the patches to move off of oslo-incubator code, as a contributor I would want a test suite that I could run locally. The tests were doing so much database work they never completed when I ran them on my local (slowish) machine.
15:44:54 <fungi> probably needs a functional job that exercises the api
15:44:56 <dhellmann> but from a feature standpoint, yes, I think it sounds like it already handles what we would want
15:45:09 <dhellmann> fungi : when I ran "tox -e py27" it was running all functional tests, afaict
15:45:18 <dhellmann> maybe it was just "mostly"
15:45:26 <dhellmann> anyway, I'll reply to that email thread with this info
15:45:32 <dhellmann> #topic open discussion
15:45:35 <fungi> right, i mean separated out from lower-level unit tests (so the unit testing goes faster)
15:45:41 <dhellmann> fungi : ack
15:45:49 <dhellmann> does anyone else have anything to bring up this week?
15:45:55 <ttx> Also I expect the must-have list to be large enough with "regular" projects requests
15:46:16 <ttx> and them to be in priority (we can continue to handle our stuff separately without creating too much issues for everyone else)
15:46:58 <dhellmann> yep
15:47:23 <dhellmann> if there's nothing else, we can call the meeting early
15:47:38 <ttx> good!
15:47:43 <ttx> ML just created
15:47:49 <ttx> so plenty of work for that last hour in the week
15:47:50 <dhellmann> woot!
15:47:55 <dhellmann> thanks everyone!
15:48:06 <dhellmann> #endmeeting