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