Comments on: Bugs will not get fixed by themselves Blogs and Ramblings of the openSUSE Members Fri, 06 Mar 2020 17:50:09 +0000 hourly 1 By: Dean Hilkewich Wed, 11 Aug 2010 16:33:38 +0000 I can definiately see how a person gets frustrated and gives up. 11.3 was the first release that I never bothered really beta testings through the releases. The reason I quit doing it is simple. Far to many times a bug that I file will get assigned, marked as a bug and then nothing… one such example is Bug 551229 – ACPI confilct error on nforce boards. That bug was reported back in October of last year, it was even assigned and since then ignored. In this particular example the issue is still there even in the next version of oS. There is one sure way of ticking off a person and that’s by ignoring them. Even when a Novell employee reports the same bug, it still goes unaddressed. It makes a person get frustrated and wonder why they even bother. It’s especially frustrating when a bug goes on through multiple releases of the distribution.

By: Andreas Jaeger Thu, 05 Aug 2010 20:36:32 +0000 /var/log/zypp/history lists the order of package installs and rpm also has this information, so you could go back…

Regarding your comments on developers and users, we always notice when it fails but seldom recognize where it works. I’ve been pointed to some miserable fails and helped to resolve them. The one thing that has changed since 8.2 is that today, a technical fit user can report a bug publically, fix it himself and get it released as online update. So, there are ways to help the developer for those that have the knowledge…

By: gumb Thu, 05 Aug 2010 17:04:04 +0000 Fair enough comments, and there’s no point in somebody venting their spleen if they’ve done nothing to report or resolve an issue themselves. However, the expectations of the user are perhaps a little idealized in some circumstances. For example, many times when I’ve wanted to report a bug myself, I’ve only stumbled upon a problem having installed lots of online updates in the interim. Maybe it’s in a piece of software I only use from time to time, so trying to trace the responsible package would be difficult now that several system changes have been made and a reasonable period of time has elapsed since things were in a working state. Indeed, I wouldn’t even know how to determine which are the updated / changed packages in my system using YaST. I think such a feature has been discussed on openFATE and maybe it’s even in 11.3 (which I’m not yet using), but it’s often too difficult to determine in which package the bug lies. For those users who let the software update run in the background and handle everything automatically, it would perhaps be even more difficult.

Picking up on some of the previous commenter’s points, when I have reported bugs the wait for a response has sometimes been so long that I’ve since updated the distro and the problem is either fixed or non-applicable in my current version, so I can’t follow-up with anything useful by the time the reply arrives. On other occasions when I look in on bug reports submitted by others that are relevant to me also, the fix supplied is a patch in the form of a tar file or a vague technical instruction that doesn’t make much sense to me and is aimed at those of a developer mentality, or is stated as fixed in the factory version and I wait but find that it never gets backported (by which time I’ve upgraded anyway).

With regards to the broader strategy discussions, as a suse USER (someone quite adept at using computers and software in general but in no sense a developer) since seven years ago and version 8.2, one thing I’ve noted in recent years is that there is a bit of a gulf between the opensuse developer community, with their own set of aims and needs and internal discussions, and the everyday users of the distro who perhaps participate by way of the odd forum post, openFATE entry or other small contribution but are often just regular non-techy members of the public, and though I don’t have any easy answers I do feel there need to be more bridges between these two camps. As I suggested in some opensuse survey a while back, maybe creating a position not so much for a Community Manager as before (more of a PR role in Zonker’s case) but rather some liaison between users and developers, would be valuable. Though it’s not his principal role, it will be interesting to see if Jos can fulfill that task a little.

I should also point out that the above isn’t a critique of developers, since they have their own valid aims, it’s just that they’re not always aligned with those of average users, and probably never will be. So somebody or a group of people need to act as a go-between. Relying solely on the technology of bug-reporting systems, forums and feature request forms may not be enough.

By: AlbertoP Thu, 05 Aug 2010 04:04:05 +0000 This is all correct. However I find there is a discrepancy between what is requested to a user, and what happens after. Bugs must be reported, it is clear, but if you require a user to report a bug, you should make the commitment to fix it, or you will have an irritated user, who will leave at best, or who will criticize you.

Since we are in times of honest discussions for the strategy, I would like to invite you to consider that many bug reports were opened during the development stages of openSUSE 11.3, and many of those bugs, even serious, and affecting key components like the kernel and X are still there, with some comment from the developers at best, some rough invitation to fix the bug ourselves in other cases.

There is a bug (619754) affecting system shutdown, which has been reported during the development of 11.3, and made it in final. Still unfixed, even if the solution is reported on the upstream kernel mailing list and is part of the .35 kernel series. Similarly, openSUSE 11.3 has been released with a bug affecting X, which crashes in relation to the usage of GL applications.

As a consequence, I wound ask users to report bugs, but I would also expect a commitment, followed by practical results and not just words to give a better image of the project, to avoid the following problems:

– Slow response time on reports
– No solution coming to the update repo (too often!)
– Rough answers and invitations to “fix it yourself since it is a community distribution”