On 06/09/14 16:26 (GMT+0300) Silviu Marin-Caea apparently typed:

On Thursday 14 September 2006 15:42, ken wrote:

...

Subject: [Bug 205096] Bug in ATI Radeon 9000M Video Card Detection

...

For a good laugh, read this bug report: https://bugzilla.novell.com/show_bug.cgi?id=205096

Some dude that filed a bug report without giving out useful information. Not laughing material, just boring.

You're right about that, but the responses to the reporter could have done a better job of eliciting useful information from him. -- "Wisdom is supreme; therefore get wisdom. Though it cost all you have, get understanding. Esteem her, and she will exalt you; embrace her, and she will honor you." Proverbs 4:7-8 NIV Team OS/2 ** Reg. Linux User #211409 ** Rotary ONLY since 1973 Felix Miata *** http://mrmazda.no-ip.com/ <- More than just a FAQ

On 06/09/14 15:50 (GMT+0200) Matthias Hopf apparently typed:

On Sep 14, 06 09:41:54 -0400, Felix Miata wrote:

...

...

...

For a good laugh, read this bug report: https://bugzilla.novell.com/show_bug.cgi?id=205096

...

...

Some dude that filed a bug report without giving out useful information. Not laughing material, just boring.

...

You're right about that, but the responses to the reporter could have done a better job of eliciting useful information from him.

No. We obviously can't. Sorry that we are a bunch of morons.

If you read carefully you'll notice that we honestly tried.

Don't be so quick go group yourself with Stefan Dirsch. My comment resulted from the additional perspective of very recent activity on these bugs: https://bugzilla.novell.com/show_bug.cgi?id=141443 https://bugzilla.novell.com/show_bug.cgi?id=204324 IMO Dirsch's bugzilla skills could be better.

The reporter even didn't care to attach the working and nonworking configuration - which would be trivial. The bug report contains exactly zero information appart from that something with this card does work.

This is all true. That's why I wrote what I wrote about the way his comments were handled. That reporter is an apparent scatterbrain. People like that need to be given a laundry list that spells out concisely what you want from them, with no discussion of what they did wrong to obfuscate it. -- "Wisdom is supreme; therefore get wisdom. Though it cost all you have, get understanding. Esteem her, and she will exalt you; embrace her, and she will honor you." Proverbs 4:7-8 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/

On Sep 14, 06 10:19:13 -0400, Felix Miata wrote:

...

If you read carefully you'll notice that we honestly tried.

Don't be so quick go group yourself with Stefan Dirsch. My comment resulted from the additional perspective of very recent activity on these bugs:

Stefan is sitting right across in the next room. Also, given the number of bug reports he has to work on every day, there may be misunderstandings, of course.

https://bugzilla.novell.com/show_bug.cgi?id=141443 https://bugzilla.novell.com/show_bug.cgi?id=204324

IMO Dirsch's bugzilla skills could be better.

Well, this is a personal opinion I can accept. Though I don't understand it, related to the two bugs you mention, as #204324 has been handled ok. I helped deducing the workaround, but that was late when it was clear what actually had happened. I personally think Stefan handled this perfectly professional. The problem with #141443 is that it is a curious bug which we cannot reproduce (though it certainly is a bug). The only thing I can think of ATM is a BIOS bug, where we cannot do anything ATM (the intel driver will get rid of BIOS dependency some day, they're working on it). I know if you have something like that the outcome is not satisfactory, but we have much more important bugs (like domain support not working at all for 7.1), and the number of users switch consoles is pretty small compared to all users (and even then we cannot reproduce).

This is all true. That's why I wrote what I wrote about the way his comments were handled. That reporter is an apparent scatterbrain. People like that need to be given a laundry list that spells out concisely what you want from them, with no discussion of what they did wrong to obfuscate it.

:^) Well, remember that we are humans as well, and we might have a bad day or get impatient as well ;) The pay at Novell is not *that* good to remain calm all the time :-P CU Matthias -- Matthias Hopf __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ labs www.mshopf.de

