I received an email from a user who switched from openSUSE to Ubuntu since his Wireless netcard did not work. It worked with openSUSE 11.2 initially but after an online update it failed. He hoped that openSUSE 11.3 worked, tested it, it failed – and he gave up and wrote a frustrated email.
I was frustrated reading this since we should have been able to help this user if he contacted us in time.
Such a regression is bad but if nobody reports the regression, then it will not get fixed at all. The openSUSE project takes fixes from the upstream projects and also adds fixes ourselves and sends them upstream. Those fixes work on the system of the developer – or the systems of the upstream developers – but nobody has access to every single hardware that a chip supports, so regressions might happen. In the past I’ve seen that such regressions that are reported with a pointer to the exact version that failed, are often fixed quite fast.
How to get the bug fixed?
So, what should you do if you encounter a bug, especially a bug that only happens after running an online update? Let’s use this example: Wireless does not work anymore after an online update.
First, I would check which online update is responsible. So, the last run contained a number of packages and I guess that the Linux kernel is the culprit. So, let’s revert that package, e.g. install it again from the openSUSE DVD.
Once the package is identified, I would file a bug report at bugzilla.novell.com against the openSUSE release that I run, in this case against openSUSE 11.2.
Following the instructions about bug reporting, I would file the bug against the component “Kernel” and write something like:
“After running online update of the kernel (rpm package kernel-desktop, old package version 2.6.32.x, new package version 2.6.32.y), I cannot connect anymore to the wireless network with my wireless card xy.”
I would attach to this report some information about the working and the non-working system like the output of the “dmesg” command from both kernels, as well as information about the hardware. Information about the hardware can be accessed with “hwinfo” in general, in this case I would add the output of “hwinfo –wlan” as attachment to the bug report.
Next the kernel developers would look into the bugreport, came back with questions and might ask me to run some more tests or even install a kernel with fixes in it to confirm that everything works. Then these fixes would go into the next kernel that would be released as online update.
Both comments and pings are currently closed.
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”
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.
/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…
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.