-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
state of the bugs
I have been doing bugzilla-sceening for some months now using http://maintainer.zq1.de/ and
https://bugzilla.opensuse.org/buglist.cgi?bug_status=NEW&bug_status=ASSI...
As can be expected, the majority of new bugs is on 13.2 and Factory.
There are a good number of bugs, that get resolved in a couple of days and everyone lives happily ever after. I have seen very detailed, technical reports, even with patches or other contributions coming from reporters.
There are people missing dropped or renamed packages https://bugzilla.opensuse.org/show_bug.cgi?id=904559 nagios-nrpe https://bugzilla.opensuse.org/show_bug.cgi?id=908430 nagios-plugins
There are bugs about things we do for legal reasons https://bugzilla.opensuse.org/show_bug.cgi?id=904238 font/subpixel https://bugzilla.opensuse.org/show_bug.cgi?id=907942
There are a number of network things which used to work, but do not with wicked (for more or less good reasons) https://bugzilla.opensuse.org/show_bug.cgi?id=904380 TUNNEL_SET_GROUP https://bugzilla.opensuse.org/show_bug.cgi?id=907215 if-up.d https://bugzilla.opensuse.org/show_bug.cgi?id=904903 tun/tap https://bugzilla.opensuse.org/show_bug.cgi?id=908375 bridges https://bugzilla.opensuse.org/show_bug.cgi?id=895219 dhcp+routes
NetworkManager is also getting its fair share of issues
https://bugzilla.opensuse.org/show_bug.cgi?id=900982 ntp https://bugzilla.opensuse.org/show_bug.cgi?id=895447 disabling https://bugzilla.opensuse.org/show_bug.cgi?id=903871 wallets https://bugzilla.opensuse.org/show_bug.cgi?id=901008 KDE-icon
dracut is also still pretty young https://bugzilla.opensuse.org/show_bug.cgi?id=908452 -i handling https://bugzilla.opensuse.org/show_bug.cgi?id=906592 s2disk https://bugzilla.opensuse.org/show_bug.cgi?id=905615 btrfs 2dev https://bugzilla.opensuse.org/show_bug.cgi?id=900831 nfs root https://bugzilla.opensuse.org/show_bug.cgi?id=906716 missing swap
And a noteworthy number of suspend-related bugs. and UMTS-modem issues
Sometimes I am a bit worried about stale maintainer data in OBS, when I don't know if people would still care about the package. And it would not be good if we leave reporters with valid bugs for weeks (or forever), but currently we don't seem to care much about those leftover bugs.
Ciao Bernhard M. - -- (o_ //\ V_/_ http://www.suse.de/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
В Sun, 07 Dec 2014 12:32:13 +0100 "Bernhard M. Wiedemann" bwiedemann@suse.de пишет:
Was not it fixed in the meantime?
N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�
Am 07.12.2014 um 13:21 schrieb Andrei Borzenkov:
В Sun, 07 Dec 2014 12:32:13 +0100 "Bernhard M. Wiedemann" bwiedemann@suse.de пишет:
Was not it fixed in the meantime?
Yes, fixed:
Information for patch openSUSE-2014-738: ---------------------------------------- Name: openSUSE-2014-738 Version: 1 [...] Summary: recommended update for dracut Description: This recommended update for dracut fixes the following issue: - ensure root fsck runs after dracut-pre-mount.service which calls resume (bnc#906592)
Thanks again :-)
seife
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014-12-07 12:32, Bernhard M. Wiedemann wrote:
Sometimes I am a bit worried about stale maintainer data in OBS, when I don't know if people would still care about the package. And it would not be good if we leave reporters with valid bugs for weeks (or forever), but currently we don't seem to care much about those leftover bugs.
I have bugs opened for years. Eventually, somebody comes and just closes them saying that the openSUSE version I reported against does not exist, and please try on a new version - without anybody ever doing anything about the bug. I doubt the person closing it even reads it, maybe it is a script doing the closing.
Some of these bugs took me days, even weeks, to try collect the data.
Some of these automatically closed bugs are still present on the new releases (sometimes obviously so), so I reopen them. And they often are eventually closed again without activity on the next release.
It is very discouraging. So each time I report less and less.
- -- Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Sunday 07 December 2014 15.01:02 Carlos E. R. wrote:
On 2014-12-07 12:32, Bernhard M. Wiedemann wrote:
Sometimes I am a bit worried about stale maintainer data in OBS, when I don't know if people would still care about the package. And it would not be good if we leave reporters with valid bugs for weeks (or forever), but currently we don't seem to care much about those leftover bugs.
You never live the case as bugowner you ask information to user and never never get it :-)
I have bugs opened for years. Eventually, somebody comes and just closes them saying that the openSUSE version I reported against does not exist, and please try on a new version - without anybody ever doing anything about the bug. I doubt the person closing it even reads it, maybe it is a script doing the closing.
Find friends, and organize a bug squashing to confirm each bug open and also participate to the next bug squash day organized.
Some of these bugs took me days, even weeks, to try collect the data.
Some of these automatically closed bugs are still present on the new releases (sometimes obviously so), so I reopen them. And they often are eventually closed again without activity on the next release.
Quality of the report, wrong product ?
It is very discouraging. So each time I report less and less.
There's something you could do, find who make changes in the rpm changelog located the package on obs, use "users" tab and pick email of bugowner / maintainers try to add them in cc list
Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 12/07/2014 12:21 PM, Bruno Friedmann wrote:
On Sunday 07 December 2014 15.01:02 Carlos E. R. wrote:
On 2014-12-07 12:32, Bernhard M. Wiedemann wrote:
There's something you could do, find who make changes in the rpm changelog located the package on obs, use "users" tab and pick email of bugowner / maintainers try to add them in cc list
I have used this method and found it easier to get a response.
Cheers!
Roman
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014-12-07 18:21, Bruno Friedmann wrote:
On Sunday 07 December 2014 15.01:02 Carlos E. R. wrote:
You never live the case as bugowner you ask information to user and never never get it :-)
Oh, I do. I "own" very few bugs, but I do ;-) I contribute as translator.
I have bugs opened for years. Eventually, somebody comes and just closes them saying that the openSUSE version I reported against does not exist, and please try on a new version - without anybody ever doing anything about the bug. I doubt the person closing it even reads it, maybe it is a script doing the closing.
Find friends, and organize a bug squashing to confirm each bug open and also participate to the next bug squash day organized.
Pointless.
Those pesky bugs do not need extra confirmation, there are logs with detailed and hard to obtain information, requiring things like modifying the kernel, maybe place video cameras or hook a second computer to capture kernel messages over a serial port...
It just needs a developer to get inside and code, or ask pertinent questions, provide patches that I can install and test and give further info. I have done everything possible from my side.
Others are quite evident from the bug report and do not need anybody else confirming that they also get it. Specially if the logs says: this is a bug, please report me.
Finding friends looks to me "political lobbying". It is corruption. It is out of place in engineering and science, IMNSHO. If it is a bug, it is a bug, period. Perhaps a crate of beer will help to solve my bugs, leaving other people bugs unsolved? >:-)
Some of these bugs took me days, even weeks, to try collect the data.
Some of these automatically closed bugs are still present on the new releases (sometimes obviously so), so I reopen them. And they often are eventually closed again without activity on the next release.
Quality of the report, wrong product ?
Nope.
If it were, the bugowners/asignees/whatever could simply ask for clarification. I'm well known, I believe. I can make mistakes, I'm human, but every report I write has a lot of effort and care behind. They can be mistaken, but I do my best so that they are good quality.
It is very discouraging. So each time I report less and less.
There's something you could do, find who make changes in the rpm changelog located the package on obs, use "users" tab and pick email of bugowner / maintainers try to add them in cc list
Not my job.
I'm not going to install obs in order to find the maintainer. It is a large package and needs an account, and some reading documents.
That's the screening or triage team job, not users job.
- -- Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Monday 08 December 2014 05.00:10 Carlos E. R. wrote:
On 2014-12-07 18:21, Bruno Friedmann wrote:
On Sunday 07 December 2014 15.01:02 Carlos E. R. wrote:
You never live the case as bugowner you ask information to user and never never get it :-)
Oh, I do. I "own" very few bugs, but I do ;-) I contribute as translator.
I have bugs opened for years. Eventually, somebody comes and just closes them saying that the openSUSE version I reported against does not exist, and please try on a new version - without anybody ever doing anything about the bug. I doubt the person closing it even reads it, maybe it is a script doing the closing.
Find friends, and organize a bug squashing to confirm each bug open and also participate to the next bug squash day organized.
Pointless.
Those pesky bugs do not need extra confirmation, there are logs with detailed and hard to obtain information, requiring things like modifying the kernel, maybe place video cameras or hook a second computer to capture kernel messages over a serial port...
It just needs a developer to get inside and code, or ask pertinent questions, provide patches that I can install and test and give further info. I have done everything possible from my side.
How can dev fix a problem that can't be reproduced ... That's why adding people with same trouble or similar can really improve the situation
Others are quite evident from the bug report and do not need anybody else confirming that they also get it. Specially if the logs says: this is a bug, please report me.
Finding friends looks to me "political lobbying". It is corruption. It is out of place in engineering and science, IMNSHO. If it is a bug, it is a bug, period. Perhaps a crate of beer will help to solve my bugs, leaving other people bugs unsolved? >:-)
Some of these bugs took me days, even weeks, to try collect the data.
Some of these automatically closed bugs are still present on the new releases (sometimes obviously so), so I reopen them. And they often are eventually closed again without activity on the next release.
Quality of the report, wrong product ?
Nope.
If it were, the bugowners/asignees/whatever could simply ask for clarification. I'm well known, I believe. I can make mistakes, I'm human, but every report I write has a lot of effort and care behind. They can be mistaken, but I do my best so that they are good quality.
Then perhaps a list of concerned bugs would help to understand the why and what.
It is very discouraging. So each time I report less and less.
There's something you could do, find who make changes in the rpm changelog located the package on obs, use "users" tab and pick email of bugowner / maintainers try to add them in cc list
Not my job.
I'm not going to install obs in order to find the maintainer. It is a large package and needs an account, and some reading documents.
The only thing you need is a web browser and you openSUSE login. Nothing more, nothing less.
That's the screening or triage team job, not users job.
Guess who is triage/screening team : you and me and others its not only "their" responsibility.
-- Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014-12-08 08:49, Bruno Friedmann wrote:
On Monday 08 December 2014 05.00:10 Carlos E. R. wrote:
How can dev fix a problem that can't be reproduced ... That's why adding people with same trouble or similar can really improve the situation
That's absurd. A good developer should be able to solve bugs just by looking at logs and code. Logs constitute "hard proof".
For instance, this one:
Date: Sat, 24 May 2014 23:40:06 +0000 Subject: [Bug 879778] New: Kernel crash on multiple file write on reiserfs GPT partition.
Took me many days to investigate and report, with some help from the mail list. No one has even commented or asked for more info or anything at all, after reporting in bugzilla...
And it is a BUG, because the kernel log says it is a bug:
[18892.976044] BUG: unable to handle kernel paging request at ffffc90012825250
There is no more confirmation needed. It IS a BUG.
Another one.
Date: Tue, 4 Mar 2014 01:48:51 +0000 Subject: [Bug 866650] New: spamd: Use of each() on hash after insertion without resetting hash iterator results in undefined behavior, Perl interpreter
That it is a bug is evident from reading the log, you do not need corroboration.
Nothing has been commented on it since March. Either it cleared itself in June, or I updated spamassassin externally myself. I have forgotten.
Another one.
Date: Fri, 27 Dec 2013 14:13:01 +0000 Subject: [Bug 856849] New: Xterms do not resize correctly.
It has been re-assigned on Fri, 14 Nov 2014 21:54:35 +0000, after a year. Maybe now somebody will look at it, maybe not.
But you can understand that asking for details a year later can be pointless, as people forget the details as they try to work around the bug.
That's the screening or triage team job, not users job.
Guess who is triage/screening team : you and me and others its not only "their" responsibility.
There is specialization of labour. I can't do triage. For good triaging you need knowledge of problems, knowledge of the teams, and very important, contacts, pick the phone and ask. Or, it has to be a person of each team, that knows his team inside out.
For instance, I usually get given the bugzillas about the Spanish translation. I can either solve them myself, or know whom to ask. I know if the problem is ours or not, or whom to ask for verification. It is my responsibility and my "field".
- -- Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Am 10.12.2014 um 01:21 schrieb Carlos E. R.:
On 2014-12-08 08:49, Bruno Friedmann wrote:
On Monday 08 December 2014 05.00:10 Carlos E. R. wrote:
How can dev fix a problem that can't be reproduced ... That's why adding people with same trouble or similar can really improve the situation
That's absurd. A good developer should be able to solve bugs just by looking at logs and code. Logs constitute "hard proof".
For instance, this one:
Date: Sat, 24 May 2014 23:40:06 +0000 Subject: [Bug 879778] New: Kernel crash on multiple file write on reiserfs GPT partition.
Took me many days to investigate and report, with some help from the mail list. No one has even commented or asked for more info or anything at all, after reporting in bugzilla...
And it is a BUG, because the kernel log says it is a bug:
[18892.976044] BUG: unable to handle kernel paging request at ffffc90012825250
There is no more confirmation needed. It IS a BUG.
Yes. But it's apparently a bad pointer dereference in the timer code => most likely a nasty race condition. That is usually not easily solved by "just looking at logs and code". Sorry.
Now I know that reporting bugs against distro kernels is sometimes hard, simply because it is often the case that the distro's kernel maintainers are also busy with developing the mainline kernel. So the first thing I do is: I try if the bug is still present in the latest Kernel:Stable kernel, and if so, if it's still present in the latest Kernel:HEAD kernel.
Often, if you can tell "this happens with 13.2 kernel, but no longer in the Kernel:Stable version", the maintainers will much more happily look into the differences and find something useful. Or, if it is still in Kernel:HEAD, then just go to the linux-kernel@vger.kernel.org list and complain about it there.
Fortunately, the openSUSE kernel are close enough to mainline that quite often you can go to the upstream projects and just ask there, without them complaining that you absolutely need to reproduce this first with the hand-built Linus-tree-of-the-day.
And yes, I am sometimes asking on opensuse-kernel instead of linux-kernel@vger, if I for example know that both people that are possible able to help me are actually kernel hackers employed by SUSE :-), see http://lists.opensuse.org/opensuse-kernel/2014-11/msg00059.html (the thread continues into December).
I was pretty successful with getting my bugs fixed like that. Yes, it is a lot of work, but that's what we (as non-hardcore kernel hackers) just have to contribute to kernel development. If I don't want that, then I have to buy Windows (or SLES) and pay for support.
For this particular bug, it might just be bad luck that reiserfs is no longer really actively maintained by anoyone? I don't know.
Best regards,
Stefan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014-12-11 15:15, Stefan Seyfried wrote:
Am 10.12.2014 um 01:21 schrieb Carlos E. R.:
Took me many days to investigate and report, with some help from the mail list. No one has even commented or asked for more info or anything at all, after reporting in bugzilla...
And it is a BUG, because the kernel log says it is a bug:
[18892.976044] BUG: unable to handle kernel paging request at ffffc90012825250
There is no more confirmation needed. It IS a BUG.
Yes. But it's apparently a bad pointer dereference in the timer code => most likely a nasty race condition. That is usually not easily solved by "just looking at logs and code". Sorry.
No, what I mean is that it is easy to identify that there is a bug without me having to find other people with the same problem - not that it is easy to solve.
In this case, I was for weeks able to reproduce the failure at will and obtain more data, if they asked. They did not. They ignored me.
Now I know that reporting bugs against distro kernels is sometimes hard, simply because it is often the case that the distro's kernel maintainers are also busy with developing the mainline kernel. So the first thing I do is: I try if the bug is still present in the latest Kernel:Stable kernel, and if so, if it's still present in the latest Kernel:HEAD kernel.
For that, they could ASK.
As I said in the report, I had a test setup rigged up, found the problem, investigated, for several days, maybe weeks, and reported. In deference to bugzilla people, I kept that setup untouched for some weeks, then I had to move on and use the hard disk.
Nobody was interested. It affects reiserfs, and that is doomed.
For this particular bug, it might just be bad luck that reiserfs is no longer really actively maintained by anoyone? I don't know.
Possibly.
But you see, I spent a long time investigating an issue and obtaining data, having to rig a second computer to record the logs during the crash, and first having to find how to do that, and all for nothing. Happened a few times to me.
Which is the main point: it is discouraging to report in Bugzilla if nobody listens. Not even a thankyou, we read you, but we are understaffed.
- -- Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014-12-08 05:00, Carlos E. R. wrote:
On 2014-12-07 18:21, Bruno Friedmann wrote:
On Sunday 07 December 2014 15.01:02 Carlos E. R. wrote:
Some of these bugs took me days, even weeks, to try collect the data.
Some of these automatically closed bugs are still present on the new releases (sometimes obviously so), so I reopen them. And they often are eventually closed again without activity on the next release.
please give some links, so I can have a look
It is very discouraging. So each time I report less and less.
yes, I have felt this frustration myself in the past and this is why I spend time trying to get bugs to the right people and starting this thread.
There's something you could do, find who make changes in the rpm changelog located the package on obs, use "users" tab and pick email of bugowner / maintainers try to add them in cc list
Not my job.
I'm not going to install obs in order to find the maintainer. It is a large package and needs an account, and some reading documents.
That's the screening or triage team job, not users job.
http://maintainer.zq1.de/ can make this much easier.
Btw: if you have a bugzilla account, you can also access https://build.opensuse.org with it.
Ciao Bernhard M.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014-12-08 11:32, Bernhard M. Wiedemann wrote:
On 2014-12-08 05:00, Carlos E. R. wrote:
On 2014-12-07 18:21, Bruno Friedmann wrote:
On Sunday 07 December 2014 15.01:02 Carlos E. R. wrote:
Some of these bugs took me days, even weeks, to try collect the data.
Some of these automatically closed bugs are still present on the new releases (sometimes obviously so), so I reopen them. And they often are eventually closed again without activity on the next release.
please give some links, so I can have a look
Let me see if I can locate some samples [...] ok.
For instance, 765084, was bureaucratically closed. I spent many hours of effort on it, even wrote changes to the kernel.
It is just an example, I do not want that particular one reopened. My memory is not what it was, I simply located that one first.
Date: Fri, 3 Feb 2012 22:12:51 +0000 Subject: [Bug 745024] Kernel vmlinuz-3.1.9-1.4 update failure
was bureaucratically closed on Fri, 8 Aug 2014, a year later. Never really solved, just closed. Of course, it is now impossible and pointless to try to solve.
Or this one, a curious one for the community:
Date: Thu, 17 Nov 2011 04:05:59 +0000 Subject: [Bug 730912] Gramar rules need to be changed for "openSUSE".
This one was about LO forcing grammar rules to write "OpenSUSE" at the start of sentences. Was bureaucratically closed on Mon, 28 Jul 2014, and I reopened it a month later, because the "bug" is of course still present. No, I do not intend to pursue the matter upstream myself, I can not convince anybody there. Some heavy weight from Novell/SUSE/openSUSE has to do that. This bugzilla tracks the situation. (I thought that Novell was a big contributor to OOo previously... :-? They should have the force to make this change)
- -- Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
- -- Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Wed, Dec 10, 2014 at 01:08:42AM +0100, Carlos E. R. wrote:
On 2014-12-08 11:32, Bernhard M. Wiedemann wrote:
On 2014-12-08 05:00, Carlos E. R. wrote:
On 2014-12-07 18:21, Bruno Friedmann wrote:
On Sunday 07 December 2014 15.01:02 Carlos E. R. wrote:
Some of these bugs took me days, even weeks, to try collect the data.
Some of these automatically closed bugs are still present on the new releases (sometimes obviously so), so I reopen them. And they often are eventually closed again without activity on the next release.
please give some links, so I can have a look
Let me see if I can locate some samples [...] ok.
For instance, 765084, was bureaucratically closed. I spent many hours of effort on it, even wrote changes to the kernel.
Dude, Jeff made the usual post release cleanup.
It had been your opportunity to evaluate this with the 12.2 release.
This unfortunately happens quite often and everyone of us has to shift reports from one release to the next.
It is just an example, I do not want that particular one reopened. My memory is not what it was, I simply located that one first.
Date: Fri, 3 Feb 2012 22:12:51 +0000 Subject: [Bug 745024] Kernel vmlinuz-3.1.9-1.4 update failure
was bureaucratically closed on Fri, 8 Aug 2014, a year later. Never really solved, just closed. Of course, it is now impossible and pointless to try to solve.
Again, this isn't "bureaucratically". It's the normal workflow.
All you had to do is to test it with 12.2 and add update the report if it's fixed or if it still exists.
Or this one, a curious one for the community:
Date: Thu, 17 Nov 2011 04:05:59 +0000 Subject: [Bug 730912] Gramar rules need to be changed for "openSUSE".
This one was about LO forcing grammar rules to write "OpenSUSE" at the start of sentences. Was bureaucratically closed on Mon, 28 Jul 2014, and I reopened it a month later, because the "bug" is of course still present.
And you've read comment #2?
No, please don't answer to this question. It was a rhetorical one.
No, I do not intend to pursue the matter upstream myself, I can not convince anybody there. Some heavy weight from Novell/SUSE/openSUSE has to do that. This bugzilla tracks the situation. (I thought that Novell was a big contributor to OOo previously... :-? They should have the force to make this change)
Comment #6 is the usual, I expect some automated post release cleanup Andreas did.
And the value of comment #7 is close to 0 in the light of comment #2.
Sorry, it's not this easy to blame others.
Thanks,
Lars
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014-12-10 14:55, Lars Müller wrote:
On Wed, Dec 10, 2014 at 01:08:42AM +0100, Carlos E. R. wrote:
Again, this isn't "bureaucratically". It's the normal workflow.
All you had to do is to test it with 12.2 and add update the report if it's fixed or if it still exists.
No, that is not the issue. The issue is that, after the reporter spending time and effort on reporting, nothing is done for months or years, then the bug report is removed in the spring cleanup, because it is old. Ok, because that release is no longer supported. That's the point, that nobody did anything on it for many months.
The point is not that the reporter can check whether the issue is still present on the next release.
And you've read comment #2?
No, please don't answer to this question. It was a rhetorical one.
But I will: it is not my issue, it is the openSUSE organization issue. I only point out its presence, I don't personally care.
And in this case, the issue is not related to a particular distribution, so closing the "bug" because the release number cited in the description is obsolete is incorrect. That's the issue here, not the content of that particular report.
- -- Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Thu, Dec 11, 2014 at 1:09 PM, Carlos E. R. carlos.e.r@opensuse.org wrote:
Again, this isn't "bureaucratically". It's the normal workflow.
All you had to do is to test it with 12.2 and add update the report if it's fixed or if it still exists.
No, that is not the issue. The issue is that, after the reporter spending time and effort on reporting, nothing is done for months or years, then the bug report is removed in the spring cleanup, because it is old. Ok, because that release is no longer supported. That's the point, that nobody did anything on it for many months.
The point is not that the reporter can check whether the issue is still present on the next release.
I've been on both sides of this.
As a bug reporter, I want the issue addressed, and silence is very annoying. After long silences, a post merely asking to confirm whether the issue still exists (as if it were to vanish spontaneously for no reason) is also extremely annoying.
But as a developer, I know bugs do vanish, seemingly unrelated changes sometimes fix issues, and when someone points out a bug in an old version I immediately search my memory for seemingly related commits that might affect the bug, and end up asking to reproduce the issue on the latest version.
As a developer, that saves us lots of blind searching, which is also particularly annoying and exhausting.
They key is balance... not asking for it when you can test yourself, not getting annoyed when asked to reproduce something and just do it unless it's very difficult, etc.
Sometimes it's good to know both sides.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014-12-11 17:30, Claudio Freire wrote:
On Thu, Dec 11, 2014 at 1:09 PM, Carlos E. R. <> wrote:
...
Yes, I can understand all that.
They key is balance... not asking for it when you can test yourself, not getting annoyed when asked to reproduce something and just do it unless it's very difficult, etc.
Attempting to reproduce that reiserfs bug requires me buying a new 3 TB hard disk, and doing nothing else but test, for days. So yes, it is hard and expensive. I kept the setup available for at least two weeks, then I filled the disk. If someone had asked something in time, I would have delayed as long as necessary. With no action, I had to move on...
Maybe, just maybe, I could try under vmware player and assigning a new 2TB disk I have available. But what for? It will be again ignored. Waste of time.
The "no response" is very frustrating for reporters. Years ago I made tons of reports. Now perhaps a dozen a year.
Yet I encourage others to report... maybe they have more luck.
- -- Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Thursday 11 December 2014 18.05:51 Carlos E. R. wrote:
On 2014-12-11 17:30, Claudio Freire wrote:
On Thu, Dec 11, 2014 at 1:09 PM, Carlos E. R. <> wrote:
...
Yes, I can understand all that.
They key is balance... not asking for it when you can test yourself, not getting annoyed when asked to reproduce something and just do it unless it's very difficult, etc.
Attempting to reproduce that reiserfs bug requires me buying a new 3 TB hard disk, and doing nothing else but test, for days. So yes, it is hard and expensive. I kept the setup available for at least two weeks, then I filled the disk. If someone had asked something in time, I would have delayed as long as necessary. With no action, I had to move on...
Maybe, just maybe, I could try under vmware player and assigning a new 2TB disk I have available. But what for? It will be again ignored. Waste of time.
The "no response" is very frustrating for reporters. Years ago I made tons of reports. Now perhaps a dozen a year.
Yet I encourage others to report... maybe they have more luck.
-- Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Funky your "perfect" bug report is just lacking critical information like hardware information kernel version and so.
I was interested to try to reproduce next week-end, but now I'm sure it will not resolve your main problem. Please read, re-read again the mail Richard has sent.
Bruno Friedmann wrote:
On Thursday 11 December 2014 18.05:51 Carlos E. R. wrote:
On 2014-12-11 17:30, Claudio Freire wrote:
On Thu, Dec 11, 2014 at 1:09 PM, Carlos E. R. <> wrote:
...
Yes, I can understand all that.
They key is balance... not asking for it when you can test yourself, not getting annoyed when asked to reproduce something and just do it unless it's very difficult, etc.
Attempting to reproduce that reiserfs bug requires me buying a new 3 TB hard disk, and doing nothing else but test, for days. So yes, it is hard and expensive. I kept the setup available for at least two weeks, then I filled the disk. If someone had asked something in time, I would have delayed as long as necessary. With no action, I had to move on...
Maybe, just maybe, I could try under vmware player and assigning a new 2TB disk I have available. But what for? It will be again ignored. Waste of time.
The "no response" is very frustrating for reporters. Years ago I made tons of reports. Now perhaps a dozen a year.
Yet I encourage others to report... maybe they have more luck.
-- Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Funky your "perfect" bug report is just lacking critical information like hardware information kernel version and so.
Please Bruno, this is not about the quality of an individual report.
Besides, it is often difficult for a reporter to know what information to provide. That is really up to the other side to determine and ask for.
On Fri, Dec 12, 2014 at 4:28 AM, Per Jessen per@computer.org wrote:
Bruno Friedmann wrote:
On Thursday 11 December 2014 18.05:51 Carlos E. R. wrote:
On 2014-12-11 17:30, Claudio Freire wrote:
On Thu, Dec 11, 2014 at 1:09 PM, Carlos E. R. <> wrote:
...
Yes, I can understand all that.
They key is balance... not asking for it when you can test yourself, not getting annoyed when asked to reproduce something and just do it unless it's very difficult, etc.
Attempting to reproduce that reiserfs bug requires me buying a new 3 TB hard disk, and doing nothing else but test, for days. So yes, it is hard and expensive. I kept the setup available for at least two weeks, then I filled the disk. If someone had asked something in time, I would have delayed as long as necessary. With no action, I had to move on...
Maybe, just maybe, I could try under vmware player and assigning a new 2TB disk I have available. But what for? It will be again ignored. Waste of time.
The "no response" is very frustrating for reporters. Years ago I made tons of reports. Now perhaps a dozen a year.
Yet I encourage others to report... maybe they have more luck.
-- Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Funky your "perfect" bug report is just lacking critical information like hardware information kernel version and so.
Please Bruno, this is not about the quality of an individual report.
Besides, it is often difficult for a reporter to know what information to provide. That is really up to the other side to determine and ask for.
And in a timely manner. Reproduceability is limited in time.
That should probably be a top priority: gathering all the facts in time, even if the bug itself is left for later, asking all the relevant questions promptly would help a bunch.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014-12-12 21:14, Claudio Freire wrote:
On Fri, Dec 12, 2014 at 4:28 AM, Per Jessen per@computer.org wrote:
Bruno Friedmann wrote:
And in a timely manner. Reproduceability is limited in time.
That should probably be a top priority: gathering all the facts in time, even if the bug itself is left for later, asking all the relevant questions promptly would help a bunch.
Absolutely!
- -- Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Friday 12 December 2014 21.21:39 Carlos E. R. wrote:
On 2014-12-12 21:14, Claudio Freire wrote:
On Fri, Dec 12, 2014 at 4:28 AM, Per Jessen per@computer.org wrote:
Bruno Friedmann wrote:
And in a timely manner. Reproduceability is limited in time.
That should probably be a top priority: gathering all the facts in time, even if the bug itself is left for later, asking all the relevant questions promptly would help a bunch.
Absolutely!
So to resume why this has not been took into account by screening bug triage ?
Thus I wonder how much of those kind of report we have?
Could we have statistics about, then concentrate on global facts, and what we need to resolve this mis-behaviour we all have?
How and what can improve the situation, workflow processing etc of bug-triage/screening team?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014-12-12 08:28, Per Jessen wrote:
Bruno Friedmann wrote:
Please Bruno, this is not about the quality of an individual report.
Besides, it is often difficult for a reporter to know what information to provide. That is really up to the other side to determine and ask for.
Indeed!
- -- Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014-12-12 06:39, Bruno Friedmann wrote:
On Thursday 11 December 2014 18.05:51 Carlos E. R. wrote:
Funky your "perfect" bug report is just lacking critical information like hardware information kernel version and so.
That could have been asked.
Kernel version is in the logs, and also it is known as being the whatever the default was in the distribution-release against which the report was made. If it were different, I would have said so.
Hardware is a field in the bugzilla. If more info is needed, you only need to ask, and I can gladly provide.
Excuses...
- -- Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 11 December 2014 at 17:09, Carlos E. R. carlos.e.r@opensuse.org wrote:
No, please don't answer to this question. It was a rhetorical one.
But I will: it is not my issue, it is the openSUSE organization issue. I only point out its presence, I don't personally care.
Carlos, you are an openSUSE Member
By definition, that makes you a member of 'the openSUSE organization' and therefore not only in position to influence, implement, and change things (everyone, not just oopenSUSE Members have that ability), but have proven your ability to contribute for a long period of time, sustained and substantially, and therefore should feel some responsibility towards doing so.
Statements like "I only point out its presence, I don't personally care." doesn't help anybody. If you really don't care, I'd recommend you stop commenting
If you do actually care, I'd recommend listening to much of the good feedback you've received on your points so far, absorb, and then propose and/or implement actual practical improvements for the project
Expecting our contributors to answer every single bug is not reasonable. Expecting them to be able to magically divine whether a bug is valid or not when they do get time to review it is also not reasonable. Part of good bug reporting is championing and being persistent with those bugs that matter to you, making sure they get attention, and being prompt in responding to questions when asked about the bug. Failure to do that, is just going to make it easier for those bugs to slip through the cracks, and that's a responsibility of the bug reporter just as much as the maintainer of the bug-impacted package.
Like Claudio said, the key is balance, please reflect on everyone's responses to you in this thread and try and find a more balanced view.
Regards,
Richard
What a thread. Quite an exercise in 'blame the user'.
There are certainly issues I do not see eye to eye on with Carlos.
On this one, however, I couldn't agree more -- and applaud him for having the tenacity and thick skin to bother trying to make the point.
From where I sit, and across my organization, bug-chasing/reporting for many instances that require significant effort to find, report, diagnose & fix them, is often seen as a waste of time. Particularly when something 'critical' is allowed to languish, or not even acknowledged, let alone responded to.
IMO, it's not an argument worth having -- mainly because it's seen as an argument.
In the end, the options are limited -- fix it yourself, or go elsewhere.
Here, anyway, we're increasingly & urgently doing both.
Again, Carlos is not alone in this experience -- I'm afraid he may be increasingly so in the resolution of it.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014-12-11 18:30, Richard Brown wrote:
On 11 December 2014 at 17:09, Carlos E. R. <> wrote:
No, please don't answer to this question. It was a rhetorical one.
But I will: it is not my issue, it is the openSUSE organization issue. I only point out its presence, I don't personally care.
Carlos, you are an openSUSE Member
By definition, that makes you a member of 'the openSUSE organization' and therefore not only in position to influence, implement, and change things (everyone, not just oopenSUSE Members have that ability), but have proven your ability to contribute for a long period of time, sustained and substantially, and therefore should feel some responsibility towards doing so.
Statements like "I only point out its presence, I don't personally care." doesn't help anybody. If you really don't care, I'd recommend you stop commenting
Don't take it out of context, because that sentence is about a very precise bug: that LibreOffice forces "openSUSE" to be written as "OpenSUSE" at the start of a sentence.
I don't personally care about that particular problem, I only reported its existence. And I can not possibly do anything about that issue. It is not my field.
Don't blame me, developers often say the same about why they do this or that. So can I. Or they don't say it, but act it. I'm sincere.
The issue came out on a mail thread, and I took upon me to report it. As simple as that. Report as in there being a Bugzilla that tracks its existence, for as long as the issue is present.
- -- Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
-
Andrei Borzenkov -
Bernhard M. Wiedemann -
Bernhard M. Wiedemann -
Bruno Friedmann -
Carlos E. R. -
Claudio Freire -
grantksupport＠operamail.com -
Lars Müller -
Per Jessen -
Richard Brown -
Roman Bysh -
Stefan Seyfried