From Fedora Project Wiki
Attendees
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)
Regrets:
- Liam Li (lili)
- He Rui (rhe)
- David Pravec (dpravec)
- Adam Williamson (adamw)
Agenda
- Proposed meeting agenda
- [FIXME meetbot summary]
Preview Meeting follow-up
QA/Meetings/20091005#Action_items
- 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
- jlaska - sync-up with clumens to identify any blocking issues from https://www.redhat.com/archives/fedora-test-list/2009-October/msg00073.html
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 http://alt.fedoraproject.org/pub/alt/stage/. 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 israwhidebroken.com front-end (see https://fedorahosted.org/autoqa/ticket/65).
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 http://git.fedorahosted.org/git/?p=fedora-data.git). 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 israwhidebroken.com into the product instance (from a package standpoint). Wwoods noted that the content should correspond to the infrastructure turbogears SOP - http://fedoraproject.org/wiki/TurboGears_Infrastructure_SOP.
Packagediff update
kparal has implemented a majority of the important rpm checks (see https://fedorahosted.org/autoqa/ticket/54#comment:2)
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 install.py and sanity.py 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 - https://www.redhat.com/archives/fedora-test-list/2009-October/msg00112.html
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 israwhidebroken.com 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 http://wiki.debian.org/MeetBot. | 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 https://www.redhat.com/archives/fedora-test-list/2009-October/msg00194.html | 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 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=526899 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 http://poelstra.fedorapeople.org/schedules/f-12/f-12-releng-tasks.html | 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 | https://fedorahosted.org/autoqa/ticket/65 | 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. https://fedorahosted.org/pipermail/autoqa-results/2009-October/001438.html | 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 - http://git.fedorahosted.org/git/?p=fedora-data.git | 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 setup.py 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 israwhidebroken.com 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 http://fedoraproject.org/wiki/TurboGears_Infrastructure_SOP | 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: https://fedorahosted.org/autoqa/ticket/54#comment:2 | 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 https://fedorahosted.org/autoqa/ticket/54#comment:2) | 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 install.py independent of autoqa/autotest | 16:57 |
| wwoods | same with sanity.py | 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 - https://www.redhat.com/archives/fedora-test-list/2009-October/msg00112.html | 17:00 |
| jlaska | #info Viking_Ice started a great discussion around how best to improve the current Category:Debugging content - https://www.redhat.com/archives/fedora-test-list/2009-October/msg00112.html | 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 https://www.redhat.com/archives/fedora-test-list/2009-October/msg00112.html | 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 https://www.redhat.com/archives/fedora-test-list/2009-October/msg00152.html | 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 fedora-test-list@redhat.com for any additional issues | 17:26 |
| jlaska | #endmeeting | 17:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!