21:00:12 <rbergeron> #startmeeting F16 Final Go or No Go Meeting
21:00:12 <zodbot> Meeting started Wed Nov  2 21:00:12 2011 UTC.  The chair is rbergeron. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
21:00:21 <rbergeron> #meetingname F16 Final Go or No Go Meeting
21:00:21 <zodbot> The meeting name has been set to 'f16_final_go_or_no_go_meeting'
21:00:29 <rbergeron> #chair tflink adamw dgilmore
21:00:29 <zodbot> Current chairs: adamw dgilmore rbergeron tflink
21:00:31 <adamw> yo
21:00:37 <dgilmore> hola
21:00:42 <rbergeron> #topic Gathering the awesome
21:00:46 * nirik is here
21:00:53 * rbergeron gives a moment or two to get everyone in the room
21:00:57 <adamw> holla
21:01:02 * dgilmore hopes to take adamw's whip away from him
21:01:32 * tflink is here but will have to leave early
21:01:36 <rbergeron> #topic Why are we here
21:01:39 <thedonvaughn> present
21:01:51 * pschindl is here
21:01:51 * cwickert is not awesome but will lurk anyway
21:01:53 <rbergeron> #link https://fedoraproject.org/wiki/Fedora_16_Final_Release_Criteria
21:01:57 <rbergeron> cwickert: sure you are :)
21:02:07 <cwickert> rbergeron: only with the hotdog costume ;)
21:02:30 <rbergeron> #info Dearly Beloved: We are gathered here today to see whether or not F16 meets the final release criteria, bugs are closed, blockers are gone, matrices are filled, testing is done, etc.
21:02:44 <rbergeron> (bottles are empty, livers are well-tuned, etc)
21:02:50 <rbergeron> AHEM.
21:03:06 <rbergeron> with that: let's take a look at blockers.
21:03:12 <rbergeron> #topic Blocker Bugz
21:03:16 <rbergeron> #link https://fedoraproject.org/wiki/Current_Release_Blockers
21:03:31 <rbergeron> adamw or tflink: want to take us through these proposed blockers
21:03:38 <rbergeron> #chair adamw tflink dgilmore
21:03:38 <zodbot> Current chairs: adamw dgilmore rbergeron tflink
21:03:58 <adamw> yo
21:04:05 <rbergeron> yo baby yo
21:04:34 <adamw> *muzak*
21:04:45 <adamw> starting with the easy one
21:04:47 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=750228
21:04:58 <adamw> this is basically fixed, dgilmore figured out whatever he had to wiggle to make efidisk.img work
21:05:06 <rbergeron> woo
21:05:10 <adamw> so we may as well close it or something. rc3 and rc4 both had working efidisks.
21:05:13 <rbergeron> is it a wiggle or a fix?
21:05:17 * dgilmore proposed killing it in fire for f17
21:05:20 <adamw> is there a difference? THIS IS FEDORA
21:05:26 <rbergeron> mmhmmm
21:05:31 <adamw> yeah, efidisk.img is essentially pointless anyway.
21:05:37 <adamw> so, yeah, moving on.
21:05:39 <dgilmore> rbergeron: its a timing issue
21:05:43 <rbergeron> #info 750228 is basically fixed
21:05:49 <adamw> we have two which are...not so simple.
21:05:51 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=750469
21:06:03 * j_dulaney is here
21:06:07 <j_dulaney> if a tad late
21:06:24 <adamw> i've written a rather lengthy explanation of the state of the art on this bug in https://bugzilla.redhat.com/show_bug.cgi?id=750469#c25
21:07:08 <adamw> the only thing missing there is what actually happens: if you install f15, then write an f16 dvd/netinst image to USB with livecd-iso-to-disk and try to upgrade to f16, it will want to install the bootloader to the USB stick you're running the installer from, and you will be unable to persuade it to install it to the MBR of the actual hard disk.
21:07:28 <adamw> you can make it install to the /boot or root partition, but there's no way to make it install to the MBR of the hard disk, which is almost certainly what you want to do.
21:07:37 <thedonvaughn> hrm which is serious since we're forcing upgrades to grub2?
21:07:40 <adamw> yes.
21:07:49 <thedonvaughn> hrm
21:08:01 <adamw> as mentioned in my Giant Novel, this bug has existed more or less forever but was mostly masked in f15, you just weren't likely to actually experience it as a major problem
21:08:35 <adamw> this is the bug red_alert was having in the Emergency Meeting yesterday, unfortunately we didn't quite  hit on the vital bit of info that he was booting from a USB stick until later.
21:08:44 <thedonvaughn> yah i'm reading that novel right now :)
21:09:31 <adamw> mgm has optioned the movie rights
21:09:36 <rbergeron> so in short: the fix he's working on is the only possible fix
21:09:45 <rbergeron> and he's implemented a small portion of it, and it's buggy?
21:10:02 <rbergeron> ...which means a fix that is not buggy in the next day or so is probably unlikely?
21:10:04 <adamw> well, no, what was implemented should have been enough to go with for release. cept it doesn't seem to work.
21:10:10 <rbergeron> ah
21:10:25 <dgilmore> adamw: i think its a blocker
21:10:42 <adamw> dgilmore: yeah, that's my inclination too, unfortunately
21:10:59 <adamw> couple of years ago we could likely have got away with it on the basis that it only affects usb, but everyone and their dog seems to write the images to usb these days
21:11:03 <rbergeron> and mine
21:11:07 <adamw> if i had to guess, i'd guess more people do that than write to dvd
21:11:14 * j_dulaney has not hit this with liveusb-creator
21:11:24 <dgilmore> adamw: i only resort to dvd media when i have to, prefering network or usb, i think alot of people will use usb to update
21:11:27 <dgilmore> and will hit this
21:11:28 <adamw> j_dulaney: we hadn't tested liveusb-creator yet
21:11:37 <adamw> j_dulaney: i'll do that next
21:11:49 <nirik> ugh
21:12:00 <rbergeron> nirik: mmhmm
21:12:08 <dgilmore> adamw: i usually use dd to write the image though
21:12:11 <satellit_> adamw: see this https://bugzilla.redhat.com/show_bug.cgi?id=750896#c8
21:12:13 <j_dulaney> adamw:  I used liveusb-creator in testing RC3
21:12:13 <adamw> we're not just working on theory here, fwiw, red_alert can reproduce it reliably and so can i, now i know how to hit it.
21:13:18 <rbergeron> okay.
21:13:28 <rbergeron> Soooooooooooo: we're not expecting a fix in hours, correct?
21:13:41 <nirik> fix will need new anaconda I suppose?
21:13:41 <adamw> it's possible that we might get one.
21:13:46 <thedonvaughn> perhaps provide a kickstart file ?
21:13:51 <adamw> yeah, fix would most likely be to anaconda.
21:13:53 <thedonvaughn> oh wait, you'd have to know the device before hand then
21:14:16 <adamw> thedonvaughn: we can't really go with any kind of workaround for this because the impact's just too nasty: you do an upgrade then wonder why your system doesn't boot right
21:14:23 <rbergeron> okay. so, let's talk about second bug, so we can weigh the full scope of things
21:14:23 <adamw> it's easy to miss what actually went wrong\
21:14:25 <thedonvaughn> aye
21:14:31 <adamw> we really ought to fix it properly
21:14:34 * nirik is sadly +1 blocker
21:14:40 <thedonvaughn> yah it's a blocker
21:14:43 <dgilmore> forcing resuce mode after upgrade to fix things is not ok
21:15:08 <adamw> whether the resulting configuration boots is likely something of a crapshoot but i doubt it often would
21:15:16 <adamw> didn't for red_alert
21:15:34 <adamw> so, seems like we're agreed this one's a blocker
21:15:34 <thedonvaughn> wait doesn't anaconda ask you which block device to use to install to mbr?  (having a brain fart)
21:15:45 <rbergeron> adamw: yes
21:15:47 <adamw> thedonvaughn: see the novel
21:16:13 <adamw> #agreed 750469 is a blocker: writing the dvd/netinst to USB is a common method of installing, and the impact of this is severe, it likely results in non-bootable systems in most cases
21:16:18 <thedonvaughn> adamw: ah i see.
21:16:18 <dgilmore> adamw: yeah its a blocker
21:16:21 <thedonvaughn> ok
21:16:41 <adamw> okay, onto the other fun
21:17:21 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=750896
21:17:28 <adamw> so this one is quite new, kparal just found it today
21:17:43 <adamw> i haven't got around to reproducing it myself yet, but i trust his diagnosis
21:18:08 <adamw> it seems that anaconda writes NM config files for every wireless AP it sees, if you bring up the network during install (so, net install, or DVD install with updates enabled, etc)
21:18:31 <adamw> this means that, when you boot the installed system, it'll happily jump onto any one of those APs if it's unsecured
21:18:32 <thedonvaughn> it's marking all found APs as 'known'.  interesting.
21:18:46 <adamw> which...doesn't seem like a thing we want our OS to do.
21:18:52 <nirik> yeah, less than ideal...
21:18:54 <rbergeron> but, but, EVERYONE KNOWS ME
21:18:59 <thedonvaughn> yup.  not good
21:19:04 <adamw> this is new.
21:19:08 <adamw> f15 didn't do it.
21:19:23 <adamw> the guilty commit is noted in comment #6
21:19:38 <tflink> interestingly enough, it doesn't appear to add other APs if you select one
21:19:45 * tflink just finished an install
21:19:56 <adamw> unfortunately it's part of a big set of changes to networking behaviour in anaconda in f16 so we can't really just revert it and hope for the best
21:20:18 <dgilmore> adamw: so it seems wrong
21:20:20 <adamw> the person who was in charge of all those changes is part of the RH brno office (that's in the czech republic, for non-RHers) so is out of office hours now
21:20:26 <dgilmore> its not ideal at all
21:20:37 <adamw> dgilmore: yeah, but the fix might be more  complex than just 'don't do that, then'.
21:20:53 <dgilmore> adamw: yeah i suspect that the fix will be invasive
21:21:13 * nirik would be ok calling it NTH... and punting if it's too invasive a fix.
21:21:14 <dgilmore> adamw: i dont think we have any criteria for this right?
21:21:18 <adamw> and apparently none of the anaconda team who's around right now really know the NM code terribly well.
21:21:42 <adamw> dgilmore: indeed. we've punted the idea of security criteria before, but it seemed like a nightmare to encode.
21:22:11 <rbergeron> nirik: yes
21:22:16 <adamw> tflink: so this is most likely to happen if you install via wired network but have a wireless adapter?
21:22:23 <adamw> tflink: if you actually installed via wireless you'd probably be okay?
21:22:32 <adamw> hey bcl
21:22:38 <thedonvaughn> ya know, now that I think about it tflink is right.  I installed RC2 on my laptop and chose an AP.  it only created _one_ ifcfg entry which was annoying because when it was installed it didn't let network-manager control it
21:22:44 <adamw> so far we accepted the usb upgrade issue as a blocker and we're kicking around the network issue now
21:22:48 <thedonvaughn> i had to remove the ifcfg entry to get NM to take over
21:22:48 <tflink> I just did a wireless install and the non-secured AP around me does not exit in sysconfig/network-scripts
21:23:04 <dgilmore> adamw: right. so its reallya  judgement thing. adamw if the code changes are too invasive it might be simpler to remove the configs it wrote out at the end
21:23:07 <adamw> tflink: can you re-install without picking any AP?
21:23:18 <dgilmore> it would mean the connection you used for install is not there
21:23:24 <thedonvaughn> I also can install to test when I get home from the office on my dev laptop
21:23:29 <dgilmore> but security wise would be better
21:23:31 <nirik> tflink: /etc/NetworkManager/system-connections/ ?
21:23:32 <adamw> dgilmore: yeah, for e.g. we'd really probably want the person who wrote the code to bash heads with dcbw and figure out what's supposed to happen.
21:23:42 <dgilmore> adamw: yeah
21:24:06 <dgilmore> adamw: my gut tells me we should block
21:24:17 <dgilmore> i can see users blasting us afterwards
21:24:23 <tflink> nirik: there's nothing in there
21:24:29 <nirik> ok
21:24:31 <adamw> it does feel a bit sticky to me, yeah.
21:24:32 <jdulaney> What did I miss?
21:24:43 <adamw> jdulaney: the clowns!
21:25:03 <jdulaney> LOL
21:25:09 <adamw> not a lot.
21:25:30 <tflink> I just have a ifcfg-<routername> in /etc/sysconfig/network-scripts/ for the AP I used during install
21:25:30 <rbergeron> okay, soooo
21:25:43 <rbergeron> blocker or NTH? nirik proposed nth earlier
21:25:58 * dgilmore is +1 blocker
21:26:07 <thedonvaughn> tflink: yup exactly.  that's what i had too
21:26:08 <nirik> so it's only when you cancel joining a wireless net?
21:26:28 * j_dulaney is also +1 blocker
21:26:28 <dgilmore> maybe we dont have enough info here?
21:26:42 <kparal1> I tried only cancelling. but I believe it behaves the same even if you don't cancel during installation
21:26:51 <adamw> hey kparal
21:27:02 * kparal1 just joined
21:27:09 <adamw> tflink's been working on reproducing
21:27:20 <tflink> kparal1: I'm not seeing that here
21:27:31 <nirik> so, yeah, it seems like we need more info/reproducers...
21:27:56 <adamw> yeah, we probably need to figure out precisely what you have to do to hit it
21:27:56 <bcl> If it is as kparal1 says, then I'm +1 blocker. lots of folks have untrusted APs surrounding them.
21:28:01 <thedonvaughn> that line self.anaconda.network.writeSSIDifcfgs(dev_ssids) <- which was the new commit seems to only write on ifcfg if i'm reading hte code right.  dev_ssids is an object returned from selectSSIDsDialog, so it should be the AP that the user choose
21:28:16 <N1tr0g3n> Cant you just turn off the Wi Fi modem at that time?
21:28:25 <thedonvaughn> confused how it's writing out all _all_ APs to a ifcfg- script
21:28:25 <N1tr0g3n> sorry if i sound stupid
21:28:34 <adamw> N1tr0g3n: if you know about the bug, sure
21:28:34 <bcl> adamw: the thread you found might not be the final, I seem to remember him going through several revisions.
21:28:34 <thedonvaughn> er "seems to only write one ifcfg"
21:28:34 <adamw> N1tr0g3n: the problem is if you don't
21:28:38 <adamw> bcl: afaics it matches up.
21:28:55 <thedonvaughn> ii'm +1 blocker
21:29:03 <adamw> the other stuff might have been revised, but that line was committed the same day of that email
21:29:07 <nirik> proposal: gather more info, vote in bug.
21:29:14 <adamw> nirik: seems reasonable
21:29:21 <rbergeron> yeah.
21:29:32 <thedonvaughn> i can do some heavy testing on that bug when i get home.  i want to review the anaconda code closer too
21:29:39 <adamw> thedonvaughn: that'd be a help, thanks
21:29:41 * thedonvaughn will update the ticket if i find anything
21:29:52 * rbergeron is waiting for somoene to propose having the second half of this meeting in the early morning when we have brno help and more info in this bug
21:30:00 <rbergeron> and maybe a fix for the other bug
21:30:19 <rbergeron> Or we call it a week, now.
21:30:25 <nirik> superhuman effort part 2?
21:30:36 <rbergeron> nirik: i hate making this be an option every time.
21:30:45 <nirik> yeah
21:30:57 <adamw> #agreed need more info on precisely how to hit 750896, will gather more tests and vote async in comments
21:31:00 <j_dulaney> Indeed
21:31:05 <adamw> #topic slip or no slip?
21:31:13 <j_dulaney> +1 slip
21:31:14 <nb> Could we get an AcceptedNTH for 750938?  It's updating fedora-release-notes to fedora-release-notes-16.1.0-1, which adds translations.  It's a low-risk change, using the same build process as always, just that translations weren't ready in time to be tagged in yet.  jjmcd just built it yesterday, it already has +3 karma and is submitted for stable by autokarma.
21:31:24 <nb> .bug 750938
21:31:26 <zodbot> nb: Bug 750938 Update fedora-release-notes to include translations - fedora-release-notes-16.1.0-1 - https://bugzilla.redhat.com/show_bug.cgi?id=750938
21:31:29 <nb> (that is, if we slip)
21:31:29 <adamw> yeah, i would dearly hate for anyone to assume the amount of crazy work qa and dev teams are putting in for this cycle to be normal or repeatable
21:31:45 <adamw> nb: i actually meant to ask dgilmore to sneak that into rc4 and forgot
21:31:49 <adamw> nb: we'll sneak it into rc5, sure
21:31:52 * j_dulaney isn't pulling another all nighter testing
21:31:54 <j_dulaney> Sorry
21:31:58 <nb> adamw, i'll mark it AcceptedNTH
21:32:15 <N1tr0g3n> nb F16 will released with this bug?
21:32:21 * nb was not sure if it needed formal votes or not
21:32:21 <N1tr0g3n> Then eventually fixed?
21:32:29 <adamw> my plan to half-ass the upgrade bug kinda hinged on it being an easy fix that affected only upgrade codepaths
21:32:35 <adamw> nb: it should get votes, but...feh.
21:32:46 <adamw> i was going to just get rc5 spun and then re-do only the upgrade tests
21:32:52 <j_dulaney> I'll say +1 NTH
21:32:54 <j_dulaney> There
21:32:58 <adamw> that's 3!
21:33:07 * nirik is fine with NTH on that...
21:33:09 <adamw> #agreed 750938 is acceptednth, updated release notes are good
21:33:11 <dgilmore> adamw: if we can get anaconda fixed today ill do RC5 tonight
21:33:15 <adamw> dgilmore: k
21:33:17 <rbergeron> +1, NTH :)
21:33:26 <nirik> there was mention of https://bugzilla.redhat.com/show_bug.cgi?id=744717 over in #fedora-devel...
21:33:30 <dgilmore> adamw: really we only need to do the install media
21:33:34 <rbergeron> dgilmore, adamw: does that mean second half of this meeting would be tomorrow?
21:33:46 <adamw> dgilmore: nah, we should do everything, we can't ship install media and live media with different anaconda builds.
21:33:47 <dgilmore> but to keep things sane we should redo all lives as well i guess
21:34:20 <N1tr0g3n> its abnormal to delay release of F16 again?
21:34:28 <N1tr0g3n> For the WiFi/anaconda bug
21:34:30 <j_dulaney> rbergeron:  I'm for slipping
21:34:34 <nirik> N1tr0g3n: delays happen.
21:34:41 <N1tr0g3n> nirik i know :)
21:34:54 <adamw> we've been trying very hard to stay on schedule
21:34:56 * rbergeron looks at adamw, dgilmore for opinions on day vs. week
21:35:02 <N1tr0g3n> is it possible to use a little older anaconda t oavoid problems?
21:35:03 <adamw> it's still vaguely possible but may cause explosions.
21:35:04 <j_dulaney> We can't make what happened last time the norm
21:35:06 <adamw> N1tr0g3n: no.
21:35:14 <dgilmore> rbergeron: if we can id rather evaluate where we are tomorrow
21:35:18 <rbergeron> j_dulaney: yep.
21:35:20 <dgilmore> id prefer to not slip a week
21:35:24 <thedonvaughn> I vote day
21:35:44 <adamw> nirik: that one doesn't look worrying to me, looks like you need an odd grub.cfg to hit it. well, it kinda sucks for the xen case, i guess. but it's fixable with an update anyway.
21:35:54 * nirik nods.
21:36:11 <adamw> i'm okay with delay decision till just before release readiness, but...no promises.
21:36:25 <adamw> we still don't actually have an anaconda fix, we're not sure about the wireless bug, and i dunno how much re-testing we'll need.
21:36:34 <tflink> nirik: yeah, I've been running grub2-mkconfig @ every kernel change on my xen box
21:36:37 <rbergeron> if we don't know by RR tomorrow, we need to cut it a week.
21:36:43 <adamw> and i don't know how long i'm going to manage to stay awake tonight...
21:37:18 <dgilmore> adamw: i suggest you go sleep after the meeting :)
21:37:21 <j_dulaney> I have a calculus exam tomorrow, I'm not staying awake late
21:37:26 <nirik> well, probibly sleeping until morning in brno might be fine... since it sounds like not too much can be done until they look at anaconda.
21:37:29 <dgilmore> adamw: i can work with anaconda folks
21:37:40 <adamw> i can't sleep afternoons
21:38:03 <adamw> nirik: we don't need brno for the upgrade bug, and we need more testing on the wireless bug.
21:38:14 <nirik> anyhow, I am fine with working on these 2 and checking tomorrow where we are.
21:38:19 <dgilmore> adamw: if we can get a fix for the grub issue but not the wireless one id go with that. im still a bit torn on the wireless issue. i kinda think we need a bit more data on it
21:38:19 <rbergeron> okay, so: 11am pacific tomorrow?
21:38:33 <adamw> anyways. yeah. wait for tomorrow is okay, as long as everyone understands this cycle is utterly fucked from a process pov and we're not doing this crap for f17
21:38:42 <N1tr0g3n> Has anyone installed F17 Rawhide?
21:38:42 <rbergeron> RR is at noon.
21:38:46 <tflink> +1 to what adamw said
21:38:59 <rbergeron> adamw: yup. once you fudge once :)
21:39:02 <dgilmore> N1tr0g3n: we dont make rawhide install media
21:39:04 <nirik> adamw: indeed.
21:39:13 <N1tr0g3n> dgilmore i didnt use install mdeia
21:39:29 <j_dulaney> rbergeron:  That's why I'm -1 on doing anything tomorrow
21:39:29 <thedonvaughn> this is my first cycle, so good to know :)d
21:39:29 <dgilmore> N1tr0g3n: regardless its off topic for this meeting
21:39:39 <N1tr0g3n> i installed the repo (fedora-release-rawhide) and did an update
21:39:59 <adamw> j_dulaney: toe that line! :)
21:40:02 <dgilmore> N1tr0g3n: please take your question to #fedora-devel
21:40:03 <adamw> someone's gotta
21:40:09 <N1tr0g3n> I wanted to know if the anaconda bug works on F17
21:40:12 <rbergeron> j_dulaney: feel free to propose. seriously, i'm not interested in killing people here - if you guys are worn/torn, then let's not push it.
21:40:14 <nirik> kudos to all of qa and release-engineering this cycle for lots of long nights and hard work.
21:40:15 <N1tr0g3n> or only F16?
21:40:22 <rbergeron> it's not worth burning poeple out over.
21:40:30 <j_dulaney> Ok, I propose we slip a week
21:40:39 <dgilmore> N1tr0g3n: elsewhere
21:40:39 <thedonvaughn> I admit i haven't been as busy with qa - been busy month at work.  if people are bruned out, le'ts just slip a week
21:40:42 <nb> N1tr0g3n, not here
21:40:48 <thedonvaughn> i'm fine personally, but i can tell most need a break
21:41:00 <j_dulaney> That way, we get a) don't get crappy bodged semi fixes and b) get proper testing of fixes
21:41:07 <adamw> the problem with slipping a week is it just drags out the burn =)
21:41:12 <rbergeron> adamw: ;)
21:41:14 <thedonvaughn> I think it's more important to fix and test properly than to rush
21:41:17 <dgilmore> adamw: indeed
21:41:18 <thedonvaughn> adamw: hah
21:41:31 <adamw> thedonvaughn: we haven't actually screwed up any of the fixes so far
21:41:33 <nirik> thedonvaughn: yeah, but then new bugs show up, lather rinse, repeat. ;)
21:41:40 <adamw> all the bugs have been newly-discovered stuff, not regressions
21:41:43 <thedonvaughn> adamw: that's not what I'm saying
21:41:44 <HeavenSmile> 1 + on slipping a week
21:41:46 <nirik> yeah, all our fixes have been kosher.
21:41:47 <adamw> anyhoo
21:42:32 <adamw> the berge? i think you're driving?
21:42:41 <rbergeron> yeah.
21:42:43 <rbergeron> I'm thinking.
21:42:53 <thedonvaughn> either way, i'll be testing tonight :)
21:42:55 * nirik is still fine with reevaluating tomorrow.
21:43:12 <nirik> if it turns out we aren't all tested by then, then slipping a week is a no brainer.
21:43:13 <rbergeron> i am too, as fine as I can be with it, given how rule-breaking it is.
21:43:15 <dgilmore> adamw: at least if its only anaconda i dont need to redo ec2
21:43:17 <j_dulaney> Remember, last time we stated we wouldn't EVER do it again?
21:43:43 * j_dulaney could pull up the relevent logs
21:43:50 <rbergeron> j_dulaney: i remember.
21:44:07 * nirik shrugs. I think we don't want to make it common... but in the past we haven't been bitten by so many last minute blockers.
21:44:23 <nirik> I think we are also being much better at testing and are finding stuff that we would have missed long ago.
21:44:32 <rbergeron> nirik: yup.
21:44:32 <N1tr0g3n> Is it going to be a final go or no go meeting tommorow
21:44:33 <N1tr0g3n> ?
21:44:51 <adamw> nirik: mostly, we're getting bitten in the ass by grub2. that's essentially what the cycle boils down to.
21:44:59 <adamw> N1tr0g3n: this is supposed to be that meeting
21:45:01 <dgilmore> if we go by the letter of our rules, we slip 1 week
21:45:03 <rbergeron> adamw: how's your soul?
21:45:03 <nirik> yeah, it's a big nasty change.
21:45:06 <adamw> N1tr0g3n: we're really supposed to make the call right now and stick to it
21:45:06 <dgilmore> not all blockers are fixed
21:45:09 <nirik> good thing btrfs didn't land. :)
21:45:18 <thedonvaughn> just think how smooth f17 will go *knocks on wood*
21:45:20 <thedonvaughn> :)
21:45:23 <adamw> N1tr0g3n: tomorrow is the 'release readiness' meeting which is more about making sure all teams are ready for the release - docs and so on
21:45:37 <adamw> thedonvaughn: yeah, with a complete anaconda UI rewrite, it'll be plain sailing!
21:45:46 <N1tr0g3n> Ok, understood
21:45:53 <rbergeron> nirik: hardyharrhar
21:45:54 <adamw> N1tr0g3n: we are, however, probably going to half-ass things and delay the decision until just before the RR meeting tomorrow
21:45:59 <nirik> I think it comes down to rel-eng qa's call... if they are willing to pull a massive effort again, great. if they don't want to, also fine, we slip a week now.
21:46:03 <j_dulaney> Oy, forgot about the Anaconda rewrite
21:46:16 <N1tr0g3n> But as long as we have blockers yet we aren't quite ready for release right?
21:46:26 <rbergeron> N1tr0g3n: yup.
21:46:33 <nirik> we are definitely not 'go' right now.
21:46:36 <adamw> yes, as dgilmore says, by the letter of the policy, we should slip as there are unaddressed blockers.
21:46:48 <N1tr0g3n> slip==delay?
21:46:52 <j_dulaney> Indeed
21:46:54 <nb> N1tr0g3n, yes
21:46:58 <adamw> i personally am okay with fudging it again but then i just want to get this damn thing done, so i don't particularly trust my judgement right now.
21:47:47 <rbergeron> dgilmore? you're also on the hook for more no sleepy here.
21:47:55 <N1tr0g3n> Must Anaconda scan for Wi Fi?
21:47:59 <dgilmore> rbergeron: im down
21:48:00 <N1tr0g3n> Cant it do that later?
21:48:14 <rbergeron> okay. then:
21:48:15 <red_alert> I think rushing this is dangerous - like the bootloader-goes-to-usbstick used to be fixed a few days ago but isn't as of today...that's the difference between 24h of testing and 1 week ;)
21:48:18 <j_dulaney> If it does get fudged, I'm apologizing in advance for not doing any testing.  Calculus exam tomorrow has priority
21:48:29 <adamw> red_alert: afaict it was never fixed.
21:48:42 <red_alert> adamw: we thought it fixed, though, afaik
21:48:47 <thedonvaughn> seems like it wasn't.  it's just hitting us hard this release becaue of grub -> grub2 upgrade
21:48:54 <thedonvaughn> it was always installing mbr to usb
21:48:57 <rbergeron> adamw: it was fixed for installs, not upgrades, right?
21:49:03 <adamw> rbergeron: that's basically it
21:49:13 <N1tr0g3n> We should warn users to unplug USB devices
21:49:13 <adamw> the test cases we had in the big bug from beta were all install paths
21:49:28 <N1tr0g3n> External HDDs usb sticks etc.
21:49:40 <rbergeron> N1tr0g3n: that doesn't work when you're installing or upgrading from the USB device
21:49:41 <nirik> N1tr0g3n: doesn't work so well if they are using it to boot off of and run the upgrader.
21:49:44 <adamw> they got fixed by trying harder to honor the bootloader target chosen at the diskssel screen, and showing the diskssel screen in the custom install path
21:50:04 <adamw> also, the 'broken' filtering code isn't broken on live boots
21:50:33 <adamw> so, basically, because we were fixing three different bugs that caused ten different problems all at once, we never quite figured that the filtering code for non-live boots wasn't working, and that that caused issues with upgrades.
21:50:58 <dgilmore> adamw: right, that really has to be fixed
21:50:58 * rbergeron nods
21:51:04 <j_dulaney> Indeed
21:51:07 <dgilmore> id prefer the wireless issue fixed
21:51:13 <N1tr0g3n> me too
21:51:20 <j_dulaney> That's also a must
21:51:21 <N1tr0g3n> Security first!
21:51:22 <adamw> okay
21:51:33 <adamw> bcl is pretty confident that the wireless issue happens only if you cancel or close the dialog
21:51:58 <N1tr0g3n> What options do you have on that dialog?
21:52:03 <N1tr0g3n> Any screenshots of it?
21:52:12 <kparal1> the dialogs asks you for wifi to connect
21:52:14 <dgilmore> adamw: ok, i think that we could add something there to make sure they are removed.
21:52:16 <kparal1> there is a combobox
21:52:22 <kparal1> of all available wifis
21:52:27 <adamw> dgilmore: bcl thinks he knows what to do, so we'll work on that.
21:52:30 <N1tr0g3n> Cant you select none?
21:52:32 <kparal1> you can select one and OK, or Cancel
21:52:33 <dgilmore> adamw: do we have anyone on the anaconda team to get us a new build
21:52:33 <adamw> anyhow, we seem to be going in circles
21:52:39 <adamw> yeah, builds aren't a problem.
21:52:42 <N1tr0g3n> Or selecting none=cancel which causes issue
21:52:43 <N1tr0g3n> ?
21:52:56 <dgilmore> adamw: rather than doing test composes id like to just have me do a rc5
21:52:59 <kparal1> I think you can't select "none"
21:53:02 <bcl> dgilmore: I have the powerish
21:53:06 <adamw> dgilmore: yeah, we can short-circuit that
21:53:09 <dgilmore> bcl: you rock
21:53:23 <bcl> nah. I just get volunteered alot :)
21:53:24 <adamw> we can just test with updates.img then go straight to compose
21:53:29 <dgilmore> bcl: can we make magic happen?
21:53:36 <dgilmore> yep
21:53:58 <bcl> we cna try
21:54:05 <bcl> even if I can't type
21:54:19 <j_dulaney> Explains a lot of bugs
21:54:20 * nirik sees a new proposed blocker: 748241 which seems not blocker to me.
21:54:34 <j_dulaney> .bug 748241
21:54:36 <zodbot> j_dulaney: Bug 748241 gnome-shell uses excessive CPU after resume - https://bugzilla.redhat.com/show_bug.cgi?id=748241
21:55:03 <j_dulaney> -1 blocker
21:55:07 <jjmcd> Doesn't actually take suspend/resume ... only takes time, and after a while the pc isunuseable
21:55:46 <jjmcd> Although, it seems like not everyone experiences it, so I dont know how common it is
21:55:52 <nirik> can be fixed in an update... doesn't hit any criteria...
21:56:00 <j_dulaney> Indeed
21:56:04 <rbergeron> nirik: yup, no criteria
21:56:04 <j_dulaney> Hence -1
21:56:08 <thedonvaughn> strange.  i never have that issue on either my workstation running F16 or my dev laptop
21:56:28 <nirik> so, gather more info, and perhaps we can get a 0 day update fix. ;)
21:56:33 * rbergeron nods
21:56:40 <jjmcd> sounds good to me
21:56:43 <adamw> haven't been seeing that one, and i'm running shell full time on two f16 machines.
21:56:50 <jjmcd> a gnome restart every few hours fixes it
21:56:53 <rbergeron> okay, so, final call
21:57:11 <adamw> -1
21:57:39 * rbergeron is going to switch topics to wrap this meeting up
21:58:01 <rbergeron> #topic Final Call
21:58:15 <j_dulaney> For alcohal?
21:58:22 * rbergeron thinks everyone seems pretty -1 on 748241
21:58:30 <j_dulaney> Dang, can't type
21:58:34 <rbergeron> j_dulaney: yup
21:58:36 <thedonvaughn> -1 here
21:58:44 <red_alert> -1
21:58:49 <j_dulaney> -1
21:58:52 <adamw> yup
21:58:53 <thedonvaughn> needs more info, better way to duplicate it methinks.  I definitely don't have that issue on my 2 machines
21:59:17 <rbergeron> propose agreed: 748241 is not a blocker, needsinfo, doesn't hit criteria
21:59:22 <adamw> ack!
21:59:24 <rbergeron> #agreed 748241 is not a blocker, needsinfo, doesn't hit criteria
21:59:27 <nirik> might be video card/driver related.
21:59:30 <rbergeron> Okay, let's wrap this crap up
21:59:33 <adamw> almost certainly is.
21:59:46 <thedonvaughn> nirik: most likely, that's what i was thinking
22:00:01 * nirik shuts up and waits for rbergeron
22:00:08 * thedonvaughn stops too :)
22:00:17 * j_dulaney sees a ponie
22:00:18 <rbergeron> propose agreed will regroup tomorrow morning. If we know either way that the bug is impossible to fix then we should punt asap for next week; otherwise, will meet at 11am PDT tomorrow to go/no-go.
22:00:26 <j_dulaney> nack
22:00:33 <thedonvaughn> ack
22:00:57 <dgilmore> ack
22:01:13 <nirik> acked
22:01:32 * rbergeron looks around, pokes adamw
22:01:44 <j_dulaney> As usual, I must stand out from the crowd ...
22:02:15 <thedonvaughn> typical contrarian, pfft. :P
22:02:15 <rbergeron> or tflink
22:02:34 <red_alert> nak...not that anyone cares for my vote ;)
22:02:35 <adamw> ack
22:02:54 <rbergeron> okay.
22:03:09 <rbergeron> #agreed will regroup tomorrow morning. If we know either way that the bug is impossible to fix then we should punt asap for next week; otherwise, will meet at 11am PDT tomorrow to go/no-go.
22:03:25 <j_dulaney> Well, it can be said that I didn't cave
22:03:33 <rbergeron> j_dulaney: :)
22:03:35 <j_dulaney> Or that I'm just a stuborn ass
22:03:37 * nirik cares for votes... do vote as you think best. ;)
22:04:28 <j_dulaney> Seems like this one had a lot more people than my first go/no go
22:04:44 <j_dulaney> I seem to recall it was me, maybe dgilmore, and one other
22:04:57 <j_dulaney> That was sometime for F14
22:05:04 * nirik has sadly been around since before they invented no-go. ;)
22:05:06 <adamw> almost certainly me. =)
22:05:19 <j_dulaney> Actually, you were gone
22:05:22 <dgilmore> nirik: yeah, you and me both
22:05:34 <j_dulaney> adamw:  I wound up dropping QA's vote
22:05:35 <thedonvaughn> ok gotta run.  have to update HP enclosure OA firmware.  weee!  I'll begin testing the blockers/gathering info/looking at the code when I get home
22:05:37 <nirik> anyhow...
22:05:55 <j_dulaney> Maybe it was you, nirik
22:06:00 <rbergeron> okay
22:06:04 * j_dulaney will have to look through the logs
22:06:05 * rbergeron is going to end in a momento
22:06:10 * rbergeron lights a fuse for 87 seconds
22:06:23 <j_dulaney> Ending this means that I must study calculus
22:06:31 * j_dulaney is grasping for distraction
22:06:47 <nirik> could be. I'm usually around
22:07:17 <rbergeron> yes, you are :)
22:07:19 <rbergeron> okay, guys.
22:07:24 <rbergeron> #endmeeting