From Fedora Project Wiki

< QA‎ | Meetings


People Present (lines said)

  • jlaska (176)
  • wwoods (38)
  • Viking-Ice (26)
  • kparal (24)
  • Oxf13 (18)
  • gtirloni (4)
  • denise (3)
  • nirik (2)
  • iarlyy (2)
  • zodbot (2)
  • pknirsch (2)


  • Liam Li (lili)
  • He Rui (rhe)
  • David Pravec (dpravec)
  • Adam Williamson (adamw)


Preview Meeting follow-up


  • jlaska to catch up with mmcgrath on delivery of autoqa hardware to PHX

hardware shipment in transit to PHX2 ... jlaska and mmcgrath will work the next steps as hardware comes online

3 bugs from the Test_Day:2009-10-01_Anaconda/Features/StorageFiltering landed on the F12Beta blocker list, as well as 2 from the Test_Day:2009-10-08_RAID.

Oxf13 expressed concerns that recent blocker bugs could have been found prior to the freeze. Jlaska noted that we booked the F12 Beta freeze with several install test runs, including Test Results:Fedora 12 PreBeta Install, Test Results:Fedora 12 Beta TC Install before the Freeze, followed by Test_Day:2009-10-01_Anaconda/Features/StorageFiltering and Test_Day:2009-10-08_RAID after the freeze.

  • poelcat to check in on beta blocker status of 510249

Appears like this has been resolved

F-12-Beta RC1 QA strategy

