Mailinglist Archive: opensuse (3506 mails)
| < Previous | Next > |
Re: [SLE] Why it's silly to file a bug report to Novell
- From: Matthias Hopf <mhopf@xxxxxxx>
- Date: Fri, 15 Sep 2006 10:15:55 +0000 (UTC)
- Message-id: <20060915101550.GC23337@xxxxxxx>
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 <mhopf@xxxxxxx> __ __ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@xxxxxxxxx
Phone +49-911-74053-715 __) |_| __) |__ labs www.mshopf.de
> > 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 <mhopf@xxxxxxx> __ __ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@xxxxxxxxx
Phone +49-911-74053-715 __) |_| __) |__ labs www.mshopf.de
| < Previous | Next > |