19:00:49 #startmeeting F18 Alpha Go/No-Go meeting 19:00:49 Meeting started Thu Sep 13 19:00:49 2012 UTC. The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:49 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:00:59 #meetingname F18 Alpha Go/No-Go meeting 19:00:59 The meeting name has been set to 'f18_alpha_go/no-go_meeting' 19:01:28 zodbot is clever and does not suffer from "f18 alpha ..." label problem :) 19:01:38 #topic roll call 19:01:43 * nirik is here 19:01:58 ok, who's here for today's neverending meeting? 19:01:59 * jlk is here 19:03:31 * rbergeron is here 19:04:20 rbergeron: hey! 19:04:29 hai 19:04:39 * kparal lurks 19:04:54 * tflink is here 19:05:19 adamw joined too... dgilmore are you around too? 19:05:29 * adamw is here 19:05:34 until he passes out on the keyboard 19:05:54 #info jreznik nirik jlk rbergeron kparal tflink adamw present 19:06:10 #chair adamw rbergeron tflink nirik 19:06:10 Current chairs: adamw jreznik nirik rbergeron tflink 19:06:39 let's start... 19:06:44 #topic Purpose of this meeting 19:06:56 jreznik: si 19:07:00 #info Purpose of this meeting is to see whether or not F18 Alpha is ready for shipment, according to the release criteria. 19:07:02 oui 19:07:07 #info This is determined in a few ways: 19:07:43 #info No remaining blocker bugs ;-) 19:07:49 #info Test matrices for Alpha are fully completed 19:07:58 #link http://qa.fedoraproject.org/blockerbugs/current 19:08:06 #link http://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria 19:08:12 #link https://fedoraproject.org/wiki/Test_Results:Current_Base_Test 19:08:19 #link http://fedoraproject.org/wiki/Test_Results:Current_Installation_Test 19:08:26 #link http://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test 19:09:05 #topic agenda 19:09:32 that noise you hear is me wildly throwing 'pass'es into the matrices 19:09:33 ignore it 19:09:56 heh 19:10:07 So we have a couple of known issues 19:10:09 I think the agenda is pretty clear - we want alpha to be shipped, we want go today... but... 19:10:21 as jlk said, we have a couple of known issue 19:10:25 s 19:11:01 and several options how to make Alpha into releasable state 19:11:44 tflink: do we want formal blocker bug review now? /me thinks so 19:12:24 sure 19:12:34 #info 3 Proposed Blockers 19:12:56 #info 3 non-VERIFIED Accepted Blockers 19:13:17 any objections to starting with the proposed blockers? 19:13:32 nope. 19:13:32 while we're at this can someone quickly knock out the KDE desktop tests? 19:13:42 i am hampered by virt suddenly up and fucking dying on my deskto[ 19:13:49 #topic (855849) could not UEFI boot F18 Alpha (TC6 through RC3) DVD or netinst written to optical disc or dd'ed to USB: /dev/root does not exist 19:13:52 #link https://bugzilla.redhat.com/show_bug.cgi?id=855849 19:13:54 #info Proposed Blockers, NEW 19:13:56 I can try it, rdieter are you around? 19:14:21 jreznik: hi, around but currently a bit busy 19:14:56 * rdieter book marks the link 19:15:00 can the kde tests be done from a install of "KDE Desktop" from the DVD? 19:15:19 re this bug 19:15:22 should be good enough 19:15:37 This bug is triggered by the DVD/boot.iso having spaces in the iso label 19:15:50 the real bug is in how grub2 handles those spaces, but we can work around it by eliminating the spaces 19:16:15 this just requires a quick re-compose (no package changes) of the media, which dgilmore is already working on should we decide to take the respin 19:16:19 use livecd-to-iso since we only need either dd or livecd-to-iso to work 19:16:48 the owners of the secure boot feature would prefer we had working DVD/boot.iso media for Alpha, it'll help them in their efforts 19:17:01 so I'd prefer we took the respun media that we spot-check during this meeting 19:17:18 jlk: sure 19:17:47 jlk: writing it with litd does not count as 'working'? 19:18:35 for the record, the broken cases here are: netinst.iso and dvd.iso, written to optical media or to usb via 'dd' 19:18:56 lives work (or, at least, boot) however they're written, it seems, and netinst and dvd boot if written to usb with 'livecd-iso-to-disk --efi' 19:18:56 adamw: hrm, it's only the dd case? 19:19:12 jlk: yeah, well, that was my result anyway. if i write dvd or netinst with livecd-iso-to-disk, it does boot 19:19:16 i guess litd changes the label? 19:19:22 I think they'd sitll want the physical media working 19:19:40 adamw: was that bios or efi? 19:19:43 efi, of course 19:19:56 there's no issue with bios boot in any case, that i'm aware of. 19:19:58 yes and we just need either method to work for the usb stick either dd or official cd/dvd burner tool to work for cd/dvd 19:19:59 adamw: for the burnt media ? 19:20:17 adamw: ok thats what i was checking 19:20:32 anyway, my vote on this is to take the respun / relabeled DVD set 19:20:33 Viking-Ice: from my pov, dd is not as needed as burned medias 19:20:55 (but not at the expense of another week slip) 19:21:42 so the criterion reads "The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to an optical disc and when written to a USB stick with at least one of the officially supported methods" 19:22:02 strictly interpreted, that requires dvd/netinst written to optical to boot EFI 19:23:13 so this "with all system firmware types that are common on those architectures" says UEFI too... 19:23:14 in boring bureaucratic terms, it's a bit odd to say that using USB media or the lives is a 'workaround' in that case, as the criterion is quite carefully worded to mean that they really all have to work. but we could weaken the criterion, i guess. 19:23:24 jreznik: yes, that's what the language about 'system firmware types' covers. 19:25:15 so the two options are - weaken criteria (with usb/live as workaround for efi) or respin 19:25:18 or, the respin would make us hit the criterion as written, i believe. 19:25:43 yeah. i'm drafting rewords in my head and they're kind of awkward, but eh, we can fix that later, if we choose to weaken it. 19:26:36 we'd pretty much have to start talking about EFI specifically again, unless we want to say it's fine if physical media don't boot BIOS, which we probably don't. 19:27:03 yep 19:27:03 what you've got to ask yourself is this: what percentage of test machines actually boot off of disks these days anyway? And if we're looking at rewording it, we've got to look at that going forward as well 19:27:22 * kparal thinks we could consider removing UEFI requirements from Alpha 19:27:22 discs even. 19:27:59 pjones: i don't really have a firm handle on how many people use dvd vs. usb these days 19:28:10 just for the record "livecd-iso-to-disk --format --msdos --reset-mbr Fedora-18-Alpha-x86_64-DVD.iso /dev/sdb" ( rc3 ) to a usb stick boots the installer just fine and currently is installing package 675 with icelandic keyboard/timezone selected, with Gnome selected as a desktop and added selected software and root password set as well. 19:28:10 kparal: this particular release it would be hard to do that, as secure boot relies on EFI 19:28:12 yeah, I don't either. 19:28:12 it's definitely more usb than it used to be, but i dunno if we can really say we don't care about discs any more 19:28:19 it's something we may want to investigate for the future. 19:28:19 for testing, I'd bet more are using USB 19:28:35 Viking-Ice: that's not EFI, though, so not relevant to this bug 19:28:38 but that's just a feeling - no data to back it up 19:28:54 also how many people are going to use optical + efi together 19:28:55 jlk: at the same time, it's unclear how much SB testing we'll actually get with the alpha that we couldn't get with, say, http://pjones.fedorapeople.org/sb/ 19:29:20 pjones: true, and since you're the owner of the feature, I guess you get to make that judgment call 19:29:33 pjones: right, we always have the option of spinning up special SB test images. heck, i think the best SB testing would be to do a test day, and we can always do custom images for test days. 19:29:37 We could probably table this bug for now to look at the others, revisit this one if necessary 19:29:48 agreed 19:29:50 i think that in general i'd be okay with watering down the criterion to just require that *some* EFI path - any one EFI path - work at Alpha 19:30:00 it might be awkward to implement, but that's just a detail 19:30:13 yeah 19:30:33 I think EFI machines that /can't/ boot usb are uncommon enough that we should be able to get pretty good test coverage there 19:30:35 we had good intentions with the whole 'efi is supported' thing, but it kinda seems like we're still not quite there yet. 19:31:10 well, I think f17 has /fairly/ well supported UEFI, but adding sb changes a lot of procedure 19:31:18 which is really what we're noticing isn't quite working yet 19:31:21 and switching to grub2 as well 19:31:23 adamw: +1 to weaken efi path for alpha 19:31:30 yep 19:31:55 in a way it's the same point, though - BIOS is so old and well established we don't have to bugger about with it like this, UEFI isn't. 19:32:30 I'm OK with weakening the criteria as well, particularly because it could mean we go with the media we already have and the results we already have 19:32:42 agreed 19:32:56 i'd like people to be okay with it 'in principle' as well as just as a way to get goddamn 18 alpha shipped already 19:33:04 but for me, that's true, i'm okay with it in principle too. 19:33:10 i am okay with this in principle :) 19:33:26 * nirik nods. 19:33:29 * kparal already acked 19:33:35 ack 19:33:46 so I think the new criteria for UEFI for /alpha/ is basically: some common boot method must work 19:33:53 yeah 19:33:58 let's do the bureaucracy 19:34:22 and doing sb testing I think in a separate day is fine, and we can try to make some noise around doing it so people actually show up 19:34:24 since they all use the same code, just arranged differently, that's not really terrible 19:34:31 proposed #agreed it is agreed in principle that the relevant release criterion should be weakened so it only requires any one of the 'normal' UEFI boot paths to work, not several 19:34:42 * jreznik really wanted SB working in all cases for alpha but actually dedicated test day with own respin sounds even better now :) pjones, your turn :) 19:34:45 adamw: you beat me to it 19:34:51 adamw: +1 19:34:52 ack 19:34:54 if we all ack that, then we can rejectedblocker the bug 19:34:56 ack 19:35:13 ack 19:35:17 jreznik: hey, I already made f17 images to test with at http://pjones.fedorapeople.org/sb/ (that's f17 + grub2 on efi + shim) 19:35:40 jreznik: in theory that should still be a valid test of the technology - from here on out we're basically testing rel-eng processes 19:35:40 acks from jreznik, rbergeron, pjones would be nice 19:35:45 ack 19:35:51 ack 19:35:54 ack 19:36:02 i guess that's enough =) 19:36:04 * jreznik is trying to multitask kde desktop tests 19:36:07 #agreed it is agreed in principle that the relevant release criterion should be weakened so it only requires any one of the 'normal' UEFI boot paths to work, not several 19:36:10 jreznik: me too, heh 19:36:23 tflink: you want to do the rejectedblocker? you usually format them nicer than me. 19:37:26 proposed #agreed 855849 - RejectedBlocker - With the above modification to the F18 alpha release requirements, this bug is not considered a blocker as USB media created with livecd-iso-to-disk is still able to boot on (u)EFI machines 19:37:48 ack 19:37:56 ack 19:38:04 ack 19:38:06 ack 19:38:14 #agreed 855849 - RejectedBlocker - With the above modification to the F18 alpha release requirements, this bug is not considered a blocker as USB media created with livecd-iso-to-disk is still able to boot on (u)EFI machines 19:38:23 seriously guys, "UEFI". plausibly "efi" if your hands are stuck in the past. No need for 100 other new and weird spellings. :) 19:38:37 sorry pjones =) 19:38:42 adamw: sorry, was blabbing in other meeting 19:38:46 #topic (848305) When kernel modsetting is enabled, laptop screen remians off until Xorg starts (ironlake) 19:38:47 #action adamw to propose criterion modification on test list 19:38:49 #link https://bugzilla.redhat.com/show_bug.cgi?id=848305 19:38:52 #info Proposed Blockers, ASSIGNED 19:39:04 so, sorry for this, it's a bit messy - the actual bug is nothing like the description 19:39:29 we pulled a new plymouth into rc2 to *fix* the bug in the description (among others), it causes problems on certain hardware, described in the later comments 19:39:59 so really the bug is 'on some NVIDIA adapters (we think), booting RC3 live gives you a glitched/unusable GDM and/or shell' 19:40:10 (or sometimes, just a tty with messages on it, while gdm claims to be running) 19:40:33 dropping 'rhgb' from the parameters acts as a workaround, for me 19:40:42 i haven't yet checked if the problem exists on an installed system, from live or from dvd 19:40:50 or on some gfx gdm/shell is ok, just plymouth is glitched 19:41:05 i kinda wish we had more data here 19:41:09 if that's a reasonable workaround, I would think that would be "not a blocker" 19:41:10 adamw: if we have a workaround, i.e. remove rhgb i think its ok for alpha 19:41:11 but not all nvidia, just significant portion (or even not so significant)? 19:41:18 rbergeron: we don't have sufficient data 19:41:25 yeah. 19:41:29 we have three systems we know hit the problem 19:41:32 and two or three we know don't 19:41:36 it'd be nice to have lots more data 19:41:45 if anyone here has an nvidia adapter and hasn't tried booting rc3 desktop live...please do 19:41:57 * tflink is trying to get working livemedia ATM 19:42:07 * nirik would be ok with common bugs explaining the workaround 19:42:15 yup same here 19:42:26 as long as it doesn't hit *too* many systems i guess i'm okay with that 19:42:31 could this end up being a problem with the grub font? 19:42:39 though i always hate 'default procedure produces unusable results' bugs 19:42:47 no. 19:42:50 it's definitely plymouth. 19:42:54 ie, if the font is too big to edit the boot options, you can't really remove rhgb 19:42:57 ohhh 19:43:05 that's only really on virt though isn't it? 19:43:08 or really tiny screens? 19:43:09 for lives that isn't a problem as their bootloader is different 19:43:23 jlk: i noticed yesterday it looks pretty crappy even on metal, but it's vaguely usable 19:43:25 and for an installed system, it could be fixed w/ update 19:43:49 I'm of the opinion that we have work arounds here that are sufficient enough to make this a non-blocker on its own 19:44:15 jlk: i agree 19:44:35 i really would like more data on this one...so little time, so much to do 19:44:39 the grub font could be an issue... 19:45:00 i think adamw shot tha tdown a minute ago 19:45:11 oh, then he said, ohhhhh 19:45:23 it could still be an issue, but no worse than the other workarounds, I think 19:45:29 yeah. 19:45:48 i really need to see what happens on an affected system with a dvd install 19:45:53 i just somehow never got round to it with all the efi bugs 19:45:54 worst case scenario, you get to a console on an installed system, update/change grub cfg to get rid of rhgb 19:46:03 not usable at all on my netbook but it's intel... and I don't think there are many small screen devices with nvidia 19:46:22 so /me is ok with workaround 19:46:27 i do worry that we'll release and it'll turn out half the world hits this bug, but... 19:46:40 but it's alpha 19:46:53 and we can point to the images from branched a day or 3 later 19:47:32 jlk: alpha is not excuse for everything 19:47:33 in my experience there's a lot of people who'll download an official pre-release who won't really ever see anything else. 19:47:38 and then draw conclusions from it. 19:48:00 yeah, we usually get questions about bugs on the alpha media even up beta RC 19:48:01 i mean, by putting an official name on it and putting it on our pages and sending out public announcements we are saying something about it 19:48:02 sure, but if it was perfect it would be final, not alpha. ;) 19:48:12 this bug's a long way from 'perfect', let's be honest. 19:48:16 well, if it's hiting half of hte people who try it 19:48:20 hitting... 19:48:20 I don't think anyone is arguing for perfection 19:48:21 it's 'i download it and boot it and it's completely fucked up' 19:48:36 it's not exactly the first impression we want to give 19:48:41 rbergeron: we don't know it's hitting half of people 19:48:49 that's the problem here 19:48:50 i know ;) 19:48:52 right now it's hitting about half of a very small sample 19:49:02 adamw: with nvidia gfx... 19:49:15 if we make this a long meeting we could post a call for testing on test and forums 19:49:20 what i'm saying is that it potentially could be 19:49:22 well, personally, I would then look at common bugs, but I know many people won't 19:49:26 nvidia is around 1/3rd of all hardware, roughly. 19:49:41 adamw: yep, we have half of 1/3rd 19:49:50 adamw, it ś not the first time and certainly not the last some people experience unbootable alpha and reporters should read the release notes where removing rhgb is mentioned which is acceptable as a workaround 19:49:51 nirik: even if you look at common bugs and see the fix and apply it, there's still a 'what the hell were they thinking' hangover in your mind, i think. for some people anyhow. 19:50:06 perhaps... 19:50:10 Viking-Ice: yeah, these conditional bugs are always arguable both ways :/ 19:50:32 can i ask - is this the only thing that is a possible blocker or do we have other possible things to discuss 19:50:40 so - the options - go with it, or create rc4 with somehow fixed plymouth (the one from rc2) 19:50:40 there's one other EFI bug 19:50:46 * nirik is ok with document and not blocker based on what I know now. If we have more time for testing that would be great. 19:51:03 respinning with old plymouth is difficult, we'd actually have to do a new build with the old code but a higher NEVR 19:52:28 adamw: I'm aware of this... 19:54:03 we could also mentioned the rhgb workaround in the announcement to give users with nvidia a heads up 19:54:18 well, so the only doable option now is -1 blocker, +1 workaround but I understand your concerns 19:54:26 and ask them to report to that bug which card they are using if they hit this bug 19:54:46 Viking-Ice: it's actually what we want from Alpha - to collect data/bugs 19:54:56 Viking-Ice: yeah, i think we're going to want to take care with the announcement text for this one for sure 19:54:57 but first impression is always first impression 19:55:04 there's frankly quite a lot of big howling bugs we want to make sure people know about 19:55:38 we definitely want to call out the 'eats your disks without telling you' issue 19:55:46 anyhow, side alley 19:56:16 well, let's break this logjam somehow 19:56:19 it sounds like the majority want to vote -1 blocker 19:56:33 I vote -1 blocker 19:56:39 i want to vote -1 blocker 19:56:52 propose #agreed 848305 is rejected as a blocker on the basis that it only affects certain systems (so a conditional violation, so a judgment call) and appears to have a relatively simple and documentable workaround 19:57:04 ack 19:57:04 ack 19:57:05 adamw: ack 19:57:07 ack 19:57:11 ack 19:57:17 ack - that seems to be the consensus 19:57:21 i think tflink and i have reservations, but i'm okay to be stampeded by the mob :) 19:57:39 #agreed 848305 is rejected as a blocker on the basis that it only affects certain systems (so a conditional violation, so a judgment call) and appears to have a relatively simple and documentable workaround 19:57:51 * adamw makes sure to get his ass covered for posterity (see what i did there) 19:58:07 ack 19:58:12 * tflink does have reservations but realizes that the majority rules in this case 19:58:28 anyhow, on to the last proposed blocker 19:58:32 #topic (856938) Native UEFI install from F18 Alpha RC3 DVD written to USB with livecd-iso-to-disk fails to boot 19:58:35 #link https://bugzilla.redhat.com/show_bug.cgi?id=856938 19:58:38 #info Proposed Blockers, NEW 19:58:56 so, this is another lovely conditional one 19:59:32 we have two fails to boot an installed EFI system, three passes, and i think tflink couldn't yet get the installer to boot... 19:59:55 * tflink is trying again - used F16 litd for that test 19:59:56 as i mentioned in the bug, we've released alphas with those kinds of ratios before. we really wanted 18 to be more robust for efi, not less, but shit happens. 20:00:18 we still have time to make uefi robust for final... 20:00:30 yeah, I'm OK with the ratio, and it may help to narrow down the fail cases by casting a wider net. 20:00:37 so based on your last comment, I'm -1 blocker 20:00:54 im -1 blocker also 20:01:01 -1 blocker from me as well 20:01:05 no ideal but may help use get more data for beta 20:01:27 -1 blocker here too. 20:01:36 hold on a second, if we're -1 blocker on this - won't we have an alpha with no way to boot UEFI? 20:01:50 nvm, a bit slow 20:03:00 can we cite "shit happens" in the commonbugs? :) 20:03:20 take it for free. 20:03:24 how about "It's just Alpha, yo!" 20:05:09 it sounds like the majority is -1 blocker again 20:05:11 well, what are the current known ways how to boot with UEFI? 20:05:22 litd usb 20:05:40 dd == noworky, optical == noworky 20:06:01 * nirik wonders what litd actually means... 20:06:06 livecd-iso-to-disk 20:06:12 tflink: dd and optical of *live* images works 20:06:18 (for me, anyhow, and i think for bcl) 20:06:20 for EFI? 20:06:23 yes 20:06:30 because the lives don't have labels with spaces in 20:06:31 then I'm just confused 20:06:38 the live isos labels are correct. 20:06:41 so they don't hit that bug we discussed earlier 20:06:42 tflink: there were two issues 20:06:42 tflink: it's cited in https://bugzilla.redhat.com/show_bug.cgi?id=856938#c6 20:06:56 1) booting the installer in EFI mode. 2) rebooting the installed system in EFI mode 20:07:00 right. 20:07:07 this all is probibly worth a blog post of wiki page... "So you have this efi machine and you want to install/boot fedora 18 alpha on it, here's the methods that work... " 20:07:23 nirik: it'll go in the relnotes/commonbugs. and ideally in the announcement too. 20:07:28 yeah 20:08:00 tflink: you can boot the installer/live env via UEFI with: dvd/netinst written to USB with litd, or live image written with anything. in my testing, anyhow. 20:08:18 when i actually do a UEFI install with one of the methods where boot works, I can't boot the installed system - that's the bug we're on at present. 20:08:19 * jreznik takes the task to poke relnotes/commonbugs guys 20:08:24 but other testers *can* boot their installed systems. 20:08:30 jreznik: commonbugs guy is...usually me :) 20:08:47 adamw: ah, ok :) so /me will help adamw :) 20:10:01 proposed #agreed 856938 - RejectedBlocker - While this is a conditional violation of the F18 alpha release criterion, it was decided that the current success rates are enough for F18 alpha 20:10:03 adamw: based on ratio and what we already -1, it doesn't matter now... 20:10:22 proposed #agreed 856938 - RejectedBlocker - While this is a conditional violation of the F18 alpha release criteria, it was decided that the current success rates are enough for F18 alpha 20:10:35 * adamw plays spot the difference 20:10:42 criteria/criterion 20:10:53 ah. 20:10:54 * rbergeron waits for her blue ribbon 20:11:05 settle for blue cheese? 20:11:10 anyway, ack 20:11:10 ack 20:11:12 ack 20:11:14 ack 20:11:24 #agreed 856938 - RejectedBlocker - While this is a conditional violation of the F18 alpha release criteria, it was decided that the current success rates are enough for F18 alpha 20:11:32 well hey, all this prevarication gave us time to fill out the matrices... 20:11:40 OK, do we want to go over the accepted blockers that aren't VERIFIED? 20:12:41 sure. 20:12:44 eh, two of those are as good as VERIFIED - someone just needs to test it 20:12:48 * jreznik thinks we should 20:12:49 should be quick. 20:13:06 #topic (856399) RC2 DVD is missing grub2-efi and shim packages 20:13:06 #link https://bugzilla.redhat.com/show_bug.cgi?id=856399 20:13:06 #info Accepted Blockers, MODIFIED 20:13:22 fixed in RC3. 20:13:29 * adamw just loop mounted the RC3 DVD and checked. 20:13:46 #info This has been fixed in RC3 and will be moved to VERIFIED shortly 20:13:49 ok 20:13:56 #topic (856096) repoclosure failure on 18 Alpha RC2 DVDs (mongodb) 20:13:56 #link https://bugzilla.redhat.com/show_bug.cgi?id=856096 20:13:56 #info Accepted Blockers, ON_QA 20:13:58 since this is a comps change, nothing to push. 20:14:00 i just closed it. 20:14:03 verified the last bug. 20:14:05 er, that's for 856399. 20:14:37 robatino confirms fix 20:14:38 mongodb-2.0.7-1.fc18.x86_64.rpm is on the DVD 20:14:40 ah, this just needs to be closed - verified in c#3 20:14:45 robatino filed passes for repoclosure and fileconflicts for rc3 20:14:46 so this is fixed 20:14:51 #info this bug has been fixed, needs to be CLOSED 20:15:00 i'll do it 20:15:08 thanks 20:15:10 #topic (856836) /etc/fstab is not written correctly after live install (F18 Alpha RC2+) 20:15:12 oh, actually, we need to push the update to close it 20:15:13 #link https://bugzilla.redhat.com/show_bug.cgi?id=856836 20:15:15 but it's VERIFIED. 20:15:16 #info Accepted Blockers, ON_QA 20:15:21 #undo 20:15:21 Removing item from minutes: 20:15:22 #undo 20:15:22 Removing item from minutes: 20:15:24 #undo 20:15:24 Removing item from minutes: 20:15:25 #undo 20:15:25 Removing item from minutes: 20:15:31 please upkarma the update: https://admin.fedoraproject.org/updates/FEDORA-2012-12613/mongodb-2.0.7-1.fc18 20:15:57 #info this bug has been fixed, needs to be moved to VERIFIED. after enough karma, the update will be pushed to stable and this bug will be closed 20:16:08 #topic (856836) /etc/fstab is not written correctly after live install (F18 Alpha RC2+) 20:16:11 #link https://bugzilla.redhat.com/show_bug.cgi?id=856836 20:16:13 #info Accepted Blockers, ON_QA 20:16:20 jreznik: you said that you verified this? 20:16:34 adamw: it already has 3 karma 20:16:43 now it does. ;) 20:16:49 ah, it had 2 when i looked. :) 20:16:58 adam has verified 856836 20:16:59 yeah, i recall someone verifying this last night. 20:17:09 i verified it with the updates image 20:17:11 not, technically, with rc3 20:17:28 #info this is reported to be verified with RC3, move to VERIFIED once that is confirmed in bz 20:17:33 hey, i just did a live rc3 install, though, so i'll verify it right now. 20:17:35 *muzak* 20:18:17 verified! 20:18:35 #info this has just been verified with RC3 -> move to VERIFIED 20:18:52 OK, I think that's everything that could potentially block release 20:19:02 STICK A FORK IN IT 20:19:08 not quite yet 20:19:12 everything has either been fixed or rejected as a release blocking bug 20:19:15 we have to check the matrices 20:19:30 * tflink was referring to blocker bugs 20:19:56 Base is covered 20:19:58 i was saying to jlk :) 20:20:06 for desktop, we're covered for Shell and KDE 20:20:10 and I was clarifying what I meant about everything :) 20:20:20 we don't really care about fallback much any more since we have llvmpipe 20:20:21 #topic the test matrices results 20:20:27 #info Base is 100% 20:20:35 adamw: yep, fallback should be killed 20:20:48 #info Desktop has Alpha tests covered for GNOME and KDE (release blocking desktops). fallback isn't really considered critical since F17 20:20:55 so for Install 20:21:13 we're missing QA:Testcase_Anaconda_save_traceback_to_disk , which we can sub in from RC2 probably 20:21:35 need somebody to fill out that x86_64 live install worked 20:21:35 hmm, no, we don't have it for RC2 20:21:46 oh, I just did that. 20:21:58 hum, we don't have a recent traceback_to_disk result at all 20:22:04 can someone do that test quick? it shouldn't take long 20:22:14 adamw: anaconda doesn't support that anymore 20:22:15 yeah, I can do it 20:22:25 kparal: oh, really? only save to remote? in that case we can grey it out 20:22:32 * adamw checks criteria 20:22:32 adamw: only save to bugzilla 20:22:41 at least I haven't seen any other option 20:23:13 * adamw checks with #anaconda 20:23:22 the alpha criterion reads " The installer must be able to report failures to Bugzilla and local disk, with appropriate information included" 20:23:24 python-meh has been under heavy development, so yeah we might not have htat option anymore 20:23:25 we would have to adjust that 20:23:42 i'm fine with dropping the local disk requirement if it's not supported in the code any more 20:23:50 doesn't make any sense to require a function that doesn't exist 20:24:14 the idea was to allow for reports from people without network connections, but if the code's not there it's not there... 20:24:50 lemme see if i can check this quick 20:25:04 any possibility for this feature to come back one day for beta/final? 20:25:14 possible 20:25:22 * tflink is double checking now 20:26:00 does 'traceback' on the command line still work, anyone know? 20:26:11 adamw: not that I'm aware of 20:26:22 hrm, it hangs when I try to report the bug. awesome 20:26:22 ah, so i have to make it crash some other way 20:26:35 http://tflink.fedorapeople.org/updates/f18_traceback.img 20:26:39 custom partitioning, here we come! 20:27:29 hah. crashed it in 10 seconds. 20:27:38 yeah 20:27:39 yup, there's only a 'Report Bug' option. no other option. 20:27:42 just make an oversized disk 20:27:45 that's what i did :) 20:27:47 great minds... 20:27:52 lol 20:27:55 what?? I don't have 200T of space?? 20:27:58 128TB /foo partitipn 20:28:33 okay, so, i think the existing criterion wasn't really a reflection that we believe we *must* have save-to-disk functionality at alpha, but that since we had the code it should work 20:29:00 propose #agreed the criterion " The installer must be able to report failures to Bugzilla and local disk, with appropriate information included" should be amended to " The installer must be able to report failures to Bugzilla, with appropriate information included" as python-meh does not currently support saving crashes to disk 20:29:08 ack 20:29:08 or, we can just waive it for alpha, i guess. 20:29:13 if we think it's coming back. 20:29:35 ack 20:29:42 waive and report bug to make it coming back 20:29:54 on second thoughts i like that more. 20:30:12 I think it could be nice/handy. 20:30:22 but dunno how difficult it will be to re-implement 20:30:37 I thougth it was already in libreport 20:30:37 propose #agreed the 'local disk' requirement of criterion " The installer must be able to report failures to Bugzilla and local disk, with appropriate information included" is waived for F18 Alpha as the failure reporting tool does not currently have code for local disk reporting, and we do not think an Alpha release strictly requires this function 20:30:49 and it could definitely help anaconda team itself a lot... especially with broken network 20:30:50 ack 20:30:50 i suppose, if we don't really believe this is critical to alpha, we should adjust the criteiron anyway. 20:31:02 okay, i'll stop flip-flopping now. 20:31:03 ack 20:31:18 ack 20:32:01 anyone else? 20:32:11 we need acks :)! 20:32:29 ackity ackity 20:32:33 ack 20:32:39 i can do the fake moustache thing again 20:32:47 for this meeting we should write -1 blocker & ack bot 20:32:52 hehe 20:33:36 jlk: come one, you're an ack machine 20:33:47 didn't catch the second proposal. 20:33:49 ack 20:33:51 * kparal reading scrollback 20:34:05 ack 20:34:27 alrighty 20:34:32 #agreed the 'local disk' requirement of criterion " The installer must be able to report failures to Bugzilla and local disk, with appropriate information included" is waived for F18 Alpha as the failure reporting tool does not currently have code for local disk reporting, and we do not think an Alpha release strictly requires this function 20:34:35 okay, so moving 20:34:36 on 20:35:06 we're missing install_to_scsi device, but we haven't had that for several releases and we always decide not to care about it, so screw that. 20:35:15 i should really just make that an optional test. 20:35:22 it should probably be removed from the matrices 20:35:37 but that detail is a discussion for another day, methinks 20:35:45 we don't have a liveusb-creatore result, but we don't need one for alpha, as we know one usb method works and that's all we require 20:35:58 tflink: 'optional' are the tests in the matrices but with no release level associated, i think that'd be fine for it 20:35:59 tflink: +1 to remove, scsi is... 20:36:32 we're missing some of the 'autopart' test cases, but in practice we've covered newUI functionality sufficiently 20:36:43 those test cases are written to oldUI and don't really properly apply to newUI 20:36:45 so that's okay 20:36:52 the testing we've done covers the criteria 20:37:07 and that's all i see 20:38:09 #info missing Install tests are install_to_SCSI which has been waived for several releases, traceback_to_disk which was waived above, and non-EFI liveusb-creator which is OK as we only need *one* working USB method for alpha, and we have more than one already 20:38:21 #info per above, Install matrix is functionally complete 20:38:34 * dgilmore votes go 20:38:44 lets ship it already. :) 20:38:52 Viking-Ice: tflink: are we in agreement that QA's vote is go, per our procedure? 20:38:53 #topic go/no-go decision 20:39:06 Go 20:39:28 per procedure, yes I'd say QA is go 20:39:37 #info rel-eng votes Go (dgilmore) 20:39:39 Releng is go 20:39:41 yup 20:39:44 #info devel votes Go (jlk) 20:39:52 #info QA votes Go (tflink, viking, adam) 20:39:56 infra is go 20:40:12 #info infra is go (dgilmore) 20:40:13 per the procedure i think dev, releng, qa, program manager and fpl get votes. 20:40:16 i say ship it :) 20:40:19 * jreznik is go 20:40:26 #info FPL votes go (rbergeron) 20:40:39 #info program manager votes go (jreznik) 20:40:43 so...i think we're go :) 20:40:48 * nirik cheers 20:40:49 :) 20:41:03 drunk in T minus 5... 4.... 20:41:27 golfing in t-minus... 20:41:30 jlk: i dont think my date would appreciate me turning up drunk 20:41:31 woeiewewew :) it's my feeling right now 20:41:31 * rbergeron will point out that that puts GA the tuesday after thanksgiving - so go/no-go would be on turkey day here in the states (not hta twe are the center of the universe) 20:41:41 (assuming we slip no more) 20:41:48 rbergeron: ahahahahahahahahahaahahahahahahahaha 20:41:49 hahaha 20:41:49 rbergeron: i believe its the tuesday of thanksgiving week 20:41:55 ahahahahahahahahahahahaha *breathes* 20:41:56 * Viking-Ice raises his mead bottle! 20:42:04 slip no more. good one. heh. 20:42:21 rbergeron: we just have the non-US people handle the meeting 20:42:28 for our us friends, /me notes we have to slip :) 20:42:52 jlk: hey, go/no-go in reasonable time, would be nice :) 20:42:55 thanksgiving is 22nd, GA right now is .. 27th, yes? 20:43:06 rbergeron: ga is 27 now 20:43:31 rbergeron: opps i thought it was the 29th 20:43:48 okay. so jus tputting that out there. ;) like i said, that assumes no more slippage 20:44:09 rbergeron: i dont get thanksgiving this year it seems 20:44:19 * dgilmore will be in .au all of november 20:44:47 okay, let's get everyone to golf and beer and bed from this meeting :) 20:45:13 rbergeron: yeah, anett is waiting for me already :) 20:45:19 so thank you all 20:45:24 might jreznik 20:45:26 night 20:45:33 thanks for all the hard work everyone. 20:45:35 who made it possible to ship alpha! 20:45:55 and now 20:45:57 3 20:46:11 dgilmore: :) 20:46:16 2 20:46:42 (and action for me) 20:46:55 #action jreznik to announce go/no-go result 20:47:02 1 20:47:33 GO 20:47:38 #endmeeting