00:00:58 #startmeeting Fedora 14 Alpha Go / No-Go meeting #1 00:00:58 Meeting started Thu Aug 12 00:00:58 2010 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 00:00:58 Useful Commands: #action #agreed #halp #info #idea #link #topic. 00:01:26 * nirik waves. 00:01:28 #meetingname gonogo 00:01:28 The meeting name has been set to 'gonogo' 00:01:39 note the highly optimistic topic! 00:01:45 * fenris02 smirks 00:01:47 so, this is the go/no-go meeting for fedora 14 alpha 00:01:47 Aye :-) 00:01:48 hola amigos 00:01:49 * tk009 watches fro the sidelines 00:02:02 we need representatives from development, releng, and qa 00:02:07 * adamw wears a QA hat 00:02:08 rc3 appears to actually boot for me, so that's progress :) 00:02:12 who wants to be development, and releng? 00:02:26 jlaska and poelcat both send apologies, btw 00:03:03 dgilmore: you can be rel-eng, right? 00:03:10 * nirik can try and be development I suppose. 00:03:16 Thanks nirik 00:03:23 * rdieter seconds dgilmore's releng nomination. 00:03:31 * jds2001 thirds it 00:03:34 =) 00:03:36 adamw: im all you have so yes 00:03:38 Hmmmmn... dgilmore doesn't seem to be responding 00:03:42 Oh, there he is! 00:03:44 #info QA representative = adamw, releng representative = dgilmore, devel representative = nirik 00:03:59 #info general busybody = jsmith 00:04:05 ;) 00:04:13 * jds2001 sits in the cheap seats 00:04:14 :) 00:04:20 okay, so, let's have a look where we are for the Alpha. 00:04:23 useful links: 00:04:25 * jsmith warmly greets all those who took time out of their busy schedules to come to the meeting 00:04:43 #link https://bugzilla.redhat.com/showdependencytree.cgi?id=611990&hide_resolved=1 00:04:58 * onekopaka_laptop sits in the cheap seats as well 00:04:58 that's the remaining blocker (and potential blocker) bugs 00:05:16 #link https://fedoraproject.org/wiki/Test_Results:Fedora_14_Alpha_RC3_Install 00:05:20 #link https://fedoraproject.org/wiki/Test_Results:Fedora_14_Alpha_RC3_Desktop 00:05:20 well, they all have to be closed before we are 'go' right? 00:05:23 I think the most worrying thing to me is the number of bugs still in NEW state in that list 00:05:35 those are the formal test matrices 00:05:45 #link https://fedoraproject.org/wiki/Fedora_14_Alpha_Release_Criteria 00:05:49 those are the release criteria. 00:05:57 okey dokey! usually, we parse the remaining bug list 00:06:04 any objections to doing that? 00:06:30 sounds good. 00:06:40 +1 from me 00:06:41 sounds good to me 00:06:42 okay. i'm going to use a slightly idiosyncratic order to hold the really icky ones for the end 00:06:52 Sorry I'm late 00:06:58 i went through each bug a couple hours back and put meeting talking points into them all 00:07:03 hi, j_dulaney 00:07:12 adamw: 00:07:14 adamw: Thanks for updating the bugs! 00:07:24 let's go with a couple of different bugs with similar impacts first 00:07:28 #topic tty bugs 00:07:39 there seems to be a few of those. 00:07:41 #link https://bugzilla.redhat.com/show_bug.cgi?id=623102 00:07:47 #link https://bugzilla.redhat.com/show_bug.cgi?id=623102 00:07:49 grr 00:07:55 #link https://bugzilla.redhat.com/show_bug.cgi?id=623430 00:07:55 #undo 00:08:00 * nirik notes you don't need to use #link. 00:08:01 where is bugbot? 00:08:08 nirik: meh, i like being formal =) 00:08:08 it figures those out itself. ;) 00:08:17 .bug 623102 00:08:19 nirik: Bug 623102 no login prompt on tty1 - https://bugzilla.redhat.com/show_bug.cgi?id=623102 00:08:23 .bug 623430 00:08:24 nirik: Bug 623430 getty on tty1 is not visible at first - https://bugzilla.redhat.com/show_bug.cgi?id=623430 00:08:49 anyway! both these bugs relate to the availability of the default login tty after doing a console boot 00:09:19 623102 happens when you do a 'minimal' install (or, in fact, any install via the traditional installer which results in X not being installed) 00:09:37 adamw: honestly as long as we have a tty the user ca egt to for alpha im ok with it 00:09:52 anaconda doesn't set up multi-user.target as the default target in such a case; it leaves graphical.target as the default 00:10:09 result: no tty1, boot goes to a blank screen and you need to do ctrl-alt-f2 to get a login screen 00:10:20 Right... both of these are edge cases where the release criteria aren't clear 00:10:22 there is no criteria that we have currently that matches these... 00:10:39 * dgilmore thinks this needs fixed by beta 00:10:41 623430 happens if you have a 'normal' install and manually boot to runlevel 3 (well, multi-user.target, but never mind) 00:10:45 but alpha is ok 00:10:50 +1 for fixed by beta 00:11:03 the ultimate result is similar - usually if you boot to a console, you'll get no obvious login screen, and have to switch to tty2 (or, for the second case, hit enter or ctrl-c) to get one. 00:11:19 I'll say +1 for fixed by beta 00:11:20 and yep, indeed, what we need to do here is set our expectations for such cases, so we can formalize them in the release criteria. 00:11:33 I would say document in release notes and yeah, fix by beta. 00:11:47 okay 00:11:55 so how badly broken can alpha be before we reckon it's too bad? 00:12:03 is the cut-off point that *some* of the default ttys are available? 00:12:26 adamw: so, i think for beta and beyond we need to ensure the user gets a login prompt without intervention regardless of how installed. 00:12:30 I would say it needs to have some way (even if you need to read a doc about it) to get to a prompt and apply updates. 00:12:36 so if we had an alpha release criteria which said 'booting to the console, you can log in through at least one of the default virtual consoles', and for beta, 'all virtual consoles must start up and offer a login prompt'? 00:12:46 adamw: I'd say that either ctrl-alt-f1 or ctrl-alt-f2 should get you to a prompt by alpha 00:12:50 adamw: Yes, that sounds good 00:12:53 adamw: for alpha we must have a tty available 00:12:56 adamw, it's alpha. it is not expected to be perfect. it should be testable. imho, vc1 is not something that should block 00:12:59 adamw: that sounds kinda custom tailored to this bug tho. 00:13:21 nirik: i'm just trying to formalize what exactly we're agreeing here 00:13:41 if vc2 doesnt come up either, that would be a real issue. 00:13:44 i'd rather we come up with a proper release criteria proposal than just a case-by-case 'oh yeah this one's okay' - the release criteria are an attempt to get away from case-by-case judgments 00:13:55 for alpha: graphical login should let you login and get to a desktop, beta: graphical and vty logins should log you in and get you to a prompt/desktop? that seems weird to make the gui target sooner tho. 00:13:57 by beta, vc1 should work. 00:14:06 adamw: your proposal is acceptable 00:14:43 adam: I concur 00:14:48 ok 00:14:58 nirik: yours doesn't require console mode startup to work *at all* for alpha? 00:15:13 yeah, which seems wrong... 00:15:26 well, i think we have a reasonable consensus from which we can start a criteria proposal at least 00:15:27 I guess your proposal is ok... 00:15:34 so in the interests of time let's move on, we can refine it on the lists later 00:15:38 * nirik nods 00:15:43 * jsmith nods as well 00:15:44 * onekopaka_laptop votes for adamw's proposal quickly 00:15:47 indeed 00:15:50 onward! 00:16:15 #agreed tty1 issues should not block Alpha, we have a broad consensus for a generic release criteria proposal to move forward on after the meeting 00:16:38 okay, this one should be quite easy 00:16:40 #topic https://bugzilla.redhat.com/show_bug.cgi?id=623213 00:17:00 .bug 623213 00:17:01 nirik: Bug 623213 Package conflicts present on F-14-Alpha-RC3 DVD - https://bugzilla.redhat.com/show_bug.cgi?id=623213 00:17:08 this is just that systemd-sysvinit and upstart-sysvinit on the media conflict, which we have as a criterion for release 00:17:18 but jlaska and i agree it would be reasonable to modify that somewhat 00:17:26 adamw: i think intentional conflicts are ok 00:17:30 the aim of the criterion was to ensure you couldn't get into dependency trouble making package selections during install 00:17:41 and with this type of conflict, you can't do that 00:17:45 Right -- comps is set so that you can't install both without explicitly doing it with a kickstart script, right? 00:17:48 * nirik nods. Intentional conflicts should be fine. 00:17:52 see comments #4 and #5 on the bug 00:18:28 my proposal would be to tighten the release criterion to consider only the case where the conflict causes a problem with any of the available package selection mechanisms during an interactive install 00:18:39 and by that test, this wouldn't be a blocker 00:18:48 +1 from me. 00:18:49 I have had no problem with any isntalls regaurding that bug. 00:18:54 I'd go the other way -- just say that intentional conflicts are OK, and call this intentional 00:19:22 Otherwise, we might get into other cases of gray area 00:19:27 jsmith: well, that's not entirely safe; someone could make two packages conflict which both wind up getting pulled in as deps in the default install set. it's unlikely, but it *could* happen. we'd want to insure against that 00:19:42 adamw: Fair enough 00:19:56 adamw: AutoQA test for that? 00:19:59 i guess we can note both proposals and discuss them after, again; but we broadly agree that the criterion should be strengthened and this conflict should fall outside it 00:20:07 Correct 00:20:09 j_dulaney: this test is in fact part automated and should be fully automated in future 00:20:09 * poelcat arrives 00:20:10 * nirik nods 00:20:13 hey poelcat 00:20:15 #chair poelcat 00:20:15 Current chairs: adamw poelcat 00:20:16 welcome poelcat 00:20:23 * jsmith greets poelcat 00:20:36 poelcat: How was the dentist? 00:20:37 Howdy 00:20:52 #agreed an intentional conflict which cannot cause problems with any interactive package selection method should not be a blocker, we will propose a tightening of the relevant release criterion and install test 00:21:04 adamw: Roger 00:21:09 okay, onward 00:21:42 oh, note: 620623 is on the list also because of 623213, we don't need to consider them separately 00:21:51 whoops, that's wrong, ignore it. =) 00:22:05 we'll do 620623 in a minute. 00:22:08 next up: 00:22:08 #topic https://bugzilla.redhat.com/show_bug.cgi?id=621027 00:22:13 .bug 621027 00:22:15 nirik: Bug 621027 Graphical screen in anaconda shows F-13 - https://bugzilla.redhat.com/show_bug.cgi?id=621027 00:22:32 so, see comment #11: this is an artwork polish bug, the alpha compose uses f13 artwork in multiple places. 00:22:48 (the desktop live has f13 background, actually, which isn't noted there) 00:22:56 By itself, I don't think this is enough to block 00:23:04 artwork is another area we haven't pinned down for the release criteria yet, we need to decide at which points we want to make sure we have the artwork pinned down 00:23:07 My yum installed desktops all have F13 artwork 00:23:11 That being said, I think future Alphas should identify themselves as such 00:23:17 * poelcat thought we were targetting wallpaper for alpha from design prospective 00:23:28 s/design/design team 00:23:35 though not explicitly a blocker 00:23:35 poelcat: I though so too... but I didn't find it on their list 00:23:45 poelcat: i believe their target is that the artwork should be done by alpha, but that's not the same as it blocking the release if it isn't... 00:23:53 dcr226: hi 00:23:54 agreed 00:23:55 it would be very nice to have it identify that way. 00:23:58 personally i'd want to start worrying about artwork at beta stage 00:24:03 mizmo attached a generic splash screen to that bug 00:24:03 but I don't think it's a blocker. 00:24:06 though it would be nice to have alphas identified as such, yes 00:24:18 I suggested we automate the mangling of the SVG to automagically put the current release number in it 00:24:24 we can work on refining this outside of this meeting 00:24:26 I don't see any reason to have art block alpha, as alpha is more for testing 00:24:32 That way, we're not depending on a manual process of "create new artwork" every time 00:24:36 of course, then, arguably, we should upgrade people who install alpha and upgrade to final to the final artwork, and that's more complication... 00:24:39 jsmith: sounds good 00:24:50 it could be something generic, like a dancing hot dog. ;) 00:24:54 Exactly! 00:24:56 LOL 00:25:03 so, are we broadly agreed alpha shouldn't block on artwork, and we should start introducing the artwork criteria at beta stage? 00:25:06 j_dulaney: You obviously haven't seen the hot dog 00:25:07 * j_dulaney votes for a steak 00:25:14 adamw: yes 00:25:15 adamw: Yes, 00:25:17 adamw: yeah 00:25:22 nirik: ? 00:25:23 adamw: indeed 00:25:24 yep 00:25:26 it needs some official public soak time 00:25:26 great 00:25:34 Onward! 00:25:44 #agreed broad consensus that artwork criteria should kick in at beta stage, this bug should not block alpha 00:25:58 #topic https://bugzilla.redhat.com/show_bug.cgi?id=620623 00:26:00 is there an #action to update the criteria? 00:26:01 okay, this is the last of the easy ones =) 00:26:07 .bug 620623 00:26:09 nirik: Bug 620623 Packages with unresolved dependencies - https://bugzilla.redhat.com/show_bug.cgi?id=620623 00:26:27 poelcat: it would be a bit premature, these are just rough outlines, we need to put proposals on test list before applying the criteria changes 00:26:36 adamw: should we make the artwork thing a permanent beta criteria? 00:26:37 It looks like this one has been resolved, right? 00:26:40 this one is basically fixed for rc3 00:26:46 Any reason not to take it off the blocker list? 00:26:50 i just wasn't sure whether bill wanted the bug closed or just taken off teh blocker list 00:27:07 I'd say close it, if the problem has been resolved. 00:27:10 well, it's fixed, so close? 00:27:10 * j_dulaney hasn't had unresolved python problems in a while 00:27:11 If it's a problem, he can re-open 00:27:14 ok 00:27:22 adamw: its fixed close it 00:27:40 #agreed this is fixed for rc3, so close it: if more dependency problems are found in potential later builds, it can be reopened 00:28:01 adamw: indeed 00:28:01 alright, those were all the ones i expected probably not to be a problem 00:28:02 Now on to the more difficult ones 00:28:05 now we're onto the tricky ones =) 00:28:24 #topic https://bugzilla.redhat.com/show_bug.cgi?id=623129 00:28:39 .bug 623129 00:28:40 nirik: Bug 623129 xdriver=vesa is not honored - https://bugzilla.redhat.com/show_bug.cgi?id=623129 00:28:51 pretty simple bug: the xdriver= parameter which should instruct anaconda to use a particular video driver just isn't used 00:28:56 bug I've had 00:28:59 (i'm 99% sure it doesn't work in live either, but haven't had time to test it yet) 00:29:14 It doesn't work with yum update 00:29:16 what this means is that in many cases, the Basic Video Driver install choice, a common workaround if your graphics card has problems with the native driver, won't work right 00:29:53 by blind luck it works with intel and nouveau-supported cards, as the 'nomodeset' parameter is passed as well as xdriver=vesa , and nouveau and intel refuse to load if there's no KMS support 00:29:54 yeah. :( 00:29:59 so in those cases you actually *do* get vesa 00:30:00 * jsmith doesn't like this 00:30:11 but it doesn't work with radeon, or any of the older, more niche drivers 00:30:27 note that intel+nouveau+radeon is about 97% of the user base, so if radeon wasn't a problem i wouldn't mind this, but it is. 00:30:35 Aye 00:30:50 the other problem is there is just no practical workaround for this 00:30:57 Correct 00:30:57 we can't ship an updates.img even if we'd consider that, as the bug is too early 00:31:14 so this needs an anaconda fix? 00:31:20 So, I'm gonna be the one to say it -- I think this means we slip a week 00:31:21 so if you have a radeon (or weird card) and the native driver doesn't work for you, you are boned unless you do a text install. and we made text install sekrit and unsupported with this release. 00:31:33 nirik: yes, there's a proposed patch in the bug 00:31:47 nirik: i'll get around to proposing a patch for spin-kickstarts to make it work in live boots soon 00:31:47 * nirik wonders if a rd_blacklist=yourvideodrivermodule would get you vesa. 00:32:03 nirik: i think not - X winds up loading it for you in that case, iirc. 00:32:08 nirik: no 00:32:22 it goes all text 00:32:27 No gui at all 00:32:38 ie, x fails to load 00:32:41 * nirik isn't sure, but we don't have time to really test that as a workaround, just an idle thought. 00:32:43 huh, that's interesting. 00:32:44 I hate to say it, but I think this is a case where it's a blocker and can't be waived -- Anybody disagree with me? 00:32:55 jsmith: I'm sadly in agreement. 00:33:03 jsmith: concur 00:33:08 btw, this is another criteria clarification issue 00:33:16 we don't actually call out the 'basic video driver' function in the criteria 00:33:23 i agree that we ought to, though, and it ought to work at alpha stage. 00:33:29 +1 00:33:30 it's just too commonly needed a workaround, sadly. 00:33:31 Indeed 00:33:32 * nirik nods. 00:33:54 okay, so it looks like we have consensus that this issue ought to block release :/ 00:33:57 I tend to agree that we should make sure users can choose vesa if they need to 00:34:11 poelcat: what's your take? i know you really wanted not to slip this time, sorry :( 00:34:35 Well, it's more than just not wanting to slip 00:34:39 it doesn't influnce my judgement ;-) 00:34:43 We also need to do what we said we were going to do 00:34:43 i concur 00:34:48 i know we can tell users you have to do text/kickstart installs 00:34:50 just for clarity, qa+releng+dev representatives all voted +1 to slip 00:35:06 indeed 00:35:12 but it does limit the amount of interactive testing we would see 00:35:15 sadly so... and I think we should add this case to the critera at some point soon... 00:35:18 i wanted to ship on time AND ship according to our stated criteria... so we're doing the second half and we'll keeping trying for the first part 00:35:25 poelcat: cool. 00:35:47 poelcat: hopefully we won't have an rcs migration and two major infrastructure bumps right before f15 alpha. or f14 beta. =) 00:35:56 The idea of the release criteria is that we're making the call based on written rules, and not based on feelings 00:35:57 so, there's one more blocker right? 00:36:12 I don't think *any* of us want the schedule to slip 00:36:20 jsmith: that takes a minor hit here in that we don't actually *have* a criterion for this, but i think we're agreed that's clearly just an oversight. on my part, i suck. =) 00:36:28 adamw: no it'll be something else :) 00:36:37 okay, let's hit up the last issue 00:36:41 adamw: It's all about continual improvement. As long as we're learning and growing, it's all good 00:36:47 we should still decide if we consider that a blocker or not, as it's important for rc4 spin purposes 00:36:54 does this mean slip to the final release? or just alpha 00:37:04 tk009: yes, one week all around. 00:37:15 adamw: I'd say blocker 00:37:23 From my perspective, this release is still going fairly smoothly compared to earlier releases 00:37:24 "One week will be added to all remaining tasks in the release schedule, including the final release date." 00:37:35 #agreed 623129 should be an alpha blocker, we will propose a release criterion that the 'basic video driver' option must work at alpha stage, and this will slip the Alpha release by one week. 00:37:57 #topic https://bugzilla.redhat.com/show_bug.cgi?id=596985 00:38:07 frankly, this one's plain ugly; we just don't have enough information yet 00:38:07 .bug 596985 00:38:09 nirik: Bug 596985 hang at start of X11 on fresh install from DVD - https://bugzilla.redhat.com/show_bug.cgi?id=596985 00:38:28 mainly because every build prior to rc3 was broken enough that we just don't have enough people testing 00:38:54 adamw: so this last one is filed against the ati driver 00:39:07 but the initial reporter was using nvidia hardware 00:39:10 in the bug, we have two reporters - one with quite a lot of hardware - reporting that anaconda flat out fails to start X with the 'radeon' driver with KMS 00:39:50 dgilmore: yeah. subsequently, though, it's been focusing on radeon. the nvidia issue seems pretty clearly an anomaly, we do have several successful nvidia installs and no other reports of something like this. 00:40:03 in addition to what's in the bug, two people have reported similar trouble on test list 00:40:08 adamw: remember my issue 00:40:21 Of course, that box has an ancient card 00:40:23 chuck forsberg - http://lists.fedoraproject.org/pipermail/test/2010-August/092581.html 00:40:30 he rui - http://lists.fedoraproject.org/pipermail/test/2010-August/092583.html 00:40:35 well, if we get xdriver=vesa working then there is at least a workaround, right? 00:40:46 adamw: does he have both cards installed at the same time? 00:40:47 Indeed, I think 00:40:57 that was at nirik 00:40:59 note that the 'basic video driver' wrinkle comes in to play here; people picking 'basic video driver' in this situation are in fact getting radeon+UMS 00:41:04 nirik: yes, that's a good point 00:41:13 fixing the xdriver=vesa issue would certainly make this one less horrible 00:41:16 * Oxf13 peeks in 00:41:18 hi, oxf13 00:41:23 I have no context, thus no input, but I'm curious of the outcome 00:41:24 hey Oxf13 00:41:30 Oxf13: we've already decided to slip 00:41:31 0xf13: good evening 00:41:35 gotcha. 00:41:44 Oxf13: now we're just considering the blockeriness of 596985 00:41:57 just so long as it isn't my fault we're slipping 00:42:02 frankly i still think we don't have enough data, i'd like to try and organize an effort to have quite a few radeon users try this 00:42:09 yeah. ENODATA 00:42:10 adamw: I don't know if it would be a blocker 00:42:11 Oxf13: Absolutely not your fault 00:42:13 Oxf13: no, it's jlaska's. oh yeah, forgot to mention - jlaska said we could blame him if we slip 00:42:19 so it's all jlaska's fault 00:42:23 everyone remember to stick to that story =) 00:42:24 LOL 00:42:25 okay 00:42:26 We're not assigning blame... 00:42:32 I would say it's not a blocker if we can document it and have a workaround. 00:42:40 Indeed, my point 00:42:42 I would say move it to beta and gather more info. 00:42:49 I agree 00:42:57 nirik: i'd be uncomfortable even with a workaround if it turns out to affect all, or virtually all, radeons 00:43:09 but if it's just, say, quite a few but nowhere near all, a workaround is fine 00:43:16 The problem obviously being the workaround doesn't work 00:43:23 adamw: agreed, affecting more than a few radeons wouldn't be bad 00:43:27 would be* 00:43:31 very bad 00:43:36 worse than that typo 00:43:38 adamw: so, you would suggest leave it and gather more data, reasses when we have the fix for the other blocker in hand? 00:43:39 heh 00:44:01 nirik: right. since we're slipping we'll have another blocker bug review meeting, that would be a good time to re-assess it, and i'll try and get more people to test in the interim 00:44:10 sounds reasonable to me. +1 00:44:48 I recently got a fairly old Dell Dimension, I'll peek at its graphics card and see what model it is, and see what this madness is all aboot 00:44:52 #agreed not enough data to assess whether 596985 is a blocker, we will continue to gather data and reassess at next blocker meeting 00:45:01 :-) 00:45:17 i guess we could circle back and note which of the issues we decided weren't blockers we would consider taking fixes for in rc4 00:45:27 https://bugzilla.redhat.com/show_bug.cgi?id=621414 HD installed with anaconda 14.15 live RC3.1 CD? reverts to internal older fedora if preset on PC HD if using USB external HD install of F14 ? 00:45:29 this is a tradeoff of 'how valuable is the fix' vs. 'how badly could it screw up anything else' 00:45:46 satellit_: are you proposing that as a potential blocker bug? 00:46:15 adamw: I think all of them are things we'd like to get fixed -- but there are several that we've decided wouldn't be alpha blockers if they weren't 00:46:34 It should be looked at as you cannot have an older fedora on PC if use external usb drive for install 00:46:40 jsmith: the thing is, we try to be fairly conservative with changes between rcs 00:47:08 adamw: I agree... but that shouldn't keep us from making progress on these few identified issues 00:47:09 jsmith: if we were being very strict, we really shouldn't accept *any* changes but those necessary to fix blocker issues; that's the proper process. usually we wiggle a bit 00:47:14 satellit_: sounds like a grub issue? 00:47:25 jsmith: oh, sure, we should be trying to fix them, but the question is whether we put the fixes in rc4 or wait till after the alpha to push them. 00:47:27 I do not know 00:47:33 adamw: I'm willing to wiggle a bit, as long as we get more testing in 00:47:36 * nirik would be fine with just fixing the one blocker and checking the radeon thing at that time. 00:47:43 adamw: But that's just my personal opinion 00:47:50 sorry, we're mixing two topics here. let's go one at a time 00:47:55 #topic https://bugzilla.redhat.com/show_bug.cgi?id=621414 00:48:00 nirik: I agree 00:48:01 whatever's going wrong here, i don't think it qualifies as a blocker 00:48:06 votes? 00:48:19 adamw: so it doesn't line up w/ any criteria? 00:48:28 .bug 621414 00:48:28 poelcat: no, multiboot stuff isn't in alpha criteria. 00:48:29 nirik: Bug 621414 On boot of f14 USB HD install, with livinst, boot defaults to (internal f12 if present); f14 boot works correctly if NO HD installed in laptop - https://bugzilla.redhat.com/show_bug.cgi?id=621414 00:48:53 I'm thinking that may be a blocker 00:48:57 adamw: i thought we encountered something at the end of f13 that was going to drive some new criteria? 00:49:12 that problme with grub and windows 00:49:16 if it isn't booting, would that not block? 00:49:19 fix is to remove internal drive then get firstboot and can see drive 00:49:40 too much messing with hardware 00:49:44 poelcat: yep. we have a multiboot with windows criterion for the Final stage - https://fedoraproject.org/wiki/Fedora_14_Final_Release_Criteria "The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working " 00:49:51 satellit_: any bios boot order possible there? 00:49:54 poelcat: we don't actually have a criterion for multiboot with other fedora installs. 00:50:02 * nirik doesn't think this is a alpha blocker off hand. 00:50:02 adamw: ah, okay 00:50:11 adamw: shouldn't there be one? 00:50:15 maybe we should, but i don't think i'd put it at alpha 00:50:28 USB drive first in EeePC900 and Aseu s Aspire one 00:50:29 And we certainly don't want to add it at this stage of the game 00:50:31 although i suppose that's a relatively common way to test an alpha 00:50:33 then i agree, move this one off the f14alpha list 00:50:43 * jsmith concurs 00:50:47 poelcat: it's not on it, but since satellit_ brought it up during the meeting, it counts as proposing it 00:51:02 okay, agreed this isn't a blocker: satellit_, please move discussion of it to the bug report or another irc channel, thanks! 00:51:03 beta with it, then? 00:51:19 #agreed 621414 is not accepted as a blocker 00:51:21 okay 00:51:23 ok thanks sorry to but in...: ) 00:51:35 #topic what fixes to accept for rc4 00:51:55 Obviously the xdriv issue 00:52:04 yeah, i meant of the non-blockers 00:52:28 we have the radeon issue, tty issues, and artwork 00:52:43 adamw: the kde printer applet issue would be nice, but not sure i want to pull in that huge update set for it 00:52:44 tty wouldn't hurt, radeon we need more info 00:52:50 we can postpone this if we'd rather see how invasive the fixes are before deciding 00:52:55 just thought it'd be good to have some initial thoughts 00:53:00 adamw: artwork would be awesome to get something done 00:53:10 dgilmore: ah, yes, good one, we didn't discuss that as it's not an alpha blocker. 00:53:24 for anyone not in the loop, dgilmore is referring to https://bugzilla.redhat.com/show_bug.cgi?id=615651 00:53:36 you get a crash in kde's printer applet as soon as you run kde, with the rc3 package set 00:53:44 it's fixed in kde 4.5.0 but that's not in f14 yet 00:53:47 I still vote Alpha should have a steak 00:53:50 adamw: backporting for something that will immedietly get updated seems pointless 00:53:53 i think i'm with dgilmore in that it's too big a change to take for rc4. 00:54:08 * jsmith tends to agree 00:54:08 given that it's not an alpha blocking issue (that type of fail would block final but not alpha or beta) 00:54:12 indeed 00:55:12 * nirik nods. 00:55:20 my personal votes - i'd want to take fixes for the tty issues if we can (the fixes are both clear and small and should be trouble-free, and they're easy to test). artwork would probably be nice but it depends how much stuff we have to change. radeon issue i think depends entirely on how widespread it turns out to be, and how tricky the fix is 00:55:58 It would be nice to have a list of "almost-blockers" that wouldn't block on their own, but should get fixed, but then everybody starts trying to get their pet bugs fixed, and we lose focus 00:56:02 adamw: how much do those things reset the testing matrix? 00:56:12 poelcat: Great question! 00:56:15 adamw: so minimally we will need an anaconda fix. the rest you mentioned would be nice. 00:56:18 jsmith: yeah, we usually maintain a list but in a fairly informal way with random bug comments and in-people's-heads 00:56:27 i think thats all we should consider 00:56:28 jsmith: we should probably come up with a whiteboard field or keyword like we did for acceptedblocker 00:56:55 poelcat: we usually want to entirely reset the matrices for a new compose if it's at all practical 00:57:10 poelcat: inheriting some results from a previous compose is *always* a hack that we only do under extreme time pressure 00:57:25 There's always going to be time pressure 00:57:28 dgilmore: +1 00:57:31 * poelcat would advocate putting them on the blocker list w/ a comment explaining why it is an exception and why it is being added 00:57:41 so it's a good question, but in practice, given that we're slipping a week and it shouldn't take too long to do an rc4 compose, it's not hugely important as we should have time to redo the full matrices anyway 00:57:51 if we decide to add them, but i'd vote for as little change as possible to stay on schedule 00:58:02 * jsmith agrees with poelcat 00:58:04 Indeed 00:58:13 poelcat: i don't think that's appropriate, because the position is that we'll take a fix if it's available when we're ready to do the compose, but won't delay the compose or the release for it. so it's not a blocker 00:58:21 i think we need a different process for 'will take a fix but not blocking' bugs 00:58:38 adamw: As long as those are *very* limited in number 00:58:59 yeah, as i said, that's the goal 00:59:02 I think those should be from amoung the ones we talked about tonight or new blocker ones. 00:59:10 only. 00:59:26 agreed 00:59:32 * nirik has to go. 00:59:37 Indeed 00:59:39 yep, we're on 1 hr and we covered the important stuff 00:59:43 nirik: peace 00:59:47 the 'take a fix' questions we can do async 00:59:51 thanks nirik! 01:00:29 #agreed we will definitively decide which fixes to take later, but there's interest in taking fixes for the tty issues and artwork if they become available in time for rc4 compose 01:00:32 i know we like to cram as much in at the last minute as possible, but it also has the potential to create more headaches so i like to err on the side of less headache potential... others prefer to live more on the edge :) 01:00:48 we can maybe work on this outside of this meeting 01:00:54 #topic open floor 01:01:00 My biggest worry is that we burn out the people that make Fedora progress 01:01:04 so, any vital topics to bring up, or bugs that should be discussed that we haven't hit yet? 01:01:28 we need someone to send out slip announcement 01:01:34 jsmith: do you want to do it? 01:01:39 poelcat: I'll do it 01:02:20 #action jsmith to send slip announcement 01:02:49 oh, yeah, action items 01:02:57 #action jsmith to send slip announcement 01:03:02 (just in case it doesn't take yours, i'm not sure) 01:03:11 #action adamw to update bug reports with decisions agreed here 01:03:19 #action adamw to co-ordinate wider testing of radeon issue 01:03:34 poelcat: okay to take an action item to update the schedule? 01:03:43 absolutely 01:03:45 * j_dulaney will try to find a radeon box to test 01:04:06 dgilmore: okay to take an action item to oversee implementation of the xdriver= fix? or shall i put that down as being for clumens? 01:04:14 #action poelcat to update schedule(s) to reflect the slip 01:04:26 adamw: sure i can do that 01:04:33 #action adamw/poelcat to organize another blocker review meeting 01:04:40 adamw: i am on pto fri-mon 01:04:41 for friday? 01:04:55 poelcat: i guess, we'll discuss it outside 01:05:08 dgilmore: well, think you can do it tomorrow? =) 01:05:17 dgilmore: i'd rather have it done by the end of the week than wait for monday 01:05:31 monday means a tuesday compose, right? 01:05:44 well, late monday or tuesday, yeah. 01:05:49 That would be a long time 01:05:50 that seems way late 01:05:57 hmnm 01:06:02 if dgilmore's on pto fri-mon 01:06:08 we need someone else to do the compose 01:06:10 then that means we compose either tomorrow or tue, or someone else does the compose 01:06:18 dgilmore: has that been covered? 01:06:18 dgilmore do you have a back up? :) 01:06:34 my backup would be notting i guess 01:06:49 I could do it at night most likely 01:06:59 I have family from Oz in town 01:07:23 dgilmore: do you think it'd be feasible to get the anaconda fix in tomorrow and do an rc4 compose with that? it leaves the radeon issue hanging but we'd have a good build if we decided that wasn't a blocker 01:07:26 totally understand, i was just afraid of waiting until tuesday when we have the next gonogo meeting the following day 01:07:43 adamw: so ill do it thursday or friday night as long as we get a anaconda fix 01:07:47 and we'd have a nice early rc4 compose to get some real good testing on 01:08:04 dgilmore: okay, let's plan to try and do that, and if we hit trouble we'll sort out a fallback plan 01:08:15 dgilmore: i'll try and line up the tty fixes too so we can take those tomorrow 01:08:24 adamw: ok sounds good 01:08:54 #agreed we will try to get anaconda fix built and tested and a full compose done tomorrow to be rc4 01:09:14 dgilmore: you can throw together a boot.iso with the proposed patch in for us to test quickly, right? 01:09:50 since we can't test it with an updates.img... 01:10:15 adamw: we can get one pretty quickly 01:10:32 cool 01:10:53 okay, i think that covers things? 01:11:02 anything else? 01:11:18 * jsmith proposes we adjourn 01:11:24 agreed 01:11:26 * dgilmore seconds 01:11:29 * adamw proposes hard liquor 01:11:32 Thanks folks! 01:11:33 adamw: great job handling everything and all you've done to pull stuff together 01:11:39 I really appreciate your hard work 01:11:40 dgilmore: thanks too for a way late night last night 01:11:47 * j_dulaney is going to sit on the beach with some beer, now 01:11:48 big thanks to dgilmore for all the compose work! 01:11:51 dgilmore: That right -- go get some sleep! 01:12:02 adamw: Thanks again for updating the status on the bugs, and pushing people for updates 01:12:10 * poelcat has to run 01:12:11 * dgilmore will be sleeping soon 01:12:11 it's illegal for me to have hard liquor. 01:12:17 onekopaka_laptop: we won't tell. 01:12:17 anywhere that I know of 01:12:23 onekopaka_laptop: also, russia. 01:12:29 thanks everyone! 01:12:32 #endmeeting