-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2009-04-02 at 10:01 +0200, Michael Schroeder wrote:

On Wed, Apr 01, 2009 at 11:50:52AM -0700, PGNet wrote:

...

over on the opensuse user list, there's, imho, a refreshingly thoughtful, well-written commentary posted by Jim Henderson,

http://lists.opensuse.org/opensuse/2009-04/msg00002.html

he's done a good job of expressing thoughts & frustrations that, i'd suggest, more than a few of us (community & commercial users alike) experience in the project.

Maybe, but his post is based in the assumption that we do only security updates for 11.0. This is simply untrue, if an update

Well, he says that probably because I told him it was so (look up the thread) O:-) Has the old SUSE policy of only security patches changed, then?

goes out to 11.0 or not is decided on a case by case basis. Plus, if the same update also goes to 11.1 chances are very high that it also is released for 11.0. The work is already done anyway.

I thought that when this happened it was simply an exception because the bug was huge or caused an uproar, not a matter of policy. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknUuR0ACgkQtTMYHG2NR9WmEACgmL+Pwg9Q474Uu03q3wx6aWT2 qmMAnjN557U4R7DCEUJ4L+YH4Pox2DIy =F5eO -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Sorry if this is a dupe; posting through gmane and I haven't seen my original reply. On Thu, 02 Apr 2009 10:01:35 +0200, Michael Schroeder wrote:

Maybe, but his post is based in the assumption that we do only security updates for 11.0.

No, my post is based on my experience in trying to have issues addressed with gsynaptics and encfs prior to the release of 11.1, and the discussion that ensued around the zypper logfile creation/logrotate issue that is in discussion.

This is simply untrue, if an update goes out to 11.0 or not is decided on a case by case basis. Plus, if the same update also goes to 11.1 chances are very high that it also is released for 11.0. The work is already done anyway.

This is good to know. Most of the other things I said in my original reply here are in my other reply, so I won't repeat myself except to say that I mean no disrespect to the openSUSE team - just sharing my perceptions, which seem to be shared by others. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2009-04-02 at 12:57 +0200, Martin Schlander wrote:

Onsdag den 1. april 2009 20:50:52 skrev PGNet:

...

http://lists.opensuse.org/opensuse/2009-04/msg00002.html

...

there needs to be some middle ground found for project "support" (however that ends up being defined) other that "Go buy SLES/D ..."

openSUSE provides security fixes and fixes for major bugs for 24 months.

I understand the "question" wasn't the period, but what. Only security patches is/was the SUSE policy for many years. Has this changed, and it includes non security related bugs? What is the policy to decide which bugs are "repaired"?

I think this area - the level of support for openSUSE - is one of the areas where openSUSE is really strong, therefore demanding more seems a bit unrealistic. And developers wasting time on old stuff, takes away resources from doing useful things with current stuff.

Usually, yes, but 11.1 got out with so many flaws that an effort to "polish" the quality of a release is the proper thing to do. I'm in favor of clearing all known bugs in software before going ahead to a new version (unless agreed not to with "client"). This is not what industry does, but it is my policy. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknUt1kACgkQtTMYHG2NR9XjxACgh6RSk4uiuzxxw75mSas1KAWy nc4An29N/Qr8fThEN4E31iRcs90dMXAr =YixI -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Thu, Apr 02, 2009 at 03:02:15PM +0200, Carlos E. R. wrote:

On Thursday, 2009-04-02 at 12:57 +0200, Martin Schlander wrote:

...

Onsdag den 1. april 2009 20:50:52 skrev PGNet:

...

http://lists.opensuse.org/opensuse/2009-04/msg00002.html

...

there needs to be some middle ground found for project "support" (however that ends up being defined) other that "Go buy SLES/D ..."

openSUSE provides security fixes and fixes for major bugs for 24 months.

I understand the "question" wasn't the period, but what. Only security patches is/was the SUSE policy for many years. Has this changed, and it includes non security related bugs? What is the policy to decide which bugs are "repaired"?

Of course it includes non-security bugs. We however try to limit it to critical bugs just after release of the current product. Decision is on a case by case basis, decided by the maintenance team and the project manager.

...