RC ISO images are available and posted to However, we still have 1 unresolved anaconda bug on the blocker list (see RHBZ #526899). Denise informed the group that Dave Lehman was investigating this issue and should have an update this afternoon.

Jlaska noted that Liam and Rui have already started executing to plan for tests that are not specific to the release candidate ISO media (see Test_Results:Fedora_12_Beta_RC1_Install). Once we have confirmation on the final ISO media kit, Liam will announce to fedora-test-list and invite testers to contribute feedback into the wiki.

AutoQA update

Wwoods spent some time last week focusing on the preupgrade F-12-Beta blocking bug (see RHBZ #526208).

Focusing on a clean solution to provide a link to the autotest results on the autoqa-results emails and front-end (see

Wwoods also looking into posting critical path package list to the wiki - currently blocked since JSON doesn't allow edit/create pages. Jlaska provided a link to something mmcgrath shared a while back (see Wwoods noted this handles uploading to the trac instance, not mediawiki.

Jlaska noted he might need guidance from wwoods when it comes to how best to incorporate into the product instance (from a package standpoint). Wwoods noted that the content should correspond to the infrastructure turbogears SOP -

Packagediff update

kparal has implemented a majority of the important rpm checks (see

kparal taking project naming suggestions to replace the current packagediff name (candidates include: 'rpmguard', 'rpmjudge' or 'rpmblame')

Some discussion followed on how best to incorporate kparal's script into autoqa. Wwoods advised that the script should work by itself much like and do in current autoqa. From there, just create a wrapper script to handle the integration with autotest.

How_to_Debug_<component> wiki pages

Viking_Ice started a great discussion around how best to improve the current Category:Debugging content -

A proposed template exists for use as a guide for all future pages (see Template:How_to_debug)

Viking-Ice would like feedback on a naming convention for future pages. Candidates include: "How to debug <component>". or "component <component> problems" or "bug info <component>". Viking-Ice noted that campbecg helped define the different pages as:

 As a reporter, looking at the wiki, I would see a page called "Bug Info ComponentX" and 
 expect a page relating to known bugs on componentx, a page called "ComponentX Problems"
 to be full of known issues related to using componentx, and "How to Debug ComponentX" 
 at a howto about how to actually debug it"

Both gtirloni and jlaska confirmed and agreed that the How to debug <component scheme made the most sense and that changes could be made as needed, but felt there was enough information available to start fleshing out additional pages. Viking-Ice noted he would investigate markmc's Virtualization bug reporting page next.

Open floor - <your topic here>

Upcoming QA events

  • 2009-10-12 - F12 Beta go/no_go meeting (@ 18:00pm - rel-eng meeting)
  • 2009-10-13 - BugZappers/Meetings
  • 2009-10-14 - Beta Project Wide Release Readiness Meeting
  • 2009-10-15 - i18n Test Day

Action items

  • jlaska will investigate the 5 anaconda F12Beta issues to determine when the failures were introduced
  • jlaska to investigate packaging of for production instance
  • jlaska to request autoqa-devel@ for autoqa development discussion and patch review

IRC transcript

jlaska #startmeeting Fedora QA Meeting 16:00
zodbot Meeting started Mon Oct 12 16:00:05 2009 UTC. The chair is jlaska. Information about MeetBot at 16:00
zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00
jlaska #topic Gathering in the lobby 16:00
* kparal gathered 16:00
jlaska Howdy kparal 16:00
jlaska We will be without a few folks today, including lili, rhe, dpravec and adamw 16:01
jlaska who knows, that could make for a short meeting :) 16:01
jlaska wwoods: Viking-Ice: around? 16:01
* Oxf13 16:01
jlaska I think Oxf13 went on a breakfa ... nope 16:01
jlaska Oxf13: howdy! 16:01
* Viking-Ice here.. 16:02
Oxf13 jlaska: eating it now 16:02
* iarlyy Hi all 16:02
denise jlaska here ... 16:02
* wwoods around..ish 16:02
jlaska Viking-Ice: iarlyy: denise: wwoods: greetings folks, welcome 16:03
* pknirsch is a lurker and hides 16:03
jlaska pknirsch: we welcome lurkers 16:03
pknirsch :) 16:04
jlaska okay, let's get started 16:04
jlaska the script is available at 16:04
jlaska #topic Previous meeting follow-up 16:04
jlaska Just a few quick action items to walk through 16:04
jlaska # jlaska to catch up with mmcgrath on delivery of autoqa hardware to PHX 16:04
jlaska Had a short chat with mmcgrath about the game plan once the hardware arrives. That helped outline a few action items needed on my end in terms of preparing the AutoQA 'israwhidebroken' software environment 16:05
jlaska there are tickets already in the autoqa instance that are assigned to me ... I'd like to get some traction on the packaging and autotest-0.11 upgrade this week 16:06
jlaska but beta is the priority 16:06
jlaska #info hardware shipment in transit to PHX2 ... jlaska and mmcgrath will work the next steps as hardware comes online 16:06
jlaska next up ... 16:07
jlaska # jlaska - sync-up with clumens to identify any blocking issues from installer test days 16:07
jlaska I had a brief chat with a few folks from the anaconda-devel group for help in isolating blockers from the 2 previous installer test days 16:08
jlaska thanks to denise dlehman and clumens for help there 16:08
jlaska 3 bugs landed on the blocker list from the first anaconda storage test day 16:08
jlaska and I believe 2 of the bugs filed by greenlion landed last week 16:08
Oxf13 on this topic, I respectfully request we don't schedule these things during a freeze when there is minimal (one might say no) time to fix any of the issues found 16:08
Oxf13 it's a good way to guarantee a slip 16:09
jlaska so don't test during a freeze? 16:09
Oxf13 by all means test, but please schedule it /before/ the freeze 16:09
Oxf13 our freezes are extremely short 16:09
jlaska we did both this milestones 16:09
Oxf13 there really isn't time built in to freeze, test, spend 2 weeks fixing everything found, get a release out, unfreeze 16:09
jlaska we had 2 pre-freeze test events that Liam organized 16:09
jlaska #link Test_Results:Fedora_12_PreBeta_Install 16:10
jlaska #link Test_Results:Fedora_12_Beta_TC_Install 16:10
Oxf13 a test day like anaconda storage test day done after the freeze is about 100% guaranteed to cause a slip 16:10
jlaska and then we followed up with 2 installer test events to handle the post-freeze change 16:10
jlaska Oxf13: we have test coverage both before and after ... I'm not sure what else we can offer? 16:10
Oxf13 maybe I'm just grumpy 16:11
jlaska hah, it is early monday for ya! 16:11
Oxf13 but it really seemed like we waited until after the freeze happened to find some installer bugs that suddenly are beta blockers, when it was too late to fix them 16:11
Oxf13 unless these really are regressions from changes since we entered the freeze... 16:11
jlaska there were a good amount of changes since the Beta Test Compose and the pre-beta testing 16:12
jlaska all around the distro 16:12
Oxf13 yes, and that's expected given how fast Fedora moves 16:12
jlaska I'll look back at those 5 bugs that landed on the blocker list ... but I feel like this time we had the freeze book-ended with testing 16:12
Oxf13 but I'm still not convinced that the current or late added anaconda blockers were regressions since the TC 16:12
jlaska but it would be good to identify opportunities to locate those bugs sooner 16:12
jlaska another challenge all around is just time 16:13
jlaska it takes time to find and file good bug reports 16:13
jlaska it takes time to digest and act on good bug reports 16:13
jlaska we try our best to find the low hanging fruit first 16:13
jlaska #info Oxf13 expressed concerns that recent blocker bugs could have been found prior to the freeze 16:14
Oxf13 it just seemed like we were in good shape until the storage test day happened, and then it seemed that a number of beta worthy bugs popped up that basically caused instant slip 16:15
Oxf13 and I'm really wondering if those bugs were regressions or just stuff that didn't get tested until the test day 16:15
Oxf13 (when it was too late to fix them without slipping) 16:15
jlaska well, we had the best coverage we've ever had in the QA group with this test compose ... Test_Results:Fedora_12_Beta_TC_Install 16:16
jlaska I'll take an action item to look at the 5 bugs that were escalated to F12Beta related to anaconda and see if I can get more detail 16:16
jlaska #action jlaska will investigate the 5 anaconda F12Beta issues to determine when the failures were introduced 16:17
jlaska I'll hold off before taking any action there 16:17
jlaska okay ... next up ... I had poelcat checking in on a bz 16:18
jlaska # poelcat to check in on beta blocker status of 510249 16:18
jlaska and I think we already had some traction there (thanks mclasen) 16:18
jlaska that's all I had for last week 16:19
jlaska anything I missed someone else would like to discuss? 16:19
jlaska (from last week) 16:19
jlaska alright ... first up ... 16:20
jlaska #topic F-12-Beta RC1 QA strategy 16:20
jlaska We are waiting on clarification for the last remaining unresolved F12Beta blocking issue 16:20
jlaska which is ... 16:20
jlaska bug#526899 16:20
buggbot Bug medium, low, ---, anaconda-maint-list, NEW, Encrypted partitions has "Unknown" type in table and ext4 in editor 16:20
denise and most recent status ..<dlehman> denise: yes. I'm trying to figure out out how to debug on a live install. 16:21
jlaska that should let us know if we can proceed with the ISO's Oxf13 has composed already, or whether we can expect a new drop later today 16:21
jlaska denise: ah good, thanks for the update 16:21
jlaska denise: if dlehman needs systems/environment testing of a patch ... I'm more than willing to help out 16:22
denise jlaska, thanks .. 16:22
jlaska #info dlehman determining how to debug 526899 on a live install 16:22
jlaska so we'll stay tuned for an update on that issue 16:23
jlaska Liam has already constructed a Beta RC1 test matrix in preparation for the ISO drop 16:23
jlaska Liam, Rui and I have begun testing non-storage related use cases and recording results into the wiki 16:24
jlaska #link Test_Results:Fedora_12_Beta_RC1_Install 16:24
jlaska but with regards to the ISO drop, we'll wait for more news on this last bug 16:24
jlaska I believe today is the go/no_go ... Oxf13 ? 16:24
Oxf13 in theory 16:24
jlaska heh, in theory and in the schedule 16:25
jlaska #link 16:25
jlaska alright, that's really all I have on the Beta QA update ... Liam will have something out to the list once we have confirmation on the release candidate 16:26
jlaska Liam will outline a plan of attack for the test matrix ... I encourage folks to pitch in with a few tests on their systems 16:26
jlaska using live media, boot.iso, kvm ... whatever 16:27
jlaska any questions/concerns on the Beta? 16:27
jlaska alllrighty ... stay tuned to fedora-test-list for updates then 16:28
jlaska next up ... wwoods and kparal ... 16:28
jlaska #topic AutoQA Updates 16:28
jlaska wwoods you want to kick it off? 16:28
* wwoods checking notes 16:29
wwoods I've spent the past couple days working on that preupgrade blocker so I gotta remember what I was doing before that 16:29
jlaska heh, and yeah by the way ... way to pinpoint that issue! 16:30
wwoods yeah but it turns out to have some other side effects, *plus* I didn't test my patch (booooo) 16:30
wwoods so there will probably be a 1.1.1-4 build of preupgrade soon 16:30
jlaska #info wwoods isolated and patched the preupgrade issue (526208), another update coming in a 1.1.1-4 build of preupgrade 16:30
wwoods anyway, autoqa: still haven't found a satisfactory way to get a reference from a test back to the results of that test in the autotest frontend 16:31
jlaska wwoods: good catch finding that before beta 16:31
wwoods adding that info to the codepaths in autotest turns out to be a huge pain 16:31
wwoods but that's really the last code change needed for the first major milestone: 16:31
wwoods 16:32
* jlaska notes ... we need a tracbot 16:32
wwoods looking through the code has given me an idea for a simpler way to accomplish this 16:32
wwoods (I think zodbot knows how to deal with trac stuff but I don't know how it works) 16:32
wwoods when I get back to autoqa that's what I'll be looking at 16:32
wwoods I also set up a second instance on a separate machine just to make sure it's possible 16:33
jlaska very good 16:33
wwoods (it worked OK so far - gotta export the data off my workstation so I can reinstall my system with F12Beta) 16:33
jlaska wwoods: will this link back to the results on the autotest server also be posted into the autoqa-results output ... e.g. 16:33
* nirik notes zodbot just has basically aliases for trac urls so you can look up specific tickets in a trac instance currently. 16:33
wwoods jlaska: that's *kind of* the goal - links from israwhidebroken (and the emails) back to the full test results/logs 16:34
wwoods the emails themselves are really just a stopgap until we have Something Better 16:34
jlaska right on 16:35
jlaska dcantrell has been helping by looking into the rats_install/i386 failure ... this might be a good 'test case' to determine what info is needed by devel to assess problems 16:36
jlaska I'll follow-up with you if any ideas come up ... but it sounds like you've got the cases planned already 16:36
wwoods right on 16:36
jlaska wwoods: anything else new and exciting on the horizon in the world of AutoQA 16:37
wwoods well hopefully we'll have the production stuff coming online soon 16:38
wwoods so, yay, full test results 16:38
jlaska um ... yes ... awesome! :) 16:38
wwoods oh the other thing I was looking at was getting the critpath results put into a wiki page 16:38
wwoods python-fedora even has a nice Wiki client class 16:38
wwoods unfortunately it uses JSON and AFAICT you can't edit/create pages with the JSON format/methods 16:39
* nirik also notes zodbot can do rss feeds -> irc if that would be useful. ;) 16:39
jlaska wwoods: here's that link I mentioned from mmcgrath - 16:39
jlaska #info wwoods looking into posting critical path package list to the wiki - currently blocked since JSON doesn't allow edit/create pages 16:40
* Oxf13 has to step out for a house inspection. 16:40
jlaska Oxf13: good luck! 16:40
wwoods nice, I'll check that out 16:41
jlaska wwoods: I might need your skills later this week for some thoughts around packaging your israwhidebroken git repo for "production" 16:41
wwoods we're not packaging a repo 16:41
jlaska as you've seen before, Ican probably get it packaged ... but it might not be the "ideal" way of doing it 16:41
jlaska wwoods: no, I meant your TG code 16:41
wwoods as I understand it TG apps can be nicely packaged as with most python things 16:41
jlaska so just using setuptools? 16:41
wwoods it's got a and all 16:42
jlaska gotcha gotcha 16:42
jlaska heh, there we go ... that's something I can do :) 16:42
wwoods so yeah, AFAIK it's just a standard python-template RPM spec 16:42
jlaska nice 16:42
jlaska #action jlaska to investigate packaging of for production instance 16:42
jlaska wwoods: I don't know if that'll need an official non fedorapeople git repo ... or if it matters etc... 16:43
wwoods right, we'll see what the admin dudes think 16:43
jlaska roger 16:43
wwoods but yeah, this link describes what you need to do to set up a TG app in production: 16:43
wwoods #link 16:43
jlaska that's the one, thx 16:44
jlaska alright, shall we turn it over to kparal for an update on the project currently known as packagediff? 16:44
kparal ok 16:44
wwoods sure! 16:44
kparal Well, I have more or less implemented majority of the important checks for differences between rpm packages. You can see the progress here: 16:45
jlaska cool, thanks for the updates wwoods! 16:45
jlaska #topic AutoQA Updates (packagediff) 16:45
kparal There are surely many bugs in the moment, but I am just working on some fake rpm packages to test the script. So hopefully it will be flawless soon [joke]. 16:45
kparal When this is done, I plan to put the script into the public, so everyone can comment on that and tell me what I have done wrong :) And we can at the same time start to integrate it with AutoQA. 16:45
jlaska #info kparal has implemented a majority of the important rpm checks (see 16:45
kparal I would also like to rename 'packagediff' to something more suitable and maybe even funnier. If you have some idea other than my current 'rpmguard', 'rpmjudge' or 'rpmblame', let me know. 16:46
kparal The last thing is that my internship in Fedora QA will end soon and don't know yet if I will continue. The question is where to store the resulting script. I can leave it in my fedorapeople account, or I can publish it elsewhere. 16:46
jlaska #info kparal taking project naming suggestions (candidates include: 'rpmguard', 'rpmjudge' or 'rpmblame') 16:47
kparal :) 16:47
jlaska kparal: I don't know if this would make sense inside the autoqa project ... wwoods would be best for guidance there 16:47
iarlyy why not rpmdiff ? 16:48
kparal already exists 16:48
kparal and actually i am using rpmdiff's output 16:48
jlaska kparal: I would think long term ... having all your changes merged into rpmdiff would be ideal 16:49
jlaska that's my guess at least 16:49
kparal i believe so too, merged or available as another tool in rpmlint package 16:49
jlaska but I suspect we might need a location for the test script while/until those changes are integrated upstream 16:49
kparal right. it can be part of autoqa, or just somewhere privately hidden 16:50
kparal but it won't be so visible in that case 16:50
jlaska I think you've got the best 2 approaches on the table so far ... I guess that depends on what wwoods (autoqa) or skvidal (rpmlint) think? 16:51
kparal or maybe ville skytta 16:51
wwoods yeah if you just want to check it in somewhere, we can treat it like an autoqa test 16:51
kparal alright, that can be a good temporary solution 16:52
jlaska wwoods: does it fit the autoqa module to create a tests/rpmdiff (that has a wrapper that calls rpmlint's rpmdiff) 16:52
jlaska I think it does since that's one of those tests that is independent of a package 16:53
jlaska kparal: that might be a good segway into your next topic then ... integrating with autoqa 16:53
kparal you mean task. yes. 16:54
jlaska yeah, you got it 16:54
jlaska okay, I'll get off my butt and request autoqa-devel list now 16:54
wwoods jlaska: yeah, that would work. unfortunately we don't yet have a hook/watcher for post-build tests 16:54
wwoods but there's no harm in having a place for the test(s) to live 16:54
jlaska #action jlaska to request autoqa-devel@ for autoqa development discussion and patch review 16:55
jlaska wwoods: okay cool 16:55
kparal there is also one question 16:55
kparal do we want this script to be also available as a separate shell tool, or just integrated as autoqa test? 16:55
jlaska ideally, it will just be the 'rpmdiff' tool provided by rpmlint right? 16:55
kparal or maybe it can be done both at the same time 16:55
jlaska but the wrapper for the script (and short-term adjustments) might live in autoqa/tests/rpmdiff ? 16:56
jlaska at least that's my guess 16:56
kparal ok 16:56
kparal i got a little confused, forget it :) 16:56
jlaska wwoods is the expert there, but that seems sane-ish 16:56
wwoods no, the tool should definitely work as a normal shell tool 16:57
wwoods and then we write a nice autoqa wrapper for it 16:57
kparal right, i see now 16:57
jlaska ah okay ... so there's an extra layer 16:57
jlaska kparal: doh! sorry :( 16:57
wwoods just like the install test.. you can just run independent of autoqa/autotest 16:57
wwoods same with 16:57
kparal ok. that's all from me i believe. 16:58
jlaska kparal: okay, thanks for the update ... and nice job working down the different comparative tests 16:59
jlaska alright, next up I asked Viking-Ice for his thoughts on the next-steps on the "How_to_Debug_<component>" thread 16:59
jlaska #topic How_to_Debug_<component> wiki pages 16:59
jlaska Viking-Ice: got a few minutes to discuss what the next steps needed are on that front? 17:00
jlaska # info Viking_Ice started a great discussion around how best to improve the current Category:Debugging content - 17:00
jlaska #info Viking_Ice started a great discussion around how best to improve the current Category:Debugging content - 17:00
jlaska uh oh ... did we loose Viking-Ice? :( 17:01
* Viking-Ice takes a sip of an hour (c)old coffee which only makes you stronger.. 17:02
jlaska eeew 17:02
jlaska :) 17:02
jlaska Viking-Ice: hey there! 17:02
Viking-Ice Greetings 17:02
jlaska Viking-Ice: didn't mean to put you on the spot, but wanted to give you a chance to talk about where things are on that thread ... and what's needed to move forward 17:03
Viking-Ice hang on a sec.. 17:03
Viking-Ice so 17:04
Viking-Ice The things are just stuck on minor details.. I think the general look and feel is ok 17:04
jlaska might I add a big kudos on the template 17:05
jlaska #link Template:How_to_debug 17:05
Viking-Ice more or less based on the Dracut page.. 17:05
jlaska again, which you started 17:05
Viking-Ice the naming 17:05
jlaska I'm sensing a trend! 17:06
Viking-Ice How to debug. or component X problems or bug info component is a bit holding it back.. 17:06
jlaska I can respond, but I liked the preference list you posted 17:06
jlaska #info Viking-Ice would like feedback on a naming convention for future pages. Candidates include: "How to debug <component>". or "component <component> problems" or "bug info <component>" 17:07
* gtirloni votes for how to debug <component> 17:08
* jlaska seconds that vote 17:08
Viking-Ice I share the same view as campbecg "As a reporter, looking at the wiki, I would see a page called "Bug Info ComponentX" and expect a page relating to known bugs on componentx, a page called "ComponentX Problems" to be full of known issues related to using componentx, and "How to Debug ComponentX" at a howto about how to actually debug it" 17:08
Viking-Ice as he mentioned in thread 17:09
jlaska yeah, that's a good breakdown 17:09
jlaska and it seems like the content of these pages falls under "a howto about how to actually debug it"? 17:09
Viking-Ice an components single report/debug page for a reporter 17:10
jlaska I don't follow, can you explain that last point? 17:11
Viking-Ice this is not just a components debug guide 17:11
Viking-Ice as you can see here How_to_Debug_Thunderbird 17:11
jlaska so there sometimes might be content that would be better to share with other debug guides? 17:12
Viking-Ice As I see it this is the how_to_debug_ pages should be a single pages refereed to reporter by maintain/triager to gather the needed info to file a proper report 17:12
jlaska Viking-Ice: we're missing some of the folks involved in that thread, including beland and adamw 17:13
jlaska but we can include what the next obstacle is for moving forward in the minutes and working that out of meeting 17:14
Viking-Ice well the naming and the debugging are more less what's holding it back 17:14
gtirloni can we have the template dictate the big sections and let each writer to work out the details for each package? 17:15
jlaska Feels like the naming of the pages is answered by campbecg's definitions 17:15
Viking-Ice You need to more or less adjust it to each component 17:16
jlaska to gtirloni's point, I think the template you started offers a really good starting point that we can let subject matter experts expand on 17:16
Viking-Ice hence having a template is no go other than being an skeleton to copy and paste 17:16
jlaska it's hard to restrict what the content of each page will look like without content for each page 17:17
Viking-Ice the debugging output stops 17:17
Viking-Ice ups 17:17
jlaska so maybe we choose a approach now ... and set a point to readjust/reassess? 17:17
Viking-Ice the debugging can more or less be a template 17:17
jlaska okay, if no objections ... let's start wrapping things up for today 17:18
Viking-Ice I would say we go with how_to_debug to move on with that objections ? 17:18
jlaska Viking-Ice: yeah I think that's a sensible plan based on the feedback to the list so far 17:19
jlaska and nothing speaks better than proven examples 17:19
gtirloni indeed 17:19
Viking-Ice I would want to have a bit more feed back from reporters on how they want to have it since they are the once that actually are going to be using those pages 17:19
jlaska and it's no big deal really ... if a few months from now it turns out we didn't make the _perfect_ choice ... we can always correct 17:19
jlaska Viking-Ice: perhaps picking the most frequently reported components from bugzappers? 17:20
gtirloni it's probably going to require many iterations to get it right.. that's normal. I think we've a very good template in place 17:20
jlaska #info Viking-Ice would like more feedback from reporters on what Debug pages to see next 17:20
jlaska gtirloni: agreed 17:20
jlaska Viking-Ice: okay anything else you'd like to include in the minutes? 17:20
Viking-Ice I was more less speaking about the how_to_debug pages not which component go tackle next 17:21
jlaska ah, so more feedbcak on the naming convention then? 17:21
Viking-Ice I was going to start work on critical path components but I probably will start on virtualzation as markmc ask for 17:21
jlaska good point 17:21
jlaska #info Viking-Ice may focus attentiong on improving the existing Virtualization bug reporting guide 17:22
Viking-Ice jlaska: not the naming more on the template itself as basis but as you pointed out we can redesign it later if necessary.. 17:22
jlaska Viking-Ice: I'd suggest going with what you've go there now (inherited from the dracut debug page) 17:22
jlaska and should the Virtualization work poke some holes in the template ... we can raise issues as needed there 17:22
jlaska okay ... let's open up the floor 17:23
jlaska #topic Open Discussion - <your topic here> 17:24
jlaska Viking-Ice: thanks for the status update on the debug thread! 17:24
jlaska alright, before we wrap up ... any other topics not yet discussed? 17:24
jlaska going once ... 17:25
kparal :) 17:25
jlaska ... twice ... ;) 17:25
jlaska okay ... let's close it out for today 17:26
jlaska thanks folks for your time and updates 17:26
jlaska follow-up to #fedora-qa or for any additional issues 17:26
jlaska #endmeeting 17:26

Generated by 2.7 by Marius Gedminas - find it at!