On Sep 15, 06 00:36:33 -0400, Felix Miata wrote:

...

Though I don't understand it, related to the two bugs you mention, as #204324 has been handled ok. I helped deducing the workaround, but that was late when it was clear what actually had happened. I personally think Stefan handled this perfectly professional.

I think it better to leave out the "perfectly". The current status is perfectly reasonable given the problem. Reaching it had a few kinks.

That perfectly normal with nontrivial bugs.

Look at the timing and what exactly was said beginning with comment 19. With the third party participating, it wasn't clear who was saying what to whom. Was Marcus there with Stefan? If he was, either only one of

This is how bugzilla works. If you specifically need information from someone you set NEEDINFO. If not, it's general babble (hopefully usefull babble).

them should have been commenting, or they should have been disussing among themselves what to say before saying it. Comment 26 should not have been necessary. Stefan definitely did much better here than in the

We don't do that often. We do that in the open, in bugzilla. This helps documenting how we eventually got to a particular solution. Why would comment 26 not be necessary? Stefan had more than a day to analyze the core file, and could finally reproduce.

...

The problem with #141443 is that it is a curious bug which we cannot reproduce (though it certainly is a bug). The only thing I can think of ATM is a BIOS bug, where we cannot do anything ATM (the intel driver will get rid of BIOS dependency some day, they're working on it). I know if you have something like that the outcome is not satisfactory, but we have much more important bugs...

He started off poorly here, marking it INVALID at comment 1 without adequate explanation in spite of a report of the same failure on more than one SUSE installation. Then months later after I reported the

1st) Changed states are not represented in the bugzilla view, didn't know that. 2nd) The bug looked like a typical "Bug sits between monitor and chair" problem at first. This happens all the time. Though I admit if read carefully (two other distributions not affected) you could read the person reporting that really has some clue. The problem is that many people see INVALID/WONTFIX/WORKSFORME as final states or even as offensive. Most times they are, but if you can attach information that contradicts the reason for setting the state, you're free to reopen.

Then I finally came to this and the factory mailing lists asking if others can reproduce, plus did a 5th install on a 4th machine, to prove the problem is no fluke only I can reproduce. In spite of this, he "resolved" the bug once more, this time as LATER, which is no resolution at all, but merely shoveling the problem under a rug.

I understand that this is unsatisfactory behavior for you. It would probably be better to leave it open at a low level, but I can tell you Stefan relly reopens Bugreports set to LATER some time later. So it's not lost. BTW - the issue is definitvely minor, as you have an easy (self-deduced) workaround for an issue that doesn't involve crashes or data loss. BTW - can you post the xorg.conf from one of the working distributions? Maybe even try it out on 10.2? If it's just a configuration issue...

This also is truth, but we must remember on Bugzilla we are putting it in writing for the whole world to see. Before clicking submit, a pause for something else, then a reread of the proposed response, and editing as necessary, is a wise rule to follow.

