16:02:20 <adamw> #startmeeting Fedora QA meeting
16:02:21 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:26 <adamw> #meetingname fedora-qa
16:02:26 <zodbot> The meeting name has been set to 'fedora-qa'
16:02:30 <adamw> #topic Roll Call
16:02:32 * Viking-Ice half in half out
16:02:39 <adamw> who's around for some qa funtimes?
16:02:48 <adamw> (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 <adamw> nice turnout
16:06:13 * cmurf is here
16:06:15 <danofsatx-work> here
16:07:07 <adamw> #topic Previous meeting follow-up
16:07:31 <adamw> "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 <adamw> as the desktop and server WGs both discussed it as part of their tech specs
16:07:52 <adamw> whoops, call of nature
16:07:54 <adamw> #chair tflink cmurf
16:07:54 <zodbot> Current chairs: adamw cmurf tflink
16:08:02 <adamw> cmurf want to pick up the story while i go answer?
16:08:13 <cmurf> Sure
16:09:38 <cmurf> 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 <cmurf> 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 <cmurf> How does it affect QA?
16:10:35 <adamw> testing paths
16:10:54 <adamw> but both choosing traditional-fs-on-LVM with no alternatives would be a decent outcome.
16:11:01 <cmurf> 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 <cmurf> 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 <cmurf> strictly speaking
16:12:50 <adamw> well, i believe server still wants to choose a variant default partition layout, so we're still gonna have differences
16:12:55 <adamw> but the closer we can make 'em the better
16:13:02 <cmurf> ?
16:13:08 <cmurf> "variant default layout" what is that?
16:13:10 <adamw> they don't want a /home partition by default
16:13:36 <adamw> 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 <adamw> pretty sensible idea, really.
16:13:54 <cmurf> *shrug* ok well that's less complicated as it's remotely possible /home doesn't get mounted during boot
16:14:22 <adamw> 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 <adamw> anyhow
16:14:31 <cmurf> So i'd still say we'd not need to apply the *full* matrix to each product.
16:14:36 <adamw> hopefully, yeah.
16:14:49 <adamw> i think the action item for now is to keep watching/driving the WG discussions, i guess
16:14:51 <adamw> would you agree?
16:15:05 <adamw> and we'll see what comes out of today's FESCo meeting
16:15:05 <cmurf> Yes. And for me to not have any more matthew mcconaughey moments.
16:15:10 <adamw> =)
16:15:13 <adamw> alright alright alright
16:15:19 <cmurf> alright
16:15:44 <adamw> #action adamw and cmurf and anyone else interested to keep watching and driving the product WG discussions on filesystems
16:16:01 <adamw> #topic Fedora.next plans
16:16:08 <adamw> so we already kinda went into this, but let's broaden it out...
16:16:34 <adamw> 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 <adamw> #info both specs are meant to be reviewed by FESCo for schedule setting purposes today, AIUI
16:17:25 <sgallagh> adamw: No FESCo meeting today. It's on Wednesday.
16:17:27 <adamw> they look pretty reasonably scoped to me; anyone have any notes on either?
16:17:29 <adamw> sgallagh: d'oh
16:17:31 <adamw> #undo
16:17:31 <zodbot> 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 <adamw> EYYYYYYY
16:17:38 <adamw> who fixed that?!
16:17:39 <sgallagh> The due date was today to allow FESCo time to review it ahead of time
16:17:46 <adamw> #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 <adamw> 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 <mpduty> /me is here
16:19:14 <nirik> I just applied a patch from misc for it. ;)
16:19:55 <adamw> nirik: misc: please send me instructions to cause the delivery of MUCH BEER
16:20:19 <adamw> so, server lists a netinst.iso and a DVD-style deliverable
16:20:22 <cmurf> my deliverable count is as follows
16:20:24 <cmurf> Server: net install, DVD/USB
16:20:28 <adamw> workstation lists a live image
16:20:36 <cmurf> Workstation: net install, live media x2 (gnome/kde)
16:20:42 <adamw> er, what?
16:20:43 <adamw> no.
16:20:49 <cmurf> no live media?
16:20:53 <adamw> " Installation methods and media We will produce a live .iso image."
16:21:00 <cmurf> OK
16:21:03 <adamw> they don't list a net install. and they're not doing a KDE image.
16:21:13 <cmurf> hrmm
16:21:22 <misc> adamw: I am already asking budget to construct a pipeline from Canada to Paris
16:21:23 <adamw> how exactly the net install thing is going to work out is still an open question
16:21:50 <cmurf> ahh yeah there is at the bottom of the doc on workstation
16:22:14 <adamw> 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 <cmurf> right
16:22:40 <adamw> 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 <adamw> 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 <cmurf> So if KDE is still a release blocking desktop (?) how is it going to be installed in order to be tested?
16:23:51 <adamw> #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 <adamw> cmurf: spin.
16:24:14 <cmurf> A spin that is release blocking? Or is the release blocking being lifted for KDE?
16:24:30 <adamw> 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 <cmurf> OK
16:24:48 <adamw> we should probably ask fesco to think about it, i guess.
16:26:56 <adamw> #action adamw to ask fesco to consider KDE release blocking status
16:27:14 <adamw> any other thoughts on the current .next stuff? anything i've missed?
16:28:16 <cmurf> nope i just skimmed both side by side
16:28:55 <cmurf> 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 <adamw> cloud doesn't use anaconda.
16:29:29 <adamw> yeah, pre-built images.
16:29:47 <adamw> welp, moving along then
16:29:49 <adamw> #topic Taskotron check-in
16:30:08 <adamw> 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 <adamw> tflink?
16:30:25 <tflink> anything in particular?
16:31:13 <cmurf> will it auto bake and ship us unicorn poop cookies?
16:31:20 <tflink> the item of largest interest is that we didn't hit our initial deadline on Friday
16:31:34 <tflink> for ... various reasons
16:31:56 <tflink> at this point, I estimate that we're 3 weeks behind
16:32:08 <jreznik> 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 <tflink> work has been progressing on the runner, on depcheck's replacement and on getting upgradepath ready for use in taskotron
16:33:25 <adamw> jreznik: i thought that was fairly clear.
16:33:37 <adamw> jreznik: i don't see any indication that workstation WG wants to own KDE deliverables.
16:34:04 <adamw> 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 <adamw> 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 <adamw> sorry, tflink.
16:35:07 <adamw> tflink: so, what was meant to be ready by friday? sorry, i've lost track of the plan
16:35:15 <tflink> adamw: an autoqa replacement
16:35:32 <adamw> ah, so we were supposed to have the autoqa-equivalent tests deployed by friday? gotcha.
16:35:53 <tflink> checks and results reporting, in at least staging form, yes
16:36:12 <adamw> so your current read is we can be up and running at that level in three weeks
16:36:49 <tflink> that's my hope, yes
16:36:59 <tflink> emphasis on staging level, though
16:37:29 <tflink> 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 <tflink> integration/scaling
16:38:33 <adamw> OK
16:38:44 <adamw> well, i don't think three weeks out is too terrible
16:38:54 <adamw> nirik: is fesco likely to lose their pants over it?
16:39:11 <nirik> over what? /me reads back up
16:39:21 <tflink> nirik: taskotron being behind schedule
16:39:48 <nirik> ah. well, it is what it is... ;)
16:40:25 <jreznik> tflink: looking on other things happening now - if you're week behind schedule, you're almost there
16:40:31 <adamw> hehe
16:40:44 <tflink> jreznik: I suppose that's one way of looking at it :)
16:42:54 <adamw> #info taskotron currently estimated to be around three weeks behind schedule, meaning staging deployment of autoqa-equivalent coverage in three weeks
16:43:04 <adamw> thanks tflink
16:43:07 <adamw> #topic Update policy
16:45:20 <adamw> so, we had a few prominent updates with dependency issues lately
16:45:51 <adamw> a LibreOffice update and a dnf update
16:46:03 <adamw> 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 <adamw> kk has been making his usual noises about how terrible everything is
16:46:46 <adamw> i did tentatively suggest on devel@ that we could disable autokarma for any update that fails the depcheck test
16:46:52 <adamw> 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 <roshi> I don't see why not
16:48:04 <tflink> how would it be implemented, though?
16:48:15 <tflink> that seems somewhat non-trivial to me
16:48:49 <nirik> there's already a bodhi patch I think.
16:48:51 <tflink> unless scanning text of comments made by the autoqa user is acceptable
16:49:13 <adamw> eh, it'd only be a relatively short-term stopgap
16:49:18 <adamw> so that kinda ugliness works for me
16:49:25 <adamw> case-matched FAILED should be a pretty safe check...
16:49:53 <tflink> and since it's just disabling automatism, it shouldn't  need any overrides
16:50:02 <adamw> 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 <jreznik> yep
16:51:06 <adamw> what are the rules for the tests being run atm?
16:51:17 <adamw> test is run on submission to testing, on edit, and...?
16:51:53 <adamw> (anything else?)
16:52:16 <tflink> adamw: are you asking about scheduling for autoqa or the rule for disabling automatism?
16:55:19 <adamw> scheduling for autoqa
16:55:37 <adamw> 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 <tflink> depcheck is scheduled on tag to fXX-updates-testing-pending and fXX-updates-pending
16:56:29 <tflink> comments are made to bodhi for each tag, or if the status changes
16:57:41 <adamw> OK. i don't think that ought to cause hysteresis, then.
16:57:49 <adamw> so i guess i'll action myself
16:58:28 <adamw> #action adamw to propose disabling of autokarma on depcheck fail (to FESCo) as a stopgap till more reliable depcheck with taskotron
16:58:41 <adamw> #topic Open floor
16:58:42 <adamw> anything else?
16:59:25 <tflink> adamw: there are more bits that would be required for actual enforcement of automated checks
16:59:42 <adamw> roger
16:59:57 <tflink> and those bits are currently not planned as part of taskotron
17:00:12 <tflink> 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 <nirik> Oh, I had one thing to mention...
17:01:55 <adamw> tflink: i think it'd be a substantial win, at least.
17:01:55 <nirik> 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 <adamw> #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 <adamw> anything else, folks?
17:05:47 <danofsatx-work> nothing here
17:05:48 * adamw sets Quantum Fuse
17:06:52 <roshi> what's the fuse attached to?
17:07:11 <roshi> some form of anti-meeting device?
17:07:24 <adamw> 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 <adamw> quite possibly!
17:08:17 <adamw> thanks for coming folks, and time for another universe to die
17:08:20 <adamw> #endmeeting