15:00:33 #startmeeting Fedora QA meeting 15:00:33 Meeting started Mon Jun 9 15:00:33 2014 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:33 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:38 #meetingname fedora-qa 15:00:38 The meeting name has been set to 'fedora-qa' 15:00:41 #topic Roll call 15:00:47 ahoyhoy folks, who's around? 15:00:58 * satellit listening 15:01:01 * nirik is lurking around in the back 15:01:07 * threebean lurks too 15:01:59 * pwhalen is here 15:02:01 satellit: did i point you at https://bugzilla.redhat.com/show_bug.cgi?id=1105720 btw? that's my bug for the welcome screen icon issue 15:02:25 ok saw it on todays workstation (missing) 15:03:20 * brunowolff is lurking 15:03:24 * tflink is here 15:03:38 that's quite enough lurking 15:03:45 * adamw proposes Anti-Lurking Ordinance 15:04:34 we seem to be missing all of the brno folks 15:05:04 brno fedora-qe folks, rather 15:05:14 * kparal here 15:05:41 hi there 15:05:59 welp, let's dive in - it's a light agenda this week anyhow 15:06:05 shouldn't keep anyone from their first beer of the evening for too long :) 15:06:23 did anyone have any agenda items i missed, btw? 15:06:37 nothing I can think of, no 15:07:20 not here 15:07:32 * roshi is here 15:08:17 alrighty then 15:08:20 #topic Fedora 21 status 15:08:44 so folks have been doing a good job of running tests from the Rawhide validation matrices and filing bugs - many thanks to all for that 15:09:39 #info there has been solid progress on Rawhide validation work, thanks to all 15:09:58 we had a temporary help in michalv 15:10:19 We currently have 8 proposed blocker bugs - if that gets up any higher we might want to run a review meeting, in case the accepted blocker count gets too high and we have to start poking devs...sound sensible? 15:10:31 +1 15:10:37 kparal: yup, and good to see pwhalen pitching in for ARM 15:11:13 #agreed we will run a blocker review meeting if the blocker count gets much above 10, so we can keep control over the number of accepted blockers 15:11:31 sounds good to me 15:11:33 +1 15:11:36 roshi: if i can ask...what's the plan for Test Days this cycle? have you been working on that? 15:11:42 +1 15:12:09 there was one person asking for infra hw for test days - but then he just kinda disappeared 15:12:38 desktop qe reported some tickets and asked for test day schedule 15:12:44 there are a couple tickets in for Alpha 15:12:47 I think pschindl could handle that in this cycle 15:12:55 haven't looked at them though 15:13:10 OK 15:13:17 i was expecting kind of a flood of them for new .next features 15:13:17 last week felt like a short week, but I can look at them today and follow up on the couple tickets there are 15:13:21 bit worrying if we're short 15:13:35 roshi: maybe you and pschindl together? 15:13:38 any other volunteers? 15:13:45 that works for me 15:13:50 Today's rawhide build (which hasn't finished yet) will include the mass rebuild, so when it finishes it will be a good time to upgrade to rawhide for testing day to day use. 15:14:14 get the existing tickets turned into events, and maybe send out a follow-up call for test days...you can also go through the accepted Change list and reach out directly to owners of changes that look like they could do with a test day 15:14:18 brunowolff: good call 15:14:42 we can do that adamw 15:14:44 #action roshi and pschindl to work through test day proposals and perhaps try to drum up some more .next Change test days 15:14:48 awesome 15:14:57 looks like 3 proposed in 2014 so far 15:15:23 we finally have to deploy that fedocal -> wiki script, so that we have just a single place to manage test day schedule 15:15:30 * pwhalen needs to request a test day for ARM 15:15:35 #info brunowolff points out that Rawhide mass rebuild will be in today's Rawhide compose, which marks a decent point to do some Rawhide testing - https://fedoraproject.org/wiki/Releases/Rawhide 15:15:41 roshi: also check if you got any ' 15:15:42 the script should be working, written by lbrabec a few months ago 15:15:46 the three we have for this year were looking for a time between alpha and beta 15:15:50 'unofficial' proposals as replies to the call for test days etc 15:15:59 roshi: ah right, the desktop ones 15:16:18 yeah - which is why I didn't look very hard at them since we don't know when alpha branch is actually going t obe 15:16:39 you can start pulling the event together ahead of time, though, always good to be prepared - but yup, it's not urgent, just wanted to make sure it's on someone's agenda 15:16:50 I'll dig through the mails as well 15:17:12 you can just assign a date as a best guess to get it on the schedule, or just start working on the wiki page as an undated draft and move it later 15:17:34 good point 15:18:20 cool cool 15:18:44 kparal: can you make sure roshi/pschindl are up to speed on that script? 15:19:10 ok 15:19:27 thanks 15:20:23 alrighty...anything else for .next? 15:20:36 i've been working on the Product release criteria, but that's mainly for the WGs not for us 15:20:42 I'm trying to suss out what *exactly* cloud wants to test 15:20:55 i'll try the get the Workstation criteria rolling this week, i think roshi is on cloud 15:21:01 roshi: heh, always fun 15:21:26 well, they keep talking about automated testing - but there currently isn't anything they have even scripted as far as testing goes 15:21:52 so that bit is going to be pretty much from scratch 15:22:03 afaict 15:22:30 roshi: where have you been talking to them? in meetings? i don't see anything on the mailing list since may 29 15:22:35 (or was it before that?) 15:22:44 in meetings 15:22:50 rgr, i'll have a look at logs 15:23:05 I'm going to hit up the mailing list today looking for some info 15:23:15 I've asked in irc a couple times but never got an answer 15:23:41 if we need to be...robust in making it clear that they need to have a viable test plan in place for Alpha, with or without automated testing, let's do that...better than having a trainwreck later 15:24:02 yup 15:24:10 make sure they understand that until they have their automated testing *actually up and running* they need a viable plan for ensuring their bits work well enough manually 15:24:18 cool cool 15:24:19 * roshi isn't a fan of train wrecks 15:24:22 =) 15:24:38 except maybe in movies 15:24:59 which gives us a smooth segue into... 15:25:03 #topic Taskotron status 15:25:09 (damn, i'm on form this morning) 15:25:14 how're we doing? :) 15:25:35 things are moving along 15:25:47 any news from the FAD? 15:25:58 yeah, that sounded productive - though it seemed like a lot of work was on bodhi2 15:26:09 yeah, a lot of the FAD was around bodhi2 15:26:22 I read some reports on planet fedora, but they were mainly about bodhi2, not taskotron 15:26:52 but we did get a plan to move qa infra stuff to being more directly managed by infra instead of in our own little fiefdom/world/whatever it is 15:27:08 that sounds good, seems like a more efficient approach 15:27:12 yeah, that was a plus. :) 15:27:15 it's going to take time but in the end, it will mean that I'll be less of a SPOF for infra stuff 15:27:19 will hopefully take some load off of tflink 15:27:34 * tflink will be doing a blog post on the taskotron parts of the FAD today or tomorrow 15:27:46 great, will read it 15:27:56 awesomesauce 15:27:57 we talked more about getting bodhi2 to display results from resultsdb instead of us posting comments 15:28:04 we got some of the integration between resultsdb and bodhi figured out, at least in theory. 15:28:06 * threebean nodes 15:28:11 jeez, *nods. 15:28:16 that's always the easy part, right? 15:28:20 ;) 15:28:43 I requested a feature to assign bodhi ids to updates @ filing time instead of @ push time 15:28:49 isn't using fedmsg easier to implement than querying resultsdb? 15:28:53 is the plan to get all this done as part of primary taskotron deployment? or are we aiming to do initial taskotron deployment 'qa style', against bodhi1, using comments? 15:29:03 kparal: if they duplicate results storage, sure 15:29:16 * threebean nods 15:29:18 bodhi IDs at filing time would be really great 15:29:23 adamw: the plan for initial deployment is a mostly drop-in replacement for autoqa 15:29:34 bodhi comments and all 15:29:41 but, I'm hoping to push bodhi to not store results... so that only resultsdb stores results (it's in the name..) 15:30:25 whether we'll actually be able to do that for update gating or not is another question, though 15:30:39 but that'll have to wait until we're in a better position to actually plan for that 15:30:45 OK 15:31:04 so are we still on track to be operational around branch time? 15:31:41 outside of the FAD, our focus is on improving documentation, making sure that the base checks (rpmlint, depcheck, upgradepath) are ready and getting the system as a whole solid 15:31:59 yeah, I don't know of anything that is likely to disrupt that plan 15:32:19 cool. 15:32:38 (except excessive numbers of meetings? :>) 15:32:48 the current plan is to have taskotron production running the first week of july to get any kinks worked out 15:33:04 then switch off autoqa right before branch 15:33:12 #info taskotron deployment work continues and we remain on schedule for production by Branched date, further down the road we have plans for improved integration between taskotron and bodhi2 15:34:22 tflink: did hadess talk to you about his need for automated open network port testing? 15:34:49 adamw: yeah, it sounds do-able but we're mising some features in taskotron that would be needed to support the testing 15:35:09 ah :/ 15:35:20 i was hoping it'd work nicely as an initial third-party test situation 15:35:29 we haven't set our post-replacing-autoqa priorities yet, so I couldn't give him a definitive answer on when it could happen 15:35:33 something by a known-good dev with a strong need for it (so it was unlikely to get abandoned) 15:35:47 adamw: the problem is that the tests he wants to run really need disposable test clients 15:36:17 ah, yeah, that testing does have a fairly strong need for a clean slate. 15:36:31 I'm not keen on the idea of installing a bunch of rpms on whichever client that task happens to run on 15:37:26 roger 15:37:33 any other taskotron news? 15:37:44 not that I can think of 15:39:26 okelydokely 15:39:44 moving on, then 15:39:46 #topic open floor 15:39:51 anyone have anything else? 15:40:22 nothing here 15:40:25 * roshi can't think of anything 15:41:05 .fire roshi insufficient thought levels 15:41:05 adamw fires roshi insufficient thought levels 15:41:51 I'd like to interject with an obligatory reminder that communicating things that could go in the release notes is helpful 15:41:57 ...so I did. 15:42:01 once you reach negative thought levels, the universe seg faults and then you have ALL the thoughts 15:42:06 it's all part of the plan 15:42:27 a cunning one indeed 15:42:46 * tflink didn't realize that the universe was succeptible to heartbleed 15:42:56 #info randomuser reminds us that we should communicate stuff we come across that ought to go into the next release's release notes - ping randomuser or the docs team via irc, email, or use bugzilla 15:43:18 thank you, adamw, well stated 15:45:14 alrighty then, if there's nothing else 15:45:19 * adamw lights the Quantum Fuse 15:45:33 that's not how you use a quantum fuse...universe explodes 15:46:05 i tought you first had to check if the quantum fuse was already set before setting it ? 15:46:15 (despites the risk of discovering it already exploded) 15:46:39 misc: you might be right, or you might not. 15:48:27 thanks folks! now back to your rss feeds^H^H^H^H^H^H^H^H^H^H^H^H^H^Hwork 15:48:27 well, regardless versions of us will be around for all eventualities, right? 15:48:30 * randomuser observes the meeting is both ended and not ended, breaks causality 15:49:02 #endmeeting