| *** yuikotakadamori has joined #openstack-sprint | 00:03 | |
| *** baoli has joined #openstack-sprint | 00:06 | |
| *** baoli has quit IRC | 00:06 | |
| *** baoli has joined #openstack-sprint | 00:14 | |
| *** baoli has quit IRC | 00:15 | |
| *** baoli has joined #openstack-sprint | 00:33 | |
| *** baoli has quit IRC | 00:36 | |
| *** baoli has joined #openstack-sprint | 00:41 | |
| *** baoli has quit IRC | 00:42 | |
| *** baoli has joined #openstack-sprint | 00:54 | |
| *** rfolco has quit IRC | 00:56 | |
| *** baoli_ has joined #openstack-sprint | 01:02 | |
| *** baoli has quit IRC | 01:05 | |
| *** cdelatte has quit IRC | 01:38 | |
| *** baoli_ has quit IRC | 01:43 | |
| *** baoli has joined #openstack-sprint | 01:44 | |
| *** baoli has quit IRC | 03:19 | |
| *** baoli has joined #openstack-sprint | 03:23 | |
| *** baoli has quit IRC | 04:10 | |
| *** hieulq has joined #openstack-sprint | 07:09 | |
| *** yuikotakadamori has quit IRC | 08:25 | |
| ttx | Ohai | 08:33 |
|---|---|---|
| * ttx will dedicate next two hours to the StoryBoard sprint | 08:35 | |
| *** hieulq has quit IRC | 08:45 | |
| *** hieulq has joined #openstack-sprint | 09:06 | |
| *** zhenguo_ has joined #openstack-sprint | 09:25 | |
| SotK | hey ttx :) | 09:29 |
| *** hieulq has quit IRC | 09:30 | |
| ttx | SotK: Trying to fix a UI glitch. Did I mention I hate CSS ? | 09:36 |
| Zara | :) | 09:38 |
| SotK | heh, join the club! | 09:38 |
| Zara | hm, there's a note in the backscroll that the gerrit integration means that tasks update status. As far as I know, this isn't yet implemented; the integration means that gerrit can post comments on stories. | 09:50 |
| Zara | ah yeah, http://eavesdrop.openstack.org/irclogs/%23openstack-sprint/%23openstack-sprint.2016-06-22.log.html#t2016-06-22T19:48:31 | 09:54 |
| Zara | so stories only have a status as a function of their constituent tasks | 09:54 |
| Zara | so the idea is to get the task status to update from gerrit | 09:54 |
| Zara | using the task id as an identifier. The story is here: https://storyboard.openstack.org/#!/story/2000012 | 09:56 |
| ttx | SotK: see my comment on that review... I did not find teh right solution I fear | 10:13 |
| ttx | And that burnt my whole sprint time :/ | 10:14 |
| ttx | That's what I get for pretending to know what I'm doing | 10:15 |
| Zara | hahaha, thanks for your help, I'll look in a bit (and thanks for reviewing, too!) | 10:35 |
| Zara | I never have any idea what I'm doing. \o/ | 10:36 |
| *** rfolco has joined #openstack-sprint | 11:53 | |
| ttx | Hm, that one should look better | 12:05 |
| SotK | ttx: looks good, thanks! | 12:54 |
| ttx | SotK: only drawback is that all events now take the full width. I've been trying to work around that unsuccessfully | 12:54 |
| ttx | probably needs some extra div container so that width limits the outside container but the text with the border inside can potentially be smaller | 12:55 |
| *** baoli has joined #openstack-sprint | 13:01 | |
| SotK | maybe setting max-width rather than width would work? | 13:02 |
| *** david-lyle_ has joined #openstack-sprint | 13:32 | |
| *** baoli_ has joined #openstack-sprint | 13:33 | |
| *** baoli has quit IRC | 13:35 | |
| *** david-lyle has quit IRC | 13:36 | |
| *** baoli_ has quit IRC | 14:19 | |
| *** baoli has joined #openstack-sprint | 14:21 | |
| *** baoli has quit IRC | 14:43 | |
| *** baoli has joined #openstack-sprint | 14:48 | |
| *** baoli has quit IRC | 14:52 | |
| *** baoli has joined #openstack-sprint | 14:54 | |
| *** david-lyle_ is now known as david-lyle | 14:59 | |
| *** baoli has quit IRC | 15:15 | |
| *** baoli has joined #openstack-sprint | 15:23 | |
| *** baoli has quit IRC | 15:23 | |
| *** baoli has joined #openstack-sprint | 15:25 | |
| anteaya | ttx: thanks for helping with teh sprint | 15:55 |
| anteaya | Zara: yes, zaro wants additional information on what the gerrit storyboard plugin should do | 15:55 |
| anteaya | it was important to me that it be functioning for yesterday and today so we could at least have a common understanding of current functionality | 15:56 |
| anteaya | also, which I do believe that any measure of gerrit storyboard interaction is necessary to migrate everyone to storyboard I'm not convinced the task update status needs to be in place on the plugin as a blocker to migration | 15:57 |
| anteaya | so for my money, as far as what is needed from gerrit storyboard integration in order to migrate, I think we are there | 15:57 |
| anteaya | we can tweak the plugin after the migration in my book (or whilst the decisions are being made) | 15:58 |
| Zara | okay, thanks for clarifying :) | 16:06 |
| anteaya | :) | 16:12 |
| zaro | yup, change id are currently linked to a story. I guess it might make more sense to link it with a task? | 16:14 |
| Zara | yeah, I think so | 16:15 |
| zaro | So maybe you can think about how that would work? | 16:15 |
| Zara | there was a bit here: https://storyboard.openstack.org/#!/story/2000584 | 16:16 |
| zaro | i mean what should happen when a comment is made in a gerrit change? | 16:16 |
| Zara | (or one option is to be able to list either story or task, and use the former for comments, the later for status changes) | 16:16 |
| zaro | just my opinion but that might be over complicated for users | 16:17 |
| zaro | confusing more than complicated | 16:18 |
| Zara | yeah, an alternative would be to derive the story id from the task, since a task can't be in multiple stories | 16:18 |
| Zara | it should be possible to do it that way, more work to implement and I haven't yet thought much about the implementation for that on the plugin side | 16:18 |
| zaro | that should be possible as long as there's an rest api for to do that | 16:19 |
| zaro | can't there be mutiple stories related to a task? | 16:21 |
| Zara | no. a story can be related to multiple projects, and a story can contain multiple tasks | 16:21 |
| Zara | but each task will only be in one story | 16:21 |
| Zara | is https://storyboard.openstack.org/api/v1/tasks helpful at all? | 16:22 |
| zaro | yes, that would work. | 16:23 |
| zaro | what about api to get a single task? | 16:23 |
| Zara | something like https://storyboard.openstack.org/api/v1/tasks/1 ? | 16:25 |
| zaro | looks good. probably all we need then. | 16:27 |
| Zara | \o/ | 16:27 |
| zaro | what's the transition you would expect? for example new patch for task 1 should do what? | 16:27 |
| Zara | so, that's why I made the storyboard bot example thing, https://review.openstack.org/#/c/302912/4/storyboardclient/v1/storyboard_bot.py . the mapping is roughly okay | 16:28 |
| Zara | the code is horrible, but that should show what should happen-- though one thing is that that currently replaces task notes with the commit message, whereas I'd rather append it | 16:29 |
| Zara | so, new patch for task 1, task 1 changes status to review and has the commit message appended in the task notes | 16:29 |
| Zara | the task notes might get a bit weird after a while but eh, first pass | 16:29 |
| zaro | that's all that task notes should contain? what if sb user manually changes notes? | 16:33 |
| zaro | hmm, how does a user even find a task id? i don't see any references to task ids from UI or url. | 16:34 |
| Zara | that's why I want it to append them, rather than replace them, so the manually-added notes are kept. it does mean they'll end up with a lot of noise where a patch is updated a lot, so if that's going to be annoying then I'm fine with it not updating them at all (or if someone thinks of something better, go for it, but that was as far as I got) | 16:35 |
| Zara | ah, yeah, I have a patch for displaying task ids in the ui | 16:35 |
| Zara | I think it needs a rebase, it's old | 16:35 |
| Zara | atm there's no nice way to do it, gimme a sec | 16:35 |
| zaro | ok, well. i think that's a requirement before changing from linking story to taskid | 16:36 |
| Zara | yes, agreed. | 16:37 |
| zaro | you think you want gerrit plugin in place before or after changing links from story to task id? | 16:37 |
| SotK | I would append a link to the gerrit change rather than the commit message | 16:39 |
| zaro | SotK: you mean task notes? | 16:41 |
| SotK | yeah | 16:42 |
| SotK | appending the commit message each time seems like duplication for no reason | 16:42 |
| pleia2 | does lp have things like this? I'd make it as similar to lp as possible | 16:42 |
| zaro | lp doesn't have tasks, issues in lp are equivalent to stories i believe | 16:43 |
| zaro | so currently it really is equivalent to what lp does | 16:43 |
| zaro | except for the auto transition part | 16:43 |
| SotK | I'd also update the task status to "review" when a patch is sent, "todo" when a patch is abandoned (maybe some syntax in abandonment message to make it invalid instead, but that is a stretch goal), and "merged" when a patch is merged | 16:44 |
| zaro | SotK: yeah, we are talking about how we can get to a point where we can map transitions. looks like there's a critical missing right now. namely, how do SB users even find task ids to add to their commit message? | 16:46 |
| pleia2 | lp does have tasks, let me see if I can find one with them | 16:48 |
| fungi | well, lp has "tasks" which roughly correspond to a project and optionally a series | 16:49 |
| zaro | pleia2: difference is that transitions happen on issues, not tasks? | 16:49 |
| * pleia2 tried to load tasks, gets a timeout error \o/ | 16:49 | |
| Zara | https://review.openstack.org/#/c/272667/ there, rebased | 16:49 |
| fungi | it's how you can make a bug "affect" multiple projects, or multiple branches/releases | 16:49 |
| anteaya | zaro: good question, the only way I know of finding the task id is by querying the api for all tasks on a story `story/11/tasks` then looking for the last id output in returned values | 16:49 |
| anteaya | it isn't labelled task_id, just id as is story | 16:49 |
| fungi | but lp lacks the idea of multiple tasks for the same project+series afaik | 16:49 |
| pleia2 | fungi: ah yes | 16:50 |
| Zara | zaro: https://review.openstack.org/#/c/272667/ the patch I mentioned, now with extra rebase. | 16:50 |
| Zara | yeah, would prefer to link url in the notes, not commit message, sorry. | 16:51 |
| fungi | here's a recent security bug with multiple tasks (assuming you reload enough times to not have lp time out on you like it did to me) https://launchpad.net/bugs/1490804 | 16:51 |
| openstack | Launchpad bug 1490804 in OpenStack Identity (keystone) kilo "[OSSA 2016-005] PKI Token Revocation Bypass (CVE-2015-7546)" [High,Fix committed] | 16:51 |
| Zara | SotK: that matches the mapping in the proof of concept bot, yay | 16:52 |
| * fungi shakes fist at lp timeouts | 16:52 | |
| fungi | there we go | 16:52 |
| anteaya | that worked? yay! | 16:52 |
| fungi | so you can see tasks for keystone (master and kilo), security advisories/notes, and several libraries | 16:52 |
| fungi | those are all "bugtasks" in lp's world | 16:53 |
| fungi | they can be assigned independently, with discrete status/importance and targeted at different milestones | 16:53 |
| fungi | the main improvement over that in the original sb design spec/poc was the idea that there could be a many-to-one relationship for tasks to projects in a story | 16:55 |
| zaro | fungi: we currently link to an LP bug so I believe jeepyb only automates transitions for bugs not tasks correct? | 16:56 |
| fungi | without having to create fixed "series" for the projects to apply each task to | 16:56 |
| fungi | zaro: sort of | 16:56 |
| fungi | zaro: jeepyb looks up the bug number referenced, then tries to map the project and branch for the change to an equivalent project and series for that bug in lp, then updates the corresponding task if there is one | 16:57 |
| zaro | ok, i guess we are talking about doing the same with SB then. lookup story from task id | 16:58 |
| zaro | update story if need and transition the task if needed. | 16:58 |
| fungi | the difference being, as i said, in sb there can be multiple tasks for any given project (getting rid of the series concept entirely there so branch mapping is irrelevant i think), so finding the right task might be hard | 16:58 |
| fungi | if i have a bug with two tasks for the openstack-infra/project-config repo and i merge a change to project/config referencing that story id, how do we know which task to change the status on? | 16:59 |
| zaro | you a human finding the right task to add to the git commit message? | 16:59 |
| fungi | right, if there are fixed task identifiers, we could solve that by specifying the task id in the commit message | 16:59 |
| anteaya | there are task ids | 17:00 |
| anteaya | each task has its own id | 17:00 |
| fungi | which is something we don't do in lp because the model is different | 17:00 |
| fungi | so just trying to outline the main distinction here as to why the finding algorithm we use in lp doesn't map directly to sb | 17:00 |
| anteaya | http://paste.openstack.org/show/521708/ output from curl https://storyboard.openstack.org/api/v1/stories/11/tasks | 17:01 |
| anteaya | fungi: ah thank you | 17:01 |
| anteaya | data from one task: {"status": "merged", "priority": null, "branch_id": 1, "title": "API Paging", "story_id": 11, "created_at": "2014-03-04T20:06:04+00:00", "updated_at": "2014-04-12T01:04:46+00:00", "assignee_id": null, "creator_id": null, "link": null, "milestone_id": null, "project_id": 456, "id": 15} | 17:02 |
| SotK | if you put the task id in the commit message you can just do `GET https://storyboard.openstack.org/api/v1/tasks/:id` and look at the "story_id" in the response, if you wanted the story ID for some reason | 17:02 |
| anteaya | so the id for that task is 15 and it has a story_id of 11 | 17:02 |
| fungi | this might be a clean way to go about it... if you see a story id in the commit message but no task id, and there is only one matching task for that project in that story, then assume that's the task to act on. if there are multiple tasks for that project in the referenced story, don't alter the tasks only leave story comments. if there is only a task referenced in the commit message, and the | 17:02 |
| fungi | project associated with the task matches the project for the change, assume that's the task to update and its corresponding parent story is where you should leave the comments | 17:02 |
| anteaya | fungi: that seems reasonable | 17:03 |
| anteaya | zaro: is that doable? | 17:03 |
| fungi | so we optimize for the typical case, and we have a safe fallback for the corner case with a more specific solution people can implement if they need to get granular | 17:04 |
| SotK | hm, I suspect we will need to be careful to check that someone hasn't put a story id when they meant to put a task id | 17:04 |
| zaro | it seems like it all can be driven with task id, not sure why we would need story id? | 17:04 |
| fungi | true, though for lp we mitigate typos by double-checking that the bug has a task associated with the project for the change | 17:05 |
| fungi | zaro: i guess we could mandate only matching the task id, however for bug migration purposes if we want to still link from historical changes to bug ids (which will be a 1:1 match for story ids during migration) then we still need the concept | 17:06 |
| zaro | bug id? are you refering to LP or SB? | 17:07 |
| fungi | so we could in theory just stick with story/bug ids as links in changes, but only actually update stories if there's a task mentioned in the commit message | 17:07 |
| fungi | if i say bug id i mean lp, but after migration we're going to have a bunch of changes that have commit messages saying things like "closes-bug: 1234" which we can link to story 1234 in sb | 17:07 |
| openstack | bug 1234 in Launchpad itself "Gina is an unmaintainable mess of command line options, environment variables and shell scripts" [Medium,Fix released] https://launchpad.net/bugs/1234 - Assigned to Daniel Henrique Debonzi (debonzi) | 17:07 |
| fungi | grrr | 17:08 |
| fungi | silly bugbot | 17:08 |
| anteaya | ha ha ha | 17:08 |
| fungi | basically trying to make sure that following links from old changes takes us to the migrated lp bugs which are now stories in sb | 17:09 |
| fungi | so that could just be a matter of updating our commentlinks regex for those, and the its-storyboard plugin for gerrit could only care about task ids | 17:10 |
| zaro | i see. makes sense | 17:10 |
| fungi | that's a pretty significant difference in behavior though, so merits some additional discussion in case others can think of issues with that i'm not seeing | 17:11 |
| zaro | i guess this means we should have everything on SB side to support task ids before installing its-storyboard plugin? | 17:12 |
| anteaya | fungi: can we perhaps add this as an item for next week's infra meeting? | 17:12 |
| anteaya | then we can get some agreement and move forward | 17:12 |
| zaro | i will be vacationing next week | 17:12 |
| anteaya | zaro: ah okay | 17:12 |
| fungi | for example, if there's an outstanding change proposed for bug nnnn, and then we migrate lp bugs into storyboard, and then that change lands it's not going to update sb to indicate that if we're only matching on task ids in the plugin. however that's an eventually consistent thing we can maybe just live with until it shakes out | 17:12 |
| anteaya | zaro: how long are you off? | 17:12 |
| zaro | until 7/4 | 17:13 |
| anteaya | are we having a meeting July 5th? | 17:13 |
| fungi | and if people really care about making sure the story for their outstanding change gets updated after the migration, they can always adjust their commit message with a new patchset to link the correct task id instead | 17:14 |
| pleia2 | I'll be around July 5th | 17:14 |
| anteaya | fungi: yeah I think our fallback is update it by hand | 17:14 |
| zaro | isn't next meeting 6/28? | 17:14 |
| fungi | anteaya: i'm having a meeting july 5th. anyone who wants to is free to join me, but if they have other things to do then that's (as always) perfectly fine | 17:14 |
| fungi | zaro: yep | 17:14 |
| anteaya | but yes do our best to integrate as a result of the move | 17:14 |
| anteaya | zaro: you said you are away next week | 17:15 |
| anteaya | zaro: so I asked about the week after | 17:15 |
| anteaya | I'm glad we are talking about it and getting ideas | 17:15 |
| zaro | ohh yeah, should be able to join then | 17:15 |
| anteaya | but it would be nice to say we'll decide at the latest on the 5th of July meeting | 17:15 |
| anteaya | great | 17:15 |
| anteaya | if we decide before, so much the better | 17:16 |
| anteaya | zaro: so does this seem doable to you? | 17:16 |
| fungi | so anyway, if it's easy to solve for that consistency issue in the plugin and allow people to use story ids for convenience indefinitely when they don't need to be specific about a task id, then great. if it's not trivial to accommodate then we can always put the onus on the people who care about it to either fix it or use less convenient workarounds | 17:16 |
| anteaya | I'm happy we have something in place, we already have at least one happy customer in #storyboard who feels the current interation is tight | 17:17 |
| anteaya | so I'm really pleased | 17:17 |
| fungi | we could also consider a syntax like "story: xxx:yyy" to indicate the task, rather than just going with a raw task id in a vacuum | 17:17 |
| anteaya | fungi: that would be interesting | 17:18 |
| zaro | yeah, i think it's doable. just need to merge zara's patch to locate task ids | 17:18 |
| anteaya | if two arguments the second is task id, if just one argument just story id | 17:18 |
| fungi | and punt to the easy case of just commenting on the story mentioned if the :yyy task suffix is missing, but update the task status if someone specifies the :yyy | 17:18 |
| anteaya | yeah | 17:19 |
| fungi | it's a less convenient syntax, but perhaps less ambiguous | 17:19 |
| fungi | anyway, this is all design bikeshed | 17:19 |
| zaro | it's probably easier to have two seperate links, story: xxx and task: yyyy | 17:19 |
| anteaya | I think it also informs the user of their options because of the design syntax | 17:20 |
| anteaya | zaro: oh | 17:20 |
| anteaya | zaro: well whatever you can put in place | 17:20 |
| fungi | yep, looking for separate headers would make sense as an alternative | 17:20 |
| anteaya | if we make it too hard, we don't get anything since you get busy with other things | 17:20 |
| fungi | right, i don't want to get overly specific on designing this, there are several ways to go about it and i'd rather the people doing the implementation pick solutions that address use cases they see as important in ways which make sense to them | 17:22 |
| anteaya | makes sense | 17:22 |
| zaro | Zara: can users get to a task from a url on the SB ui? | 17:22 |
| fungi | and i trust the people doing the development on sb and the plugin. they're all smart folks who make wise choices | 17:22 |
| anteaya | they have proven themselves to be | 17:24 |
| anteaya | question: Zara would like the api doc examples to point to the storyboard-dev server as opposed to the storyboard server, any thoughts or objections to that suggestion? | 17:24 |
| anteaya | zaro: I'm unable to navigate to a task using the task id in the url | 17:26 |
| anteaya | Zara: very pretty orange | 17:27 |
| zaro | so i guess action plan is to be able to identify task ids (zara's change) then make changes to its-storyboard to update (comments/transitions) tasks and related story. test on review-dev.o.o then install on review.o.o | 17:28 |
| zaro | does that sound about right? | 17:28 |
| anteaya | that workflow works for me | 17:28 |
| Zara | that sounds right to me :) (also yeah, I don't think it's possible to get to a task from an url on the ui) | 17:29 |
| zaro | that would be nice, but i guess probably not necessary for its-storyboard to do its thing. | 17:30 |
| anteaya | Zara: noone objects to your suggested use of storyboard-dev in the api doc examples so I'm going to get something to eat and then I'll make that change, thank you | 17:30 |
| Zara | \o/ | 17:30 |
| Zara | and thanks everyone for being so flattering! :D | 17:31 |
| anteaya | you are awesome | 17:31 |
| anteaya | as are SotK and pedroalvarez | 17:31 |
| anteaya | wooo team! | 17:31 |
| pleia2 | oh, I met one of their colleagues at an openstack event last week | 17:31 |
| anteaya | oh? | 17:32 |
| pleia2 | promptly forgot his name, because that's what I do | 17:32 |
| anteaya | describe him | 17:32 |
| pleia2 | white dude, taller than me | 17:32 |
| anteaya | what did he talk about? | 17:32 |
| Zara | uh oh. | 17:32 |
| pleia2 | he said he recognised me from the summit and said he worked with Zara and SotK | 17:32 |
| anteaya | was it Danny? | 17:33 |
| anteaya | dark hair, close cut | 17:33 |
| anteaya | large gentleman? | 17:33 |
| pleia2 | it was in SF, I think he's based somewhere around here? | 17:33 |
| pleia2 | could be | 17:33 |
| zaro | i'll need to know how to update a task status from REST api, doesn't look like that's in the documentation | 17:33 |
| anteaya | Danny has been in California since after summit | 17:33 |
| pleia2 | ok, probably him then :) | 17:33 |
| anteaya | zaro: key | 17:33 |
| pleia2 | he was nice | 17:33 |
| Zara | 7 ft lebanese guy? :D | 17:33 |
| Zara | if it's him, he goes by dabukalam on irc | 17:34 |
| anteaya | zaro: http://docs-draft.openstack.org/46/332946/14/check/gate-storyboard-docs/3b4578a//doc/build/html/webapi/v1.html#put--v1-stories--story_id--tasks | 17:34 |
| anteaya | zaro: here is the patch: https://review.openstack.org/#/c/332946/ | 17:34 |
| anteaya | zaro: as I say in the comment in the tasks file: Key is one of: "key": "review", "key": "todo", "key": "invalid", "key": "merged", "key": "inprogress" | 17:35 |
| anteaya | zaro: let me know if you need more | 17:35 |
| anteaya | pleia2: Danny is awesome nice | 17:35 |
| anteaya | it was likely Danny, persia you know and I don't know anyone else involved with codethink in attendance | 17:36 |
| anteaya | besides Zara and SotK | 17:36 |
| anteaya | pleia2: you have yet to meet pedroalvarez, who is awesome | 17:36 |
| pleia2 | indeed! | 17:37 |
| pleia2 | the in person storyboard sprints always sneak up on me | 17:37 |
| zaro | anteaya: that one requires knowing the story id, would prefer to use the 'PUT /v1/tasks' endpoint | 17:37 |
| zaro | http://docs-draft.openstack.org/46/332946/14/check/gate-storyboard-docs/3b4578a//doc/build/html/webapi/v1.html#put--v1-tasks | 17:37 |
| anteaya | zaro: ah okay | 17:38 |
| anteaya | zaro: I haven't gotten around to documenting an example for that one yet | 17:38 |
| zaro | ok. keep me posted. thanks. | 17:38 |
| Zara | yes, they're both ace :) | 17:42 |
| anteaya | zaro: working on it, so far I haven't found the right incantation | 17:44 |
| Zara | I'm heading home soon; unfortunately I've only changed task-statuses via the python client and the webclient so I can't help with the incatation. | 17:46 |
| Zara | *incantation | 17:47 |
| Zara | ahh, timezones :) | 17:48 |
| Zara | I can check both channels every so often this evening | 17:50 |
| anteaya | Zara: thanks for a great two days | 17:51 |
| anteaya | enjoy your evening | 17:51 |
| anteaya | zaro: I'm going to get some food and come back to this | 17:52 |
| anteaya | zaro: I'll let know now if I find it | 17:52 |
| anteaya | s/now// | 17:52 |
| persia | Just to add to the bikeshedding above: I believe comments on changes in gerrit should not be copied to the story. One of the issues I had with LP was do-called "workflow bugs" which only exist to allow developer discussion about an implementation, independent the discussion about the problem. Having separate comment streams in gerrit and SB ensures that different audiences can usefully consume appropriate messages | 17:54 |
| persia | That said, it is all bikeshedding, so if others feel differently, I do not mind. | 17:55 |
| anteaya | persia: thanks for picking up a brush and joining in :) | 17:57 |
| zaro | persia: shouldn't be difficult to accomodated either use case, should be just configuration to do that. | 17:59 |
| zaro | but i'm sure well all have better idea once its setup and we can ajust to taste. | 18:00 |
| persia | zaro: yep :) | 18:00 |
| persia | (for clarity, I do not actually have an SB instance anywhere: I'm just very opinionated about requirements tracking) | 18:01 |
| *** zara_the_lemur__ has joined #openstack-sprint | 18:43 | |
| anteaya | zaro: http://paste.openstack.org/show/521729/ | 19:11 |
| anteaya | 'https://storyboard-dev.openstack.org/api/v1/tasks' -X PUT | 19:11 |
| anteaya | --data-binary '{"task_id":20,"status":"merged"}' | 19:11 |
| anteaya | so I don't know what key is here | 19:12 |
| anteaya | but status is what you need to use here | 19:12 |
| anteaya | and apparently you don't need story_id here | 19:12 |
| anteaya | zaro: this is how you update the assignee: --data-binary '{"task_id":20,"assignee_id":12}' | 19:25 |
| anteaya | 12 it turns out is pedroalvarez | 19:25 |
| anteaya | this gets all your users: curl --insecure 'https://storyboard-dev.openstack.org/api/v1/users' | 19:28 |
| anteaya | I'm trying to see if I can get a user id if I give it a name | 19:28 |
| anteaya | zaro: this gives you several results for users matching a search term: curl --insecure https://storyboard-dev.openstack.org/api/v1/users/search?q=James | 19:36 |
| zaro | anteaya: thanks. | 19:37 |
| anteaya | welcome | 19:38 |
| anteaya | this gives me an error: curl --insecure https://storyboard-dev.openstack.org/api/v1/users --data-binary '{"full_name":"Anita Kuno"}' | 19:38 |
| anteaya | so I don't know how I am supposed to offer up the full_name parameter | 19:39 |
| anteaya | but is says I should be able to: http://docs.openstack.org/infra/storyboard/webapi/v1.html#get--v1-users | 19:40 |
| zara_the_lemur__ | I don't know the syntax for curl. fwiw https://storyboard-dev.openstack.org/api/v1/users?full_name=Anita%20Kuno works as a link, so I think it's just a matter of finding the right syntax | 19:45 |
| anteaya | zara_the_lemur__: thank you | 19:45 |
| anteaya | that is the syntax curl will accept too: curl --insecure https://storyboard-dev.openstack.org/api/v1/users?full_name=Anita%20Kuno | 19:46 |
| anteaya | I don't know if that is the only syntax but this syntax works | 19:47 |
| anteaya | wooo | 19:47 |
| anteaya | so I am going to update the api docs againg | 19:47 |
| anteaya | again | 19:47 |
| anteaya | I can't get delete to work and suspect it won't work via the api, so I will just remove the TODO on delete for now and disccuss more when folks have time | 19:48 |
| anteaya | I'll add bits for tasks in a separate patch | 19:48 |
| anteaya | zaro: zara_the_lemur__ found the syntax to query for user output based on name | 19:49 |
| anteaya | so search works and full_name if full_name in gerrit matches full_name in storyboard | 19:49 |
| anteaya | fungi: is it safe to assume full_name in gerrit matches full_name in storyboard since they both use openid? | 19:50 |
| fungi | not really safe, no | 19:50 |
| anteaya | hmmm | 19:50 |
| fungi | gerrit uses the openid data it gets at first login to populate its database | 19:51 |
| fungi | however, after that gerrit allows you to change your name | 19:51 |
| anteaya | ah | 19:51 |
| zara_the_lemur__ | anteaya: okay, thanks :) glad I could help, given I know pretty much nothing about curl! there might be better ways of doing things that I don't know about; hopefully someone with stronger api skills can look over things later. | 19:51 |
| * zara_the_lemur__ vanishes again | 19:51 | |
| anteaya | zara_the_lemur__: working suits me fine | 19:51 |
| fungi | there is no guarantee the full name reported by openid matches the full name tracked in gerrit at an arbitrary point in the future after account creation | 19:51 |
| anteaya | if someone wants to throw stones I'm an easy target | 19:51 |
| anteaya | zara_the_lemur__: thanks for your help! | 19:51 |
| anteaya | fungi: okey dokey | 19:52 |
| anteaya | zaro: I guess we are at some combination of search and full_name to get storyboard user_id | 19:52 |
| clarkb | anteaya: fungi you can also change your full name in gerrit | 19:52 |
| anteaya | too bad the user api didn't allow searching on openid | 19:52 |
| anteaya | clarkb: yeah | 19:52 |
| clarkb | at https://review.openstack.org/#/settings/contact | 19:52 |
| fungi | clarkb: right, that was what i meant, but you can do it in lp too i guess, i should have mentioned it's both places | 19:53 |
| anteaya | :( | 19:53 |
| fungi | anteaya: zaro: i suggest you try something similar to what we do in gerrit | 19:53 |
| fungi | er, in jeepyb | 19:53 |
| anteaya | every storyboard user has an openid which right now is a launchpad url | 19:53 |
| anteaya | "openid": "https://login.launchpad.net/+id/7PrMEYW" is mine | 19:53 |
| fungi | we query launchpad using the openid url we have, and lp has a reverse lookup account by openid method in its api | 19:53 |
| anteaya | would that match with gerrit? | 19:53 |
| anteaya | ah yeah okay | 19:54 |
| fungi | most of the time, yes | 19:54 |
| anteaya | too bad we can't just query the storyboard user api with it | 19:54 |
| fungi | _if_ they log into gerrit with a different lp account than they log into sb with, it could get weird | 19:54 |
| fungi | also in a reasonable openid consumer system, the account may be associated with multiple openids | 19:54 |
| anteaya | fungi: then they come running to us and someone looks at the db, is my prediction | 19:54 |
| fungi | so you might need to iterate through them | 19:55 |
| fungi | anyway, it may be that we need the sb api to grow a "lookup by openid" feature | 19:55 |
| anteaya | okay so it looks like changing the status of a task is really easy task_id and status | 19:55 |
| anteaya | but setting assignee needs a user id | 19:55 |
| anteaya | and getting the user id looks more complex | 19:56 |
| fungi | so if the sb api had a method where we can query with an openid and get back the corresponding sb account id that would be great (or if any methods taking an account id optionally could take an openid string as well) | 19:56 |
| anteaya | zaro: if you can do changing status with a task id for now that would be great, that looks like the simple one | 19:56 |
| anteaya | fungi: yes I agree | 19:57 |
| anteaya | fungi: I think if I am to look at that myself I would have to set up an instance of storyboard first | 19:57 |
| anteaya | I don't know of SotK or zara_the_lemur__ have changed the api in the past | 19:57 |
| fungi | so that the plugin could just say "i want task nnnn reassigned to the sb user with openid xxxx" | 19:58 |
| anteaya | so don't know what would be entailed on their end | 19:58 |
| fungi | and then have sb act on that, would simplify things greatly | 19:58 |
| anteaya | fungi: yeah, that would be so much easier, then all the other lookup loops | 19:58 |
| anteaya | agreed | 19:58 |
| anteaya | okay I don't know how to extend the api but I think in this instance it is worth examining | 19:59 |
| anteaya | hopefully someone will beat me to it | 19:59 |
| fungi | this is, for example, one of the things gerrit's api does well (though it's missing openid as an identifier option), you can identify an account in an api call by id or username or e-mail address | 19:59 |
| fungi | or full name | 19:59 |
| anteaya | right, choices | 19:59 |
| anteaya | reasonable ones | 19:59 |
| anteaya | most user accounts on storyboard right now don't have an email | 19:59 |
| anteaya | everyone's email is null | 20:00 |
| anteaya | since you don't need to set it to sign in I don't predict many folks will bother setting it | 20:00 |
| fungi | makes for fewer api calls/round-trips if you have only one of those pieces of information since the api doesn't insist on only accepting the index id | 20:00 |
| anteaya | well null email on the -dev server anyway | 20:00 |
| anteaya | right | 20:01 |
| fungi | so you don't have to start with a lookup query to map to the account number and then make a separate call to use it | 20:01 |
| anteaya | yup | 20:01 |
| anteaya | someone was thinking | 20:01 |
| fungi | anyway, that's _probably_ a simple addition to the sb api, but i say that having not looked closely at that part of teh codebase and as someone who likely won't have time to implement it | 20:01 |
| fungi | therefore, grain of salt and whatever | 20:02 |
| anteaya | I'm sure it would be simple for someone | 20:02 |
| anteaya | hefty grain of salt if this ends up on me | 20:02 |
| SotK | regarding `DELETE /v1/stories/:id`, I think only admins can do it | 20:04 |
| anteaya | SotK: okay thanks, any thoughts on how I should document that? | 20:05 |
| * SotK doesn't really know | 20:05 | |
| SotK | maybe a note that its admin only near the example | 20:05 |
| anteaya | I can't create the example | 20:05 |
| SotK | (I think the 405 you got was because of a typo in your command last night, it said "-DELETE" instead of "DELETE") | 20:05 |
| anteaya | could an admin give me the example command? | 20:06 |
| anteaya | did it, thank you | 20:06 |
| SotK | would you like me to write a quick patch for lookin up users by openid url? | 20:07 |
| SotK | s/lookin/looking/ | 20:07 |
| anteaya | SotK: oh would you? | 20:07 |
| anteaya | you are awesome | 20:08 |
| SotK | user accounts will have an email btw, we just don't have it publically accessible | 20:08 |
| anteaya | yes, I would like that | 20:08 |
| anteaya | oh okay | 20:08 |
| SotK | I don't think the openid url is either, but I don't see any reason to disallow lookups | 20:09 |
| anteaya | thanks | 20:09 |
| SotK | though, maybe it is if you see users as having it | 20:09 |
| anteaya | I can see all users openid's | 20:09 |
| anteaya | curl --insecure 'https://storyboard-dev.openstack.org/api/v1/users' | 20:10 |
| anteaya | s/did it, thank you/did I? thank you | 20:13 |
| SotK | argh, my VM here is being super slow today | 20:21 |
| anteaya | it happens | 20:23 |
| SotK | anteaya, fungi: https://review.openstack.org/333567 | 20:26 |
| SotK | `GET /v1/users?openid=dQxpCYE` will find me with that patch for example | 20:27 |
| *** Daviey has quit IRC | 20:27 | |
| *** Kiall has quit IRC | 20:27 | |
| *** zaro has quit IRC | 20:27 | |
| *** morgabra has quit IRC | 20:27 | |
| *** natorious has quit IRC | 20:27 | |
| * SotK tries using the full url | 20:27 | |
| *** Kiall has joined #openstack-sprint | 20:27 | |
| fungi | right, at least as far as precedent, launchpad's api allows account lookup by openid, and gerrit's api allows account lookup by e-mail. they're both relatively innocuous | 20:28 |
| fungi | SotK: neat, so it's just a substring match on the openid field then? | 20:29 |
| SotK | yep | 20:29 |
| *** morgabra has joined #openstack-sprint | 20:29 | |
| anteaya | SotK: what does your full curl command look like if you don't mind | 20:29 |
| *** natorious has joined #openstack-sprint | 20:30 | |
| * SotK did it in browser, one sec | 20:30 | |
| anteaya | thanks | 20:30 |
| *** zaro has joined #openstack-sprint | 20:32 | |
| *** Daviey has joined #openstack-sprint | 20:34 | |
| *** rfolco has quit IRC | 20:35 | |
| SotK | anteaya: `curl --insecure https://storyboard-dev.openstack.org/api/v1/users?openid=dQxpCYE` will work once that patch is merged | 20:35 |
| *** rfolco has joined #openstack-sprint | 20:35 | |
| anteaya | thanks | 20:39 |
| anteaya | SotK: we are waiting on a review from zara_the_lemur__ the merge that patch? | 20:40 |
| anteaya | to merge | 20:40 |
| anteaya | SotK: any idea if we can also find by email? | 20:41 |
| SotK | aye, or someone else with +2 on that repo | 20:41 |
| SotK | I can write a patch for it | 20:41 |
| anteaya | thanks | 20:41 |
| SotK | I'll update that one actually | 20:41 |
| anteaya | will it work even if you can't find the email via the api? | 20:41 |
| SotK | (others with +2 on that repo are NikitaKonovalov and infra cores iirc) | 20:42 |
| anteaya | the api won't show me emails because you said you told it not to | 20:42 |
| SotK | yeah, it will do | 20:42 |
| anteaya | SotK: cool thanks | 20:42 |
| anteaya | SotK: I'll wait on your update then bug | 20:42 |
| SotK | I don't see a problem with being able to say "does this email have an account", since that is less likely to be used as a vector for obtaining email addresses I imagine | 20:42 |
| anteaya | I think so too | 20:43 |
| SotK | anteaya, fungi: https://review.openstack.org/333567 now with emails! | 20:53 |
| fungi | SotK: well, allowing to search for account by e-mail address substring allows for brute-forcing e-mail addresses in very few steps (you can guess one character at a time rather than having to guess them all at once) | 20:53 |
| fungi | SotK: for our use case i don't really care because we treat e-mail addresses as entirely public data, but other organizations might | 20:54 |
| fungi | so up to you how you choose to try and secure that | 20:55 |
| anteaya | fungi: would you prefer email was not added to the api? | 20:56 |
| fungi | i don't have a preference, though it seems useful | 20:56 |
| anteaya | it seems useful to me too | 20:56 |
| fungi | it would probably be just as useful though if e-mail address and openid lookups were full-string rather than substring matching | 20:56 |
| anteaya | but yes, back to SotK's email information concern regarding hiding all the email info, this could compromise that position | 20:57 |
| fungi | i have no idea if that's significantly more complicated with the current implementation | 20:57 |
| anteaya | oh a match rather than a filter | 20:58 |
| SotK | hm, actually, the api doesn't return the email addresses in the result | 20:58 |
| anteaya | SotK: yeah that is what I was seeing | 20:58 |
| anteaya | all my returned email addresses are null | 20:59 |
| anteaya | on -dev anyway | 20:59 |
| fungi | my point was that if you can substring match on e-mail address, even if it doesn't return the address, you can quickly figure out what addresses are in use | 21:00 |
| fungi | start, say, matching on @openstack.org and you see a handful of accounts returned, then a@openstack.org and nothing, try b@openstack.org ... when you try y@openstack.org you'll find my account coming back again, so now try ay@openstack.org... et cetera | 21:01 |
| SotK | that makes sense, I'll make it full-match on emails | 21:01 |
| anteaya | only four James on storyboard all have email null | 21:01 |
| fungi | eventually you find that jeremy@openstack.org returns exactly one account and <anything>jeremy@openstack.org never returns any matches, then you know that's a valid e-mail address | 21:01 |
| fungi | probably a few thousand api calls to get there, but not that many when it comes to automating stuff with computers | 21:02 |
| fungi | okay, more than a _few_ thousand, but it changes the work factor from something like 6^26 to something more like 26^6 | 21:03 |
| *** rfolco has quit IRC | 21:03 | |
| SotK | do we care about openids being substring matched too? | 21:04 |
| fungi | and that's of course for a completely uninformed brute-force run. with some heuristics that could come way, way down | 21:04 |
| fungi | SotK: i don't personally, but i also don't see a lot of point in substring matching on an openid | 21:04 |
| fungi | it's sort of like being able to say, "return all the accounts whose index number ends in the digits 361" | 21:05 |
| fungi | either you have the whole openid and can query with that, or you're going to use something else | 21:05 |
| SotK | heh, the point was it was less code to do it that way, but now that is irrelevant | 21:06 |
| fungi | the situations where you usefully have only part of an openid is basically nil | 21:06 |
| fungi | yep, i get why it was done that way (name searches are useful that way) | 21:06 |
| fungi | particularly for auto-completion | 21:06 |
| fungi | e-mail addresses _could_ be useful that way (gerrit does that, for example) but gerrit also doesn't attempt to hide e-mail addresses. you can just query up a whole list of them if you like | 21:07 |
| fungi | if you do care about securing e-mail addresses, then subscring matches for them through the api is a questionable choice | 21:07 |
| clarkb | fungi: which makes sense considering they are all published in the git trees anyways | 21:07 |
| fungi | clarkb: well, yes and no. if you submit a patchset it will be in the commit, and if you leave a vote it may be in got notes, but if you're just browsing and have an account there it's not necessarily going to show up in git | 21:08 |
| clarkb | thats true, but browsing also doesn't require an account or email addr to be provided | 21:09 |
| fungi | regardless, i agree gerrit's use case is different enough from storyboard's that its api choices may not be reasonable in the other context | 21:09 |
| persia | Yes, but watching does. | 21:09 |
| SotK | fungi, anteaya: https://review.openstack.org/333567 now only with full matching | 21:30 |
| anteaya | yay full matching | 21:31 |
| clarkb | persia: good point | 21:32 |
| fungi | SotK: cool--thanks! | 21:36 |
| anteaya | fungi: clarkb if you want to approve that patch so that zaro can keep working, that would be great | 21:38 |
| anteaya | I can fix my docstring nit in a follow up patch | 21:39 |
| fungi | was just waiting for tests to come back on that last patchset before looking closer | 21:40 |
| clarkb | 333567? | 21:41 |
| clarkb | I am not super familiar with that code base so would prefer to not approve changes there | 21:41 |
| anteaya | clarkb: yes, and fair enough | 21:43 |
| anteaya | fungi: yup, makes sense | 21:43 |
| fungi | the change looks reasonable, and at this point i don't know of anyone more familiar with that code base than the author of the change, so willing to approve it if tests pass | 21:46 |
| anteaya | fungi: thank you | 21:46 |
| fungi | is gate-storyboard-js-integration expected to fail? i see it's nonvoting but not sure if that's for other reasons | 21:53 |
| fungi | ERROR: unknown environment 'grunt' | 21:54 |
| anteaya | yeah I have seen that a lot | 21:55 |
| anteaya | I can't recall the reason | 21:55 |
| zara_the_lemur__ | heh, yeah, that test is broken atm. (I'm heading off to bed now, but will take a look at patches in the morning if necessary) | 21:55 |
| anteaya | but I have seen that error in the past | 21:55 |
| anteaya | zara_the_lemur__: thank you | 21:55 |
| zara_the_lemur__ | 'night! | 21:56 |
| anteaya | zara_the_lemur__: enjoy sleep | 21:56 |
| *** zara_the_lemur__ has quit IRC | 21:56 | |
| SotK | yeah, it doesn't work on any change to openstack-infra/storyboard, and we haven't ever had time to devote to fixing it | 21:57 |
| *** baoli has quit IRC | 21:57 | |
| SotK | that is why it is non-voting (plus idk how implemented the test part of it is) | 21:57 |
| anteaya | should we move it to experimental do you think? | 22:00 |
| anteaya | until someone has time to spend fixing it? | 22:01 |
| anteaya | no sense having it run everytime if it always fails and noone looks at it | 22:01 |
| anteaya | https://review.openstack.org/#/c/333604/ | 22:08 |
| anteaya | thanks Adam | 22:16 |
| SotK | yw :) | 22:18 |
| SotK | thanks for the patch | 22:18 |
| anteaya | :) | 22:19 |
| anteaya | welcome | 22:19 |
| anteaya | fungi: jenkins is happy in all but one test https://review.openstack.org/#/c/333567/4 we are demoting that test: https://review.openstack.org/#/c/333604/ | 22:20 |
| anteaya | pleia2: would you have time to try a delete command and see if you can get it to work? | 23:12 |
| anteaya | pleia2: Adam feels only admins can delete and I'm not an admin | 23:13 |
| anteaya | if you get a command that works if you could add the command in a comment on my patch I'll include it | 23:13 |
| pleia2 | anteaya: what should I try to delete? | 23:13 |
| anteaya | a story? | 23:14 |
| pleia2 | ok | 23:14 |
| anteaya | http://docs.openstack.org/infra/storyboard/webapi/v1.html#delete--v1-stories | 23:14 |
| pleia2 | ah, with the api? | 23:15 |
| pleia2 | in the web ui for https://storyboard-dev.openstack.org/#!/story/5 I have a "Remove this story" link | 23:15 |
| anteaya | yeah with the api | 23:16 |
| anteaya | I do not have a "Remove this story" link when I view that story | 23:16 |
| pleia2 | ok, so here's how the webui looks for me as an admin: http://princessleia.com/temp/Screenshot_2016-06-23_16-15-42.png | 23:16 |
| anteaya | this is for an example for the api docs | 23:16 |
| pleia2 | crafting my api command now | 23:16 |
| pleia2 | thanks | 23:17 |
| anteaya | thank you | 23:17 |
| anteaya | pleia2: here is my view: http://imgur.com/q8GDR9Q | 23:18 |
| anteaya | and I'm the author | 23:18 |
| anteaya | and not an admin | 23:18 |
| pleia2 | if I delete every story in the dev instance, tell them it was someone else | 23:23 |
| anteaya | ha ha ha | 23:24 |
| pleia2 | taking me a few minutes while I figure this out :) | 23:26 |
| anteaya | I _totally_ understand | 23:27 |
| anteaya | the amount of time Ihave to spend on each command is exactly why I wanted the docs to have examples | 23:28 |
| anteaya | no way we are going to be able to sell this great api to folks unless they can use it | 23:28 |
| pleia2 | struggling to figure out what we want in the json | 23:33 |
| pleia2 | doesn't want the id: | 23:33 |
| pleia2 | looking at the code | 23:34 |
| pleia2 | aha! story_id | 23:35 |
| pleia2 | ok, this is what we want: | 23:35 |
| pleia2 | curl -X DELETE 'https://storyboard-dev.openstack.org/api/v1/stories' -H 'Authorization: Bearer TOKEN' -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/json, text/plain, */*' --data-binary '{"story_id":5}' --insecure | 23:35 |
| pleia2 | where "5" is the story_id | 23:36 |
| pleia2 | also, I hope you don't mind that I deleted your story :) | 23:36 |
| anteaya | nope that is what is was there for | 23:37 |
| anteaya | and thank you | 23:37 |
| anteaya | yay a command that works! | 23:37 |
| anteaya | can you add that to my patch as a comment? | 23:37 |
| pleia2 | sure | 23:37 |
| anteaya | thanks | 23:37 |
| anteaya | have you the strength to try to delete a task now? http://docs.openstack.org/infra/storyboard/webapi/v1.html#delete--v1-stories--story_id--tasks | 23:37 |
| anteaya | hopefully the command is similar | 23:38 |
| anteaya | I got 404: GET /api/v1/stories/5: Story 5 not found | 23:38 |
| anteaya | by the way a whole lot of these errors are really unncessary | 23:39 |
| pleia2 | sure, can you find a deletable task for me while I poke at the API? | 23:39 |
| anteaya | any 404 redirects me to the dashboard anyway | 23:39 |
| anteaya | yes | 23:39 |
| pleia2 | yeah, same | 23:40 |
| anteaya | {"status": "merged", "priority": "medium", "branch_id": 153, "title": "Task Foo", "story_id": 11, "created_at": "2016-06-23T18:59:29+00:00", "updated_at": "2016-06-23T19:24:02+00:00", "assignee_id": 12, "creator_id": 13, "link": null, "milestone_id": null, "project_id": 153, "id": 20} | 23:40 |
| anteaya | that should be a good one to delete | 23:40 |
| anteaya | the task id is at the end: 20 | 23:41 |
| pleia2 | ok, let me bring it up in the webui so i can see before/after | 23:41 |
| anteaya | https://storyboard-dev.openstack.org/#!/story/11 | 23:41 |
| pleia2 | story 11 | 23:41 |
| anteaya | yup | 23:41 |
| pleia2 | success \o/ adding this comment in the review too | 23:42 |
| anteaya | yay | 23:42 |
| anteaya | thanks so much | 23:42 |
| anteaya | oh can you add the output too? | 23:42 |
| anteaya | zaro asked for the examples to provide their output | 23:43 |
| anteaya | hopefully it is a page up away | 23:43 |
| pleia2 | neither had any output | 23:43 |
| anteaya | oh okay thanks | 23:43 |
| anteaya | just gave you back your cursor | 23:43 |
| pleia2 | ok, saved inline in gerrit | 23:45 |
| anteaya | thank you so much | 23:48 |
| pleia2 | happy to help :) with these examples documented we should be the last people to struggle through this! | 23:49 |
| anteaya | oh I do hope so | 23:50 |
| anteaya | I hope then the other sections at least follow some of the patterns | 23:50 |
| * pleia2 nods | 23:50 | |
| anteaya | I would like to get the stories section agreed to and merged then work on the other sections | 23:50 |
| pleia2 | nice work on tackling this, it's going to be a huge help | 23:52 |
| anteaya | thank you | 23:55 |
| anteaya | I've been doing curl url -x REST ACTION | 23:55 |
| anteaya | will your delete still work if I move the rest action after the url? | 23:56 |
| anteaya | I think it will | 23:56 |
| anteaya | oh and that should be capital x there | 23:56 |
| anteaya | -X | 23:56 |
| anteaya | pleia2: ^^ | 23:56 |
| pleia2 | it didn't matter where --insecure went, so I have no reason to believe moving the -X DELETE flat won't do the same | 23:57 |
| pleia2 | s/flat/flag | 23:57 |
| anteaya | okay thanks | 23:58 |
| pleia2 | I'll confirm with another task on that story | 23:58 |
| anteaya | awesome thanks | 23:58 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!
