16:01:59 #startmeeting storyboard 16:02:00 Meeting started Mon Mar 23 16:01:59 2015 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:01 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:02:03 The meeting name has been set to 'storyboard' 16:02:04 o/ 16:02:07 o/ 16:02:19 Our agenda at https://wiki.openstack.org/wiki/StoryBoard#Agenda 16:02:24 jeblair: around? 16:02:43 #top�c Actions from last week 16:02:47 o/ 16:03:00 hi 16:04:01 Babysit https://review.openstack.org/#/c/158434/ through gate to fix JS draft (done) 16:04:16 so it's fixed now, woohoo 16:04:27 #topic Urgent items 16:04:46 None where reported pre-meeting... Anything anyone wants to raise now ? 16:04:54 o/ 16:05:05 i still think the paging issue is urgent 16:05:19 i'm just not good at updating wiki pages, sorry 16:05:25 https://review.openstack.org/#/c/162126/ not very urgent, but we need to discuss tat 16:05:29 that* 16:06:02 there are two aspects -- first, the fact that you can't see more than X comments on a story, and second, that without logging in, you can't see more than Y stories at all 16:06:15 both of which we're spending time talking people through in the infra channel 16:06:27 jeblair: it's on the agenda, we can skip directly to that 16:06:35 oh, sorry 16:06:46 ttx: up to you 16:07:17 #topic Issue with paging (aka "lots of comments") 16:07:22 jeblair: please continue 16:08:10 well, that's about all i had. i put up a hacky change to at least return all the comments until there is proper paging support in the client 16:08:58 this second attempt to address the problem does not change the api and has big TODO notes in the code 16:09:21 er FIXME even 16:09:43 well, the workaround is so small and obvious, I dont's see much of an issue in it 16:11:06 krotscheck: you -1d the patch; do you want to discuss it? 16:11:13 The value of having is higher that waiting for a proper solution I think 16:11:35 Nope. My comments are clear: StoryBoard does not have enough resources to accept regressions at this time. 16:11:44 NikitaKonovalov: i agree -- it's a real problem 16:11:55 If you can hire more resources to contribute, great. 16:11:58 krotscheck: i don't think it's a regression; actually the opposite 16:12:05 You are welcome to disagree. 16:12:30 krotscheck: it's a half-implemented feature, but it doesn't work without both halves 16:12:45 I welcome patches that fill in the gap. 16:12:53 In fact, I'm working on them. 16:13:15 But I only have so much time in the day, and StoryBoard has ben deprioritized within HP, so I need to manage my time. 16:13:53 krotscheck: there's nothing irreversible about 162643; why not apply it now to make it more usuable, and revert it when the other patches are ready? 16:14:43 krotscheck: i understand, which is why i'm not asking you to reprioritize anything as much as accept this workaround temporarily until you do finish your work 16:15:06 krotscheck: I'll take the temporary fix orver the hypothetic feature completion at this point, especially if your work is parttime now 16:15:56 since I understand you can't promise any date anymore 16:16:47 I would be amenable to that if I see concrete progress towards allocating more resources towards StoryBoard, but at this point I have to draw a line on insiting that any new commits move the project forward, not back. 16:17:12 Incidentally, I'm aslo curious about what private conversations have been had regarding that. 16:17:20 Because it feels like I'm out of the loop. 16:17:49 nothing but the review as far as I'm concerned :) 16:18:00 krotscheck: our first priority is to the usability of the system, so i believe we need to merge this and fix later. this moves nothing back and it does not hinder forward progress on the javascript side. 16:18:16 jeblair: It's your prerogative as PTL to ignore my -1 16:18:48 krotscheck: understood 16:19:18 for those trying to keep track of the score at home: https://review.openstack.org/#/c/159515/ 16:20:00 ok, let's move on 16:20:04 ++ 16:20:22 #topic Manual data fix or migration with no downgrades 16:20:26 #link https://review.openstack.org/#/c/162126/ 16:20:57 Aleksey has a change here that will make current SB data potentially wrong 16:21:07 I insisted on a corresponding migration 16:21:38 Aleksey said he could do one but then the corresponding downgrade is not really doable 16:21:43 so yep, we've got stories mostly with ids < 20000 that lack some fields 16:21:49 ah, yeah, i think openstack in general is heading in the right direction by dropping downgrades 16:21:50 Doesn't the TC have a policy that says "no downgrades"? 16:21:56 so we could say that we don't care about downgrade (as the rest of openstack just decided) 16:22:10 Right. That. 16:22:10 so i think the right direction here is to have a correct upgrade and no downgrade 16:22:11 just making sure we all agree that's the right solution here 16:22:24 Works for me. 16:22:27 ok, we probably test downgrades somewhere so we'd have to disable that too 16:22:43 btw we may think of cleaning up some strange stories with no authors as well 16:22:44 we're doing database dumps and system backups of them, right? 16:22:52 or tasks with no projects 16:22:56 jeblair: you tell me :) 16:23:10 ttx: i will, was hoping someone else would confirm :) 16:23:41 yes, they are configured. 16:24:14 so looks like the migration should be harmless 16:24:17 ok, so no-downgrade sounds like the best way forward there 16:24:25 * ttx adds to review 16:24:47 if we're ever really worried about a migration, we can ask infra-root to double check we have a recent working backup :) 16:25:08 or even excecute a special off-schedule database backup 16:25:21 ok, next topic... 16:25:30 #topic Email spooling implementation 16:25:39 #link https://review.openstack.org/#/c/151413/ 16:25:52 That's another long line of patches blocked by disagreement on a review 16:26:13 Well, I was hoping to get the whole story committed. 16:26:22 Jim thinks we should not be in the business of writing an email spooler 16:26:22 As in, all the patches up so that my argument could be made in code. 16:26:37 and therefore -1ed the head patch 16:26:45 But priorities. 16:26:46 Anyway 16:27:05 The entire concept is that I wanted to separate the thing that renders the email, and the thing that sends the email. 16:27:06 krotscheck: the danger there is that the disagreement is fundamental, and i would not want you to write unecessary code 16:27:34 Because lots of things could go wrong in either step, and I'd rather not make one break cause the whole system to fall apart. 16:27:47 The 'Outbox' use is just a convenient library that happend to provide a sane way of storing rendered emails. 16:28:09 Which I feel makes it look like a spooler. 16:28:27 But, well, there's lots of different emails that StoryBoard is likely to send in the future. 16:28:39 And lots of different processes that might send them. 16:28:52 On this one I'd say that the incremental improvement would be to accept the patch -- even if I argue that this may be a bit too much technical debt and reinvention. But then it's written now. 16:29:42 i feel pretty strongly that the world has developed a number of competent MTAs, and storyboard does not need to implement another one. 16:30:02 some of the code may be written, but not all of it. and my objections were made over a month ago and ignored 16:30:24 jeblair: not ignored. I clearly stated that I wanted to make sure all the patches were in before engaging in that discussion 16:30:50 Please do not misrepresent me. 16:30:59 krotscheck: as you can see, that makes it much harder to have a conversation about whether this is entirely the wrong direction. 16:31:21 You're welcome to submit a counterargument via patches. 16:31:43 krotscheck: that's not the way code review works 16:31:51 Would you like to take over the email feature? It feels like you have a strong opinion on how that should be handled. 16:32:49 krotscheck: could you perhaps write a narrative for your vision of this so that you don't have to completely implement the feature in order for us to discuss it? 16:33:54 That works for me. 16:34:12 Do we have a spec for that ? 16:34:44 krotscheck: could use a spec or an infra thread, whatever is the most comfortable medium 16:34:51 ++ 16:36:58 Shall we move on ? 16:37:13 wfm 16:38:21 ok, moving on? 16:38:33 #topic "Pagination/search" feature priority and proposed implementation 16:38:54 so there was some diagreement on the need/priority/implementation for this when we reviewed the Roadmap a couple weeks ago 16:39:03 trying to find logs 16:39:37 NikitaKonovalov said pagination and search https://review.openstack.org/#/c/139638/ should be added somewhere 16:40:16 * krotscheck was not aware of that spec. 16:40:19 then jeblair said he doesn't really want pagination at all 16:41:10 I commented on that spec that it felt a bit overkill 16:41:27 Pagination is necessary as a performance feature. Downloading massive datasets will directly impact client performance. 16:41:55 Some user's resilience to slowness is different than others. page size should be configurable by user. 16:41:59 krotscheck: sure, but isn't there a way to trigger next dataset loads when you scroll down ? 16:42:24 i.e. "infinite" scrolling rather than paging ? 16:42:35 krotscheck: i agree that api pagination makes sense for performance reasons 16:42:37 In some cases, eys. 16:42:59 ttx: It doesn't make sense in the case of search results. If you're searching, users usually refine their parameters rather than paging. 16:43:10 ttx: It does make sense in the case of comment threads or feeds. 16:43:24 ok 16:43:45 I guess I was worried when the specs creates a table to store user searches 16:44:00 Well, that's an entirely different issue. 16:44:01 just so that you can page through search results 16:44:04 krotscheck: we still may use paging for loading comments, just without scrolling part, 16:44:30 as you said, that feels overkill when most users would rather refine search aprameters than page 16:45:28 Well, this particular approach seems more geared at improving the performance of search queries. 16:45:49 Actually 16:45:59 So let's make a quick distinction here between search and browse. 16:46:25 In the case where someone's looking for something specific, they are searching, and thus more likely to refine terms. 16:46:36 Maybe that's what this spec is missing, this distinction 16:46:39 In the case of a browse, they want to see a consistent list of a subset. 16:46:49 Say: I want all things that are assigned to me. 16:47:01 If I have 100 things that are assigned to me, I'm going to want to page through that. 16:47:14 (If you're jeblair, you might not want to page through that ;) ) 16:47:35 So yeah, that distiction may be missing from the spec. 16:47:46 :) 16:48:45 As far as the implementation goes, the reason it's generating the result set and storing it is because there's a question on how you page through a dataset that is likely to change over the time it takes to page. 16:49:13 OK, so it looks like we could use more iterations on the spec 16:49:27 One "RESTful" approach is usally to ask the server to create a resultset, and then consume it. 16:49:41 (So a POST -> 304 -> GET) 16:49:53 Personally I don't think we should page in the story comments/timeline area 16:50:17 since the first and last items are equally interesting 16:50:39 ttx: I agree. Most of my changes in that area are contingent on https://review.openstack.org/#/c/160462/ 16:50:51 (WHich merged) 16:51:01 ok 16:51:14 (So that now we don't have to load all the things and then filte rin the UI) 16:51:32 I'm also working on preloading results when the request is made. 16:51:34 so it looks like the spec really needs to be more use-case oriented, becaus ea different solution may be needed for each case (comments list, search, browse) 16:51:47 Perhaps/ 16:51:54 yeah, "may" 16:52:45 Honestly, I think this approach, though dev overkill, addresses most of the use cases. 16:53:02 Not dev overkill. Sorry, that's charged. 16:53:53 Also, I might point out that jedimike hasn't been able to contribute much since he updated the spec in december. 16:54:16 * krotscheck feels this spec might be awesome, but ultimately not have anyone willing to build it. 16:54:41 yeah,ok 16:54:57 it may provide a public service in shaping thinking around it, even if it isn't immediately implemented 16:54:58 Switching to next topic 16:55:13 #topic In progress work 16:55:20 We have been updating the Roadmap as we go 16:55:26 https://wiki.openstack.org/wiki/StoryBoard/Roadmap 16:55:49 Good news is Tags are almost done, so the 1.2.1 targets are almost complete 16:56:01 the UI change is on review 16:56:08 and aripinen is tackling a lot of the 1.2.2 things 16:56:37 but it's not working properly, as there is some parameter misunderstanding with API 16:57:31 any other in-progress report ? 16:57:42 nothing new from me 16:58:01 Working on bringing paging into the UI. 16:58:37 ok, quick switch to open discussion for last 2 min 16:58:42 #topic Open discussion 16:58:47 Anything anyone ? 16:58:54 Also, I think we fixed the launchpad login problem. 16:58:54 Almost : https://review.openstack.org/165194 16:59:14 krotscheck: how did that manifest? 16:59:30 jeblair: User wh hasn't logged into launchpad tries to log into storyboard. 17:00:09 Has no username, can't log in. 17:00:23 cool, thx 17:01:54 ok, out of time 17:01:57 #endmeeting