16:00:25 <tflink> #startmeeting f20beta-blocker-review-2
16:00:25 <zodbot> Meeting started Wed Oct  2 16:00:25 2013 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:25 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:25 <tflink> #meetingname f20beta-blocker-review-2
16:00:25 <zodbot> The meeting name has been set to 'f20beta-blocker-review-2'
16:00:25 <tflink> #topic Roll Call
16:00:32 * dan408 waves
16:00:36 * roshi is here
16:00:44 * kparal prepares dinner
16:00:45 <tflink> kparal: we're not a SMTP server :-/
16:00:58 <dan408> you had me at ehlo
16:01:00 * cmurf is present
16:01:09 * Viking-Ice sharpens his ax now let's slice down those blockers ;)
16:01:14 <kparal> tflink: sorry, sometimes I get confused who I'm talking to
16:01:18 * mkrizek is here
16:01:21 <tflink> kparal: ouch
16:01:27 * pschindl is here
16:01:33 <tflink> any volunteers for secretary duty?
16:01:46 * pwhalen is here
16:01:52 * kparal points at... someone else :)
16:02:03 <tflink> kparal: I hear a volunteer
16:02:39 <roshi> I got it :)
16:02:49 <roshi> unless kparal really wants it :p
16:03:02 <kparal> phew, no thanks :)
16:03:52 <tflink> looks like we have enough people, time for some boilerplate!
16:03:59 <tflink> adamw: you around for blocker meeting fun time?
16:04:09 <tflink> #topic Introduction
16:04:14 <tflink> Why are we here?
16:04:14 <tflink> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and freeze exception bugs.
16:04:18 <cmurf> it's cocktail hour where adam is
16:04:19 <tflink> #info We'll be following the process outlined at:
16:04:19 <tflink> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:04:29 <tflink> #info The bugs up for review today are available at:
16:04:29 <tflink> #link http://qa.fedoraproject.org/blockerbugs/current
16:04:30 <dan408> 9am
16:04:35 <tflink> #info The criteria for release blocking bugs can be found at:
16:04:35 <tflink> #link https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria
16:04:40 <kparal> Beta
16:04:41 <tflink> #info Up for review today, we have:
16:04:45 <tflink> bah
16:04:47 <tflink> #undo
16:04:47 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x50462f10>
16:04:49 <tflink> #undo
16:04:49 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x249f4950>
16:05:01 <tflink> link https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria
16:05:06 <tflink> #info Up for review today, we have:
16:05:13 <tflink> #chair kparal adamw roshi
16:05:13 <zodbot> Current chairs: adamw kparal roshi tflink
16:05:25 * handsome_pirate waves
16:05:34 <tflink> #info 9 Proposed Blockers
16:05:34 <tflink> #info 7 Accepted Blockers
16:05:34 <tflink> #info 1 Proposed Freeze Exceptions
16:05:35 <tflink> #info 4 Accepted Freeze Exceptions
16:05:50 <tflink> if there are no objections, we'll start with the proposed blockers
16:06:35 <cmurf> noobjections go
16:06:44 <tflink> #topic (1009809) KeyError: 'name'
16:06:44 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1009809
16:06:44 <tflink> #info Proposed Blocker, anaconda, ON_QA
16:07:22 <handsome_pirate> Wow
16:07:42 <handsome_pirate> No DNS for bugzilla
16:08:05 <kparal> I guess I should have tested this one with repo=nfs:, right?
16:08:16 <cmurf> OK so I think the question for this bug is whether or not there is at least one NFS method that's working.
16:08:22 <kparal> feel free to needinfo me next time
16:08:39 <handsome_pirate> Ah, there it goes
16:08:45 <tflink> yeah, punt I think unless someone's tried it for beta
16:09:04 <kparal> I didn't. so punt and maybe it will get closed once TC1 is out
16:09:07 <cmurf> And maybe it needs retesting with anaconda 20.21-1 as it might have been a bug in there
16:09:08 * handsome_pirate is +1 punt
16:09:09 <kparal> and anaconda is stable
16:09:10 <cmurf> so yea punt
16:09:43 <dan408> +1
16:09:44 <tflink> proposed #agreed 1009809 - This still needs testing to see if at least 1 of nfs/nfsiso works - will revisit once that testing has been done
16:10:03 <roshi> ack
16:10:06 <dan408> ack
16:10:06 <kparal> ack
16:10:07 <cmurf> ack
16:10:10 <tflink> #agreed 1009809 - This still needs testing to see if at least 1 of nfs/nfsiso works - will revisit once that testing has been done
16:10:10 <Viking-Ice> ack
16:10:16 <tflink> topic (1012504) FSError: filesystem already exists
16:10:16 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1012504
16:10:16 <tflink> #info Proposed Blocker, anaconda, ASSIGNED
16:10:42 <cmurf> The bottom line here is that the installer sometimes creates a btrfs file system and then later tries to reformat it ext4 and then crashes.
16:10:43 <tflink> another reason to get the new blockerbugs version put in production - this damn sort order bug :-/
16:11:02 <cmurf> +1 blocker
16:11:13 <handsome_pirate> +1 blocker
16:11:13 <dan408> odd. I havent had any issues with partitioning since custom partitioning was fixed
16:11:46 <dan408> can you provide some more steps to reproduce?
16:11:51 <cmurf> it is transient but dlehman knows were the problem is
16:11:55 <dan408> this happens on dvd and netinst?
16:12:26 <dan408> and how did you get back to partition screen after install started?
16:12:36 <tflink> yeah, +1
16:12:45 <Viking-Ice> +1
16:13:01 <roshi> +1
16:13:09 <tflink> proposed #agreed 1009809 - AcceptedBlocker - Violates the following F20 beta release criterion for btrfs autopart: "Complete an installation using any combination of disk configuration options it allows the user to select"
16:13:12 <cmurf> testing has been done with desktop; i did not get back to partition screen after i started the install, the installer itself for some reason decides to spuriousy reformat a btrfs volume as ext4
16:13:14 <handsome_pirate> ack
16:13:15 <dan408> ack
16:13:17 <cmurf> ack
16:13:17 <Viking-Ice> ack
16:13:24 <roshi> ack
16:13:29 <dan408> cmurf: oh ok
16:13:39 <tflink> cmurf: this was with autopart, no?
16:13:47 <dan408> manual
16:13:54 <adamw> sorry, folks, just got here
16:13:55 <cmurf> it has happened with autopart and with custom but the bug as reported is manual
16:14:02 <adamw> f20 exploded messily today
16:14:16 <dan408> so this is after going through the parititoning a few times
16:14:21 <dan408> which I can see crashing
16:14:36 <tflink> bah, i got the criterion wrong, then
16:14:59 <dan408> im sure if you go through it 3 or 4 times it might crash
16:15:07 <cmurf> yes, in the orginal description the user was behaving erratically, but that's not required to trigger this bug
16:15:34 <dan408> you can trigger it on 1 time partitioning?
16:15:43 <cmurf> yes
16:15:52 <cmurf> again it's transient it doesn't always happen
16:15:59 <tflink> proposed #agreed 1009809 - AcceptedBlocker - Violates the following F20 beta release criterion for btrfs custom partitions: "When using the custom partitioning flow, the installer must be able to ... Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes ..."
16:16:13 * Viking-Ice throws ack in there
16:16:19 <cmurf> ack
16:16:26 <tflink> roshi: you'll probably want to quote more of the criterion than I did - there are length restrictions to lines in irc
16:16:36 * roshi nods
16:16:38 <roshi> ack
16:16:45 <dan408> ack
16:16:57 <tflink> #agreed 1009809 - AcceptedBlocker - Violates the following F20 beta release criterion for btrfs custom partitions: "When using the custom partitioning flow, the installer must be able to ... Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes ..."
16:17:01 <roshi> that's the wrong bug number
16:17:07 <roshi> 1012504
16:17:32 <tflink> huh, did I not change topic or is zodbot being slow
16:17:33 <tflink> ?
16:17:35 <tflink> #undo
16:17:35 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x29fc7590>
16:17:54 <tflink> #agreed 1012504 - AcceptedBlocker - Violates the following F20 beta release criterion for btrfs custom partitions: "When using the custom partitioning flow, the installer must be able to ... Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes ..."
16:18:07 <tflink> #topic (1010495) Apple Mac EFI: you have not created a bootloader stage1 target device
16:18:08 <roshi> you were missing "#" methinks when you set the topic
16:18:10 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1010495
16:18:13 <tflink> #info Proposed Blocker, anaconda, POST
16:18:20 <tflink> meetbot fail!
16:19:05 <tflink> huh, I didn't think this one would be fixed
16:19:12 <cmurf> Mac EFI bug has a fix that works for me. I'd say making this blocking is a precident setting thing. So it's legit to punt on this.
16:19:16 <adamw> i think it turned out not to be the bug bcl thought it was
16:19:18 <Viking-Ice> no neither did I
16:19:36 <adamw> cmurf: it's not really a precedent setting thing, we were supposed to be blocking on macs now, at least that was my understanding
16:19:45 <cmurf> OK I didn't know that.
16:19:46 <adamw> we used to have wording that explicitly excepted them from the criteria and then we took it out
16:19:48 <tflink> yeah, same here
16:19:48 <Viking-Ice> but let's accept it and pull the fix in
16:19:50 <cmurf> So in that case it's a clear +1 bocker.
16:19:54 <tflink> +1
16:19:57 <Viking-Ice> +1
16:19:58 <cmurf> bLocker
16:19:59 <adamw> Viking-Ice: we're not frozen anyhow, so it's kinda academic
16:19:59 <handsome_pirate> +1 blocker
16:20:11 <adamw> i'm +1 blocker for now, though, we can always fight about it in future if it becomes necessary
16:20:15 <roshi> +1
16:20:35 <dan408> +1
16:20:55 <cmurf> adamw: have you experinced fighting with a fellow word fountain? like watching two water buffalo drown.
16:21:24 <tflink> bah, criterion?
16:21:40 <adamw> haha.
16:21:57 <kparal> ESP stands for?
16:22:05 <cmurf> EFI System Partition
16:22:06 <adamw> EFI system partition
16:22:09 <kparal> thx
16:22:21 <cmurf> we don't have any EFI/UEFI related beta criteria....
16:22:25 <cmurf> ?
16:22:32 <cmurf> or are they just implied
16:22:44 <kparal> implied
16:23:01 <tflink> implied, IIRC we only explicitly require the images to boot
16:23:16 <adamw> we can call it a conditional violation of "Cleanly install to a disk with a valid ms-dos or gpt disk label and partition table which contains existing data and sufficient unpartitioned space for a Fedora installation "
16:23:20 <adamw> (for guided partitioning)
16:23:31 <cmurf> yes
16:23:46 <dan408> ms dos??
16:23:48 <adamw> cmurf: we don't have any BIOS criteria either. ;)
16:23:53 <adamw> dan408: it's a disk label format.
16:23:57 <tflink> that's better than what I was coming up with :)
16:24:19 <cmurf> for custom partitioning, i think it's the 2nd bullet
16:24:20 <dan408> is that the same as MBR?
16:24:23 <tflink> proposed #agreed 1010495 - AcceptedBlocker - Violates the following F20 beta release criterion for EFI system partitions on apple hardware: "Cleanly install to a disk with a valid ms-dos or gpt disk label and partition table which contains existing data and sufficient unpartitioned space for a Fedora installation"
16:24:24 <Viking-Ice> ack
16:24:26 <adamw> dan408: it's a more accurate term.
16:24:28 <dan408> ack
16:24:32 <dan408> adamw:
16:24:33 <dan408> k
16:24:46 <adamw> dan408: an MBR is something that usually (but not always) exists on an msdos-labelled disk.
16:24:47 <kparal> ack
16:24:48 <cmurf> ack
16:25:01 <cmurf> MBR = MSDOS disklabel
16:25:03 <tflink> #agreed 1010495 - AcceptedBlocker - Violates the following F20 beta release criterion for EFI system partitions on apple hardware: "Cleanly install to a disk with a valid ms-dos or gpt disk label and partition table which contains existing data and sufficient unpartitioned space for a Fedora installation"
16:25:15 <tflink> #topic (1013800) devicetree.py:1293:handleVgLvs:DeviceTreeError: failed to look up thin pool
16:25:18 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1013800
16:25:21 <tflink> #info Proposed Blocker, anaconda, NEW
16:25:34 <cmurf> The MBR bootstrap region is a 440 byte section of the MBR.
16:25:40 <adamw> cmurf: if you look at the Alpha 'images must boot' criterion's notes, there's a 'supported firmware types' one which says 'Release-blocking images must boot from all system firmware types that are commonly found on the primary architectures.' - that's what makes UEFI covered.
16:25:53 <cmurf> adamw got it thanks
16:25:54 <Viking-Ice> do we have any criteria that covers thinp?
16:26:10 <tflink> no, but we do have on ethat covers all offered partition types
16:26:12 <adamw> it probably comes in the 'no errors' bit of the partitioning criteria
16:26:19 <tflink> and lvm thinp is offered for autopart
16:26:39 <adamw> or better, "Complete an installation using any combination of disk configuration options it allows the user to select "
16:26:41 <cmurf> yeah if it's offered, it has to work, or the offer needs to be removed - is my view
16:26:42 <Viking-Ice> autoblocker then
16:26:42 <tflink> "Complete an installation using any combination of disk configuration options it allows the user to select "
16:26:46 <adamw> (referring to Guided Partitioning"
16:26:48 <adamw> yup, that one.
16:26:48 <tflink> bah, not fast enough
16:26:59 <adamw> i.e. if one of the paths guided offers is just busted, we're blocking. so, if that's what this bug is, +1
16:27:18 <Viking-Ice> +1
16:27:21 <roshi> +1
16:27:23 <kparal> +1
16:27:25 <tflink> proposed #agreed 1013800 - AcceptedBlocker - Violates the following F20 beta release criterion for LVM thinp: "Complete an installation using any combination of disk configuration options it allows the user to select"
16:27:28 <cmurf> ack
16:27:30 <roshi> ack
16:27:38 <adamw> tflink: maybe add the first half of the criterion, but sure
16:27:51 <kparal> ack
16:28:01 <Viking-Ice> ack
16:28:06 <handsome_pirate> ack
16:28:07 <tflink> proposed++ #agreed 1013800 - AcceptedBlocker - Violates the following F20 beta release criterion for LVM thinp: "When using the guided partitioning flow, the installer must be able to ... Complete an installation using any combination of disk configuration options it allows the user to select"
16:28:14 <tflink> #agreed 1013800 - AcceptedBlocker - Violates the following F20 beta release criterion for LVM thinp: "When using the guided partitioning flow, the installer must be able to ... Complete an installation using any combination of disk configuration options it allows the user to select"
16:28:24 * tflink can undo if there are objections to the change
16:28:39 <tflink> #topic (1013586) SizeNotPositiveError: spec= param must be >=0
16:28:39 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1013586
16:28:39 <tflink> #info Proposed Blocker, anaconda, NEW
16:28:57 <cmurf> I've added a needinfo here
16:29:36 <kparal> cmurf: what is "for OP"?
16:29:49 <tflink> original poster
16:29:55 <kparal> ah, that's me!
16:29:56 <tflink> poster, using forum speak :)
16:30:03 <tflink> poster/reporter
16:30:09 <cmurf> my juvenile forum vernacular
16:30:10 <tflink> me use words good
16:30:22 <Viking-Ice> me uses words that resemble english
16:30:23 <kparal> cmurf: right, I haven't seen the error with a disk layout created by windows installer
16:30:31 <kparal> it might be a good idea to try more partitioning tools
16:30:50 <Viking-Ice> punt for testing and more data ?
16:30:58 <roshi> +1 punt
16:31:02 <cmurf> it might be that it's just inducing an existing bug that needs to be fixed
16:31:03 <cmurf> +1 punt
16:31:15 <cmurf> so it may still be a blocker
16:31:16 <tflink> I'm not against the idea but I'd be suprised if it was a gnome-disks issue
16:31:21 <kparal> so, if it turns out to be a gnome-disks problem, is it not a blocker?
16:31:37 <tflink> more borderline
16:31:38 <Viking-Ice> I would not think so
16:31:41 <kparal> gnome-disks is likely to be used by people to adjust  the disk layout before installation
16:31:46 <Viking-Ice> ?
16:31:56 <kparal> well, I do it sometimes
16:32:05 <kparal> it's much easier in gnome-disks than in anaconda
16:32:05 <cmurf> kparal: exactly so the exact nature of the problem needs to be better understood
16:32:13 * jreznik is finally around
16:32:14 <tflink> creation != modification, though
16:32:35 <Viking-Ice> kparal,  we could pull it in as an fe if it's DE app breakage but not a blocker
16:32:38 <tflink> i can't really think of a situation where someone would create a ntfs partition pre-install with gnome-disks
16:32:51 <cmurf> i think it depends on the problem
16:32:53 <kparal> tflink: it happens with ext4 as well
16:33:01 <Viking-Ice> anywho we all agree to punt
16:33:05 <tflink> ah ... details
16:33:06 <tflink> yeah
16:33:14 <kparal> give me a minute, I'll try gparted
16:33:17 <cmurf> if we find out that gnome-disks calls ntfs-3g and it's making a bad NTFS volume, I'd say that ought to be blocking, it's a forum of corruption
16:33:30 <cmurf> anyway more testing is needed
16:33:32 <Viking-Ice> if not used by the installer not blocked
16:33:44 <tflink> proposed #agreed 1013586 - We need more information and testing to figure out how common this failure mode is. will re-visit once more testing has been done.
16:33:47 <Viking-Ice> ack
16:33:50 <kparal> cmurf: it happens with ext4 as well
16:33:56 <cmurf> interesting
16:34:11 * kparal installing gparted on live
16:34:14 <roshi> ack
16:34:25 <cmurf> it might be triggered due to the fact the volume has no files on it
16:34:26 <tflink> ack/nak/patchk?
16:34:47 <cmurf> we need to hear from dlehman what he thinks triggers this
16:34:51 <kparal> a sec
16:34:54 <cmurf> ack
16:35:03 <tflink> #agreed 1013586 - We need more information and testing to figure out how common this failure mode is. will re-visit once more testing has been done.
16:35:17 <kparal> interesting, with gparted-created partition it didn't crash
16:35:22 <cmurf> hmmm
16:35:38 <kparal> already agreed, let's move on
16:35:42 <tflink> #topic (1012646) anaconda creates grub.cfg lacking an initrd entry, kernel panics on reboot
16:35:45 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1012646
16:35:47 <tflink> #info Proposed Blocker, anaconda, ASSIGNED
16:35:53 <cmurf> ok hold on this on for a sec
16:36:16 <cmurf> 1012646 and 864198 are related; it's either one or the other that's the blocker
16:36:35 <adamw> reading
16:36:37 <cmurf> anaconda creates a grub.cfg before the initrd is made
16:36:51 <cmurf> then grubby fixes the grub.cfg after the initrd is made
16:36:54 <Viking-Ice> anaconda should just install and use gummiboot instead of grub on efi ;)
16:36:57 <cmurf> so i think 1012646 is NOT a blocker
16:37:01 <cmurf> and probably not a bug
16:37:01 <adamw> UEFI specific?
16:37:04 <cmurf> no
16:37:15 <cmurf> i think the ultimate bug and blocker is 864198
16:37:20 <tflink> btrfs specific, though?
16:37:25 <cmurf> yes
16:37:31 <cmurf> specifically boot on btrfs
16:37:40 <tflink> do we want to do 864198 first, then?
16:37:42 <cmurf> which is only possible through Manual Partitioning
16:37:46 <cmurf> that's reasonable
16:38:08 <tflink> or reject this one?
16:38:12 <adamw> reject this, i think
16:38:15 <cmurf> 1012646 was filed before i thought of the ancient 864198 bug
16:38:19 <Viking-Ice> is not btrfs still flag experimental ?
16:38:22 <adamw> anaconda isn't running grub2-mkconfig to create a live config file
16:38:24 <Viking-Ice> yeah reject
16:38:31 <adamw> it's running grub2-mkconfig to make grub2-install work
16:38:53 <adamw> or, hmm. maybe i'm misremembering...
16:38:54 <cmurf> adamw: it appears to run it because grubby can't make the whole grub.cfg
16:39:10 <Viking-Ice> <shrug> grubby is so utterly broken
16:39:17 <cmurf> and grubby would puke if there wasn't a basic grub.cfg in place
16:39:18 <tflink> proposed #agreed 1012646 - RejectedBlocker - This is a problem but the actual bug is in grubby, not anaconda and in this case, anaconda is behaving as expected
16:39:22 <Viking-Ice> ack
16:39:27 <adamw> i think that's close enough for now
16:39:28 <cmurf> ack
16:40:11 <roshi> ack
16:40:26 <tflink> #agreed 1012646 - RejectedBlocker - This is a problem but the actual bug is in grubby, not anaconda and in this case, anaconda is behaving as expected
16:40:43 <tflink> #topic (1013087) selection of rescue kernel causes kernel panic, due to lack of initramfs
16:40:46 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1013087
16:40:48 <tflink> #info Proposed Blocker, anaconda, NEW
16:41:42 <dan408> +1
16:41:44 <cmurf> ok so weirdly this problem is masked for most people because when they reboot the primary (non-rescue) kernel and do a yum update, new-kernel-pkg for an updated kernel also somehow calls dracut to write out an initramfs for the rescue kernel
16:42:07 <cmurf> but if you use the rescue kernel grub menu option before a yum update, you get a kp
16:42:14 <cmurf> so yeah +1
16:42:26 <dan408> so this wouldnt affect netinstall would it? just live media and dvd?
16:42:44 <cmurf> i don't know, does netinstal install a rescue kernel?
16:42:45 <kparal> I thought that anaconda was calling dracut --regenerate-all at the end of the installation
16:42:59 <kparal> dan408: all media install a rescue kernel, just cloud media don't contain it afaik
16:43:03 <Viking-Ice> is the dracut-config-rescue package installed ?
16:43:06 <cmurf> kaparl: no it appears anaconda calls new-kernel-pkg and it calls dracut
16:43:19 <adamw> do we actually require the rescue kernel to work for any reason?
16:43:25 <tflink> what criteria does this violate?
16:43:26 <cmurf> viking: oh that's a good point this could be a dracut bug not anaconda
16:43:38 <dan408> kparal: i was just wondering because netinstall is an updated installation, so after finishing a netinstall a yum update wouldnt do anything
16:43:40 <Viking-Ice> tflink, none I think
16:43:43 <adamw> i don't think this clearly does violate one
16:43:57 * roshi doesn't see one
16:43:57 <adamw> the rescue kernel is basically a non-system-specific kernel, right?
16:44:00 <tflink> if you're really in trouble, you can use the rescue mode on iso
16:44:01 <cmurf> seems like a problem for the rescue kernel to crash haha
16:44:04 <adamw> so it's for if you change the system hardware drastically
16:44:04 <Viking-Ice> -1 reject that sucker
16:44:17 <kparal> adamw: yes
16:44:22 <cmurf> well wait
16:44:22 <adamw> nice feature, i guess, but i don't see that it violates the criteria (though it does obviously look bad if you try it out)
16:44:27 <kparal> I'd say this should be a final blocker. not sure about beta
16:44:28 <tflink> cmurf: I'm not saying it isn't a bug; just that it isn't a release blocking issue :)
16:44:29 <cmurf> it crashes unti you can update
16:44:32 <adamw> still, i'm happy with -1 for beta unless i missed something
16:44:44 <Viking-Ice> adamw, when you need it your system is screwed anyway ;)
16:44:46 <tflink> cmurf: you can work around it, though
16:44:55 <kparal> anaconda rescue mode has to work, I see no reason why we should not require rescue kernel to work as well
16:44:58 <kparal> it's just a new thing
16:44:58 <dan408> -1 for beta then, I think it should be fixed by final though
16:45:07 <kparal> what milestone is anaconda rescue mode in?
16:45:15 <tflink> alpha
16:45:20 <cmurf> hmm seems reasonable that it works for final and not beta
16:45:29 <kparal> I think this should be alpha as well then
16:45:39 <Viking-Ice> does not anaconda rescue mode work ( which most likely is then due to that missing dracut config rescue stuff )
16:45:44 <tflink> proposed #agreed 1013087 - RejectedBlocker - While unfortunate, this does not violate any F20 beta release criteria and thus is rejected as a release blocking issue for f20 beta
16:45:45 <kparal> but we might want to reconsider rescue mode in general
16:45:48 <Viking-Ice> ack
16:45:52 <cmurf> but the thing is, it prevents testing for beta to be unable to boot the rescue kernel just due to a lack of an initramfs
16:45:57 <dan408> ack
16:46:06 <Viking-Ice> kparal, we need to reconsider the entire concept of rescue mode
16:46:14 <dan408> +1 Viking-Ice
16:46:24 <kparal> I see several examples where only the rescue kernel worked, because there were some modules missing in normal initrd due to hostonly mode
16:46:31 <kparal> *I saw
16:46:46 * Viking-Ice does not use initrd
16:46:48 <cmurf> if anything the rescue kernel should be the sure fire one that works in case dracut made the smaller initramfs for the system wrong and it can't boot
16:46:59 * dan408 doesnt bother with rescue mode
16:47:01 <kparal> so if we reject this, I believe we should add a note that we will adjust the criteria before final
16:47:07 <Viking-Ice> why
16:47:11 <tflink> we will?
16:47:17 <kparal> I would
16:47:27 <kparal> I just propose it, of course
16:47:33 <tflink> what does the rescue mode solve that can't be solved w/ anaconda rescue mode?
16:47:44 <dan408> nothing
16:47:47 <kparal> hmm, it actually boots a working system
16:47:51 <cmurf> i have one computer and no install disk because i travel with a laptop?
16:47:55 <tflink> sure, it looks really bad if rescue mode crashes if initial boot fails
16:48:01 <cmurf> and i can't make an install disk because i can't boot?
16:48:15 <cmurf> there's a simple fix here
16:48:20 <tflink> cmurf: how did you install, then?
16:48:31 <cmurf> i'm proposing a scenario not reality
16:48:32 <dan408> chicken, meet egg
16:48:36 <cmurf> no
16:48:39 <cmurf> not at all
16:48:43 <tflink> if I'm understanding correctly, the rescue initramfs will be generated on first kernel upgrade
16:48:43 <adamw> note, all current references to the 'rescue mode' in the criteria are talking about the one on the install media
16:48:46 <kparal> I believe rescue mode should be in our criteria, both anaconda and system rescue
16:48:56 <adamw> this 'rescue kernel' is something new since, iirc, f19, the criteria do not consider it explicitly at all
16:49:02 <Viking-Ice> kparal, not system rescue
16:49:03 <kparal> adamw: because the rescue kernel is a new thing
16:49:06 <adamw> yes
16:49:08 <cmurf> yes
16:49:14 <kparal> so, let's add it
16:49:14 <Viking-Ice> installer yes local no
16:49:29 <tflink> I still don't see why this should be a release blocking issue
16:49:42 <cmurf> whether the rescue kernel criteria says it should work by final or beta isn't a hill i'll die on
16:49:43 <tflink> if you haven't upgraded kernel since install, you probably have the image around
16:49:48 <cmurf> but it should work by final or it's just silly
16:49:50 <cmurf> remove it
16:49:58 <adamw> yeah, i'm still with tflink on this one
16:50:02 <Viking-Ice> as am I
16:50:06 <kparal> ok
16:50:11 <dan408> I see his view
16:50:31 <adamw> i haven't seen the cases he's seen, where hostonly has really tripped people up in 'normal use'
16:50:31 <dan408> but im -1
16:50:32 <tflink> I agree that it should be fixed and would consider FE
16:50:38 <cmurf> i install the system, i walk out the door for a flight, i have no media, and i'm stuck on a plan for 8 hour without a bootable computer
16:50:39 <adamw> dan408: er. tflink is -1.
16:50:45 <dan408> yeah
16:50:48 <dan408> as am i
16:50:57 <dan408> I have learned not to rely on rescue mode
16:50:59 <cmurf> i don't think we get involved in people's install workflows. the rescue kernel should work the question is when, beta or final.
16:51:05 <adamw> cmurf: if you install the system and the hostonly initrd doesn't work, then that is the blocking bug, not this.
16:51:20 <kparal> there are better reasons. you don't know what is wrong, the system doesn't boot, but with rescue mode it boots. that helps you _a lot_. you can't have this with anaconda rescue
16:51:21 <adamw> hostonly initrd should only ever be a problem if you change the hardware in the system.
16:51:22 <tflink> cmurf: I'm not sure you would be much better off with rescue mode in the airplane situation
16:51:48 <adamw> tflink: the rescue kernel does not put you in a 'rescue mode'. it puts you in a regular system. aiui, anyhow.
16:52:14 <cmurf> the rescue kernel and initramfs ought to be essentially the same thing as on the install media
16:52:20 <Viking-Ice> let's move on
16:52:28 <cmurf> all the more reason why i'm not sure why ther isn't an initramfs already present
16:52:29 <tflink> how about this: we reject for beta and if kparal/cmurf want to propose criteria changes - that can be discussed on the list
16:52:31 <kparal> adamw: I have seen several examples where hostonly was a problem without changing hardware. benl was one of the "victims". unfortunately it could not be reproduced
16:52:41 <cmurf> yes fine, move on
16:52:45 <adamw> we should probably thrash this out and have the discussion about whether we should explicitly or implicitly require the rescue kernel to work at any point, but maybe in this meeting isn't the time...
16:52:52 <kparal> cmurf: please repropose for Final blocker
16:52:58 <adamw> kparal: well, i think we'd want some solid data for that. at least, bug #s.
16:53:03 <Viking-Ice> adamw, qa meetign
16:53:06 <adamw> Viking-Ice: or list
16:53:10 <tflink> #agreed 1013087 - RejectedBlocker - While unfortunate, this does not violate any F20 beta release criteria and thus is rejected as a release blocking issue for f20 beta
16:53:17 <Viking-Ice> ack
16:53:29 <cmurf> ack
16:53:35 <tflink> #topic (1013767) rootfs on thinp not found, startup failure
16:53:35 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1013767
16:53:35 <tflink> #info Proposed Blocker, dracut, NEW
16:54:44 <tflink> so we have bugs on thinp failing during install and post-install?
16:54:50 <cmurf> yes
16:55:03 <tflink> nice to see new features working well :)
16:55:05 <cmurf> altough the thinp install bug is probably fixed by new blivet which is how i was able to get it to install to triggerthis bug
16:55:21 <Viking-Ice> which in turn might fix this ( the detection script in dracut )
16:55:30 <Viking-Ice> so I say punt for now
16:55:39 <cmurf> no i have applied the new blivet and it still crashes
16:55:45 <Viking-Ice> we need haralds input on this before deciding anything anyway
16:56:28 <adamw> well, at least some confirmation would be nice i guess
16:56:33 <cmurf> yeah this bug is that the LV's aren't active
16:56:54 <adamw> note that "post-install requirements" says "Except where otherwise specified, each of these requirements applies to all supported configurations described above."
16:57:21 <Viking-Ice> adamw, sounds awfully like this bug filed against the downstream distro against us rhbz#921235
16:57:25 <adamw> one implication of that is, basically, that any installation scenario considered 'blocking' by the criteria - which we've already decided includes thinp autopart - is also required to actually boot.
16:57:25 <cmurf> presumably since it's offered in guided partitioning it should boot
16:57:35 <adamw> right.
16:57:46 <cmurf> i'm not sure if it's a dracut thing
16:57:50 <cmurf> or systemd thing though
16:57:58 <cmurf> thing=bug
16:57:58 <Viking-Ice> it's not systemd
16:58:15 <Viking-Ice> but hey let's always blame systemd for all the worlds problem
16:58:27 <tflink> Viking-Ice: sounds like a plan. either that or PA :)
16:58:33 <adamw> i would be +1 on this if it's confirmed to be affecting a typical guided thinp deployment
16:58:35 * tflink votes for blaming canada, though :)
16:58:49 <adamw> blame canada for systemd, that should cover everything!
16:59:03 <tflink> sweet, I think we're done here then
16:59:21 <cmurf> so is this a punt or what
16:59:27 <tflink> getting back to reality ... votes?
16:59:29 <Viking-Ice> I would say so
16:59:32 <tflink> punt or +1?
16:59:37 <adamw> eh. either punt or +1 with the option to withdraw, i guess
16:59:38 <cmurf> i think it's a +1 but we also need info
16:59:40 <adamw> i can go for either
16:59:55 <tflink> yeah, I'm ok with either. not -1.
16:59:55 <cmurf> it's reproducible in a VM and on baremetal
17:00:07 <cmurf> and it's guided partitioning
17:00:19 <cmurf> and the initramfs was built with a dracut that should support thinp
17:00:22 <Viking-Ice> we need to know from harald if it's dracut or something else
17:00:25 <cmurf> right
17:00:38 <Viking-Ice> but most likely this is a fallout from the other bug
17:00:41 <cmurf> but on principle the vote is whether thinp installs should boot
17:00:43 <adamw> Viking-Ice: we don't need to know that in order to decide if it's a blocker bug though, really
17:01:04 <cmurf> viking-ice: well the other bug though is an installer problem that's fixed in blivet
17:01:14 <cmurf> when i boot the desktop media, the thinp volumes are all active and fine
17:01:19 <cmurf> thinp metadata is fine
17:01:20 <Viking-Ice> and has this been tested afterwords
17:01:25 <cmurf> the file systems on the thinp LV's are fine
17:01:27 <adamw> Viking-Ice: that doesn't seem right. the other bug prevents you getting an install done at all if you hit it. but cmurf managed to work around that bug, and _then_ ran into this one.
17:02:04 <Viking-Ice> adamw, true I'm +1 for blocker just wanted more data
17:02:36 <tflink> I don't see any -1s - in the interest of not having to review this again, lets just accept it
17:02:37 <adamw> sure, we need more data to FIX it, just not to vote :)
17:02:41 <adamw> yeah, that seems fine
17:02:51 <tflink> if it turns out to be something obscure, we can revisit
17:02:58 <cmurf> agreed
17:04:07 <tflink> huh, we don't seem to have a generic "it should boot" criteria
17:04:16 <tflink> just the graphical and non/graphical cases
17:04:52 <Viking-Ice> well techincally you dont require initrd
17:04:53 * Viking-Ice hides
17:05:05 <tflink> proposed #agreed 1013767 - AcceptedBlocker - Violates the following F20 alpha release criterion for LVM thinp autopart installs: "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility."
17:05:06 <cmurf> yes but that requires user intervention
17:05:12 <Viking-Ice> ack
17:05:15 <cmurf> ack
17:05:38 <tflink> ack/nak/pak?
17:06:26 <tflink> roshi, kparal, pschindl: ack/nak/patch?
17:06:41 <roshi> ack
17:06:49 <tflink> #agreed 1013767 - AcceptedBlocker - Violates the following F20 alpha release criterion for LVM thinp autopart installs: "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility."
17:06:59 <tflink> #topic (864198) grubby fatal error updating grub.cfg when /boot is btrfs
17:06:59 * kparal wakes up
17:07:02 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=864198
17:07:05 <tflink> #info Proposed Blocker, grubby, ASSIGNED
17:07:59 <cmurf> summary is; Installer allows user to create a legitimate layout, boot on Btrfs, which GRUB2 can boot. Yet grubby doesn't properly update the grub.cfg, and therefore requires intentional user intervention for the system to boot to a working login prompt/desktop.
17:08:21 <adamw> tflink: what scenarios are not covered as either a) graphical or b) non-graphical? semi-graphical? :P
17:08:49 <Viking-Ice> this one has been following us for 2 releases now
17:08:51 <cmurf> FWIW: this bug also breaks subsequent kernel updates, which means without user intervention you don't boot the newly installed kernel
17:08:52 <tflink> adamw: situations that are both?
17:08:55 <Viking-Ice> based on comments
17:08:59 <adamw> cmurf: is this the config you get if you use the btrfs filesystem option for guided partitioning? or only if you do a specific custom layout?
17:09:00 <Viking-Ice> let's put it to rest +1
17:09:08 <cmurf> adamw: custom only
17:09:11 <adamw> tflink: if a bug affects both, then it's DOUBLE blocker.
17:09:16 <cmurf> adamw: guided uses ext4 for boot
17:09:33 <tflink> adamw: does that mean the affected software goes on double secret probation?
17:09:50 <cmurf> or secret double probation
17:09:53 <adamw> the custom partitioning criteria are sort of focused on the functionality of the partitioner itself, not the consequences...
17:09:57 <adamw> so we're in a bit of a grey area
17:10:16 <adamw> it'd be a conditional violation of the 'it must boot' criteria, i guess: violates them in the case you configure the specific layout that causes the bug.
17:10:23 <cmurf> adamw: post-install requirements don't propose an exception for custom producing unbootable systems
17:10:53 <Viking-Ice> this is a violation of the criteria and we have let it slide for two long
17:10:57 <Viking-Ice> mean too
17:10:59 <tflink> yeah, it seems a bit silly to say that "it installs, therefore not a blocker"
17:11:08 <tflink> when it doesn't install _and_ boot
17:11:18 <cmurf> we need to hear from pjones
17:11:19 <adamw> cmurf: i refer you to https://fedoraproject.org/wiki/Blocker_Bug_FAQ#What_about_hardware_and_local_configuration_dependent_issues.3F
17:11:39 <adamw> "When a bug causes a criterion not to be met in some but not all cases, the teams involved in the release process will make a judgement as to whether the impact of the bug is severe enough to consider the release as a whole not to meet the release criteria"
17:11:41 <adamw> that's us. :P
17:12:19 <cmurf> wait what
17:12:25 <tflink> but at the same time, this doesn't really pass the "last blocker @ go/no-go" test
17:12:26 <cmurf> there's a double negative in there
17:12:39 <adamw> cmurf: i don't think there is.
17:12:48 <cmurf> a criterion not met in some, but not all cases
17:12:49 <cmurf> ?
17:13:02 <cmurf> "not to be met in some but not all cases"
17:13:03 <adamw> that's not a double negative.
17:13:18 <adamw> the first 'not' is talking about the criterion, the second 'not' is talking about the cases.
17:13:27 <tflink> we're getting off in the weeds here
17:13:27 <roshi> it could be worded better, but there's no double negative
17:13:33 * tflink bangs gavel
17:13:40 <adamw> it ain't not only a double negative when both the negatives are dealing with one noun clause ;)
17:13:46 <cmurf> okok
17:13:49 <roshi> we have a gavel?
17:13:54 <adamw> .fire roshi could NOT
17:13:54 <zodbot> adamw fires roshi could NOT
17:13:55 <tflink> I do :)
17:14:12 <adamw> roshi: my legalese is flawless, damnit.
17:14:20 <roshi> haha
17:14:27 <Viking-Ice> I have stunner that zaps people much more effective then an gavel
17:14:31 <cmurf> that's really confusing
17:14:33 <cmurf> i'm still confused
17:14:37 <Viking-Ice> +1 blocker
17:14:43 <adamw> +1 viking
17:14:45 <adamw> =1 blocker
17:14:50 <tflink> Viking-Ice: unless you're looking to get the attention of several people at the same time
17:14:50 <adamw> sigh.
17:14:51 <cmurf> +1 blocker
17:14:54 <adamw> I mean, +1 getting back to the voting
17:14:59 <cmurf> it should work or we need to be told why it can't be made to work
17:15:03 <tflink> but I'm not planning to bring a gavel to a tazer fight
17:15:18 <Viking-Ice> tflink, that's what lightnings are for It's not without reason I carry the hammer of Þór
17:15:22 <adamw> i'm probably -1 blocker for beta, though. i don't * think* a lot of people are going to stick /boot on a btrfs subvol. probably doesn't pass the 'last blocker' smell test.
17:15:25 <cmurf> grub2-mkconfig produces a working booting system grubby does not
17:15:34 <adamw> cmurf: *everything* should work, but not everything can be a blocker.
17:15:39 * tflink makes note not to make Viking-Ice too mad, he has the lightnings
17:15:40 <roshi> basically, a bug that causes specific exceptions to the criteria - not a complete failure to meet the criteria cmurf
17:15:54 <roshi> I thought all vikings had lightnings...
17:15:56 <cmurf> post-install criteria
17:15:59 <cmurf> it should boot
17:15:59 <roshi> +1
17:16:01 <tflink> hammer and lightning in one
17:16:07 <tflink> yeah +1
17:16:12 <Viking-Ice> smash and strike ;)
17:16:13 <tflink> well, +.5
17:16:17 <adamw> cmurf: the point is that this bug does not violate that criterion in all cases, or anywhere *close* to all cases
17:16:28 <cmurf> ummm yes it does
17:16:34 <adamw> cmurf: ummmm no
17:16:36 <cmurf> if you put btrfs on boot it does not boot
17:16:37 <tflink> cmurf: not for btrfs autopart
17:16:44 <adamw> cmurf: right, and that's what, 0.1% of installs?
17:16:46 <Viking-Ice> we have enough votes let's move on
17:16:52 * adamw pulls number wildly out of ass, but you get the point
17:17:13 <cmurf> ok well that's a vague way to decide what is a blocker
17:17:33 <adamw> cmurf: unfortunately no-one's figured out how to take all the subjectivity out of it.
17:17:41 <tflink> cmurf: the process, by definition, is somewhat subjective
17:17:44 <adamw> it's pretty hard to write deterministic rules to cover ALL POSSIBLE BUGS EVER
17:17:53 <adamw> i'd like it if we could, but it'd take a smarter monkey
17:17:57 <cmurf> well it's not even about the bug details
17:17:59 <cmurf> it's about the result
17:18:07 <adamw> not really
17:18:24 <adamw> it's about how commonly an issue can be encountered before we decide it's unacceptable
17:18:40 <adamw> or how important it is to us that the specific broken configuration be fixed
17:18:54 <cmurf> ok well i think it's more ideological. you want the installer installing things that work, not things that don't work.
17:19:01 <adamw> do we have some particularly pressing reason why we really want people to be able to put /boot on a btrfs subvol in f20 beta, for instance?
17:19:29 <cmurf> so it can be tested
17:19:33 <adamw> cmurf: that's all well and good, but it's a pretty impossible standard to set. i doubt we've ever done a single release where you couldn't somehow persuade the installer to deploy something non-bootable.
17:19:38 * Viking-Ice acks to the proposed blocker critera and shrughs of time wasting, puts on intermission https://www.youtube.com/watch?feature=player_embedded&v=AGF5ROpjRAU and goes out for a smoke
17:19:44 <cmurf> better to have it working for beta and blow up than final and blow up
17:19:56 <adamw> sure.
17:20:03 <adamw> but we're not in an ideal world =)
17:20:25 <adamw> i just don't think this passes the 'smell test' - if we got to a go/no-go meeting and this was the last bug, do you think folks would generally favour pushing the release out a week to fix this?
17:20:48 <cmurf> ha
17:20:57 <cmurf> ok you and i know full well that that would certainly get this bug a lot of attention
17:21:02 <adamw> there is a bit of a tension between the 'system-specific bugs' clause and the 'each of these requirements applies to all supported configurations described above' bit of the criteria, which we should probably resolve more clearly.
17:21:06 <cmurf> and then we'd see whether or not people expect it to work and when
17:21:15 <cmurf> clarity would come
17:21:27 <adamw> cmurf: well, i don't like to push things too far there
17:21:37 <adamw> there is a question of credibility
17:21:42 <cmurf> i don't think it's pushing that far
17:21:51 <cmurf> I think the policy needs to be that if it's offered in the installer it needs to result in a working system; or the offer needs to be removed from the installer. Otherwise you're handing out razor blades to users and telling them to go play on the freeway.
17:21:52 <tflink> the more I think about it, I'm -1 for beta
17:22:04 <adamw> the more 'we' (the folks in blocker review meetings, which ought to be a broad base of people but practically speaking is usually QA people) accept bugs as blockers that don't hold up at go/no-go meetings, the less of it we have
17:22:23 <adamw> cmurf: it's a beta. we explicitly tell you not to install it in any kind of critical situation.
17:22:26 <tflink> testers are responsible for finding the important bugs and knowing which ones those are
17:22:39 <adamw> we are releasing it to be tested, not for you to give all your important files to.
17:22:40 <tflink> finding bugs and raising important ones, rather
17:22:43 <adamw> (types he, from his f20 laptop)
17:23:15 <adamw> the bar you're trying to set is not one we have, generally speaking, ever aspired to
17:23:21 <tflink> I agree that it doesn't pass the "last blocker at go/no-go" test
17:23:43 <adamw> if you look at the delta between beta and final, or just look at the betas we've shipped in the past, it is not a principle i think we're capable of accepting
17:24:25 <tflink> adamw: I disagree on the capable but it certainly is a different standard than the one set in the past
17:24:30 <adamw> hell, look at the OS X bootloader bug: we shipped a *final release* which will give you a non-bootable system last time out. i would love it if we could plausibly say we weren't going to do that, but the fact of the matter is fedora does that.
17:24:53 <adamw> oh, wait, that's an install showstopper isn't it? still, you get the idea.
17:25:01 <adamw> i'm pretty sure we've shipped bugs like this before.
17:25:05 <tflink> adamw: that's a dangerous line to walk
17:25:07 * adamw is the realist
17:25:11 <cmurf> adamw: we both know that when it comes down to the wire a LOT of individual blocking bugs, if they had not been fixed, would not have passed the go/no-go smell test
17:25:23 <cmurf> that didn't happen because they were fixed before the wire
17:25:30 <adamw> cmurf: i'm not sure i agree with that. at least, i try not to vote +1 on bugs like that.
17:25:37 <adamw> anyhoo
17:25:43 <cmurf> there is a significant emotional effect of go/no-go on bugs holding up releases
17:25:43 <adamw> maybe we should just count votes and move on
17:25:46 <tflink> I see +3/-1
17:25:57 <adamw> i thought you said -1?
17:26:07 <cmurf> i count a draw
17:26:07 <tflink> I did, I didn't see you explicitly say -1
17:26:14 <tflink> +3/-2
17:26:20 <tflink> did I miss another one?
17:26:24 <cmurf> so punt the thing, and tell the submitter to propose it for final
17:26:42 * jreznik is blocked by other meetings, tries to follow it here and is more -1 blocker for beta for this
17:27:04 <tflink> +3/-3
17:27:06 <cmurf> definitely a draw
17:27:17 <cmurf> ok so punt it, let's get info from pjones
17:27:26 <cmurf> vote on it in a week
17:27:38 <Viking-Ice> ?
17:27:39 <tflink> I'd rather make a decision so we don't have this same argument again in a week :)
17:27:39 <cmurf> we'd have +6 for that
17:27:45 <Viking-Ice> what it was +5 just a minute ago
17:27:51 <cmurf> tflink i will promise not to argue next week
17:28:13 <kparal> I'm OK with -1 for Beta
17:28:22 <tflink> +3/-4
17:28:34 <Viking-Ice> <tflink> well, +.5
17:28:42 <tflink> Viking-Ice: later changed to -1
17:28:42 <cmurf> reject blocker, get info from pjones, revist for final
17:29:04 <Viking-Ice> nonsensce we have been carrying this for 2 GA release now let's put this to rest
17:29:15 <adamw> that seems like wonky logic
17:29:15 <Viking-Ice> peter can just fix grubby
17:29:24 <cmurf> viking_ice i agree however there is a vote here and it's +3/-4
17:29:27 <Viking-Ice> adamw, it's a clear violation on top of that
17:29:32 <adamw> the fact that we have shipped stable releases with the bug and there has not been any significant complaint supports -1, not +1
17:29:48 <adamw> Viking-Ice: i disagree. to me it's a conditional violation, which means it's a subjective call based on severity and broadness of impact.
17:30:02 <Viking-Ice> adamw, yeah yeah we all know how you judge that
17:30:05 <cmurf> adamw: fair point, HOWEVER if there is ever a day in this century when btrfs ships as default fs, this needs to be fixed
17:30:14 <cmurf> and we shouldn't wait until the last minute to be fixing every btrfs related bug
17:30:18 <tflink> cmurf: sure, but that's not f20
17:30:19 <cmurf> bit by bit is a good idea
17:30:26 <cmurf> baby steps
17:30:31 <cmurf> this is a baby step for f20
17:30:34 <adamw> i mean, strictly speaking lots of bugs are conditional, but it's pretty obvious if it affects like 20% of all installs, that's bad. but when it's much smaller than that, like here, it's not clear.
17:30:39 <tflink> proposed #agreed 864198 - RejectedBlocker - This does not clearly violate any F20 beta criteria as it's a corner case. Therefore, it does not qualify as a release blocking bug for f20 beta.
17:30:46 <Viking-Ice> nack
17:31:00 <tflink> Viking-Ice: patch?
17:31:01 <adamw> you shouldn't nack the agreement because you disagree with the vote
17:31:07 <cmurf> right
17:31:08 <Viking-Ice> tflink, you could have proposed the blocker when we had clear +5 yet you did not but now you do
17:31:22 <adamw> only if there's something wrong with the text as it represents the discussion/vote we had
17:31:26 <cmurf> i'd patch it to include the fact it's a long standing bug that has other consequences and needs to be fixed, what's the hold up?
17:31:34 <tflink> Viking-Ice: I usually wait until the discussion slows down a bit
17:31:41 <Viking-Ice> adamw,  so the lesson to learn here is to stall until tflink changes his mind
17:32:32 <adamw> well, no, i'd say the lesson is that when a bug seems to be particularly contentious and discussion clearly isn't settled yet, don't hold a vote in the middle of things.
17:32:43 * tflink apologizes for speaking too quickly before
17:32:49 <adamw> i'm not sure about that +5, anyway. if you were counting me as +1 at any point, that's wrong (my fault for doing joke votes)
17:32:51 <tflink> I think, anyways
17:32:52 <adamw> i was never +!
17:32:54 <adamw> +1
17:33:12 <Viking-Ice> still does not change the fact that this is a violates the criteria
17:33:24 <adamw> Viking-Ice: let's not go over that again.
17:33:26 <Viking-Ice> regardless of your thoughts of how many are affected
17:33:28 <tflink> so do many bugs
17:33:53 <adamw> the thing about 'conditional blockers' is pretty accepted practice, by now. it's not like this is the first time we have considered or rejected a bug on that basis.
17:33:53 <tflink> I don't think there's ever been a fedora release without some bugs that are conditional violations of criteria
17:34:16 <adamw> i'm confused as to why people are acting like we're doing something shockingly new, when this seems like business as usual to me.
17:34:31 <Viking-Ice> no problem reject this and I get more reporters to comment on it and re propose it as a blockers so adam can up his count
17:34:33 <tflink> f20a was released with a bug that has hit more people than have commented on this one
17:34:37 <adamw> i may have made a bad job of explaining/interpreting certain bits of the criteria, in which case sorry, i should look at making that clearer.
17:34:41 <cmurf> ok well punting a bug that prevents a system from booting forever doesn't seem like good policy
17:34:50 <cmurf> either remove the capability or fix the bug
17:34:59 <cmurf> i'm fine with it being rejected as a blocker for beta
17:35:18 <cmurf> i think the proposal needs to ask pjones what the hold up is, maybe he needs something grub2 folks don't
17:35:24 <adamw> cmurf: that's the purpose of this meeting, remember. we're not really here to decide whether someone should be admonished for not fixing the bug for two releases.
17:35:24 <cmurf> it's a long standing bug
17:35:26 <tflink> you could also apply the argument to pokemon systems
17:35:54 <cmurf> i'm not saying admonished
17:36:24 <cmurf> i'm saying to recognize it's a problem that might very well be a blocker in the (near) future, a fix is eventually going to be very necessary
17:36:44 * adamw has mislaid his crystal ball
17:36:45 <tflink> and at that point, I'll be a blocker
17:36:51 <cmurf> the opensuse folks have this working by the way
17:36:54 <cmurf> in their beta
17:36:58 <adamw> ...okay?
17:37:08 <cmurf> offered in the installer, and it boots
17:37:11 <Viking-Ice> adamw, we need to start testing btrfs as cmurf has pointed out and this is a clear criteria violator and I rather like we sort this out in beta but sure let's revisit as a final if you so much desire dealing with boot/fs related issues at that time
17:37:12 <adamw> not really sure what relevance that has to anything.
17:37:21 <tflink> proposed #agreed 864198 - RejectedBlocker - This does not clearly violate any F20 beta criteria and is a corner case. Therefore, it does not qualify as a release blocking bug for f20 beta.
17:37:34 <adamw> Viking-Ice: i would prefer the bug be fixed for beta. i would prefer the bug be fixed in the next five minutes. that doesn't make it a release blocker.
17:37:47 <Viking-Ice> adamw, it violates the critera which makes it a blocker
17:37:48 <tflink> agreed, I'd love to see this fixed
17:38:06 <tflink> I'd be willing to wager that patches would be considered
17:38:06 <cmurf> adamw is correct on principle, i think the beta criteria support a stronger position however
17:38:09 <cmurf> so let's move on
17:38:09 <Viking-Ice> but based on your whim count which is totally irrelevant you decide to ignore it
17:38:15 <adamw> Viking-Ice: you keep just saying that, and completely disregarding the objection which has been made to the statement.
17:38:20 <tflink> ack/nak/patch?
17:38:32 <adamw> Viking-Ice: it is not a whim and it is not totally irrelevant. it is something we have been doing, consistently, for multiple releases. it's a standard part of blocker voting.
17:38:35 <cmurf> ack
17:38:40 <adamw> ack
17:38:44 * cmurf is going for coffee
17:38:58 <adamw> Viking-Ice: seriously, just go look back through the logs...
17:39:15 <kparal> ack
17:39:25 <tflink> #agreed 864198 - RejectedBlocker - This does not clearly violate any F20 beta criteria and is a corner case. Therefore, it does not qualify as a release blocking bug for f20 beta.
17:39:35 <tflink> on the bright side, that was the last proposed blocker on my list
17:40:17 <Viking-Ice> we got the mei mei bug proposed as well but I removed it since it looked like no one tested it on f20 or kernel 3.11 for that matter
17:40:18 <tflink> on to proposed FE
17:40:35 <tflink> mei mei?
17:40:38 <Viking-Ice> 917081
17:40:39 <adamw> Viking-Ice: oh, the intel mei stuff?
17:40:47 <Viking-Ice> adamw, yeah
17:41:01 <adamw> i was hitting that somewhere. erf. can't remember if it was on my dell laptop or what.
17:41:12 <Viking-Ice> it came with the 3.10 kernel
17:41:14 <adamw> https://bugzilla.redhat.com/show_bug.cgi?id=980221
17:41:40 <adamw> oh, looks like I figured it was fixed in 3.11rc1?
17:41:47 <Viking-Ice> it went ( for me with ) 3.11 as well as 3.9 awhere not affected
17:41:58 <adamw> sounds like it matches my experiences
17:42:08 <Viking-Ice> yeah but the GA release are using 3.10.x
17:42:18 <adamw> yeah, not an issue for this meeting, though
17:42:32 <Viking-Ice> it got proposes hence I warranted it should be mentioned
17:42:54 <Viking-Ice> atleast ( even thou I removed it )
17:43:03 <tflink> Viking-Ice: you do realize that if I had done that, you would be reading me the riot act right now, right?
17:43:35 <Viking-Ice> tflink, no I would not there was no indication in the bug that people actually tried this on F20
17:44:05 <tflink> #topic (1007590) Black screen after F20 graphical install on PPC64
17:44:08 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1007590
17:44:10 <tflink> #info Proposed Freeze Exceptions, glibc, ASSIGNED
17:44:21 <adamw> Viking-Ice: sure, i should've said, sounds like we don't need to accept it, good idea to bring it up though
17:45:20 <adamw> ppc64 is not a primary arch.
17:45:32 <adamw> are we on to FE?
17:45:36 <adamw> oh yeah
17:45:39 <Viking-Ice> I think so yes
17:45:43 <Viking-Ice> so +1 FE
17:45:47 <adamw> sounds like +1 FE then, showstopper issue for a secondary arch
17:46:12 <jreznik> do FEs makes sense before freeze?
17:46:28 <Viking-Ice> not really
17:46:32 <adamw> jreznik: sure, it means we will take a fix once freeze kicks in
17:46:41 <Viking-Ice> but we can just as well cut them down now
17:46:44 <adamw> the status has no impact *right now*, it just gets us out front of the voting process.
17:46:59 * roshi was going to ask that jreznik
17:47:02 <tflink> proposed #agreed 1007590 - AcceptedFreezeException - This is a showstopper for PPC64 and while not PA, a tested fix would be considered past freeze.
17:47:11 <adamw> ack
17:47:19 <jreznik> ack
17:47:23 <roshi> ack
17:47:29 <tflink> #agreed 1007590 - AcceptedFreezeException - This is a showstopper for PPC64 and while not PA, a tested fix would be considered past freeze.
17:47:47 <tflink> ok, that's all the proposed FE
17:47:59 <tflink> moving on to the accepted blockers not already ON_QA/VERIFIED
17:48:07 <tflink> #topic (986575) installer fails to apply lower bound to resize requests in custom spoke
17:48:10 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=986575
17:48:12 <tflink> #info Accepted Blocker, anaconda, ASSIGNED
17:48:53 <adamw> eh, this is one i'm not sure makes sense for an FE...
17:49:00 <adamw> kinda thing it's better to poke pre-freeze.
17:49:06 <Viking-Ice> this is accepted blocker
17:49:15 <adamw> hum, right
17:49:22 <adamw> was about to say "or as a blocker" :P
17:49:33 <Viking-Ice> I'm not sure we need to go through those now
17:49:34 <adamw> are you clicking the wrong list, tflink?
17:49:41 <adamw> oh no, i missed a line again
17:49:42 <tflink> ?
17:49:45 <adamw> sigh
17:49:48 <adamw> goddamn tiny letters
17:49:51 <Viking-Ice> unless of course we want to drag teh anaconda maintainers in for status updates?
17:50:13 <adamw> tflink: maybe only bring up ones that look like we could do something useful?
17:50:24 <adamw> i agree with viking it's a bit early to go through all of them and just agree that they need fixin' :)
17:50:24 <tflink> k, give me a sec to read through them
17:50:29 <Viking-Ice> lol
17:50:41 <Viking-Ice> what's the status on the usual over size crap
17:50:52 <adamw> dunno if anyone's doing anything about it yet
17:50:56 <adamw> i'll ask desktop team
17:51:06 <adamw> desktop is only juuust barely oversize though
17:51:09 * jreznik promised to take a look but... :(
17:51:26 <adamw> the test image I built yesterday was 1007681536
17:51:33 <adamw> hmm, that's 7MB, thought it was 0.7MB. darn.
17:51:47 <tflink> pschindl: have you done any more poking at 1009132?
17:53:16 <tflink> yeah, the size ones are the bugs that seem to need some annoyance-giving
17:53:24 <tflink> #undo
17:53:24 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x1dc79e10>
17:53:25 <tflink> #undo
17:53:25 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x8443ad0>
17:53:26 <tflink> #undo
17:53:26 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x1dc79650>
17:53:34 <Viking-Ice> yep and they seem to be on status quo
17:53:34 <tflink> #topic (1000891) DVD is oversized (larger than 4.7 GB)
17:53:34 <tflink> #link https://bugzilla.redhat.com/show_bug.cgi?id=1000891
17:53:35 <tflink> #info Accepted Blocker, distribution, NEW
17:53:45 <tflink> has anything even changed on these?
17:53:52 * adamw just poked desktop team
17:54:03 <Viking-Ice> hopefully hard with a stick
17:54:19 <tflink> says the man with a hammer full of lightning :)
17:54:42 <adamw> hehe
17:55:00 <Viking-Ice> tflink, metal stick for better connectivity
17:55:08 <roshi> so, we're not doing anything with 986575 at the moment, right?
17:55:17 <tflink> roshi: correct
17:55:27 <tflink> who do we need to pester about this? notting?
17:55:31 <roshi> ok, just checking before I removed it from my memory
17:55:34 <roshi> :D
17:55:37 <adamw> dvd size, notting would be a good suspect, and jreznik
17:55:43 <adamw> for desktop, the desktop team
17:55:44 <adamw> is KDE oversize?
17:55:59 <tflink> not sure - its not filed as a blocker if so
17:56:14 <jreznik> I think it was ok
17:56:43 <Viking-Ice> pester bill harder about thsi
17:56:45 <Viking-Ice> mean this
17:57:12 <Viking-Ice> adamw, hand him a metal stick tell him to hold it for a minute and I will raise the hammer of lightning
17:57:13 <jreznik> yeah, sure
17:57:35 <Viking-Ice> give him a light jolt to get things moving....
17:57:38 <tflink> Viking-Ice: not too much lightning, that'll delay any fixes even more ;)
17:57:57 <Viking-Ice> not to crispy noted
17:58:35 <tflink> I just have a feeling that this is going to produce another flamewar on devel like f19
17:58:55 <tflink> so, anyone want the #action?
17:58:55 <jreznik> it is...
17:58:59 <Viking-Ice> tflink, it will and always will as long as we keep shipping the dvd
17:59:03 <adamw> hand it to jreznik
17:59:06 <jreznik> yep
17:59:38 <tflink> #action jreznik to start investigating ways to trim down the dvd size or find someone to do it
18:00:04 <tflink> #info DVD still oversize, needs discussion/changes to get it back under 4.7 GB
18:00:27 <tflink> anything else here?
18:00:32 <jreznik> or stop shipping DVDs :)
18:00:55 <tflink> #action jreznik to start campaign to stop shipping dvds
18:01:06 <Viking-Ice> +1 to that
18:01:42 <tflink> anyhow, I'm not sure that any other blockers need attention right now
18:01:48 <adamw> hey, looks like we're not the only ones who half-ass things
18:02:01 <tflink> the desktop team seems aware of the isssue and is working to rebuild stuff
18:02:07 <adamw> the FAA panel on electronic devices on airplanes says wifi should be fine because "The vast majority" of aircraft "are going to be just fine,"
18:02:24 <adamw> y'know, if there's ONE time when I worry that 'vast majority' might be a bit too loose a criterion...
18:02:32 <adamw> it's when it comes to giant flying machines.
18:02:51 <roshi> I like how the FAA wants me to turn off a GPS because it'll cause interference... o.O
18:03:03 <roshi> damn receivers - always interfering with things
18:03:11 <roshi> </sarcasm>
18:03:13 <tflink> any other accepted blockers that people want to review
18:03:17 <adamw> nope
18:03:40 <tflink> roshi: you expect people to be able to tell the difference between a transmitter and a receiver by just looking at it?
18:03:48 <tflink> then it's time for #topic Open Floor
18:03:53 <roshi> well, it's a GPS
18:03:56 <tflink> fail
18:04:00 <roshi> what else is it supposed to be?
18:04:01 <tflink> #topic Open Floor
18:04:04 <roshi> :p
18:04:26 <tflink> roshi: not sure, but you had better turn it off or the plane might crash
18:04:49 <tflink> any other topics that should be brought up today?
18:05:17 <tflink> or do we all meander over to the fesco meeting that just started?
18:05:40 * tflink sets quantum magic fuse made from unicors to (0,5] minutes
18:05:57 <roshi> unicors - those are rare
18:06:00 <tflink> #info next blocker review meeting will be 2013-10-09 @ 16:00 UTC
18:06:04 <adamw> i've got to go make dinner
18:06:13 <tflink> roshi: even more rare now that I'm making fuses out of them :)
18:06:14 <adamw> so if someone can go and be Very Alarmed at the fesco meeting that'd be great
18:06:26 * tflink is getting the panic button out
18:06:42 <adamw> ah, the trusty old standby
18:06:49 <adamw> bbl
18:07:43 <tflink> boom!
18:07:48 <tflink> thanks for coming everyone!
18:07:54 * tflink will send out minutes shortly
18:07:58 <tflink> #endmeeting