19:02:46 #startmeeting storyboard 19:02:47 Meeting started Wed Aug 22 19:02:46 2018 UTC and is due to finish in 60 minutes. The chair is SotK. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:02:48 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:02:50 The meeting name has been set to 'storyboard' 19:03:04 #link https://wiki.openstack.org/wiki/Meetings/StoryBoard Agenda 19:03:20 once again I forgot to update it until now, sorry 19:03:34 #topic Announcements 19:04:47 o/ 19:05:02 welcome diablo_rojo 19:05:10 fungi, here too? 19:07:33 do we have anything to announce? 19:07:43 Requirements migrated last week? 19:07:55 I think thats the only one 19:08:10 oh, yep, i'm around 19:08:30 Requirements was the only one you migrated last week correct? 19:08:36 afaik, yes 19:08:44 Cool. 19:08:49 Oh hello fatema_ :) 19:08:59 i'm scheduled to migrate some project called "slogging" a week from tomorrow 19:09:08 hello, sorry I'm late 19:09:30 hello fatema_ :) 19:10:01 Hi, diablo_rojo SotK 19:10:06 Oh yes that's the other one I was trying to remember 19:10:11 fatema_, no worries 19:11:43 #topic Migration Updates 19:12:16 I saw that Searchlight and Freezer are kind of reorganizing and I suggested now might be a good time to migrate. Haven't heard anything back from them yet. 19:12:22 Still nothing from keystone. 19:12:31 And others are holding out for attachments. 19:12:57 I thiiink thats all the updates I have 19:13:56 cool, hopefully you hear back from folks 19:13:56 diablo_rojo: it looked like the new searchlight ptl agreed with your recommendation? 19:14:16 at least based on my reading of the reply on that thread 19:14:23 fungi, oh, okay cool- missed that in my inbox 19:14:28 I'll take another look. 19:14:33 Can do a test migration today 19:16:04 speaking of test migrations, not sure if you saw my comment in #storyboard during the requirements migration testing but repeating the migration tool runs only pulls in new tasks/comments (and users), doesn't update any existing tasks whose statuses have changed in lp since the previous run 19:16:07 I see the thread but I don't see my message nor a response- just ttx and Nguen and Trinhs messages 19:16:59 ah, its mentioned in the first email of the searchlight thread 19:17:04 fungi, would we want to update those though? We wouldnt want sb statuses to be overwritten if they had changed. 19:17:13 OH 19:17:14 LOL 19:17:16 I see now 19:17:26 diablo_rojo: http://lists.openstack.org/pipermail/openstack-dev/2018-August/133632.html 19:17:48 He must have started a new thread that looks practically the same. 19:17:52 Hence my confusion 19:18:08 the mailman archive seems to thread it correctly 19:18:31 fungi, probably just inbox getting confused 19:18:35 or my brain 19:18:37 or both 19:18:40 but yeah, maybe he dropped reference headers 19:21:24 as for updating task status, i guess it depends 19:21:32 #topic In Progress Work 19:21:46 A bunch of your stuff landed SotK :) 19:21:57 I noticed, thanks for the reviews! 19:22:01 in that particular case we spent a while trying to figure out why there were a lot more active stories in storyboard-dev for requirements when there was only one open in lp 19:22:18 before i noticed that most of them had been resolved before the second migration run 19:22:32 made it hard to compare the state between the test import and what was in lp 19:23:07 Oh weeird 19:24:03 basically during an earlier test import they had been active, so when rerunning last week their active statuses weren't updated to be resolved 19:24:18 as the tasks already existed on sb-dev 19:24:56 That should be a simple thing to add. We would just want to check that the status in sb isnt already resolved and reset it to active 19:25:37 yeah, i don't know that it's a problem to be "fixed" so much as just a caveat to keep in mind when you're doing these 19:26:17 I could go either way 19:26:38 I don't think its that big a deal, but I can see how if it happens to a lot of stories, it could be a pain 19:26:44 well, one way doesn't involve needing to do anything ;) 19:27:15 I am almost always in favor of those ways unless there is some pressing reason to do otherwise 19:27:19 so i'm in favor of spending our effort wisely and just leaving it the way it is unless it becomes a serious problem 19:27:24 me too 19:27:30 Works for me :) 19:28:03 we've also had a couple more requests for making the project and project-group story list have smarter rules for inferred story state (not taking other projects into account when determining state) 19:29:50 mhmm, I think that should be fairly doable 19:29:59 as a workaround, i suggested using a task board with automatic lanes based on task states rather than stories 19:30:12 but that's obviously suboptimal 19:31:37 So if its completed in a project show it as done there and if its being shown in a project group and they aren't all done show it as active? 19:32:31 basically in the project story listing ignore the states of tasks for other projects, and in the project-group story listing ignore the states of tasks for any projects not in that project-group 19:32:40 at least i find that an easier way to reason about it 19:32:47 Okay 19:32:53 I think that makes sense 19:32:55 yep, that's how I've understood it 19:34:21 dhellmann pointed out an issue earlier too, where stories with many comments become a bit unusable in the webclient 19:35:25 yeah, we dropped pagination a while back to avoid confusion, but that brings new problems if you have a story with >1k comments 19:35:50 Popular story :) 19:35:56 A release goal I would guess? 19:36:01 popular with his script anyway 19:36:04 Even > 100 comments ends up being noticeably slow. 19:36:10 the py3k-first release goal, yeah 19:37:02 looks like mordred was talking in #storyboard about updates to make it less painful 19:37:12 but also 'is not really here right now' 19:37:33 I think that's pretty much the next thing I'm going to work on fixing after I've finished the project groups by name thing I've started 19:37:58 and then after that probably writing a spec for attachments 19:38:12 unless anyone beats me to it of course :) 19:38:14 he had also mentioned that the lack of separation between a story state for only "todo" tasks and a story state with an assorted mix of task states made finding untriaged stories harder (at least i think it was dhellmann who pointed that out) 19:38:44 oh yeah, I think it was 19:39:15 it probably makes sense to look at that at the same time as improving how story state is determined when browsing by project/project group 19:39:22 There is probably scope for having a richer list of story states (derived from the small set of task states). 19:39:45 yeah, for that, there were some nuanced combinations of states we probably wanted to take into account, so having some sort of matrix might make it easier to reason through 19:39:46 Key to a larger list is not actually letting it be set manually, to avoid the "too many choices" problem. 19:42:11 Do there exist any stories of how people did that sort of thing with LP, or did people not usually use bugtasks in LP? 19:42:54 the discussion about it is in the irc logs from the 5th and 6th of August 19:43:08 ah now I can link it because I have the internet again 19:43:15 http://eavesdrop.openstack.org/irclogs/%23storyboard/%23storyboard.2018-08-06.log.html 19:43:34 and also http://eavesdrop.openstack.org/irclogs/%23storyboard/%23storyboard.2018-08-05.log.html 19:44:45 * fungi is jealous of SotK's internet access returning 19:45:06 heh 19:46:08 I'm happy if we just address the states discussed in those logs for now 19:46:25 maybe there would be value in a "Review" state when all tasks are in review too 19:46:55 I like the idea of mirroring the task status when all tasks are in the same status (or invalid+that status). 19:47:02 persia: we use bugtasks in lp a lot... i think it's a combination of the fact that lp doesn't have non-project-specific lists of bug and it treating bugtask states as a priority ordered list so just displayed the highest state value of those across the various series bugtasks present for that project 19:48:21 fungi: https://bugs.launchpad.net/bugs/+bugs exists, but I agree that nobody ever uses it. 19:48:23 new>triaged>confirmed>in-progress>merged>released>opinion>wont-fix>invalid or something like that 19:48:47 * SotK is happy with mirroring too, re-reading those logs I'm a bit concerned that "new" has unwanted meaning for that context 19:48:50 ahh, yes i've used the non-project-specific bug listing option so infrequently that i didn 19:48:56 't realize it existed at all 19:49:23 SotK: sure, i like "todo" for that instead 19:49:27 * persia has been using that bug tracker since before it was called "Launchpad", and so remembers lots of special bits that probably should have been removed from the interface years ago 19:50:05 *cough* blueprints *cough* 19:50:23 One of the features I like about mirroring is that it is amenable to gaming. For example, if one wants to have "TODO" be untriaged and "Active" be triaged, one can create a task "triage this" and mark it complete. 19:50:45 wfm 19:50:49 blueprints is actually an entirely different project that was put into LP. Also, yes :) 19:52:21 yeah, i got a ton of backstory on how blueprints was developed and shoehorned in, none of which is likely germane to this discussion ;) 19:52:54 Also yes :) 19:53:48 heh 19:53:53 anything else in progress? 19:54:22 Some of fatema_ 's stuff needs reviews 19:54:38 Other than that- not really 19:55:15 oh, I'd be really happy if https://review.openstack.org/#/q/status:open+project:openstack-infra/storyboard-webclient+branch:master+topic:bugfixes can get some reviews so that I can pad out the update email I've been drafting with more things 19:55:48 https://review.openstack.org/#/c/589663/ would also be good to get merged if someone that isn't diablo_rojo has time to review it 19:56:08 * SotK plans to look at fatema_'s patches in his next reviewing session 19:56:39 * diablo_rojo adds bugfixes reviews to the list 19:57:27 thanks SotK 19:57:38 Is there time for questions ? 19:57:42 sure 19:57:47 #topic Open Discussion 19:57:56 3 minutes :) 19:58:03 :D 19:58:09 https://review.openstack.org/#/c/423876/ for this one 19:58:35 Is there a way to pick it up? 19:58:53 Is it worth doing? 19:59:11 I want to add simplejson to make it possible to use arrow function in coding 19:59:26 Alternately, is there another way to cause those requirements to apply iff the migration script is run? 19:59:29 if it's worth restoring, any core reviewer should be able to set it to restored state 19:59:47 well in the discussion http://eavesdrop.openstack.org/irclogs/%23storyboard/%23storyboard.2017-01-23.log.html 20:00:00 For clarity, my opposition is only to LaunchpadLib: I have no objection to simplejson. 20:00:22 persia, that's fine by me 20:00:29 we're out of time, lets continue in #storyboard 20:00:34 #endmeeting