From Fedora Project Wiki

< QA‎ | Meetings


People present (lines said)

  • jlaska (160)
  • wwoods (58)
  • adamw (46)
  • Oxf13 (35)
  • Viking-Ice (24)
  • kparal (17)
  • jwb (7)
  • jeff_hann (4)
  • mether (3)
  • zodbot (3)
  • buggbot (2)
  • Jeff_S (2)
  • skvidal (1)



Previous meeting follow-up

See QA/Meetings/20091019#Action_items

  • jlaska to rename other debug pages (see to be consistent with "How to debug <component> problems". Update back-links also

I believe this task is complete. See Category:Debugging for feedback. I've also organized the pages by the component name.

Remaining Question - What do folks want to do with ... KernelBugTriage? Should this change to How to debug kernel problems

Viking_Ice locale test suggestion

Background -

Viking-Ice posted a sample script to demonstrate what an automated test should do (see Some discussion followed on where best to implement this additional automated test in AutoQA. The group felt that adding the test to Israwhidebroken.com_Proposal was not appropriate. Jlaska felt that this test would be best suited for the QA:Fedora_12_Install_Test_Plan, is it currently is light on i18n verification. Viking-Ice took an action item to create a test case and propose adding it to the test plan. Once added, that test can be included in upcoming automation efforts User:Liam and User:Rhe are investigating.

Milos Jakubicek suggestion on FTBFS bugs

Background - Milos Jakubicek suggested a day/project to work on filing FTBFS(fails-to-build-from-scratch) bugs for all remaining packages that failed to build in F12 mass rebuild (see Some discussion followed on what a QA effort around this might look like. F13 indicated he would have no problems tagging FTBFS rebuilds for F12. Mether provided a link to an existing effort (see FTBFS).

Unfortunately, Milos was not available during the meeting. Adamw took an action item to follow-up with Milos for next weeks meeting (or on fedora-test-list).

Marcela Maslanova test day proposal

Marcela Maslanova sent a test day proposal for including all tests in a package (see Marcela was not present for the meeting, and Jlaska indicated further power management test day feedback was expected from Phil Knirsch soon. Jlaska wanted to highlight that this was the first test day that included a test day rpm which provided scripts to automate test cases and test results collection.

Some outstanding questions for the group:

  1. Is there anything we need to be thinking or doing to support this type of work in the future?
  2. Where should the test scripts used to in test day packages live?

AutoQA Updates from wwoods and kparal

autoqa-devel list now active Wwoods reminded the group that the autoqa development mailing list for patch review, autoqa progress and test development. Join the autoqa-devel list and contribute today!.

RpmGuard update Kparal directed the group to a blog post detailing his current status on the rpmguard effort. Kparal received some feedback from the post, including:

The next task for Kparal is to investigate the koji-build watcher wwoods is working on and integrate rpmguard into autoqa to have it up and running.

Post-koji-build watcher Wwoods provided a brief update on the post-koji-build which picks up every new build in a set of koji tags specified by autoqa. Some discussion followed on between kparal and wwoods on how to pass data between the tests and the watcher script. Wwoods indicated his current post-koji-build watcher would be landing in autoqa.git soon.

AutoQA library Wwoods indicated a library would also be landing in git soon that takes a package NVR and a koji tag, and returns the previous released versions of that package. Wwoods also noted a plan to create a general purpose autoqa library for use by all tests with helpers for koji interaction and virt guest creation.

Critical Path Package List Due to recent questions around the current critical path package list, wwoods reminded the group about the script This script will solve the critical path package set and write output to critpath.txt. Jwb notified the group that he would be incorporating this script into the rawhide compose process. Future rawhide composes will include a critpath.txt file (e.g.

Open discussion - <Your topic here>

FUDCon Attendees

F13 asked who was planning to attend FUDCon. Since wwoods was planning for an AutoQA talk on how maintainers could add tests into PkgCVS, F13 would focus on the messagebus talk.

Upcoming QA events


  • 2009-10-30 - Blocker Bug Day (F12Blocker) #2

Action items

  • adamw will ask Milos to follow-up at next week's meeting or on the list on the FTBFS topic
  • Viking-Ice investigating creating a test case for bug#530452 ... and adding to F12 install matrix
  • wwoods to add roadmap/tickets for reworking shared autoqa code (watchers, test helper methods, etc) into a proper library

IRC Transcript

jlaska #startmeeting Fedora QA Meeting - QA/Meetings/20091026 16:08
zodbot Meeting started Mon Oct 26 16:08:23 2009 UTC. The chair is jlaska. Information about MeetBot at 16:08
zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:08
jlaska #chair adamw 16:08
zodbot Current chairs: adamw jlaska 16:08
jlaska #topic Gathering 16:08
jlaska hey gang, show of $limb ... who do we have joining today? 16:09
* jlaska notes ... Oxf13 indicated he would arrive late 16:09
* skvidal worries about this $limb thing 16:10
* kparal here 16:10
jlaska kparal: howdy 16:10
jlaska Viking-Ice: adamw: wwoods: and anyone else I'm forgetting 16:11
* Viking-Ice here.. 16:11
* wwoods is here 16:11
jlaska greetings gents 16:11
jlaska adamw might be running late, so just going to kick things off and he run things when he returns 16:12
jlaska skvidal: don't be afraid :) 16:12
jlaska I put adamw's proposed agenda on the wiki, and plan to just walk the list (see QA/Meetings/20091026) 16:12
jlaska starting with ... 16:12
jlaska #topic Previous meeting follow-up 16:12
jlaska I took an action item to rename the existing debug pages to the new format "How to debug <component> problems" 16:13
jlaska so I think we're good there 16:13
jlaska 16:13
jlaska there was 1 page left that I was unclear how folks wanted that 16:13
jlaska #info So the only open item on my list is ... should KernelBugTriage be renamed to How to debug kernel problems? 16:14
jlaska I'll follow up with cebbert before renaming that page 16:14
jlaska besides, I think that page is more about traiging and not so much debugging, but could be wrong 16:15
jlaska that's all I had recorded for last week, any other items before we dive into the agenda? 16:15
jlaska Okay ... then first topic up ... 16:16
jlaska #topic Viking_Ice locale test suggestion 16:16
jlaska #link 16:16
jlaska Viking-Ice: you raised this on f-t-list this past week, sounds like you felt this is something that could be automated? 16:17
Viking-Ice yup give me sec.. 16:17
jlaska sure 16:17
jlaska Viking-Ice: want us to come back to this topic? 16:20
Viking-Ice yup 16:20
jlaska alright ... I'll move that to the end 16:21
jlaska the next topic is around a discussion that milos Jakubicek and adamw had ... I'll save that for when Adamw returns 16:21
jlaska #topic Marcela Maslanova test day proposal 16:22
adamw morning - sorry, I overslept 16:22
jlaska adamw: welcome morning ... 16:22
jlaska you need a few minutes? Or should we jump back to the FTBFS topic? 16:22
adamw go for it 16:23
jlaska okay ... just a quick update on the current topic 16:23
jlaska pknirsch is will be providing a formal summary of last weeks power management test day 16:23
jlaska but I also received some updates from Marcela Maslanova around his experiences creating a test day rpm with automated scripts 16:24
jlaska not sure if everyone had a chance to participate in this last event ... there's always time to jump in 16:24
jlaska #link Test_Day:2009-10-22 16:24
kparal *her* experience :) 16:25
jlaska kparal: doh, thank you :) 16:25
jlaska Just a summary for me ... the test day was awesome from a preparation stand-point 16:26
jlaska you download a test day rpm ... and each of the tests was a script provided by the package 16:26
jlaska so, the only thing I wanted to raise here was just around building on this process 16:26
jlaska I know that not all test day topics are as easily automated 16:26
jlaska but certainly need help from folks in identifying ways to automate future test days in much the same format that Marcela and team have 16:27
jlaska installer might be one of those easy topics (w/ virt) 16:27
jlaska I suspect X might not be very easy 16:28
jlaska anyhow ... unless any other thoughts there ... let's jump back to FTBFS 16:28
jlaska #topic Milos Jakubicek suggestion on FTBFS bugs 16:28
jlaska adamw: you want to take it away? 16:28
adamw well it's milos' idea, but I can explain what he told me 16:29
jlaska go for it 16:29
adamw #link 16:29
adamw that's a list of remaining packages that did not rebuild in the f12 mass rebuild, with most false positives taken out (there's still a couple in there) 16:29
adamw milos' suggestion is that we make sure FTBFS (fails-to-build-from-scratch, it's a debian term) bugs are filed for each one 16:30
jlaska aha ... was trying to parse that acronym ... thx 16:30
adamw we didn't get into any details of how exactly to arrange it, but it seemed like a decent idea to me 16:30
adamw i suggested he come to the meeting to discuss it but obviously couldn't make it 16:31
jlaska I saw him earlier in #fedora-qa ... but he dropped off 16:31
Oxf13 here now. 16:32
adamw hi oxf13 16:32
adamw so, that's the idea, pretty much. if anyone has any thoughts go ahead 16:32
jlaska are these things that should be lined up prior to F-12 GA? 16:32
jlaska if they weren't rebuilt ... what's the fallout (packages that contain .fc11 in the name)? 16:33
adamw there's no terrible fallout, but making sure all packages build is good policy 16:33
jlaska esp given a recent self-hosting blog post 16:34
adamw it's possible some of them won't work any more till they get rebuilt, and if you leave it too long you wind up with a giant backlog of crusty packages (i speak from experience) 16:34
* Viking-Ice ready now :) 16:34
adamw doing it before f12 ga would be nice but not essential, they can always be pushed as updates and anyway it'd be good for future releases too 16:34
jlaska I'd be curious for Oxf13's take ... I know Jesse was closely involved with the mass rebuild 16:34
Oxf13 if they're non crit-path packages, I have no issue with tagging them up until we hit RC 16:35
* jlaska wonders if python-bugzilla can help here 16:35
adamw i think they all are, looking at the list, they're mostly pretty obscure 16:35
jlaska yeah 16:35
jlaska I don't see anything wrong with filing bugs to track this stuff, that's the suggestion right? 16:36
adamw jlaska: it may, except it's useful to provide a note of the build failure message in ftbfs bugs, which wouldn't be straightforward to automate. 16:36
adamw yes 16:36
jlaska adamw: good point 16:36
mether adamw, FYI 16:36
adamw although the idea is specifically to do it as a 'project' within QA, not just to say 'filing these bugs is a good idea'. though I didn't get milos' thoughts on specifically how he wanted to arrange it. 16:37
adamw mether: ah thanks 16:37
mether Matt Domsch does a mass rebuild now and then as a QA measure 16:37
adamw that seems to claim that bugs 'will' be filed, implying it happens automatically 16:37
mether he has scripts that do that 16:38
Oxf13 and he autofiles bugs for the failures. 16:38
adamw oh, yeah, milos did point to that same F12FTBFS list, but noted that there are 39 bugs on it 16:38
Oxf13 using python-bugizlla 16:38
adamw whereas the list of packages he provided is rather longer than 39 16:38
Oxf13 his pass happened a month or so before my pass 16:38
adamw #link 16:38
adamw anyway, i'm sensing we need milos to explain his idea more fully either at next week's meeting or on the ml :) 16:39
jlaska yeah, let's carry the topic fwd? 16:39
adamw ok 16:39
jlaska definitely open to the idea, but nothing tangible is coming to me other than one person walking down a list? 16:39
Oxf13 yeah, I haven't read the email yet 16:40
adamw it could be done as a group thing, but i think we should clarify whether it needs to happen and why his list is longer than the bugs filed by matt's thingy and so on 16:41
Oxf13 his list is longer because more things failed in my pass 16:41
Oxf13 and I didn't autofile bugs 16:41
adamw ah, ok. 16:41
adamw anyway, i'll take an action item to ask him to follow-up at next week's meeting or on the list 16:42
jlaska #action adamw will ask Milos to follow-up at next week's meeting or on the list on the FTBFS topic 16:42
jlaska okay, shall we jump back to Viking-Ice's topic? 16:43
jlaska #topic Viking_Ice locale test suggestion 16:43
jlaska #link 16:43
Viking-Ice basically this is what I had in mind.. 16:43
jlaska Viking-Ice: take it away my good man 16:43
Viking-Ice 16:43
* adamw -> biobreak 16:44
Viking-Ice A test case that checks if keyboard layout is correct after install reports if not 16:44
jlaska Viking-Ice: would we then want to iterate over installing using different lang/keymap settings ... and run this script? 16:44
jlaska #link 16:45
Viking-Ice I dont think we need to parse all of them 16:45
Viking-Ice a single test should suffice and we should be able to add this to a current installation test 16:46
jlaska Viking-Ice: for this test to fail now, you need to install with a non US lang and keymap? 16:46
Viking-Ice in the ks file set the keyboard to a none us layout ( keyboard is-latin1 ) 16:47
Viking-Ice jlaska: it's the other way around it fails if it's not what we defined in keyboard 16:48
jlaska Viking-Ice: seems like there is a enough to write a wiki Test_Case: for this 16:48
Viking-Ice why ? 16:48
Viking-Ice this should be automated 16:48
jlaska gotta have a test before you automate 16:48
jlaska Seems like it should be yeah 16:49
jlaska but if we just write automation with no background or indication of the steps required, it's not really clear for people outside the group why that test exists 16:49
Viking-Ice how do you wiki-fi for autoqa ? 16:49
jlaska well, for israwhidebroken ... we have QA:Rawhide_Acceptance_Test_Plan 16:49
jlaska once we have a test case, for me, the next step is determining where it's best to automate this 16:50
Viking-Ice guess it would be added here QA:Anaconda_package_install_test_case 16:50
jlaska whether it's a generally useful thing that affects how usable rawhide is - 'israwhidebroken' 16:50
Viking-Ice but ok 16:50
adamw Viking-Ice: no, that's a different test case. 16:50
adamw test cases should be single purpose, not a clump of different tests in one. 16:51
jlaska lili and rhe are currently looking into automating the current test matrix ... I think your case would fit perfectly there 16:51
Viking-Ice Basic Functionality <-- then ? 16:51
wwoods No. RATS is supposed to be a super-simple basic test 16:51
adamw it would be a new test case, with its own name. 16:51
Viking-Ice ah ok 16:51
wwoods you're talking about something for a more exhaustive test plan 16:51
jlaska yeah ... I'd see this case being added to the list here QA:Fedora_12_Install_Test_Plan 16:52
wwoods it's called the Acceptance Test Plan because it sets out the criteria for judging whether we can even accept a rawhide tree for *real* testing 16:52
wwoods you're talking about defining one of the cases for the *real* testing 16:52
wwoods which is awesome and exciting 16:52
wwoods but, yeah, falls outside of the rawhide acceptance test plan 16:52
jlaska Viking-Ice: that test matrix you see floating aroudn is something that would come into play after wwoods's rats plan 16:52
jlaska and it's light on validating any i18n tests ... it could use this 16:53
Viking-Ice ok what's usually done with the output from those test ( OK fail ) mailed etc.. 16:53
jlaska That's what they're investigating now ... very *early* stages 16:53
adamw the tests in the test matrix are done manually, you see Liam Li send out mails every so often for that testing 16:53
wwoods depends on how you write the test. right now it gets stuffed into the autotest UI; we have the RATS tests also sending email when they complete 16:54
wwoods you can decide what you want it to do 16:54
adamw autoqa tests are run regularly and results mailed to a special mailing list at present, but automating tests is more complex and hasn't been done for all tests yet 16:54
jlaska and I think you've got a good test case here to cover recent non-US lang/keymap failures 16:54
jlaska so it'll be a bit before we have the full test matrix automated 16:55
jlaska so I'd start with getting the test case defined and added to the install test plan 16:55
jlaska how do others feel? 16:55
Oxf13 worksforme 16:55
Viking-Ice this checks for what is essentially what maintainer asked for on bug 530452 16:55
buggbot Bug high, low, ---, jmccann, MODIFIED, Gnome sets the keyboard layout to USA after every log in 16:55
jlaska Viking-Ice: yeah, we certainly need more testing there 16:56
Viking-Ice so what additional steps do we take from here.. 16:57
jlaska basically, create a wiki test case and propose adding it to the current install test matrix 16:57
Viking-Ice ok 16:57
jlaska I think that's the first step 16:57
jlaska the follow-on steps will be around automating that large matrix ... I don't have any updates on that front, other than that's a topic Liam and Rui have started investigating 16:58
jlaska Viking-Ice: but this way, if we've go tthe test case ... it won't get lost 16:58
jlaska anyone want to take an action item to create the test case and request addition to the matrix? 16:58
Viking-Ice guess me I suppose with guided hand :) 16:59
jlaska hehe ... thanks! 16:59
adamw Viking-Ice: it's pretty straightforward to create a test case, it's just a wiki page based on a template; edit any existing test case to see how it's done 16:59
Viking-Ice or review patients :) 16:59
jlaska #link Template:QA/Test_Case 16:59
adamw Viking-Ice: but feel free to ping me if you're having trouble 16:59
jlaska #action Viking-Ice investigating creating a test case for bug#530452 ... and adding to F12 install matrix 17:00
buggbot Bug high, low, ---, jmccann, MODIFIED, Gnome sets the keyboard layout to USA after every log in 17:00
jlaska Viking-Ice: fedora-qa tickets will come into play here soon 17:00
jlaska once we have an idea on how to proceed on the matrix automation front 17:01
jlaska alright, any other updates on this topic, or shall we jump to autoqa? 17:01
jlaska okay ... autoqa time 17:02
jlaska #topic AutoQA Updates from wwoods and kparal 17:02
jlaska wwoods: kparal: what's up in your realm? 17:02
kparal ok, news from the rpmguard world: 17:02
kparal I have posted a blog about rpmguard 17:02
kparal 17:02
kparal and I also wrote to some mailing lists. 17:02
kparal maybe you have noticed 17:02
jlaska #link 17:03
kparal there was some feedback, skvidal posted me a link to his mungingdiff 17:03
kparal 17:03
kparal but I'm not sure if there are parts inside which I haven't already implemented in rpmguard 17:03
kparal also alexey torkhov suggested to leverage rpmsodiff in my tool. I have created a ticket for that, because I have decided to look at it a little later: 17:03
kparal 17:03
kparal the upcoming task is to look at the watcher wwoods is working on and integrate rpmguard into autoqa to have it up and running 17:04
jlaska #info the upcoming task is to look at the watcher wwoods is working on and integrate rpmguard into autoqa to have it up and running 17:04
wwoods so, yup - we've got a basic watcher for koji 17:04
wwoods it's ready to be run and picks up every new build in a set of koji tags that we specify 17:04
kparal so, for my script the important part would be to find out the version and the link of the previous package release. to have something to compare 17:05
wwoods right - the tests for that hook will likely get a package NVR and/or package name as input 17:05
wwoods but I'm writing a library to take e.g. a package NVR and tag and give you the previous released versions of that package 17:06
wwoods or rather, I have written that tool 17:06
kparal is it in the git atm? 17:06
wwoods and it will be available for use in post-koji-build tests 17:06
wwoods not yet 17:06
jlaska sweet 17:06
kparal looking forward to it 17:06
Oxf13 hrm. 17:06
wwoods I need to rearrange the autoqa library stuff a little bit so the tests can share code like this better 17:06
Oxf13 it might make more sense to compare to the previous shipped package, rather than the previous built package 17:06
wwoods Oxf13: I said "previously released" 17:07
Oxf13 (would make it a lot easier to discover too) 17:07
Oxf13 wwoods: oh sorry, missed that 17:07
kparal very good point, nice 17:07
wwoods to go into more detail: you give it a package name (e.g. "preupgrade") and a tag (e.g. "dist-f12-updates-candidate") 17:07
jlaska #info basic watcher for koji in place. picks up every new build in a set of koji tags that we specify 17:07
wwoods we have some data that indicates which other tags to check for that 17:08
wwoods i.e. "dist-f12-updates-candidate" -> "dist-f12" and "dist-f12-updates" (iirc) 17:08
Oxf13 wwoods: (not to distract, but wouldn't dist-f12-updates(-testing) be more appropriate? not all -candidate builds get shipped) 17:08
jlaska #info wwoods has a library soon to be added to git repo which takes a package NVR and tag and provides the previous released versions of that package 17:08
Oxf13 wow, n/m. 17:08
wwoods so then it asks koji for the NVR of the packages with those specific tags 17:08
wwoods right, the point is that the watcher sees the build land in -candidate 17:08
wwoods and the test can use this library call if it needs to know the corresponding version for -updates or -updates-testing or the GA 17:09
jlaska wwoods: cool, so it walks the tag inheritance chain? 17:09
wwoods not explicitly, no 17:09
wwoods we have to keep a mapping in autoqa that tells us which "parent" tags to check for a given -candidate 17:09
wwoods we already have a mapping like this in the other watchers 17:10
jlaska wwoods - keepin' it simple 17:10
wwoods e.g. 17:10
jlaska right on 17:10
wwoods so I'm thinking we need to move the data from line 30-76 17:10
wwoods which is also in 17:11
wwoods and keep a shared autoqa.repoinfo data structure 17:11
Oxf13 yeah, that sounds good 17:11
jlaska +1 17:11
Oxf13 we could make a watcher library 17:11
wwoods which may be provided by a config file (so we don't have to update the package just to tweak the inheritance/URLs/etc) 17:11
Oxf13 that includes the mapping, and any other common stuff, then each watcher script could import the library 17:11
wwoods Oxf13: yep, that's the plan - gonna have an autoqa library for the server-side stuff (watchers etc) 17:12
Oxf13 rock 17:12
Oxf13 it's like... real software development 17:12
wwoods and one for the test stuff (like the things in and 17:12
wwoods (and the proposed koji-interfacing stuff I mentioned for post-koji-build) 17:12
adamw Oxf13: maybe we need something to automatically check whether there's any bugs in it =) 17:12
Oxf13 adamw: crazy talk. 17:12
wwoods I should roadmap out this plan but I was upgrading my workstation to F12B last week 17:13
wwoods but yeah now that I think of it, I'm going to give myself an action to do that 17:13
* jlaska pulls out the meetbot action pen 17:13
jlaska wwoods: are these post things? 17:14
wwoods #action wwoods to add roadmap/tickets for reworking shared autoqa code (watchers, test helper methods, etc) into a proper library 17:14
jlaska oh thanks ... u did it for me :) 17:14
wwoods jlaska: yes, this is a different milestone in my opinion 17:14
jlaska #info update from mmcgrath on hardware the hardware delivery ... looking at Nov 20 17:15
wwoods oh also! I'd like to mention 17:15
wwoods which was rewritten to be dead stupid simple to use 17:15
wwoods you run that script, it solves critpath and writes critpath.txt 17:15
jlaska #link 17:16
Oxf13 I do believe jwb was going to integrate that with the rawhide compose 17:16
wwoods Oxf13: excellent! 17:16
Oxf13 so that we'd have a written out critpath just like we do the depsolve and repodiff 17:16
jwb yes. need to get back to that, but i've been sick 17:16
jlaska Oxf13: so that output would be in the mash log dir for each rawhide compose? 17:16
Oxf13 which would give us a static url, 17:16
Oxf13 jlaska: yes 17:16
jlaska delicious! 17:16
wwoods after warren's confusion using the months-old deplist.txt I had sitting in my people.fp.o page I want to make sure everyone knows how this works 17:16
Oxf13 "mash/rawhide" is a symlink that gets updated each compose 17:17
wwoods oh man that would be totally aces 17:17
jwb it will be dated, but yeah 17:17
jlaska thanks jwb 17:17
wwoods I'll do whatever I can to help get that integrated 17:17
wwoods dated as in it'll have a date on it 17:17
wwoods not "it'll be kind of old" 17:17
wwoods right? 17:17
jwb wwoods, you did a lot already. i just need to take your script and add it to the releng git repo, etc. yes, dated as in 'critpath-<date>.txt' 17:17
Oxf13 jwb: dated? What will be dated? 17:18
Oxf13 hrm. 17:18
jwb the file itself 17:18
Oxf13 jwb: it might be better to not date it, so that we have a static URL 17:18
Oxf13 it'll already be in a dated directory 17:18
wwoods it'll be in a datestamped *directory*.. yeah 17:18
jwb oh, true 17:18
jwb ok, wfm 17:18
jwb i was still going off of the 'will be on mirrors' idea 17:19
jlaska #info jwb working to integrate critpath script into daily rawhide compose process 17:19
jlaska wwoods: kparal: great updates thx ... anything else to note for the logs? 17:19
wwoods oh 17:20
wwoods autoqa-devel! 17:20
jlaska ah yes 17:20
wwoods 17:20
jlaska and atodorov gets points for being the first poster 17:21
jlaska I don't know if it needs this or not ... 17:21
jlaska #link 17:21
Oxf13 blah, more lists I should probably be on 17:21
* jeff_hann here...sorry I'm late 17:22
jlaska jeff_hann: thanks for joining ... just about to go to open floor 17:22
wwoods yeah, Yet Another Mailing List, but honestly we avoided it as long as we possibly could 17:22
wwoods and eventually determined that we really need a mailing list after all 17:22
jlaska Thanks for the updates wwoods and kparal ... lots of progress 17:23
jlaska so ... I'm going to skip ahead and jump back on the agenda 17:23
jlaska #topic Upcoming QA events - 2009-10-29 - i18n Test Day 17:23
jlaska #link Test_Day:2009-10-29 17:23
jlaska #info Looking for volunteers 17:24
jlaska Rui and Jens pulled together the test day wiki page. I think it looks pretty good 17:24
jlaska but we could use more volunteers to help with i18n testing this Thursday 17:24
jlaska if you're interested, feel free to add a watch to the wiki page 17:25
jlaska or add yourself to the cc list of the tracking ticket 17:25
adamw also poke any chinese/japanese/korean speakers you know :) 17:25
jlaska #link 17:25
jlaska adamw: yes please! 17:25
jlaska I'm personallyn not well versed in i18n verification ... so more eyes are needed to review the plan and propose changes 17:26
jlaska and of course ... help test :) 17:26
jlaska #topic Upcoming QA events - 2009-10-30 - Blocker Bug Day #2 17:26
jlaska Kudos to adamw and Oxf13 for walking through the list not once, but twice last week 17:26
adamw we are shooting for this blocker bug meeting to end slightly before the heat death of the universe 17:26
jlaska #link 17:27
jlaska adamw: ouch, no kidding :) 17:27
jlaska recap from last meeting ... 17:27
jlaska #link 17:27
jlaska Under the column ... how can I help ... 17:27
jlaska add block:F12Blocker for issues you feel affect a fair number of users, or are just plain embarrasing 17:28
jlaska If you are assigned or on the cc list of a blocker list bug ... you can help in advance by ensuring the bug is up-to-date 17:28
jlaska adamw: anything else you can think of? 17:28
adamw not really - more people coming to the meeting to help review the bugs is always welcome 17:29
jlaska agreed! 17:29
jlaska adamw: something about more eyes right? :) 17:29
adamw more eyes make all arguments longer, yes 17:30
jlaska bingo! 17:30
jlaska okay, moving along ... 17:30
jlaska #Topic Open discussion - <Your topic here> 17:30
jlaska anything else not covered that is of interest? 17:31
jlaska concerns, questions, complaints ... favorite color? 17:31
Oxf13 Who all is going to FUDCon ? 17:31
jeff_hann just for information value, I have several kernel bugs I'm working on 17:31
wwoods I'll be at FUDCon 17:32
Oxf13 wwoods: good, I want to get people talking about the message bus, and what kind of data you'd need from it for autoqa et al 17:32
adamw I am 17:32
adamw Jeff_S: wrong meeting, but did you get in touch with rjune regarding kernel triage in the end? 17:32
adamw grr 17:32
adamw jeff_hann: ^^^ 17:33
Jeff_S adamw: no :) 17:33
adamw Jeff_S: go away, WrongJeff =) 17:33
Jeff_S lol 17:33
jlaska heh 17:33
Oxf13 so I signed up to do an update on AutoQA, but since wwoods will be there, perhaps wwoods should take over that pitch? 17:33
jeff_hann :) 17:33
jeff_hann will do that 17:33
wwoods Oxf13: sure, I can do that 17:34
jlaska Oxf13: we're planning for a blitzkrieg of autoqa information for the FUDCon 17:34
wwoods we're hoping to be able to give a status update and demonstrate a prototype for how maintainers can add post-build tests right in pkgcvs 17:34
Oxf13 rock 17:34
jlaska okay gang ... I think we can put a fork in this meeting 17:35
jlaska thanks everyone for joining and providing your $0.02 17:35
jlaska As usual, minutes will be on the mailing list soon 17:36
adamw thanks jlaska 17:36
jlaska #endmeeting 17:36

Generated by 2.7 by Marius Gedminas - find it at!