I think this area - the level of support for openSUSE - is one of the areas where openSUSE is really strong, therefore demanding more seems a bit unrealistic. And developers wasting time on old stuff, takes away resources from doing useful things with current stuff.

Usually, yes, but 11.1 got out with so many flaws that an effort to "polish" the quality of a release is the proper thing to do.

That we do ... but there should not be that many flaws left.

I'm in favor of clearing all known bugs in software before going ahead to a new version (unless agreed not to with "client"). This is not what industry does, but it is my policy.

We would never get new things release in that case. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

...

...

On 4/2/2009 at 15:57, "Carlos E. R." wrote: I'm in favor of clearing all known bugs in software before going ahead to a new version (unless agreed not to with "client"). This is not what industry does, but it is my policy.

We would never get new things release in that case.

So, what? >>:-)

Clearing only bugs keeps ONLY disallows you from upgrading to a newer version of ANYTHING, as, besides new features, it most likely will bring new bugs. so if you're lucky, in 5 years we can release openSUSE 11.1 in a state with less bugs (with exactly the versions of applications that are in now). remains the question: who would possibly want to use that at that time and even more: who would be ABLE to use it (think kernel, new hardware and so on... A new version is a no/go, as the policy is bug-fixing only!) So all in all: a noble policy, but far off what reality can make use of. Dominique -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Thu, Apr 2, 2009 at 10:41 AM, Carlos E. R. wrote:

If sofware fails, you are told to wait and upgrade

which sometimes is not a problem, of course. however, what seems to missing from this discussion -- to my read, anyway -- is a recognition that: novell openly banks on the strong/tight relationship between its commercial products and this community. tbh, that's a good relationship. we (non-developer users) are asked to contribute to the project, AND to file bugs @novell. so, when something is important to us (often standing in the way our business requirements) -- we do. sometimes by feature request, sometimes by filing a bug, sometimes by spending lots of times helping trace the bug, etc. contributors of all shapes-n-sizes -- developers AND users -- contribute "for free" to this project. but, tbh, many of those contributions _do_ make their way back into commercial project. if the ultimate response to such efforts -- not just ours, but the developers' as well -- is "wait and upgrade", or worse, "Go buy SLES", why again should we contribute as asked ? all that's being requested is additional consideration for the value of those backports etc. to the users that spend the time to report the problems and work, as best as they are able, with the development teams of both the project and the commercial side to help solve them. to repeat, more often than not "it works" just fine. but as you're hearing from users, sometimes it doesn't. and we're asking to at least better understand, and perhaps, hopefully, help to improve. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Thu, Apr 2, 2009 at 11:15 AM, Jim Henderson wrote:

This comment is interesting to me as well, not directly related but indirectly so

again, well-spoken.

Not all of our users have a background in information technology, so it's not always obvious what information needs to be provided.

it's not just an issue of "not having a background in IT" ... it's often an issue of not having a deep-background in _this_ IT. e.g., we work with our own & our clients' "developers" a-plenty ... they just happen to be focussed on business & scientific apps development (and, frankly numerous OTHER environments, other than *SUSE). expecting us to be immediately facile in e.g., "openSUSE kernel-speak", and as well versed as, e.g., jbeulich, theo (mentioned here only because they have been _incredibly_ helpful), and scads of others is unreasonable. and, yes, i'm _very_ aware that -- in my own specific case -- my non-fluency in "their" forte is frustrating -- all around, trust me. hm. correction. unreasonable ONLY if we've been told that that level of expertise is a _prerequisite_ for filing the bug in the first place. and, of course, it's not ... yes, users have $$$ resources. and we spend them in numerous ways that _do_ contribute to both project & commercial product "health". if the message needs to be "develop you own expertise", that's ok -- as long as it's, imho, clearly stated. as a user, it's -- in all fairness -- more important for me to understand well how the project works, than to bank on false expectations. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Jim Henderson wrote:

On Thu, 02 Apr 2009 10:57:08 -0700, PGNet wrote:

...

we (non-developer users) are asked to contribute to the project, AND to file bugs @novell. so, when something is important to us (often standing in the way our business requirements) -- we do. sometimes by feature request, sometimes by filing a bug, sometimes by spending lots of times helping trace the bug, etc.

