14:01:17 <tflink> #startmeeting fedora-qa-devel
14:01:17 <zodbot> Meeting started Mon Jun 30 14:01:17 2014 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:01:23 <tflink> #meetingname fedora-qa-devel
14:01:23 <zodbot> The meeting name has been set to 'fedora-qa-devel'
14:01:27 <tflink> #topic roll call
14:01:33 * roshi is here
14:01:33 * kparal is here
14:01:45 <kparal> pschindl is probably delayed in the traffic
14:02:03 * jskladan is in, although just for a bit, as I'll be having an interview for the next The Show
14:02:33 <tflink> jskladan: I see how this works, you're some big tv star now and don't have time for us :'(
14:02:56 <jskladan> tflink: singatures will be given on the airport ;)
14:03:41 * mkrizek is here
14:04:20 <jskladan> but I pinged the guys I might be coming couple minutes late, so I have about 20 minutes before they'll be getting nervous, I guess
14:04:52 <tflink> jskladan: I think you're set for tasks for iteration 5, though?
14:05:22 <tflink> depcheck and the fxx-updates-testing run issue?
14:05:31 <jskladan> yup
14:06:21 <tflink> cool
14:07:22 <tflink> I think everyone who I was expecting to be here is here, save garretrizal and lbrabec
14:07:27 <kparal> tflink: should we move unclosed tickets from iter4 to iter5?
14:08:22 <kparal> I believe those two are fine with whatever task we throw at them
14:08:42 <jskladan> kparal: ^^ that
14:08:52 <tflink> kparal: just T222, I think. the others are either due to be closed shortly or not needed for iteration 5 (T228)
14:09:25 * kparal was thinking about taskotron.log task
14:09:47 <tflink> i thought that task was already in iteration 5
14:10:02 <tflink> nope, it's not
14:10:09 <kparal> T119
14:10:27 <kparal> let's add it there
14:10:44 * tflink added it to the iteration 5 ticket
14:11:07 <tflink> anyhow, let's get this party started since we have a hard stop
14:11:17 <tflink> #topic Taskotron Status Update
14:11:43 <tflink> #info Iteration 4 is almost done, still waiting on T269
14:12:02 <tflink> #info progress is being made on getting dev/stg/prod systems up using infra's playbooks
14:12:22 <tflink> still hoping to replace autoqa around F21 branch
14:12:33 <roshi> I'll push 269 here in a bit
14:13:05 <tflink> I suspect that there are going to be a few issues raised by infra as we deploy, will file tickets as the issues come up, if they come up
14:13:48 <tflink> as a heads up, I'm going to be looking for (more?) volunteers to help with infra and rel-eng as the tasks become more possible for others to help out with
14:14:37 <kparal> do we already have some volunteers?
14:14:45 <mkrizek> me
14:15:01 <tflink> mkrizek said that he wouldn't quit over having more infra responsibilities :)
14:15:01 <kparal> great
14:15:14 <mkrizek> :)
14:15:18 <tflink> roshi has also expressed some interest
14:15:30 <tflink> I haven't talked to anyone about the rel-eng-ish stuff yet, though
14:15:35 <roshi> I'm interested in all the things
14:15:46 <tflink> that'll be limited to me as long as we're still using a copr with my account
14:16:00 * tflink doesn't know if we can have a group copr account or not
14:16:30 * pschindl is late but finally here
14:16:41 <tflink> I think that's about it for status, unless someone has something I missed
14:16:59 <kparal> pschindl: welcome
14:17:22 * tflink assumes nothing else, moving on
14:17:36 <tflink> #topic Preparing for Production and Replacing AutoQA
14:18:07 <tflink> I added this in mostly to make sure that there's not something we're mising before moving to production and replacing AutoQA
14:18:43 <tflink> Does anyone know of any issues/features which should be added to Taskotron before moving to production?
14:18:52 <tflink> other than the stuff already planned for iteration 5?
14:19:16 * roshi has nothing
14:19:16 <tflink> in retrospect, this should have been after the planning portion
14:19:40 <tflink> if you do know of something, let me know
14:19:51 <kparal> nothing here, at the moment
14:19:51 <tflink> #topic boards for iteration 5
14:20:12 <tflink> one of the things I'd like to try for  iteration 5 is using workboards in phabricator
14:20:27 <tflink> taskotron: https://phab.qadevel.cloud.fedoraproject.org/project/board/2/
14:20:44 <tflink> the basic idea is that we have multiple categories
14:21:14 <tflink> backlog of all open tickets for the project, stuff on deck for the current iteration, stuff in progress and stuff that's pretty much complete
14:21:26 <tflink> any objections to using this for iteration 5?
14:21:36 * tflink will still plan to keep a tracking ticket updated for now
14:21:50 <roshi> I like the planning board idea
14:21:51 <kparal> let's go for it
14:21:56 <mkrizek> no objections
14:22:06 <tflink> #agreed try using workboards for iteration 5
14:22:22 <kparal> does the tickets move automatically between columns?
14:22:23 <tflink> so, please update the workboard as you take tasks and finish them
14:22:28 <kparal> or do we have to shuffle them manually?
14:22:31 <tflink> no, that needs to be done manually
14:22:38 <kparal> ow
14:22:50 <roshi> they don't automatically get moved based on status?
14:22:51 <kparal> I hoped for automatic update
14:23:07 * mkrizek doesn't like it
14:23:28 <tflink> should I undo the #agreed
14:23:29 <tflink> ?
14:23:42 <kparal> well I think it's still better to navigate than a simple tracking ticket
14:23:47 <tflink> closing a ticket will remove it from the workboard
14:24:01 <tflink> it's less clunky to update as well
14:24:02 <kparal> even when in Complete stage?
14:24:09 <roshi> manual isn't bad - I just figured their state would be reflected on the board
14:24:18 <tflink> I suspect that the complete stage will be short-lived if ever used
14:24:27 <tflink> once a ticket is closed, it is removed from the workboard
14:24:42 <kparal> then the Complete column is not really useful
14:24:44 <tflink> the other limitation is that workboards are confined to a single project
14:25:21 <kparal> well let's try it and we'll see
14:25:28 <tflink> but that shouldn't be a huge issue since most of the tickets are in the taskotron project
14:25:35 <roshi> for an iteration the complete column is useful, instead of tasks just disappearing
14:26:07 <kparal> roshi: yes, but the question is whether people will remember it
14:26:22 <tflink> workboards are still a beta feature of phab, IIRC, I could check for new features and do a new build
14:26:38 <kparal> ticket X should be closed because it's not part of current iteration, ticket Y should not be closed because it is part of current iteration. confusing
14:26:40 <tflink> which I may do anyways to get rid of that cursed scolling bug :)
14:26:46 <roshi> if it doesn't take too much time I guess, tflink
14:27:15 <kparal> but anyway, let's try it for this iteration
14:27:21 <roshi> just don't close T until iteration is done, but yeah, I see your point
14:27:34 <tflink> we can figure out the exact process as we go along
14:27:47 <tflink> I suspect that there are other complications that we haven't thought of yet :)
14:28:59 <tflink> #topic conditionals in actions?
14:29:10 <tflink> this is something that I wanted to bring up quick in meeting
14:29:24 <tflink> and of course, I do it after jskladan leaves :)
14:30:05 <tflink> the idea would be to support conditional actions in tasks - something like "when: X == 'foo'"
14:30:27 <tflink> at the moment, the driving use case here is depcheck but this is just one possible solution to the problem
14:30:53 <kparal> I'm very worried about the task yaml file becoming a programming language
14:30:56 <tflink> the problem being: for depcheck runs on fxx-updates-pending, only that tag has to be downloaded and mashed
14:31:37 <tflink> kparal: i think it was destined to have some features like this but yeah, we do need to keep an eye on the complexity
14:31:57 <kparal> so what exactly the problem is with depcheck?
14:31:57 <tflink> but for fxx-updates-testing-pending, it needs to download that tag and fxx-updates-pending
14:32:19 <tflink> so we have different downloads needed for different input tags
14:32:47 <kparal> I see
14:33:29 <tflink> jskladan and I have talked about various solutions to the problem and while this was just one possible answer, I think it could end up being useful in other situations
14:33:47 <tflink> so I wanted to bring it up in meeting as a heads up
14:33:56 <kparal> if the default directive behavior is not sufficient and can't be improved generally, I'd rather stick the implementation into the check itself and call the directives directly
14:34:14 <tflink> kparal: not sure I follow
14:34:17 <roshi> could another directive be created that gave this conditional functionality?
14:34:33 <tflink> roshi: yeah, that was the other solution we were talking about
14:34:48 <tflink> a "smart download" feature that downloads the tags it needs to
14:35:01 <kparal> will it differentiate based on check name?
14:35:09 <kparal> different checks will have different needs
14:35:12 <tflink> haven't gotten that far, to be honest
14:35:26 <tflink> but that's why I was thinking about the conditional actions
14:35:34 <roshi> aiui - directives are simple functions that taskotron can use, so this would fit in well with what a directive is
14:36:03 <kparal> maybe this would be better discussed outside of the meeting with some code samples?
14:36:03 <tflink> I don't think this will be the last task which has some need for that and I think that some simple 'when: <boolean>' would be a good feature to have
14:36:04 <roshi> in my head, for example, koji_directive is the requests lib for taskotron
14:36:43 <tflink> yeah, I don't want to get too far into the details here - mostly wanted to bring it up so folks were aware of it and test for any violent reactions
14:36:52 <kparal> I imagine the depcheck task could provide a simple compute_tags.py file that could be executed prior to the koji task, and it's output (a list of tags) would be fed to the koji task
14:37:27 <kparal> or it can be 'def compute_tags()' inside the main check file
14:37:50 <tflink> yeah, that would be another solution - add a function to depcheck that returns the tags it needs
14:38:32 <kparal> I just don't want to end up with ant -- imperative programming in xml :)
14:38:33 <tflink> anyhow, moving on since we have ~ 20 minutes left. discussion on this topic without jskladan is rather pointless, anyways
14:39:09 <kparal> yes, let's do that outside of the meeting
14:39:15 <tflink> #topic Renaming and clarifying existing names in Taskotron
14:39:21 <tflink> this is another "heads up" topic
14:39:33 <tflink> I don't want to get too far into the details, but wanted to mention T213
14:39:42 <tflink> https://phab.qadevel.cloud.fedoraproject.org/T213
14:40:07 <tflink> The idea is to have consistent, easily associated names for the different parts of taskotron
14:40:21 <tflink> ie, calling taskyaml files "recipes"
14:40:38 <kparal> better suggestions welcome, of course. but I kind of liked this one
14:40:49 <tflink> this will need to be discussed more outside the meeting before implementing anything, though
14:41:13 <roshi> makes sense to me
14:41:24 <tflink> kparal: yeah, that's what I was looking for - more eyes and minds for suggestions
14:41:40 <tflink> but for now, moving on to iteration 5 planning
14:41:47 <kparal> ack
14:41:48 <tflink> #topic Iteration 5 Planning
14:42:06 <tflink> Initial task list: https://phab.qadevel.cloud.fedoraproject.org/w/taskotron-5/
14:42:33 <tflink> pschindl and jskladan are good on tasks at the moment, I think
14:42:49 <tflink> pschindl: I really want to get T119 done before the next release
14:43:30 <tflink> I'll be spending a good amount of time on T234
14:43:33 <pschindl> tflink: I will do my best to deliver it this week.
14:44:18 <tflink> keeping garretraziel on T222 makes sense to me for the time being, he's finding inconsistencies
14:44:18 <kparal> since I'm the most usual trouble maker, I thought about getting involved in T119 as well and helping peter with the process
14:44:32 <tflink> kparal: works for me
14:44:34 <kparal> unless there's something more urgent I should work on
14:44:42 <tflink> the big task that's on list list is T272
14:45:00 <tflink> mkrizek seems to be the natural choice for T271
14:45:10 <tflink> since he's already somewhat familiar with buildbot config
14:45:41 <kparal> T272 will need a wider discussion, and an input from josef about resultsdb side of things
14:45:45 <mkrizek> tflink: works for me
14:46:05 <kparal> oh, that's not T272, that's T264
14:46:11 <kparal> but it's very similar
14:46:41 <tflink> kparal: yeah, it's currently left as "do a proposal for discussion", the implication being that more tickets will be added once a decision is reached
14:46:59 <tflink> hopefully we'll be able to avoid some of our usual descent into details, though :)
14:47:12 <tflink> kparal: yeah T264 is related to T272 but not quite the same
14:47:59 <tflink> roshi: would you take T242? I figure you're a good candidate for that since you're not familiar with the old docs and are more likely to spot issues
14:48:25 <roshi> sure
14:48:44 <tflink> kparal: would you be willing to take T213?
14:48:58 <kparal> definitely
14:49:29 <kparal> me and josef can also take T264 and T272, or at least discuss it properly
14:49:45 <tflink> kparal: ok, sounds good to me
14:49:58 <tflink> it doesn't have to be perfect, just consistent enough for now :)
14:50:13 <kparal> martin's input will help with T272 I guess. he has the most experience with builbot I believe
14:50:23 <kparal> more than zero, to be precise
14:50:42 <tflink> kparal: I think that will end up being mostly in T271
14:50:54 <tflink> the two are related but not completely overlapping
14:51:13 <kparal> ok. still, it's useful to know what's possible in buildbot
14:51:29 <tflink> sure, that makes sense
14:51:53 <tflink> I'd like to avoid too much customization in buildbot for the time being, if possible
14:52:18 <tflink> there's a new, not-quite-backwards-compatible version coming in the near future that will fit our use case better
14:52:47 <tflink> so if possible/reasonable, I'd like to save customization for that new version
14:52:58 <roshi> that makes sense
14:53:45 <tflink> T239 sounds like a good task for lbrabec and garretraziel
14:54:16 <kparal> sure, why not
14:54:26 <tflink> going through and making sure that the defaults for libtaskotron are good for the local use case and making sure there aren't any glaring holes in our documentation
14:55:05 <tflink> cool, I think that's plenty of work for the time being
14:55:27 <tflink> I expect that there will be semi-urgent tasks that come up in the next 2 weeks as we get things deployed
14:55:48 <roshi> that'll be fun :)
14:56:10 <tflink> for certain, quasi-massochistic, definitions of fun, sure :-P
14:56:27 <roshi> :)
14:56:42 <tflink> anyhow, we have 4 minutes left, anything else for iteration 5 planning?
14:56:56 * roshi has nothing
14:57:17 <tflink> the priority for the near future is getting Taskotron deployed into production and to the point where we can turn off autoqa
14:59:13 <tflink> the consistency that we're looking to determine in this iteration and its improvements to consistency are good for making the case of why taskotron is an improvement over autoqa and making it easier for folks to use
14:59:22 <tflink> if there's nothing else, time for
14:59:26 <tflink> #topic Open Floor
14:59:38 <tflink> in the last ... 1 minute - anything that should be brought up?
14:59:45 <kparal> nothing here
14:59:48 * roshi has nothing for open floor, heading to fedora-meeting
15:00:22 <tflink> alrighty, then. I'll set the quantum fuse
15:00:29 * tflink will send out minutes shortly
15:00:35 <tflink> Thanks for coming, everyone
15:00:39 <tflink> #endmeeting