Imagine there are Test versions ....

English Open Chat
1

… and nobody reports the bugs.

Or:

What really p***es me off about the “community” nowadays

Yes, time for a little rant of my own now.

Reading the threads in the “Pre Release Beta” subforum makes me shake my head in more than 95% of all cases.

Statement:

Regarding the real value of versions explicitly marked for testing, this subforum is the most misunderstood and therefore most useless part of this (but to make you a bit more comfortable, not only this, it is the same in several different fora) forum.

Reasons for this statement:

  • Only a minimal percentage of threads in this subforum really deal with testing unstable versions and reporting bugs to the maintainers/developers.

  • There are many threads regarding software not even an officially supported part of the distribution to be tested -or even worse- not even part of other, well respected third party maintainers like packman. Have a look at the amounts of threads regarding proprietary graphics drivers, which are maintained by the vendors and where bugs could only be fixed by them.

  • Nearly none of the threads refer to a bug report on the problem, no matter if already exists or (as in most cases) still does not.

  • Nearly none of the threads offer test cases how to reproduce potential bugs or describe problems in a way one would expect from somebody being able to actually do some meaningful testing.

Conclusions:

Only few “testers” seem to understand the main reason behind unstable versions and giving them to the community; the opportunity to give feedback to the ones being able to fix bugs.

Instead, this subforum seems to be the trash dump for whining about XYZ not working in an unstable release without any real motivation of actually doing something about it yourself.

Will this really improve the quality of the distribution?

Maybe yes, but only in the way, that hopefully somebody else (no, count me out on that, I’ve given up some time ago. If people don’t have the time and motivation to write decent bug reports at least give valuable descpriptions on the problem on their own, then they shouldn’t use unstable versions) will do some extra work for them (and very often those are the people already doing a lot of work on their own for the same purpose).

Is this what community stands for?

At least for me it isn’t, as it will waste a lot of time for minimal (or even none) extra value.

I don’t know, what the recent definition of community is at the moment, but for me community stands for “take and give back, even if you can’t give back a lot”.

Whining about “xyz not working” without any recognizeable motivation to actually do some work on her/his own is certainly not “community”.

I bet you, when deleting more than 90% of the threads in that subforum one would not throw away anything substantial, maybe it is not a lot better in other subfora, but this can not be something being satisfied with.

This is not about ‘you should not test if you are not a “Linux God” with 15 years of experience and at least 100 contributions to kernel/xorg/glibc/whatever otherwise you are not qualified’, this is about ‘Why do you run test versions, when you obviously don’t even think about reporting problems to the maintainers?’.

Even a rather new user to Linux/openSUSE can contribute to the community, but also a lot of users which seem to be experienced very rarely show that they actually post with the main point for testing in mind.

I don’t get it, I really don’t, maybe somebody can enlighten me, when I seem to have lost the meaning of what I thought “community” and FLOSS stands for.

2

I sympathise - and now you have got that off your chest, you can get back to the important business of reporting bugs in RC-2.

3

I don’t use RC2 any more.

Deleted it yesterday (two VM) and will wait for the release.

If there are still bugs in it, I will search for solutions/workarounds when they hit me.

The bugs I reported before were fixed and the potential one I posted here (including a test case and asking for confirmation) got no responses from all those “testers”, so why should I care any longer about their problems?

I will start to care if they become mine, exactly the same way as most of the others seem to think about this issue.

4

I am afraid I bear with you.

5

Don’t be afraid, but to be honest, your thread yesterday was the one which really made me think, because it actually was the way it should be, even with a high possibility that you really have a difficult (as read in “rare and very unusual”) problem and it was a (much too) rare exception.

So in fact, the last bug report/problem I am really still interested in, is this strange missing CPU bug.

6

I share the view that we see too much of that.

Unfortunately that is something common to more than just the Pre-Release/Beta area, and I believe it also (besides disliking the forum format) is one of the reasons we have too few developers/packagers visit the forum. Those packagers/developers that do on occasion come to visit - come to help in the technical, not listen to the rants.

My view, which has evolved over the years, is the best way to help redirect the forum is as much as possible to answer rants (about x and y not working) with technical replies (and try not to get drawn in by the emotions) Also to make our own requests for help as technically factual as possible. Unfortunately, answering rants with technical posts (ignoring the emotion/illogical in the rant) is “easier said than done” as the illogic of so many rants makes it difficult not to “snap back”. But I do believe that a pure technical response (to the max extent possible - which can be very difficult when there is a dearth of factual information) is the way to help turn things around.

7

Well, generally speaking, you are correct, but maybe I should not have used the term “whining”, because it was not meant to be about rants.

The real problem is the obviously missing motivation of most users posting their problems on test versions, to do their homework before posting.

a) What information will be needed?

b) Where is the appropriate bug tracker for my problem?