Given the time constraints, this doesn't always work, though it's in principle a good idea :-( Matthias -- Matthias Hopf __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ labs www.mshopf.de

On Sep 15, 06 14:59:03 +0200, Leendert Meyer wrote:

...

We don't do that often. We do that in the open, in bugzilla. This helps documenting how we eventually got to a particular solution.

This good. But what the problem seemed to be, IIUC from Felix, is that it was not clear if someone is talking to someone else specific, or more in general to the group (of involved people).

Yes, that happens. Bugzilla style depends on the people using it, ousiders may be confused by the style. But that's the normal case if you start talking/contributing in colaborative enironments that are new to you.

E.g. talking to someone specific could be clearly marked if the text is preceded by that person's name.

This is typically done.

Hmm, this looks like the time before I had a threaded email program like KMail. Maybe a threaded display of messages could make things a bit clearer?

Maybe that would be cool. But normally bugzilla entries are flat. Matthias -- Matthias Hopf __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ labs www.mshopf.de

On 06/09/15 12:15 (GMT+0200) Matthias Hopf apparently typed:

Why would comment 26 not be necessary?

#21 - FM - 09:28:00 Let me know if the core dump would help too. ... #24 - SD - 09:31:34 Looks like we have a broken vesa driver. #25 - MS - 09:34:14 yes indeed #26 - FM - 09:49:26 Yes indeed you would like a core file, or yes indeed vesa driver is broken? #27 - SD - 09:57:03 Yes, core file would help. #21 was directed to the Novell/SUSE Bugzilla response team, as it was a team effort at that point. #25 was an a counterproductive ambiguous comment. #26 was necessitated by that ambiguous comment to elicit what followed in #27.

BTW - can you post the xorg.conf from one of the working distributions?

If someone from Novell thinks that really might be helpful it should be requested in the bug.

Maybe even try it out on 10.2? If it's just a configuration issue...

That's a bit easier said than done. Fontpath handling is different among them, particularly as to xorg 6.x vs. 7.x. https://bugzilla.novell.com/attachment.cgi?id=98798 is a comparison of their keyboard sections. I'm not familiar with the ramifications of the differences. -- "Wisdom is supreme; therefore get wisdom. Though it cost all you have, get understanding. Esteem her, and she will exalt you; embrace her, and she will honor you." Proverbs 4:7-8 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/

On Thursday 14 September 2006 16:33, Carlos E. R. wrote:

The Thursday 2006-09-14 at 15:50 +0200, Matthias Hopf wrote:

...

If you read carefully you'll notice that we honestly tried. The reporter even didn't care to attach the working and nonworking configuration - which would be trivial. The bug report contains exactly zero information appart from that something with this card does work.

The original problem is that lspci says that the card is an "Radeon R250" when it is a "Radeon 9000M". Based on that info, Sax installs the wrong driver.

It doesn't actually mention that it's the wrong driver though. I'm fairly certain R250 and 9000M are both handled by radeon_drv

This is the main bug, still unsolved.

** Notice that he mentions that this he reported more than a year ago. **

Yes, to the lspci upstream maintainer

The changes the reporter did to xorg.conf are irrelevant, but I'm sure you can guess what they were: Boardname in Section Device. Isn't it obvious? Why do you need the exact wording? What needs to be corrected is the detection routine; knowing the exact workaround is not necesary.

Except that I'm almost 100% certain that the BoardName entry isn't used by anything at all

On 9/14/06, Felix Miata wrote:

You're right about that, but the responses to the reporter could have done a better job of eliciting useful information from him.

indeed ... I think the reporter simply knew there was a problem, and thought that "novell" would like to know. He assumed that, once in bugzilla, some individual human would run with it, under their own initiative. He only knew the symptom ... that his card was being mis-identified ... he was not interested beyond that personally, especially since he had his own workaround. But he thougth Novell would/should be interested enough to check it out. If I were that guys boss ... I would not be happy about his performance. Peter

Anders Johansson wrote:

On Thursday 14 September 2006 15:52, Peter Van Lone wrote:

...

...

You're right about that, but the responses to the reporter could have done a better job of eliciting useful information from him. indeed ... I think the reporter simply knew there was a problem, and

On 9/14/06, Felix Miata wrote: thought that "novell" would like to know. He assumed that, once in bugzilla, some individual human would run with it, under their own initiative.

He only knew the symptom ... that his card was being mis-identified ... he was not interested beyond that personally, especially since he had his own workaround.

The obvious point is that the misidentification isn't the cause of the misconfiguration. What the exact cause is couldn't be determined, because the reporter *wouldn't say how it was misconfigured*. All he said was "it doesn't work, I changed something and now it works"

The bug reporter gives more than that. He does say that the error is caused by sax2, yes? He does specify his video card and the one erroneously reported by sax2. Plus, the reporter did offer to run a diagnostic on his machine, as long as it didn't write any changes to his system. And he did provide a correction to the pci.ids table. Not enough? You should warn your customers that they'll be held to very high standards if they ever want to (not even need to) report a bug.

...

But he thougth Novell would/should be interested enough to check it out.

If I were that guys boss ... I would not be happy about his performance.

Bugs cannot be fixed without information. Either a bug is reproduced locally, or the reporter provides enough information so that it can be tracked down. This is how debugging works, and no boss can make it otherwise

What if a bug report comes in and the user doesn't know what's causing the problem? He just knows that, upon install, the screen gets messed up. Do you just close the report and forget about the bug (what this developer did)? If that's the case, then it *is* silly to report a bug. -- One is not superior merely because one sees the world as odious. -- Chateaubriand (1768-1848)

On Thursday 14 September 2006 17:16, ken wrote:

The bug reporter gives more than that. He does say that the error is caused by sax2, yes? He does specify his video card and the one erroneously reported by sax2. Plus, the reporter did offer to run a diagnostic on his machine, as long as it didn't write any changes to his system. And he did provide a correction to the pci.ids table. Not enough? You should warn your customers that they'll be held to very high standards if they ever want to (not even need to) report a bug.

The bug reporter is you Ken. The developers also clearly state that what you call erroneous detection is not an error. The radeon driver covers both those cards you list in your bug report. Besides, that is just a text string for human consumption and has nothing to do with the quality, or lack thereof, of the video display.

...

Bugs cannot be fixed without information. Either a bug is reproduced locally, or the reporter provides enough information so that it can be tracked down. This is how debugging works, and no boss can make it otherwise

What if a bug report comes in and the user doesn't know what's causing the problem? He just knows that, upon install, the screen gets messed up.

The developers clearly ask you for the changes you made to xorg.conf. You clearly refuse to provide that information.

Do you just close the report and forget about the bug (what this developer did)? If that's the case, then it *is* silly to report a bug.

Since you, Ken, won't provide the necessary information to reproduce the bug, what can anyone do? You describe the problem only as a display that is "trashed and completely unusable". I can do that very easily on any system that I can get my fingers on its keyboard. IMNSHO you filed a very silly bug report. You refused to cooperate with the developers who asked you specifically what you did to fix the problem. You then ranted about everyone else's inability to read your mind. There may very well be a hardware/software problem but right now it looks more like a PEBKAC on your end. Stan

On 06/09/15 09:47 (GMT-0400) ken apparently typed:

Stan Glasoe wrote:

...

The developers clearly ask you for the changes you made to xorg.conf. You clearly refuse to provide that information.

If you actually read the bug report, specifically https://bugzilla.novell.com/show_bug.cgi?id=205096#c6:

"It was a couple years ago, so I don't remember. I saved a copy of the good (my hand-edited version) of xorg.conf. Then, when the screen got hosed, I overwrote the new xorg.conf with my good copy, went back into level 5 and I was good."

So how do you get "refuse to provide that information"?

Because you know how to restore a hosed configuration, and you should be able to hose it by running sax2 again, according to comment 4. That would provide an opportunity for you to capture the defective xorg.conf to attach to the bug, along with your working xorg.conf. It's actually what https://bugzilla.novell.com/show_bug.cgi?id=205096#c5 is looking for, even though it isn't stated explicitly. -- "Wisdom is supreme; therefore get wisdom. Though it cost all you have, get understanding. Esteem her, and she will exalt you; embrace her, and she will honor you." Proverbs 4:7-8 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/

On Friday 15 September 2006 21:00, ken wrote:

And because I might not want to hose a *production* system (noted at

A production desktop?

https://bugzilla.novell.com/show_bug.cgi?id=205096#c4) to help Suse solve *a problem I don't have*, that I reported only for the benefit of others and for Suse's benefit, Suse can't or won't fix it because I'm the problem and so am entitled to this brand of gratitude. Okay. I guess we understand each other now.

There really wasn't a problem, until people started screaming that the bug should have been fixed even without information about what the bug was You don't have to help in fixing the bug, but if you don't you really shouldn't complain that it doesn't get fixed.

Anyone else considering filing a bug report, you've been warned.

and I hope they learn the lesson: provide information = work gets done. No information = no solution

On 06/09/15 15:00 (GMT-0400) ken apparently typed:

...

...

If you actually read the bug report, specifically https://bugzilla.novell.com/show_bug.cgi?id=205096#c6:

And because I might not want to hose a *production* system (noted at https://bugzilla.novell.com/show_bug.cgi?id=205096#c4) to help Suse solve *a problem I don't have*, that I reported only for the benefit of others and for Suse's benefit, Suse can't or won't fix it because I'm the problem and so am entitled to this brand of gratitude.

Reporters who don't follow bugzilla protocol are entitled to nothing. All they do is waste people's time, including their own. In far less than the time you wasted writing all those useless additional comments in the bug, maybe 5-10 minutes, you could have: 1-dropped to runlevel 3 2-run sax2 3-tested that the new xorg.conf was in fact broken using startx 4-saved the broken file 5-restored the good xorg.conf 6-returned to runlevel 5 7-attached your good & bad xorg.conf & Xorg.0.log.old files to the bug Meanwhile, all normal "production" functions would have continued uninterrupted in runlevel 3. The respondents could have spelled this out, so only most of the blame is on you rather than all of it. -- "Wisdom is supreme; therefore get wisdom. Though it cost all you have, get understanding. Esteem her, and she will exalt you; embrace her, and she will honor you." Proverbs 4:7-8 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/

On Friday 15 September 2006 08:47, ken wrote:

Stan Glasoe wrote:

...

..... The developers also clearly state that what you call erroneous detection is not an error. The radeon driver covers both those cards you list in your bug report. Besides, that is just a text string for human consumption and has nothing to do with the quality, or lack thereof, of the video display.

So you're saying that there's no problem?

Not at all. I am saying that you won't provide the information that you have on your computer. Whatever the problem is can be worked around by your edits to xorg.conf that you won't provide to the developers so they have something to go on.

...

The developers clearly ask you for the changes you made to xorg.conf. You clearly refuse to provide that information.

If you actually read the bug report, specifically https://bugzilla.novell.com/show_bug.cgi?id=205096#c6:

"It was a couple years ago, so I don't remember. I saved a copy of the good (my hand-edited version) of xorg.conf. Then, when the screen got hosed, I overwrote the new xorg.conf with my good copy, went back into level 5 and I was good."

So how do you get "refuse to provide that information"?

You no longer have that specific xorg.conf file from that specific machine? Do you have that specific machine and do you use it and does it still exhibit this corrupt display? If you no longer have this machine or its not under your support, what's the point of complaining that the alleged issue isn't fixed?

I would think that anyone reading your false and inflammatory comment and similar comments of some others here are going to think twice before filing a bug report.

Ah, yeah. I read your supposed bug report very carefully before replying because I can tell you are out to pick a fight or troll or cause some kind of 'bash SUSE developers' fest. Over at http://en.opensuse.org/HCL/Laptops/Dell there is a Dell Inspiron 600M listed and video is a green check mark. Too bad there isn't more info than that or an xorg.conf to look at. I've even checked out http://tuxmobil.org/dell.html for Inspiron 600Ms and the few SUSE reports all say X works beautifully. Again, where's the info? If you can't provide the information then why even bother creating a bug report? Stan

On Friday 15 September 2006 17:11, Carlos E. R. wrote:

The Friday 2006-09-15 at 16:52 -0500, Stan Glasoe wrote:

...

You no longer have that specific xorg.conf file from that specific machine? Do you have that specific machine and do you use it and does it still exhibit this corrupt display? If you no longer have this machine or its not under your support, what's the point of complaining that the alleged issue isn't fixed?

The answer to this he already said in the report in bugzilla, but to save you time: I understand he has the edited (correct and working) file. He does not have the original hosed file because he edited it on top or erased it (I would have kept a copy, I always do). He can not test it because it is a production machine.

We also have to read what he says and not repeat answered questions ;-)

Carlos E. R.

That may be but then he is trying to get someone to fix a problem that no longer exists! If the machine in question is still running then there is an xorg.conf that can be copied off of it and sent in to be looked at by someone. And if Ken was the one to copy it off the machine then he may see something in it that may jog his memory about the edits he made. No one is asking him to test anything except the concept of sending information into the developers. Anyone out there either running SUSE 9.3 (or still have an archive of it from upgrades, etc) with a Dell Inspiron 600M with the Radeon 9000M graphics that could attach their xorg.conf to https://bugzilla.novell.com/show_bug.cgi?id=205096 ? Please? Ken: can you get the working xorg.conf off that machine and attach it to https://bugzilla.novell.com/show_bug.cgi?id=205096 ? Please? Maybe something will come of it if information is provided. Stan

On Friday 15 September 2006 12:11, Carlos E. R. wrote:

The Friday 2006-09-15 at 16:52 -0500, Stan Glasoe wrote:

...

You no longer have that specific xorg.conf file from that specific machine? Do you have that specific machine and do you use it and does it still exhibit this corrupt display? If you no longer have this machine or its not under your support, what's the point of complaining that the alleged issue isn't fixed?

The answer to this he already said in the report in bugzilla, but to save you time: I understand he has the edited (correct and working) file. He

so why the f...doesn't he give out that oh so famous xorg.conf?

does not have the original hosed file because he edited it on top or erased it (I would have kept a copy, I always do). He can not test it because it is a production machine.

tsk tsk tsk... there have been numerous howto's re this point...

We also have to read what he says and not repeat answered questions ;-)

-- Cheers, Carlos E. R.

Why have so many tried so hard to be nice to someone who apparently does not want to do anything other than complain? You 've been trolled. enough already. d.

Per Jessen wrote:

...

Do you just close the report and forget about the bug (what this developer did)? If that's the case, then it *is* silly to report a bug.

It's not the case.

/Per Jessen, Zürich

According to https://bugzilla.novell.com/show_bug.cgi?id=205096, the issue is "RESOLVED" and the "Resolution" is "WONTFIX". This tells me it *is* the case. -- One is not superior merely because one sees the world as odious. -- Chateaubriand (1768-1848)

On Friday 15 September 2006 15:47, Felix Miata wrote:

On 06/09/15 09:31 (GMT-0400) ken apparently typed:

...

Per Jessen wrote:

...

...

Do you just close the report and forget about the bug (what this developer did)? If that's the case, then it *is* silly to report a bug.

It's not the case.

According to https://bugzilla.novell.com/show_bug.cgi?id=205096, the issue is "RESOLVED" and the "Resolution" is "WONTFIX".

This tells me it *is* the case.

It isn't, because the current resolution is inappropriate. The appropriate resolution is INVALID, because it is CANTFIX based upon the information provided.

Didn't I read somewhere in this list that NEEDINFO would be more appropriate? (It seems to me it would) Cheers, Leen

On Friday 15 September 2006 17:43, Felix Miata wrote:

On 06/09/15 17:16 (GMT+0200) Leendert Meyer apparently typed:

...

On Friday 15 September 2006 15:47, Felix Miata wrote:

...

On 06/09/15 09:31 (GMT-0400) ken apparently typed:

...

According to https://bugzilla.novell.com/show_bug.cgi?id=205096, the issue is "RESOLVED" and the "Resolution" is "WONTFIX".

This tells me it *is* the case.

It isn't, because the current resolution is inappropriate. The appropriate resolution is INVALID, because it is CANTFIX based upon the information provided.

Didn't I read somewhere in this list that NEEDINFO would be more appropriate?

(It seems to me it would)

It was set to NEEDINFO 3 times without getting any usable new info, making INVALID a totally appropriate replacement.

Indeed: won't inform -> can't fix -> WONTFIX. Cheers, Leen

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2006-09-15 at 11:43 -0400, Felix Miata wrote:

On 06/09/15 17:16 (GMT+0200) Leendert Meyer apparently typed:

...

On Friday 15 September 2006 15:47, Felix Miata wrote:

...

...

On 06/09/15 09:31 (GMT-0400) ken apparently typed:

...

...

...

According to https://bugzilla.novell.com/show_bug.cgi?id=205096, the issue is "RESOLVED" and the "Resolution" is "WONTFIX".

...

...

...

This tells me it *is* the case.

...

...

It isn't, because the current resolution is inappropriate. The appropriate resolution is INVALID, because it is CANTFIX based upon the information provided.

...

Didn't I read somewhere in this list that NEEDINFO would be more appropriate?

...

(It seems to me it would)

It was set to NEEDINFO 3 times without getting any usable new info, making INVALID a totally appropriate replacement.

Notice that the wording "WONTFIX" can be thought as offensive. At first look, that word looks offensive to me (I come from a different culture), so it could be so to others. It is a bad choice of words, IMO: it can be interpreted to mean "I will not fix it because I don't wan't to fix it and I'm the boss and you shut up". Most probably that is not what is intended, but I find the choice of words in "WONTFIX" as very poorly choosen. The wording must be selected to be polite and understood by people from many cultures and backgrounds. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFCwfntTMYHG2NR9URAg0PAKCOVRwO7w+hxyG1ZCXSAmZeLvqJdQCeI9dl 8UUbCkKhQ7rT5Gwr38HXDsY= =CYgc -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2006-09-15 at 16:25 -0400, Felix Miata wrote:

WONTFIX is inherited with the Bugzilla software from Mozilla.org and is descibed for bugzilla.mozilla.org users at https://bugzilla.mozilla.org/page.cgi?id=fields.html#resolution .

Maybe it would be good for someone who takes this offense to go to bugzilla.mozilla.org or news.mozilla.org and bring this up.

I'm not offended, now. But I was quite "surprised" the first time I saw it. I just mentioned it so that you don't get surprised if you see now and then people "angry" with being told "wontfix". It is not for me to go to the mozilla people. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFCxxntTMYHG2NR9URAvw7AJ49AluPusedIQVid+PTheWyMH/S2wCfbe3J Sh3W7+Zav8rtZ/C3Qmv1EnI= =ShyJ -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2006-09-15 at 18:43 -0600, Darryl Gregorash wrote:

...

<snip>

It is not for me to go to the mozilla people.

Yes, it is.

No. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFC1MktTMYHG2NR9URAkWAAJsHzZCLdiUTskkJtzEWR8QHfGw/rwCeLMp2 /LYZ62cGFooiIEAYHTFPpSA= =EcuN -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2006-09-15 at 22:02 -0600, Darryl Gregorash wrote:

...

No.

You are the one who was complaining about the terminology in use, it sure isn't up to anyone else.

wontfix. Do you prefer it that way? :-P - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFC9uvtTMYHG2NR9URApSbAKCA7P6fJunvmFSpv9JX9MWnvFDVrACfTXeI agRxhz+dLMbAtlfVMmrQttE= =W1db -----END PGP SIGNATURE-----

On 16/09/06 05:10, Carlos E. R. wrote:

The Friday 2006-09-15 at 22:02 -0600, Darryl Gregorash wrote:

...

...

No.

You are the one who was complaining about the terminology in use, it sure isn't up to anyone else.

wontfix.

Do you prefer it that way? :-P

I don't have a problem with it. You do, it seems. You want me to write something like this to mozilla? "Dear bugzilla authors, Carlos has a problem with the 'wontfix' terminology, so I am writing to complain about it." Sure. I am sure they will get on that right away.

Anders Johansson wrote:

What could they have done? The reporter explictly said he wasn't going to provide any more information

All he said was "sax2 screws up xorg.conf". When asked how it got screwed up, he basically said "I can't remember, you figure it out, and it won't help you because you're not going to fix it anyway"

What would you have said to a comment like that?

Does he work for SCO? It sounds a lot like their legal arguments. ;-)

