| dhellmann | ok, it is too late in the day to figure out how to add a required parameter via WSME | 00:00 |
|---|---|---|
| dhellmann | I wonder if it would make sense to change all of that to jsonschema anyway | 00:01 |
| openstackgerrit | Doug Hellmann proposed openstack-infra/storyboard master: handle missing lanes arg when creating a board https://review.openstack.org/545168 | 00:19 |
| openstackgerrit | Doug Hellmann proposed openstack-infra/storyboard master: handle missing filters arg when creating a worklist https://review.openstack.org/545169 | 00:19 |
| openstackgerrit | Doug Hellmann proposed openstack-infra/storyboard master: use required enums to validate 'type' args https://review.openstack.org/545170 | 00:19 |
| diablo_rojo | dhellmann, thanks for the patches! | 00:21 |
| dhellmann | that still results in my script creating a board with no lanes :-( | 00:21 |
| dhellmann | but it does create the board and the worklist | 00:21 |
| dhellmann | I create the board, then the worklist, then add filters to it | 00:22 |
| dhellmann | I'm assuming that I have not properly associated the board and worklist somehow but I'm not sure what I'm missing from that | 00:22 |
| dhellmann | the script is in http://paste.openstack.org/show/673316/ | 00:23 |
| * diablo_rojo looks | 00:23 | |
| dhellmann | I will try changing it to pass the worklist definitions when I create the board, but I was trying to follow what I thought the UI was doing in terms of making API calls | 00:24 |
| dhellmann | ah, so apparently after I create the worklist I have to push a new definition of the board that includes that worklist | 00:46 |
| dhellmann | that is unexpected | 00:46 |
| dhellmann | so, I'll probably just update the client to pass all of the data in a single call instead | 00:46 |
| dhellmann | and that'll be tomorrow | 00:47 |
| *** persia_ has joined #storyboard | 00:48 | |
| *** persia_ has quit IRC | 00:50 | |
| *** persia_ has joined #storyboard | 00:51 | |
| *** thrace has joined #storyboard | 00:54 | |
| *** persia has joined #storyboard | 00:54 | |
| diablo_rojo | Sounds like a simpler fix | 01:03 |
| diablo_rojo | Definitely unexpected that you need to give it a new definition | 01:03 |
| persia | My vague memory of workflow was an assumption that folk would create worklists and then boards, but I've always felt the board design was bolt-on, rather than being a prime focus: maybe the model ought be revisted for that. | 01:09 |
| persia | But updating the board to include the new worklist is consistent with that memory, as much as that might seem like unexpected behaviour from a boards-first perspective. | 01:10 |
| *** udesale has joined #storyboard | 04:09 | |
| *** openstackstatus has quit IRC | 06:27 | |
| *** openstack has joined #storyboard | 06:29 | |
| *** ChanServ sets mode: +o openstack | 06:29 | |
| *** openstackstatus has joined #storyboard | 06:30 | |
| *** ChanServ sets mode: +v openstackstatus | 06:30 | |
| *** jtomasek has joined #storyboard | 08:40 | |
| SotK | oh good, the publish-openstack-javascript-content job is still broken | 09:22 |
| SotK | I suspect the worklists and boards code is quite coupled to the webclient implementation of things, which (for example) creates a worklist and then updates the board to contain it | 09:36 |
| SotK | it being that way around is an artifact of the workflow persia mentioned, initial ideas involved being able to add pre-existing worklists to your board | 09:37 |
| SotK | permissions make that sadly complicated though | 09:37 |
| SotK | I also think that worklist_filters.type is a thing left over from a worse implementation of worklist filters and it should probably go away | 09:39 |
| SotK | also, thanks for the patches dhellmann, and sorry that the python client is so far behind the webclient | 09:40 |
| openstackgerrit | Merged openstack-infra/storyboard master: remove unused variable in test-cleanup.sh https://review.openstack.org/539695 | 10:07 |
| *** udesale_ has joined #storyboard | 10:07 | |
| *** udesale has quit IRC | 10:10 | |
| *** udesale__ has joined #storyboard | 10:16 | |
| *** openstackgerrit has quit IRC | 10:18 | |
| *** udesale_ has quit IRC | 10:19 | |
| *** udesale_ has joined #storyboard | 11:29 | |
| *** udesale__ has quit IRC | 11:32 | |
| *** udesale_ has quit IRC | 11:34 | |
| *** udesale has joined #storyboard | 12:41 | |
| *** udesale has quit IRC | 14:08 | |
| *** udesale_ has joined #storyboard | 14:08 | |
| *** aspiers has quit IRC | 16:33 | |
| dhellmann | persia , SotK : when I try to pass the lane and worklist data in the call that creates the board I get an error because the worklist needs an ID. But I don't know the ID, yet. So does that mean I have to create the worklist separately and then pass the same data when creating the board? | 16:36 |
| *** udesale_ has quit IRC | 16:37 | |
| *** aspiers has joined #storyboard | 16:43 | |
| SotK | dhellmann: yeah, you need to create the worklist first and then pass the "lane" object when creating the board (eg. something like "lanes": [{"worklist_id": 1, "position": 0}] iirc) | 16:43 |
| dhellmann | ah, ok | 16:43 |
| dhellmann | so I don't need the full worklist definition there, just its id | 16:43 |
| persia | Yes. | 16:44 |
| dhellmann | ok. I'm trying to make this tool idempotent. Do you have any tips for figuring out if the worklist already exists if it's not tied to the board at the time it is created? | 16:44 |
| dhellmann | the title of the board is going to be pretty generic, since it's a lane | 16:45 |
| dhellmann | unless the lane and list can have different titles? | 16:45 |
| * dhellmann checks the data model | 16:45 | |
| SotK | the lane just uses the list title, this isn't a use case I've considered a lot really :/ | 16:46 |
| SotK | a "lane" is just a mapping between boards and worklists with a "position" attribute | 16:47 |
| SotK | s/with a/ with an added/ might make more sense there | 16:48 |
| dhellmann | yeah, that's what I thought | 16:48 |
| dhellmann | Maybe the thing to do is create the lists with long well known names, associate them with the board, then change the names when the board is fully created. | 16:50 |
| dhellmann | that feels very complicated, though | 16:50 |
| SotK | that's the best thing I can think of doing without changing the data model | 16:51 |
| persia | We really should talk about the data model though. If we want to have first-class boards (I'm not a fan, but appreciate that others are), then we ought avoid situations where we have 95 worklists named "backlog". | 16:55 |
| persia | But I think for dhellmann's script, best to do it the complicated way (for now), and talk about the data model if we can organise having most of us in the same place and timezone. | 16:56 |
| dhellmann | \o/ got it working | 17:49 |
| dhellmann | https://review.openstack.org/537690 is the start of the series with the script and http://paste.openstack.org/show/674741 has the full text | 17:50 |
| dhellmann | thanks, persia, SotK , Zara, and diablo_rojo for your help | 17:50 |
| persia | Thanks a lot for exercising the python client. While some effort went into trying to keep it up to date, a total lack of identified users didn't help keep anyone motivated. | 17:51 |
| persia | Now that it has a user, I think we can start to think sensibly about how to make the experience smoother, improve the representations, etc. | 17:52 |
| *** openstackgerrit has joined #storyboard | 17:52 | |
| openstackgerrit | Doug Hellmann proposed openstack-infra/storyboard master: use required enums to validate 'type' args https://review.openstack.org/545170 | 17:52 |
| openstackgerrit | Doug Hellmann proposed openstack-infra/storyboard master: mark worklist filter_criteria as a required field https://review.openstack.org/545405 | 17:52 |
| openstackgerrit | Doug Hellmann proposed openstack-infra/storyboard master: mark FilterCriterion title as a mandatory field https://review.openstack.org/545406 | 17:52 |
| dhellmann | persia : yeah, I'd like to see an actual release and to have the python API reflect things like required parameters for calls to make it easier to do the right thing | 17:53 |
| dhellmann | for now I'm just building my virtualenv by hand to run this tool | 17:53 |
| persia | I think those are achieveable. There has been talk about a storyboard session at PTG, but I don't know that any specific slot has been scheduled or even that everyone has committed to having time to think about storyboard at PTG. | 17:54 |
| dhellmann | I'm interested in participating if we can put something together | 17:55 |
| dhellmann | for now, it's time for lunch | 17:55 |
| diablo_rojo_phon | Nothing has been scheduled yet. I was looking at maybe Tuesday afternoon and Wednesday morning. Gotta double check my schedule, but I was trying to keep hours here and there for StoryBoard. | 17:56 |
| SotK | I will be at the PTG most likely thinking about StoryBoard for a large portion of the time | 17:57 |
| SotK | though I won't be around on Friday | 17:57 |
| persia | That's probably enough of us. Shall we look at something Wednesday then? | 18:03 |
| SotK | I feel like Wednesday is the traditional day for StoryBoard sessions | 18:05 |
| diablo_rojo_phon | Sounds good to me. | 18:36 |
| dhellmann | diablo_rojo_phon : I'm not going to be available on Tuesday but could join Wednesday after we tag the final release | 18:50 |
| diablo_rojo | Sounds like Wednesday is the best day for a bigger group get together/chat | 18:51 |
| dhellmann | diablo_rojo , SotK , Zara , persia : I could use a +1 from you on this release request for the python client: https://review.openstack.org/545437 | 18:59 |
| dhellmann | I'm happy to serve as release liaison for storyboard, but as it's currently designated as part of the infrastructure team I don't know how that would work | 19:00 |
| dhellmann | I wouldn't want to take on all of the deliverables the infra team manages | 19:00 |
| diablo_rojo | dhellmann, done | 19:00 |
| dhellmann | diablo_rojo : thanks | 19:00 |
| diablo_rojo | dhellmann, lol yeah I wouldn't either. I can't even imagine how many that is. | 19:01 |
| diablo_rojo | I'll back you as our release liaison. | 19:01 |
| dhellmann | I wonder if it makes sense to spin storyboard out into its own team | 19:01 |
| diablo_rojo | I had been thinking about that for a while. I think it makes sense under infra..but maybe if its on its own team it will get more attention? I dunno. Something we can discuss at the PTG- what that would look like. | 19:02 |
| dhellmann | something to discuss at the ptg, maybe | 19:02 |
| diablo_rojo | dhellmann, :) | 19:02 |
| dhellmann | heh, yeah | 19:02 |
| * dhellmann runs off to take care of another errand | 19:03 | |
| persia | Release makes a lot of sense. Last substantial code change before dhellmann's patches seems to be September 2016. | 19:03 |
| persia | dhellmann: My only concern with release is whether you need a couple more quick changes before a release happens. If it works well enough (but not ideally), then release before the session is probably sensible. | 19:04 |
| persia | On having a separate team: that several folk in Infra can review has been very useful in taking care of things sometimes: unless there is a sponsor for at least one developer at least half-time, I think a team would be overkill. | 19:05 |
| persia | Of course, if people think having a team would cause that sponsorship to happen, then it might make sense (assuming a willing individual to consume that sponsorship) | 19:06 |
| dhellmann | persia : releases are pretty cheap and easy, so if we find issues with this version we can iterate | 19:41 |
| dhellmann | I can't really see having a team drive sponsorship for contribution; I just wondered if the team was self-sufficient enough | 19:42 |
| dhellmann | and anyone from the infra team who wanted to remain a reviewer could, of course | 19:42 |
| dhellmann | the whole question was triggered by my first version of that patch, which didn't pass validation locally because "storyboard" wasn't the name of the team that owned the repo :-) | 19:43 |
| persia | I think that's an actual bug in the script. There are lots of repos where that is true, especially for the teams with more repos than others. | 19:46 |
| persia | On the other hand, Infra is *huge*: that's nice sometimes, because it usually means one can find helpful hands in neighbour projects, but it also means that there are many repos for which there are other repos in the openstack-infra/ namespace that have no connection or overlap at all. | 19:48 |
| persia | It also means that key infra folk (which title I avoid to avoid highlighting) can come fix whatever project is necessary to get the infra working again in the event of an outage, which is absolutely critical to ensuring the level of service we have all come to accept. | 19:49 |
| dhellmann | the release validation checks the governance list to verify that all repos are owned by a team under governance | 19:53 |
| dhellmann | and we use the team to identify the PTL and liaison who we expect to either submit or sign off on the release | 19:54 |
| dhellmann | so it's more of a communication check for the release team | 19:54 |
| persia | Makes sense, but as we're hiding under clarkb's umbrella, he really is the right person to make that decision. | 20:17 |
| openstackgerrit | Doug Hellmann proposed openstack-infra/python-storyboardclient master: build universal wheels https://review.openstack.org/545446 | 20:19 |
| openstackgerrit | Doug Hellmann proposed openstack-infra/python-storyboardclient master: remove sphinx-isms from README.rst and clean up docs https://review.openstack.org/545447 | 20:25 |
| openstackgerrit | Doug Hellmann proposed openstack-infra/storyboard master: mark worklist filter_criteria as a required field https://review.openstack.org/545405 | 21:00 |
| openstackgerrit | Doug Hellmann proposed openstack-infra/storyboard master: mark FilterCriterion title as a mandatory field https://review.openstack.org/545406 | 21:01 |
| openstackgerrit | Doug Hellmann proposed openstack-infra/python-storyboardclient master: remove sphinx-isms from README.rst and clean up docs https://review.openstack.org/545447 | 21:42 |
| persia | dhellmann: Thanks for documenting the test results match my reading of the code :) | 21:48 |
| dhellmann | persia :-) | 21:49 |
| persia | You also seem to have fallen for the mail delay loop recheck that almost caught me :) That was patchset 1 that got the python27 timeout, but it doesn't matter that much (as we aren't likely to have core review until tomorrow) | 21:49 |
| dhellmann | oh, oops | 21:50 |
| dhellmann | someday I'll figure out how to read a gerrit screen | 21:50 |
| persia | I think it only happens when hyperefficient developers fix issues before Zuul has a chance to report on the last version. | 21:51 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!