c) How can I describe how to reproduce the bug to get confirmation?

Now a least a) is not an issue specific to “Pre-Release/Beta”, but if a new users with maybe only very few posts needs some help on that, this is OK, but for somebody actually testing alphas/betas this should be considered as a prerequisite the tester must know, perhaps not in detail but at least

a) stating the OS version & architecture

b) stating versions of software involved

c) providing useful information on hardware (USB/PCI-IDs instead of only “fancy names”) involved

should be “normal business” for such users.

8

I’d say it’s a good thing the questions relating to third party packages don’t end up on the bug tracker as most of the time they’re caused by simply version numbers not adding up. (Using 11.1 repositories with 11.2 might give some issues)

But yes, a whole lot of problems should end up on the bugtracker instead of the forums.

Can’t blame people for wanting NVidia drivers on their beta version can you? After all it’s awfully hard to run the KWin effects without them, and I’d like to watch some videos as well (so I need both SMPlayer AND the NVidia drivers)

9

I agree that having the proprietary driver available for testing is a good idea.

But the point is the proprietary driver IS available (just a repos is not). They can be installed “the hardway”, which is what I have done (where the hardway is not hard). In my case I had to install a “proprietary” beta nVidia driver, but it worked.

If the proprietary beta driver (such as the nVidia) does NOT work (but in this case it does) then a user should be writing a bug report on the nVidia (not the Novell) bug tracking mechanism (IMHO).

As for a proprietary driver not being packaged as an rpm for installation - the intention is these openSUSE releases are put forward for testing by reasonably knowledgeable users. All aspects of the release are not complete, because of that very aspect. Drivers are available, but are not yet “as polished” (ie in repos). It is expected that the users who volunteer to help are able to surmount these minor hiccups.

There are simply insufficient volunteers to package every minute detail (such as repos of proprietary drivers for a milestone/RC candidate release, where such release come out every few weeks - thats simply too much effort to try to produce IMHO). Alternative methods to install (such as the “hardway” - which happens to be easy) are available.

10

I’m not too sure it would be that helpful if Bug reporting were that simple. ATM, it’s really only the more experience that enter in to this. It’s probably better that inexperienced users do arrive here first, present their case/issues and allow us to identify the possible issues. Yes, we may not like it, but IMO it’s better than flooding Bugzilla with a load of useless reports.

11

First of all, you can blame them for two things.

a) Not knowing, that they will not be able to report any kernel related bugs after that without reproducing the problem after uninstalling that driver, because it taints the kernel and therefor bug reports with this tainted kernel can not be accepted

b)Obviously not knowing how to build the driver “the hard way” no matter what distro, they would have the same problems on a stable release. I can not use the NVidia drivers on my test installations, because they are (or better “were”) VMs. What I could do (and did) was to build the drivers from my “own” (modified from jengelh’s specs) src.rpms, and none of the drivers made any problems building. The src.rpm contains only one patch, which is needed to adjust the Makefile when building chrooted, so it is of no relevance for building via the run-installer. This leads to the conclusion, that all “NVidia driver not building with 11.2-whatever-pre-version”-problems are neither related to the drivers nor to the distro but to the users themselves not being able to install the driver “by hand” no matter which distro we are talking about.

What sense does it make to start testing unstable releases if you are not even able to perform such a basic and most importantly very well documented step?

You will have lots of additional problems not related to bugs in the unstable release, you will have the same problems as all other users with real bugs (which would be great if you are the one actually finding and report them, but most people don’t report because they don’t know how to do it), you would have a lot more work if you would start do report bugs (and consequently, most “testers” avoid that) and you will gain practically nothing.

12

this is a good discussion to have…i’ve been thinking about it for
months…the ‘catch 22’ of it all:

  1. several (me include) routinely say “when 11.x comes out you should
    wait a few months for the bugs to shake out”

  2. if everyone waits there will be NO bug shakeout…and eventually no
    release…

and i have to ask myself, why would i say that? and, the answer is
because when 9.1, and .3 came out (i skipped 9.2) they didn’t feel
like a beta (to me, as 10.1, 2, and 3 and 11.1 did)…

and, if 11.2 plops on the street as broken as .1 it will just get worse…

but, the only way to have a robust 11.2 is to have a BUNCH of bug
smashers busy in the runup to release…so, what do ‘we’ (community)
do, we have an “OPEN beta”, open to anyone with a computer…

and, what do we get? [another ‘catch 22’] a few experienced folks and
a mass of Redmond Ship Jumpers that think anytime a milestone/RC
doesn’t do as Mista does it is broke–and they file a useless ‘bug
report’ sucking developer time, and patience [because even after chmod
777 it won’t “do right”]…

ok, i’ve participated in a few betas in my day…they were closed (by
invitation and/or meeting some set criteria), had strict guidelines,
and active mail lists where tester and developer shared a usable level
of technical lingo…