On Thursday 14 September 2006 18:16, John E. Perry wrote:

...

All he said was "sax2 screws up xorg.conf". When asked how it got screwed up, he basically said "I can't remember, you figure it out, and it won't help you because you're not going to fix it anyway"

What would you have said to a comment like that?

"Please send me a copy of your good xorg.conf"? Since he stated clearly that that fixed his problem, and stated clearly what the problem was, couldn't you have gained some information from that?

He didn't "state clearly what the problem was", all he said was "sax2 screwed up my config file". And no, a working system is generally useless for debugging purposes. A broken system can be debugged, but you can't look for bugs that don't exist anymore. In my debugging experience, the really useful bit would have been to find out what he changed to make it work

Even if not, someone should have been able to look at the code to see why the card was not identified correctly, or whether it was misidentifying itself.

The text string describing the card (which was what he complained about) is for human consumption. It isn't used for system configuration. The pci id database that maps PCI ids to text strings isn't even a requirement for a running system. You can run a system perfectly well without it (although the output from system tools like lspci will be much more boring for humans to read)

OK, here's an outsider's point-of-view... The original reporter could have been more helpful in offering up information e.g. the current, working xorg.conf. The SuSE person could have been more direct in asking for specific information e.g. the current, working xorg.conf. Before this degenerates into a slanging match about who is wrong and who said what to whom and why, let's admit that there's fault on both sides. Put it down to a personality clash/misunderstanding/moment of stress/whatever and let the SuSE people get back to their jobs. After all, every minute they're spending responding to these emails is time that they're /not/ fixing bugs and making SuSE Linux better... Yours in mutual reconcilliation... -- David Smith Work Email: Dave.Smith@st.com STMicroelectronics Home Email: David.Smith@ds-electronics.co.uk Bristol, England GPG Key: 0xF13192F2