Not all of our users have a background in information technology, so it's not always obvious what information needs to be provided. To a developer or someone with an IT background, saying "get a stack trace" means something. To a normal user, you might as well be asking them for directions to the Martian highlands - they don't know what a "stack trace" is or how to get one.

And here you have perfectly described the misunderstanding that happens constantly on a public bug reporting tool. User: I want to do A and then B happens. I try to understand why B happens and it turns out that it shouldn't. So i tell the developer that and he will solve my problem. Developer: I write A and then release it. A has 63 problems because there is no bugfree software. Now a user comes with the 64th problem and does not even provide a backtrace. Why did he not send a patch? As you can see those are two valid views on the same situation. The solution to this is that both try to get closer to the others side. So bugzilla is not a user support tool nor is it a patch submit tool. And complaining about the one or the other is completely unrealistic. Henne -- http://opensuse.org -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Thu, 02 Apr 2009 12:23:12 -0700, PGNet wrote:

exactly that issue happened to me just in the last days ... file a bug. be told it's not a bug, take it to the lists. took it to the list -- with subsequent, _additional_ info. the developer followed to the list, took the time to clarify that -- with the additional info -- it actually _is_ a bug, and now the developer's helping directly again @ bugzilla.

that's *tremendously* helpful. and, i learned some things that'll ensure greater efficientcy, at least on my part, in the future.

that process does NOT happen all the time. and, it would have simply languished if the developer had left it at "WONTFIX" ...

Very good summary. And I think this is the situation with some of the users who have complained over on OSF about bugs being closed "WONTFIX" or "WORKSFORME" with no explanation or attempt on the developer's part to gather more information. I guess the bottom line is that it comes down to education of users of Bugzilla about how to get things addressed as well as setting an appropriate level of expectation explicitly rather than letting an implicit expectation level be set through the users' experience. Or put another way, some PR work. :-) Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Thu, Apr 2, 2009 at 12:45 PM, Henne Vogelsang wrote:

These are situations that are unfortunate ... but that frequently happen.

agreed

cant be changed

don't agree. the beginnings of that change start with mind-numbingly drawn-out threads like this ;-)

Complaining might be a bit too harsh sorry :) What i meant was that each and every on of us has to accept that this process will go wrong in some cases.

good. just making sure. as timely. relevant coincidence, readers here may find this of some interest &/or food for thought, http://www.pcworld.com/businesscenter/article/162457/linux_needs_critics.htm... " ... It also categorizes my comments as "complaints" when they're actually criticism--offered in good faith with the hope of making things better. There is a very important difference between a complaint (negative) and criticism (positive). ... " which, as usual, the well-known author states more clearly & eloquently that might i ... -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Thursday 02 April 2009 03:14:53 pm Henne Vogelsang wrote: ...

...

http://www.pcworld.com/businesscenter/article/162457/linux_needs_critics. html

Sorry. To my defense: I'm no native speaker and complaining has not a negative touch in my native tongue (german).

I'm not too, but I have feeling that either word can have positive or negative connotations depending on context. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Il giorno gio, 02/04/2009 alle 15.33 -0500, Rajko M. ha scritto:

On Thursday 02 April 2009 03:14:53 pm Henne Vogelsang wrote: ...

...

...

http://www.pcworld.com/businesscenter/article/162457/linux_needs_critics. html

Sorry. To my defense: I'm no native speaker and complaining has not a negative touch in my native tongue (german).

I'm not too, but I have feeling that either word can have positive or negative connotations depending on context.

Right, but "not reading between the lines" is a requirement is a multi-cultural environment, and it is always a good habit IMHO. It becomes even more important on a mailing list, where for the nature of the medium we don't see each other. Regards, A. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Thu, 02 Apr 2009 20:45:09 -0500, Rajko M. wrote:

The only thing that should not happen is to rush with retaliation if something appear as insult.

In my opinion/experience, it's generally best to start with the assumption that what's been said is *not* intended as an insult unless it's really, *really* clear that it's meant to be. In otherwords, apply the "tact filter" inbound rather than assuming the tact filter was applied outbound on the sender's side. If it turns out that it was applied on both ends of the conversation, that's great, but it's usually safer to assume in questionable situations that it was applied than it wasn't - that can lead to less misunderstandings (and flamewars). Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Thu, 02 Apr 2009 21:10:55 +0200, Henne Vogelsang wrote:

