16:02:20 #startmeeting Fedora QA meeting 16:02:21 Meeting started Mon Mar 3 16:02:20 2014 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:21 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:02:26 #meetingname fedora-qa 16:02:26 The meeting name has been set to 'fedora-qa' 16:02:30 #topic Roll Call 16:02:32 * Viking-Ice half in half out 16:02:39 who's around for some qa funtimes? 16:02:48 (and/or Oscar post-mortem?) 16:03:01 * nirik is lurking around in the back. 16:03:12 * mkrizek is here 16:03:50 * brunowolff is here 16:04:06 * pschindl is here 16:04:13 * tflink is present 16:05:05 * roshi is here 16:05:42 nice turnout 16:06:13 * cmurf is here 16:06:15 here 16:07:07 #topic Previous meeting follow-up 16:07:31 "adamw to draft up a proposal to the Anaconda devs about guided partitioning screen", "cmurf to fill in blanks on the proposal" - this rather got overtaken by events 16:07:45 as the desktop and server WGs both discussed it as part of their tech specs 16:07:52 whoops, call of nature 16:07:54 #chair tflink cmurf 16:07:54 Current chairs: adamw cmurf tflink 16:08:02 cmurf want to pick up the story while i go answer? 16:08:13 Sure 16:09:38 Summary of 150+ emails on the subject is: Server WG still leans to XFS on LVM. Workstation WG hasn't clearly decided. Both are leaning toward one default no choices (the end of Partition Scheme pop-up in the guided path). 16:10:13 At issue is, if Btrfs is ready sooner than later, then why should Workstation switch to XFS now only to switch again, to Btrfs. 16:10:28 How does it affect QA? 16:10:35 testing paths 16:10:54 but both choosing traditional-fs-on-LVM with no alternatives would be a decent outcome. 16:11:01 If Server is XFS on LVM, and Workstation is something else, then we effectively have two automatic/guided paths even though there isn't a Partition Scheme pop-up menu. 16:11:44 If Server and Workstation products agree on a default with no alternate, that means the same code path is in place in the installer, so it wouldn't matter whether testers use Server or Workstation products to do matrix testing of automatic/guided partitioning. 16:12:07 strictly speaking 16:12:50 well, i believe server still wants to choose a variant default partition layout, so we're still gonna have differences 16:12:55 but the closer we can make 'em the better 16:13:02 ? 16:13:08 "variant default layout" what is that? 16:13:10 they don't want a /home partition by default 16:13:36 i think the plan was to have /boot , root and swap, but instead of /home in the rest of the space, leave it unallocated for the admin to use 16:13:46 pretty sensible idea, really. 16:13:54 *shrug* ok well that's less complicated as it's remotely possible /home doesn't get mounted during boot 16:14:22 yeah, and if we're on LVM by default, presumably they mean 'include it in the VG but don't create an LV', so it shouldn't change things too much. 16:14:28 anyhow 16:14:31 So i'd still say we'd not need to apply the *full* matrix to each product. 16:14:36 hopefully, yeah. 16:14:49 i think the action item for now is to keep watching/driving the WG discussions, i guess 16:14:51 would you agree? 16:15:05 and we'll see what comes out of today's FESCo meeting 16:15:05 Yes. And for me to not have any more matthew mcconaughey moments. 16:15:10 =) 16:15:13 alright alright alright 16:15:19 alright 16:15:44 #action adamw and cmurf and anyone else interested to keep watching and driving the product WG discussions on filesystems 16:16:01 #topic Fedora.next plans 16:16:08 so we already kinda went into this, but let's broaden it out... 16:16:34 in case anyone hasn't seen them, the workstation tech spec as it stands now is at https://fedoraproject.org/wiki/Workstation/Technical_Specification , and the server one is at https://fedoraproject.org/wiki/Server/Technical_Specification 16:16:52 #info both specs are meant to be reviewed by FESCo for schedule setting purposes today, AIUI 16:17:25 adamw: No FESCo meeting today. It's on Wednesday. 16:17:27 they look pretty reasonably scoped to me; anyone have any notes on either? 16:17:29 sgallagh: d'oh 16:17:31 #undo 16:17:31 Removing item from minutes: INFO by adamw at 16:16:52 : both specs are meant to be reviewed by FESCo for schedule setting purposes today, AIUI 16:17:36 EYYYYYYY 16:17:38 who fixed that?! 16:17:39 The due date was today to allow FESCo time to review it ahead of time 16:17:46 #info both specs are meant to be reviewed by FESCo for schedule setting purposes on Wednesday 16:17:51 * adamw owes someone many, many beer 16:18:31 one thing that occurred to me is to count up the possible deliverables load 16:18:36 * danofsatx-work thinks it was nirik 16:19:02 /me is here 16:19:14 I just applied a patch from misc for it. ;) 16:19:55 nirik: misc: please send me instructions to cause the delivery of MUCH BEER 16:20:19 so, server lists a netinst.iso and a DVD-style deliverable 16:20:22 my deliverable count is as follows 16:20:24 Server: net install, DVD/USB 16:20:28 workstation lists a live image 16:20:36 Workstation: net install, live media x2 (gnome/kde) 16:20:42 er, what? 16:20:43 no. 16:20:49 no live media? 16:20:53 " Installation methods and media We will produce a live .iso image." 16:21:00 OK 16:21:03 they don't list a net install. and they're not doing a KDE image. 16:21:13 hrmm 16:21:22 adamw: I am already asking budget to construct a pipeline from Canada to Paris 16:21:23 how exactly the net install thing is going to work out is still an open question 16:21:50 ahh yeah there is at the bottom of the doc on workstation 16:22:14 i mean, we haven't nailed down the details of whether the Products can be implemented simply as comps groups and we can have / want a generic netinst, or if we want product-specific ones, or what 16:22:32 right 16:22:40 but just in terms of what the product WGs are talking about now, we've got basically three Product deliverables, ignoring the arch question 16:22:58 that more or less matches the current situation, so it doesn't seem like we're making things massively worse, at least. 16:23:49 So if KDE is still a release blocking desktop (?) how is it going to be installed in order to be tested? 16:23:51 #info server lists a netinstall and a DVD-style deliverable, workstation lists a live image deliverable. Server explicitly states it will provide media for all three primary arches, Workstation does not talk about it (yet). 16:23:56 cmurf: spin. 16:24:14 A spin that is release blocking? Or is the release blocking being lifted for KDE? 16:24:30 cmurf: there'll still be a KDE live image, I'm sure. it won't be part of the Workstation product. whether or not we block release on it hasn't been decided yet, afaik, though the default assumption would be that we do. 16:24:40 OK 16:24:48 we should probably ask fesco to think about it, i guess. 16:26:56 #action adamw to ask fesco to consider KDE release blocking status 16:27:14 any other thoughts on the current .next stuff? anything i've missed? 16:28:16 nope i just skimmed both side by side 16:28:55 i think cloud could use any net install and maybe the Server image along with a kickstart. I think they envision kickstart and pre-built images being their deliverables. 16:29:24 cloud doesn't use anaconda. 16:29:29 yeah, pre-built images. 16:29:47 welp, moving along then 16:29:49 #topic Taskotron check-in 16:30:08 just thought it would be good to sync up on taskotron status, as it's .next-related and we didn't talk about it for a bit 16:30:20 tflink? 16:30:25 anything in particular? 16:31:13 will it auto bake and ship us unicorn poop cookies? 16:31:20 the item of largest interest is that we didn't hit our initial deadline on Friday 16:31:34 for ... various reasons 16:31:56 at this point, I estimate that we're 3 weeks behind 16:32:08 adamw: well it's still not clear if kde is going to be part of workstation or not (and thus separate kde live) or even product 16:32:52 work has been progressing on the runner, on depcheck's replacement and on getting upgradepath ready for use in taskotron 16:33:25 jreznik: i thought that was fairly clear. 16:33:37 jreznik: i don't see any indication that workstation WG wants to own KDE deliverables. 16:34:04 jreznik: read the "Core Package list" part of the WS spec. "List the core packages of the product. This list includes all packages that will be shipping on the core media." 16:34:29 it includes gdm and gnome-shell and control-center and gnome-software. none of those would be on a KDE live image. 16:34:48 sorry, tflink. 16:35:07 tflink: so, what was meant to be ready by friday? sorry, i've lost track of the plan 16:35:15 adamw: an autoqa replacement 16:35:32 ah, so we were supposed to have the autoqa-equivalent tests deployed by friday? gotcha. 16:35:53 checks and results reporting, in at least staging form, yes 16:36:12 so your current read is we can be up and running at that level in three weeks 16:36:49 that's my hope, yes 16:36:59 emphasis on staging level, though 16:37:29 I suspect that we're going to hit some integration problems but it's hard to judge how bad until we get it in staging 16:37:42 integration/scaling 16:38:33 OK 16:38:44 well, i don't think three weeks out is too terrible 16:38:54 nirik: is fesco likely to lose their pants over it? 16:39:11 over what? /me reads back up 16:39:21 nirik: taskotron being behind schedule 16:39:48 ah. well, it is what it is... ;) 16:40:25 tflink: looking on other things happening now - if you're week behind schedule, you're almost there 16:40:31 hehe 16:40:44 jreznik: I suppose that's one way of looking at it :) 16:42:54 #info taskotron currently estimated to be around three weeks behind schedule, meaning staging deployment of autoqa-equivalent coverage in three weeks 16:43:04 thanks tflink 16:43:07 #topic Update policy 16:45:20 so, we had a few prominent updates with dependency issues lately 16:45:51 a LibreOffice update and a dnf update 16:46:03 i went through the last three weeks of depcheck tests and found some less prominent ones that i reported to their maintainers 16:46:23 kk has been making his usual noises about how terrible everything is 16:46:46 i did tentatively suggest on devel@ that we could disable autokarma for any update that fails the depcheck test 16:46:52 anyone like/dislike that idea? have any other ideas? 16:47:39 * nirik thinks thats a fine idea. 16:47:45 * tflink as well 16:47:57 I don't see why not 16:48:04 how would it be implemented, though? 16:48:15 that seems somewhat non-trivial to me 16:48:49 there's already a bodhi patch I think. 16:48:51 unless scanning text of comments made by the autoqa user is acceptable 16:49:13 eh, it'd only be a relatively short-term stopgap 16:49:18 so that kinda ugliness works for me 16:49:25 case-matched FAILED should be a pretty safe check... 16:49:53 and since it's just disabling automatism, it shouldn't need any overrides 16:50:02 the only issue i see with it is we do know about some pretty dependable false-negatives. anything with explicit Conflicts is gonna get hit every time. but meh 16:50:06 yep 16:51:06 what are the rules for the tests being run atm? 16:51:17 test is run on submission to testing, on edit, and...? 16:51:53 (anything else?) 16:52:16 adamw: are you asking about scheduling for autoqa or the rule for disabling automatism? 16:55:19 scheduling for autoqa 16:55:37 what i'm concerned about is autokarma hysteresis: the bot turns it off, the submitter turns it on, the bot turns it off again... 16:55:54 depcheck is scheduled on tag to fXX-updates-testing-pending and fXX-updates-pending 16:56:29 comments are made to bodhi for each tag, or if the status changes 16:57:41 OK. i don't think that ought to cause hysteresis, then. 16:57:49 so i guess i'll action myself 16:58:28 #action adamw to propose disabling of autokarma on depcheck fail (to FESCo) as a stopgap till more reliable depcheck with taskotron 16:58:41 #topic Open floor 16:58:42 anything else? 16:59:25 adamw: there are more bits that would be required for actual enforcement of automated checks 16:59:42 roger 16:59:57 and those bits are currently not planned as part of taskotron 17:00:12 I'm not saying it can't happen, just that it's not planned (yet) 17:00:28 * tflink was under the impression that enforcing results wasn't the highest priority 17:01:00 Oh, I had one thing to mention... 17:01:55 tflink: i think it'd be a substantial win, at least. 17:01:55 changes to abrt private bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1044653 if anyone objects to the proposed setup/changes there, please note your rational objections. ;) 17:03:04 #info changes are planning to the handling of abrt private bugs: see https://bugzilla.redhat.com/show_bug.cgi?id=1044653 for details and post any concerns there 17:04:39 anything else, folks? 17:05:47 nothing here 17:05:48 * adamw sets Quantum Fuse 17:06:52 what's the fuse attached to? 17:07:11 some form of anti-meeting device? 17:07:24 you know what, i've never looked 17:07:58 * roshi just wants to know if we're deleting universes somewhere in the multiverse on accident or something... 17:08:10 quite possibly! 17:08:17 thanks for coming folks, and time for another universe to die 17:08:20 #endmeeting