and, if you didn’t test/report as wanted, you didn’t get invited to
participate again…

i was happy a few months back to see the call for testers here (and
wished i had time to participate)

btw, each beta i participated in had a reward at the end and somewhere
around here i have a ‘free’ retail copy of PKZip (for OS/2), and other
now useless stuff…

do we (the community) reward competent and productive testers with
anything? T-Shirt, mug, stickers, retail package? job title? what?

oh, if you did’t catch it: i think it is wrong to think of these
user help fora as the way out of allowing downloads of M$ like
too-buggy-to-use releases–which just serve to (in my mind) further
tarnish the brand…

ymmv!

palladium
Have a lot of fun…

13
  1. The forum is all about asking for help, otherwise what is the point of having one?
  2. It makes sense to ask other users here first in case one is simply doing something wrong - avoids wasting dev time.
  3. If nobody tests the new stuff, nothing would get done.
  4. People use the beta versions for various reasons, personally I use them to get better support for newer hardware. And seeing as suse policy is to stick with one kernel version per release, it’s really a by-product of that decision.
  5. Official bug reporting is still far too hard and complicated.

Wouldn’t it be nice to have a sexy little “report as bug” button that simply transferred you to the bug site with most of the data already filled in? No extra login names to remember, no blasted passwords etc’.

I mean, the whole point of creating this forum was to consolidate all the separate sites into one. Why not go one step further and integrate bugs as well?

“…because the devs would be bombarded with rubbish bug reports and waste time”

QED!

14

Great idea, so please delete all HowTos, remove the search function, all stickies and while you are at it, also automatically all posts older than let’s say 4 weeks, because the forum is then certainly not about finding answers which have already been given several times.

And if being told to open a bug report in most cases nothing happens. That’s what this thread is all about.

Yup, but who actually tests this stuff an reports problems? Again, see last remark.

OK, then why wasting any more time on stable releases and people actually doing some hard work on backporting drivers etc. to older versions?

Why at all offering newer kernels for distributions in unofficial repositories to give users the possibility to change drivers without having to change the whole OS?

Complete waste of time.

See above, not necessary in > 99% of all cases.

Now that’s an interesting statement.

  • Getting an account in bugzilla is the same procedure than getting one here in the forum

  • When opening a new bug, one is asked with easy to select options on what product and part of the OS (kernel, YaST, networking, etc.) one wants to file a bug

  • After that one gets automatically some search results matching the last bugs related to your choice before, so searching is done for you without you having to do anything yourself

  • On entering your description, you get an extra field with “steps to reproduce” and a field for the actual behavior and the expected one

Apart from that, entering your description of the problem is exactly the same, so I don’t see how reporting bugs is more difficult.

Yeah, why not, still this will not raise the quality of bug reports and of descriptions made in a forum, it is also not the topic of this thread.

They are not at the time, because even if somebody here is telling $USER to file a bug report, in most cases nothing happens.

Telling people to not use beta versions if they obviously don’t have the skills (and very often also not the need) to use them is mostly ignored the same way as telling them to file a bug report, that’s what this is all about.

15

Right… Recently I’ve been worried about whether the final 11.2 release will have as few bugs as possible or will be extremely buggy… Because not many people seem to want to file bug reports. Some experienced users just work around the problem themselves, not caring to report the bug, saying it’s a ‘waste of time’ and a slow and cumbersome process.

16

Going on my current use of 11.2 RC2
It’s virtually bug free.

17

Well, I could name you two annoyances you will find still present in RC2 ATM.

I know these, because I filed bugreports on them, one has already been fixed but isn’t upstream yet, the other one got no response yet.

A) If you are on x86_64 or on i686 with kernel-desktop, try to disable ipv6 via YaST, reboot and have a look at the output of ifconfig -a after that.

=> No, ipv6 is still enabled

B) Switch from NetworkManager to IFUP, configure your user to allowing him access via kinternet/cinternet and try to configure any ethernet interface (wired or wireless) via one of those frontends.

=> You can not connect to smpppd not even as root with kinternet/cinternet(/or qinternet), there are no ethernet interfaces visible.

18

caf4926 wrote:

>
> Going on my current use of 11.2 RC2
> It’s virtually bug free.
>
>

Does that mean it’s free of virtual bugs?

Graham

19

I can tell you I dropped the Desktop kernel and went default, it resolved an issue I had with powersave (bug reported BTW and I posted the resolved) Maybe worth a try for your issues?

:wink:

20

Nope, as I already reported this issue and why this behavior occurs including a workaround (on x86_64 the default kernel is affected as well).

It is not a classic “bug” but an intended change in kernel configuration, so one has to do some argumentation, why it should be considered a bug (not for the first time, the last issue I reported was reverted a few weeks later), but with this one, obviously my points were not valid enough.