15:00:21 #startmeeting releaseteam 15:00:22 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:25 The meeting name has been set to 'releaseteam' 15:00:29 courtesy ping: ttx, dims, sigmavirus, tonyb, fungi 15:00:30 Good morning! 15:00:39 sigmavirus : o/ 15:00:45 \o 15:00:45 o/ 15:00:57 this is week R-14, and our agenda is in the etherpad as usual 15:00:59 #link https://etherpad.openstack.org/p/ocata-relmgt-tracking 15:01:20 o/ 15:01:30 #topic late ocata-1 milestone tags 15:01:45 just added that to decide what to do with in-flight 15:02:04 and have an idea of who missed the call 15:02:08 I'm comfortable approving all of the requests that are up now (assuming they look ok) 15:02:08 (even vague) 15:02:20 * ttx looks them up 15:02:24 I can make the list of who hasn't proposed a tag at all 15:02:45 unless someone else has time to do that today? 15:02:57 no hurry 15:02:58 dhellmann: how does one do it? I could do it during the meeting perhaps 15:03:04 +1 on approving the in-flight stuff 15:03:27 sigmavirus : it's a manual review of deliverables with cycle-milestone against what has been tagged or proposed 15:03:43 dhellmann : am booked solid for a few days... 15:04:01 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 we could do that sometimes next week 15:04:27 maybe that's what I'll work on this afternoon 15:04:34 yeah, no rush 15:04:35 like I said, no hurtry 15:04:38 hurry* 15:04:55 just that it might hide a deeper problem within those teams 15:05:06 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 dhellmann: all lgtm 15:05:25 I haven't had a chance to review the others yet 15:05:25 good 15:05:28 adding +2 as we speak 15:05:37 cool 15:05:38 hrm 15:05:42 anything else on this topic? 15:05:47 1.4.0.b1 15:05:57 did that pass validation? 15:06:03 apparently yes 15:06:07 that's a bug 15:06:54 ok, well, they proposed it on time. let's see if they can turn around a fix quickly. 15:07:29 anything else? 15:07:43 lpuppet is not realty ocata-1 so no hurry 15:08:04 ah, yeah 15:08:06 zaqar lgtm 15:08:14 same for zaqar-ui 15:08:20 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 mon,asca no hurry 15:09:10 since it's not ocata-1 either 15:09:57 was fooled by commit messages 15:10:08 I'm pretty sure they don't want it 'released' 15:10:17 and submitted ocata-1 by accident 15:10:21 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 I told stevemar I'd let them make the call, but I haven't seen an update 15:10:57 yeah, been a busy week. its still on my list 15:10:59 oh, yeah, monasca is cycle-with-intermediary not cycle-with-milestones 15:11:16 I bet they just got confused with ocata-1 messaging 15:11:21 probably 15:11:48 and i guess the monasca licensing clarifications are satisfactory from the release team's perspective now 15:11:50 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 fungi : I thought that was resolved. we did release new newton versions with their updated license info. 15:12:32 yep, i saw. just confirming 15:12:41 I propose we move on 15:12:43 yep 15:12:50 #topic goals progress report 15:13:04 approved the zaqar ones 15:13:08 I wanted to do a quick check on where some of our higher priority goals for this cycle stand 15:13:40 #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 #info "branch automation" spec has been approved, but coding has not started 15:14:04 I'm going to try to start that next week 15:14:07 * dhellmann crosses fingers 15:14:42 #info "new announcement mailing list" needs the infra change approved 15:14:47 ttx, anything else to report there? 15:14:54 #link https://review.openstack.org/#/c/394418/ 15:15:02 blocked on ML creation 15:15:18 fungi: would appreciate review @ https://review.openstack.org/#/c/394418/ 15:15:26 then I can configure the list and unblock the rest of the patch chain 15:15:29 thanks, just pulled it up 15:16:02 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 (not just created but configured) 15:16:20 lgtm, approved 15:16:32 cool, ~30min until it's active ? 15:16:51 thanks, fungi 15:16:54 roughly. you should receive an admin e-mail to the specified address when it gets created 15:17:03 nice 15:17:07 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 dhellmann: it's still high on my to do list, if you want to hold off 15:17:51 or i can filter you the urls and stuff if you're in a hurry 15:18:03 fungi : oh, I thought adding the historical data was on my list. I'm happy to have you do it. :-)_ 15:18:36 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 dhellmann : yep. i expect one more week like this... 15:19:10 dims : ack, no worries, we have plenty of time 15:19:29 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 but if there's sufficient date metadata in there, maybe that's not hard 15:19:56 fungi : yes, that's what I remember 15:20:23 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 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 #link https://sks-keyservers.net/pks/lookup?op=vindex&search=0xd47bab1b7dc2e262a4f6171e8b1b03fd54e2ac07&fingerprint=on 15:22:47 I think it's fine to go ahead and switch now 15:23:11 although maybe wait until we finish tagging the first milestone, so they are all signed with the same key? 15:23:13 but anyway, feel free to follow the attestation instructions if you also want to sign it now 15:23:17 #link http://docs.openstack.org/infra/system-config/signing.html#attestation 15:23:25 ++ 15:23:31 dhellmann: i'm happy to wait if you let me know when you want that done 15:23:41 monday? 15:23:48 monday it is. setting myself a reminder now 15:24:01 I'll probably flip the switch on announcements on Monday too 15:24:14 i.e. announce new list before we start processing releases on it 15:24:17 great, thanks 15:24:18 excellent 15:24:20 rather than now 15:24:26 yes, we want folks to have time to subscribe 15:24:41 time being "1 day" but yes :) 15:24:49 :) 15:24:56 1 > 0 15:25:04 meh, there are archives too ;) 15:25:14 and digest by default ! 15:25:20 so at least 23 hours more 15:25:22 fungi: I might ping you after the meeting to talk about twine uploads and signing them and such 15:25:41 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 sigmavirus: yeah, i have a nice long story for you about why we're not going to bother 15:26:06 (dstufft says he's ripping that feature out entirely with warehouse because it's useless) 15:26:07 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 fungi: that is correct 15:26:19 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 fungi: also off topic for here :) 15:26:36 (and entirely my fault it came up ;) ) 15:26:42 dhellmann: on it 15:26:44 sigmavirus: sure, get up with me in #-infra if you have news on that front, thanks! 15:27:11 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 the puppet team will be proposing a new tag, if they haven't already 15:28:03 write me down on that. Might have time to work on it next week 15:28:17 thanks 15:28:26 add it to the ocata plan with my name 15:28:30 are there any other updates on tasks we've started? 15:28:40 ttx: I'll do that after the meeting 15:29:00 dhellmann: pointers to review which should have failed would be useful 15:29:11 ttx: ack, I'll pull that info together 15:29:30 moving on then 15:29:35 #topic migration to storyboard 15:29:49 I have to get something to do on Thanksgiving day after all 15:30:15 diablo_rojo contacted PTLs recently asking for info about what storyboard lacks that would let us move over to it 15:31:02 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 for tracking our own work it seems fairly straightforward 15:31:58 the only "tasklist" we have is the ocata-plan 15:32:07 In /theory/ we could turn it into a set of stories 15:32:08 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 and use boards and all to get fancy 15:32:21 for example, a story or task or whatever for each milestone tag 15:32:26 and for the final release steps 15:33:03 that would be helpful for me 15:33:05 I'll readily admit than despite having created the damn thing I'm not a primary user 15:33:07 on the other hand, the spreadsheet dashboard we use for the final release work gives an easy to consume UI 15:33:29 and I'm not sure that special case is the sort of thing the storyboard team is interested in building 15:33:33 I haven't seen the spreadsheet so that may be better :) 15:33:43 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 I think SToryboard is most useful once you have tasks that are shared with other teams 15:33:58 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 fungi : yes, that's definitely a nice feature 15:34:26 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 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 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 then you have a way to "push" work to them and track completion 15:34:56 story = Bug in LP 15:35:00 task = BugTask in LP 15:35:19 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 Board are a way to list tasks (think like tags/milestones in LP) 15:35:38 although maybe the search is less powerful, and I'm expecting more than is implemented 15:35:50 (those are actually tasklists, and then you can arrange several tasklists in a Trelmlo-like kanban board 15:35:51 story also can be a (more flexible) equivalent of a blueprint in lp 15:36:17 to be fair, it's difficult for us to use it unless everyone else uses it 15:36:22 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 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 documentation 15:36:58 We'd use it as a coordination tool, and you can't get coordination until everyone uses it 15:37:10 right 15:37:14 so we are not the best group to convince first 15:37:22 well, we could theoretically put our own tasks into it 15:37:43 I'd say that Ocata-1 is a story for us and a milestone for others. 15:37:52 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 i.e. we'd crrate a "Publish Ocata-1" story, with tasks for every project that need a tag created 15:38:18 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 so it's not in a board or whatever we're using for tracking 15:38:21 fungi : this team doesn't use lp at all right now, so I think that wouldn't be an issue 15:38:27 we really just use the -plan and -tracking etherpads 15:38:30 then projects are free to use that task in any board they use to organize work 15:38:38 and then the dashboard for final release 15:38:49 yeah, given that all the milestone tracking moved out of lp for your purposes, it's likely a non-issue 15:38:58 ttx: ok, I did not realize that tasks could be associated with individual projects 15:39:02 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 ttx: does storyboard know about deliverables or just repos? 15:39:14 dhellmann: well, tasks are associated with repos 15:39:16 dhellmann: like LP BugTasks 15:39:28 you can create "groups" however 15:39:41 which are arbitrary many-to-many groupings of repos 15:39:56 the release team doesn't think in terms of repos, though. we focus on the deliverable level. 15:40:03 so maybe groups are what we'd want 15:40:17 dhellmann: probably yes 15:40:32 I don't think we have a "must-have" to communicate at this stage 15:40:41 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 that would let me see what it would look like 15:40:58 dhellmann: difficult to do unless that project has migrated though 15:41:02 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 which points back to what I said about us being the last to migrate :) 15:41:17 but yeah, my only need is some instructions for using it 15:41:42 The good side is that it has a good api 15:41:43 yes, that seems likely, though I wouldn't want to lag 15:41:56 so we could create all we need automatically (like Ocata-1 stories) 15:42:08 that would be useful 15:42:18 so my take is: 15:42:36 we don't have a must-have gap to communicate 15:42:51 when all teams have migrated we'll use it for some tracking 15:43:05 if at that point we realize we are still missing something, I'd expect us to contribute it 15:43:25 yes, probably 15:43:31 because the largest problem (getting everyone to use it) would be behind us 15:43:45 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 but exploring it is definitely useful 15:44:15 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 probably needs a functional job that exercises the api 15:44:56 but from a feature standpoint, yes, I think it sounds like it already handles what we would want 15:45:09 fungi : when I ran "tox -e py27" it was running all functional tests, afaict 15:45:18 maybe it was just "mostly" 15:45:26 anyway, I'll reply to that email thread with this info 15:45:32 #topic open discussion 15:45:35 right, i mean separated out from lower-level unit tests (so the unit testing goes faster) 15:45:41 fungi : ack 15:45:49 does anyone else have anything to bring up this week? 15:45:55 Also I expect the must-have list to be large enough with "regular" projects requests 15:46:16 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 yep 15:47:23 if there's nothing else, we can call the meeting early 15:47:38 good! 15:47:43 ML just created 15:47:49 so plenty of work for that last hour in the week 15:47:50 woot! 15:47:55 thanks everyone! 15:48:06 #endmeeting