...

Not all of our users have a background in information technology, so it's not always obvious what information needs to be provided. To a developer or someone with an IT background, saying "get a stack trace" means something. To a normal user, you might as well be asking them for directions to the Martian highlands - they don't know what a "stack trace" is or how to get one.

And here you have perfectly described the misunderstanding that happens constantly on a public bug reporting tool.

User: I want to do A and then B happens. I try to understand why B happens and it turns out that it shouldn't. So i tell the developer that and he will solve my problem.

Developer: I write A and then release it. A has 63 problems because there is no bugfree software. Now a user comes with the 64th problem and does not even provide a backtrace. Why did he not send a patch?

As you can see those are two valid views on the same situation. The solution to this is that both try to get closer to the others side.

Agreed, and very well stated, Henne. At the same time, though, the user situation is a more common use case for bugzilla - user reports a bug, and the developer asks for additional information to track it down. That's even how bugzilla.novell.com is used for Novell's products other than openSUSE. (I may not have mentioned here, I am a Novell employee - I work in the training organisation, not with the Linux products specifically).

So bugzilla is not a user support tool nor is it a patch submit tool. And complaining about the one or the other is completely unrealistic.

Well, I'd say Bugzilla is a user support tool in as much as it is a place where program defects are submitted and tracked through to resolution. Since users use the software that bugzilla tracks bugs in, the case can be made that it is a user support tool - but I think we agree that the more usual way it should be used is that "I have a problem" is discussed on a mailing list or forum before a bug is submitted; the user searches before submitting a bug to make sure it's not already in the system as well. But if I, as a user, report a bug and haven't provided complete information, the course of action from a developer standpoint isn't "WORKSFORME" but to request more information. Unless it is a configuration or user education issue and not really a bug. Put another way, there's a fine line between using Bugzilla inappropriately as a discussion medium (a replacement for a mailing list or forum) and using it as a means to gather information about a true defect. That becomes a user education issue (not openSUSE user, but bugzilla user - covering both openSUSE users and developers). Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Thu, Apr 2, 2009 at 1:02 PM, Henne Vogelsang wrote:

And user education is not always the highest priority a developer has. This is what i think sometimes is not understood. That a simple WONTFIX or WORKSFORME without any further comment means exactly this: I wont fix it and unfortunately i don't have any time to explain why.

This is a sad story, but a true one.

sure. understood. some developers agree with your approach; others choose a different one. that is exactly why -- writing "just" as a user that contributes to this project as well, and doesn't have time to waste either -- this discussion is happening on the _project_ list, about _project_ issues, and how users can both contribute and receive contributions. i think & hope the process can be improved. as is often said "can't fix what you don't know about". consider your stated position/example above ... acknowledging for the sake of discussion that noone should, or liekly can, change your mind, any suggestions as to what a user should do in that case? how is the user supposed to make further progress -- _either_ on that particular bug, or with their overall goal os continuing to benefit from & contribute to the project? -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Thu, 02 Apr 2009 22:51:39 +0200, Henne Vogelsang wrote:

If a developer does that to me i ask why in the bug. I don't reopen it and try to explain why this specific bug is so important or anything i simply ask why he closed it in this fashion. Most times you will get an honest answer.

From a time perspective, if users are going to ask "why did you close

See, though, you're a geek like I am (and like the developer probably is) - you have an inverted "tact" filter. :-) Think of a tact filter as being like a firewall. Geeks filter inbound. Normal people filter outbound (they say "gee, should I say that or not" to themselves before they say something - in normal circumstances). The problem is often that Normals (and Geeks in some cases) assume everyone filters the same way they themselves do. It's generally human nature to assume (not consciously) that the reason others do things a certain way is because it's the way they would. Everyone only has their own experience as a frame of reference unless they consciously make an effort to put themselves in the other's shoes. What we're looking at here, I think, is (in some cases) those who filter inbound and those who filter outbound. this", it's less efficient to close without comment because then the developer has to close the bug again and explain why they closed it after being asked. It is more efficient to put the onus on the person who filed the bug to provide more information or to answer and close at the same time if that's the right thing to do.

