14:02:47 #startmeeting qadevel 14:02:47 Meeting started Mon Oct 6 14:02:47 2014 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:02:47 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:02:57 #meetingname qadevel 14:02:57 The meeting name has been set to 'qadevel' 14:03:03 #topic welcome 14:03:41 anyone here for the qadevel meeting? 14:03:48 * kparal is here 14:05:42 mkrizek: welcome 14:05:47 * mkrizek joins 14:05:58 I don't think jskladan will come 14:06:20 kparal: any idea if there's a better time for him? 14:06:33 I suppose I could just ask him directly :) 14:06:38 I had a hard time reaching him today as well 14:06:54 probably best to talk to him directly 14:07:02 I can do that tomorrow 14:07:11 hrm, no interns, either 14:08:04 that's probably my fault, I didn't ask them to come explicitly 14:08:09 like I said, it'll be short :) 14:08:18 #topic iteration 6 status 14:08:37 some of the bits have been done, but a lot of the tickets are still open 14:08:55 https://phab.qadevel.cloud.fedoraproject.org/T322 14:10:11 I have to admit I haven't followed the latest development and I didn't have time to work on any ticket lately 14:10:29 no worries, I don't think you had any iteration6 tickets 14:10:50 jsedlak said he had a patch for T338, was it not posted to Phab? 14:10:58 the big missing pieces that I can think of are: bodhi retries, depcheck output and the backup tickets 14:11:03 oh, it's linked there 14:11:40 I think it's waiting on him 14:12:05 yeah, just reading through it 14:12:33 I think retrying just 5xx is good enough for the moment, but I don't mind either way 14:12:44 but if we need to push it quickly, we can just take it as it is 14:12:56 all the error I've seen from Bodhi are 5xx 14:14:03 yeah, I can patch the use of 'i' as a variable 14:15:09 btw, some return codes are not errors, like 3xx redirect, so we need to take that into account when catching anything except 200 ok 14:15:09 I assume that he's gone for the day? 14:15:30 I'm today at our local university, so I don't know whether he was in the office 14:15:35 true, but a 3xx or a 200 shouldn't throw an error 14:15:43 since he's not online, probably is not anymore 14:18:06 I don't see john online either 14:18:17 kparal: have you talked to him recently about the depcheck output? 14:18:35 he asked some questions and advice 14:18:54 he showed me some proof of concept new log output, I asked for some changes 14:19:02 that was last week 14:19:07 he was having some trouble with valid tap generation on friday but I've not heard back from him since then 14:19:10 not sure when exactly 14:20:04 how long do we want to wait on that? 14:20:05 I have no further into than that 14:20:09 *info 14:20:24 eh, I'll chat with him if/when he shows up online later today 14:20:59 maybe ask him to push his changes to some git branch, so we can pick it up if we're in a hurry and want to finish it ourselves 14:21:20 yeah, will do 14:21:36 I'd like to get everything deployed by tomorrow, if possible 14:21:56 and switch off autoqa on friday 14:22:15 that would give us until tuesday to back out of it, if needed 14:22:41 if I'm remembering the schedule correctly, freeze starts on tuesday 14:22:58 2014-10-14 14:23:02 right 14:23:33 I'm quite certain people will be unhappy about the current depcheck output. so we should sort it out before then 14:23:42 yeah, agreed 14:24:07 I'll talk to Josef tomorrow and one of us will take it as a top priority task 14:24:18 * tflink is also wondering if making a few small resultsdb changes would be good to quell frustration 14:24:36 just please make sure John pushes his stuff somewhere where we can find it 14:24:43 will do 14:25:03 #action tflink to get status update on depcheck enhancements from handsome_pirate 14:25:25 the alternative is to delay taskotron production, which I guess you're not happy with 14:25:36 I'd rather not do that, but we can 14:26:14 if we deploy it shortly before freeze and then we find out serious problems during the freeze, what can we do about it? 14:26:14 maybe syncing up on thursday or so would be wise - to make the final decision 14:26:36 we can ask for freeze breaks 14:27:04 ok 14:27:21 I'm planning to keep autoqa in hibernation for a while 14:27:38 ie - just turn it off instead of deleting anything 14:28:01 sure, that's a good idea 14:28:07 anything else for iteration6? 14:28:15 yeah 14:28:23 https://phab.qadevel.cloud.fedoraproject.org/T333 14:28:32 this seems high priority to me 14:28:44 just found out what it was earlier today 14:28:47 * tflink is thinking that we should just extend the iteration for another week since freeze is next week 14:29:06 mkrizek: good find, your proposed fix sounds good to me 14:29:21 cool 14:29:36 * mkrizek is fine with extending the iteration for another week 14:31:02 #topic next iteration 14:31:47 outside of the depcheck output ticket, anything else that should be done before freeze? 14:32:06 * tflink needs to file a ticket about blockerbugs spamming him relentlessly 14:32:39 nothing I can't think of 14:32:42 *can 14:32:53 what about upgrading phab? 14:33:00 is it affected by freeze? 14:33:02 oh yeah, can do 14:33:08 technically, no 14:33:22 but there's no reason not to update it if your tests turned out well 14:33:27 I tested the stg version 14:33:33 #action tflink to update production phab 14:33:36 there should be a ticket somewhere for you to upgrade it :) 14:34:06 in infrastructure project 14:35:11 any objections to just extending iteration6 instead of going through all the ticket churn of doing iteration 7? 14:35:35 no objections 14:36:12 #info will extend iteration 6 for 2 more weeks instead of closing it out - freeze starts next week and a new iteration would mean a lot of ticket churn 14:38:21 any other topics that I've forgotten before moving to open floor? 14:39:02 nothing here 14:39:11 #topic open floor 14:39:17 no further topic either 14:39:31 any other things before we close out? 14:40:39 * tflink takes that as a no 14:40:47 thanks for coming, everyone 14:40:53 * tflink will send out minutes shortly 14:40:56 #endmeeting