14:00:28 <tflink> #startmeeting fedora-qadevel
14:00:28 <zodbot> Meeting started Mon Oct  3 14:00:28 2016 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:28 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:28 <zodbot> The meeting name has been set to 'fedora-qadevel'
14:00:28 <tflink> #meetingname fedora-qadevel
14:00:28 <zodbot> The meeting name has been set to 'fedora-qadevel'
14:00:28 <tflink> #topic Roll Call
14:00:34 * mkrizek is here
14:00:39 <tflink> who all is here for the qadevel meeting?
14:00:40 * jskladan is here
14:01:15 * kparal is here
14:02:19 * tflink waits another minute or so to see if more folks show up
14:02:26 <tflink> #chair jskladan kparal mkrizek
14:02:26 <zodbot> Current chairs: jskladan kparal mkrizek tflink
14:02:54 * garretraziel is here
14:03:22 <tflink> ok, let's get this party started
14:03:33 <tflink> #topic Announcements and Information
14:03:44 <tflink> #info fixed bug proposal form issue, figured out how to build for new epel-infra tag - tflink
14:03:54 <tflink> anything else to add?
14:03:59 <mkrizek> new epel-infra tag?
14:04:10 <tflink> yeah, the infra repo is effectively dead
14:04:24 <tflink> the new way to do that is to tag builds epel-infra in koji
14:04:34 <tflink> which is lots of fun
14:04:36 <mkrizek> is there SOP for that?
14:05:03 <tflink> not that I know of, I had to fumble my way through it on Friday but I could have easily missed something
14:05:09 * tflink should write up what he learned
14:05:19 <mkrizek> ok
14:06:17 <mkrizek> #info resultsdb_frontend and execdb are in updates-testing - mkrizek
14:06:18 <tflink> it requires a new process for us, from building srpms to building the rpm
14:06:20 <tflink> :-/
14:06:46 <mkrizek> yeah, fun :/
14:07:20 <tflink> fortunately, the taskotron stuff doesn't need the infra repo anymore (or for much longer, if it does)
14:07:53 <mkrizek> did we talk about sending blockerbugs for review btw?
14:08:03 <tflink> not really but I'm thinking about it now
14:08:20 <mkrizek> can you think of any blockers on that?
14:08:39 <tflink> I don't see a point in having it available as an epel package other than a formality and avoiding this new PITA
14:08:51 <tflink> the css build may be an issue
14:09:26 <tflink> but we can discuss this outside the meeting, there are plenty of other topics to get to today :)
14:09:32 <mkrizek> sure
14:09:49 * tflink assumes there are no more questions/comments on the stuff above
14:10:22 <tflink> #topic Docker Testing Status
14:10:31 <tflink> we seem to have no lbrabec again this week
14:11:00 <tflink> jskladan: do you know of anything that's missing for this beyond getting the new trigger code merged in and tested?
14:11:47 <jskladan> well, the actual code for `discover`
14:12:09 <tflink> that's missing the information about where the actual tests will be stored, though
14:12:11 <jskladan> since we don't have it at all (and I'm not sure that we have the pretty specific idea of how it should work)
14:12:16 <tflink> if I'm understanding you, anyways
14:12:40 <tflink> there's only one image that we need to support for now, so I'm not so worried about that. it can change later if need be
14:12:44 <jskladan> yup, it's missing piece of code on missing procedure (or however to call it)
14:12:47 <tflink> for now == for F25
14:13:08 <tflink> it's F26 when the floodgates will open
14:13:13 <jskladan> but if we do anything else than `discover` for the docker images, it's ready
14:13:21 <jskladan> (apart of the merge)
14:13:39 <tflink> cool, trigger is the next topic on the list
14:13:45 * jskladan yaay
14:14:05 <tflink> I think that we're pretty much done with what we committed to support for F25 in terms of Docker image testing
14:14:29 * tflink needs to put the example tasks from the docs into a repo somewhere and we need to get the trigger code merged and tested
14:14:37 <tflink> but other than that, I think it's all in place
14:14:47 <tflink> well, sans more testing :)
14:14:54 <tflink> but anyways, moving on
14:14:59 * jskladan I don't always test...
14:15:12 <tflink> ... but when I do test, I always test in production
14:15:24 <tflink> #topic Trigger Rewrite Status
14:16:02 <tflink> do we have any reasons not to merge the rewrite code into develop?
14:16:35 <jskladan> nothing serious. I'd like to get the license https://phab.qadevel.cloud.fedoraproject.org/D963#inline-4797
14:16:46 <jskladan> sorted
14:16:54 <jskladan> other that that, I think we are good (for now)
14:17:54 <tflink> I think that keeping everything as GPL is kosher so long as credit is given and citations made
14:18:05 <jskladan> OK
14:19:07 <tflink> if there are no objections, I'd like to get that merged today or tomorrow
14:20:45 * tflink understands silence and no complaints in the review as "no objections"
14:20:59 <tflink> jskladan: will you be able to get that merged today or tomorrow?
14:21:08 <jskladan> yes, absolutely
14:21:12 <tflink> cool
14:21:13 <jskladan> I'll do it tomorrow
14:21:33 <tflink> #info no objections to new configurable trigger code, will be merged into develop for testing
14:21:40 <tflink> anything else on this topic?
14:22:02 <jskladan> nothing
14:22:37 * tflink will poke lbrabec about the docker code that will need to be merged once the base trigger rewrite is in
14:22:49 <tflink> ok, moving on
14:22:51 <tflink> #topic Resultsdb v2.0
14:24:13 <jskladan> Done, apart of the discussion about the exec_url currently in the qa-devel
14:24:36 <tflink> i feel like I'm re-asking a question but I don't see it in the qadevel thread
14:24:56 <tflink> is there going to be a way to get from execdb job to all of the results created during that job?
14:25:00 <jskladan> I might be mistaken... mmnt
14:25:28 <jskladan> Subject: Resultsdb v2.0 - API docs
14:26:13 <tflink> oh, just found the question, it doesn't look discussed, though
14:26:13 <jskladan> tflink: yup, it's just whether we use Groups to do it, or a special field in Result
14:26:52 <jskladan> I don't really care that much either way, I'd just like to have it sorted before we roll it out (or I start working on the changes)
14:26:58 <tflink> agreed
14:27:32 <tflink> I also don't care which method we use, so long as we can find results created from each job and we aren't running head first into known performance issues
14:28:01 <tflink> jskladan: your preference is to keep the group concept instead of adding a column for the exec_url, right?
14:28:12 <jskladan> kparal seems to be slightly on my preferred side of keeping it in Group, as consensus
14:28:34 <tflink> sounds good
14:28:44 <jskladan> s/as consensus/to have the url 'by agreement' rahter than 'by fact'/ (or how to word it)
14:28:51 * jskladan my english potato today
14:29:03 <tflink> using convention instead of coding it into the schema
14:29:06 <tflink> or something like that
14:29:10 <kparal> yes, I like how it is done currently. but I have no strong objections to other implementation either
14:29:11 <jskladan> thanks
14:29:35 <kparal> jskladan has a better guess wrt to performance impacts
14:29:53 <tflink> #agreed the resultsdb 2.0 API is fine as it is, we don't see any reason to force an exec_url for every result
14:30:05 <jskladan> so, let's agree on keeping the data in group's url (and yes, it means less work for me), performance-vise, it's really a wash, I think. it's index search either way
14:30:17 <tflink> does that #agreed work well enough?
14:30:21 <jskladan> absolutely
14:30:55 <jskladan> having exec_url in result would mean duplicating the uuid, but since we don't really have _that much_ data anyway (especially once we go forward with data-retiring)...
14:31:12 <jskladan> it's not really the (or a) reason against it
14:31:42 <jskladan> so, as this is agreed, I think that ResultsDB v2.0 is ready to be packaged
14:31:55 <tflink> how is it duplicating data? am I forgetting something?
14:32:30 <jskladan> if we kept exec_url per-result, many results would have the same url stored (compared with storing it in Group)
14:32:43 <tflink> oh
14:32:54 <tflink> i thought you meant that there would be data duplication if it was in the group
14:33:13 <jskladan> but it as our data is anecdotaly small (for a database) this is really would not be remotely a problem
14:33:14 <tflink> cool, I assume that the resultsdb code can be merged into develop tomorrow as well?
14:33:19 <jskladan> yes, will do
14:33:38 <jskladan> and I'll start working on Taskotron bits that interact with it
14:33:47 <tflink> sounds good to me
14:33:51 <tflink> thanks for getting all of this done
14:34:03 <jskladan> hopefully just trigger (minimal changes), and libtaskotron (resultsdb directive)
14:34:37 <tflink> hopefully?  :-/
14:34:42 * tflink is kidding
14:34:43 <jskladan> well, one never knows :D
14:34:52 <jskladan> I'm confident that I'll be able to do it by the end of the week
14:35:17 <tflink> great, looking forward to getting the testing started for all of this
14:35:43 <tflink> anything else on this topic?
14:35:56 <jskladan> I have nothing
14:36:19 <tflink> OK, moving on
14:36:20 <tflink> #topic Dist-Git Task Storage Proposal
14:36:33 <tflink> last call for objections to me sending this out to devel@
14:36:51 <jskladan> none. Do it! Push the button!
14:38:01 * tflink takes that silence as "no objections" since this has come up in discussion before
14:38:14 <tflink> #topic Bodhi Interface Package Change
14:38:41 <tflink> this is something that hasn't really affected us yet but has the potential to break things
14:39:49 * tflink wishes he would have gotten a link to the devel@ post before the meeting
14:40:31 <jskladan> tflink: what's this about?
14:40:44 * jskladan is still catching up on things
14:41:25 <tflink> ah ha, found it
14:41:28 <tflink> #link https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CS75FONLSX57FGLWZBDLNI3THJAWM7RC/
14:41:36 <tflink> my understanding is as follows:
14:41:52 <tflink> the bodhi client libraries weren't really updated when bodhi went to 2.x
14:42:07 <kparal> finally, fixed bodhi client!
14:42:09 <tflink> they're now being updated and not all the changes are backwards compatible
14:42:25 <tflink> to make things even more fun, there are no plans to push the new changes to anything older than F26
14:42:38 <tflink> so if there are issues in our code, we'll have to support both for a while
14:42:53 <tflink> but if we're lucky, we won't have to change anything in libtaskotron
14:43:06 <kparal> I think this should not bite us, because we're using bodhi API from python-fedora, and this is just the cmdline client update (which uses the same API)
14:43:13 * tflink completely missed this thread until it came up later in IRC
14:43:14 <kparal> but I'd have to examine it closer
14:43:49 <tflink> yeah, I haven't looked at it closely enough yet, either
14:43:55 <tflink> just wanted to mention it
14:43:55 <jskladan> kparal: you said it, I'll remeber :)
14:44:04 <jskladan> thx
14:44:07 <kparal> thanks for heads up
14:44:34 * jskladan has 25 minutes of battery life left, just so you know, if I time out...
14:44:39 <tflink> ok
14:44:50 <tflink> anything else on this?
14:44:54 * tflink assumes not
14:45:20 <tflink> ok, moving on
14:45:21 <tflink> #topic Video Meetings
14:45:38 * tflink forgot to bring this up again before the first meeting of the month
14:46:23 <tflink> we never really reached a consensus on whether to do video meetings as-needed or to do the first meeting of every month via video as well
14:47:18 <tflink> I see a +1 for on-demand and a +1 for the first meeting of every month
14:47:36 <kparal> I'd probably go with as-needed
14:47:39 <garretraziel> I would do it on-demand also
14:47:41 <jskladan> after thinking on it, I'm for on-demand
14:48:17 <tflink> ok, we now have consensus :)
14:48:47 <garretraziel> hooray for democracy!
14:48:55 * tflink will add it to the regular agenda
14:49:05 <tflink> a topic asking whether a video meeting is desired/needed
14:49:12 <jskladan> cool
14:49:57 <tflink> that's all I had for today
14:50:00 <tflink> #topic Open Floor
14:50:09 <tflink> any other topics that folks would like to bring up?
14:51:03 * jskladan is just going to leave this here https://www.youtube.com/watch?v=trK1cZTpa14
14:51:35 <kparal> jskladan: no wonder your battery is getting low
14:51:45 <jskladan> :D
14:52:42 * kparal assumes everyone's watching it
14:54:07 * tflink assumes that there are no other topics
14:54:13 <jskladan> nope
14:54:37 <tflink> beyond remixes of childrens' programming
14:55:08 * jskladan has cute kittens, if anyone's interested
14:55:38 * tflink debates changing the topic to cute kittens
14:55:53 <tflink> but i think that endmeeting works better :)
14:56:03 <tflink> thanks for coming everyone
14:56:08 * tflink will send out minutes shortly
14:56:12 <tflink> #endmeeting