From a community and overall project perspective, it would also seem to me to be more efficient to comment+close or ask for more information because that encourages the behaviour of users reporting bugs so the distro can be improved.

Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Thu, Apr 2, 2009 at 1:51 PM, Henne Vogelsang wrote:

If a developer does that to me i ask why in the bug. I don't reopen it and try to explain why this specific bug is so important or anything i simply ask why he closed it in this fashion. Most times you will get an honest answer.

to be fair, i've done exactly that ... and, on occasssion, received a straightforward answer. even had the developer re-open the bug a couple of times themselves. ;-) might be a bit easier on everyone if Jim's suggestion were taken up -- i.e., the default didn't unceremoniusly, with no comment, close the bug as a 1st step. _that_ sometimes leaves the user wondering: (1) do i reopen the bug just to comment further? (2) do i simply post additional comments to the closed bug? is anyone still paying attention to it? (3) do i email the developer directly? i can personally state that it's sometimes confusing, and sometimes choosing one gets ... er ... let's say less than "optimal" response.

In general i try to be as trusting as i can be and talk to people :)

good policy, i believe. one that works only if practiced by all parties concerned ... just an observation -- even in this thread, _inviting_ the discussion, it really does tend to sound like "users vs developers", doesn't it. certainly not a "one project for all" vibe ... -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Thu, 2009-04-02 at 20:39 +0000, Jim Henderson wrote:

Another option (something that I see in a few communities) is the ability to vote on bugs - let the community decide what's important for them. Maybe that would work here - though I imagine with the sheer size of a full distro, there'd likely be many bugs with 0 or 1 votes and not many with more than 10 - but it's a mechanism to get feedback from the community about what's important to them.

Bugzilla for openSUSE/Novell does have voting. It's kinda hidden, though. -- Kevin "Yeaux" Dupuy openSUSE Member www.twitter.com/KevinDupuy -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Thursday 02 April 2009 09:36:23 pm Jim Henderson wrote:

On Thu, 02 Apr 2009 20:57:44 -0500, Kevin \"Yeaux\" Dupuy wrote:

...

On Thu, 2009-04-02 at 20:39 +0000, Jim Henderson wrote:

...

Another option (something that I see in a few communities) is the ability to vote on bugs - let the community decide what's important for them. Maybe that would work here - though I imagine with the sheer size of a full distro, there'd likely be many bugs with 0 or 1 votes and not many with more than 10 - but it's a mechanism to get feedback from the community about what's important to them.

Bugzilla for openSUSE/Novell does have voting. It's kinda hidden, though.

That's good to know, at the same time, maybe that's a mechanism that should be promoted more and used/leveraged.

Jim, problem with bugzilla is, by now, somewhat archaic user interface, but even when it was designed it had not in mind absolutely clueless users as reporters. There must be better method. Some combination of bugzillas with highly skilled developers and lesser skilled volunteer helpers in forums and ML as liaisons. This would require education of people that tend to learn, developers and intermediate skilled volunteers. Developers should learn that this venue to collect bugs is open, and volunteers would do the same thing they already do, but instead to give advice to everyone to report a bug, they would offer help. Two more things will have to change, developers should be very responsive on initial bug report, and bugs reported by volunteers would be their responsibility to follow, but if original reporter never comes back, no one will blame volunteer. This looks good on the screen. What do you think? -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2009-04-02 at 21:10 +0200, Henne Vogelsang wrote:

And here you have perfectly described the misunderstanding that happens constantly on a public bug reporting tool.

User: I want to do A and then B happens. I try to understand why B happens and it turns out that it shouldn't. So i tell the developer that and he will solve my problem.

Developer: I write A and then release it. A has 63 problems because there is no bugfree software. Now a user comes with the 64th problem and does not even provide a backtrace. Why did he not send a patch?

As you can see those are two valid views on the same situation. The solution to this is that both try to get closer to the others side.

There is a third situation: the user supplies the required info, there are precise logs, kernel OOps, etc, but the bug is not solved and remains open for years (literally). I can tell you that it is quite frustrating. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknVTXwACgkQtTMYHG2NR9XbmgCbBH014BIFeyhGoMmvJaex8rOF DKAAn1C7rqfOo5fzd4a5sAs+IOZAMPjG =MLot -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2009-04-03 at 14:26 +0200, Vladimir Nadvornik wrote:

