Testing/Logs/20061116

17:02 -!- wwoods changed the topic of #fedora-testing to: Fedora QA - Meeting started at 2200 UTC! Agenda: http://fedoraproject.org/wiki/Testing/Meetings/20061116
17:03 <@wwoods> hooray! Meeting officially started! I'll still give people 5min to filter in.
17:04 -!- che [n=bleh@redhat/che]  has joined #fedora-testing
17:04 < che> evening
17:04 <@wwoods> howdy
17:04 -!- clumens [i=chris@nat/redhat/x-9233b9450490b78d]  has joined #fedora-testing
17:05 <@wwoods> clumens: SUCKER!
17:05 <@wwoods> everyone GET HIM
17:05 -!- dcantrell [i=dcantrel@nat/redhat/x-2db76e33f85318f5]  has joined #fedora-testing
17:05 < clumens> NOO
17:05 -!- hwist [n=henrik@host186-86.bornet.net]  has joined #fedora-testing
17:06 <@wwoods> okay, 5 minute grace period over, meeting officially starting.
17:06 <@wwoods> If you missed it, the agenda is on the wiki page referenced in the topic.
17:06 <@wwoods> So! Reviewing what we talked about last week. (http://fedoraproject.org/wiki/Testing/Meetings/20061109)
17:07 <@wwoods> I was supposed to write a test-plan template for the wiki.
17:07 <@wwoods> I've gathered a bunch of testplan layouts - a couple internal ones, looked at the IEEE official Test Plan stuff
17:08 <@wwoods> the IEEE stuff is here: http://standards.ieee.org/reading/ieee/std_public/description/se/829-1983_desc.html
17:08 <@wwoods> it's.. a bit baroque.
17:08 < clumens> well, yes.
17:08 <@wwoods> I think we're really just going to have something nicely simple for that, like 3 parts
17:08 <@wwoods> Description (an overview of the test plan's purpose)
17:09 <@wwoods> Actions (steps to follow to test some bit of functionality)
17:09 <@wwoods> and Expected Results (duh)
17:09 -!- gumby_ [n=steveb@Glenwood-mikrotik.veracitycom.net]  has joined #fedora-testing
17:09 <@wwoods> This is basically what Testify (internal RH tool) uses.
17:09 < dmalcolm> kind of like a bugzilla, but hopefully a not-a-bugzilla, if you see what I mean
17:10 <@wwoods> dmalcolm: right, although tracking people actually *using* the plans is.. something else. we'll get to that in a minute.
17:10 -!- MikeC [i=mike@host-72-51-160-134.newwavecomm.net]  has joined #fedora-testing
17:10 <@wwoods> So, I haven't gotten the template up yet (sorry), I'll do that tomorrow.
17:11 <@wwoods> Any questions there? I suspect we'll probably want to look at the template and try writing a few HOWTOs with it before anyone will have input..
17:12 <@wwoods> Next is Beaker/RHTS status. dmalcolm, any big developments in RHTSland?
17:12 < dmalcolm> talking about test plans, I'm a little worried that having "plans" might discourage the kind of exploratory testing that most of us do
17:13 < clumens> i imagine that people would regularly do exploratory testing and then once they find something, formalize it so in the future we know what to look for
17:13 <@wwoods> dmalcolm: hmm. I certainly don't want that. Mostly I want little guides that tell me exactly how I would go about testing a random package
17:13 < che> actually that hits my primary question. who will do the testing and to who does the plan apply?
17:13 <@wwoods> like, for instance, if there's an net-snmp update.. I have no clue how to set up an snmp server, or what to do with it
17:14 <@wwoods> so if there were a few wiki pages about "here's something net-snmp does, and here's how you test it"
17:14 <@wwoods> that would be fantastic
17:14 < che> 4 eyes principle? is it a mandatory qa test done for every core/extras package?
17:14 <@wwoods> che: we can't yet *require* tests for all packages
17:14 <@wwoods> che: but I think this is a starting point for that
17:14 < che> wwoods, yet implies though thats the plan.
17:14 < che> wwoods, or rather... long term goal
17:15 <@wwoods> che: one of the things discussed during the Summit was the new Updates tool
17:15 <@wwoods> http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem
17:16 < che> wwoods, thanks for the link.. going to look at it.
17:16 <@wwoods> I would like to have links to how-to-test docs, bugzilla, etc. for the Pending Update Stage
17:16 <@wwoods> and that's also where RHTS tests etc. would fire
17:16 < dmalcolm> cool
17:17 <@wwoods> dmalcolm: it's written in turbogears, have you messed with that too?
17:17 < dmalcolm> what, the Updates tool?
17:17 <@wwoods> turbogears.. I know you've been playing happily with django for a while
17:17  * dmalcolm has played with CherryPy, Cheetah and SqlObject, as well as Django
17:18  * dmalcolm is fully Agile-compliant
17:18 < clumens> and you support all the latest buzzwords
17:18 < che> lol
17:18 < dmalcolm> heh
17:18 <@wwoods> welcome to dmalcolm 2.0 (beta)
17:18  * dmalcolm crashes
17:18 < che> wwoods, cool bot... can i get on the partyline?
17:19  * che grins
17:19 < clumens> i think i had a turbogears 16 back in the day.
17:19 < dmalcolm> wwoods: anyway, moving on to Beaker/RHTS?
17:19 <@wwoods> So anyway, yes, Beaker/RHTS
17:20 < dmalcolm> not much to see so far, beyond the last meeting
17:20 < dmalcolm> (should I recap that info?)
17:20 <@wwoods> No real developments on the test lab.. I've got hardware, but we still need software work
17:20 <@wwoods> nah, it's in the logs from the last meeting
17:21 < dmalcolm> I did some hacking on a result browser for Beaker that could sit outside the firewall, called "Honeydew"
17:21 -!- hwist [n=henrik@host186-86.bornet.net]  has quit ["Leaving"] 
17:21 <@wwoods> heh, very nice. How do we plan to have the RHTS tests run for new updates / devel packages?
17:21 < dmalcolm> but it's too early to be useful (it's in testing.108.redhat.com subversion in the incubator dir)
17:21 <@wwoods> I'm guessing the updates system will have a link to call out to Beaker to run appropriate tests?
17:22 < dmalcolm> yes, I think we'll need to have an XML-RPC interface
17:22 < dmalcolm> we can mock up the XML-RPC stubs in the Honeydew module, perhaps
17:22 < dmalcolm> do you want me to take an action item to look at this?
17:22 < dmalcolm> (more buzzwords)
17:23 <@wwoods> if you've got time, that would be fantastic
17:23 < dmalcolm> who else is hacking on the Updates system?
17:24 <@wwoods> Do we want Beaker to end up outside the firewall, or do we plan on having it stay inside Red Hat? I'm not sure what it would cost to host a rack of machines somewhere...
17:24 < dmalcolm> aha
17:24 <@wwoods> dmalcolm: Luke Macken mostly
17:24 < dmalcolm> I'll contact him
17:24 <@wwoods> dmalcolm: fantastic, thank you
17:25 < dmalcolm> for those who don't know RHTSL each test has metadata, part of the metadata is "what packages should this test be run for"
17:25 < dmalcolm> s/RHTSL/RHTS/
17:25 < gumby_> just briefly: what does Beaker do?
17:26 <@wwoods> gumby_: beaker is just the name for the Fedora test lab
17:26 < dmalcolm> it's a rack of machines that can be autoinstalled with software, and tests.  Tests are deployed as RPMs, and run
17:27 < dcantrell> I'd like to point out that automated testing like that is only moderately useful for testing the installer
17:27 < dcantrell> the installer is....special
17:27 <@wwoods> dcantrell: very true.
17:27 < clumens> (or firstboot)
17:27 <@wwoods> automated installer testing catches a few things but most of the stuff the installer does is interactive. and magical.
17:27 < clumens> or bootloaders, etc.  i'm sure we can come up with quite a list.
17:28 < dcantrell> the exception list is larger than we all think, probably.
17:28  * craigt point gumby_ to http://fedoraproject.org/wiki/QA/Beaker
17:28 < che> wwoods, some functionality testing could be done with kickstarts (not the ui though)
17:28 < dcantrell> wwoods: the installer is mostly magic, true.
17:28 <@wwoods> che: yeah, we do a lot of kickstart-based install testing
17:29 < clumens> that's just all top-secret internal eyes-only stuff at the moment.
17:29 < dcantrell> could we not come up with something that uses dogtail to do some interactive testing for anaconda?  that would _have_ to be paired with actual people sitting down and doing interactive installs
17:29  * gumby_ now has a clue, thank you
17:29 < che> wwoods, for the ui something like a gui testing framework would have to be implemented as special installer option isnt it?
17:29  * craigt points gumby_ to https://testing.108.redhat.com/ as well
17:29 <@wwoods> che: I'm actually rewriting our kickstart-install test tool in hopes that a) it can be released as OSS and b) it will stop being such a pain to use
17:29 < che> wwoods, and then youd have to have some "ai" or "logic" for some of the options.
17:29 <@wwoods> but yeah, that ain't quite baked yet
17:30 <@wwoods> che: as dcantrell mentions, we're thinkin' you could use dogtail to drive anaconda
17:30 < che> but hmm id set the priority really on "defaults" and "defaults are easily tested.
17:30 <@wwoods> and that would get us some more automated testing
17:30 < che> wwoods, not a bad idea
17:30 <@wwoods> but actual human testing is still REALLY important
17:30 < che> as always.
17:30 <@wwoods> especially for the mutant weirdo hardware and install cases that people seem to find
17:31 < che> automated testing can never catch all bugs... but it can catch lots of "showstoppers" or completly broken things.
17:31 < che> wwoods, of course.
17:31 <@wwoods> Oh, getting back to the agenda for one moment - anyone have any big things they noticed in bugzilla from the past week
17:31 < dmalcolm> one other thing about RHTS...
17:31 <@wwoods> any new and interesting bugs, anything popping up a lot that isn't on the common bugs list
17:31 <@wwoods> dmalcolm: go ahead?
17:31 < dmalcolm> I looked at making it east to write "rpmlint" regression tests
17:32 <@wwoods> dmalcolm: hmm! that might be something that should go into the build system
17:32 < dmalcolm> so if you have the rpmlint output of say, evolution on FC6, you can create a test that's run against evolution, and complains if new errors occur
17:33 < dmalcolm> need to fuzz the output though, for instance the kernel embeds lots of VERSION-RELEASE info in the error messages
17:33 < dmalcolm> ultimately I'm doing textual diffs
17:33 <@wwoods> heh. still, it would probably help packagers if the build system yelled at them when they messed up their specfiles
17:33  * dmalcolm wonders which build system
17:34  * craigt wonders what 'fuzz the output' means ?
17:34 <@wwoods> the new build system is a huge topic for FC7 development.. jkeating (f13) and other developer-types know a lot more than I do about it
17:34 < dcantrell> dmalcolm, is rpmlint a tool that you can run against a spec file?  something like speclint would be handy
17:34 < dmalcolm> craigt: W: kernel unstripped-binary-or-object /lib/modules/2.6.18-1.2798.fc6/kernel/sound/pci/rme9652/snd-hdspm.ko
17:34 < dmalcolm> W: kernel ldd-failed /lib/modules/2.6.18-1.2798.fc6/kernel/sound/pci/rme9652/snd-hdspm.ko
17:34 < dmalcolm> convert it to: W: kernel unstripped-binary-or-object /lib/modules/$(VERSION)-$(RELEASE)/kernel/sound/pci/rme9652/snd-hdspm.ko
17:34 < dmalcolm> W: kernel ldd-failed /lib/modules/$(VERSION)-$(RELEASE)/kernel/sound/pci/rme9652/snd-hdspm.ko
17:35 < dmalcolm> so that it isn't always different, simly when davej respins the kernel
17:35 < dmalcolm> s/simly/simply/
17:35 < dmalcolm> dcantrell: it can run on srpms IIRC, which would cover most of the same cases I think
17:36 < che> dmalcolm, you can also run it on binary rpms
17:37 < dcantrell> dmalcolm: interesting.  I know a frequent problem I hit is RPM macro expansion _inside_ comments in the spec file and the results are....strange
17:37 -!- guzu [n=guzu@89.136.6.179]  has quit ["Leaving"] 
17:37 < dmalcolm> yes, the above is from running it on my installed kernel
17:37 < che> dcantrell, old bug
17:37 < che> dcantrell, if you put #%configure into a spec it gets executed
17:37 < dcantrell> che, yes, I know. but it's still present and people need to know to avoid it
17:38 < dmalcolm> auto-catching the bug with a lint tool would be a Good Thing
17:38 < che> dmalcolm, id rather see the stuff fixed
17:38 < dmalcolm> you mean in rpmbuild?
17:38 < dcantrell> that particular rpm bug probably won't be fixed for a while
17:39 < che> dmalcolm, well if i comment %configure out its commented out.
17:39 < che> dmalcolm, wherever it occurs.
17:39 <@wwoods> dmalcolm: definitely a Good Thing; that seems like something that should either go into the New Build System or the Updates System
17:39 <@wwoods> http://fedoraproject.org/wiki/FedoraSummit/NewBuildSystem btw
17:40 <@wwoods> jkeating talked about having post-build checks run on new packages before they can go anywhere
17:40 < dmalcolm> (it's arguably a bug in rpmbuild that is hard to fix, or a bug in each individual specfile, which is easy to fix, but hard to spot; lint tool makes the latter easier)
17:40 <@wwoods> rpmdiff, rpmlint, etc
17:40 < che> dmalcolm, that bug exists since years... its annoying :)
17:40 < che> dmalcolm, workaround vs fix :)
17:40 < dmalcolm> agreed
17:41 <@wwoods> dmalcolm: I'll take an Action Item (tm) to ask jkeating about where rpmlint regression checking should fit in
17:41 <@wwoods> does that make sense?
17:41 < che> maybe i can get paul nasrat to look at it
17:41 < dmalcolm> If you want lint tools, BTW, I've written glade-lint and docbook-lint here: https://testing.108.redhat.com/source/browse/testing/trunk/incubator/
17:42 <@wwoods> Moving along ('cuz I don't want this meeting to last past 6): Fedora Summit Recap!
17:42 <@wwoods> So I was on the phone with the Fedora Summit dudes on Tuesday to talk about QA
17:43 <@wwoods> We've talked a bit about the new updates tool - I think that's a really good place for us testers to work
17:43 <@wwoods> Basically we discussed having people test out the packages in updates-testing - the tool will have a list of those
17:44 <@wwoods> with links to bugs, changelog, how-to-test docs, automated test results, etc. for each update
17:44 <@wwoods> and a place for us testers to say "Love it!" or "Hate it!"
17:44 <@wwoods> so if a package is messed up you can say "hate" and add a comment as to why
17:45 <@wwoods> a bug would be created for each package and your comment would be added to that bug.
17:45 < che> wwoods, nice idea
17:45 <@wwoods> so after a week or two in updates-testing, there should be a bunch of tester feedback on that package
17:46 <@wwoods> what *should* happen is that no package should go live until there's only positive feedback
17:47 <@wwoods> the way jesse was talking about it, though, the maintainer can still ignore the feedback and request a package to be pushed
17:47 < che> wwoods, if i get it the right way... the people write a reason
17:47 <@wwoods> but the package goes to the release team to be signed
17:47 <@wwoods> right
17:47 < che> wwoods, that means youd have to "read" everything that says "hate"
17:47 <@wwoods> so unless the maintainer has a damn good reason for pushing a package that's got a Hate rating of -8
17:48 < che> wwoods, my idea would be to have a kinda multible choice sel and then the possibility to write a test
17:48 <@wwoods> the release test team should go "uh, no." and refuse to sign it
17:48 < che> wwoods, like "broken for my hardware" "generally broken" etc
17:48 < che> wwoods, and then a reason
17:48 <@wwoods> che: ooh, good idea
17:48 < che> wwoods, less reading required i guess.
17:48 <@wwoods> the 'hate' button can give you a list of common reasons
17:48 < che> wwoods, right thats what i meant
17:49 < craigt> that all seems to make a lot of sense for update-testing packages, but what about rawhide testing?
17:49 < che> wwoods, theres more possible with that way... more automated visualisations of reasons etc
17:49 < che> wwoods, and also less to read
17:49 <@wwoods> craigt: right, that's a bit different. I still think the quick-feedback model is good there
17:50 < che> wwoods, how about a bugzilla module for updates-testing
17:50 < che> wwoods, and instead giving a reason you have to supply a bugzilla number :))
17:50 < che> wwoods, i mean instead of manually writing details of the reason
17:51 < che> wwoods, then one could also easily track all existing reasons in bugzilla and just +1 one of em if they apply for you.
17:52 <@wwoods> che: heh! that would be pretty good as a 'hate' option for when there's already a bugzilla number for your problem
17:52 < che> wwoods, well that would make it also easier to handle i guess and to keep overview
17:52 <@wwoods> oh, so the bugs against that package would show up in the hate-reasons list? hmm
17:52 <@wwoods> 1min - wife keeps calling
17:52 < che> wwoods, maybe maybe not.
17:53 < che> wwoods, would be an idea but could also be handled externally.
17:53 < craigt> che, should the 'reason' be added as comments on the existing bug ?
17:53 < che> craigt, hmm good question. this vision i have is like 60 secs old.
17:53 < che> craigt, :)
17:54 <@wwoods> craigt: that's what we had envisioned - when you add your reason, it shows up in a bug filed against that package
17:54 <@wwoods> as a new comment
17:54 < che> wwoods, with 1000 testers that would be lots of spam though
17:55 <@wwoods> 1000 testers! I'd love to have that as a problem
17:55 <@wwoods> heh
17:55 < craigt> so the existing/open bugs would have to be listed for each package
17:55 < che> wwoods, i am not sure how it scales atm.
17:56 <@wwoods> che: right, it's hard to say how many testers we'd have, because this would require some kind of authentication - either a Fedora Account, bugzilla auth, openID.. something
17:56 < che> wwoods, i like scalable solutions though thats why i think in "1000"s
17:56  * che is demanding
17:57 < che> even if its only like 100 testers ... reading those threads will be an awful task
17:57 <@wwoods> che: well, the comment could be optional - the updates tool can keep track of hate/love points
17:58 <@wwoods> without needing a comment for each one
17:58 < craigt> che, yeah which means they wont be read
17:58 < che> wwoods, good solution
17:58 < che> wwoods, that means if i just second whats already there... i just add hate :)
17:58 <@wwoods> yep
17:58 < che> wwoods, hate to all the bug(s) that apply to me
17:59 < che> wwoods, also implies i got multible hate points per app
17:59 < che> wwoods, one for each bug.. :)
17:59 <@wwoods> well, probably we'd track love/hate per-package
17:59 <@wwoods> voting on which bugs should be fixed is a different story
18:00 < che> wwoods, then you have problems to rate criticality of bugs from a users perspective
18:00 < che> wwoods, again agreed
18:00 < che> wwoods, priorisation on the developer side works with different major criteria :)
18:00 <@wwoods> I'll have to come up with a mockup for this idea, I think
18:00 <@wwoods> unless someone else wants to take a swing at it?
18:01 < che> wwoods, but if you got like 10 bugs that are equally bad... wouldnt you fix the one with 1000 hate points vs one with 3 hate points first :=)
18:01 <@wwoods> che: definitely! I'd love for users to be able to easily vote on bugs
18:01 < che> wwoods, if you want i can send you a draft at some point about priorisation of issues :)
18:01 < che> wwoods, i wrote one once :)
18:01 <@wwoods> but this is more for testers to give quick feedback on package updates, in updates-testing and rawhide
18:02 <@wwoods> there's actually lot of stuff we want to implement in bugzilla
18:02 < che> ok
18:02 <@wwoods> except RH bugzilla is weird
18:02 <@wwoods> it's diverged from upstream pretty bad and we keep having arguments about whether to work on RH bugzilla
18:02 < che> hmm it could be worse :)
18:02 <@wwoods> or start a Fedora bugzilla instance
18:02 < che> i have seen much much worse bugzilla setups :)
18:03 <@wwoods> really? I hear a lot of complaints about bugzilla
18:03 < craigt> che, but have u seen any good ones ;)
18:03 < che> people always complain
18:03 <@wwoods> too hard to find bugs, too much cruft, blah blah blah
18:03 <@wwoods> I don't know if starting a fedora bugzilla instance is the answer
18:03 < che> i agree that its hard to filter properly
18:03 <@wwoods> but it would make it easier to do development on these wacky features we keep talking about
18:03 <@wwoods> like bug voting.. and experience points for testers/reporters/etc
18:04 <@wwoods> we're kind of talking about agenda items 2b. and 2c. here, actually
18:04 < che> something like "bugzilla rpg"
18:04 < che> and then we put it on happypenguin.org :)
18:04 <@wwoods> che: from the gnome bugzilla?
18:04 < che> i was just joking now
18:04 <@wwoods> hah!
18:04 <@wwoods> no, seriously, gnome bugzilla awards points for testers and bug reporters and such
18:04 < che> not a bad idea
18:04 <@wwoods> and people gain levels and stuff
18:04 < che> but i would hide those results from the user
18:05 <@wwoods> no way!
18:05 <@wwoods> half the point of adding something like that
18:05 <@wwoods> is that it gives people motivation to help test and fix bugs and such
18:05 <@wwoods> one of the big problems we have is that, with the exception of you guys here now, people aren't real motivated to test stuff just for testing's sake
18:05 < dmalcolm> someone's even written a panel applet that tells you how many bugs you need to level-up
18:06 < che> if someone reports crap and talks crap you substract a point :)
18:06 < che> to not upset the reporter its better to hide the "points"
18:06 < che> hehe
18:06 < che> if you work without substraction... oh well :) then you can show it
18:06 < che> "your avatar is dead with -1 hitpoints, please create a new bugzilla account and create a char"
18:06 <@wwoods> yeah, I think it's better if the BugMasters can grant experience to people for good works
18:06 <@wwoods> che: hah!
18:06 < dmalcolm> http://davyd.livejournal.com/199152.html
18:06 < che> dmalcolm, lol
18:07 <@wwoods> there's some cool things in the gnome bugzilla, but we can't use them because we're not tracking upstream bugzilla
18:07 < che> i shoudl have kept some bugs with me until i can grind the levels up :))
18:08 <@wwoods> HEH well everyone who's here right now will totally get a bunch of levels when we start the bugzilla-rpg
18:08 <@wwoods> for being OldSchool
18:08 < che> hahaha
18:08 < che> we
18:08 < che> wwoods, actually you just found a good argument why we all should want that feature
18:09 <@wwoods> but, anyway - if you have any other ideas for how to get people to help with testing and bugzapping, let me know
18:09 < che> wwoods, good move hehe
18:09 <@wwoods> probably what we need is an external tracker for this stuff
18:09 < craigt> the wiki mentions BugSquashing day...
18:09 <@wwoods> since building things into RH bugzilla is kind of nasty
18:09 <@wwoods> craigt: our wiki?
18:09 < craigt> but I've never seen any work on those days?
18:09 < craigt> y
18:09 <@wwoods> yeah, BugZappers has kind of died out
18:10 <@wwoods> We talked about that at the summit too
18:10 < che> wwoods, hmm its hard to motivate yet unmotivated people to do stuff
18:10 <@wwoods> Jack was saying, basically, that it only works as long as someone's around to 'push on the gas'
18:10 < craigt> or it used to...can't find it now
18:10 < che> wwoods, maybe its not a bad idea to be able to show off some "status"
18:10 <@wwoods> che: right, I think it's a cool idea
18:11 <@wwoods> craigt: something like http://fedoraproject.org/wiki/BugZappers ?
18:11 < craigt> yes, that's where it was...
18:11 <@wwoods> I think we could start up Bug Days again
18:11 -!- dcantrell [i=dcantrel@nat/redhat/x-2db76e33f85318f5]  has left #fedora-testing ["Leaving"] 
18:11 <@wwoods> especially if we had an experience system
18:12 < craigt> i showed up a few times in #fedora-triage on those days...nothing happening
18:12 <@wwoods> but I need you guys to help run it
18:12 <@wwoods> craigt: yeah, samew
18:12 <@wwoods> err same
18:12 < craigt> if there was a triage list of things to work on, a few hours time would go further
18:13 < craigt> (or is it farther)
18:13 <@wwoods> craigt: so maybe we need to set a theme for the bug days?
18:13 < craigt> a theme?
18:13 < craigt>  like what bugs are priority
18:14 <@wwoods> right, like: this friday, we're working on Laptop Suspend/Resume bugs
18:14 < craigt> sure, that would help
18:14 < che> wwoods, d620 ... works sometimes :))
18:14 < che> wwoods, hehe
18:14 <@wwoods> so if you have problems with laptop suspend/resume...
18:14 <@wwoods> come on down
18:14 < che> wwoods, good idea
18:14 <@wwoods> etc.
18:14 < craigt> +1
18:14 <@wwoods> also a voting booth for what we should work on
18:15 < che> wwoods, but that would also kinda throw the priorisation away
18:15 <@wwoods> err, for what the theme should be
18:15 < che> wwoods, on suspend day will it be possible to fix most suspend bugs?
18:15 <@wwoods> or maybe it's just up to us?
18:15 < che> wwoods, or is it about reporting only?
18:15 <@wwoods> che: we've done stuff like that before, where we get the developers to work with us that day
18:15 < che> wwoods, like telling people "ok.. today you all test suspend..."
18:16 <@wwoods> and spend all day testing and reporting bugs and having him/her help trace problems and fix them
18:16 <@wwoods> so, sometimes it will be possible to fix bugs that very day
18:16 <@wwoods> but sometimes it will just be to report bugs
18:16 -!- rick__g [n=rick@adsl-70-232-11-158.dsl.chcgil.sbcglobal.net]  has left #fedora-testing [] 
18:16 <@wwoods> and I will track down the developers later
18:16 < craigt> maybe a good place to start, once we had a theme, could be bugs w NEEDINFO
18:16 <@wwoods> heh
18:16 <@wwoods> oooh! good one
18:17 <@wwoods> Lovechild was finding bugs with patches earlier today
18:17  * craigt saw that
18:17  * craigt thought that was smart
18:17 <@wwoods> yeah, that was a fantastic idea
18:18 <@wwoods> Do you guys want to do a bug day tomorrow?
18:18  * craigt is in
18:18 <@wwoods> as a note to myself: I'll take an Action Item (tm) to prototype a bugzilla RPG using RH bugzilla
18:19  * craigt as time permits anyway
18:19 <@wwoods> naturally
18:19 < che> wwoods, i could come up with a few ideas for that maybe
18:19  * craigt is at work
18:19 < che> wwoods, depending on how much work someone wants to invest into it
18:19 <@wwoods> we aren't all so lucky to work on testing Fedora fulltime
18:19 <@wwoods> che: for the RPG? have you messed with bugzilla much? because any help there would be awesome
18:20 < che> wwoods, i have messed with game design in the past :)
18:20 < che> wwoods, not sure how far you wanna go :)
18:20 <@wwoods> che: cooool. I'll try to work on the backend bits - pulling user info for a given bugzilla userid
18:20 <@wwoods> then we start working out how to award XP and letting people choose classes and such
18:20 <@wwoods> heh
18:21 < che> wwoods, something like that.. and having items
18:21 < che> wwoods, maybe we could do something like "bugzilla avatar battle weekends"
18:21 < che> :)
18:21 < che> wwoods, wouldnt that motivate people more?
18:21 <@wwoods> che: haha! awesome
18:21 <@wwoods> that would be a blast
18:21 <@wwoods> do we want a theme for tomorrow's bug day, or should we just try to help people file bug reports?
18:22 <@wwoods> e.g. direct people on #fedora to #fedora-triage and help them to submit new reports
18:22  * Lovechild makes mental note to sign off IRC when he goes to bed
18:23 < gumby_> I'd like to work out suspend/resume problems, if that's still on the table
18:23 < che> gumby_, +1
18:23 <@wwoods> gumby_: sure, let's do that - we'll work on getting reports in tomorrow
18:23 < che> networkmanager is another candidate
18:24  * craigt is lucky...no suspend /resume prob on is lappy
18:24 < craigt> che, oh yea
18:24 < che> lots of open bug reports for that one
18:24 < craigt> +1 for networkmanger bugs
18:24 <@wwoods> and I'll see if I can get the developers to sign on for a suspend/resume day
18:24 <@wwoods> ooooh networkmanager's another good one
18:24 <@wwoods> SELinux might be a good quest too
18:24 < che> would be sweet if we could enable it by default with fc7
18:25 < Lovechild> I'm tempted to suggest X, I know there are a lot of setups that aren't quite perfect  with the new auto config stuff
18:25 < che> selinux is always a good pick
18:25 <@wwoods> Lovechild: very good idea, I hear frequent reports about that
18:25 <@wwoods> but they're hard to nail down
18:25 < Lovechild> and when you report them ajax leave them untouched so you need to go buy a new videocard..
18:26 <@wwoods> Lovechild: yeah, ajax is really busy, and it's hard to help people debug things when you can't sit down and poke their hardware
18:26 < Lovechild> .. new old and well supported hardware is my answer to everything
18:26 < gumby_> Compiz has been giving me headaches lately, but that's very low-priority
18:26 <@wwoods> Lovechild: the intel stuff (i9xx for example) is really well-supported
18:26 <@wwoods> which isn't surprising - GPL drivers made by manufacturer = everyone wins
18:26 < Lovechild> wwoods: as is the r200 card I put in my machine
18:27 <@wwoods> Now, I need some lead time to get developers to help out on bug days
18:27 <@wwoods> should we do suspend/resume for two weeks, so the first week is just reporting bugs and the second is more reporting + developer help fixing
18:28 <@wwoods> well, maybe I can get pjones to come hang out tomorrow
18:28 < Lovechild> I would love to do intensive bughunts.. one app a day for a week.. 7 major apps on our desktop getting hammered 24/7
18:28 <@wwoods> Lovechild: ooh! that would also be fun
18:28 < Lovechild> IRC would be great to organising that kind of thing..
18:28 <@wwoods> This week: mail clients. Evolution, KMail, ...
18:28 < Lovechild> just pick on Evolution.. that's always good
18:29 <@wwoods> you could spend a month on evolution if you wanted to
18:29 < Lovechild> I think we should focus on our default apps, those are the ones people are most likely to use and encounter bugs in
18:29 < che> oh yeah... evo is another candidate
18:29 <@wwoods> well, it's been 90 minutes.. I have to get home before my wife gets mad, but I'll definitely post notes and a summary tomorrow
18:29 < che> you mentioned nearly all my problem childs already :))
18:30 <@wwoods> tomorrow - suspend/resume bug day
18:30 < Lovechild> Evolution, Firefox, Nautilus
18:30 < che> 0:30 here and i have a course tomorrow :) and then i need to travel home
18:30  * craigt will check in AM, needs to go home
18:30 < Lovechild> Totem is another one that's less than robust
18:30 <@wwoods> if you see anyone in #fedora complaining about suspend/resume, get them into #fedora-triage and help get a bug reported
18:30 < craigt> I don't really care what app we start with...
18:30 < craigt> ciao
18:31 < che> good night
18:31 <@wwoods> so long folks, thanks very much for your help!
18:31 -!- craigt [n=cthomas@static-68-236-219-35.nwrk.east.verizon.net]  has quit ["Leaving"] 
18:31 < che> wwoods, a pleasure
18:31 < Lovechild> I can't believe I slept through the meeting
18:31 <@wwoods> Lovechild: haha, you're forgiven
18:31 < Lovechild> only woke up when wwoods dinged me
18:32  * dmalcolm goes to sleep
18:33 < Lovechild> wwoods: another thing that would be good.. bugzilla clean ups - have our testers pick one app a day and check every filed bug against it.