19:00:36 #startmeeting storyboard 19:00:36 I am fragile and mobile for a while 19:00:37 Meeting started Wed Mar 8 19:00:36 2017 UTC and is due to finish in 60 minutes. The chair is zara_the_lemur__. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:38 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:40 The meeting name has been set to 'storyboard' 19:00:57 #topic Announcements 19:01:05 I WOULD LIKE TO ANNOUNCE THAT WE HAVE NO ANNOUNCEMENTS 19:01:08 #topic urgent items 19:01:15 None of which I am aware 19:01:21 #topic in-progress work 19:01:50 I believe we have at least one webclient patch awaiting reviews 19:02:07 I can take a look today. 19:02:14 #link https://review.openstack.org/#/c/436702/ 19:02:55 Wonderful. Has anyone been able to review the branch handling patch? 19:03:32 for 19:03:36 #link https://review.openstack.org/#/c/423877/ ? 19:03:54 yeah there should be logs for that from the other evening, though it appears to have timed out 19:03:57 * zara_the_lemur__ will recheck 19:04:39 is that the non-master branche one or my "good enough for monasca" halfway house? 19:04:40 ohhhh, or the revision of 19:04:45 #link https://review.openstack.org/#/c/437469/ 19:05:07 I haven't looked at that one yet 19:05:21 btw the story is up here: 19:05:27 #link https://storyboard.openstack.org/#!/story/2000876 19:05:36 so if yours is good enough for monasca, those tasks should be edited 19:05:38 The non master branch one. 19:06:21 Hopefully we can get SotKs reverified and merged soon. 19:06:33 * SotK hasn't had time, but will make time today to review that 19:07:54 After that's in what else do we have left before Monasca can move? 19:08:26 I think just agree a date for the move 19:08:50 testing against the production data went fine so I am confident it will be fairly smooth 19:09:32 \o/ 19:09:36 Cool. I can reach out to them and see if we can pick a date. Maybe for next week? 19:09:47 * diablo_rojo_phon is excited 19:10:42 maybe worth setting the time after the patch is reviewed so we know how much work is left on that 19:11:09 (and sorry I haven't had time to get to it yet :() 19:11:31 wfm, though I will be around early next week 19:11:41 erm 19:11:45 good to know :P 19:11:53 Will or won't? 19:12:22 around less at early times next week 19:12:33 * SotK cannot type on his slow old phone 19:13:24 Ah got it. So a time end of next week? Thursday or Friday would be better then? 19:14:08 I can float the idea even if we don't confirm a day yet. 19:14:19 any day works, just later times 19:14:50 tues or wed gets my vote 19:14:57 since I have meetings then anyway 19:15:28 Ah got it. 19:15:59 I can see if they are interested in doing it during our next meeting if that would work? 19:16:42 * SotK will likely be not around during the meeting next week :( 19:17:22 SotK: what time is sufficiently late for you? 19:18:17 I'm hoping 2100 but maybe even later 19:18:30 we can wait for a different week if that is too late 19:18:33 Okay that works. 19:19:01 * SotK momentarily disappears 19:19:08 SotK: (I'm not too fussed, just want to know in advance if it is that late.) 19:19:32 I'll see what day works for them at least that late. 19:20:17 should probably switch to discussion 19:20:20 well should've done that before 19:20:25 #topic Open Discussion 19:21:38 Oh well :) 19:21:51 You're still a better meeting host than I would be. 19:22:14 idk, I just change to 'discussion' at some random point in the discussion each week 19:22:35 well, the meeting's pretty small so I don't see a reason to be rigid about it 19:22:37 is my excuse 19:24:06 Okay so should we take the leftover time to go figure out why SotKs Patch failed to merge? 19:24:19 And review the other patches. 19:24:22 I think it's just timeouts 19:24:44 * zara_the_lemur__ is wondering what would be most helpful from me or SotK on your branches patch 19:25:00 probably, the migration scripts are entirely untested afaik 19:25:54 * davidlenwell ran those scripts on my test deployment .. there are a large number of network timeouts and slow responses .. but there might not be much that can be done about it. 19:26:19 yeah, it's probably just one where we need to recheck until we're lucky 19:26:27 the db migrations or the lp migrations? 19:26:28 I am a bad example 19:27:23 there was some talk around flattening our db migrations at one point 19:28:29 What all would that entail? A lot of effort or minimal? 19:29:19 theoretically not much work I think 19:29:31 but I havent thought in much detail 19:30:52 currently you can't generate a working storyboard db from the code without editing the db-generation script by hand 19:31:15 though it didn't take a lot of hand-editing 19:31:35 My knowledge of DB stuff is limited otherwise I'd jump on this. 19:31:35 I think the 'story types' table needed to be populated with at least one row 19:31:59 because some code expects there to be a thing to match against type id 1 or something 19:32:08 (so also that code could be changed) 19:32:26 I think it will all be noted in my postgresql wip from a few weeks ago 19:32:56 one of them; I seem to have sent two different changes for that somehow... 19:33:41 aw, no, it isn't 19:34:33 there are irc logs, then 19:34:34 somehwere 19:34:36 *somewhere 19:35:53 * SotK wonders if we need story_types 19:36:14 I'm not convinced we do. 19:36:31 certainly our current implementation of story permissions doesn't need it 19:37:08 but there is interesting problems wrt auto-adding the vmt to security issues that it may help solve 19:37:14 s/is/are/ 19:37:45 What is the expected total enumeration of types? 19:38:12 Just security/normal? 19:38:41 perhaps, I haven't given this much thought either 19:39:05 those are the only two which spring to mind, which doesn't really need a separate table 19:39:35 I usually argue against types because people want to look at feature/bug, but I would argue in favour of certain enumeration. 19:39:53 the current list that storyboard has is 'bug', 'feature', 'private_vulnerability', 'public_vulnerability' 19:40:13 which I don't think gives us much 19:40:34 No. 19:40:40 especially given that a story can be of only one type and those types don't exclude each other 19:40:42 especially as we don't use it 19:41:17 :) 19:41:17 we certainly don't need bug/feature 19:41:23 indeed 19:41:40 and the private/public vulnerability thing is aiming for the launchpad model directly I think 19:41:56 #agreed bug/feature is user opinion not core story data 19:42:04 it surprises me how many people get hung up on not having the distinction between bug/feature 19:42:19 and you can convey 'vulnerability' with tags or similar, and public/private elsewhere 19:42:36 my guess is that it can govern who foots the bill? 19:43:04 at ptg someone literally said to me "I'd like storyboard but not being to easily filter between bugs / features is a problem" 19:43:14 Yes, who pays. Less meaningful in collaborative spaces. 19:43:32 I agree, though I feel like it could be argued that "security-related" deserves to be a "story type" or similar 19:44:03 I can see the 'if it's a feature request, it's extending the scope of a project from agreed terms, vs if it's a bug, someone didn't meet the terms agreed 19:44:06 ' 19:44:10 it certainly would give us an easier way of programmatically identifying vulnerability stories without hardcoding a tag name 19:44:45 SotK: I think a hardcore type flag is better than a hardcore tag for that. 19:44:54 Hardcoded 19:44:59 best autocorrect 19:45:01 I agree wholeheartedly 19:45:20 I am concerned that'll suffer from feature-creep 19:45:34 but we already have types 19:45:43 so it'd simplify what we already have support for 19:45:52 fsvo support :P 19:45:55 but yes 19:46:33 * SotK considers having it in a table now is useful in case other actual story types become clear, but I don't know that that is real value without more thought 19:46:51 heh 19:47:16 Just need to take care to semantically distinguish objective types from subjective types. 19:47:24 I'd rather tags since people will probably get sad if they can't filter on them in all the ways they can on tags, but it's not a strong preference since anything is better than what we have atm. 19:47:52 just be prepared for 'I want a worklist containing only things of this story type' etc 19:48:02 we can just implement filtering for the type flag 19:48:19 tags is asking for a whole world of complication ime 19:48:50 what about it seems complicated ooi? 19:49:04 Yes. Tags is bad for deep automation. Excellent for user automation, but that does not fit VMT needs. 19:49:14 what persia said 19:50:03 namely, we'd have to say 'you need to add a "vulnerability" tag to your story after you make it to file a security bug' 19:50:30 oh, on the submission side, yes 19:50:36 and then the added tag would need to be exactly "vulnerability" because it would be hardcoded as our "security issue" tag in the API 19:50:46 I was picturing a checkbox that would apply a tag sneakily. 19:51:00 but then you lose the reusability of components 19:51:02 such a checkbox may as well just set a flag 19:51:05 yes 19:51:19 and this way someone is probably less likely to remove the tag accidentally 19:51:23 * persia was thinking a checkbox for a binary flag representation. 19:51:29 * SotK too 19:51:57 Sounds pretty unanimous 19:53:11 * SotK thinks we don't want the story_types table 19:53:41 hah, I was gonna say I suspect all stories are type '1' currently, so if we don't want to change them, make that the value for 'non-vulnerability', and get rid of the other rows 19:54:32 that settles it, all stories are bugs :D 19:55:26 but yeah, I can't see any real value in that table over flags for things we think are objectively "types" and tags for opinions 19:56:17 sure, I'm not sure how much of the code will need rewriting without it 19:56:19 hopefully not much 19:57:15 Making decisions always feels like progress even if it means doing more work :) 19:57:39 oh and it's used by can_mutate which we also don't use afaik 19:57:44 so maybe some spring cleaning round there 19:58:48 oh, we're at the end 19:59:05 well there's a fluffy yak to shave anyway 19:59:15 #endmeeting