On pá 3. dubna 2009, Carlos E. R. wrote:

...

There is a third situation: the user supplies the required info, there are precise logs, kernel OOps, etc, but the bug is not solved and remains open for years (literally). I can tell you that it is quite frustrating.

Yes, indeed, this is a third situation:

Packager - didn't write the code himself and does not know about potential problems. - can fix bugs that he is able to reproduce - debugging bugs that he is not able to reproduce is very time consuming - it basically means guessing potential problems and navigating the user through testing them. The logs, etc. are often not sufficient. - there are tasks with higher priority

IMHO bugs in this situation should be moved upstream and the original reporter is probably in a better position to do so because he can at least reproduce the problem.

I have bugs frozen for months, some even years, after I did all the requested tests and supplied all the info I was asked for. After that, not a single comment. Even for years! A new suse version is released, I retest, I comment that the bug is not solved, no answer. It is discouraging. And about moving upstream... sometimes the bug is caused by a suse patch. I can not decide to go upstream unless told to, and then, reporting upstream for somebody that is not accustomed to the ways and people upstream... is not very productive. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknWBbAACgkQtTMYHG2NR9XaXACfToUfqd4/o34E+k85Ug96dHBe /bgAn3FQ2UwKN0rdHEqRl6H+4brMiqwI =hpQY -----END PGP SIGNATURE-----

Rajko M. a écrit :

In other words, we need volunteers like you (and many others including me),

could we have "members" given a better priority on bugzilla? Members may have more interest/responsiveness for non members it's often better to ask first on the mailing list to get help jdd -- http://www.dodin.net http://valerie.dodin.org http://www.youtube.com/watch?v=t-eic8MSSfM http://www.facebook.com/profile.php?id=1412160445 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On pá 3. dubna 2009, Carlos E. R. wrote:

On Friday, 2009-04-03 at 14:26 +0200, Vladimir Nadvornik wrote:

...

On pá 3. dubna 2009, Carlos E. R. wrote:

...

There is a third situation: the user supplies the required info, there are precise logs, kernel OOps, etc, but the bug is not solved and remains open for years (literally). I can tell you that it is quite frustrating.

Yes, indeed, this is a third situation:

Packager - didn't write the code himself and does not know about potential problems. - can fix bugs that he is able to reproduce - debugging bugs that he is not able to reproduce is very time consuming - it basically means guessing potential problems and navigating the user through testing them. The logs, etc. are often not sufficient. - there are tasks with higher priority

IMHO bugs in this situation should be moved upstream and the original reporter is probably in a better position to do so because he can at least reproduce the problem.

I have bugs frozen for months, some even years, after I did all the requested tests and supplied all the info I was asked for. After that, not a single comment. Even for years!

A new suse version is released, I retest, I comment that the bug is not solved, no answer. It is discouraging.

This should not happen with bugs where the cause is known. For bugs that needs some (unknown) time for debugging, there are these 3 options: 1. Novell packager will find the time for debugging after the higher priority tasks are done - this can take very long. 2. Novell packager closes the bug with WORKSFORME 3. Somebody outside Novell helps with debugging

And about moving upstream... sometimes the bug is caused by a suse patch.

Even such bugs can be interesting for upstream - for example they indicate that the logging is insufficient. At worst, the upstream bug will be rejected.

I can not decide to go upstream unless told to, and then, reporting upstream for somebody that is not accustomed to the ways and people upstream... is not very productive.

I think that if you say in bugzilla tat you are willing to handle the bug with upstream, the Novell developers will provide you some advices how to do it, if they knows. It is in their interest. And it is definitely more productive than just waiting. Vladimir -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2009-04-03 at 16:54 +0200, Vladimir Nadvornik wrote: ...

I think that if you say in bugzilla tat you are willing to handle the bug with upstream, the Novell developers will provide you some advices how to do it, if they knows. It is in their interest.

And it is definitely more productive than just waiting.

