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