21:00:12 #startmeeting F16 Final Go or No Go Meeting 21:00:12 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 21:00:21 #meetingname F16 Final Go or No Go Meeting 21:00:21 The meeting name has been set to 'f16_final_go_or_no_go_meeting' 21:00:29 #chair tflink adamw dgilmore 21:00:29 Current chairs: adamw dgilmore rbergeron tflink 21:00:31 yo 21:00:37 hola 21:00:42 #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 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 #topic Why are we here 21:01:39 present 21:01:51 * pschindl is here 21:01:51 * cwickert is not awesome but will lurk anyway 21:01:53 #link https://fedoraproject.org/wiki/Fedora_16_Final_Release_Criteria 21:01:57 cwickert: sure you are :) 21:02:07 rbergeron: only with the hotdog costume ;) 21:02:30 #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 (bottles are empty, livers are well-tuned, etc) 21:02:50 AHEM. 21:03:06 with that: let's take a look at blockers. 21:03:12 #topic Blocker Bugz 21:03:16 #link https://fedoraproject.org/wiki/Current_Release_Blockers 21:03:31 adamw or tflink: want to take us through these proposed blockers 21:03:38 #chair adamw tflink dgilmore 21:03:38 Current chairs: adamw dgilmore rbergeron tflink 21:03:58 yo 21:04:05 yo baby yo 21:04:34 *muzak* 21:04:45 starting with the easy one 21:04:47 #topic https://bugzilla.redhat.com/show_bug.cgi?id=750228 21:04:58 this is basically fixed, dgilmore figured out whatever he had to wiggle to make efidisk.img work 21:05:06 woo 21:05:10 so we may as well close it or something. rc3 and rc4 both had working efidisks. 21:05:13 is it a wiggle or a fix? 21:05:17 * dgilmore proposed killing it in fire for f17 21:05:20 is there a difference? THIS IS FEDORA 21:05:26 mmhmmm 21:05:31 yeah, efidisk.img is essentially pointless anyway. 21:05:37 so, yeah, moving on. 21:05:39 rbergeron: its a timing issue 21:05:43 #info 750228 is basically fixed 21:05:49 we have two which are...not so simple. 21:05:51 #topic https://bugzilla.redhat.com/show_bug.cgi?id=750469 21:06:03 * j_dulaney is here 21:06:07 if a tad late 21:06:24 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 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 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 hrm which is serious since we're forcing upgrades to grub2? 21:07:40 yes. 21:07:49 hrm 21:08:01 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 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 yah i'm reading that novel right now :) 21:09:31 mgm has optioned the movie rights 21:09:36 so in short: the fix he's working on is the only possible fix 21:09:45 and he's implemented a small portion of it, and it's buggy? 21:10:02 ...which means a fix that is not buggy in the next day or so is probably unlikely? 21:10:04 well, no, what was implemented should have been enough to go with for release. cept it doesn't seem to work. 21:10:10 ah 21:10:25 adamw: i think its a blocker 21:10:42 dgilmore: yeah, that's my inclination too, unfortunately 21:10:59 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 and mine 21:11:07 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 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 and will hit this 21:11:28 j_dulaney: we hadn't tested liveusb-creator yet 21:11:37 j_dulaney: i'll do that next 21:11:49 ugh 21:12:00 nirik: mmhmm 21:12:08 adamw: i usually use dd to write the image though 21:12:11 adamw: see this https://bugzilla.redhat.com/show_bug.cgi?id=750896#c8 21:12:13 adamw: I used liveusb-creator in testing RC3 21:12:13 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 okay. 21:13:28 Soooooooooooo: we're not expecting a fix in hours, correct? 21:13:41 fix will need new anaconda I suppose? 21:13:41 it's possible that we might get one. 21:13:46 perhaps provide a kickstart file ? 21:13:51 yeah, fix would most likely be to anaconda. 21:13:53 oh wait, you'd have to know the device before hand then 21:14:16 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 okay. so, let's talk about second bug, so we can weigh the full scope of things 21:14:23 it's easy to miss what actually went wrong\ 21:14:25 aye 21:14:31 we really ought to fix it properly 21:14:34 * nirik is sadly +1 blocker 21:14:40 yah it's a blocker 21:14:43 forcing resuce mode after upgrade to fix things is not ok 21:15:08 whether the resulting configuration boots is likely something of a crapshoot but i doubt it often would 21:15:16 didn't for red_alert 21:15:34 so, seems like we're agreed this one's a blocker 21:15:34 wait doesn't anaconda ask you which block device to use to install to mbr? (having a brain fart) 21:15:45 adamw: yes 21:15:47 thedonvaughn: see the novel 21:16:13 #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 adamw: ah i see. 21:16:18 adamw: yeah its a blocker 21:16:21 ok 21:16:41 okay, onto the other fun 21:17:21 #topic https://bugzilla.redhat.com/show_bug.cgi?id=750896 21:17:28 so this one is quite new, kparal just found it today 21:17:43 i haven't got around to reproducing it myself yet, but i trust his diagnosis 21:18:08 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 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 it's marking all found APs as 'known'. interesting. 21:18:46 which...doesn't seem like a thing we want our OS to do. 21:18:52 yeah, less than ideal... 21:18:54 but, but, EVERYONE KNOWS ME 21:18:59 yup. not good 21:19:04 this is new. 21:19:08 f15 didn't do it. 21:19:23 the guilty commit is noted in comment #6 21:19:38 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 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 adamw: so it seems wrong 21:20:20 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 its not ideal at all 21:20:37 dgilmore: yeah, but the fix might be more complex than just 'don't do that, then'. 21:20:53 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 adamw: i dont think we have any criteria for this right? 21:21:18 and apparently none of the anaconda team who's around right now really know the NM code terribly well. 21:21:42 dgilmore: indeed. we've punted the idea of security criteria before, but it seemed like a nightmare to encode. 21:22:11 nirik: yes 21:22:16 tflink: so this is most likely to happen if you install via wired network but have a wireless adapter? 21:22:23 tflink: if you actually installed via wireless you'd probably be okay? 21:22:32 hey bcl 21:22:38 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 so far we accepted the usb upgrade issue as a blocker and we're kicking around the network issue now 21:22:48 i had to remove the ifcfg entry to get NM to take over 21:22:48 I just did a wireless install and the non-secured AP around me does not exit in sysconfig/network-scripts 21:23:04 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 tflink: can you re-install without picking any AP? 21:23:18 it would mean the connection you used for install is not there 21:23:24 I also can install to test when I get home from the office on my dev laptop 21:23:29 but security wise would be better 21:23:31 tflink: /etc/NetworkManager/system-connections/ ? 21:23:32 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 adamw: yeah 21:24:06 adamw: my gut tells me we should block 21:24:17 i can see users blasting us afterwards 21:24:23 nirik: there's nothing in there 21:24:29 ok 21:24:31 it does feel a bit sticky to me, yeah. 21:24:32 What did I miss? 21:24:43 jdulaney: the clowns! 21:25:03 LOL 21:25:09 not a lot. 21:25:30 I just have a ifcfg- in /etc/sysconfig/network-scripts/ for the AP I used during install 21:25:30 okay, soooo 21:25:43 blocker or NTH? nirik proposed nth earlier 21:25:58 * dgilmore is +1 blocker 21:26:07 tflink: yup exactly. that's what i had too 21:26:08 so it's only when you cancel joining a wireless net? 21:26:28 * j_dulaney is also +1 blocker 21:26:28 maybe we dont have enough info here? 21:26:42 I tried only cancelling. but I believe it behaves the same even if you don't cancel during installation 21:26:51 hey kparal 21:27:02 * kparal1 just joined 21:27:09 tflink's been working on reproducing 21:27:20 kparal1: I'm not seeing that here 21:27:31 so, yeah, it seems like we need more info/reproducers... 21:27:56 yeah, we probably need to figure out precisely what you have to do to hit it 21:27:56 If it is as kparal1 says, then I'm +1 blocker. lots of folks have untrusted APs surrounding them. 21:28:01 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 Cant you just turn off the Wi Fi modem at that time? 21:28:25 confused how it's writing out all _all_ APs to a ifcfg- script 21:28:25 sorry if i sound stupid 21:28:34 N1tr0g3n: if you know about the bug, sure 21:28:34 adamw: the thread you found might not be the final, I seem to remember him going through several revisions. 21:28:34 er "seems to only write one ifcfg" 21:28:34 N1tr0g3n: the problem is if you don't 21:28:38 bcl: afaics it matches up. 21:28:55 ii'm +1 blocker 21:29:03 the other stuff might have been revised, but that line was committed the same day of that email 21:29:07 proposal: gather more info, vote in bug. 21:29:14 nirik: seems reasonable 21:29:21 yeah. 21:29:32 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 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 and maybe a fix for the other bug 21:30:19 Or we call it a week, now. 21:30:25 superhuman effort part 2? 21:30:36 nirik: i hate making this be an option every time. 21:30:45 yeah 21:30:57 #agreed need more info on precisely how to hit 750896, will gather more tests and vote async in comments 21:31:00 Indeed 21:31:05 #topic slip or no slip? 21:31:13 +1 slip 21:31:14 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 .bug 750938 21:31:26 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 (that is, if we slip) 21:31:29 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 nb: i actually meant to ask dgilmore to sneak that into rc4 and forgot 21:31:49 nb: we'll sneak it into rc5, sure 21:31:52 * j_dulaney isn't pulling another all nighter testing 21:31:54 Sorry 21:31:58 adamw, i'll mark it AcceptedNTH 21:32:15 nb F16 will released with this bug? 21:32:21 * nb was not sure if it needed formal votes or not 21:32:21 Then eventually fixed? 21:32:29 my plan to half-ass the upgrade bug kinda hinged on it being an easy fix that affected only upgrade codepaths 21:32:35 nb: it should get votes, but...feh. 21:32:46 i was going to just get rc5 spun and then re-do only the upgrade tests 21:32:52 I'll say +1 NTH 21:32:54 There 21:32:58 that's 3! 21:33:07 * nirik is fine with NTH on that... 21:33:09 #agreed 750938 is acceptednth, updated release notes are good 21:33:11 adamw: if we can get anaconda fixed today ill do RC5 tonight 21:33:15 dgilmore: k 21:33:17 +1, NTH :) 21:33:26 there was mention of https://bugzilla.redhat.com/show_bug.cgi?id=744717 over in #fedora-devel... 21:33:30 adamw: really we only need to do the install media 21:33:34 dgilmore, adamw: does that mean second half of this meeting would be tomorrow? 21:33:46 dgilmore: nah, we should do everything, we can't ship install media and live media with different anaconda builds. 21:33:47 but to keep things sane we should redo all lives as well i guess 21:34:20 its abnormal to delay release of F16 again? 21:34:28 For the WiFi/anaconda bug 21:34:30 rbergeron: I'm for slipping 21:34:34 N1tr0g3n: delays happen. 21:34:41 nirik i know :) 21:34:54 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 is it possible to use a little older anaconda t oavoid problems? 21:35:03 it's still vaguely possible but may cause explosions. 21:35:04 We can't make what happened last time the norm 21:35:06 N1tr0g3n: no. 21:35:14 rbergeron: if we can id rather evaluate where we are tomorrow 21:35:18 j_dulaney: yep. 21:35:20 id prefer to not slip a week 21:35:24 I vote day 21:35:44 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 i'm okay with delay decision till just before release readiness, but...no promises. 21:36:25 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 nirik: yeah, I've been running grub2-mkconfig @ every kernel change on my xen box 21:36:37 if we don't know by RR tomorrow, we need to cut it a week. 21:36:43 and i don't know how long i'm going to manage to stay awake tonight... 21:37:18 adamw: i suggest you go sleep after the meeting :) 21:37:21 I have a calculus exam tomorrow, I'm not staying awake late 21:37:26 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 adamw: i can work with anaconda folks 21:37:40 i can't sleep afternoons 21:38:03 nirik: we don't need brno for the upgrade bug, and we need more testing on the wireless bug. 21:38:14 anyhow, I am fine with working on these 2 and checking tomorrow where we are. 21:38:19 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 okay, so: 11am pacific tomorrow? 21:38:33 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 Has anyone installed F17 Rawhide? 21:38:42 RR is at noon. 21:38:46 +1 to what adamw said 21:38:59 adamw: yup. once you fudge once :) 21:39:02 N1tr0g3n: we dont make rawhide install media 21:39:04 adamw: indeed. 21:39:13 dgilmore i didnt use install mdeia 21:39:29 rbergeron: That's why I'm -1 on doing anything tomorrow 21:39:29 this is my first cycle, so good to know :)d 21:39:29 N1tr0g3n: regardless its off topic for this meeting 21:39:39 i installed the repo (fedora-release-rawhide) and did an update 21:39:59 j_dulaney: toe that line! :) 21:40:02 N1tr0g3n: please take your question to #fedora-devel 21:40:03 someone's gotta 21:40:09 I wanted to know if the anaconda bug works on F17 21:40:12 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 kudos to all of qa and release-engineering this cycle for lots of long nights and hard work. 21:40:15 or only F16? 21:40:22 it's not worth burning poeple out over. 21:40:30 Ok, I propose we slip a week 21:40:39 N1tr0g3n: elsewhere 21:40:39 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 N1tr0g3n, not here 21:40:48 i'm fine personally, but i can tell most need a break 21:41:00 That way, we get a) don't get crappy bodged semi fixes and b) get proper testing of fixes 21:41:07 the problem with slipping a week is it just drags out the burn =) 21:41:12 adamw: ;) 21:41:14 I think it's more important to fix and test properly than to rush 21:41:17 adamw: indeed 21:41:18 adamw: hah 21:41:31 thedonvaughn: we haven't actually screwed up any of the fixes so far 21:41:33 thedonvaughn: yeah, but then new bugs show up, lather rinse, repeat. ;) 21:41:40 all the bugs have been newly-discovered stuff, not regressions 21:41:43 adamw: that's not what I'm saying 21:41:44 1 + on slipping a week 21:41:46 yeah, all our fixes have been kosher. 21:41:47 anyhoo 21:42:32 the berge? i think you're driving? 21:42:41 yeah. 21:42:43 I'm thinking. 21:42:53 either way, i'll be testing tonight :) 21:42:55 * nirik is still fine with reevaluating tomorrow. 21:43:12 if it turns out we aren't all tested by then, then slipping a week is a no brainer. 21:43:13 i am too, as fine as I can be with it, given how rule-breaking it is. 21:43:15 adamw: at least if its only anaconda i dont need to redo ec2 21:43:17 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 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 I think we are also being much better at testing and are finding stuff that we would have missed long ago. 21:44:32 nirik: yup. 21:44:32 Is it going to be a final go or no go meeting tommorow 21:44:33 ? 21:44:51 nirik: mostly, we're getting bitten in the ass by grub2. that's essentially what the cycle boils down to. 21:44:59 N1tr0g3n: this is supposed to be that meeting 21:45:01 if we go by the letter of our rules, we slip 1 week 21:45:03 adamw: how's your soul? 21:45:03 yeah, it's a big nasty change. 21:45:06 N1tr0g3n: we're really supposed to make the call right now and stick to it 21:45:06 not all blockers are fixed 21:45:09 good thing btrfs didn't land. :) 21:45:18 just think how smooth f17 will go *knocks on wood* 21:45:20 :) 21:45:23 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 thedonvaughn: yeah, with a complete anaconda UI rewrite, it'll be plain sailing! 21:45:46 Ok, understood 21:45:53 nirik: hardyharrhar 21:45:54 N1tr0g3n: we are, however, probably going to half-ass things and delay the decision until just before the RR meeting tomorrow 21:45:59 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 Oy, forgot about the Anaconda rewrite 21:46:16 But as long as we have blockers yet we aren't quite ready for release right? 21:46:26 N1tr0g3n: yup. 21:46:33 we are definitely not 'go' right now. 21:46:36 yes, as dgilmore says, by the letter of the policy, we should slip as there are unaddressed blockers. 21:46:48 slip==delay? 21:46:52 Indeed 21:46:54 N1tr0g3n, yes 21:46:58 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 dgilmore? you're also on the hook for more no sleepy here. 21:47:55 Must Anaconda scan for Wi Fi? 21:47:59 rbergeron: im down 21:48:00 Cant it do that later? 21:48:14 okay. then: 21:48:15 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 If it does get fudged, I'm apologizing in advance for not doing any testing. Calculus exam tomorrow has priority 21:48:29 red_alert: afaict it was never fixed. 21:48:42 adamw: we thought it fixed, though, afaik 21:48:47 seems like it wasn't. it's just hitting us hard this release becaue of grub -> grub2 upgrade 21:48:54 it was always installing mbr to usb 21:48:57 adamw: it was fixed for installs, not upgrades, right? 21:49:03 rbergeron: that's basically it 21:49:13 We should warn users to unplug USB devices 21:49:13 the test cases we had in the big bug from beta were all install paths 21:49:28 External HDDs usb sticks etc. 21:49:40 N1tr0g3n: that doesn't work when you're installing or upgrading from the USB device 21:49:41 N1tr0g3n: doesn't work so well if they are using it to boot off of and run the upgrader. 21:49:44 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 also, the 'broken' filtering code isn't broken on live boots 21:50:33 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 adamw: right, that really has to be fixed 21:50:58 * rbergeron nods 21:51:04 Indeed 21:51:07 id prefer the wireless issue fixed 21:51:13 me too 21:51:20 That's also a must 21:51:21 Security first! 21:51:22 okay 21:51:33 bcl is pretty confident that the wireless issue happens only if you cancel or close the dialog 21:51:58 What options do you have on that dialog? 21:52:03 Any screenshots of it? 21:52:12 the dialogs asks you for wifi to connect 21:52:14 adamw: ok, i think that we could add something there to make sure they are removed. 21:52:16 there is a combobox 21:52:22 of all available wifis 21:52:27 dgilmore: bcl thinks he knows what to do, so we'll work on that. 21:52:30 Cant you select none? 21:52:32 you can select one and OK, or Cancel 21:52:33 adamw: do we have anyone on the anaconda team to get us a new build 21:52:33 anyhow, we seem to be going in circles 21:52:39 yeah, builds aren't a problem. 21:52:42 Or selecting none=cancel which causes issue 21:52:43 ? 21:52:56 adamw: rather than doing test composes id like to just have me do a rc5 21:52:59 I think you can't select "none" 21:53:02 dgilmore: I have the powerish 21:53:06 dgilmore: yeah, we can short-circuit that 21:53:09 bcl: you rock 21:53:23 nah. I just get volunteered alot :) 21:53:24 we can just test with updates.img then go straight to compose 21:53:29 bcl: can we make magic happen? 21:53:36 yep 21:53:58 we cna try 21:54:05 even if I can't type 21:54:19 Explains a lot of bugs 21:54:20 * nirik sees a new proposed blocker: 748241 which seems not blocker to me. 21:54:34 .bug 748241 21:54:36 j_dulaney: Bug 748241 gnome-shell uses excessive CPU after resume - https://bugzilla.redhat.com/show_bug.cgi?id=748241 21:55:03 -1 blocker 21:55:07 Doesn't actually take suspend/resume ... only takes time, and after a while the pc isunuseable 21:55:46 Although, it seems like not everyone experiences it, so I dont know how common it is 21:55:52 can be fixed in an update... doesn't hit any criteria... 21:56:00 Indeed 21:56:04 nirik: yup, no criteria 21:56:04 Hence -1 21:56:08 strange. i never have that issue on either my workstation running F16 or my dev laptop 21:56:28 so, gather more info, and perhaps we can get a 0 day update fix. ;) 21:56:33 * rbergeron nods 21:56:40 sounds good to me 21:56:43 haven't been seeing that one, and i'm running shell full time on two f16 machines. 21:56:50 a gnome restart every few hours fixes it 21:56:53 okay, so, final call 21:57:11 -1 21:57:39 * rbergeron is going to switch topics to wrap this meeting up 21:58:01 #topic Final Call 21:58:15 For alcohal? 21:58:22 * rbergeron thinks everyone seems pretty -1 on 748241 21:58:30 Dang, can't type 21:58:34 j_dulaney: yup 21:58:36 -1 here 21:58:44 -1 21:58:49 -1 21:58:52 yup 21:58:53 needs more info, better way to duplicate it methinks. I definitely don't have that issue on my 2 machines 21:59:17 propose agreed: 748241 is not a blocker, needsinfo, doesn't hit criteria 21:59:22 ack! 21:59:24 #agreed 748241 is not a blocker, needsinfo, doesn't hit criteria 21:59:27 might be video card/driver related. 21:59:30