Provided that taking upstream is the appropriate action. The user does not know if the bug is caused by a suse addition, in which case it causes time lost for both the reported and the upstream folk. Also consider that the user is not known upstream. He may know nothing about that particular upstream project. The people upstream may all be devs and be unprepared to listen to a user, which is not using the last upstream version: they would ask the user to try the cvs version, which is not a simple task - plus, that version would not have suse patches, which can be determinant. Telling a user to report upstream should be the last resort. It is certainly daunting for me! I think it is more appropriate for the maintainer to report upstream with CC to the user to add additional data the people upstream may require, because the maintainer should be accustomed to the requirements upstream and knows what they want or like. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknWMaQACgkQtTMYHG2NR9Uc4wCdEITDeRsqpKISb9XdsxfW+CCm rzsAnRzKRVI3yxuE5/tGIwwqZ0lHN+kg =K6h0 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2009-04-03 at 09:32 -0400, Cristian Rodríguez wrote:

Carlos E. R. escribió:

...

There is a third situation: the user supplies the required info, there are precise logs, kernel OOps, etc, but the bug is not solved and remains open for years (literally). I can tell you that it is quite frustrating.

Maybe because there are gazillions of other. more important, priority problems to fix ?

Even filesystem crash or data loss? Isn't that worth a comment in many months? - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknWMhIACgkQtTMYHG2NR9Xj6QCffFuj0g9I7lwX6Ki6kJOTFT02 slwAnjGGNlaQ3RZNv25l0KXz8EfJVsPB =KJQP -----END PGP SIGNATURE-----

On Friday 03 April 2009 11:27:51 am PGNet wrote:

isn't one of the points arising in this thread the issue that if there ARE judged to be "gazillions of other. more important, priority problems to fix" that at the very least it might be nice for a user to know, via a comment in said submitted bug, that that determination has been made?  ideally, perhaps even including the user in that determination discussion?

You can imagine how hot is on a developers side of the wire. To give comments takes time from priorities and I'm sure that guys paid for coding are hard pressured to solve priorities, ie. Novell's customers problems, in a timely manner. That is what bring lunch on a table and roof over the head. When that is done they can go and solve all other issues. It is just the fact that proprietary only companies have no opensource related need for man*hours and they compete in the same market place. That creates pressure on those that have opensource component and it will not change until it is established some kind of social responsibility trough obligation to provide certain amount of man*hours for public service, like broadcasting companies already have. That solution is not very likely to happen any soon, as unlike broadcast companies that can't broadcast somewhere else in the world, software can be developed anywhere, and adding rules will push business out of regulated zone. The only solution right now is to have more people from community involved in such activity as friendly bug handling. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Rajko M. a écrit :

It is just the fact that proprietary only companies have no opensource related need for man*hours and they compete in the same market place.

not really. open source gives also advantages: the competitors have much more bugs than opensource aps - and I don't speak only of Msoft, ost proprietary apps I have to use are horribly buggy, even if expensives. but it's very difficult to balance between debugging time and coding time and this is mostly users fault: users asks for new features, not debugged apps, id not windows should have died long ago jdd -- http://www.dodin.net http://valerie.dodin.org http://www.youtube.com/watch?v=t-eic8MSSfM http://www.facebook.com/profile.php?id=1412160445 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2009-04-03 at 09:27 -0700, PGNet wrote:

On Fri, Apr 3, 2009 at 8:58 AM, Carlos E. R. <> wrote:

...

Telling a user to report upstream should be the last resort. It is certainly daunting for me!

...

I think it is more appropriate for the maintainer to report upstream with CC to the user to add additional data the people upstream may require, because the maintainer should be accustomed to the requirements upstream and knows what they want or like.

agreed.

