| *** openstackgerrit has quit IRC | 00:18 | |
| *** openstackgerrit has joined #storyboard | 00:19 | |
| *** r1chardj0n3s is now known as r1chardj0n3s_afk | 00:49 | |
| *** r1chardj0n3s_afk is now known as r1chardj0n3s | 01:30 | |
| *** timrc is now known as timrc-afk | 01:37 | |
| *** r1chardj0n3s is now known as r1chardj0n3s_afk | 01:51 | |
| *** r1chardj0n3s_afk is now known as r1chardj0n3s | 03:37 | |
| *** mrmartin has joined #storyboard | 06:12 | |
| *** r1chardj0n3s is now known as r1chardj0n3s_afk | 06:28 | |
| *** reed has quit IRC | 06:39 | |
| *** openstackgerrit has quit IRC | 06:49 | |
| *** openstackgerrit has joined #storyboard | 06:49 | |
| *** alexismonville has joined #storyboard | 07:57 | |
| *** jtomasek has joined #storyboard | 08:03 | |
| *** alexismonville has quit IRC | 08:14 | |
| *** jcoufal has joined #storyboard | 08:31 | |
| *** mrmartin has quit IRC | 08:32 | |
| *** MaxV has joined #storyboard | 08:41 | |
| *** alexismonville has joined #storyboard | 08:47 | |
| *** jedimike has joined #storyboard | 08:56 | |
| openstackgerrit | Merged openstack-infra/storyboard: Workflow documentation is now in infra-manual https://review.openstack.org/139432 | 08:58 |
|---|---|---|
| *** mrmartin has joined #storyboard | 09:59 | |
| *** MaxV has quit IRC | 10:06 | |
| *** MaxV has joined #storyboard | 10:13 | |
| yolanda | jedimike, is dropdown of task assignee working for you using the mouse? | 10:56 |
| yolanda | looks as only work for me when using keyboard | 10:57 |
| jedimike | yolanda, I can click on the names, yeah | 10:57 |
| yolanda | but when you click , the assignee is reflected on the task? i'm loosing that | 10:58 |
| jedimike | yolanda, i'll try assigning one of my tasks to you and then back to me, one minute... | 10:58 |
| jedimike | yolanda, ah, you're right, it's broken. Also, you appear in the list twice :) | 10:58 |
| yolanda | jedimike, yes, it's always been like that, not sure why | 10:59 |
| yolanda | i may have 2 launchpad ids | 10:59 |
| yolanda | ok, i'll file the story, i corrected something similar few time ago | 11:00 |
| yolanda | jedimike, i have few reviews pending from storyboard, could you take a look? after your spec :) | 11:01 |
| jedimike | yolanda, haha, i'll take a look when I'm finished this section, if you want to wait until after them spec it might be next week ;) | 11:02 |
| yolanda | noooo | 11:02 |
| jedimike | I'm just writing up how the simpler markers are generated when a snapshot is taken, 20 minutes tops :) | 11:02 |
| yolanda | i wrote a new one for nodepool now, was quick to write, but i was thinking about it all night | 11:03 |
| jedimike | ok, some fancy sql written :) yolanda, do you have links to your reviews? | 11:24 |
| yolanda | jedimike: https://review.openstack.org/137798, https://review.openstack.org/138389, https://review.openstack.org/139100 | 11:25 |
| * jedimike goes to review | 11:28 | |
| yolanda | thx | 11:30 |
| jedimike | yolanda, just to make sure I understand the task status summary - the api would give back an array of TaskStatusCount models? | 11:35 |
| yolanda | yes, basically i wanted to return a list with state:count | 11:35 |
| yolanda | i didn't figure a better way to do it with pecan, looks as for any compount type you need to define a model, do you know a better way? | 11:36 |
| jedimike | yolanda, no, that looks like a good solution to be because the client gets the raw data and can present it any way the view wants to. If we presented it as a "key:value" string, the client would have to parse the values out of that | 11:37 |
| jedimike | so this looks good to me :) | 11:37 |
| yolanda | jedimike, my fear there is that the result was a bit noisy, lots of taskstatuscount objects | 11:37 |
| jedimike | yolanda, there's an argument to be made that a client doesn't need them, and can do that transformation itself because it can ask for the list of statuses from the api | 11:39 |
| jedimike | hmmm | 11:40 |
| yolanda | jedimike, but it needs the count of each task status to present it in the frontend | 11:40 |
| jedimike | yolanda, yes, but it already has those. So the original story summary has a column for each task status, and the count in that column, yeah? So if the client can ask the api for a list of task statuses, the client can extract the columns for display easily | 11:41 |
| yolanda | jedimike, but how can you match them? can we ensure that we are returning the values in the same order as in the list task status api? | 11:42 |
| jedimike | yolanda, so the story summary names the columns after the status, doesn't it? So you'd have a column called "ToDo" or something, and it would have the number of To Do tasks in it? | 11:43 |
| yolanda | jedimike, no, it should only be returning key, count, not the nsame | 11:44 |
| yolanda | name | 11:44 |
| jedimike | can you paste what the story summary looks like without the transform? | 11:44 |
| jedimike | just so i'm not making a mistake figuring out what the key is :) | 11:45 |
| yolanda | jedimike, so the final result is something like [['key':'review', 'count':1], ['key':'todo', 'count':2]] | 11:45 |
| yolanda | not the label | 11:45 |
| jedimike | yolanda, ok, maybe I've misunderstood how _story_build_summary_query works. What columns do you get back from that? | 11:47 |
| jedimike | because it looks to me that the label for the columns is the task status | 11:48 |
| yolanda | jedimike, the full story details, then the story count as i told you, and then a calc about the general story state | 11:48 |
| jedimike | yolanda, but you're specifying the label for each count column as the task status itself, which means you'd have a column called "To do" and the count of the To Do tasks in there, yeah? | 11:49 |
| yolanda | jedimike, not the label itself but the key | 11:51 |
| jedimike | oh, the pk of the task status? | 11:51 |
| yolanda | task status returns [['todo', 'Todo'], ['review', 'Review']] etc... | 11:51 |
| yolanda | so yes, it's just the key to reference it | 11:51 |
| jedimike | ok, so if the client asks the api for the task statuses, it should get that key back too, which means it can use that key to extract the count and doesn't need the summary | 11:52 |
| yolanda | iedimike, but the initial api was already doing that, in the story it was extracting the task count summary | 11:53 |
| yolanda | so i just left that the same, but using variable statuses | 11:53 |
| yolanda | that's output from the story api | 11:54 |
| yolanda | {"status": "active", "task_statuses": [{"count": 1, "key": "review"}, {"count": 2, "key": "todo"}, {"count": 0, "key": "invalid"}, {"count": 1, "key": "merged"}, {"count": 1, "key": "inprogress"}], "description": "add a new story 1", "title": "I update the test story", "created_at": "2014-11-18T09:06:20", "updated_at": "2014-11-21T13:57:49", "is_bug": true, "creator_id": 1, "id": 1} | 11:54 |
| jedimike | yeah, and now that the task statuses are dynamic, the api is adding a column for each task status with the summary in, and I think that's all the api should do. Generating a summary is the job of the client - the data has already been put there by the api, the client just needs the list of task statuses to generate the summary, and it can ask the api for that | 11:55 |
| yolanda | so it's using the key to associate with the right label we get on the task status api | 11:55 |
| jedimike | yolanda, perfect, so if i have the list of task status keys, I can extract everything I need from that on the client side | 11:56 |
| yolanda | jedimike, but to calculate the summary there, then you need to have a call to return all the tasks belonging to a story | 11:56 |
| yolanda | and that's worse | 11:56 |
| jedimike | no, you can do it from what you pasted there | 11:56 |
| jedimike | so I ask the api for the list of task statuses, I do that once, and I have the key and label for each task status | 11:56 |
| yolanda | yes, i do it like that | 11:56 |
| jedimike | then, when I render each story, I know what status key goes with what label, and I can loop round "task_statuses" from what you pasted ^^ and extract the counts | 11:57 |
| jedimike | no extra api calls | 11:57 |
| jedimike | and no extra work on the api side | 11:57 |
| yolanda | jedimike, yes, that's the idea | 11:57 |
| jedimike | ah | 11:57 |
| jedimike | hang on | 11:57 |
| jedimike | what does that json look like if you *don't* generate the summary? | 11:58 |
| jedimike | can you paste that? | 11:58 |
| yolanda | we always generate the summary | 11:58 |
| jedimike | yes, and the summary generated is deleting columns from the results. Can you paste it without doing that? | 11:58 |
| yolanda | {"status": "active", "review": 1, "todo":1, "description": "add a new story 1", "title": "I update the test story", "created_at": "2014-11-18T09:06:20", "updated_at": "2014-11-21T13:57:49", "is_bug": true, "creator_id": 1, "id": 1 | 12:00 |
| jedimike | perfect! Now if the client has the status keys, it can just reference the "todo" attribute | 12:00 |
| *** alexismonville has quit IRC | 12:01 | |
| jedimike | if the status doesn't appear in the record, it knows it's a 0 | 12:01 |
| yolanda | jedimike, yes, but then you are returning variable columns on the api, i mean, don't having a standard signature | 12:03 |
| yolanda | it will be returning different results depending on the statuses you have configured | 12:03 |
| yolanda | that's what i didn't like and the reason for grouping that | 12:03 |
| jedimike | yeah. by the way, I'm not saying we *should* do it this way, just exploring it so if someone else asks why it's done this way on the review, there's an answer ;) | 12:05 |
| yolanda | ok, i like to have an api well defined and with expected fields, so that's the reason | 12:05 |
| yolanda | you can add the question in the review and i answer there so we reflect the conversation | 12:05 |
| jedimike | yolanda, cool :) I think having expected fields is a good reason to do the summary in the api, I'll ask the question, you can reply, and I'll +1 :D | 12:07 |
| yolanda | nice | 12:08 |
| jedimike | haha sorry for dragging that out, just wanted to make sure I'd thought about it properly before +1'ning it ;) | 12:08 |
| yolanda | jedimike, was a nice discussion | 12:08 |
| jedimike | yolanda, I get on edge with those type of discussions sometimes, I don't want people to think I'm having a go at them, I just like to explore options out loud - helps me understand :) | 12:11 |
| yolanda | it's an useful thing | 12:11 |
| jedimike | ok, comment added :) | 12:12 |
| yolanda | replied | 12:13 |
| jedimike | and +1'd :) | 12:13 |
| jedimike | ok, getting something to drink before the next one, haha | 12:13 |
| yolanda | that was hard :) | 12:14 |
| yolanda | but i still feel more comfortable with python and pecan than with angular | 12:15 |
| *** mrmartin has quit IRC | 12:22 | |
| *** jcoufal has quit IRC | 12:25 | |
| *** jcoufal has joined #storyboard | 12:27 | |
| *** jcoufal has quit IRC | 12:28 | |
| *** jcoufal has joined #storyboard | 12:29 | |
| *** mase_x200 has joined #storyboard | 12:31 | |
| jedimike | yolanda, https://review.openstack.org/#/c/137798/2/src/app/dashboard/controller/dashboard_controller.js that's an interesting change! Is that something to do with the circular dependencies? | 12:41 |
| yolanda | checking | 12:50 |
| yolanda | oh, let me amend it :) | 12:50 |
| yolanda | that's derived from testing | 12:51 |
| yolanda | not really a change, but essay/error tries | 12:51 |
| *** alexismonville has joined #storyboard | 12:55 | |
| yolanda | jedimike, btw, the task status frontend won't be merged until the story count lands, it needs some work on it as well | 13:23 |
| yolanda | i'll put a -1 in workflow | 13:23 |
| openstackgerrit | yolanda.robla proposed openstack-infra/storyboard-webclient: Retrieve task statuses from the backend https://review.openstack.org/138389 | 13:26 |
| jedimike | yolanda, no problem, i put my +1 there anyway | 13:29 |
| yolanda | thx | 13:29 |
| openstackgerrit | yolanda.robla proposed openstack-infra/storyboard-webclient: Read user preferences from backend https://review.openstack.org/137798 | 13:35 |
| ttx | Branch support spec draft @ https://review.openstack.org/#/c/139613/ | 13:39 |
| ttx | Milestone support spec draft @ https://review.openstack.org/#/c/139626/ | 13:39 |
| yolanda | cool, new specs! | 13:45 |
| ttx | I'm not feeling particularly wordy today, so maybe I don't make a lot of sense :) Consider that a first draft. | 13:46 |
| yolanda | ttx, looks as friday is the day for write specs, jedimike and me have been working a bit on it as well :) | 13:46 |
| ttx | it is specs day for me, yes. | 13:46 |
| jedimike | all my specs are first drafts :) unless people like them, then they're final ;) | 13:47 |
| *** jcoufal has quit IRC | 14:00 | |
| *** miqui_ has joined #storyboard | 14:04 | |
| *** mattfarina has joined #storyboard | 14:20 | |
| jedimike | openstack-infra/infra-specs: Result set management and paging specification https://review.openstack.org/139638 | 14:31 |
| jedimike | it's... not a simple one, I don't think | 14:32 |
| jedimike | and with that, i'm going to get lunch :) | 14:32 |
| *** mrmartin has joined #storyboard | 14:45 | |
| yolanda | jedimike going to review | 14:50 |
| *** mase_x200 has quit IRC | 14:53 | |
| *** Piet has joined #storyboard | 15:21 | |
| *** reed has joined #storyboard | 15:34 | |
| *** ssam2 has joined #storyboard | 16:00 | |
| *** Piet has quit IRC | 16:11 | |
| *** mrmartin has quit IRC | 17:07 | |
| *** Piet has joined #storyboard | 17:25 | |
| *** MaxV has quit IRC | 17:28 | |
| *** mrmartin has joined #storyboard | 18:09 | |
| *** gothicmindfood has quit IRC | 19:19 | |
| *** gothicmindfood has joined #storyboard | 19:25 | |
| *** zaro has joined #storyboard | 19:35 | |
| *** alexismonville has quit IRC | 19:43 | |
| *** mrmartin has quit IRC | 19:57 | |
| *** ssam2 has quit IRC | 20:01 | |
| openstackgerrit | Merged openstack-infra/storyboard-webclient: Workflow documentation is now in infra-manual https://review.openstack.org/139433 | 20:18 |
| *** r1chardj0n3s_afk is now known as r1chardj0n3s | 21:30 | |
| *** mattfarina has quit IRC | 21:57 | |
| *** Piet has quit IRC | 22:10 | |
| *** timrc-afk is now known as timrc | 23:01 | |
| *** jedimike has quit IRC | 23:37 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!