15:01:52 #startmeeting Fedora QA Meeting 15:01:52 Meeting started Mon May 26 15:01:52 2014 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:52 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:02:02 #meetingname fedora-qa 15:02:02 The meeting name has been set to 'fedora-qa' 15:02:08 #topic Roll call 15:02:14 ahoyhoyhoy 15:02:21 * satellit listening 15:02:26 * mkrizek is here 15:02:35 who's around for qa fun times? 15:02:46 * pschindl is here (but I have to leave in 15 minutes) 15:03:00 our first viking-ice free meeting? :( 15:03:21 * kparal here 15:03:55 let's call it "comma-full" meeting 15:05:04 * tflink is around 15:07:21 hehe 15:07:45 #chair misc tflink 15:07:45 Current chairs: adamw misc tflink 15:08:37 okey dokey, let's gooo 15:08:42 #topic Previous meeting follow-up 15:09:44 #info "adamw to synthesize server, desktop and cloud test outlines to give a rough idea of required fedora.next test coverage and kickstart a discussion of how it should be organized" - did that: https://lists.fedoraproject.org/pipermail/test/2014-May/121396.html , and it's the first topic for discussion this week 15:09:55 that's all i had as a formal action item, anything else to follow up on? 15:13:14 well, I guess not! 15:13:25 #topic Fedora 21 test plan discussion 15:13:39 so, as linked above, i put up a draft f21 'test plan' as a sort of trial balloon 15:13:46 did folks get a chance to read it yet? any thoughts on the plan? 15:14:11 I read it briefly 15:14:38 I think it's good 15:14:49 I studied mainly the responsibilities section 15:15:03 I think it proposes a reasonable balance 15:16:08 are the WG's criteria going to be part of the blocker meetings, then? 15:16:20 or is the idea to separate the processes? 15:16:45 that's a good point, are we going to vote on their criteria, or will their representatives always be present? 15:17:29 will workstation only be a live or a boot.iso choice? 15:17:50 tflink: i was kinda assuming we'd keep the same combined process, but it's a good question 15:18:07 satellit: I believe their only official deliverable is the live 15:18:12 k 15:18:39 they might not be interested in attending a blocker bug meeting where generic/other WGs' issues get discussed 15:18:57 tflink: we do have the option of 'devolving' the process and letting WGs handle their own blocker issues 15:19:03 so maybe we will need to do some time slots, covering particular WG's issues 15:19:04 might be interesting to get the WGs'/fesco's take on that 15:19:35 if they're deciding on the criteria, it seems a little odd that we'd be interpreting them 15:20:01 the release schedule is the same for all WGs, right? so a single WG can block other products from releasing? 15:20:29 kparal: more blocker review meetings :) 15:20:46 have any of the WGs started on the criteria process? 15:20:46 kparal: at least for f21, indeed it is 15:20:52 tflink: not afaik 15:21:12 tflink: I'll need to develop some ack-ing bot, after all 15:21:57 kparal: no kidding 15:22:24 f21 branches in what, a little over a month? 15:22:35 if they can block other products, I think we should be involved in the blocker bug discussion. although we might lack knowledge to properly understand some of those very specific issues. that's a bit unfortunate 15:22:39 forget autoqa, clearly autoack is the most important dev priority 15:22:45 or is that date still "no earlier than"? 15:23:08 kparal: well, we can be involved however it's organized, i guess 15:23:17 tflink: July 8, 'no earlier than' 15:23:20 https://fedoraproject.org/wiki/Releases/21/Schedule 15:23:47 sounds like it's up for discussion again @ the next fesco meeting 15:24:24 the schedule, I mean 15:25:01 interesting 15:25:12 but yeah, we have at least 6 weeks or so to get the criteria and process nailed down 15:25:58 #info tflink noted that it has to be decided whether Products will have their own blocker review process or we will retain one project-wide review process 15:26:12 if this is going to involve feature requests for the tracker, it'd be nice to know soon :) 15:26:39 eg, tracking multiple products on the same page, multiple trackers 15:27:55 thinking about it, trying to split up the process would add quite a lot of complexity 15:28:31 we'd have to somehow split the bugs by product, which either involves asking reporters to do it at the 'blocker nomination' stage and trusting them to get it right, or some kind of triage 15:28:45 unless bugzilla is going to be split per-Fedora-product, which i don't think is going to happen 15:30:29 keeping them together is going to be more complexity as well, but probably less than splitting them up 15:30:46 I can see getting into a situation where a blocker is bounced between meetings at least once 15:31:33 * satellit if desktop is on boot.iso and workstation is the live version...how note differences in BZ? 15:32:23 tflink: yeah, though we'd want to try and make sure we had a rep from each group at each meeting 15:32:28 or at least each meeting we had a blocker from their product 15:33:02 satellit: yeah, that'd be fun 15:33:23 satellit: if the bug really only happened from boot.iso, it wouldn't be a Workstation product blocker 15:33:32 k 15:33:56 adamw: I suspect that isn't going to work incredibly well given past scheduling fun 15:34:50 tflink: we'd have to be somewhat more forceful about it than we are about getting devel/releng folks to show up 15:36:33 * satellit is desktop still a blocking DE? in f21 15:36:46 satellit: there's no DE called "desktop" 15:37:02 gnome3 15:37:04 satellit: there's a DE called GNOME, and it's still release blocking of course 15:37:10 k 15:37:25 though i do need to revisit the criteria language about 'release blocking desktops' and see if it still makes sense in a .next world 15:38:13 * satellit but no live for testing Gnome-desktop 15:39:08 well, the Workstation product basically is the GNOME live. 15:39:38 whether we'd count issues from installing GNOME via boot.iso as release blocking is kinda an interesting question, it ultimately depends on how important the project decides boot.iso is, i guess 15:41:11 there are a few things like that which i think we're gonna have to to shake out as we go along, hard to predict everything 15:42:42 welp, thanks for the feedback so far 15:42:43 anything else? 15:44:03 other than making sure we get product WG feedback, not much 15:44:07 of course 15:44:24 welp, then 15:44:26 #topic Open floor 15:44:33 anything else? how's taskotron coming, tflink? 15:44:51 we're adjusting to a time-based release cadence 15:45:22 trying to get ready to deploy to a production system - there's lots of "behind the scenes" stuff left to do in order to get ready for that 15:45:41 autoqa-stg has been retired 15:46:25 sounds like we're in the finishing stretch at least 15:46:33 in theory, depcheck is almost ready to start running in dev/stg 15:46:47 #info taskotron is doing 'behind the scenes' preparation for production deployment 15:47:21 other work is progressing well, will have another release on friday 15:47:47 coolbeans 15:48:13 the bodhi2/taskotron FAD is next week in Denver 15:49:33 * adamw nods long as if he absolutely knew that was a thing that was happening 15:49:46 adamw: I thought you knew about that, actually 15:50:01 https://fedoraproject.org/wiki/FAD_Bodhi2_Taskotron_2014 15:50:09 where was it discussed? 15:50:52 infra list and meetings, mostly. I don't recall where the initial announcements were 15:51:57 ah, i don't usually follow those :/ 15:52:12 welp, hope it works out well 15:52:38 I think it'll answer a lot of questions about taskotron deployment and future bodhi2 integration 15:52:50 sounds great 15:52:54 specifically making the whole "automation feedback in bodhi comments" thing die in a fire 15:53:07 #info there is a bodhi2 / taskotron FAD occurring next week in Denver 15:53:11 tflink: yaaay fire 15:53:20 * kparal offers the match 15:53:56 kparal: I'll bring the petrol 15:54:43 we have an unlimited budget for FIIIIIRE 15:55:28 welp, sounds like we're about done 15:56:19 * adamw sets Quantum Fuse 15:57:44 * satellit afk.... 15:58:10 thanks for coming, folks! 15:58:58 #endmeeting