There is a new draft posted at: https://fedoraproject.org/wiki/User:Beland/How_to_Triage
I recommend moving this to replace: https://fedoraproject.org/wiki/BugZappers/How_to_Triage
and changing the "Checklist" line on: https://fedoraproject.org/wiki/User:Adamwill/Draft_Bugzappers to "[[BugZappers/How to Triage|How to Triage]] - Includes checklists for use while doing triage"
I recommend making [[BugsAndFeatureRequests]] the destination of the "Bugzilla Primer" link. I added some complementary content here. It seems fairly complete, unlike https://fedoraproject.org/wiki/BugZappers/UnderstandingBugzilla which I'm leaving as a subpage.
-- Beland
On Tue, 2009-03-17 at 11:20 -0400, Christopher Beland wrote:
There is a new draft posted at: https://fedoraproject.org/wiki/User:Beland/How_to_Triage
This is excellent - thanks, Chris.
Some notes:
I'm not sure it's a good idea for the triager to do the work of splitting a report which actually deals with multiple issues up into separate reports. The problem is that then the triager becomes the 'reporter', and it won't be clear to the maintainer that the real reporter is actually some guy on the CC list. This could lead to confusion. I'd prefer to put the onus on the reporter to split the issues up.
Generally, this draft does not reference the actual use of the GreaseMonkey triage script at all. It would be best for each point at which a definite action can take place to mention both what to do manually, and - if there is one - what GreaseMonkey script button to use. E.g. it shouldn't just say that, once the report is complete, you set it to ASSIGNED, but that you can click the script's Triaged button to do the work for you.
I'm not sure about the 'how to handle bugs in multiple versions' section. This is a problem it's impossible to solve gracefully in Bugzilla, but we should do the best we can. I've found it's difficult to handle bugs in multiple versions in a single report - people will get annoyed if a significant issue is reported in both 10 and Rawhide, for e.g., and fixed in Rawhide then marked as fixed, but never fixed in 10, and there's no way to keep this active in Bugzilla.
The best approach IMHO is separate reports for separate releases; it's pretty crappy, but the least bad. This is something we can discuss, though. What does everyone else think?
I'm not sure about the 'optional steps' bit. It's a bit of a weird organization. I don't think 'is it an upstream bug?' is optional at all, to start with.
The NEEDINFO section needs to explicitly complete the loop by saying that, after marking NEEDINFO, you should follow the progress on the bug and complete the triage on it or close it as insufficient info, as required. The triager's job is not done once a bug is marked NEEDINFO.
well, that's most of my comments for now :) wdyt? I can adjust the draft with my proposed changes, if you like.
(Regarding https://fedoraproject.org/wiki/User:Beland/How_to_Triage )
On Wed, 2009-03-18 at 13:26 -0700, Adam Williamson wrote:
I'm not sure it's a good idea for the triager to do the work of splitting a report which actually deals with multiple issues up into separate reports. The problem is that then the triager becomes the 'reporter', and it won't be clear to the maintainer that the real reporter is actually some guy on the CC list. This could lead to confusion. I'd prefer to put the onus on the reporter to split the issues up.
I was wondering whether cloning a bug would maintain the reporter? If not, then it's probably best for the reporter to file a new bug, unless the triager can reproduce the problem.
Generally, this draft does not reference the actual use of the GreaseMonkey triage script at all. It would be best for each point at which a definite action can take place to mention both what to do manually, and - if there is one - what GreaseMonkey script button to use. E.g. it shouldn't just say that, once the report is complete, you set it to ASSIGNED, but that you can click the script's Triaged button to do the work for you.
Not coincidentally, I don't use GreaseMonkey (to keep my system relatively clean), so I don't see what changes it makes. If anyone who does use it would like to insert instructions/references at appropriate points, that would be a useful addition. But it seems necessary to also have sensible instructions for those who don't have it installed.
I'm not sure about the 'how to handle bugs in multiple versions' section. This is a problem it's impossible to solve gracefully in Bugzilla, but we should do the best we can. I've found it's difficult to handle bugs in multiple versions in a single report - people will get annoyed if a significant issue is reported in both 10 and Rawhide, for e.g., and fixed in Rawhide then marked as fixed, but never fixed in 10, and there's no way to keep this active in Bugzilla.
The best approach IMHO is separate reports for separate releases; it's pretty crappy, but the least bad. This is something we can discuss, though. What does everyone else think?
I see three options: A Maintain one bug report per bug, across all versions B Maintain one bug report per bug, across all versions, unless a reporter is advocating for a backport C Maintain separate bug reports for each version a bug appears in
I generally do (A) for Fedora bugs, is this common practice for other triagers and maintainers?
Having multiple bugs for the same problem makes it harder to collect diagnostic information, and seems confusing for maintainers. Triage-time doesn't seem like a good point to make copies of bugs, because the fix for all two or three different Fedora versions is likely to be the same. Probably the time to make new bugs for specific versions, if any is when a fix is deployed to at least one version.
Sometimes developers just deploy fixes to all active versions, in which case we save a bit of overhead. Sometimes they don't. At that point, it seems reasonable to say "If you need a backport to an older supported version, please reopen this bug and add a comment to this effect and include your rationale." or "If you need a backport to an older supported version, please open a new bug against that version. Reference this bug and simply request that the fix be backported to the desired version." In the latter case, the developer can respond "CLOSED/WONTFIX" or by deploying a backported fix. Or maybe no one will actually care, or people will be happy that when the next supported release comes out, they will get the bugfix (and the version they are currently using will hit EOL in the not-to-distant future, anyway). In that case, we save the overhead of having bugs without advocates in Bugzilla.
I'm not sure about the 'optional steps' bit. It's a bit of a weird organization. I don't think 'is it an upstream bug?' is optional at all, to start with.
Certainly there was disagreement on the list about whether triagers should be trying to reproduce bugs, which is why I made that optional.
As for the upstream issue, there are really two questions: * Has the bug been reported upstream? * Should Fedora volunteers or Red Hat employees fix the bug or just report it upstream and call it a day?
As a triager, I'd be willing to answer the first question if it would be useful to developers, but it at least doubles the workload by having to search through two Bugzillas. Most of us also won't have the permissions to do cleanup on the upstream Bugzilla, so that could get a bit messy.
As for the second question, I always have some hope that the Fedora package maintainer will produce a patch which they will apply immediately but send a copy upstream for inclusion there. I don't really feel comfortable making decisions about whether or not Fedora-affiliated maintainers have enough personal time to do a patch themselves, or they need to pass it on. And if triagers aren't expected to have familiarity with the code base (or even be programmers) then it's hard to say whether a given bug can or should be fixed at the distribution level or at the source.
The NEEDINFO section needs to explicitly complete the loop by saying that, after marking NEEDINFO, you should follow the progress on the bug and complete the triage on it or close it as insufficient info, as required. The triager's job is not done once a bug is marked NEEDINFO.
I sort of assume that bugs left in NEEDINFO for long enough will simply show up on the radar of other triagers who explicitly search for them. Doesn't seem like the original triager is going to have any special expertise at that point, and it's also possible a different triager might attempt to reproduce or supply the requested information themselves.
On a practical level, there's no guarantee that the original triager will even be still doing triage in 30 or 60 days, so I wouldn't count on them to take ownership of a given bug for that long.
well, that's most of my comments for now :) wdyt? I can adjust the draft with my proposed changes, if you like.
Feel free. For the places where we have policy decisions to make, it might actually be useful to have two or three alternative versions right there on the page that we can choose between or at least use as a starting point for discussion.
-B.
Christopher Beland wrote:
I see three options: A Maintain one bug report per bug, across all versions B Maintain one bug report per bug, across all versions, unless a reporter is advocating for a backport C Maintain separate bug reports for each version a bug appears in
I generally do (A) for Fedora bugs, is this common practice for other triagers and maintainers?
Yes, AFAICT it's the current practice for almost everyone except the security team which for some reason wants to do its own thing. :-/
Having multiple bugs for the same problem makes it harder to collect diagnostic information, and seems confusing for maintainers. Triage-time doesn't seem like a good point to make copies of bugs, because the fix for all two or three different Fedora versions is likely to be the same. Probably the time to make new bugs for specific versions, if any is when a fix is deployed to at least one version.
+1
We already had a discussion on this topic, but unfortunately it came to no consensus. :-(
Kevin Kofler
On Sat, 2009-03-21 at 22:21 +0100, Kevin Kofler wrote:
Christopher Beland wrote:
I see three options: A Maintain one bug report per bug, across all versions B Maintain one bug report per bug, across all versions, unless a reporter is advocating for a backport C Maintain separate bug reports for each version a bug appears in
I generally do (A) for Fedora bugs, is this common practice for other triagers and maintainers?
Yes, AFAICT it's the current practice for almost everyone except the security team which for some reason wants to do its own thing. :-/
Having multiple bugs for the same problem makes it harder to collect diagnostic information, and seems confusing for maintainers. Triage-time doesn't seem like a good point to make copies of bugs, because the fix for all two or three different Fedora versions is likely to be the same. Probably the time to make new bugs for specific versions, if any is when a fix is deployed to at least one version.
+1
We already had a discussion on this topic, but unfortunately it came to no consensus. :-(
As I said, it's because it's a problem you can't solve well with Bugzilla. Every possible approach has significant disadvantages, so you will likely never get consensus for any one option.
Christopher Beland wrote:
(Regarding https://fedoraproject.org/wiki/User:Beland/How_to_Triage )
On Wed, 2009-03-18 at 13:26 -0700, Adam Williamson wrote:
I'm not sure it's a good idea for the triager to do the work of splitting a report which actually deals with multiple issues up into separate reports. The problem is that then the triager becomes the 'reporter', and it won't be clear to the maintainer that the real reporter is actually some guy on the CC list. This could lead to confusion. I'd prefer to put the onus on the reporter to split the issues up.
I was wondering whether cloning a bug would maintain the reporter? If
Is "clone" like "fork?" Do you want two (or more) threads of discussion.
An alternative to my previous suggestion might be a subordinate bug, "this also occurs in ...." The parent bug cannot be closed (the software won't allow it) until all subordinate bugs are fixed too.
It might be that a bug report reflecting on F10 might be prompted to a parent, that points to F10 and any where else it occurrs. The F10 subordinate bug could then be closed.
Discussion should be against the parent, and the original reporter should be kept informed of progress.
not, then it's probably best for the reporter to file a new bug, unless the triager can reproduce the problem.
Er, the reporter has a problem in F10. Isn't it expecting a bit much of a reporter to install and test on RHEL[1] xx, Rawhide and anything else you can think of?
An _experienced_ triager could take a punt that "This might occur in ...."
1. yes, I know _this_ is Fedora. I can't help thinking RHEL matters too, because the bugs database is shared/
On Mon, 2009-03-23 at 22:51 +0900, John Summerfield wrote:
Christopher Beland wrote:
(Regarding https://fedoraproject.org/wiki/User:Beland/How_to_Triage )
On Wed, 2009-03-18 at 13:26 -0700, Adam Williamson wrote:
I'm not sure it's a good idea for the triager to do the work of splitting a report which actually deals with multiple issues up into separate reports. The problem is that then the triager becomes the 'reporter', and it won't be clear to the maintainer that the real reporter is actually some guy on the CC list. This could lead to confusion. I'd prefer to put the onus on the reporter to split the issues up.
I was wondering whether cloning a bug would maintain the reporter? If
Is "clone" like "fork?" Do you want two (or more) threads of discussion.
An alternative to my previous suggestion might be a subordinate bug, "this also occurs in ...." The parent bug cannot be closed (the software won't allow it) until all subordinate bugs are fixed too.
You can't do that, because there's no clear invariable parent/child relationship. Imagine a bug that exists in F10 and Rawhide. There are some cases where it might get fixed in F10 but not Rawhide, some where it might get fixed in Rawhide but not F10, some where it might get fixed in both and some where it might get fixed in neither.
See what I mean about every possible choice having drawbacks...
as I mentioned in a discussion on -devel-list, Launchpad handles this perfectly. But doing it in Bugzilla would require significant modifications.
On Mon, 2009-03-23 at 10:17 -0700, Adam Williamson wrote:
An alternative to my previous suggestion might be a subordinate bug, "this also occurs in ...." The parent bug cannot be closed (the software won't allow it) until all subordinate bugs are fixed too.
You can't do that, because there's no clear invariable parent/child relationship. Imagine a bug that exists in F10 and Rawhide. There are some cases where it might get fixed in F10 but not Rawhide, some where it might get fixed in Rawhide but not F10, some where it might get fixed in both and some where it might get fixed in neither.
Usually a bug is fixed in the newer version and backported to older versions. Bugzilla is mostly for reminding humans what to do, so it seems fine to expect people to change the order of what-depends-on-what in weird cases where a bug is fixed in an older version but not a newer one, despite being the "same" bug.
-B.
Adam Williamson wrote:
The best approach IMHO is separate reports for separate releases; it's pretty crappy, but the least bad. This is something we can discuss, though. What does everyone else think?
The prospects of getting reporters to do that are just about zero.
The proper solution is to fix the software (bugzilla), the release needs to be a multi-valued[1] field with whatever code changes that requires.
1 I don't even know how well the backend database supports this, I know for many years relational theory forbade it. OTOH ADABAS, which I supported in the early 80s did do multivalued fields (and repeating groups) and could index them. OTOH it made no pretense of being relational.
Christopher Beland wrote:
There is a new draft posted at: https://fedoraproject.org/wiki/User:Beland/How_to_Triage
Great work.
I've added a short paragraph to the end about using the EasyFix keyword:
9.) Is it a bug trivial to fix?
If you think that the bug is trivial to fix, please add the "EasyFix" keyword. This enables provenpackagers to track for bugs that they may easily help to fix and prevents such bugs from starving long time in Bugzilla. Examples of what could be considered as EasyFix bugs are e.g. missing requires (or similar minor updates to the SPEC files) or bugs with a simple patch attached.
Regards, Milos
Christopher Beland wrote:
There is a new draft posted at: https://fedoraproject.org/wiki/User:Beland/How_to_Triage
I went from the above to https://fedoraproject.org/wiki/BugZappers/StockBugzillaResponses
Here is my response to the latter: "Thank you for taking the time to prepare this guide. However, this guide isn't very useful because it is excessively hard to read as it's formatted to overflow a fixed-width column.
"Please, if you can, take the time to correct the formatting and test it on a variety of browsers including Seamonkey, Firefox, IE6 and IE7, Lynx, elinks and Links v2" in a variety of different-sized fonts.
Does what I did to this section look better? Is it copy-and-paste-able cleanly from the browsers that people are using?
https://fedoraproject.org/wiki/BugZappers/StockBugzillaResponses#No_stack_tr...
-B.
On Mon, 2009-03-23 at 22:36 +0900, John Summerfield wrote:
"Thank you for taking the time to prepare this guide. However, this guide isn't very useful because it is excessively hard to read as it's formatted to overflow a fixed-width column.
"Please, if you can, take the time to correct the formatting and test it on a variety of browsers including Seamonkey, Firefox, IE6 and IE7, Lynx, elinks and Links v2" in a variety of different-sized fonts.
Christopher Beland wrote:
Does what I did to this section look better? Is it copy-and-paste-able cleanly from the browsers that people are using?
https://fedoraproject.org/wiki/BugZappers/StockBugzillaResponses#No_stack_tr...
-B.
On Mon, 2009-03-23 at 22:36 +0900, John Summerfield wrote:
"Thank you for taking the time to prepare this guide. However, this guide isn't very useful because it is excessively hard to read as it's formatted to overflow a fixed-width column.
"Please, if you can, take the time to correct the formatting and test it on a variety of browsers including Seamonkey, Firefox, IE6 and IE7, Lynx, elinks and Links v2" in a variety of different-sized fonts.
Looks just fine, quickly looking using firefox and lynx. Test with IE6 and IE7, different fonts sizes? Go right ahead, let someone who cares know what you found.
TK009
John Summerfield requested the fixed-width formatting at
https://fedoraproject.org/wiki/BugZappers/StockBugzillaResponses
be changed. That's done now. While I was in there, I also tweaked the wording of some stock responses to be more polite, so review of the revised text is welcomed.
I also had a question about the nVidia proprietary driver stock response. After reading:
https://fedoraproject.org/wiki/Features/NouveauAsDefault
I was wondering if the response should be rewritten to suggest moving to the open source "xf86-video-nouveau" driver, which will be available in Fedora 11. (Will it be backported to 9 and 10 as well?) It was also unclear whether "xf86-video-nv" is open source enough not to warrant the "proprietary driver" response, or what.
-B.
On Tue, 2009-03-31 at 13:33 -0400, Christopher Beland wrote:
I also had a question about the nVidia proprietary driver stock response. After reading:
https://fedoraproject.org/wiki/Features/NouveauAsDefault
I was wondering if the response should be rewritten to suggest moving to the open source "xf86-video-nouveau" driver, which will be available in Fedora 11. (Will it be backported to 9 and 10 as well?) It was also unclear whether "xf86-video-nv" is open source enough not to warrant the "proprietary driver" response, or what.
nouveau is available in F10 and I think F9 as well, it's just not the default. Probably we should say "nv or nouveau", or something similar.
nv is open source enough not to need the proprietary driver response, but bugs in nv are likely to be given fairly low priority in future.
On Tue, 2009-03-31 at 10:49 -0700, Adam Williamson wrote:
On Tue, 2009-03-31 at 13:33 -0400, Christopher Beland wrote:
I also had a question about the nVidia proprietary driver stock response. After reading:
https://fedoraproject.org/wiki/Features/NouveauAsDefault
I was wondering if the response should be rewritten to suggest moving to the open source "xf86-video-nouveau" driver, which will be available in Fedora 11. (Will it be backported to 9 and 10 as well?) It was also unclear whether "xf86-video-nv" is open source enough not to warrant the "proprietary driver" response, or what.
nouveau is available in F10 and I think F9 as well, it's just not the default. Probably we should say "nv or nouveau", or something similar.
nv is open source enough not to need the proprietary driver response, but bugs in nv are likely to be given fairly low priority in future.
Given that I don't have the hardware in question and I haven't played around with this, I added the following:
The open source "nouveau" driver is the recommended alternative. It is used by default in Fedora 11 and later if you remove any customizations that explicitly set the video driver. The older "nv" driver may be needed in some cases. It is also available in older Fedora releases. Install the pacakages xorg-x11-drv-nouveau or xorg-x11-drv-nv and override the X server's default choice if necessary. See https://fedoraproject.org/wiki/Features/NouveauAsDefault for more information. <<
There doesn't seem to be a good page with step-by-step instructions for F9 or F10 conversion, so I was vague. Probably this will become less of an issue as those versions are EOL'd anyway.
Improvements welcome directly to the wiki text.
-B.
Christopher Beland, Thu, 28 May 2009 02:31:22 -0400:
Given that I don't have the hardware in question and I haven't played around with this, I added the following:
The open source "nouveau" driver is the recommended alternative. It is used by default in Fedora 11 and later if you remove any customizations that explicitly set the video driver. The older "nv" driver may be needed in some cases. It is also available in older Fedora releases. Install the pacakages xorg-x11-drv-nouveau or xorg-x11-drv-nv and override the X server's default choice if necessary. See https://fedoraproject.org/wiki/Features/NouveauAsDefault for more information. <<
Great, will add to the script momentarily!
Matěj
On 5/28/2009 3:53 AM, Matej Cepl wrote:
Christopher Beland, Thu, 28 May 2009 02:31:22 -0400:
Given that I don't have the hardware in question and I haven't played around with this, I added the following:
The open source "nouveau" driver is the recommended alternative. It is used by default in Fedora 11 and later if you remove any customizations that explicitly set the video driver. The older "nv" driver may be needed in some cases. It is also available in older Fedora releases. Install the pacakages xorg-x11-drv-nouveau or xorg-x11-drv-nv and override the X server's default choice if necessary. See https://fedoraproject.org/wiki/Features/NouveauAsDefault for more information. <<
Great, will add to the script momentarily!
Spell check. :-)
Christopher Beland, Thu, 28 May 2009 02:31:22 -0400:
to the open source "xf86-video-nouveau" driver, which will be available in Fedora 11. (Will it be backported to 9 and 10 as well?)
There was nouveau driver in Fedora Xorg like since forever (certainly F8, maybe even F7, not sure about that), which in its later versions (for sure F10) worked for some (emphasizing *some*) better than -nv, so I was suggesting it over -nvidia, when somebody smallest willingness to leave THAT THING. However, it was certainly something which nobody could trust his life, honour, and welfare to.
Unfortunately F11 nouveau will almost certianly not be ported to F10, because it is (as all other KMS drivers) tightly linked to the development in kernel, and I am afraid nobody will port all KMS kernel patches to F10.
It was also unclear whether "xf86-video-nv" is open source enough not to warrant the "proprietary driver" response, or what.
-nv is a difficult beast. From the legal standpoint it is pure open source (MIT/X11 license as the rest of Xorg), but from the programmer's point of view it is more complicated ... it has been maintained only by one nVidia employee, source is largely undocumented, some would say even obfuscated, and extremely difficult to deal with. So, yes it is open source (it is in Fedora, right?)
There doesn't seem to be a good page with step-by-step instructions for F9 or F10 conversion, so I was vague. Probably this will become less of an issue as those versions are EOL'd anyway.
I hope upgrade from F9/F10 should work automagically.
Much more interesting than how to install -{nv,nouveau} is how to get rid of -nvidia goo which stays on the disk (unless rpm from The Repository Which Shall Not Be Named is used, which quite often isn't). Mike Harris my esteemed predecessor in Xorg bug triaging wrote a long piece on this https://fedoraproject.org/wiki/Xorg/3rd_Party_Video_Drivers (which somebody cleaned up recently for English; thank you!).
Matěj
On Thu, 2009-05-28 at 09:31 +0000, Matej Cepl wrote:
There doesn't seem to be a good page with step-by-step instructions for F9 or F10 conversion, so I was vague. Probably this will become less of an issue as those versions are EOL'd anyway.
I hope upgrade from F9/F10 should work automagically.
To be precise, if you have no xorg.conf, F11 will use nouveau automatically, assuming it's installed, which I think it should be (Matej, it was installed by default on previous releases, right - just not *used* by default?) If you have an xorg.conf remaining from a previous release which specifies a particular driver (nvidia or nv), that driver will continue to be used, F11 won't magically override your xorg.conf.
Much more interesting than how to install -{nv,nouveau} is how to get rid of -nvidia goo which stays on the disk (unless rpm from The Repository Which Shall Not Be Named is used, which quite often isn't). Mike Harris my esteemed predecessor in Xorg bug triaging wrote a long piece on this https://fedoraproject.org/wiki/Xorg/3rd_Party_Video_Drivers (which somebody cleaned up recently for English; thank you!).
I'm going to amend that slightly to explain *how* to uninstall proprietary drivers, and try and explain in a roundabout way that it's OK if you use TRWSNBN).
To be precise, if you have no xorg.conf, F11 will use nouveau automatically, assuming it's installed, which I think it should be (Matej, it was installed by default on previous releases, right - just not *used* by default?) If you have an xorg.conf remaining from a previous release which specifies a particular driver (nvidia or nv), that driver will continue to be used, F11 won't magically override your xorg.conf.
Atleast that's not what happened for me on a fresh F11 install with a Nvidia GeForce 6150. I got a 1024x768 stretched display with vesa. I had to manually create a new xorg.conf from the nouveau test day [1] and restart X. After that it worked fine.
This was a lxde only install that skipped firstboot if that is significant. Manually running system-config-display still came up with vesa at 1024x768 though.
[1] https://fedoraproject.org/w/uploads/d/d9/Xorg.conf.nouveau
On Thu, 2009-05-28 at 23:43 +0530, Gireesh wrote:
To be precise, if you have no xorg.conf, F11 will use nouveau automatically, assuming it's installed, which I think it should be (Matej, it was installed by default on previous releases, right - just not *used* by default?) If you have an xorg.conf remaining from a previous release which specifies a particular driver (nvidia or nv), that driver will continue to be used, F11 won't magically override your xorg.conf.
Atleast that's not what happened for me on a fresh F11 install with a Nvidia GeForce 6150. I got a 1024x768 stretched display with vesa. I had to manually create a new xorg.conf from the nouveau test day [1] and restart X. After that it worked fine.
This was a lxde only install that skipped firstboot if that is significant. Manually running system-config-display still came up with vesa at 1024x768 though.
We do specifically blacklist a few adapters to vesa instead of nouveau, ones which have been reported to fail completely with nouveau. What's the PCI ID of your graphics card, please? lspci -nn will tell you.
We do specifically blacklist a few adapters to vesa instead of nouveau, ones which have been reported to fail completely with nouveau. What's the PCI ID of your graphics card, please? lspci -nn will tell you. --
nVidia C51 [Geforce 6150 Go] [10de:0244] (rev a2)
My card has a problem with nouveau either on F10 or F11 except for suspend/resume (as expected)
On Fri, 2009-05-29 at 00:22 +0530, Gireesh wrote:
We do specifically blacklist a few adapters to vesa instead of nouveau, ones which have been reported to fail completely with nouveau. What's the PCI ID of your graphics card, please? lspci -nn will tell you. --
nVidia C51 [Geforce 6150 Go] [10de:0244] (rev a2)
My card has a problem with nouveau either on F10 or F11 except for suspend/resume (as expected)
Hmm. That's not blacklisted. Can you confirm that if you rename /etc/X11/xorg.conf and restart X, you still get vesa? Can you pastebin your /var/log/Xorg.0.log in that case? Thanks.
On Fri, May 29, 2009 at 12:34 AM, Adam Williamson awilliam@redhat.com wrote:
On Fri, 2009-05-29 at 00:22 +0530, Gireesh wrote:
We do specifically blacklist a few adapters to vesa instead of nouveau, ones which have been reported to fail completely with nouveau. What's the PCI ID of your graphics card, please? lspci -nn will tell you. --
nVidia C51 [Geforce 6150 Go] [10de:0244] (rev a2)
My card has a problem with nouveau either on F10 or F11 except for suspend/resume (as expected)
Hmm. That's not blacklisted. Can you confirm that if you rename /etc/X11/xorg.conf and restart X, you still get vesa? Can you pastebin your /var/log/Xorg.0.log in that case? Thanks. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
I am at work right now and can get to the laptop only after some time. But I will do something better. Open a bug report if I can reproduce it.
Adam Williamson, Thu, 28 May 2009 09:35:43 -0700:
(Matej, it was installed by default on previous releases, right - just not *used* by default?)
Yeah, we install everything per default ... including drivers for things which nobody ever seen working for years.
previous release which specifies a particular driver (nvidia or nv), that driver will continue to be used, F11 won't magically override your xorg.conf.
Yes, that's correct.
I'm going to amend that slightly to explain *how* to uninstall proprietary drivers, and try and explain in a roundabout way that it's OK if you use TRWSNBN).
Thanks a lot!
Matěj
On Fri, 2009-05-29 at 13:10 +0000, Matej Cepl wrote:
Adam Williamson, Thu, 28 May 2009 09:35:43 -0700:
(Matej, it was installed by default on previous releases, right - just not *used* by default?)
Yeah, we install everything per default ... including drivers for things which nobody ever seen working for years.
previous release which specifies a particular driver (nvidia or nv), that driver will continue to be used, F11 won't magically override your xorg.conf.
Yes, that's correct.
I'm going to amend that slightly to explain *how* to uninstall proprietary drivers, and try and explain in a roundabout way that it's OK if you use TRWSNBN).
Thanks a lot!
Matěj
How are you coming with the mouse problem? Just asking, we are creatures of adaptation.:-)
On Fri, 2009-05-29 at 14:09 +0000, Matej Cepl wrote:
Lawrence E. Graves, Fri, 29 May 2009 07:19:31 -0600:
How are you coming with the mouse problem? Just asking, we are creatures of adaptation.:-)
Sorry, don't understand.
Matěj
I am the guy who sent the bug about the mouse that wouldn't change from left to the right-handed use. You ask for my log files and then sent me some instruction for me to perform trying to narrow down the possible problem. I know you are very busy right now with the intended RC in a few days so if this has slipped your mind, I truly understand. I can wait until the release of RC. https://bugzilla.redhat.com/show_bug.cgi?id=502129
On Fri, 2009-05-29 at 08:35 -0600, Lawrence E. Graves wrote:
That bug is actually waiting for more diagnostic information from you, Lawrence. (And I'm not sure the developer working on the bug is actually reading this mailing list.)
-B.
On Fri, 2009-05-29 at 10:59 -0400, Christopher Beland wrote:
On Fri, 2009-05-29 at 08:35 -0600, Lawrence E. Graves wrote:
That bug is actually waiting for more diagnostic information from you, Lawrence. (And I'm not sure the developer working on the bug is actually reading this mailing list.)
-B.
I don't see how they are waiting on me, I've sent them two log files of my computer. If there is more information needed from me, let me know, I'll be glad to give it. I want to be apart of the solution and not the problem. Thank you for your response to this matter. Is there another place I need to send the needed information?
On Fri, 2009-05-29 at 09:09 -0600, Lawrence E. Graves wrote:
I don't see how they are waiting on me, I've sent them two log files of my computer. If there is more information needed from me, let me know, I'll be glad to give it. I want to be apart of the solution and not the problem. Thank you for your response to this matter. Is there another place I need to send the needed information?
https://bugzilla.redhat.com/show_bug.cgi?id=502129
Visit the bug above and scroll down to the bottom of the page; you'll see the question asked. You should be getting an e-mail every time this bug is updated; the bug page is the right place to answer questions or add new information.
-B.
On Fri, 2009-05-29 at 11:44 -0400, Christopher Beland wrote:
On Fri, 2009-05-29 at 09:09 -0600, Lawrence E. Graves wrote:
I don't see how they are waiting on me, I've sent them two log files of my computer. If there is more information needed from me, let me know, I'll be glad to give it. I want to be apart of the solution and not the problem. Thank you for your response to this matter. Is there another place I need to send the needed information?
https://bugzilla.redhat.com/show_bug.cgi?id=502129
Visit the bug above and scroll down to the bottom of the page; you'll see the question asked. You should be getting an e-mail every time this bug is updated; the bug page is the right place to answer questions or add new information.
-B.
--
I believe I'll get the order of things right one day. It will be people like you who will be instrumental in that taking place. I did as you asked. Thanks again. Lawrence E. Graves lgraves@risingstarmbc.com
Lawrence E. Graves, Fri, 29 May 2009 08:35:53 -0600:
I am the guy who sent the bug about the mouse that wouldn't change from left to the right-handed use. You ask for my log files and then sent me some instruction for me to perform trying to narrow down the possible problem. I know you are very busy right now with the intended RC in a few days so if this has slipped your mind, I truly understand. I can wait until the release of RC. https://bugzilla.redhat.com/show_bug.cgi?id=502129 --
Oh boy, I am sorry, but I really don't understand all active bugs around. Looking at the bug, it's now all in Peter's hands ... he usually deals with his bugs pretty swiftly.
Matěj
the open source "xf86-video-nouveau" driver, which will be available in Fedora 11. (Will it be backported to 9 and 10 as well?)
The driver is already in 10. I had to install xf86-video-nouveau, then do the following.
init 3 chkconfig nvidia off service nvidia off modprobe nouveau
(The nvidia driver was from RPMfusion).
Finally I created a Xorg.conf with the following
Section "Device" Driver "nouveau" EndSection
It seemed to work fine for me until I rebooted 5 days later. Probably the nouveau driver didn't get automatically loaded again but that can be fixed by adding nouveau to /etc/modprobe.conf or similar.
Gireesh
After Adam's comments, I changed the advice for 2-in-1 bugs to point to the stock reply (which asks reporters to do the split), and updated that reply to be more polite and informative.
So this leaves the following decisions to make at the meeting: * "Option 1", "Option 2" or other text for "How to Handle Bugs in Multiple Versions" section? * Should a check for bugs filed in upstream Bugzillas be mandatory? * Should triagers decide whether a bug should be handled upstream or by Fedora, or should this be left to package maintainers? * Should NEW triagers be asked to do NEEDINFO updates in 30 and 60 days if needed, or should this be left to triagers following the NEEDINFO checklist? * After these issues are decided, is this draft ready to go live?
Suggested improvements which might be implemented before or after deployment: * Add references to GreaseMonkey buttons in checklist instructions * Make https://fedoraproject.org/wiki/BugZappers/StockBugzillaResponses more friendly by not using fixed-width boxes.
-B.
Christopher Beland wrote:
- Should a check for bugs filed in upstream Bugzillas be mandatory?
no
- Should triagers decide whether a bug should be handled upstream or by Fedora, or should this be left to package maintainers?
package maintainer
- Should NEW triagers be asked to do NEEDINFO updates in 30 and 60 days if needed, or should this be left to triagers following the NEEDINFO checklist?
I do my own.
- After these issues are decided, is this draft ready to go live?
Suggested improvements which might be implemented before or after deployment:
- Add references to GreaseMonkey buttons in checklist instructions
- Make https://fedoraproject.org/wiki/BugZappers/StockBugzillaResponses more friendly by not using fixed-width boxes.
-B.
TK009
On Mon, 2009-03-23 at 14:50 -0400, Christopher Beland wrote:
After Adam's comments, I changed the advice for 2-in-1 bugs to point to the stock reply (which asks reporters to do the split), and updated that reply to be more polite and informative.
So this leaves the following decisions to make at the meeting:
- "Option 1", "Option 2" or other text for "How to Handle Bugs in Multiple Versions" section?
I guess Option 1 seems to be mostly preferred, so I'm OK with that one.
- Should a check for bugs filed in upstream Bugzillas be mandatory?
- Should triagers decide whether a bug should be handled upstream or by Fedora, or should this be left to package maintainers?
I think we should probably discuss this with the maintainers rather than coming to a unilateral decision on it.
- Should NEW triagers be asked to do NEEDINFO updates in 30 and 60 days if needed, or should this be left to triagers following the NEEDINFO checklist?
I think we should ask triagers to take responsibility for following up their own triaged bugs. We can have procedures to catch cases where this isn't done, but I'm really not a fan, as I've written, of drive-by triaging.
- After these issues are decided, is this draft ready to go live?
Suggested improvements which might be implemented before or after deployment:
- Add references to GreaseMonkey buttons in checklist instructions
I'll do this later today, with reference to mcepl's shiny new generation script.
-
Adam Williamson -
Christopher Beland -
David Boles -
Gireesh Sreekantan -
John Summerfield -
Kevin Kofler -
Lawrence E Graves -
Matej Cepl -
Milos Jakubicek -
TK009