the vast majority of times (there's been exceptions, to be sure) i've tried communications @ upstream, i've been _completely_ ignored. not a comment. occassionally i get a "screamer" @ upstream IRC, to add to the overall fun ...

Me too. I reported once upstream. I had bought a Haupage TV card; it did not work. I was told to ask on their mail list, which was their channel (that's a problem, each different project has their own peculiar method of reporting). I was totally ignored. In the end, I had to ditch that TV card, and buy a real TV instead. I had to spend money on other hardware, that is, to solve a software problem... So I don't like reporting upstream. I hate it, in fact. Useless waste of time and money. One's experience can spoil the fun, I'm afraid. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknWWCMACgkQtTMYHG2NR9WKKQCdFr7L+PBCgHu0v5q7v+Z98zIt Dv4An0fyb4O9OA8o4sA08Wk382qm9FQ2 =IWIR -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2009-04-02 at 20:54 -0500, Kevin "Yeaux" Dupuy wrote:

On Thu, 2009-04-02 at 19:41 +0200, Carlos E. R. wrote:

...

I don't understand that answer. Why would solving bugs bring new bugs?

I'm not a developer, but being involved with openSUSE development, I've learned that bugs are tricky little gubbers. Any time you start editing, deleting, or adding code, a bug can pop up. (Obviously, an actual developer will give a more knowledgeable explanation ;-) )

Obviously. It is normally understood that adding so many lines of code adds about a fixed percent of new bugs. But usually, the task of clearing bugs does not add new bugs. Shouldn't, that is, the percent is much smaller.

...

which is unfortunate. If a bridge falls down after comission, someone goes to jail. If sofware fails, you are told to wait and upgrade. It is just some insect in some relais.

A bridge is a life and death situation. Your computer isn't. There is special software for technologies in the areas of life and death situations, such as hospitals. With all due respect, I don't want openSUSE running my pacemaker, or Vista or Leopard either. For obvious reasons.

My metaphor is a well known exaggeration, of the known point that the software profession takes little responsibility of the quality of the code they produce - and I'm part of that "they". You can change the metaphor to a car not starting or something of the sort. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEUEARECAAYFAknVd7UACgkQtTMYHG2NR9VfmQCWJar4Tqr/GHk3ZvEduOvD2Y0l sACeO8CjcrZz0m+CMpCmDP60cSiDDCY= =Ac6d -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

On Thu, 02 Apr 2009 12:57:40 +0200, Martin Schlander wrote:

Onsdag den 1. april 2009 20:50:52 skrev PGNet:

...

http://lists.opensuse.org/opensuse/2009-04/msg00002.html

...

there needs to be some middle ground found for project "support" (however that ends up being defined) other that "Go buy SLES/D ..."

openSUSE provides security fixes and fixes for major bugs for 24 months.

That's better than Fedora (~12 months), Mandriva (~12 months) _and_ Ubuntu (18 months, non-lts).

Even for Debian it's only 30 months (assuming the 18 month release cycle is followed successfully, which it of course never is.). And for Ubuntu LTS it's only on 36 months on desktops.

I think you miss my point here, Martin. It's not about the stated support timeframe. It's about the perception - a perception backed by my own experiences in trying to get issues affecting my systems fixed.

I think this area - the level of support for openSUSE - is one of the areas where openSUSE is really strong, therefore demanding more seems a bit unrealistic. And developers wasting time on old stuff, takes away resources from doing useful things with current stuff.

"Demanding" is a little strong. I was commenting on the *perception* that it seems to take a bit of pressure to get patches backported. Take the encfs/boost example. That issue was discovered and reported when 11.0 wasn't "old stuff" - 11.1 was still in development. The gsynaptics bug I also comment on was discovered pre-11.1 (and come to think, I don't know that the fixes from 11.1 did get backported, as my touchpad on my D620 still doesn't work right because I can't disable circular scrolling). Even when reported, the fix was "upgrade to 11.1 pre-release because the fix is committed there and won't be in 11.0". I do not mean *any* disrespect to the team at all. Please understand that - I am generally VERY happy with openSUSE. But it seems that too often, I see suggestions in various venues (such as OSF and the users mailing list) to upgrade the OS (a major undertaking - and I run 11.0 currently on 6 different systems here at home), and then the response to "well, I'm not ready to do that" is "if you want professional support, move to SLE". I'm not asking for professional support; quite frankly, I prefer the community support model - having participated as a recipient, a provider, and a leader (in the Novell forums) - to be generally higher quality than paid professional support. As I said in the users list, I'm a user and thus part of this community. I can't contribute code because I don't trust myself to write good enough code (nor, maybe more importantly, do I have the time), but I can contribute in other ways by helping test and reporting when I see what I think is a problem, either with processes or with the software itself. There is always room for improvement in processes. But if nobody is willing to say "hey, this could be better", then we don't get the perspectives needed to find out how things could be improved. I want openSUSE to continue to be the best distribution out there (and I *do* think it's the best one I've worked with). Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org