Felix Miata wrote:

On 06/09/14 16:26 (GMT+0300) Silviu Marin-Caea apparently typed:

...

Some dude that filed a bug report without giving out useful information. Not laughing material, just boring.

You're right about that, but the responses to the reporter could have done a better job of eliciting useful information from him.

IMHO, the reporter was being deliberately uncooperative - which is just not the right attitude when you're asking others to help you. /Per Jessen, Zürich

On Thu, 14 Sep 2006 09:27:16 -0800 John Andersen wrote:

Sadly that's not all that uncommon. There was a thread here where someone reported a Floating Point "Glitch" when Zmd was running. Not a single word as to the nature of this "Glitch", what the "Glitch" actually did, how the "Glitch" was discovered, or even what the symptoms were. All we know is there was a "glitch".

Not useful. No possible help can be offered in these situations.

It was I. Perhaps I did not express myself clearly enough in my original report. I posted because I thought it was worth remarking on about a seeming coincidence of two unusual events (zmd starting to use up CPU when I didn't trigger it ; and an application reporting a floating point computation error <that application has experienced no errors before or since>). If I had been looking for help, I would have given more details . I believed that including that error text would NOT have clarified what I was posting about - namely the seeming COINCIDENCE that I thought was unusual. That is also why I deliberately used the word "glitch" . Since this to me was a one-time happening that was done and over with, I did not expect help to be offered to me -- nor did I __ask__ for any help. I posted because I wanted to set others besides me to thinking about: "Could this be more than a coincidence ?" mikus p.s. The 'glitch' was discovered more than 24 hours later, when I noticed that the background computational application was (still!) receiving less CPU than usual. Going over the periodic messages put out by that application, I saw the error message, and saw that the messages previous to the error showed the expected amount of CPU time received, whereas the messages after the error showed less CPU time available. [When I killed zmd, the application's CPU time went back to normal.] Perhaps me reporting this might have led you to believe me more when I said there was a "glitch" - but what I was focusing on was the coincidence, not on what led me to discover it.