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