00:00:58 <adamw> #startmeeting Fedora 14 Alpha Go / No-Go meeting #1
00:00:58 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
00:01:26 * nirik waves.
00:01:28 <adamw> #meetingname gonogo
00:01:28 <zodbot> The meeting name has been set to 'gonogo'
00:01:39 <adamw> note the highly optimistic topic!
00:01:45 * fenris02 smirks
00:01:47 <adamw> so, this is the go/no-go meeting for fedora 14 alpha
00:01:47 <jsmith> Aye :-)
00:01:48 <dgilmore> hola amigos
00:01:49 * tk009 watches fro the sidelines
00:02:02 <adamw> we need representatives from development, releng, and qa
00:02:07 * adamw wears a QA hat
00:02:08 <fenris02> rc3 appears to actually boot for me, so that's progress :)
00:02:12 <adamw> who wants to be development, and releng?
00:02:26 <adamw> jlaska and poelcat both send apologies, btw
00:03:03 <adamw> dgilmore: you can be rel-eng, right?
00:03:10 * nirik can try and be development I suppose.
00:03:16 <jsmith> Thanks nirik
00:03:23 * rdieter seconds dgilmore's releng nomination.
00:03:31 * jds2001 thirds it
00:03:34 <tk009> =)
00:03:36 <dgilmore> adamw: im all you have so yes
00:03:38 <jsmith> Hmmmmn... dgilmore doesn't seem to be responding
00:03:42 <jsmith> Oh, there he is!
00:03:44 <adamw> #info QA representative = adamw, releng representative = dgilmore, devel representative = nirik
00:03:59 <adamw> #info general busybody = jsmith
00:04:05 <adamw> ;)
00:04:13 * jds2001 sits in the cheap seats
00:04:14 <jds2001> :)
00:04:20 <adamw> okay, so, let's have a look where we are for the Alpha.
00:04:23 <adamw> 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 <adamw> #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 <adamw> that's the remaining blocker (and potential blocker) bugs
00:05:16 <adamw> #link https://fedoraproject.org/wiki/Test_Results:Fedora_14_Alpha_RC3_Install
00:05:20 <adamw> #link https://fedoraproject.org/wiki/Test_Results:Fedora_14_Alpha_RC3_Desktop
00:05:20 <nirik> well, they all have to be closed before we are 'go' right?
00:05:23 <jsmith> I think the most worrying thing to me is the number of bugs still in NEW state in that list
00:05:35 <adamw> those are the formal test matrices
00:05:45 <adamw> #link https://fedoraproject.org/wiki/Fedora_14_Alpha_Release_Criteria
00:05:49 <adamw> those are the release criteria.
00:05:57 <adamw> okey dokey! usually, we parse the remaining bug list
00:06:04 <adamw> any objections to doing that?
00:06:30 <nirik> sounds good.
00:06:40 <jsmith> +1 from me
00:06:41 <onekopaka_laptop> sounds good to me
00:06:42 <adamw> okay. i'm going to use a slightly idiosyncratic order to hold the really icky ones for the end
00:06:52 <j_dulaney> Sorry I'm late
00:06:58 <adamw> i went through each bug a couple hours back and put meeting talking points into them all
00:07:03 <adamw> hi, j_dulaney
00:07:12 <j_dulaney> adamw:
00:07:14 <jsmith> adamw: Thanks for updating the bugs!
00:07:24 <adamw> let's go with a couple of different bugs with similar impacts first
00:07:28 <adamw> #topic tty bugs
00:07:39 <onekopaka_laptop> there seems to be a few of those.
00:07:41 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=623102
00:07:47 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=623102
00:07:49 <adamw> grr
00:07:55 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=623430
00:07:55 <jsmith> #undo
00:08:00 * nirik notes you don't need to use #link.
00:08:01 <fenris02> where is bugbot?
00:08:08 <adamw> nirik: meh, i like being formal =)
00:08:08 <nirik> it figures those out itself. ;)
00:08:17 <nirik> .bug 623102
00:08:19 <zodbot> nirik: Bug 623102 no login prompt on tty1 - https://bugzilla.redhat.com/show_bug.cgi?id=623102
00:08:23 <nirik> .bug 623430
00:08:24 <zodbot> nirik: Bug 623430 getty on tty1 is not visible at first - https://bugzilla.redhat.com/show_bug.cgi?id=623430
00:08:49 <adamw> anyway! both these bugs relate to the availability of the default login tty after doing a console boot
00:09:19 <adamw> 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 <dgilmore> adamw: honestly as long as we have a tty the user ca egt to for alpha im ok with it
00:09:52 <adamw> 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 <adamw> 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 <jsmith> Right... both of these are edge cases where the release criteria aren't clear
00:10:22 <nirik> there is no criteria that we have currently that matches these...
00:10:39 * dgilmore thinks this needs fixed by beta
00:10:41 <adamw> 623430 happens if you have a 'normal' install and manually boot to runlevel 3 (well, multi-user.target, but never mind)
00:10:45 <dgilmore> but alpha is ok
00:10:50 <jsmith> +1 for fixed by beta
00:11:03 <adamw> 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 <onekopaka_laptop> I'll say +1 for fixed by beta
00:11:20 <adamw> 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 <nirik> I would say document in release notes and yeah, fix by beta.
00:11:47 <adamw> okay
00:11:55 <adamw> so how badly broken can alpha be before we reckon it's too bad?
00:12:03 <adamw> is the cut-off point that *some* of the default ttys are available?
00:12:26 <dgilmore> 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 <nirik> 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 <adamw> 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 <jsmith> adamw: I'd say that either ctrl-alt-f1 or ctrl-alt-f2 should get you to a prompt by alpha
00:12:50 <jsmith> adamw: Yes, that sounds good
00:12:53 <dgilmore> adamw: for alpha we must have a tty available
00:12:56 <fenris02> 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 <nirik> adamw: that sounds kinda custom tailored to this bug tho.
00:13:21 <adamw> nirik: i'm just trying to formalize what exactly we're agreeing here
00:13:41 <fenris02> if vc2 doesnt come up either, that would be a real issue.
00:13:44 <adamw> 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 <nirik> 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 <fenris02> by beta, vc1 should work.
00:14:06 <dgilmore> adamw: your proposal is acceptable
00:14:43 <j_dulaney> adam:  I concur
00:14:48 <adamw> ok
00:14:58 <adamw> nirik: yours doesn't require console mode startup to work *at all* for alpha?
00:15:13 <nirik> yeah, which seems wrong...
00:15:26 <adamw> well, i think we have a reasonable consensus from which we can start a criteria proposal at least
00:15:27 <nirik> I guess your proposal is ok...
00:15:34 <adamw> 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 <j_dulaney> indeed
00:15:50 <onekopaka_laptop> onward!
00:16:15 <adamw> #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 <adamw> okay, this one should be quite easy
00:16:40 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=623213
00:17:00 <nirik> .bug 623213
00:17:01 <zodbot> nirik: Bug 623213 Package conflicts present on F-14-Alpha-RC3 DVD - https://bugzilla.redhat.com/show_bug.cgi?id=623213
00:17:08 <adamw> this is just that systemd-sysvinit and upstart-sysvinit on the media conflict, which we have as a criterion for release
00:17:18 <adamw> but jlaska and i agree it would be reasonable to modify that somewhat
00:17:26 <dgilmore> adamw: i think intentional conflicts are ok
00:17:30 <adamw> the aim of the criterion was to ensure you couldn't get into dependency trouble making package selections during install
00:17:41 <adamw> and with this type of conflict, you can't do that
00:17:45 <jsmith> 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 <adamw> see comments #4 and #5 on the bug
00:18:28 <adamw> 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 <adamw> and by that test, this wouldn't be a blocker
00:18:48 <nirik> +1 from me.
00:18:49 <j_dulaney> I have had no problem with any isntalls regaurding that bug.
00:18:54 <jsmith> I'd go the other way -- just say that intentional conflicts are OK, and call this intentional
00:19:22 <jsmith> Otherwise, we might get into other cases of gray area
00:19:27 <adamw> 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 <jsmith> adamw: Fair enough
00:19:56 <j_dulaney> adamw:  AutoQA test for that?
00:19:59 <adamw> 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 <jsmith> Correct
00:20:09 <adamw> 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 <adamw> hey poelcat
00:20:15 <adamw> #chair poelcat
00:20:15 <zodbot> Current chairs: adamw poelcat
00:20:16 <nirik> welcome poelcat
00:20:23 * jsmith greets poelcat
00:20:36 <jsmith> poelcat: How was the dentist?
00:20:37 <j_dulaney> Howdy
00:20:52 <adamw> #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 <j_dulaney> adamw: Roger
00:21:09 <adamw> okay, onward
00:21:42 <adamw> oh, note: 620623 is on the list also because of 623213, we don't need to consider them separately
00:21:51 <adamw> whoops, that's wrong, ignore it. =)
00:22:05 <adamw> we'll do 620623 in a minute.
00:22:08 <adamw> next up:
00:22:08 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=621027
00:22:13 <nirik> .bug 621027
00:22:15 <zodbot> nirik: Bug 621027 Graphical screen in anaconda shows F-13 - https://bugzilla.redhat.com/show_bug.cgi?id=621027
00:22:32 <adamw> so, see comment #11: this is an artwork polish bug, the alpha compose uses f13 artwork in multiple places.
00:22:48 <adamw> (the desktop live has f13 background, actually, which isn't noted there)
00:22:56 <jsmith> By itself, I don't think this is enough to block
00:23:04 <adamw> 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 <j_dulaney> My yum installed desktops all have F13 artwork
00:23:11 <jsmith> 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 <poelcat> s/design/design team
00:23:35 <poelcat> though not explicitly a blocker
00:23:35 <jsmith> poelcat: I though so too... but I didn't find it on their list
00:23:45 <adamw> 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 <j_dulaney> dcr226: hi
00:23:54 <poelcat> agreed
00:23:55 <nirik> it would be very nice to have it identify that way.
00:23:58 <adamw> personally i'd want to start worrying about artwork at beta stage
00:24:03 <jsmith> mizmo attached a generic splash screen to that bug
00:24:03 <nirik> but I don't think it's a blocker.
00:24:06 <adamw> though it would be nice to have alphas identified as such, yes
00:24:18 <jsmith> I suggested we automate the mangling of the SVG to automagically put the current release number in it
00:24:24 <poelcat> we can work on refining this outside of this meeting
00:24:26 <j_dulaney> I don't see any reason to have art block alpha, as alpha is more for testing
00:24:32 <jsmith> That way, we're not depending on a manual process of "create new artwork" every time
00:24:36 <adamw> 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 <j_dulaney> jsmith: sounds good
00:24:50 <nirik> it could be something generic, like a dancing hot dog. ;)
00:24:54 <jsmith> Exactly!
00:24:56 <j_dulaney> LOL
00:25:03 <adamw> 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 <jsmith> j_dulaney: You obviously haven't seen the hot dog
00:25:07 * j_dulaney votes for a steak
00:25:14 <poelcat> adamw: yes
00:25:15 <jsmith> adamw: Yes,
00:25:17 <dgilmore> adamw: yeah
00:25:22 <adamw> nirik: ?
00:25:23 <j_dulaney> adamw: indeed
00:25:24 <nirik> yep
00:25:26 <poelcat> it needs some official public soak time
00:25:26 <adamw> great
00:25:34 <jsmith> Onward!
00:25:44 <adamw> #agreed broad consensus that artwork criteria should kick in at beta stage, this bug should not block alpha
00:25:58 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=620623
00:26:00 <poelcat> is there an #action to update the criteria?
00:26:01 <adamw> okay, this is the last of the easy ones =)
00:26:07 <nirik> .bug 620623
00:26:09 <zodbot> nirik: Bug 620623 Packages with unresolved dependencies - https://bugzilla.redhat.com/show_bug.cgi?id=620623
00:26:27 <adamw> 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 <j_dulaney> adamw:  should we make the artwork thing a permanent beta criteria?
00:26:37 <jsmith> It looks like this one has been resolved, right?
00:26:40 <adamw> this one is basically fixed for rc3
00:26:46 <jsmith> Any reason not to take it off the blocker list?
00:26:50 <adamw> i just wasn't sure whether bill wanted the bug closed or just taken off teh blocker list
00:27:07 <jsmith> I'd say close it, if the problem has been resolved.
00:27:10 <nirik> well, it's fixed, so close?
00:27:10 * j_dulaney hasn't had unresolved python problems in a while
00:27:11 <jsmith> If it's a problem, he can re-open
00:27:14 <adamw> ok
00:27:22 <dgilmore> adamw: its fixed close it
00:27:40 <adamw> #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 <j_dulaney> adamw: indeed
00:28:01 <adamw> alright, those were all the ones i expected probably not to be a problem
00:28:02 <jsmith> Now on to the more difficult ones
00:28:05 <adamw> now we're onto the tricky ones =)
00:28:24 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=623129
00:28:39 <nirik> .bug 623129
00:28:40 <zodbot> nirik: Bug 623129 xdriver=vesa is not honored - https://bugzilla.redhat.com/show_bug.cgi?id=623129
00:28:51 <adamw> pretty simple bug: the xdriver= parameter which should instruct anaconda to use a particular video driver just isn't used
00:28:56 <j_dulaney> bug I've had
00:28:59 <adamw> (i'm 99% sure it doesn't work in live either, but haven't had time to test it yet)
00:29:14 <j_dulaney> It doesn't work with yum update
00:29:16 <adamw> 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 <adamw> 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 <nirik> yeah. :(
00:29:59 <adamw> so in those cases you actually *do* get vesa
00:30:00 * jsmith doesn't like this
00:30:11 <adamw> but it doesn't work with radeon, or any of the older, more niche drivers
00:30:27 <adamw> 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 <jsmith> Aye
00:30:50 <adamw> the other problem is there is just no practical workaround for this
00:30:57 <jsmith> Correct
00:30:57 <adamw> we can't ship an updates.img even if we'd consider that, as the bug is too early
00:31:14 <nirik> so this needs an anaconda fix?
00:31:20 <jsmith> So, I'm gonna be the one to say it -- I think this means we slip a week
00:31:21 <adamw> 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 <adamw> nirik: yes, there's a proposed patch in the bug
00:31:47 <adamw> 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 <adamw> nirik: i think not - X winds up loading it for you in that case, iirc.
00:32:08 <j_dulaney> nirik:  no
00:32:22 <j_dulaney> it goes all text
00:32:27 <j_dulaney> No gui at all
00:32:38 <j_dulaney> 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 <adamw> huh, that's interesting.
00:32:44 <jsmith> 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 <nirik> jsmith: I'm sadly in agreement.
00:33:03 <j_dulaney> jsmith:  concur
00:33:08 <adamw> btw, this is another criteria clarification issue
00:33:16 <adamw> we don't actually call out the 'basic video driver' function in the criteria
00:33:23 <adamw> i agree that we ought to, though, and it ought to work at alpha stage.
00:33:29 <jsmith> +1
00:33:30 <adamw> it's just too commonly needed a workaround, sadly.
00:33:31 <j_dulaney> Indeed
00:33:32 * nirik nods.
00:33:54 <adamw> okay, so it looks like we have consensus that this issue ought to block release :/
00:33:57 <dgilmore> I tend to agree that we should make sure  users can choose vesa if they need to
00:34:11 <adamw> poelcat: what's your take? i know you really wanted not to slip this time, sorry :(
00:34:35 <jsmith> Well, it's more than just not wanting to slip
00:34:39 <poelcat> it doesn't influnce my judgement ;-)
00:34:43 <jsmith> We also need to do what we said we were going to do
00:34:43 <poelcat> i concur
00:34:48 <dgilmore> i know we can tell users you have to do text/kickstart installs
00:34:50 <adamw> just for clarity, qa+releng+dev representatives all voted +1 to slip
00:35:06 <j_dulaney> indeed
00:35:12 <dgilmore> but it does limit the amount of interactive testing we would see
00:35:15 <nirik> sadly so... and I think we should add this case to the critera at some point soon...
00:35:18 <poelcat> 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 <adamw> poelcat: cool.
00:35:47 <adamw> poelcat: hopefully we won't have an rcs migration and two major infrastructure bumps right before f15 alpha. or f14 beta. =)
00:35:56 <jsmith> 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 <nirik> so, there's one more blocker right?
00:36:12 <jsmith> I don't think *any* of us want the schedule to slip
00:36:20 <adamw> 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 <poelcat> adamw: no it'll be something else :)
00:36:37 <adamw> okay, let's hit up the last issue
00:36:41 <jsmith> adamw: It's all about continual improvement.  As long as we're learning and growing, it's all good
00:36:47 <adamw> we should still decide if we consider that a blocker or not, as it's important for rc4 spin purposes
00:36:54 <tk009> does this mean slip to the final release? or just alpha
00:37:04 <nirik> tk009: yes, one week all around.
00:37:15 <j_dulaney> adamw:  I'd say blocker
00:37:23 <jsmith> From my perspective, this release is still going fairly smoothly compared to earlier releases
00:37:24 <nirik> "One week will be added to all remaining tasks in the release schedule, including the final release date."
00:37:35 <adamw> #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 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=596985
00:38:07 <adamw> frankly, this one's plain ugly; we just don't have enough information yet
00:38:07 <nirik> .bug 596985
00:38:09 <zodbot> 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 <adamw> mainly because every build prior to rc3 was broken enough that we just don't have enough people testing
00:38:54 <dgilmore> adamw: so this last one is filed against the ati driver
00:39:07 <dgilmore> but the initial reporter was using nvidia hardware
00:39:10 <adamw> 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 <adamw> 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 <adamw> in addition to what's in the bug, two people have reported similar trouble on test list
00:40:08 <j_dulaney> adamw:  remember my issue
00:40:21 <j_dulaney> Of course, that box has an ancient card
00:40:23 <adamw> chuck forsberg - http://lists.fedoraproject.org/pipermail/test/2010-August/092581.html
00:40:30 <adamw> he rui - http://lists.fedoraproject.org/pipermail/test/2010-August/092583.html
00:40:35 <nirik> well, if we get xdriver=vesa working then there is at least a workaround, right?
00:40:46 <dgilmore> adamw: does he have both cards installed at the same time?
00:40:47 <j_dulaney> Indeed, I think
00:40:57 <j_dulaney> that was at nirik
00:40:59 <adamw> 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 <adamw> nirik: yes, that's a good point
00:41:13 <adamw> fixing the xdriver=vesa issue would certainly make this one less horrible
00:41:16 * Oxf13 peeks in
00:41:18 <adamw> hi, oxf13
00:41:23 <Oxf13> I have no context, thus no input, but I'm curious of the outcome
00:41:24 <dgilmore> hey Oxf13
00:41:30 <adamw> Oxf13: we've already decided to slip
00:41:31 <j_dulaney> 0xf13:  good evening
00:41:35 <Oxf13> gotcha.
00:41:44 <adamw> Oxf13: now we're just considering the blockeriness of 596985
00:41:57 <Oxf13> just so long as it isn't my fault we're slipping
00:42:02 <adamw> 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 <nirik> yeah. ENODATA
00:42:10 <j_dulaney> adamw: I don't know if it would be a blocker
00:42:11 <jsmith> Oxf13: Absolutely not your fault
00:42:13 <adamw> Oxf13: no, it's jlaska's. oh yeah, forgot to mention - jlaska said we could blame him if we slip
00:42:19 <adamw> so it's all jlaska's fault
00:42:23 <adamw> everyone remember to stick to that story =)
00:42:24 <j_dulaney> LOL
00:42:25 <onekopaka_laptop> okay
00:42:26 <jsmith> We're not assigning blame...
00:42:32 <nirik> I would say it's not a blocker if we can document it and have a workaround.
00:42:40 <j_dulaney> Indeed, my point
00:42:42 <nirik> I would say move it to beta and gather more info.
00:42:49 <j_dulaney> I agree
00:42:57 <adamw> nirik: i'd be uncomfortable even with a workaround if it turns out to affect all, or virtually all, radeons
00:43:09 <adamw> but if it's just, say, quite a few but nowhere near all, a workaround is fine
00:43:16 <j_dulaney> The problem obviously being the workaround doesn't work
00:43:23 <onekopaka_laptop> adamw: agreed, affecting more than a few radeons wouldn't be bad
00:43:27 <onekopaka_laptop> would be*
00:43:31 <onekopaka_laptop> very bad
00:43:36 <onekopaka_laptop> worse than that typo
00:43:38 <nirik> 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 <adamw> heh
00:44:01 <adamw> 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 <nirik> sounds reasonable to me. +1
00:44:48 <onekopaka_laptop> 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 <adamw> #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 <jsmith> :-)
00:45:17 <adamw> 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 <satellit_> 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 <adamw> this is a tradeoff of 'how valuable is the fix' vs. 'how badly could it screw up anything else'
00:45:46 <adamw> satellit_: are you proposing that as a potential blocker bug?
00:46:15 <jsmith> 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 <satellit_> It should be looked at as you cannot have an older fedora on PC if use external usb drive for install
00:46:40 <adamw> jsmith: the thing is, we try to be fairly conservative with changes between rcs
00:47:08 <jsmith> adamw: I agree... but that shouldn't keep us from making progress on these few identified issues
00:47:09 <adamw> 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 <j_dulaney> satellit_: sounds like a grub issue?
00:47:25 <adamw> 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 <satellit_> I do not know
00:47:33 <jsmith> 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 <jsmith> adamw: But that's just my personal opinion
00:47:50 <adamw> sorry, we're mixing two topics here. let's go one at a time
00:47:55 <adamw> #topic https://bugzilla.redhat.com/show_bug.cgi?id=621414
00:48:00 <j_dulaney> nirik: I agree
00:48:01 <adamw> whatever's going wrong here, i don't think it qualifies as a blocker
00:48:06 <adamw> votes?
00:48:19 <poelcat> adamw: so it doesn't line up w/ any criteria?
00:48:28 <nirik> .bug 621414
00:48:28 <adamw> poelcat: no, multiboot stuff isn't in alpha criteria.
00:48:29 <zodbot> 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 <j_dulaney> I'm thinking that may be a blocker
00:48:57 <poelcat> adamw: i thought we encountered something at the end of f13 that was going to drive some new criteria?
00:49:12 <poelcat> that problme with grub and windows
00:49:16 <j_dulaney> if it isn't booting, would that not block?
00:49:19 <satellit_> fix is to remove internal drive then get firstboot and can see drive
00:49:40 <j_dulaney> too much messing with hardware
00:49:44 <adamw> 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 <nirik> satellit_: any bios boot order possible there?
00:49:54 <adamw> 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 <poelcat> adamw: ah, okay
00:50:11 <j_dulaney> adamw:  shouldn't there be one?
00:50:15 <adamw> maybe we should, but i don't think i'd put it at alpha
00:50:28 <satellit_> USB drive first in EeePC900 and Aseu s Aspire one
00:50:29 <jsmith> And we certainly don't want to add it at this stage of the game
00:50:31 <adamw> although i suppose that's a relatively common way to test an alpha
00:50:33 <poelcat> then i agree, move this one off the f14alpha list
00:50:43 * jsmith concurs
00:50:47 <adamw> poelcat: it's not on it, but since satellit_ brought it up during the meeting, it counts as proposing it
00:51:02 <adamw> 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 <j_dulaney> beta with it, then?
00:51:19 <adamw> #agreed 621414 is not accepted as a blocker
00:51:21 <adamw> okay
00:51:23 <satellit_> ok thanks sorry to but in...: )
00:51:35 <adamw> #topic what fixes to accept for rc4
00:51:55 <j_dulaney> Obviously the xdriv issue
00:52:04 <adamw> yeah, i meant of the non-blockers
00:52:28 <adamw> we have the radeon issue, tty issues, and artwork
00:52:43 <dgilmore> 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 <j_dulaney> tty wouldn't hurt, radeon we need more info
00:52:50 <adamw> we can postpone this if we'd rather see how invasive the fixes are before deciding
00:52:55 <adamw> just thought it'd be good to have some initial thoughts
00:53:00 <dgilmore> adamw: artwork  would be awesome to get something done
00:53:10 <adamw> dgilmore: ah, yes, good one, we didn't discuss that as it's not an alpha blocker.
00:53:24 <adamw> for anyone not in the loop, dgilmore is referring to https://bugzilla.redhat.com/show_bug.cgi?id=615651
00:53:36 <adamw> you get a crash in kde's printer applet as soon as you run kde, with the rc3 package set
00:53:44 <adamw> it's fixed in kde 4.5.0 but that's not in f14 yet
00:53:47 <j_dulaney> I still vote Alpha should have a steak
00:53:50 <dgilmore> adamw: backporting for something that will immedietly get updated seems pointless
00:53:53 <adamw> 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 <adamw> given that it's not an alpha blocking issue (that type of fail would block final but not alpha or beta)
00:54:12 <j_dulaney> indeed
00:55:12 * nirik nods.
00:55:20 <adamw> 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 <jsmith> 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 <poelcat> adamw: how much do those things reset the testing matrix?
00:56:12 <jsmith> poelcat: Great question!
00:56:15 <dgilmore> adamw: so minimally we will need an anaconda fix.  the rest you mentioned would be nice.
00:56:18 <adamw> 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 <dgilmore> i think thats all we should consider
00:56:28 <adamw> jsmith: we should probably come up with a whiteboard field or keyword like we did for acceptedblocker
00:56:55 <adamw> poelcat: we usually want to entirely reset the matrices for a new compose if it's at all practical
00:57:10 <adamw> poelcat: inheriting some results from a previous compose is *always* a hack that we only do under extreme time pressure
00:57:25 <jsmith> There's always going to be time pressure
00:57:28 <nirik> 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 <adamw> 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 <poelcat> 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 <j_dulaney> Indeed
00:58:13 <adamw> 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 <adamw> i think we need a different process for 'will take a fix but not blocking' bugs
00:58:38 <jsmith> adamw: As long as those are *very* limited in number
00:58:59 <adamw> yeah, as i said, that's the goal
00:59:02 <nirik> I think those should be from amoung the ones we talked about tonight or new blocker ones.
00:59:10 <nirik> only.
00:59:26 <adamw> agreed
00:59:32 * nirik has to go.
00:59:37 <j_dulaney> Indeed
00:59:39 <adamw> yep, we're on 1 hr and we covered the important stuff
00:59:43 <j_dulaney> nirik:  peace
00:59:47 <adamw> the 'take a fix' questions we can do async
00:59:51 <adamw> thanks nirik!
01:00:29 <adamw> #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 <poelcat> 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 <poelcat> we can maybe work on this outside of this meeting
01:00:54 <adamw> #topic open floor
01:01:00 <jsmith> My biggest worry is that we burn out the people that make Fedora progress
01:01:04 <adamw> so, any vital topics to bring up, or bugs that should be discussed that we haven't hit yet?
01:01:28 <poelcat> we need someone to send out slip announcement
01:01:34 <poelcat> jsmith: do you want to do it?
01:01:39 <jsmith> poelcat: I'll do it
01:02:20 <jsmith> #action jsmith to send slip announcement
01:02:49 <adamw> oh, yeah, action items
01:02:57 <adamw> #action jsmith to send slip announcement
01:03:02 <adamw> (just in case it doesn't take yours, i'm not sure)
01:03:11 <adamw> #action adamw to update bug reports with decisions agreed here
01:03:19 <adamw> #action adamw to co-ordinate wider testing of radeon issue
01:03:34 <adamw> poelcat: okay to take an action item to update the schedule?
01:03:43 <poelcat> absolutely
01:03:45 * j_dulaney will try to find a radeon box to test
01:04:06 <adamw> 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 <adamw> #action poelcat to update schedule(s) to reflect the slip
01:04:26 <dgilmore> adamw: sure i can do that
01:04:33 <adamw> #action adamw/poelcat to organize another blocker review meeting
01:04:40 <dgilmore> adamw: i am on pto fri-mon
01:04:41 <poelcat> for friday?
01:04:55 <adamw> poelcat: i guess, we'll discuss it outside
01:05:08 <adamw> dgilmore: well, think you can do it tomorrow? =)
01:05:17 <adamw> dgilmore: i'd rather have it done by the end of the week than wait for monday
01:05:31 <poelcat> monday means a tuesday compose, right?
01:05:44 <adamw> well, late monday or tuesday, yeah.
01:05:49 <j_dulaney> That would be a long time
01:05:50 <poelcat> that seems way late
01:05:57 <adamw> hmnm
01:06:02 <adamw> if dgilmore's on pto fri-mon
01:06:08 <poelcat> we need someone else to do the compose
01:06:10 <adamw> then that means we compose either tomorrow or tue, or someone else does the compose
01:06:18 <adamw> dgilmore: has that been covered?
01:06:18 <poelcat> dgilmore do you have a back up? :)
01:06:34 <dgilmore> my backup would be notting i guess
01:06:49 <dgilmore> I could do it at night most likely
01:06:59 <dgilmore> I have family from Oz in town
01:07:23 <adamw> 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 <poelcat> totally understand, i was just afraid of waiting until tuesday when we have the next gonogo meeting the following day
01:07:43 <dgilmore> adamw: so ill do it thursday or friday night as long as we get a anaconda fix
01:07:47 <adamw> and we'd have a nice early rc4 compose to get some real good testing on
01:08:04 <adamw> 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 <adamw> dgilmore: i'll try and line up the tty fixes too so we can take those tomorrow
01:08:24 <dgilmore> adamw: ok sounds good
01:08:54 <adamw> #agreed we will try to get anaconda fix built and tested and a full compose done tomorrow to be rc4
01:09:14 <adamw> dgilmore: you can throw together a boot.iso with the proposed patch in for us to test quickly, right?
01:09:50 <adamw> since we can't test it with an updates.img...
01:10:15 <dgilmore> adamw: we can get one pretty quickly
01:10:32 <adamw> cool
01:10:53 <adamw> okay, i think that covers things?
01:11:02 <adamw> anything else?
01:11:18 * jsmith proposes we adjourn
01:11:24 <j_dulaney> agreed
01:11:26 * dgilmore seconds
01:11:29 * adamw proposes hard liquor
01:11:32 <jsmith> Thanks folks!
01:11:33 <poelcat> adamw: great job handling everything and all you've done to pull stuff together
01:11:39 <jsmith> I really appreciate your hard work
01:11:40 <poelcat> 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 <adamw> big thanks to dgilmore for all the compose work!
01:11:51 <jsmith> dgilmore: That right -- go get some sleep!
01:12:02 <jsmith> 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 <onekopaka_laptop> it's illegal for me to have hard liquor.
01:12:17 <adamw> onekopaka_laptop: we won't tell.
01:12:17 <onekopaka_laptop> anywhere that I know of
01:12:23 <adamw> onekopaka_laptop: also, russia.
01:12:29 <adamw> thanks everyone!
01:12:32 <adamw> #endmeeting