17:06:47 #startmeeting 2011-02-25 Alpha Blocker review meeting #3 17:06:47 Meeting started Fri Feb 25 17:06:47 2011 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:06:47 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:07:01 I guess I'll steer if no-one else is around to do it 17:07:28 so, welcome! we're here to review the F15 Alpha blockers again 17:07:43 note that in the go/no-go meeting on Wednesday we agreed to a one-week slip, so we're now one week behind the published schedule 17:08:19 this should be the final review before the repeated go/no-go next wednesday, if we stay on the new track. 17:08:32 any volunteers to act as bugzilla secretary? 17:08:42 I guess I will. 17:08:45 yay 17:08:53 we don't need no-one else in our Sekrit Club 17:09:19 I don't see any open blockers or NTH bugs though. 17:09:32 you may not be looking at the right list, because there are a few 17:09:37 hold on, let's ping a few people 17:10:00 That's because I used the wrong query. 17:10:12 I was looking at closed but not verified. 17:10:12 jsmith: ping 17:10:40 mcepl: ping 17:10:49 rbergeron: ping 17:10:51 dlehman: ping 17:10:58 adamw: pong 17:11:00 oh, wait, anaconda's good, cancel dlehman page :) 17:11:09 dlehman: we're doing blocker review again, but i think anaconda's good 17:11:11 adamw: pong 17:11:12 I have a bunch of stuff on F15Beta 17:11:23 dlehman: right, we don't need to worry about beta for now, we're still on alpha 17:11:26 but nothing on the alpha 17:11:31 has anything be added since the go no go meeting 17:11:54 Viking-Ice: one or two, plus we need to consider which if any of the bugs previously discussed should be nth for the RC2 17:12:29 okay, so we have a few people now, let's go ahead... 17:12:48 i'll be working off https://bugzilla.redhat.com/showdependencytree.cgi?id=657616&hide_resolved=1 first 17:12:55 #topic https://bugzilla.redhat.com/show_bug.cgi?id=676827 17:12:59 Bug 676827: high, unspecified, ---, peter.hutterer, MODIFIED, keyboard with german layout doesn't work in gdm 17:13:04 this is the bug we decided to slip for 17:13:17 it looks like we have a working fix now, according to initial testing, so that's good 17:13:38 fix is in xorg-x11-server. does anyone have anything to add there? 17:13:43 * mcepl follows the meeting, but will be soon drawn away by family duties 17:13:52 mcepl: understood, thanks 17:14:09 adamw: I'm glad to see what looks like a proper fix in there :-) 17:14:21 red_alert: So you're happy with the fix? 17:14:53 jsmith: works for me, but I haven't tried French or German layouts 17:15:49 OK, so we should probably ask for a bit more testing, just to be sure? 17:16:00 yeah. naturally it'll happen with rc2 when it gets spun, too. 17:16:16 I asked in #fedora-qa this morning but it's been a quiet day there 17:16:26 but rc2 should do the job 17:16:47 hola amigos 17:16:51 hey dgilmore 17:17:08 adamw: -1 to blocker :) 17:17:28 dgilmore: 10 points for persistence :) 17:17:38 alright, looks like we're good 17:17:57 #agreed 676827 fix is in and looks good, more testing always welcome, rc2 should get the testing job done 17:18:03 w00t! 17:18:05 Next! 17:18:06 oh, we do need karma on the fixed package, i guess. and a push from dgilmore. 17:18:28 it needs one +1 more :) 17:18:33 red_alert: only for auto-push 17:18:41 +2 with a proventester is enough for it to be manually pushed 17:18:47 Should I change the status to VERIFIED? 17:18:48 right 17:18:54 #action 676827 dgilmore push fixed build to stable 17:18:56 brunowolff: go for it 17:19:04 #topic https://bugzilla.redhat.com/show_bug.cgi?id=678720 17:19:05 Bug 678720: urgent, unspecified, ---, lpoetter, ASSIGNED, systemd echoes keystrokes to the screen 17:19:37 so this is a new one added to the list shortly after the meeting by toshio 17:19:38 hey 17:19:43 i asked him to join us...ah, there he is 17:19:55 I don't know if this is a blocker or not, but it seemed somewhat serious. 17:19:58 This one looks a bit worrisome to me 17:20:12 lennart said he'd checked a patch in upstream. 17:20:24 My gut reaction would be to call it a blocker -- but I haven't looked at the criteria to see which criterion it would hit 17:20:25 Note I filed a seperate bug for the same problem a long time ago. 17:20:27 But iiuc, there's not a fedora package of that yet. 17:20:38 brunowolff: that was not systemd related was it? 17:20:41 brunowolff: i remember that one, but i think this is a separate instance 17:20:49 I recall something similar in previous releases 17:20:55 it would probably help to get more testing and see if many people hit this 17:21:01 17:21:08 i believe we called a similar bug in f14 a blocker for alpha or beta 17:21:40 does this happen with "normal" usages 17:21:54 Viking-Ice: yes. For me it does. 17:21:58 What I am seeing only happens with systemd. At one point I tested using the other startup in F15 and prompting 17:21:58 hehe 17:21:59 abadger1999: so to be clear, what paths have you tested that hit this? 17:22:08 for encrypted disk passwords worked fine. 17:22:12 booting runlevel 5, hitting esc, ctrl-alt-f1 and login? 17:22:20 Viking-Ice: I installed f14, upgraded to rawhide, changed the systemd symlink to multi-user 17:22:27 adamw: runlevel 3 equivalent 17:22:47 * Viking-Ice boots into runlevel 3 to confirm 17:22:48 it also occurs to me that no-one will have hit this booting live 17:22:53 when I reboot, (with or without rhgb quiet; with or without hitting esc) 17:22:55 as you don't have to type a password to login 17:23:02 abadger1999: k, thanks 17:23:14 I usually (but not 100% of the time) get the problem 17:23:36 My bug for this is: https://bugzilla.redhat.com/show_bug.cgi?id=655538 and it might have more background 17:23:37 so, my proposal here is we call out for testing on -test and possibly -devel 17:23:37 Bug 655538: medium, low, ---, rstrode, NEW, Passwords for non root encrypted devices print during boot. 17:23:41 username and password echoed at the getty; console not working correctly 17:23:53 on what is happening, since there are notes about what is happening. 17:24:11 I've not hit this and I frequently switch to different runlevel allthou usually without rhgb quiet 17:24:19 Viking-Ice: thanks 17:24:29 no echo here 17:24:33 abadger1999: what kinda system are you testing on? something beefy? 17:24:44 (just trying to get an idea if this may be a fast or slow system race issue) 17:24:46 adamw: vm on a laptop. 17:24:51 so, not too speedy 17:24:52 * abadger1999 checks spec 17:25:18 4GB RAM; Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz 17:25:26 VM has one core and 512MB 17:25:46 BTW, I am not sure whether it somehow doesn't relate to my https://bugzilla.redhat.com/show_bug.cgi?id=678927 (which blocks https://bugzilla.redhat.com/show_bug.cgi?id=679842, which is Alpha blocker). 17:25:49 Bug 678927: unspecified, unspecified, ---, mgrepl, MODIFIED, SELinux denial prevents systemd-tty-ask from collecting password for unlocking encrypted /home partition 17:25:49 Bug 679842: unspecified, unspecified, ---, lpoetter, ASSIGNED, Systemd udev rule prevents systemd-tty-ask from collecting password for unlocking encrypted /home partition 17:26:09 mcepl: this is *login* passwords, not encrypted device passwords. 17:26:18 mcepl: at least, abadger's issue is. 17:26:21 oh shuut ... sorry 17:26:29 I've misread the bug 17:26:35 you may be looking at bruno's bug 17:26:41 Note that 678720 has been marked as a duplicate of 655538. 17:26:49 brunowolff's issue kinda straddles both mcepl's bug and my bug. 17:26:53 ...and then de-duped. 17:26:56 I can't reproduce the issue either 17:27:00 anyhoo, i think we need more data 17:27:09 can people who can't reproduce please post in the bug, including exact steps they tried? 17:27:15 (and people who can reproduce, of course :>) 17:27:37 I can install a new VM if someone wants me to test -- is there a preferred image/method to install at this point? 17:27:38 BTW, I have been able to reproduce Bruno's bug for a long time (since very very early F15) 17:27:54 proposal: #action adamw to send out call for testers to try and replicate the issue and post their results in the bug. #action abadger1999 and lennart to try and isolate a cause 17:27:56 ack/nack? 17:27:58 i think abadger1999 issue is pretty serious 17:28:11 abadger1999: RC1 at this point 17:28:25 * abadger1999 gets to downloading 17:28:41 votes on the proposal? 17:28:42 * jsmith leans toward ACK barring further information 17:28:43 ack 17:28:53 adamw: i'm at a conference 17:28:56 rbergeron: ok 17:29:00 let's wait for abadger1999 to reproduce this with a fresh install and if he can reproduce let's proceed with what you proposed 17:29:21 reasonable 17:29:59 Yeah, this one is more serious than my bug, as I can clear stuff at boot. This one leaves passwords for discovery unless you know about the bug. 17:30:26 i think that because this will effect a somewhat unknown but smallish number of people it should be a beta blocker 17:30:30 #agreed 678720 is worrying but needs more data: we need to know the root cause and need to test if it affects other installs. blocker status undetermined until more data available 17:30:48 #action abadger1999 to try and reproduce with a clean install and investigate possible causes with lennart 17:31:00 #action adamw to send out call for wider testing if abadger1999 can reproduce with a clean install 17:31:07 that okay with everyone? 17:31:13 17:31:18 adamw: sure 17:31:20 yes 17:31:23 yup 17:31:28 great 17:31:35 +1 17:31:46 #topic https://bugzilla.redhat.com/show_bug.cgi?id=679486 17:31:48 Bug 679486: medium, low, ---, xgl-maint, ASSIGNED, Unable to start graphical installer on RC1 KDE live image 17:32:03 this is still on the alpha tracker just because we didn't finish up secretary work from the go/no-go yet 17:32:18 at the go/no-go we agreed it was not a blocker due to inability of anyone to reproduce, but we have significantly more data since then 17:32:21 cannot we do other password, cryptsetup stuff first ... it seems related, and I have some comment son it 17:32:32 hehe 17:32:35 erf, okay 17:32:39 changing track! we'll be back on this one 17:32:55 mcepl: 679842? 17:33:06 678927? 17:33:29 both, they are very closely related (if not duplicates) and blocking each other. 17:33:32 okay 17:33:38 #topic https://bugzilla.redhat.com/show_bug.cgi?id=679842 17:33:40 Bug 679842: unspecified, unspecified, ---, lpoetter, ASSIGNED, Systemd udev rule prevents systemd-tty-ask from collecting password for unlocking encrypted /home partition 17:33:50 this is again one we decided wasn't a blocker at the go/no-go but haven't cleaned up yet 17:34:12 thanks to jlaska and dgilmore we determined it did not affect a default+encryption install (the minimal actions necessary to set up encryption) 17:34:14 so I was running around appropriate people around this one and it seems to be an epic struggle between LVM, Lennart and udev people ... 17:34:39 it seems there's a fix in for the selinux denial, but it also seems the selinux denial isn't terribly important? 17:34:44 but no one knows for sure what's going on ... there are multiple things wrong (and maybe it is SELinux after all?), but there is nothing certain, and certianly nothing which would fix it for me. 17:35:07 yes, it is probably deeper than just SELinux 17:35:52 one possible candidate are some messed up udev rules, then there is certianly something wrong with udev database (there is different one in initrd image then in kernel), but fixing that (via mkinitrd) didn't help me either. 17:36:08 s/in kernel/in live system/ 17:36:14 do you have any data which would change our understanding of the *impact* of the bug? 17:37:02 well, the situation is that I have to start in runlevel 1, make cryptsetup runs manually, and then telinit 5 to get gdm, If that's acceptable at the Alpha level, than be it. 17:37:15 mcepl: the issue is in what configurations you hit the bug 17:37:18 judge yourself 17:37:32 what do you mean by configurations? 17:37:37 at present our understanding is you need to go into partitioning and do a custom setup with encryption before you'd hit this 17:37:41 this does not affect "default install" encrypted or not 17:38:02 if you just use the big-picture partitioning options - 'use entire disk', 'use free space' etc - and check the 'encryption' box, you don't hit this 17:38:13 based on that we determined it was beta, not alpha 17:38:17 yup 17:38:26 oh well, this isn't a clean install ... I have been running this /home encrypted since at least F10. So although I have fresh installed o ver it, the partitionining was done long long time ago 17:38:48 right - for alpha, our requirements in terms of what partition layouts should work are pretty limited 17:38:55 yes, I have /home partition and swap encrypted, which kind of screws up gdm (when it doesn't have /home) 17:39:19 although we do call out 'existing linux partitions', which might hit this, i guess? 17:39:36 i've never been entirely clear on exactly what that option does. 17:39:57 mcepl: how did you setup your disks? 17:39:59 it does not reuse you partition layout as one would have wanted 17:40:00 criterion is "The installer must be able to complete an installation using the entire disk, existing free space, or existing Linux partitions methods, with or without encryption enabled" 17:40:06 I do custom partitioning always (and leaving partitioning as it is with formatting just root, swap and similar) 17:40:07 I have /home, / and swap encrypted and don't see this. 17:40:33 OK, then I am out of this criterion 17:40:33 No LVM though. 17:40:45 same as I would do it 17:40:46 okay 17:40:54 i think we haven't changed our understanding of the impact 17:40:59 so this remains non-blocker... 17:41:11 adamw: agreed 17:41:18 given the apparent complexity here (thanks for the investigation mcepl), it doesn't seem a good candidate for nth either 17:41:18 Should I move it to beta blocker? 17:41:27 let's consider nth first 17:41:39 anyone think this is a good nth candidate? 17:41:53 for any who aren't clear - nth means we'd take a fix into the alpha respin if it was available 17:42:17 the likelihood of the fix breaking something else is a clear factor when considering nth status, which is why i feel icky about this one. 17:42:29 I say it's an blocker 17:42:33 beta 17:42:44 right, i think beta blocker is agreed 17:42:44 as in beta blocker 17:42:47 but the question is, alpha nth or no 17:42:55 * jsmith is on the fence 17:42:59 let's not risk another delay 17:43:03 I guess if I had to vote, I'd say NTH 17:43:04 a bug can be both 17:43:09 well, I would for nth, because while uncovering this, there were numerous things really broken dug out. 17:43:28 which would be nice to have in respin, if it happens. 17:43:29 I'm - on nth 17:43:36 -1 nth 17:43:40 -1 nth 17:43:42 + hard beta blocker 17:43:55 -1 nth 17:44:07 mcepl: see, fixing 'numerous things' in core components like udev and lvm strikes me as scary at this point =) 17:44:29 so we have...me, viking, bruno -1 nth 17:44:34 mcepl and jsmith +1 nth 17:44:36 any other votes? 17:44:39 well, letting them broken just because of bureaucracy sounds scary to me as well, but taken being overvoted 17:44:53 *taking 17:45:14 mcepl: the existing testing gives us reasonable confidence they're not 'broken' in terms of the alpha criteria - i.e. they haven't caused any other alpha blocker bugs in all the tc+rc testing 17:45:40 adamw: seem to have forgotten red_alert's vote 17:45:46 whoops! sorry 17:45:47 adamw: -1 nth 17:45:55 okay, so that's 5 to 2, i'm calling it =) 17:45:59 as I said, go ahead with lifting it, but please put it on beta blocker list. 17:46:25 #agreed no data changes the impact of 679842, it remains not an alpha blocker. agreed by all that it is a beta blocker. voted not alpha NTH by 5 to 2. 17:46:34 brunowolff: go ahead and secretaryize :) 17:46:46 Doing... 17:46:55 #topic https://bugzilla.redhat.com/show_bug.cgi?id=679486 17:46:57 Bug 679486: medium, low, ---, xgl-maint, ASSIGNED, Unable to start graphical installer on RC1 KDE live image 17:46:58 back to this one 17:47:26 so, as I said, at the go/no-go we agreed this was not a blocker on the basis of non-reproducibility 17:47:28 (is that a word?) 17:47:49 we know what's the cause is now 17:47:50 thanks to viking and red_alert, we have a much better understanding of the issue now, which is summarized in comment #38 (I hope without errors) 17:48:12 actually it was called non-blocker and even closed notabug before go/nogo :/ 17:48:31 red_alert: sure, but we discussed it at go/no-go to be 'safe' 17:48:34 anyhoo 17:48:54 so, this is really a kind of race between desktop login and networkmanager, if dhcp is setting the system hostname 17:48:58 * red_alert reopened and reblocked the next time after reproducing ;) 17:49:14 s/time/morning/ 17:49:15 it's not limited to kde, but showed up more there because it uses auto-login and gnome doesn't 17:49:29 you could probably hit it on gnome with a fast system, slightly slow network, and a quick trigger finger 17:49:37 does this affect complete installs btw ? 17:49:42 as in non livecd's 17:50:01 Viking-Ice: traditional install? i don't see any reason it would 17:50:23 It should 17:50:26 it's only because livecd has no fixed hostname in /etc/sysconfig/network which installed systems normally do have 17:50:36 okay 17:50:52 I c 17:50:55 (i.e. the hostname you configure in anaconda) 17:51:22 so the key question here, i guess, becomes how many systems use DHCP hostname assignment, and how likely are you to hit the bug exactly 17:51:26 both of which are a bit tricky to answer 17:51:48 * dgilmore thinks this is probably a beta blocker 17:51:51 anyone have a clear feeling either way on the blockeriness of this? my gut instinct is -1 blocker, +1 nth 17:51:58 * jsmith is just the opposite 17:51:59 given there's a reasonably easy workaround 17:52:13 -1 -1 nth +1 betablocker 17:52:19 It's easy to work around, if you control your DHCP environment 17:52:24 I figure we don't need to block alpha with this, if we document 'xhost +' as a workaround - but it should be fixed sometime 17:52:32 jsmith: no, the 'easy workaround' is to run 'xhost +' 17:52:37 then re-run the installer, and it works 17:52:38 jsmith: i think most people do 17:52:40 adamw: Ah, that workaround... 17:52:50 since most people will plug into a router type device 17:52:53 sorry, should have mentioned that :) 17:52:56 "xhost +" is a bit of a security issue though, right? 17:53:06 in a live environment? meh. 17:53:06 * jsmith always learned that "xhost +" is a command of last resort 17:53:29 +1 alpha nth, +1 beta blocker :) 17:53:29 we should note the cases we've identified for dhcp host assignment too 17:53:44 Alright, looks like I'm in the minority here 17:53:54 Let's go ahead and mark it as alpha NTH, and beta blocker 17:53:59 so far we've come up with 'some corporate networks' (red_alert's case), and 'system connected directly to consumer ISP' (rather than via a router) 17:54:05 I figure instead of 'xhost +' there's also something that only allows the new hostname 17:54:27 red_alert: yeah, we can probably come up with something finer-grained. 17:55:32 This seems like an odd way to do things. Why not use the loopback interface for local X connections? 17:55:39 okay, so, proposed #agreed 679486 agreed not an alpha blocker due to ease of workaround and quite limited impact, agreed beta blocker and alpha NTH 17:56:00 brunowolff: if it's not related to the blockeriness can you comment in the bug or on a mailing list for more general stuff? thanks 17:56:09 ack/nack/modify? 17:56:18 ACK 17:56:57 brunowolff: oh, please also add the CommonBugs keywords to any bugs where we talk about documenting a workaround, like this one - thanks! 17:57:40 ack 17:57:41 I'll add the key word for this one while updating it, but did any of the ones we already did need this? 17:57:55 Iack 17:57:58 ack 17:58:15 brunowolff: possibly the encryption issue i guess 17:58:51 okay 17:58:52 OK, I'll go back to that one and look at it. 17:58:57 #agreed 679486 agreed not an alpha blocker due to ease of workaround and quite limited impact, agreed beta blocker and alpha NTH 17:59:16 okay, we're onto the NTH list now 17:59:40 ack 17:59:50 #topic https://bugzilla.redhat.com/showdependencytree.cgi?id=657617&hide_resolved=1 18:00:53 just a couple here that haven't been discussed 18:00:55 #topic https://bugzilla.redhat.com/show_bug.cgi?id=677842 18:00:56 Bug 677842: unspecified, unspecified, ---, jglisse, NEW, [abrt] mutter-2.91.6-4.fc15: ureg_src: Process /usr/bin/mutter was killed by signal 11 (SIGSEGV) 18:01:06 so, back to the ol' mutter issue 18:01:30 i think we now have a reasonably good understanding of this: it's an issue with gcc in generating 32-bit code, and it actually does affect multiple types of card 18:01:40 so basically if you run the 32-bit image you've got a decent chance of hitting this 18:02:01 +1 NTH 18:02:02 we rejected this as a blocker at the go/no-go, but i wanted to consider it as NTH 18:02:22 I think this is pretty obvious as a NTH 18:02:25 i'm definitely +1 nth, i'd really like this to get fixed 18:02:28 +1 nth 18:02:49 I propose a workaround of removing 32bit from the list of primary architectures ;) 18:02:52 red_alert: hehe 18:03:05 agreed days of 32 are over 18:03:08 adamw: i wont object to having this nth 18:03:17 i think we need to actively get the tools folks involved too, since it's pretty clearly a compiler issue but they don't seem to be active in the bug 18:03:20 +1 nth 18:03:27 adamw: I agree 18:03:55 does anyone want to reconsider blocker status for this, given that it apparently has impact beyond just r600+ radeons? 18:04:08 nope 18:04:12 nope 18:04:37 adamw: Tempting... but I'm gonna say no... NTH is probably enough 18:04:52 not all r600+ are affected, though 18:05:07 red_alert: i think actually they are, but only 32-bit is affected 18:05:14 ah, possible 18:05:22 already forgot about that again :/ 18:05:24 successes with r600+ are all x86-64 afaict 18:05:50 i think all r600+ radeons and an undetermined range of nvidia hardware is affected, that's my best read atm 18:05:54 not sure about intel yet 18:06:24 so if you look at the big picture, the 32-bit alpha is going to be pretty broken if we don't fix this. 18:06:38 which makes red_alert's proposed workaround look marginally more sensible ;) 18:06:58 still, we voted. i'll try and get X and tools folks to get together and fix this quick 18:07:12 dgilmore: what's the current plan for spinning rc2, are we looking at monday? 18:07:47 adamw: today 18:07:56 assuming all blockers are fixed 18:07:59 Aren't people still running i686 likely not to have r600 based video cards? 18:07:59 ah, see, that's the thing - the ones we're marking NTH aren't going to get into rc2 unless we fix 'em fast 18:08:01 yey, that saves my weekend! rain AND rc3 <3 18:08:11 brunowolff: sure - but it seems other cards are affected... 18:08:58 brunowolff: when secretaryizing, remember to add 'AcceptedBlocker' whiteboard field to agreed blockers, 'RejectedBlocker' to rejected ones; same for NTH ('AcceptedNTH' and 'RejectedNTH') 18:09:14 helps us keep track of what we've already made a determination on 18:09:28 Thanks. I haven't had practice at this yet. 18:09:31 npnp :) 18:09:57 #agreed 677842 remains non-blocker, is accepted as NTH for Alpha 18:11:23 adamw: For cases where waiting for more information, I shouldn't put anything in whiteboard? 18:11:30 brunowolff: right 18:11:36 brunowolff: that indicates status is still undetermined 18:11:38 #topic https://bugzilla.redhat.com/show_bug.cgi?id=679171 18:11:40 Bug 679171: high, unspecified, ---, mgracik, POST, Hitting enter to move to Next screen crashes firstboot 18:11:42 okay, this is the last one on the list for now 18:11:51 this is the 'firstboot crashes if you hit enter' bug 18:12:00 we determined it wasn't a blocker on wednesday, but i'm proposing it as NTH 18:12:02 hum I did not notice this 18:12:06 especially since we have a fix, i'd like to pull it in 18:12:14 ok +1 nth 18:12:21 adamw: Do we yet know where the problem lies? 18:12:23 +1 nth 18:12:28 adamw: In other words, is it in firstboot itself? 18:12:33 adamw: Or in some other component? 18:12:44 jsmith: the fix is in firstboot. 18:12:51 adamw: +1 for nth 18:12:52 adamw: Then I'm definitely for NTH 18:12:57 in its initscripts, it fact. see https://www.redhat.com/archives/anaconda-devel-list/2011-February/msg00235.html 18:13:23 +1 for NTH 18:14:59 okay 18:15:07 #agreed 679171 accepted as NTH 18:15:15 * jsmith has to run.... Sorry folks! 18:15:20 #action adamw to try and get the fix pushed into firstboot in time for rc2 18:15:26 thanks jsmith! we're all done now i think 18:15:30 #topic open floor 18:15:49 anyone have any bugs to bring forward for consideration as blocker or nth? any we dropped as blockers but missed considering as nth? I tried to catch them all, but may have missed some 18:15:51 I'd like to propose 673824 and 680410 as NTH 18:15:55 cool, thanks 18:16:01 so when are we going to stop adding bugs the list 18:16:07 they're probably the same issue but two bugs for tracking reasons 18:16:09 since if we continue to do we never get alpha out 18:16:28 Viking-Ice: nth bugs don't block alpha. 18:16:35 Viking-Ice: they just go into the spin if a fix is available. 18:16:42 Viking-Ice: the rc2 train leaves the station tonight regardlesss 18:16:46 #topic https://bugzilla.redhat.com/show_bug.cgi?id=673824 18:16:46 I'm also talking about alpha 18:16:47 Bug 673824: unspecified, unspecified, ---, rvykydal, ASSIGNED, [anaconda] prompts user for network device prematurely in netinst 18:16:55 blockers 18:16:57 adamw: and if i remeber to pull the fix in 18:17:00 Viking-Ice: we have exactly one blocker 18:17:08 dgilmore: that's what i put the list in the trac ticket for :) 18:17:34 adamw: i still forget sometimes 18:17:36 red_alert: so, what's the impact of this? 18:17:40 dgilmore: heh 18:18:01 basically it's just a premature dialog asking for network 18:18:16 *cosmetic* bug? 18:18:25 right 18:18:28 that's not a big issue on the netinst media...but can be sort of annoying on the dvd if you plan not to use network 18:18:41 can you not configure a network connection and install will continue? 18:18:42 just a general bug 18:18:44 * dgilmore says no 18:18:44 it's caused by no longer having stage 1 and 2 18:18:55 * dgilmore doesnt want any anaconda changes now 18:19:03 agreed 18:19:10 yeah, the fact that this is in anaconda makes me very hard to convince for a +1 18:19:53 okay, we'll go beta then :) 18:20:05 I just say it's an general bug 18:20:24 okay, i'm -1...looks like a consensus :) 18:20:30 #agreed 673824 rejected nth 18:20:39 could be UI design if they are using the same designers as the Gnome hehe 18:20:43 no need to bring up the other one I said then 18:20:53 680410 looks like a dupe, so no need to discuss it...right 18:21:06 #topic open floor 18:21:09 any other proposals? 18:21:24