15:00:51 <adamw> #startmeeting Fedora QA meeting
15:00:51 <zodbot> Meeting started Mon Apr  2 15:00:51 2012 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:51 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:57 <adamw> #meetingname fedora-qa
15:00:57 <zodbot> The meeting name has been set to 'fedora-qa'
15:01:03 <adamw> #topic roll call
15:01:25 * adamw calls some rolls
15:01:29 * brunowolff is here
15:01:32 * mkrizek present
15:01:33 * jskladan jumps and waves
15:01:42 * j_dulaney like rolls
15:01:46 <adamw> bacon, swiss, jam...
15:01:52 <j_dulaney> Mmm
15:01:53 <j_dulaney> .bacon
15:01:53 <zodbot> I love bacon, you love bacon, WE ALL LOVE BACON!! (except for NiveusLuna, who was tragically attacked by bacon as a child.)
15:02:23 * tflink is here
15:02:40 * tflink does not understand this obsession w/ bacon, though
15:02:56 <j_dulaney> Bacon = Awesome
15:03:08 * adamw isn't sure about the existence of beef rolls
15:03:13 * j_dulaney thanks tflink for giving me his bacon at FUDcon
15:03:43 <tflink> j_dulaney: only because you assigned it that value :-P
15:03:49 * kparal arrives
15:04:27 <j_dulaney> tflink:  It is an explosion of amazing tastyness in my mouth
15:05:09 <adamw> #topic previous meeting follow-up
15:05:15 <adamw> let's get started!
15:05:34 <adamw> "kparal to propose revised criteria to cover split installs (installer sourced from one repo, packages from internet repos)" - kparal, guess you were too busy for that?
15:05:46 <kparal> erm
15:05:59 <kparal> not done
15:06:33 <kparal> but did we receive the new description of what anaconda should and shouldn't be capable of?
15:06:46 <kparal> wwoods' action item
15:06:57 <adamw> i'm not sure we got it in a formal manner, but i think all the info is there in the bug...
15:07:29 <kparal> ok, so, I'll propose it this week
15:07:33 <adamw> #info kparal did not yet get a chance to propose split installation release criteria
15:07:48 <adamw> "wwoods to ensure anaconda docs are updated to reflect what repo= is supposed to be capable of"
15:08:09 * adamw attaches a bottle of gin to a string and dangles it in front of wwoods
15:09:12 <j_dulaney> adamw:  You have to use something weird to get his interest
15:09:26 <tflink> is he still on PTO?
15:09:45 <adamw> i guess he's in some sort of paralytic coma. again. that's just five minutes behind his personal weekly paralytic coma record!
15:09:49 <adamw> tflink: possibly, not sure
15:11:15 <adamw> #info wwoods not around to report on status of his action item
15:11:27 <adamw> #topic Fedora 17 Beta status / blocker review
15:11:43 <adamw> well, unfortunately we still haven't been able to spin an RC3 :( unaddressed blockers remain.
15:11:51 <adamw> #info we still haven't been able to spin an RC3 :( unaddressed blockers remain.
15:12:01 * j_dulaney is a sad panda
15:12:36 <tflink> wasn't there a fix for the libvirt issue over the weekend? Or did we already remove boxes from comps?
15:12:45 <adamw> #info on the good side, we have pretty good RC2 test coverage, just a couple of tests remain, we can knock those off today
15:12:48 <adamw> tflink: yes, and yes
15:13:05 <adamw> tflink: but we have an anaconda bug that breaks kickstart, still
15:13:15 <adamw> and two new proposed blockers
15:13:40 <adamw> so, let's do a quick review of those two blockers...
15:13:59 <adamw> #topic Fedora 17 blocker review: http://bugzilla.redhat.com/show_bug.cgi?id=807510
15:14:32 <tflink> sounds like a blocker if its still a problem
15:14:51 <adamw> i was actually going to vote not a blocker, on the basis of obscure hardware
15:15:07 <tflink> LSI MegaRaid is obscure HW?
15:15:09 <j_dulaney> bugzilla being slow this morning
15:15:23 <brunowolff> This could still be a hardware issue even though it works with RHEL6.
15:15:43 <tflink> and F16
15:15:51 * tflink has a box that is almost identical
15:16:09 <brunowolff> F16 and F17 are both using 3.3 kernels and it could be a kernel bug.
15:16:16 <adamw> tflink: eh.
15:16:22 <adamw> you just have to make things difficult.
15:16:34 <brunowolff> Or were you saying it worked on F16?
15:16:35 <tflink> tis' one of my goals in life :)
15:16:35 <adamw> brunowolff: 16 would not be using a 3.3 kernel at install time.
15:16:39 <adamw> and it works on f16.
15:16:46 <adamw> the thing is, this was tested on beta rc
15:16:47 <tflink> brunowolff: I'm running almost the same HW with F16
15:16:47 <adamw> rc1
15:16:52 <adamw> so it could just be the missing modules stuff
15:17:02 <adamw> tflink: have you tried 17 with it?
15:17:13 <tflink> adamw: nope
15:17:19 * j_dulaney is leaning +1 blocker
15:18:33 <adamw> i think it might  be nice to know what's broken and if it's broken in rc2.
15:18:42 <VICODAN> sup
15:18:43 <tflink> I can look into it, but that box is in a RH lab which limits some of the stuff I can do with it
15:18:51 <adamw> and it might be nice to have more than one tester, so...*looks at the guy with the megaraid*
15:18:51 <VICODAN> still having the qa meeting?
15:18:54 <adamw> yes
15:18:58 <VICODAN> sweet i made it finally
15:19:04 <VICODAN> can someone catch me up?
15:19:05 <VICODAN> sorry
15:19:26 <Southern_Gentlem> tflink, spin up a updated f16 live and see if it sees the raid
15:19:26 <VICODAN> we reviewing the blocker?
15:19:27 <tflink> VICODAN: not much has happened, just doing a mini blocker-review ATM
15:19:31 <VICODAN> got it
15:19:52 <tflink> Southern_Gentlem: that might be harder than re-installing given the environment the machine is in
15:20:03 * tflink will look into it, though
15:20:12 <Southern_Gentlem> tflink,  tht way there is no installing
15:20:23 <adamw> tflink: it seems simpler to me just to do a 17 install.
15:20:29 <tflink> Southern_Gentlem: assuming that I have a way to actually boot the live, sure
15:20:31 <adamw> Southern_Gentlem: but it's remote hardware. makes it tricky to boot a live.
15:20:55 <tflink> I wonder if adamw is on the right track about modules
15:21:07 <tflink> we already know there were missing dracut modules from RC1
15:21:09 <VICODAN> upgrading via dvd worked fine
15:21:19 <Southern_Gentlem> adamw,  that would show if it was a kernel isssue
15:21:22 <VICODAN> preupgrade was where i had problems, have we fixed that?
15:21:37 <tflink> I'll look into it, though. it'll take some time for me to get everything off of that machine that I need before reinstalling
15:21:53 <VICODAN> also has anyone looked at rescue mode?
15:22:16 <adamw> no, and yes.
15:22:32 <VICODAN> i couldn't really do much with rescue mode
15:22:43 <adamw> tflink: i'd be less worried if the reporter had re-tested by now. :/
15:22:44 <VICODAN> it actually warns about a lot of things it uses are deprecated
15:23:03 <adamw> can we stick to discussing one bug at a time?
15:23:07 <VICODAN> sure
15:23:11 <adamw> things get messy otherwise. thanks.
15:23:16 <tflink> sounds like we're leaning towards needing more info, though
15:23:50 <adamw> well, if anyone feels confident enough to vote at present, they can. whether it's fixed in rc2 isn't strictly relevant to whether it's a blocker (though it might tell us more about what the problem is).
15:24:34 <tflink> if it _is_ just limited to IBM machines, I'd be inclined to say not a beta blocker
15:24:41 <brunowolff> Do we have to delay an RC build if we vote blocker, but don't have a good way to test if the issue is fixed?
15:24:46 <tflink> final blocker, yes. beta blocker, no
15:24:54 <adamw> propose #agreed we need more testing and detail on this bug to determine blocker status, tflink will try on a system he has access to with a megaraid
15:24:55 <VICODAN> talking about 807510?
15:25:00 <brunowolff> Can we vote blocker, but think it may have been fixed in RC2?
15:25:12 <tflink> if it's all HW raid or even just all LSI cards, I'm more inclined to say beta blocker
15:25:17 <tflink> VICODAN: yep
15:25:20 <adamw> brunowolff: it would require someone to stick their necks out and say so in the bug, but yeah.
15:25:25 <VICODAN> not a beta blocker.
15:25:44 <adamw> tflink: i haven't tested hw raid yet, but 'regular' consumer hw raid doesn't work like megaraid is described as working.
15:26:10 <adamw> tflink: you don't have to go into Advanced Storage Devices and pick it. you just do a perfectly normal install to /dev/sda, which is what a 'regular' hardware RAID controller shows up as. mine, anyway.
15:26:28 <tflink> adamw: one of these days, I really need to sit down and figure out the difference between all these raid controllers
15:26:35 <VICODAN> it shouldn't even be an issue. you don't need drivers for hardware raid IIRC
15:26:42 <adamw> that, or make a nice bonfire out of them.
15:26:52 <tflink> adamw: that's how my megaraid works, I'm not sure why the tester is using advanced storage
15:26:53 <adamw> VICODAN: that's the case i described. megaraid is, apparently, different.
15:27:00 <adamw> tflink: hum, maybe it's testing error?
15:27:01 <VICODAN> doubtful
15:27:06 <VICODAN> pebcak
15:27:21 <adamw> still, advanced storage devices doesn't just display crap at random
15:27:26 <tflink> all of the LUN handling is done in BIOS or in the card's interface
15:27:31 <VICODAN> ^^
15:27:31 <tflink> depending on the system
15:27:40 <VICODAN> HW raid just presents a drive
15:27:50 <VICODAN> you just partition it as normal
15:27:51 <adamw> VICODAN: we know.
15:27:53 <tflink> from a high level, yes
15:27:59 <VICODAN> yep
15:28:05 <tflink> however, there are kernel modules for HW raid cards
15:28:14 <VICODAN> right
15:28:25 <tflink> so we're back to "needs more testing"
15:28:30 * tflink votes that we move on
15:28:32 <VICODAN> but it's not a betablocker
15:28:38 <tflink> yes, it is
15:28:49 <VICODAN> why is that?
15:29:00 <brunowolff> I'm inclined to vote -1 beta blocker now. If this is reproduced with RC2 or later and is affecting all megaraid devices, I'd change to +1.
15:29:01 <VICODAN> how many people would this affect?
15:29:41 <VICODAN> im with bruno
15:29:42 <tflink> VICODAN: beta release criteria #8 - "The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot"
15:29:45 * j_dulaney is still leaning +1 blocker, but votes NEEDINFO
15:29:49 <adamw> propose #agreed more information needed on #807510 to reach a determination of blocker status, tflink will test with his similar hardware
15:29:54 <j_dulaney> ack
15:29:55 <tflink> ack
15:30:04 <VICODAN> tflink: yeah but this is a very rare case and hasn't been proven
15:30:14 <brunowolff> ack
15:30:19 <tflink> VICODAN: data to back that statement up?
15:30:21 <adamw> #agreed more information needed on #807510 to reach a determination of blocker status, tflink will test with his similar hardware
15:30:27 <adamw> that's enough, let's move on, guys.
15:30:31 <tflink> +1
15:30:32 <VICODAN> im just going to agree with adam
15:30:47 <adamw> #topci Fedora 17 blocker review: http://bugzilla.redhat.com/show_bug.cgi?id=808029
15:30:49 <adamw> gr
15:30:52 <adamw> #topic Fedora 17 blocker review: http://bugzilla.redhat.com/show_bug.cgi?id=808029
15:31:21 <adamw> this seems pretty straightforward +1 on the criteria.
15:31:28 <tflink> agreed
15:31:32 <tflink> +1 blocker
15:31:33 <adamw> since my plan to change that criterion didn't pan out. le sigh
15:31:36 <kparal> +1
15:31:43 <VICODAN> +1
15:32:01 <j_dulaney> +1
15:32:18 <adamw> actually, hold that thought
15:32:40 <VICODAN> eh
15:32:56 <adamw> https://lists.fedoraproject.org/pipermail/test/2011-November/104481.html has three +1 replies
15:33:07 <adamw> which is really pretty solid consensus for changing the criteria. i just never got around to doing it
15:33:19 <adamw> so alternative would be to go ahead and implement that criteria change, and make this final blocker rather than beta.
15:33:46 <VICODAN> +1 to that that sounds reasonable.
15:33:49 <tflink> I could go either way
15:34:00 <kparal> is kickstart injection into initrd so unusual?
15:34:30 <kparal> that allows Beta to be broken with virt-install --initrd-inject ks.cfg
15:34:39 <j_dulaney> +1
15:34:39 <brunowolff> This sounds reasonable. Enough is guaranteed to work to test kickstarts at Beta.
15:35:31 <VICODAN> hm i mean I could see why it would be a BETA blocker but at the same time it's a beta, not everything is guaranteed to work
15:35:59 <kparal> I just wonder, because --initrd-inject is the easiest approach possible
15:36:11 <j_dulaney> Indeed
15:36:12 <kparal> no http hosting, no nfs hosting
15:36:18 <VICODAN> it would definitely make more sense to have it as a final blocker
15:36:19 <adamw> god, i hate virt-install.
15:36:38 * j_dulaney is growing to like it
15:36:39 <kparal> we can have it final, I just question "unusual" :)
15:36:40 <pjones> adamw: btw, see https://bugzilla.redhat.com/show_bug.cgi?id=807510#c10 .  I think #807510 may be NOTABUG rather than blocker
15:37:30 <pjones> adamw: and I find it very unlikely that it has anything to do with megaraid or whatnot
15:37:33 <VICODAN> usual/unusual, it doesn't matter, this isn't RHEL how many people are deploying a hundred fedora beta boxes via kickstart?
15:38:05 * j_dulaney raises his hand
15:38:05 <adamw> pjones: yeah, thanks
15:38:15 <j_dulaney> Maybe no a hundred, but quite a few
15:38:20 <j_dulaney> In VMs
15:38:22 <VICODAN> j_dulaney: for business purposes? and why?
15:38:28 <adamw> can we please avoid sidetracks?
15:38:29 <kparal> there a push for exactly that inside RH
15:38:42 <VICODAN> ok
15:38:42 <adamw> lots of people use kickstarts, the question here is the importance of this specific kickstart deployment method at beta
15:39:11 <j_dulaney> Well, if the criterion was voted to be moved, I'll go with that.
15:39:11 <VICODAN> im indifferent on this issue, I personally am leaning towards final blocker
15:39:30 <adamw> prior to virt-install, the best use case i'd seen cited for initrd injection was indeed the case where you're deploying hundreds of identical installs from a single image, and that seems highly unlikely to be needed *at beta stage*
15:39:44 <adamw> but virt-install does seem like a pretty interesting case which hadn't been cited before
15:39:46 <VICODAN> that's exactly my point
15:39:57 <adamw> right, but we'd been over it before
15:40:02 <adamw> prior to the proposal being made
15:40:05 <VICODAN> it should definitely get fixed, but i dont think it's required to for a beta releasse
15:40:15 <adamw> the new case that hadn't been considered before is virt-install. which is a more sensible thing to use at beta.
15:40:57 <adamw> it makes me less convinced about the proposal, is my point...
15:41:21 <VICODAN> well, shall we vote then?
15:41:44 <adamw> sure, if we get a clear outcome from the vote i'll amend the proposal accordingly
15:42:00 * j_dulaney is +1 keep as is
15:42:01 <adamw> so i guess if you think virt-install is an important enough case for beta, vote +1 blocker...
15:42:04 <VICODAN> okay what are the 2 options? +1 = final blocker -1 = betablocker?
15:42:13 <VICODAN> -1
15:42:23 <adamw> everyone stop voting, this is too confusing. =)
15:42:35 <adamw> as we're discussing a proposed blocker, +1 is 'beta blocker', -1 is 'not a beta blocker'.
15:42:39 <VICODAN> -1, it is a final blocker, not a beta blocker
15:42:41 <adamw> you may proeed. =)
15:42:52 <j_dulaney> Where's the Proposed?
15:42:59 <adamw> j_dulaney: it comes after votes.
15:43:09 <adamw> #chair tflink kparal j_dulaney
15:43:09 <zodbot> Current chairs: adamw j_dulaney kparal tflink
15:43:32 <kparal> +1 beta blocker
15:43:42 <tflink> with the criteria as is, +1 blocker
15:43:45 <kparal> as it currently stands
15:43:46 <j_dulaney> +1 Beta Blocker
15:44:06 <brunowolff> +1 beta blocker
15:44:13 * jskladan also likes virt-install quite a lot (-> +1 beta blocker)
15:44:24 <kparal> we might discuss the criteria change, but it might be a longer discussion, so it's not viable right here right now
15:44:26 <VICODAN> well i guess that's settled
15:44:27 <adamw> tflink: i was hoping to turn this into a referendum on how we should change the criteria
15:44:35 <adamw> but okay, i'll re-open the thread
15:45:00 <adamw> propose #agreed 808029 is accepted as a beta blocker per the criteria as they stand; criteria modification proposal is pending but needs further discussion in light of the virt-install use case
15:45:09 <tflink> adamw: well, you asked for blocker votes. I assumed that you were attempting to separate the two issues
15:45:25 <j_dulaney> ack
15:45:37 <tflink> ack
15:45:39 <jskladan> ack
15:45:45 <brunowolff> ack
15:45:47 <adamw> #agreed 808029 is accepted as a beta blocker per the criteria as they stand; criteria modification proposal is pending but needs further discussion in light of the virt-install use case
15:45:51 <adamw> yeesh, that was icky.
15:46:03 <j_dulaney> So, time for more icky
15:46:11 <adamw> heh
15:46:17 <adamw> i guess the other big thing to discuss is indeed also icky...
15:46:23 <adamw> #topic Fedora 17 blocker/NTH review - https://bugzilla.redhat.com/show_bug.cgi?id=808378
15:46:27 <tflink> is it just me or is this meeting more chaotic than usual?
15:46:31 <adamw> tflink: not just you
15:46:42 <adamw> and it's about to get more fun!
15:46:51 <adamw> so, this is the NTH for 'include GNOME 3.4 in rc3'
15:46:51 <tflink> is this the gnome 3.4 bug?
15:47:01 <adamw> yeah
15:47:27 <adamw> on the 'positive' side, 3.4 seems to work fine, for me. well, no worse than 3.3.91 at least. on the 'negative' side, we're now tight on time and getting tighter.
15:48:10 <tflink> pretty much the same dilemma as friday :-/
15:48:13 <Southern_Gentlem> more testing the better
15:48:22 * tflink is leaning towards +1, though
15:49:08 <j_dulaney> as am I
15:49:20 <brunowolff> I have been using 3.4 in fall back mode since it landed in testing and I haven't run across any deal breakers. The most notable change is the list of logins displayed in gdm.
15:49:20 * satellit_ both worked for me in Virtualbox and as persistent usb's
15:49:24 <VICODAN> why not?
15:49:27 <j_dulaney> If it's to buggy, I'll just switch back to Fluxbox
15:49:40 <VICODAN> from reaidng this there are a number of bugfixes in 3.4
15:50:07 <tflink> VICODAN: the reason not to do it is that we'd have to re-do all of the desktop validation
15:50:08 <adamw> VICODAN: because in general, we change as little as possible between RCs.
15:50:15 <adamw> the more that gets changed, the more likely something will break.
15:50:20 <tflink> assuming that there are no other issues, that is
15:50:32 <tflink> re-doing the validation only is a best-case scenario
15:50:46 <adamw> right now, we know that gnome 3.3.91 as shipped in beta rc2 passes all the beta criteria. bumping to 3.4 introduces a risk that, somehow, the change will break the criteria.
15:51:14 <VICODAN> i suggest that we test it in rawhide if that makes any sense (At the risk of sounding like an idiot)
15:51:16 <tflink> and there is not much time to get a fix for anything that might break and block release
15:51:33 <VICODAN> or updates-testing
15:51:33 <adamw> VICODAN: it's already in 17 updates-testing and lots of people have used it there without obvious explosions
15:51:45 <tflink> VICODAN: there are F17 beta-ish lives available for testing if you'd like to take them for a spin
15:52:00 <adamw> VICODAN: but pulling something into a compose is different. a good general rule of thumb in autoqa is that if you're saying to yourself that 'nothing could possibly go wrong', something almost certainly will. =)
15:52:03 <adamw> s/autoqa/qa/
15:52:20 <VICODAN> i have a sticker in front of me that says "what could go wrong?"
15:52:24 <VICODAN> im sitting in a NOC
15:52:26 <VICODAN> ;)
15:52:28 <VICODAN> anyways
15:52:42 <VICODAN> maybe leave it for RC3? or Final?
15:52:48 <tflink> the s-word is another good indicator - if you hear "x SHOULD y" ... that's a red flag :)
15:52:48 <adamw> also, general 'day-to-day' usage doesn't _exactly_ hit all the acceptance criteria. a lot, but not all. and there can be issues in a fresh install you don't see in a day-to-day update.
15:52:54 <adamw> whether we put it in Beta RC3 is the question here.
15:53:11 <VICODAN> I say yes.
15:53:31 <brunowolff> How hard is the desktop team asking for this?
15:53:53 <adamw> moderately
15:53:59 <adamw> as in, they'd really like it, but they understand if we say no.
15:54:15 <j_dulaney> Let's go ahead and vote
15:54:33 <tflink> so, are we willing to risk slipping beta again in exchange for more gnome 3.4 testing before final?
15:54:34 <VICODAN> from kalev: - people keep reporting bugs that have already been fixed and reported by others, duplicating effort;
15:54:36 <adamw> oh, crap, i meant to spin a newer image with an updated selinux-policy in it too, to make sure that doesn't explode anything. it shouldn't, though. whoops, there's the S word.
15:54:46 <VICODAN> thats enough for a +1
15:54:49 <VICODAN> IMHO
15:54:51 <tflink> adamw: my i686 image has the new selinux-policy
15:54:54 * adamw likes to keep the desktop team owing him a favour, so what the hell, +1
15:54:57 <adamw> tflink: oh cool, thanks for that.
15:55:00 <j_dulaney> +1
15:55:00 <VICODAN> +1
15:55:04 <tflink> +1
15:55:24 <brunowolff> slight +1 for using 3.4
15:55:35 <adamw> propose #agreed #808378 is accepted as NTH because we're insane and bad at doing our jobs
15:55:41 <adamw> ^H^H^H^H^H
15:55:57 <VICODAN> heh
15:55:58 <kparal> I can only ack that
15:56:01 <tflink> adamw: way to not water down the truth :)
15:56:05 <brunowolff> ack
15:56:07 <adamw> propose #agreed #808378 is accepted as NTH because 3.4 fixes several known bugs and we obviously would prefer testing of final to testing of an obsolete beta
15:56:15 <adamw> ack whichever you like ;)
15:56:36 <brunowolff> ack
15:56:40 <tflink> the first one is closer to the truth, the second one sounds better to an outside observer
15:56:41 <VICODAN> ack
15:56:47 <adamw> tflink: heh
15:56:49 <tflink> either way ack
15:57:03 <VICODAN> wasn't it insane to move to gnome 3 in the first place? :P jk
15:57:04 * adamw puts on his 'professional manager' hat
15:57:10 <adamw> #agreed #808378 is accepted as NTH because 3.4 fixes several known bugs and we obviously would prefer testing of final to testing of an obsolete beta
15:57:14 <adamw> boy, is that hat dusty.
15:58:10 <adamw> kparal brings news of one more proposed blocker
15:58:16 <adamw> #topic Fedora 17 blocker review - https://bugzilla.redhat.com/show_bug.cgi?id=809052
15:58:45 <adamw> seems like Shell-on-software-rendering is often/always broken in cirrus/VNC VMs (as opposed  to qxl/Spice VMs)
15:58:58 <kparal> actually it seems like always
15:59:02 <kparal> since last RC
15:59:06 <adamw> qxl/Spice has been the default since f16, but lots of people keep a VM configuration around for a long time rather than creating a new one...
15:59:08 <kparal> before it worked I think
15:59:10 <adamw> kparal: uh, not for me.
15:59:28 <adamw> kparal: i tested both beta rc2 and my 3.4 image in a kvm, worked fine.
15:59:31 <j_dulaney1> I think it worked for me, as well
15:59:31 <kparal> interesting. pschindl also reproduced that bug
15:59:33 <VICODAN> this is probably related to mesa
15:59:38 <tflink> I see this a lot
15:59:41 <adamw> kparal: or by 'since', do you mean 'after a yum update'?
15:59:53 <kparal> I reproduced on RC2 Live, just after boot
16:00:01 <tflink> for some reason, all of my F16 VMs default to cirrus+VNC which results in graphically-broken gnome-shell
16:00:04 <adamw> kparal: do you have that VM configuration around to verify the hardware?
16:00:05 <j_dulaney> Which way did the vote on 3.4 go?
16:00:06 <rbergeron> the words i love to see: ONE MORE PROPOSED BLOCKER
16:00:13 <adamw> rbergeron: you're on PTO, go away
16:00:17 <adamw> j_dulaney: +1
16:00:27 <j_dulaney> adamw:  TY
16:00:28 <kparal> adamw: do you want it now?
16:00:33 <adamw> kparal: always!
16:00:37 <adamw> also, i want a golden toilet.
16:00:57 <j_dulaney> Can I have one made of diamond?
16:01:16 <kparal> adamw: http://fpaste.org/LyZD/
16:01:53 <adamw> kparal: that's cirrus/VNC.
16:02:05 <VICODAN> adamw: i will try and reproduce this problem, but i think it's related to MESA and I also think it's probably fixed with the new mesa
16:02:16 <kparal> adamw: yes. I see it only on cirrus+vnc
16:02:18 <VICODAN> so i dont think this is a betablocker anymore, but I will test
16:02:28 <tflink> adamw: isn't that the HW in question here?
16:02:44 <adamw> tflink: i thought by 'actually seems like always', kparal was disputing my assertion that it only happens on cirrus/vnc
16:02:52 <kparal> oh no, sorry
16:03:03 <tflink> adamw: the default on my F16 boxes is cirrus+vnc
16:03:03 <kparal> always like in all attempts to boot
16:03:07 <adamw> oh, you were just saying 'always' not 'often'. ah.
16:03:10 <adamw> wires crossed!
16:03:26 <kparal> I reproduce it on both archs
16:03:32 <adamw> tflink: i dunno what the hell is wrong on your f16 boxes then. =)
16:03:50 <adamw> anyhow, i think we can say cirrus/vnc is sufficiently common we shouldn't just bork the hell out of it...
16:04:14 <j_dulaney> cirrus/vnc is also default on my F16 VMs
16:04:20 <tflink> adamw: who knows what's wrong. at least they're booting now that I spent a lot of quality time with EFI shell and other tools
16:04:33 <VICODAN> j_dulaney: vmware or vbox or kvm?
16:04:44 <adamw> VICODAN: this is kvm.
16:04:51 <adamw> VICODAN: vmware and vbox use different setups.
16:04:56 <VICODAN> k
16:05:05 <VICODAN> maybe KVM should be switched to use a different driver
16:05:10 <VICODAN> like intel hd graphics
16:05:11 * kparal still tries to translate 'bork out'
16:05:14 <VICODAN> cirrus logic is kind of old
16:05:29 <adamw> VICODAN: it's an emulated card.
16:05:32 <tflink> kparal: leave it broken
16:05:33 <j_dulaney> kparal:  ignore the bug
16:05:37 <kparal> thanks :)
16:05:39 <VICODAN> yeah, it should emulate a different card.
16:05:50 <tflink> kparal: np, it's a rather odd way to put it :)
16:05:59 <adamw> VICODAN: the reason Cirrus is the default is because it has the best multi-OS compatibility.
16:06:00 <VICODAN> cirrus logic is antiquated
16:06:19 <VICODAN> the best multi-os compatibility is intel
16:06:21 <adamw> the kvm team did think things through, they didn't just pick some random-ass adapter.
16:06:27 <VICODAN> lol
16:06:35 <adamw> er, qemu, rather.
16:06:35 <VICODAN> what does vmware and virtualbox use?
16:06:37 <j_dulaney> Hmm
16:06:47 <j_dulaney> So much for getting past blocker again today
16:07:11 <adamw> j_dulaney: I know
16:07:20 <kparal> note: I am quite sure this is a recent regression. I don't have previous composes at hand, but I can try later
16:07:30 <adamw> VICODAN: anyway, it's really pointless to argue about here. the fact is that it *does* default to cirrus. we can say all day that it shouldn't, that changes nothing
16:07:44 <VICODAN> well
16:07:55 <adamw> kparal: when you say 'recent regression', do you mean it worked with *shell* before?
16:08:00 <VICODAN> how would this be fixed? building cirrus logic support in to the 3.3 kernel?
16:08:02 <adamw> or it used to default to fallback mode and hence work?
16:08:07 <kparal> adamw: I believe so
16:08:09 * j_dulaney remembers Alpha TCs at the least working with software render with his default config, namely Cirrus
16:08:25 <kparal> it worked with shell
16:08:31 <adamw> VICODAN: we would fix whatever's broken in llvmpipe.
16:08:50 <VICODAN> so mesa
16:08:55 <adamw> that's what i said.
16:09:00 <VICODAN> and are we sure it wasn't fixed with the latest mesa update?
16:09:10 <adamw> it was probably *broken* with the latest mesa update.
16:09:13 <VICODAN> LOL
16:09:14 <kparal> yep
16:09:16 <adamw> kparal: can you try with mesa -1 rather than -9?
16:09:22 <kparal> I can
16:09:39 <VICODAN> because I Was getting display corruption on virtualbox when opening a terminal and the latest mesa fixed it for me
16:09:41 <kparal> but it will take some time. not worth waiting for it
16:09:50 <VICODAN> but again that's not kvm
16:09:55 <VICODAN> and using a different driver
16:10:11 <adamw> VICODAN: that was a different bug, yes.
16:10:16 <adamw> VICODAN: fixed between -7 and -9.
16:10:34 <adamw> anyhow, we're getting sidetracked again
16:10:44 <adamw> can we just take blocker votes? +1 from me
16:10:49 <VICODAN> -1
16:11:06 <kparal> +1
16:11:15 <adamw> i always lose track of exactly when we switched from cirrus/vnc to qxl/spice as default, but it's manifestly the case lots of people are still on the former
16:11:20 <j_dulaney> +1
16:12:03 <tflink> +1
16:12:04 <VICODAN> adamw: you know where my loyalty is on virtualization so it doesn't affect me either way
16:12:18 <brunowolff> +1 beta blocker
16:12:40 <adamw> VICODAN: it's not a question of whether it affects you, if you're going to vote, you have to look at the issue disinterestedly and assess whether it meets the established criteria.
16:12:46 <VICODAN> i did
16:12:47 <adamw> speaking of, i really should have cited the criteria in this case, bad me
16:12:51 <VICODAN> i dont think it's a beta blocker
16:13:16 <VICODAN> final yes, beta no.
16:13:23 <adamw> this is a conditional breach of "The release must install and boot successfully as a virtual guest in a situation where the virtual host is running the previous stable Fedora release, using Fedora's current preferred virtualization technology" in the condition 'VM is using cirrus rather than qxl'
16:13:59 <VICODAN> well it boots and installs right? you just can't open firefox?
16:14:18 <tflink> VICODAN: gnome-shell is not usable
16:14:26 <kparal> no, no application works
16:14:30 <VICODAN> but it boots and installs.
16:14:31 <adamw> VICODAN: see the screenshots, there's extensive corruption in everything.
16:14:31 <kparal> everything is blurred
16:14:50 <kparal> you can't control anaconda
16:14:57 <VICODAN> then in that case +1
16:15:08 <adamw> VICODAN: oh, forgot to cite, "ollowing on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to a working graphical environment without unintended user intervention"
16:15:22 <VICODAN> thank you
16:15:25 <VICODAN> +1
16:15:43 <j_dulaney> Crap, Earl Scruggs passed away
16:16:12 <j_dulaney> Wrong channel
16:16:15 <VICODAN> lool
16:16:19 <VICODAN> is that a beta blocker?
16:16:35 <VICODAN> too soon?
16:16:39 <adamw> propose #agreed 809052 is a blocker per the virtualization and 'installed system should boot to working desktop' criteria, for the sufficiently common case of VM using cirrus as the graphics driver
16:16:43 <adamw> if it is, it'll be damn hard to fix
16:16:46 <VICODAN> ack
16:16:47 <brunowolff> ack
16:16:52 <kparal> ack
16:16:54 <tflink> ack
16:17:11 <adamw> #agreed 809052 is a blocker per the virtualization and 'installed system should boot to working desktop' criteria, for the sufficiently common case of VM using cirrus as the graphics driver
16:17:13 <adamw> whew.
16:18:06 <adamw> well, this has gone on entirely too long. again.
16:18:11 <adamw> sorry bout that, folks.
16:18:36 <j_dulaney> adamw needs to be fired
16:18:38 <adamw> i'd still kind of like to take a shot at the 'sub-project' topic in the interests of it not hanging around on the agenda forever, is that okay?
16:18:40 <adamw> .fire adamw
16:18:40 <zodbot> adamw fires adamw
16:18:44 <adamw> FREE!
16:18:47 <j_dulaney> For not managing meetings better
16:18:51 * adamw grabs golf clubs and disappears over the horizon
16:19:08 <VICODAN> burn him at the stake!
16:19:12 <j_dulaney> +1 for sub-project
16:19:13 <VICODAN> so are we done?
16:19:27 <adamw> not entirely
16:19:36 <adamw> #topic 'Project' status
16:19:50 <adamw> so, this is https://lists.fedoraproject.org/pipermail/test/2012-March/106215.html
16:20:34 <adamw> for those who didn't follow the thread, briefly, QA has never been an Official Sub-Project, just because it got overlooked, basically. the Board is now proposing to make us one. the two significant consequences of this would be a) we'd  be in the projects list and b) we'd be in the sidebar of the wiki.
16:20:39 <adamw> truly, our lives are now fulfilled.
16:21:14 * tflink doesn't have a strong opinion on this, can't see it having much practical impact
16:21:22 <adamw> viking_ice noted that there was some Political History about the whole QA/bugzappers relationship some years back, but it seems like no-one gives a fig about that now.
16:21:25 <ianweller> adamw: ping me for said life-fulfilling sidebar wiki link when it's all said and done
16:21:34 <j_dulaney> Don't we already have a budget, etc. anyway?
16:21:46 <tflink> adamw: I looked for that history, couldn't find anything
16:22:04 * j_dulaney is interested in such
16:22:05 <adamw> j_dulaney: i don't think we get a *fedora* budget, and i don't think this would change that. the RH staff who work on Fedora QA have a *Red Hat* budget. which we spend on liquor.
16:22:24 <j_dulaney> Ah
16:22:28 <adamw> aiui, it involved the question of whether bugzappers was just a subsidiary bit of QA or whether it was its own independent project.
16:23:11 <adamw> oh, in order to be granted said life-changing Project status, we'd have to say something about our governance. i put a draft in the thread, which everyone seemed happy with. it's in that linked post.
16:23:31 <adamw> it just says that we don't have a formal governance structure, don't have a leader, and make decisions by consensus. now agree with me or i'll make you pay!
16:23:57 * kparal agrees
16:24:17 * j_dulaney disagrees just to see what adamw will do
16:24:43 <adamw> proposal: we stick the proposed Governance section somewhere in the wiki and let rbergeron know we're happy to accept subproject status and the glorious, glorious fame that accompanies it
16:24:50 <brunowolff> I think we also have a goal not to have releases slip even though it doesn't always seem like it.
16:24:54 * adamw re-assigns all remaining blockers to j_dulaney
16:25:03 <adamw> brunowolff: heh :)
16:25:47 <j_dulaney> Hmm, can I change the release criteria so that they're not blockers any more?
16:26:06 <VICODAN> lol
16:26:29 <adamw> j_dulaney: NOW you're thinking like a pro
16:26:38 <adamw> so, anyone hate the proposal?
16:26:40 <brunowolff> Part of our activities is trying to get things resolved that we would be forced to slip for.
16:27:11 <Viking-Ice> so what's our take on merging back triagers under QA
16:27:27 <brunowolff> The proposal sounds reasonable. It would be nice to work in some anti-slippage wording, but that isn't a big deal.
16:27:30 <adamw> brunowolff: it sounds like you're volunteering to write a better list of goals!
16:27:33 <adamw> which would be awesome
16:27:47 <adamw> but i don't think is required for us to accept the subproject thing
16:28:00 <tflink> brunowolff: I'd be very strongly against any explicit anti-slip goals for QA
16:28:07 <adamw> our goals don't get carved in stone when we take project status, or anything, we can go ahead and improve them, as a separate thing.
16:28:21 <brunowolff> +1 for a subproject. We could use more people and that might make us more visible.
16:28:43 <adamw> Viking-Ice: honestly, that's how i've seen it for years anyway. i don't think it really matters now, since bugzappers is pretty dormant. let's say +/-0 for me...
16:28:49 <tflink> +1 for pretty much what brunowolff said
16:28:52 <j_dulaney> +1 to not have blockers assigned
16:29:04 <adamw> Viking-Ice: but i think as we discussed on thread, we can take project status for QA anyway, we don't have to resolve that issue as a part of it.
16:29:12 <brunowolff> I think as long as the goals are helping expiditing resolving issues that would result in a slip I think its OK.
16:29:55 <brunowolff> We also do planning for testing in a way that is supposed to reduce the risk of slipping while still letting people get new and exciting stuff in releases.
16:29:59 <adamw> okay, that sounds positive enough
16:30:25 <brunowolff> That last one, I think needs some work.
16:30:41 <tflink> brunowolff: I imagine that we could get in a rather long argument about that :) not sure a meeting that's already 30 minutes over is the best place for that, though
16:30:43 <adamw> brunowolff: like i said, i think it'd be awesome if you draft up an improved/more detailed list of goals for us to bunfight over, but i don't think we need to do that ahead of accepting project status. the current goals statement is already 'active', whatever that means, after all - project status doesn't change that.
16:31:03 <Viking-Ice> adamw makes no sense having zapper in seperate namespace in the wiki
16:32:33 <adamw> okay, i think we're positive enough on the proposal...
16:32:46 <tflink> adamw: as written in your email?
16:32:56 <Viking-Ice> still begs the question with the zappers
16:33:02 <brunowolff> They have a different focus. QA seems more focussed on release quality, where as zappers are more focused on ongoing quality post release.
16:33:06 <Viking-Ice> so please answer that one before agreeing to anything
16:33:19 <adamw> Viking-Ice: why?
16:33:32 <Viking-Ice> so we can merger or split reporters
16:33:44 <adamw> Viking-Ice: i can't see any reason we have to decide whether bugzappers is a QA sub-project or not before we accept 'official project status' for QA.
16:34:23 <adamw> look at it this way: if we decide bugzappers is a sub-project of QA, can QA be a Fedora project? obviously yes. if we decide bugzappers is not a sub-project of QA, can QA be a Fedora project? obviously yes. so why do we have to decide the qa/bugzappers relationship before accepting project status for qa?
16:35:07 <adamw> this seems like a really straightforward five minute change that we seem to be kicking around for weeks for no obvious reason, to be honest...
16:35:24 <adamw> qa gets stuck on a list of things it should have been on for years, we get a sidebar link, everyone moves on...
16:35:24 <Viking-Ice> ok let's accept that one then deal with either merged or splitting things out of qa
16:35:31 <adamw> Viking-Ice: yeah, that's what i'm proposing.
16:35:38 <Viking-Ice> +1
16:35:40 <j_dulaney> +1
16:35:42 <brunowolff> +1
16:35:51 <tflink> +1
16:36:10 <kparal> +1
16:37:00 <adamw> #agreed we're happy for QA to officially become a 'Fedora project', we will stick the drafted Governance section into the Wiki somewhere and let the board know we're happy to accept project status. This decision does not in any way influence the question of the QA/Bugzappers relationship
16:37:07 <adamw> Viking-Ice: that okay for you?
16:37:33 <Viking-Ice> ok
16:37:44 <adamw> cool.
16:37:59 <adamw> let's blow through the other topics real quick before this turns into a friday meeting...
16:38:22 <adamw> #topic Test Day report
16:38:34 <adamw> so there were two test days last week
16:38:40 <adamw> https://fedoraproject.org/wiki/Test_Day:2012-03-27_Kdump and https://fedoraproject.org/wiki/Test_Day:2012-03-29_Gnome_Shell_Software_Rendering
16:39:06 <adamw> kdump looks like it was a bit doa, likely due to late organization and lack of publicity
16:39:25 * j_dulaney has to go to class
16:39:28 <j_dulaney> Peace y'all
16:39:46 <adamw> shell software rendering seems to have gone off pretty nicely, decent amount of testing and some useful reports, though quite a few bugs reported weren't really anything to do with software rendering of shell.
16:39:54 <adamw> anyone have any other notes on the test days?
16:40:51 <adamw> #info kdump looks like it was a bit doa, likely due to late organization and lack of publicity
16:40:58 <adamw> #info shell software rendering seems to have gone off pretty nicely, decent amount of testing and some useful reports
16:41:10 <VICODAN> sorory boss walked in
16:41:36 <adamw> #topic Upcoming QA events
16:41:52 <adamw> we have a couple more test days this week, https://fedoraproject.org/wiki/Test_Day:2012-04-04_Power_Management and https://fedoraproject.org/wiki/Test_Day:2012-04-05_L10n_I18n_Installation
16:42:01 <VICODAN> only notes I have for test day annoying warning messages when installing off DVD
16:42:03 <adamw> i'd ask j_dulaney for status on those but he just left, whee.
16:42:21 <adamw> PM event looks to be nicely set up already
16:42:43 <kparal> we will try to join it with Brno's RH Open House event
16:42:45 <adamw> l10n/i18n install is mostly in place too but might need a bit of polishing
16:42:47 <VICODAN> okay next test day is 04-05?
16:42:47 <adamw> kparal: sounds great
16:42:49 <kparal> "bring your hardware and measure it"
16:42:52 <adamw> VICODAN: 04-04 and 04-05.
16:42:55 <VICODAN> okay
16:43:01 <VICODAN> will we have an RC3 by then?
16:44:09 <adamw> i hope so. shouldn't matter for the test days, though. test days are topic-specific, not part of validation.
16:44:38 <adamw> #info we have a couple more test days this week, https://fedoraproject.org/wiki/Test_Day:2012-04-04_Power_Management and https://fedoraproject.org/wiki/Test_Day:2012-04-05_L10n_I18n_Installation
16:44:46 <adamw> #info Go/No-Go #2 is scheduled for 04-04
16:44:54 <adamw> and i think that's about all that's coming up.
16:45:05 <adamw> #topic AutoQA update
16:45:09 <adamw> kparal, tflink, anything important?
16:45:29 <kparal> I don't think so
16:45:41 <tflink> nothing I can think of
16:45:49 <kparal> there's no progress now, too many other tasks
16:48:12 <adamw> okey dokey
16:48:19 <adamw> #info no autoqa progress atm, too much Beta testing
16:48:23 <adamw> aaand we're done
16:48:26 <adamw> #topic Open Floor
16:48:30 <adamw> anyone have anything for open floor?
16:50:57 <adamw> then let's end this nightmare, sorry for the over-run
16:51:01 <adamw> thanks for coming all
16:51:03 <adamw> #endmeeting