16:01:10 #startmeeting f20beta-blocker-review-1 16:01:10 Meeting started Wed Sep 25 16:01:10 2013 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:10 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:01:10 #meetingname f20beta-blocker-review-1 16:01:10 #topic Roll Call 16:01:10 The meeting name has been set to 'f20beta-blocker-review-1' 16:01:31 * roshi is here 16:01:33 * pwhalen is here 16:01:36 I'm here 16:01:55 * mkrizek here 16:01:59 time for fun! 16:02:04 * satellit listening 16:02:19 ahoyhoy 16:02:27 * adamw sets phaser to FUN 16:03:05 * jreznik is around but listening to another meeting 16:03:09 that was quick :) 16:03:19 any volunteers for secretary duty? 16:03:46 I got it 16:04:31 OK, let's get started with some boilerplate 16:04:41 Why are we here? 16:04:41 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 nice-to-have bugs. 16:04:48 We'll be following the process outlined at: 16:04:48 #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:04:54 The bugs up for review today is available at: 16:04:54 #link http://qa.fedoraproject.org/blockerbugs/current 16:05:01 The criteria for release blocking bugs can be found at: 16:05:01 #link https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria 16:05:04 #link https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria 16:05:10 #info Up for review today, we have: 16:05:18 #info 10 Proposed Blockers 16:05:18 #info 3 Accepted Blockers 16:05:18 #info 0 Proposed Freeze Exceptions 16:05:18 #info 3 Accepted Freeze Exceptions 16:05:35 * kparal can't attend today, sorry 16:05:37 if there are no objections, we'll get started with the proposed blockers 16:05:56 #chair adamw kparal 16:05:56 Current chairs: adamw kparal tflink 16:06:10 #topic (1009809) KeyError: 'name' 16:06:10 #link https://bugzilla.redhat.com/show_bug.cgi?id=1009809 16:06:10 #info Proposed Blocker, anaconda, MODIFIED 16:07:19 looks like this affects nfs iso installs 16:08:03 from the criteria notes: "The installer can handle two different types of NFS repository. It can either contain a package tree, as with HTTP and FTP repositories, or it can contain the DVD ISO image of the same release as the installer. For Beta, only one of these types must work - if one works and the other doesn't, that is OK. " 16:08:04 yeah, sounds like a blocker - crashes right away 16:08:14 oh, good point 16:08:17 so, actually, not a blocker, per what we decided before 16:08:18 does nfs repo work? 16:08:30 nfsiso blocks beta only? 16:08:45 fenris02: no, beta is blocked only if nfs *and* nfsiso don't work 16:08:50 ah, ok 16:08:54 seems odd though 16:08:58 tflink: it's not 100% clear from the reports but it looks like yes 16:09:00 um, check the matrices? 16:09:18 fenris02: there was a previous release where we had to make a go/no-go day call whether to ship beta with one broken but the other working, iirc 16:09:22 and we decided to ship 16:09:53 metrics on how / what people install would be nifty at this point 16:10:28 tflink: hum, looks like he didn't fill out pass or fail for regular nfs for alpha 16:10:39 logic is that you can always turn nfs<->nfsiso 16:11:07 nfs->nfsiso would be trickier, i guess 16:11:09 I'm not even sure that it was tried 16:11:26 punt, someone test with nfs? 16:12:19 for now, sure 16:13:36 proposed #agreed 1009809 - While this could be a blocker, it isn't clear if nfs repos are working yet and only one is required to work for beta. Will revisit when we have more data on nfs repos 16:13:56 #topic (1010453) Anaconda uses btrfs when lvm is selected in text mode 16:13:59 #link https://bugzilla.redhat.com/show_bug.cgi?id=1010453 16:14:01 #info Proposed Blocker, anaconda, MODIFIED 16:14:24 oh 16:14:27 #undo 16:14:27 Removing item from minutes: 16:14:28 #undo 16:14:28 Removing item from minutes: 16:14:30 #undo 16:14:30 Removing item from minutes: 16:14:49 +1 for 1009809 punt 16:14:51 paying attention ftw 16:14:57 +1 punt 16:15:02 ack 16:15:08 ack 16:15:10 ack 16:15:20 #agreed 1009809 - While this could be a blocker, it isn't clear if nfs repos are working yet and only one is required to work for beta. Will revisit when we have more data on nfs repos 16:15:26 #topic (1010453) Anaconda uses btrfs when lvm is selected in text mode 16:15:29 #link https://bugzilla.redhat.com/show_bug.cgi?id=1010453 16:15:31 #info Proposed Blocker, anaconda, MODIFIED 16:16:22 I see there is a fix now, haven't tried it. did anyone else have time? 16:16:49 well, we've got to get people to test btrfs *somehow*...:P 16:16:52 +1, i guess 16:16:55 i think it was just posted today 16:17:16 that's a fun one technically not a blocker it does indeed deliver a filesystem just not the correct one ;) 16:17:19 +1 16:17:22 +1 blocker 16:17:33 +1 16:17:33 +1 16:17:35 +1 block. anaconda should do what you selected 16:17:41 +1 16:17:52 fenris02, anaconda is getting smarter then the user ;) 16:17:57 * fenris02 chuckles 16:18:09 proposed #agreed 1010453 - AcceptedBlocker - Violates the following F20 beta release criterion for lvm partitioning in text installs: "Complete an installation using any combination of disk configuration options it allows the user to select" 16:18:14 ack 16:18:20 ack 16:18:21 ack 16:18:24 ack 16:18:27 ack 16:18:37 ack 16:18:54 #agreed 1010453 - AcceptedBlocker - Violates the following F20 beta release criterion for lvm partitioning in text installs: "Complete an installation using any combination of disk configuration options it allows the user to select" 16:19:06 #topic (1010495) Apple Mac EFI: you have not created a bootloader stage1 target device 16:19:09 #link https://bugzilla.redhat.com/show_bug.cgi?id=1010495 16:19:12 #info Proposed Blocker, anaconda, NEW 16:19:52 hello 16:19:52 doesnt that qualify for failing to install? the user cannot boot .. 16:20:08 vague hw support line 16:20:09 +1 16:20:12 FE 16:20:35 bcl told me in IRC the other day this won't get fixed :/ 16:20:44 Apple HW is special 16:20:45 fun 16:20:46 required changes too messy for f20 at this point, he says 16:20:57 it rather sucks to ship two releases in a row which don't work properly on macs 16:20:57 Viking-Ice, efi (not uefi) 16:21:10 https://bugzilla.redhat.com/show_bug.cgi?id=1010495#c6 16:21:15 adamw: for 10009809 I can test this one tonight I use NFSISO a lot for testing 16:21:51 adamw, well we block and delay for a fix to land 16:22:06 ( if we care enough ) 16:22:39 * spstarr_work is indifferent to 1010495 i cant test this and have no EFI systems 16:23:09 anaconda could just error out sorry efi waterproof ;) 16:23:30 i guess i'm -1 blocker as there's no sense in shipping f19 with it broken then blocking f20 for it, but it does suck 16:23:43 'i'm sorry, this is a mac, and like N-O. NO.' 16:23:52 i thought we figured this out right before f19 shipped 16:24:04 it was reported right before f19 shipped, I mean 16:24:10 yeah I think so 16:24:55 is bcl here to give us gestimated delay on release if we block on this 16:25:01 hmm, that might have been a factor 16:25:51 i'm also interested if the stuff from comment #12 onwards affects the question of shipping the fix in f20 16:26:07 having users having to wait additional 6 months or more for $NEXT_RELEASE is worse then we slip for three weeks or what not 16:27:11 Viking-Ice: for the users with the affected hardware, yup 16:27:22 adamw, for the rest of the world as well 16:27:24 so it's a tradeoff between affected and unaffected users 16:27:36 it's not like we have ever released on time and we aren't about to start doing that now 16:27:55 so not slipping would be out of character but shows we care ;) 16:27:56 considering we already punted +1 week 16:28:04 Viking-Ice: and with that attitude, we'll never ship on time 16:28:19 tflink, only if we never be ready 16:28:21 so the question comes down to two things: 16:28:45 looks like bcl isn't around (or is playing possum) 16:28:46 mac hw is funky, but is relatively common. 16:28:48 1) how long would it take to add needed functionality to support macs 16:29:10 can anyone else speak to the issue, or is bcl the one and only? 16:29:11 2) how many users would be affected by this and are we OK with two releases that won't work on apple HW 16:29:48 I personally think one fine two releases user == gone 16:30:10 there is a significant difference between 1 and 2 releases, yeah, with the maintenance cycle 16:30:23 but if it's really that disruptive a change we have to take that into account 16:30:25 especially if we end up delaying f21 16:31:04 you mean if we get what would we do if we had time time 16:31:32 adamw: I'd rather not block on mac stuff. 16:31:39 Viking-Ice: yeah, that reminds me that I need to go check on what happened to that conversation 16:31:53 I *may* have time to try out a label idea, I can do that w/o the new parted, but I may not. 16:32:03 bcl: heh, we keep going around the roundabout on this one, then 16:32:06 bcl, what are we talking much delay here 16:32:10 does anyone have even a guess as to the percentage of users on mac hw? 16:32:19 not anymore 16:32:24 i recall a few releases back we used to explicitly except Macs from the install criteria, then we changed that because it seemed like everyone agreed we should support them 16:32:30 now we're going to put it back? 16:32:44 roshi: usable stats on this kind of question is something we're really lacking :/ 16:32:45 I do actually dual boot mine, but once I've installed once I just fedup things. 16:32:53 we used to have smolt but it died and census hasn't been deployed yet 16:32:54 * roshi takes a note of that 16:33:06 delayed 2 releases and those users on apple hw gone 16:33:10 some guys were complaining on g+ how bad it is not to support macs but we only way we can support it - is to have people working on macs and have macs available... 16:33:21 adamw: Ill not debate criteria, but IIRC that's because we thought it was working. 16:33:26 * satellit_e Virtualbox works on my macbook pro 16:33:38 What we have here is it not working, and no solution pending ATM, just some ideas. 16:33:51 you're meaning in a kind of 'structural' sense 16:33:53 right? 16:34:03 which is really stuff that should happen in that short time between releases that we have ;) 16:34:07 it's not just a bug but a kind of incompatibility of approach... 16:34:17 bcl, just throw wwoods at it he works well under pressure fueled by moonshine ( just look at fedup ) 16:34:22 right. 16:34:47 our HFS+ ESP looks like a mac HFS+ boot disk, and we don't yet have a good way to tell the difference between them. 16:35:06 on one hand that's good, because it shows up in the lists and boots with a nice icon. 16:35:16 it's becoming more a policy question than anything :/ 16:35:26 On the other hand, IIRC the workaround is to just delete it and make a new one. 16:36:02 would just making a new one every time work? 16:36:12 It isn't really stopping you from installing, it just makes it more manual. and nothing has changed with regards to that from f19. 16:36:36 tflink: then you end up with more than 1 which is something we fixed :) 16:36:37 well, it makes it quite a *lot* more manual, really 16:36:55 cant we detect delete make new one 16:37:03 then 16:37:04 bcl: true, but if it's a choice between not working and having a bunch of them, which is worse? 16:37:09 the difference between 'i can use the guided path and everything works' and 'i have to know how to create an EFI-bootable layout with custom partitioning' is quite a big one 16:37:29 yeah those are not waterproof steps 16:37:38 I'll have to run through it again, but I think you can just delete it in the recover space dialog. 16:38:03 wouldn't that run the risk of deleting the OSX loader as well? 16:38:12 tflink: my memory is fuzzy, but having more wasn't good either. 16:38:24 right, i don't see how OS X can still boot if you nuke its ESP during fedora installation. 16:38:27 tflink: only if you pick the wrong one 16:38:39 eh? 16:38:46 how can os x still boot if you nuke its esp? 16:38:55 adamw: you're not. you're nuking ours. 16:39:11 OSX has its own. It is usually alot larger than ours. 16:39:12 bcl: and since the issue at hand is telling the difference between the two, installation becomes a bit more like russian roulette :) 16:39:17 um. my understanding of the bug is that it affects the case of simply taking a clean OS X box and trying to install fedora on top of it 16:39:25 so what 'our' esp are you nuking? what am I missing? 16:39:28 no 16:39:46 this bug (unless I'm totally out to lunch) is when re-installing on top of a previous install. 16:39:49 ah 16:39:56 i may be missing that 16:40:03 but if you are re-installing that should be fine no? 16:40:09 AFAIK if you take a clean system with enough extra space (shrink OSX in OSX) it works fine. 16:40:09 ( to nuke it that is ) 16:40:11 "Steps to Reproduce: 16:40:11 1. Computer contains either a default OS X installation, or a default Fedora 18 or 19 installation." 16:40:22 take a look at the old bug that chris closed. 16:41:04 the initial description of that bug talks about a case of a reinstall over an existing fedora install, yes, but i thought the issue had been found to be wider 16:41:06 1. OS X installed, and successful F18 or F19 system already instaled. 16:41:10 was what it used to say. 16:41:26 (no idea why he closed and duped that, it should have just stayed open) 16:42:16 yeah and you usually close the newer bug dupe of the old one 16:42:17 anyway, you guys decide if you want to block. I will at least re-visit it and make sure I understand it. 16:42:18 right, but like i said, that's just the initial description 16:42:26 later on it seems to change 16:42:33 I *may* try adding a lable, etc. if I find the time. 16:42:38 e.g. c#29: "So the bug is triggered merely by having any ESP on the disk." 16:42:55 and presumably the more recent bug description ought to be more accurate than an older one, all else being equal 16:42:56 rampant random speculation :) 16:43:04 so let' s pull it in as an FE ( so we wont forget it ) and see how it goes 16:43:18 I don't trust any of it unless I test it myself. 16:44:17 still, it's clear we're working from different assumptions 16:44:20 votes? 16:44:27 punt? FE? 16:44:29 +1 FE 16:44:33 adamw: right. need more facts :) 16:44:34 run away? 16:44:46 personally, I'm +1 to run away :) 16:44:48 there's a significant difference between 'affects re-install over an existing fedora install, can be worked around by deleting the old fedora ESP' and 'affects any attempt to auto-partition alongside an existing EFI OS' 16:44:53 +1 beer 16:45:00 +1 beer too 16:45:05 better than running away 16:45:14 * roshi would prefer bourbon though... 16:45:16 +1 punt, ask cmurf to confirm once and for all which description is accurate 16:45:29 if it's the more serious case, bcl, would you be open to re-considering blocker status? 16:45:32 * Viking-Ice goes out for a smoke while you guys drink beer 16:46:28 +1 on the punt 16:46:28 adamw: or someone less verbose. 16:46:38 bcl: heh, us word fountains have gotta stick together 16:46:45 If it blocks installing to a clean system I'm +1 16:46:50 OK 16:46:55 that used to work fine IIRC. 16:47:05 proposed #agreed 1010495 - It's still not completely clear what is going on here and we need more information on the issue and any possible fixes. Will revisit when there is more available information 16:47:10 there were definitely a couple of releases where it worked, yep. 16:47:20 nack, make it a bit more specific? 16:48:06 proposed #agreed 1010495 - there's a question as to whether this affects only systems with two existing ESPs, or any system with an existing EFI OS installation. We will establish this and re-visit the bug next time. 16:48:30 ack 16:49:12 ack 16:49:39 #agreed 1010495 - there's a question as to whether this affects only systems with two existing ESPs, or any system with an existing EFI OS installation. We will establish this and re-visit the bug next time. 16:50:10 #topic (908118) Rescue mode does not detect an encrypted Fedora installation 16:50:13 #link https://bugzilla.redhat.com/show_bug.cgi?id=908118 16:50:15 #info Proposed Blocker, anaconda, NEW 16:50:58 "The rescue mode of the installer must be able to detect and mount any installation performed according to the applicable criteria" 16:51:00 seems pretty clear 16:51:06 +1 per criteria 16:51:19 +1 16:51:23 +1 16:51:56 proposed #agreed 908118 - AcceptedBlocker - Violates the following F20 beta criterion for systems with encrypted partitions: "The rescue mode of the installer must be able to detect and mount any installation performed according to the applicable criteria, and provide a shell with access to utilities capable of performing typical recovery operations." 16:52:09 ack 16:52:12 ack 16:52:14 ack 16:52:36 #agreed 908118 - AcceptedBlocker - Violates the following F20 beta criterion for systems with encrypted partitions: "The rescue mode of the installer must be able to detect and mount any installation performed according to the applicable criteria, and provide a shell with access to utilities capable of performing typical recovery operations." 16:52:41 #topic (986575) installer fails to apply lower bound to resize requests in custom spoke 16:52:44 #link https://bugzilla.redhat.com/show_bug.cgi?id=986575 16:52:46 #info Proposed Blocker, anaconda, ASSIGNED 16:53:53 +1 per criterion: "When using the custom partitioning flow, the installer must be able to ... Reject or disallow invalid disk and volume configurations without crashing" 16:53:57 yeah, +1 16:54:05 +1 16:54:53 proposed #agreed 986575 - AcceptedBlocker - Violates the following f20 beta criterion when setting partition sizes smaller than usable for installation: "When using the custom partitioning flow, the installer must be able to ... Reject or disallow invalid disk and volume configurations without crashing" 16:55:09 ack 16:55:11 ack 16:56:11 +1 and ack on that 16:56:33 #agreed 986575 - AcceptedBlocker - Violates the following f20 beta criterion when setting partition sizes smaller than usable for installation: "When using the custom partitioning flow, the installer must be able to ... Reject or disallow invalid disk and volume configurations without crashing" 16:57:01 #topic (1009278) UnicodeDecodeError: 'ascii' codec can't decode byte 0xe6 in position 0: ordinal not in range(128) 16:57:04 #link https://bugzilla.redhat.com/show_bug.cgi?id=1009278 16:57:07 #info Proposed Blocker, anaconda, MODIFIED 16:57:36 i feel +1 on this for beta, do we have a criterion? 16:57:48 not sure, but I'm also +1 16:57:59 +1 16:58:05 3 people have reported this in the last 2 days 16:58:11 reported/duped 16:58:25 +1 16:58:31 yeah +1 16:58:46 we don't really have a good criterion for this that I can see 16:59:00 I did not hit this however not in RC3 even but that looks bad 16:59:01 but as far as criteria go ... the closest I can think of is the alpha "must complete" crierion 16:59:07 we can kinda fudge it under "When using the dedicated installer images, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces. ", yeah 16:59:19 but it sucks to go too far towards using that as a catch-all, we should probably have something specific 16:59:31 still, let's use it for now 16:59:32 +1 16:59:33 we need "we deemed it so" criteria 17:00:10 this doesn't happen with the dedicated installer images, though 17:00:29 just lives, IIRC 17:00:56 Viking-Ice: that's more or less what we use this one as 17:01:12 tflink: well it'll have to be 'violates this criterion in the case of XXX' anyway, so 17:01:35 yeah, I was just looking again and hoping that there was something else 17:02:24 proposed #agreed 1009278 - AcceptedBlocker - Violates the following F20 alpha criterion for liveinstalls with a non-default keyboard: "When using the dedicated installer images, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces." 17:02:33 ack 17:02:39 ack 17:03:52 ack/nak/patch? 17:04:57 Viking-Ice, roshi, spstarr_work: ack/nak/patch? 17:05:01 ack 17:05:06 #agreed 1009278 - AcceptedBlocker - Violates the following F20 alpha criterion for liveinstalls with a non-default keyboard: "When using the dedicated installer images, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces." 17:05:13 #topic (1008965) mouse cursor sometimes disappears on login 17:05:13 #link https://bugzilla.redhat.com/show_bug.cgi?id=1008965 17:05:13 #info Proposed Blocker, gnome-settings-daemon, NEW 17:05:37 not sure this really needs to block beta, though it is a pain 17:05:42 is that a vm? 17:05:57 I've seen this on bare metal 17:06:02 ( I know about a bug that resets mouse speed when using a vm dont know if I reported it thou ) 17:06:32 I have actually seen this with rdesktop ( or similar bug ) on F18 17:06:33 do we even have a criterion for this? 17:06:38 +1 FE 17:06:57 it's a nuance which you can live with 17:07:03 in beta 17:07:23 I'm on the fence, g-i-s is kinda crappy w/o a cursor 17:07:27 definitely +1 FE (so in this time more to push devels to take a look than the need for freeze exception) 17:07:45 s/kinda/pretty/ 17:08:22 there's the 'kill g-s-d' workaround 17:08:29 does that leave gsd dead or make it respawn, btw? 17:08:51 tflink: sorry, awk on previous bug 17:08:53 ack 17:09:16 adamw: one would hope that it respawns 17:09:37 is that a sneaky way of saying 'it should respawn', tflink? :) 17:09:44 i spy someone trying to smuggle in an s word 17:10:16 let's not dwell to long with this 17:10:37 it's like saying heck instead of hell 17:10:39 :) 17:10:40 I'm pretty sure the guys will have fixed this for beta anyway 17:11:02 Viking-Ice: that's the kind of thing that's bitten us in the ass before, but yeah, for now -1/+1 17:11:20 has anyone tried the kparal patch? 17:11:58 http://koji.fedoraproject.org/koji/taskinfo?taskID=5981871 17:12:04 contains that patch 17:12:24 not yet, didn't see it 17:12:57 proposed #agreed 1008965 - RejectedBlocker AcceptedFreezeException - While unfortunate, this does not violate any F20 beta release criteria and thus is rejected as a blocker for f20 beta. However, a tested fix would be considered past freeze. 17:13:02 ack 17:13:34 ack 17:13:36 ack 17:14:01 #agreed 1008965 - RejectedBlocker AcceptedFreezeException - While unfortunate, this does not violate any F20 beta release criteria and thus is rejected as a blocker for f20 beta. However, a tested fix would be considered past freeze. 17:14:18 #topic (1009132) updates-plugin-WARNING **: failed to download: The backend exited unexpectedly. 17:14:22 #link https://bugzilla.redhat.com/show_bug.cgi?id=1009132 17:14:24 #info Proposed Blocker, gnome-settings-daemon, ASSIGNED 17:14:59 should be a blocker by the criteria 17:15:12 yeah 17:15:14 assuming it's reproducible and not a freak case 17:15:41 bah, I haven't made the actual criteria changes yet 17:15:57 make it so nr1 17:16:11 so nr1? 17:16:42 make it so, number one 17:16:48 http://askmarcbarrett.com/wp-content/uploads/2012/12/star-trek-make-it-so-300x200.jpg 17:16:52 oh, ok 17:16:59 I thought that was some other abbreviations 17:17:57 that would sound like a blocker to me too 17:18:29 a user not able to perform updates *ever* is bad (if they don't use yum manually on cli) 17:18:55 workaroundable, possible if its broken package 17:20:23 +1 17:20:27 * tflink is looking for the criteria change 17:20:51 +1 17:21:33 proposed #agreed 1009132 - AcceptedBlocker - Violates the following F20 beta criterion for graphical updates on a gnome install: "The installed system must be able to download and install updates with the default graphical package manager in all release-blocking desktops." 17:21:41 ack 17:21:43 +1, we should sort it out by beta (with that whole g-s vs old pkg kit thing) 17:21:49 ack 17:21:51 ack 17:22:26 ack 17:23:09 ack 17:23:26 #agreed 1009132 - AcceptedBlocker - Violates the following F20 beta criterion for graphical updates on a gnome install: "The installed system must be able to download and install updates with the default graphical package manager in all release-blocking desktops." 17:23:44 #topic (1004572) AttributeError: 'NoneType' object has no attribute 'id' 17:23:48 #link https://bugzilla.redhat.com/show_bug.cgi?id=1004572 17:23:50 #info Proposed Blocker, python-blivet, ON_QA 17:24:20 +1 17:24:35 adamw: do you want to update the wiki with the new criteria for 1009132? 17:25:28 Anaconda partition crashes are bad if we want Anaconda to be solid at partitioning 17:25:34 roshi: i think it's on tflink's todo 17:25:39 he proposed the change 17:25:50 is this not fixed yet via traditional update? 17:26:15 not pushed stable yet 17:26:15 adamw: you proposed the change 18SEP on test@ 17:26:22 roshi: i did? oh, good for me 17:26:24 then yes, i will :) 17:26:29 :) 17:26:36 now, what did I come in here for? 17:26:38 I did? 17:26:41 why are there kids on my lawn? 17:26:54 this will likely be pushed stable soona nyhow, but +1 17:26:54 because they did not find the mud? 17:27:01 yeah +1 17:27:01 +1 17:27:04 +1 17:27:40 +1 17:27:42 if you want a criterion then "Assign mount points to existing storage volumes" in beta 17:27:52 and/or "Complete an installation using any combination of disk configuration options it allows the user to select " for guided 17:28:45 proposed #agreed 1004572 - AcceptedBlocker - Violates the follwing F20 beta release criterion: "When using the custom partitioning flow, the installer must be able to ... Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes, or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions" 17:28:58 is tha ttoo long? 17:29:08 nope, works fine 17:29:19 roshi: you could cite both criteria in the note if you want extra credit ;) 17:29:49 ack/nak/patch? 17:29:51 adamw: how many extra credits? 17:29:53 ack 17:29:55 ack 17:30:46 sixty three 17:30:59 sixty three == ack ? 17:31:14 Federation or Republic? 17:31:22 lol 17:31:50 * tflink dons moustache and says ... ack 17:31:53 Imperial 17:31:59 le ack 17:32:01 #agreed 1004572 - AcceptedBlocker - Violates the follwing F20 beta release criterion: "When using the custom partitioning flow, the installer must be able to ... Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes, or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions" 17:32:04 ack 17:32:18 #topic (1005506) TypeError: unsupported operand type(s) for +: 'long' and 'NoneType' 17:32:21 #link https://bugzilla.redhat.com/show_bug.cgi?id=1005506 17:32:24 #info Proposed Blocker, python-blivet, MODIFIED 17:32:51 +1 17:32:55 +1 17:32:58 +1 17:33:25 proposed #agreed 1005506 - AcceptedBlocker - Violates the following F20 beta release criterion: "Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes, or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions" 17:33:29 partition code is gosh darn hard :( 17:33:30 ack/nak/patch? 17:33:34 ack 17:33:42 ack 17:33:43 ack 17:33:46 ack 17:34:01 #agreed 1005506 - AcceptedBlocker - Violates the following F20 beta release criterion: "Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes, or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions" 17:34:40 OK, that's all of the propose blockers on my list today 17:34:55 yay 17:35:07 the partition ones worry me 17:35:18 and probably will until Anaconda handles all those cases :/ 17:35:29 on to the accepted freeze exceptions 17:35:34 er, accepted blockers 17:36:00 hrm, do we want to go over the oversize bugs? 17:36:05 is anyone working on them? 17:36:32 not yet but I can start poking 17:36:38 best get it done 17:36:49 notting is probably the first one to start with 17:36:57 #topic (1000891) DVD is oversized (larger than 4.7 GB) 17:36:57 #link https://bugzilla.redhat.com/show_bug.cgi?id=1000891 17:36:57 #info Accepted Blocker, distribution, NEW 17:37:04 1005506 seems to be a dupe of 1004572 17:37:13 ...? 17:38:00 not sure there's much to say 17:38:02 here 17:38:02 heh 17:38:16 i meant get the poking done, not set a topic for the bug 17:38:18 AcceptedBlocker++? Is that a thing? 17:38:21 but sure, we need to poke notting 17:38:29 double-plus accepted 17:38:36 other than to prepare for the flamewar on devel@ on what can be accepted 17:38:48 i guess my new rubygem in Fedora 20 is the cause ;) 17:39:02 we should just drop that dvd altogether 17:39:36 and just use netinstall or sub-community's images ;) 17:40:14 * adamw leaves that one alone 17:40:32 #info work on this process needs to be started soon 17:41:03 #action adamw and/or jreznik to start pestering folks to get stuff removed from the dvd 17:41:34 ok, assuming that I didn't miss any bugs, it would be time for: 17:41:38 #topic Open Floor 17:41:48 Anything else that needs to be brought up today? 17:41:59 Wayland testing possible ? 17:42:07 not there yet 17:42:47 well it's possible in theory 17:43:48 what is our most urgent testing needs now? 17:44:05 those readying this and want to play with wayland in it's brokeness --> log in, drop to a VT and run "gnome-session --session=gnome-shell-wayland" <-- 17:44:22 nothing specifically urgent i don't think 17:44:22 i have class tonight and can allocate from 4:30pm-6:40pm QA cycles 17:44:29 test matrix/test days 17:44:51 * tflink sets the fuse for (0,5] minutes 17:44:57 be useful to run any un-done beta tests against alpha to catch blockers early 17:45:05 tflink, make that a quantum fues 17:45:07 mean fues 17:45:09 so, please let me know and I will do what I can remotely 17:45:10 frack fuse 17:45:21 adamw: yes 17:45:35 * spstarr_work looksat list 17:45:43 * tflink resets the quantum fuse for (0,5] minutes 17:46:09 * Viking-Ice fires a fire arrow up in the air 17:46:12 ok 17:46:16 thanks for coming, everyone 17:46:22 * tflink will send out minutes shortly 17:46:48 #info next f20 beta blocker review meeting will be 2013-10-02 @ 16:00 UTC 17:46:52 #endmeeting