Fedora QA Meeting Date: 2009-06-24 Time: 16:00 UTC (12 EDT) Location: #fedora-meeting on irc.freenode.net
1. Previous meeting follow-up ... https://fedoraproject.org/wiki/QA/Meetings/20090617
2. Fedora 12 QA schedule changes - https://www.redhat.com/archives/fedora-test-list/2009-June/msg00507.html
3. AutoQA - update from wwoods
4. Test Day SOP draft - update from awilliam
5. Improve Bug Reporting proposal - update from viking_ice
6. <Your topic here>
Hope to see you there.
Thanks, James
On Jun 23, 2009, at 22:02, James Laska jlaska@redhat.com wrote:
Fedora QA Meeting Date: 2009-06-24 Time: 16:00 UTC (12 EDT) Location: #fedora-meeting on irc.freenode.net
1. Previous meeting follow-up ... https://fedoraproject.org/wiki/QA/Meetings/20090617 2. Fedora 12 QA schedule changes - https://www.redhat.com/archives/fedora-test-list/2009-June/msg00507.html 3. AutoQA - update from wwoods 4. Test Day SOP draft - update from awilliam 5. Improve Bug Reporting proposal - update from viking_ice 6. <Your topic here>Hope to see you there.
I will miss this due to fudcon Berlin.
-- Jes
Full IRC transcript available at https://fedoraproject.org/wiki/QA/Meetings/20090624.
= Attendees =
* (Southern_Gentlemen) * Jóhann Guðmundsson (viking-ice) * Will Woods (wwoods) * Seth Vidal (skvidal) * James Laska (jlaska) * John Poelstra (poelcat)
Regrets: * Adam Williamson (adamw) * Jesse Keating (f13)
= Agenda =
[https://www.redhat.com/archives/fedora-test-list/2009-June/msg00652.html Proposed meeting agenda]
== Previous meeting follow-up ==
* [jlaska] - update [[QA/Goals]] wiki document No traction over the last week. Still a high priority item for jlaska. Lot's great things happening in QA, and some common themes around them. Just looking for a concise way to document those efforts into a single page.
* [wwoods] - updates on Rawhide acceptance test plan
Test plan: https://fedoraproject.org/wiki/QA:Rawhide_Acceptance_Test_Plan created. Some feedback on fedora-test-list helped shape the list of tests to include.
Viking_ice asked if we forgot to include a test for network connectivity as a basic functionality test?
== Fedora 12 QA schedule changes ==
https://www.redhat.com/archives/fedora-test-list/2009-June/msg00507.html
* wwoods asked if additional blocker bug days were listed * Viking_ice and jlaska both were on the fence with regards to whether or not to include test days in the formal Fedora schedule. Viking_ice suggested test days need more flexibility currently when it comes to the schedule. * poelcat hilighted the second change in the schedule around compose checkpoints during each milestone.
The next step will be to propose the schedule changes to rel-eng. If approved, we then work to plan around the changes.
== AutoQA - update from wwoods ==
https://fedorahosted.org/autoqa
Wwoods provided an update on where the autoqa project is. Real Soon Now we'll be trying to write some test code and wikifying what we learn about writing tests for autotest. I expect next meeting (or the one after that) we may have some test code and/or results to show and a list of cases we need help writing.
Additionally, writing test cases in the wiki has already started and will be ongoing.
Wwoods intends to solicit volunteers to help with defining test cases, and once defined, automating the test cases. Anyone with a little python skill can likely contribute.
== Test Day SOP draft - update from awilliam ==
Adamw was unable to make the meeting, but sent a quick update to the mailing list on a Fedora Test Day SOP document. Adam's draft email can be found https://www.redhat.com/archives/fedora-test-list/2009-June/msg00662.html. Please pass along any constructive feedback to the mailing list.
== Improve Bug Reporting proposal - update from viking_ice ==
https://fedoraproject.org/wiki/User:Johannbg/QA/Improve_reporting
Viking_ice introduced several topics noted in the above document. All topics outline areas where improvements could be made around bug reporting.
Viking_ice provided good news for those concerned about the look'n'feel of the bugzilla reporting page. Bugzilla-3.4 intends to simplify this view (see http://lpsolit.wordpress.com/2009/05/24/simpler-form-to-file-bugs-in-bugzill...).
Jlaska asked what specific feedback viking_ice was interesting in, and suggested possibly teaming up with the BugZappers since several of the proposed ideas line up with BugZapper goals.
Viking_ice asked whether the abrt tool could be used to improve bug reporting.
Viking_ice summarized by saying ''we need to come up with some plans on how to gather the info from maintainers on what they want on their reports on how to get that info from them.'' and pointed to [[User:Johannbg/QA/Kernel]] as an example based on j-rod's suggestion from the Fedora 11 retrospective meeting.
Jlaska suggested having a way to catalog content (e.g. debugging tips, or bug filing tips) for testers to easily find could be a great start.
== Open discussion ==
=== Target Audience for israwhidebroken.com? ===
Viking_ice asked who are the target audience with israwhidebroken.com and what is being hope to accomplish with that? Adding that we, as testers, know that rawhide is largely broken before beta.
Jlaska suggested pulled content from the [[Israwhidebroken.com_Proposal| IRB.COM FAD proposal]] ... ''Provide a single, well-known location with information about whether or not Rawhide is broken, and a link to the last known-good Rawhide tree.'' Jlaska summarized, ''for me ... it's all about consistently gathering data to facilitate decision making.''
= Upcoming QA events =
* 2009-06-30 - [[BugZappers/Triage_days]] * 2009-07-01 16:00 UTC - Next QA Meeting [[QA/Meetings/20090701]]
= Action items =
* [viking_ice] - check-in with abrt * [wwoods] - add post-install network test to basic functionality in rawhide acceptance plan * [jlaska] - update [[QA/Goals]] wiki document
On 06/24/2009 06:35 PM, James Laska wrote: <snip> ..... </snip..
HOLD THE PRESSESS ;)
There seems to be a bit miss summation here..
So to get one thing clear this is the problem that we are faced with ( taken from my improve_reporting page )
"Lack of needed information for maintainer(s) to be able to successfully work with the report."
The reason for the lack of the needed information on a report is in most cases simply that the reporter has not a clue what to include in the report itself and is not mandatory to provide that information.The underlying problem is not the reporter nor the triager which often ask the reporter to include wrong information because the triager has no better clue what to include in the report so he ask for the most common include case ( usually to include /var/log/messages). The problem is that the maintainer(s) them self have failed to provide this information or has done so only to the reporter on a report bases.When a maintainer introduces a component into Fedora it should be mandatory for him to provide this information along with how to enable debug output and to provide test plans for the component.
Viking_ice asked whether the abrt tool could be used to improve bug reporting.
Hum I never asked if abtr could be used to improve bugs it goes without saying that any automated bug reporting tool does as long as it works.. I was asking if any one knew how abrt is solving this problem. wwoods mentioned that "IIRC they had (or were planning to have) plugins or conf files that specify what files to attach" Which does not solve the problem they just pass the burden to the maintainer to write that plugin or config file or us and since we need to have that info in other places like bugzilla then it's question if we should not gather that info from maintainers perhaps file a bug against all components in bugzilla and asking the maintainer for that info and we then we would write that plugin or config file or abrt would fetch the info for that in the same db as bugzilla would?
Viking_ice summarized by saying ''we need to come up with some plans on how to gather the info from maintainers on what they want on their reports on how to get that info from them.'' and pointed to [[User:Johannbg/QA/Kernel]] as an example based on j-rod's suggestion from the Fedora 11 retrospective meeting.
I was not refering to my QA/Kernel in a conjunction with the above problem. I just mentioned that I had also started on https://fedoraproject.org/wiki/User:Johannbg/QA/Kernel https://fedoraproject.org/wiki/User:Johannbg/QA/Kernelin regards to j-rods wish on the F11RR meeting
Jlaska suggested having a way to catalog content (e.g. debugging tips, or bug filing tips) for testers to easily find could be a great start.
JBG
Thanks for the corrections, I've updated the minutes accordingly.
Thanks, James
On Wed, 2009-06-24 at 23:08 +0000, "Jóhann B. Guðmundsson" wrote:
On 06/24/2009 06:35 PM, James Laska wrote:
<snip> ..... </snip..
HOLD THE PRESSESS ;)
There seems to be a bit miss summation here..
So to get one thing clear this is the problem that we are faced with ( taken from my improve_reporting page )
"Lack of needed information for maintainer(s) to be able to successfully work with the report."
The reason for the lack of the needed information on a report is in most cases simply that the reporter has not a clue what to include in the report itself and is not mandatory to provide that information.The underlying problem is not the reporter nor the triager which often ask the reporter to include wrong information because the triager has no better clue what to include in the report so he ask for the most common include case ( usually to include /var/log/messages). The problem is that the maintainer(s) them self have failed to provide this information or has done so only to the reporter on a report bases.When a maintainer introduces a component into Fedora it should be mandatory for him to provide this information along with how to enable debug output and to provide test plans for the component.
Viking_ice asked whether the abrt tool could be used to improve bug reporting.
Hum I never asked if abtr could be used to improve bugs it goes without saying that any automated bug reporting tool does as long as it works.. I was asking if any one knew how abrt is solving this problem. wwoods mentioned that "IIRC they had (or were planning to have) plugins or conf files that specify what files to attach" Which does not solve the problem they just pass the burden to the maintainer to write that plugin or config file or us and since we need to have that info in other places like bugzilla then it's question if we should not gather that info from maintainers perhaps file a bug against all components in bugzilla and asking the maintainer for that info and we then we would write that plugin or config file or abrt would fetch the info for that in the same db as bugzilla would?
Viking_ice summarized by saying ''we need to come up with some plans on how to gather the info from maintainers on what they want on their reports on how to get that info from them.'' and pointed to [[User:Johannbg/QA/Kernel]] as an example based on j-rod's suggestion from the Fedora 11 retrospective meeting.
I was not refering to my QA/Kernel in a conjunction with the above problem. I just mentioned that I had also started on https://fedoraproject.org/wiki/User:Johannbg/QA/Kernelin regards to j-rods wish on the F11RR meeting
Jlaska suggested having a way to catalog content (e.g. debugging tips, or bug filing tips) for testers to easily find could be a great start.
JBG
fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
On Wed, 2009-06-24 at 23:08 +0000, "Jóhann B. Guðmundsson" wrote:
The reason for the lack of the needed information on a report is in most cases simply that the reporter has not a clue what to include in the report itself and is not mandatory to provide that information.The underlying problem is not the reporter nor the triager which often ask the reporter to include wrong information because the triager has no better clue what to include in the report so he ask for the most common include case ( usually to include /var/log/messages). The problem is that the maintainer(s) them self have failed to provide this information or has done so only to the reporter on a report bases.When a maintainer introduces a component into Fedora it should be mandatory for him to provide this information along with how to enable debug output and to provide test plans for the component.
I think you've definitely accurately identified a problem here and it's important to improve this situation, but making things compulsory for maintainers isn't always the best way to go :). For instance, I recently added congruity as a package to Fedora (didn't push any builds yet, I'll do it soon). If I'd had to fill out some form to explain what info should be provided in the case of bugs, that would have just felt like another annoying hoop to jump through. I also might not really _know_ what to put there, yet, since I haven't seen what it does when it doesn't work right, so I'm not really sure how I'd go about diagnosing a problem. But if it were to happen, I'd work it out.
So I'd say it's more something we should figure out a process for triagers and maintainers to work on together, without beating anyone over the head with a stick. We should be taking the initiative in asking our maintainers what information they need on reports for the components we work on. If they're not replying to these questions, we should ask if there's something wrong with how we're asking them, and if not, take it to the appropriate level to explain why we really need co-operation from maintainers on this. Rather than jumping straight to getting out the big stick :)
If a triager were to develop a sudden desire to triage bugs on any package I maintained, and came and asked me in a productive way what sort of information would be required on bugs of the kind BUG_REPORT_X, I'd happily help out with that, and I think most maintainers probably would. But asking them to do it cold when initially importing a package might be a bit different.
On 06/25/2009 04:25 PM, Adam Williamson wrote:
On Wed, 2009-06-24 at 23:08 +0000, "Jóhann B. Guðmundsson" wrote:
<snip> ... </snip>
First of all if an individual brings a component into Fedora and does not know how or what's needed to effectively debug and work on the component he's about to expose to the whole Fedora userbase the component ( unless it's being introduced and maintained by some one that does ) should not be allowed to be brought into Fedora.
We are faced with the fact that we need to play catchup with what ca 5000 - 7000 components and to be able to effective in doing so we need to draw the line NOW and start requiring packagers to provides us with that information when the component gets accepted and included in Fedora so we dont have to start chasing the NEW components after we finished with the old ones..
I think asking for some competence/responsibility from packagers is not to much! After all is exposing this to thousand, hundreds of thousand millions of users and he needs to be competent enough to handle the reports that flow in bugzilla against the component he introduced.
Jóhann " The man that lacks the ability to be subtle" Guðmundsson
On Thu, 2009-06-25 at 17:37 +0000, "Jóhann B. Guðmundsson" wrote:
I think asking for some competence/responsibility from packagers is not to much! After all is exposing this to thousand, hundreds of thousand millions of users and he needs to be competent enough to handle the reports that flow in bugzilla against the component he introduced.
There's a difference between competence and knowledge. If someone were to report a bug in the package I discussed a bit ago, from the report I'd probably know what to ask to figure out what was going wrong, and then - if it were likely to apply to future reports - I'd add that information to the 'what information to ask for on bug reports for this issue' page. So I'd consider myself competent enough to generate the knowledge in the appropriate circumstance. But it's harder to work entirely on theory - 'Imagine something's gone wrong. Now, what's the first question you'd ask?'...that's a bit harder. Usually, the information you get from someone when something actually goes wrong is important in figuring out what question you're going to ask to figure out how to fix it, and it's easier to identify patterns in what information you need in _retrospect_ rather than in advance. For me, anyway. It may be that this is different for others.
On 06/25/2009 05:48 PM, Adam Williamson wrote:
On Thu, 2009-06-25 at 17:37 +0000, "Jóhann B. Guðmundsson" wrote:
I think asking for some competence/responsibility from packagers is not to much! After all is exposing this to thousand, hundreds of thousand millions of users and he needs to be competent enough to handle the reports that flow in bugzilla against the component he introduced.
There's a difference between competence and knowledge. If someone were to report a bug in the package I discussed a bit ago, from the report I'd probably know what to ask to figure out what was going wrong, and then - if it were likely to apply to future reports - I'd add that information to the 'what information to ask for on bug reports for this issue' page. So I'd consider myself competent enough to generate the knowledge in the appropriate circumstance. But it's harder to work entirely on theory - 'Imagine something's gone wrong. Now, what's the first question you'd ask?'...that's a bit harder. Usually, the information you get from someone when something actually goes wrong is important in figuring out what question you're going to ask to figure out how to fix it, and it's easier to identify patterns in what information you need in _retrospect_ rather than in advance. For me, anyway. It may be that this is different for others.
The ultimate goal ( atleast from my stand point ) is to make it mandatory for a reporter to attache the needed file to be successfully able to work with the report from the start! A reporter is filling a bug, bugzilla checks if the file(s) the maintainer needs to have, have been attached to the report if not reporter is not able to submit the report. This eliminates unneeded/unwanted word games between maintainer and reporter ( or triager and reporter if you will ) and provides the maintainer with something to work with other than potentially half baked description of the underlying issue from an inexperienced reporter..
Jóhann "Still lacking the subtle part" Guðmundsson
On Thu, 2009-06-25 at 18:05 +0000, "Jóhann B. Guðmundsson" wrote:
On 06/25/2009 05:48 PM, Adam Williamson wrote:
On Thu, 2009-06-25 at 17:37 +0000, "Jóhann B. Guðmundsson" wrote:
I think asking for some competence/responsibility from packagers is not to much! After all is exposing this to thousand, hundreds of thousand millions of users and he needs to be competent enough to handle the reports that flow in bugzilla against the component he introduced.
There's a difference between competence and knowledge. If someone were to report a bug in the package I discussed a bit ago, from the report I'd probably know what to ask to figure out what was going wrong, and then - if it were likely to apply to future reports - I'd add that information to the 'what information to ask for on bug reports for this issue' page. So I'd consider myself competent enough to generate the knowledge in the appropriate circumstance. But it's harder to work entirely on theory - 'Imagine something's gone wrong. Now, what's the first question you'd ask?'...that's a bit harder. Usually, the information you get from someone when something actually goes wrong is important in figuring out what question you're going to ask to figure out how to fix it, and it's easier to identify patterns in what information you need in _retrospect_ rather than in advance. For me, anyway. It may be that this is different for others.
The ultimate goal ( atleast from my stand point ) is to make it mandatory for a reporter to attache the needed file to be successfully able to work with the report from the start! A reporter is filling a bug, bugzilla checks if the file(s) the maintainer needs to have, have been attached to the report if not reporter is not able to submit the report. This eliminates unneeded/unwanted word games between maintainer and reporter ( or triager and reporter if you will ) and provides the maintainer with something to work with other than potentially half baked description of the underlying issue from an inexperienced reporter..
Yeah, I don't think I explained it very well and it's not really the most important thing anyway. Let's try and work on collecting the information as the most important thing. For BugZappers - have you checked the page I mentioned in my other reply in this thread, to see if the necessary information for your components are listed there? If there's some information that's often needed in reports relating to a component you triage, make sure it has a page where this is explained, following the style already used. Then you can point people to that to explain what they should include, and it'll be available for others to refer to.
On Thu, 25 Jun 2009 20:26:42 +0100 Adam Williamson awilliam@redhat.com wrote:
Yeah, I don't think I explained it very well and it's not really the most important thing anyway. Let's try and work on collecting the information as the most important thing. For BugZappers - have you checked the page I mentioned in my other reply in this thread, to see if the necessary information for your components are listed there?
Speaking of which, I've made a few changes to https://fedoraproject.org/wiki/Xorg/Debugging and I'm still unhappy about the result. I think it's still cluttered.
Could you guys please have a look and bring some clarity ?
Cheers
François
On Thu, 2009-06-25 at 23:06 +0200, François Cami wrote:
On Thu, 25 Jun 2009 20:26:42 +0100 Adam Williamson awilliam@redhat.com wrote:
Yeah, I don't think I explained it very well and it's not really the most important thing anyway. Let's try and work on collecting the information as the most important thing. For BugZappers - have you checked the page I mentioned in my other reply in this thread, to see if the necessary information for your components are listed there?
Speaking of which, I've made a few changes to https://fedoraproject.org/wiki/Xorg/Debugging and I'm still unhappy about the result. I think it's still cluttered.
Could you guys please have a look and bring some clarity ?
Your re-arrangement looks great to me, thanks for that - I can think of a possible way to maybe clarify it a bit more, I'll try to work on that tomorrow and see if it works. But good job!
On Thu, 2009-06-25 at 23:06 +0200, François Cami wrote:
On Thu, 25 Jun 2009 20:26:42 +0100 Adam Williamson awilliam@redhat.com wrote:
Yeah, I don't think I explained it very well and it's not really the most important thing anyway. Let's try and work on collecting the information as the most important thing. For BugZappers - have you checked the page I mentioned in my other reply in this thread, to see if the necessary information for your components are listed there?
Speaking of which, I've made a few changes to https://fedoraproject.org/wiki/Xorg/Debugging and I'm still unhappy about the result. I think it's still cluttered.
Could you guys please have a look and bring some clarity ?
Your re-arrangement looks great to me, thanks for that - I can think of a possible way to maybe clarify it a bit more, I'll try to work on that tomorrow and see if it works. But good job!
One quick note: English style differs from French in a few ways. One common one - in English, it's not normal to have a space before a question mark (or anything else...there's another punctuation mark where this is different, but I can't remember which one it is). There's a few other things I can't quite think of right now, I'll let you know if I remember them.
On Thu, 25 Jun 2009 22:36:44 +0100 Adam Williamson awilliam@redhat.com wrote:
On Thu, 2009-06-25 at 23:06 +0200, François Cami wrote:
On Thu, 25 Jun 2009 20:26:42 +0100 Adam Williamson awilliam@redhat.com wrote:
Yeah, I don't think I explained it very well and it's not really the most important thing anyway. Let's try and work on collecting the information as the most important thing. For BugZappers - have you checked the page I mentioned in my other reply in this thread, to see if the necessary information for your components are listed there?
Speaking of which, I've made a few changes to https://fedoraproject.org/wiki/Xorg/Debugging and I'm still unhappy about the result. I think it's still cluttered.
Could you guys please have a look and bring some clarity ?
Your re-arrangement looks great to me, thanks for that - I can think of a possible way to maybe clarify it a bit more, I'll try to work on that tomorrow and see if it works. But good job!
Thank you. I'm still trying to look at it with non-bugzapper eyes and avoid thinking "WTF ?".
One quick note: English style differs from French in a few ways. One common one - in English, it's not normal to have a space before a question mark (or anything else...there's another punctuation mark where this is different, but I can't remember which one it is). There's a few other things I can't quite think of right now, I'll let you know if I remember them.
I'm all ears :)
François
On Thu, 2009-06-25 at 23:06 +0200, François Cami wrote:
Could you guys please have a look and bring some clarity ?
I did some stylistic cleanup...a few questions I think novice bug reporters might have:
* What is the advice for Fedora 10 users, upgrade to F11 and retry? Try a F11 or Rawhide LiveCD/USB?
* How do I tell if I have "KMS problems" or "OpenGL/Mesa problems"?
* How do I tell which applications use OpenGL?
* I assume if you are using OpenGL, you'll always have the command "glxinfo" installed? If not, readers would need to know how to install it.
Other than that, the page looks quite understandable.
-B.
On Thu, 2009-06-25 at 21:39 -0400, Christopher Beland wrote:
On Thu, 2009-06-25 at 23:06 +0200, François Cami wrote:
Could you guys please have a look and bring some clarity ?
I did some stylistic cleanup...a few questions I think novice bug reporters might have:
- What is the advice for Fedora 10 users, upgrade to F11 and retry? Try
a F11 or Rawhide LiveCD/USB?
This is a more general thing which should probably be addressed on the parent page (I'll check if it is already, and add something if not). I think we should say something along the lines that it's fine to file reports on any supported release, but if you're running an older supported release and you have no particular attachment to it, you may want to try a newer release to see if it fixes your issue. (Note that it's best to phrase things in a general way like this, in this case, rather than referring to specific releases, because if you refer to specific releases you have to go back and edit it each time a new one comes out).
How do I tell if I have "KMS problems" or "OpenGL/Mesa problems"?
How do I tell which applications use OpenGL?
I assume if you are using OpenGL, you'll always have the command
"glxinfo" installed? If not, readers would need to know how to install it.
I've made a big revision to the page to hopefully address all of those, and a few others, and add some more rigor and consistency. It now has a section on identifying issues and a section on what information to include, and I added a few other misc things (including a note about not filing reports on nvidia or fglrx issues). Following the theme above about not mentioning specific releases, I changed the common bugs link to go to the page Bugs/Common, which uses a neat mediawiki trick to always show you the _current_ common bugs page.
I think we may need a generic page on adding kernel parameters, if there isn't one already. I'll try and write one later.
Other than that, the page looks quite understandable.
I hope I didn't make it worse :)
On Fri, 2009-06-26 at 11:03 +0100, Adam Williamson wrote:
On Thu, 2009-06-25 at 21:39 -0400, Christopher Beland wrote:
On Thu, 2009-06-25 at 23:06 +0200, François Cami wrote:
Could you guys please have a look and bring some clarity ?
I did some stylistic cleanup...a few questions I think novice bug reporters might have:
- What is the advice for Fedora 10 users, upgrade to F11 and retry? Try
a F11 or Rawhide LiveCD/USB?
This is a more general thing which should probably be addressed on the parent page (I'll check if it is already, and add something if not). I think we should say something along the lines that it's fine to file reports on any supported release, but if you're running an older supported release and you have no particular attachment to it, you may want to try a newer release to see if it fixes your issue. (Note that it's best to phrase things in a general way like this, in this case, rather than referring to specific releases, because if you refer to specific releases you have to go back and edit it each time a new one comes out).
How do I tell if I have "KMS problems" or "OpenGL/Mesa problems"?
How do I tell which applications use OpenGL?
I assume if you are using OpenGL, you'll always have the command
"glxinfo" installed? If not, readers would need to know how to install it.
I've made a big revision to the page to hopefully address all of those, and a few others, and add some more rigor and consistency. It now has a section on identifying issues and a section on what information to include, and I added a few other misc things (including a note about not filing reports on nvidia or fglrx issues). Following the theme above about not mentioning specific releases, I changed the common bugs link to go to the page Bugs/Common, which uses a neat mediawiki trick to always show you the _current_ common bugs page.
I think we may need a generic page on adding kernel parameters, if there isn't one already. I'll try and write one later.
Other than that, the page looks quite understandable.
I hope I didn't make it worse :)
This is killer stuff guys! Really nice work :) You've captured something above 90% of the X issues testers encountered during Fedora 11 campaign. I've added a Category to this and similar pages to help me find these things better. Hopefully this helps others ...
https://fedoraproject.org/wiki/Category:Debugging
Are there any other suggested components to target next? NetworkManager and Packagekit were two that spring to mind as an active bug recipients. Debugging pam issues could be interesting as well.
I'm trying to gather the most reported components from triageweb to get more insight here ... any other thoughts?
Thanks, James
2009/6/26 James Laska jlaska@redhat.com
Are there any other suggested components to target next? NetworkManager and Packagekit were two that spring to mind as an active bug recipients. Debugging pam issues could be interesting as well.
I triage all the NetworkManager bugs and have recently start with the help from Dan to build a "what info we need & debug option for this" list. It's actually in a very technical state and not really end-user ready. I hope that get a public version done the next week. The main problem with NetworkManager bugs is, that the half is not related to NetworkManager, it often a mixture of kernel/hal/udev problems. That's also the reason why it so advantage to triage the bugs :)
-- Regards, Niels
I'm trying to gather the most reported components from triageweb to get more insight here ... any other thoughts?
Thanks, James
--
James Laska -- jlaska@redhat.com Quality Engineering -- Red Hat, Inc. ==========================================
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
Niels Haase, Fri, 26 Jun 2009 20:31:30 +0200:
I triage all the NetworkManager bugs and have recently start with the help from Dan to build a "what info we need & debug option for this" list. It's actually in a very technical state and not really end-user ready. I hope that get a public version done the next week. The main problem with NetworkManager bugs is, that the half is not related to NetworkManager, it often a mixture of kernel/hal/udev problems. That's also the reason why it so advantage to triage the bugs.
You are my hero! I had to bug triage NetworkManager bugs for some time (in the days when the Fedora maintainer was caillon) and these one of the most depressive and desperate days of my work for Red Hat. Thanks a lot.
Matej
On Fri, 2009-06-26 at 09:25 -0400, James Laska wrote:
Are there any other suggested components to target next? NetworkManager and Packagekit were two that spring to mind as an active bug recipients. Debugging pam issues could be interesting as well.
Looking at F9+F10+F11+Rawhide reports, below are the current components with the most bugs in the system (in all states). Going in order:
* [[KernelBugTriage]] exists, but is does not explicitly list what items should be included in a bug report, or how to diagnose the subtype. * [[Anaconda/BugReporting]] exists and is helpful. * No such page for yum. * [[Bug info SELinux]] covers the most common type of problem; might need expansion to deal with other types of bugs. * [[Bug info openoffice]] exists and is helpful. * Page for NetworkManager is being written by Niels and Dan. * No such page for rpm. * [[Bug info Firefox]] exists, though it doesn't seem comprehensive. * No such page for evolution.
kernel 4705 anaconda 3996 yum 968 selinux-policy 867 openoffice.org 794 NetworkManager 777 rpm 741 firefox 724 selinux-policy-targeted 679 xorg-x11-drv-ati 639 evolution 618 initscripts 613 gdm 582 mkinitrd 471 distribution 470 xorg-x11 454 xorg-x11-server 441 gcc 434 glibc 408 nautilus 404 system-config-network 380 PackageKit 371 pulseaudio 367 gnome-packagekit 363 xorg-x11-drv-i810 361 hal 358 gnome-panel 332 kdebase 286 control-center 280 udev 260 virt-manager 252 compiz 252 gnome-power-manager 248 gnome-applets 235 eclipse 233 pirut 219 kdebase-workspace 215 firstboot 211 system-config-printer 202 gtk2 200 up2date 199 rhythmbox 197 cups 196
On Sat, Jun 27, 2009 at 01:54:14AM -0400, Christopher Beland wrote:
On Fri, 2009-06-26 at 09:25 -0400, James Laska wrote:
Are there any other suggested components to target next? NetworkManager and Packagekit were two that spring to mind as an active bug recipients. Debugging pam issues could be interesting as well.
Looking at F9+F10+F11+Rawhide reports, below are the current components with the most bugs in the system (in all states). Going in order:
- [[KernelBugTriage]] exists, but is does not explicitly list what items
should be included in a bug report, or how to diagnose the subtype.
There's some basic notes on how the kernel team deals with bugs at https://fedoraproject.org/wiki/KernelBugTriage It could use some more expansion. I'll try and get to it next week.
Dave
On Fri, 26 Jun 2009 11:03:54 +0100 Adam Williamson awilliam@redhat.com wrote:
On Thu, 2009-06-25 at 21:39 -0400, Christopher Beland wrote:
On Thu, 2009-06-25 at 23:06 +0200, François Cami wrote:
Could you guys please have a look and bring some clarity ?
I did some stylistic cleanup...
(...)
Other than that, the page looks quite understandable.
I hope I didn't make it worse :)
Certainly not - the changes you and Christopher did are right on the money !
Thanks a bunch.
François
On Fri, 2009-06-26 at 20:12 +0200, François Cami wrote:
Certainly not - the changes you and Christopher did are right on the money !
THAT'S the one! No space before a ! in English, just like the ?. :)
On Fri, 26 Jun 2009 20:17:55 +0100 Adam Williamson awilliam@redhat.com wrote:
On Fri, 2009-06-26 at 20:12 +0200, François Cami wrote:
Certainly not - the changes you and Christopher did are right on the money !
THAT'S the one! No space before a ! in English, just like the ?. :)
Good catch! <=
Cheers
F
On Fri, 2009-06-26 at 11:03 +0100, Adam Williamson wrote:
- What is the advice for Fedora 10 users, upgrade to F11 and retry? Try
a F11 or Rawhide LiveCD/USB?
This is a more general thing which should probably be addressed on the parent page (I'll check if it is already, and add something if not). I think we should say something along the lines that it's fine to file reports on any supported release, but if you're running an older supported release and you have no particular attachment to it, you may want to try a newer release to see if it fixes your issue.
If by "parent page" you mean https://fedoraproject.org/wiki/Xorg it looks like the info there is terribly out of date (and version-specific, which I agree is best avoided in the wiki to avoid fast obsolescence).
-B.
Christopher Beland, Thu, 25 Jun 2009 21:39:09 -0400:
- What is the advice for Fedora 10 users, upgrade to F11 and retry? Try
a F11 or Rawhide LiveCD/USB?
Just to make it very plain ... we should NEVER say that somebody should upgrade from their supported distro just to fix the bug. We may be forced to tell them we don't see much hope for fixing their bug in the old distro, but you should be vrey aware and conscious, that this is failure on our side. We have promised them to support their distro for a year and month (or so) ... we may have to fail to honor our promise, but we should be aware that we are failing.
- How do I tell if I have "KMS problems" or "OpenGL/Mesa problems"?
try nomodeset and if it helps you have KMS problem?
- How do I tell which applications use OpenGL?
ldd <binary file> |grep libGL
???
- I assume if you are using OpenGL, you'll always have the command
"glxinfo" installed? If not, readers would need to know how to install it.
I think that it is in the very default installation, but not 100% positive about that.
Matěj
Jóhann B. Guðmundsson, Thu, 25 Jun 2009 17:37:54 +0000:
First of all if an individual brings a component into Fedora and does not know how or what's needed to effectively debug and work on the component he's about to expose to the whole Fedora userbase the component ( unless it's being introduced and maintained by some one that does ) should not be allowed to be brought into Fedora.
No, we don't require our packagers to be programmers, and there many packagers which automatically ship all bugs (which are not packaging bugs) upstream for the resolution. Such people may have no clue what is required for the debugging. Also, how many upstream programs include such information in their doucmentation?
Matěj
On Wed, 2009-06-24 at 14:35 -0400, James Laska wrote:
Jlaska suggested having a way to catalog content (e.g. debugging tips, or bug filing tips) for testers to easily find could be a great start.
I have arranged something of a system for this already:
https://fedoraproject.org/wiki/BugsAndFeatureRequests#Information_required_f...
notice the sub-pages linked to there. For any component, either add the information to the existing sub-page, or create a new one and link it from that section.
== Open discussion ==
=== Target Audience for israwhidebroken.com? ===
Viking_ice asked who are the target audience with israwhidebroken.com and what is being hope to accomplish with that? Adding that we, as testers, know that rawhide is largely broken before beta.
Jlaska suggested pulled content from the [[Israwhidebroken.com_Proposal| IRB.COM FAD proposal]] ... ''Provide a single, well-known location with information about whether or not Rawhide is broken, and a link to the last known-good Rawhide tree.'' Jlaska summarized, ''for me ... it's all about consistently gathering data to facilitate decision making.''
To put it clearly, the target audience is anyone who knows the dangers of Rawhide, wants to use it, but wants to know whether it's actually literally broken (in the sense of it can't possibly be installed / used at the most basic level) on that particular day, and they would hence be wasting their time. The aim is to make it easier for those who _can_ safely use Rawhide, to use it.
-
"Jóhann B. Guðmundsson" -
Adam Williamson -
Christopher Beland -
Dave Jones -
François Cami -
James Laska -
Jesse Keating -
Matej Cepl -
Niels Haase