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 [firstname.lastname@example.org] 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 [email@example.com] 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 [firstname.lastname@example.org] 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 [email@example.com] 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 [firstname.lastname@example.org] 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 [email@example.com] 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.