From Fedora Project Wiki

< QA‎ | Meetings

Attendees

  • adamw (231)
  • VICODAN (105)
  • tflink (78)
  • j_dulaney (52)
  • kparal (47)
  • brunowolff (27)
  • Viking-Ice (8)
  • zodbot (6)
  • Southern_Gentlem (4)
  • jskladan (3)
  • pjones (2)
  • ianweller (1)
  • mkrizek (1)
  • satellit_ (1)
  • rbergeron (1)
  • j_dulaney1 (1)

Agenda

  • Previous meeting follow-up
  • Fedora 17 Beta status / blocker review
  • 'Project' status
  • Test Day report
  • Upcoming QA events
  • AutoQA update
  • Open floor

Previous meeting follow-up

  • kparal to propose revised criteria to cover split installs (installer sourced from one repo, packages from internet repos): didn't have a chance to do this yet
  • wwoods to ensure anaconda docs are updated to reflect what repo= is supposed to be capable of: wwoods was not around to update this

Fedora 17 Beta status / blocker review

  • We still haven't been able to spin an RC3
  • We have pretty good RC2 test coverage, just a couple of tests remain, we can knock those off today

Blocker review

  • AGREED: more information needed on #807510 to reach a determination of blocker status, tflink will test with his similar hardware
  • 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
  • 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
  • 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

'Project' status

  • See the on-list discussion
  • 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

Test Day report

Upcoming QA events

AutoQA update

  • No news, team is busy with Beta testing

Open floor

IRC Log

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

Generated by irclog2html.py 2.8 by Marius Gedminas - find it at mg.pov.lt!

Retrieved from "https://fedoraproject.org/w/index.php?title=QA/Meetings/20120402&oldid=283725"