Rajko wrote:

On Tue, 07 Aug 2012 12:45:41 -0700 It is about 3-4 openSUSE users that I know about and it is for period of last few years, which is insignificant, if one would not know: http://www.useit.com/alertbox/participation_inequality.html

Due to this issue alone, openSUSE lost quite some number of reports, and most likely users.

OpenSuse Doesn't want those reports. If they can't even follow the corporate line in regards to creating a login, then how are they going to follow open-suse mindthink that further narrows the fields of what is even ***ALLOWED*** to be reported as a bug without being abused? See https://bugzilla.novell.com/show_bug.cgi?id=771516 For a great example of something that used to work, but no longer does -- except under some ideal suse-build environment. It's a real bug report for something that used to work -- bug it now broken, yet the pressure (as documented in the report) has been to tell the user that it is their problem and that their valid, current, suse install the problem -- and is unsupported for a build environment. I had to fight just to have the bug closed as "WONTFIX" -- the developers wanted to close it as INVALID because their build works under their idealized build & test conditions. It used to be products were build to run on released products -- not just factory-only sterile conditions, but this was before openSUSE's Tivoization efforts to turn openSUSE into a platform for platform for developing end-user appliances. It's a retreat from the general linux-distro model of 1 source working anywhere (including other OS's) to an opposite and antithetical extreme of it working on virtually no end-user's real "in-use", production system (clean room build and test only!). This was most of my latest reply on that bug -- as it well details they problem(s) in the in the attitude shift that's caused the problem. The fact that most users are ok with this this (as indicated by the responder's last comment "this is how the community feels about your bug reports)" is a very strong reason why most users wouldn't be comfortable submitting feedback or bugreports. ----------------------- (In reply to comment #11)

If it is faulty please provide a patch to enhance the working version. ==== The purpose of a bug-tracking mechanism is not to force nor beat users into submission for having submitted a bug. It's not to prove the superiority of your build process over theirs. It's not to prove to them that your idealized value of how to run the program works and whatever they are doing is wrong.

The point is to get feed back about something that broke for the user -- specifically something that *USED* to work (building samba from RPM) for them. This is a regression. It used to be those were treated as P1/S1 bugs. Now the user is abused for not having an approved setup and the user has to try to explain why they bug report isn't invalid.

It's your build which fails and I don't have the time nor do I see the value to the project to debug your failing build.

At one point in time people cared about the projects and products they shipped on to build in as many configurations (to the point that they build on DIFFERENT OS's). You only care that your build works on some idealized config -- which is very different from the attitude of how open source development used to be done.

It is faulty for your requirements but not for the requirements we have as an Open Source Software project.

The Samba project builds on multiple architectures with no were near the restrictions of the open suse project. Opensuse's version of rpm build is faulty because it doesn't build -- NOT just in all the places that samba builds, but because it doesn't even build on "generic" (not specially tuned) machines as does the original script. Why? because you remove various pieces from samba necessary for it to build all of itself. I cannot submit a patch -- because it would be rejected. I have been that route before -- It's not because I can't submit a patch -- it's because suse only wants certain things two work. If you want to swear that you will accept my patch, I can create one -- but I would bet I'll hear that "users don't want all that other stuff on their machines (ldb, tdb, docs...etc)... You are creating 'use-only' machines by design (that don't easily support modification or developers). I can't create a patch for that as it's a high level decision made about products more than just samba. It's what stallman calls the 'Tivo-ization' of the product.

I don't care if the bug state stays at wontfix. It demonstrates very well your unwilling habit to learn and cooperate.

---- Only if I'd never submitted patches that had been rejected would that be true. But having done so, because it's not the direction open suse has decided to take, the bug staying at won't fix is documentation of configurations that suse doesn't support. It isn't a reflection of your development abilities. It documentation of an area that Suse no longer supports. This information is vital if open suse is ever to figure out how their decisions affect those who try to use all of suse as a development platform and the effects of their Tivoization program in moving openSuse to be an appliance development platform rather than a linux development platform.

See also comment #1 to get a picture what our community thinks.

It shows me very well the picture of a user that says "I got mine", and the fact that your build, which used to work, no longer works is your problem, and unless you apologize for wasting our time for having even submitted a case were something doesn't work, we are gonna ignore you for having a system we no longer support. Do you really think their weight counts any more than me than that of a petulant 5-year old? This note is a perfect example of why it's pointless to worry about people registering for bugs -- when they will get this type of response to reporting them. It's called "hypocrisy". -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org