[opensuse-project] users' perspectives on openSUSE support, backports, our contributions, etc (fwd from user-list)
hi, 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. for starters, i'll let his comments @ that thread speak for themselves ... and hope to see some good discussion here. for my part, i'll say this -- *suse (that's SLES, SLED and openSUSE) are our distributions of choice. the community and support are, in general, the best of the bunch. tbh, there _is_ some concern on my part in posting this that simply raising the flag will engender some less-than-happy retorts -- but, my hope is that I'm wrong and Jim's right and that there is a recognition that "mortal users" do contribute value, that those contributions have value to BOTH opensuse and the commercial products, and that there needs to be some middle ground found for project "support" (however that ends up being defined) other that "Go buy SLES/D ..." thanks. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
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 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. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- 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 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Carlos E. R. wrote:
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.
Not even that :O) The thread was simply a misunderstanding (and a huge follow-up on it) caused by similar summaries of two bugs talking about growing log files. The bugs were otherwise unrelated, though [1]. Nice example of how easily can misinformation spread :O) Beware people! This can (and does) happen every day. :O)))) All it takes is someone omitting one thing or the other, misphrasing something, following up on false info, or even with strong emotions. This can happen even unintentionally, so i don't blame anyone, i just ask you to be careful. [1] http://lists.opensuse.org/opensuse/2009-04/msg00421.html - -- cheers, jano Ján Kupec YaST team - ---------------------------------------------------------(PGP)--- Key ID: 637EE901 Fingerprint: 93B9 C79B 2D20 51C3 800B E09B 8048 46A6 637E E901 - ---------------------------------------------------------(IRC)--- Server: irc.freenode.net Nick: jniq Channels: #zypp #yast #suse #susecz - ---------------------------------------------------------(EOF)--- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAknZ+4YACgkQgEhGpmN+6QEpRgCfVC3+zvRP3Crp9nQUIp4IGPcc q4IAniylm3lnSHJ5r+RNBrBGP7GMm1dw =Qo25 -----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
Onsdag den 1. april 2009 20:50:52 skrev PGNet:
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 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. -- 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:
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:
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?
It never was true. Just look at the 11.0 updates: 8 CATEGORY: update stack 2 CATEGORY: optional 113 CATEGORY: recommended 234 CATEGORY: security It's true that the majority of updates are security updates, but more than 30% are bugfixes.
What is the policy to decide which bugs are "repaired"?
It's decided by the maintenance team an a case by case basis. It depends on the severity of the bug, how complex the fix is, if it would be extra work to create a fix for an old distributions and other things. It also depends on when the last update was released, people would complain if we release a kernel update every week. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- 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:
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2009-04-02 at 15:13 +0200, Marcus Meissner 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? >>:-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknUxE8ACgkQtTMYHG2NR9WBeACfRYwKpfDaN60DZ4Iw0SeJY6VS y2IAniDD0RXK6cEC3Txi4mbhPTpuLGxa =Cy6m -----END PGP SIGNATURE----- -- 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." <carlos.e.r@opensuse.org> 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2009-04-02 at 18:06 +0200, Dominique Leuenberger wrote:
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.
I don't understand that answer. Why would solving bugs 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).
Why 5 years? Why not 4 months? >:-)
So all in all: a noble policy, but far off what reality can make use of.
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. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknU+MoACgkQtTMYHG2NR9XmHwCeIH/8B+1dAEHOldJUo8ymWUrg l2UAn2bRfZfyYNiAua9I72nXt8ocpUFl =i8Ng -----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 2, 2009 at 10:41 AM, Carlos E. R. <carlos.e.r@opensuse.org> 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, 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.
This comment is interesting to me as well, not directly related but indirectly so - in the openSUSE Forums (have a look in the soapbox forum for some examples), I occasionally see people complaining that they opened a bug and it is closed by a developer as "WORKSFORME", rather than the developer asking for further information so they can trace the problem down. While I haven't run into this one myself, it seems that some members of the user community are asking why they should file bugs if they just get closed without the developer asking for more information. 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. Just closing the bug - even though the user has done what is requested and filed one in the first place so as to feel that they're contributing to the continued improvement of the distribution - tells the user that submitting bugs is just a waste of their time, and they become less inclined to do so. Just an observation on my part; having a background in IT and enough coding experience to be dangerous, I usually include text in my bugs that asks for the developer to let me know if other information is needed, and try to provide as much relevant information as I can. I know what that relevant information is likely to be; my aunt who uses her machine to surf the web, listen to music, and occasionally write a letter won't have any clue. 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 11:15 AM, Jim Henderson <hendersj@gmail.com> 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
On Thu, 02 Apr 2009 11:30:38 -0700, PGNet wrote:
On Thu, Apr 2, 2009 at 11:15 AM, Jim Henderson <hendersj@gmail.com> wrote:
This comment is interesting to me as well, not directly related but indirectly so
again, well-spoken.
Thanks. :-)
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.
Well, yes and no - I think there's really three levels of expertise involved: * no background in systems at all (ie, don't know what, for example, a stack trace is, much less how to get one) * Background in IT but not this type (ie, know what a stack trace is and even maybe why it's useful but not how to get one on this platform) * Background in this type of IT (ie, know what a stack trace is, how to get one, and possibly even how to use it) IOW it's not really an "either/or" situation, but shades of grey.
if the message needs to be "develop you own expertise", that's ok -- as long as it's, imho, clearly stated.
Even then, one of the venues for developing expertise is participation in the community. That means the community needs to be welcoming of questions, too - not just in mailing lists, forums, and IRC/chat systems, but also in processes that get issues reported to developers in order to get them fixed. Not saying that the openSUSE community is actively unfriendly (quite the opposite), just a point of observation about what's needed IMHO for success. That doesn't mean there isn't room for improvement, though. 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
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, Apr 2, 2009 at 12:10 PM, Henne Vogelsang <hvogel@opensuse.org> wrote:
As you can see those are two valid views on the same situation.
fair point.
The solution to this is that both try to get closer to the others side.
that frequently happens. that also frequently _fails_ to happen. hence the discussion here.
So bugzilla is not a user support tool nor is it a patch submit tool.
perfectly reasonable position, in principle. from one user's perspective (speaking only for myself ...), having a honestly submitted bug even legitimately redirected "elsewhere" rather defeats the purpose if the issue at hand is them summarliy ignored @ "elsewhere" ... to Jim's example of WONTFIX ... a bit more explanation as to what/why, might actually be helpful to users in that specific case so that they might do a better job narrowing down the problem. 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" ...
And complaining about the one or the other is completely unrealistic.
just to be clear, i don't believe anyone has "complained" here at all. do you, perchance, read otherwise? -- 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
Hi, PGNet wrote:
On Thu, Apr 2, 2009 at 12:10 PM, Henne Vogelsang <hvogel@opensuse.org> wrote:
The solution to this is that both try to get closer to the others side.
that frequently happens. that also frequently _fails_ to happen. hence the discussion here.
Yes of course. But sometimes this is bound to happen. There are certain situations where one or the other side cant act differently. For instance Jims example of Users that simply don't have the knowledge of how to produce a bugreport that helps the developer. Or for the other side it can be the case that a developer simply has no time to explain how to do that. These are situations that are unfortunate, cant be changed but that frequently happen.
And complaining about the one or the other is completely unrealistic.
just to be clear, i don't believe anyone has "complained" here at all. do you, perchance, read otherwise?
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. 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, Apr 2, 2009 at 12:45 PM, Henne Vogelsang <hvogel@opensuse.org> 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
Hi, PGNet wrote:
On Thu, Apr 2, 2009 at 12:45 PM, Henne Vogelsang <hvogel@opensuse.org> wrote:
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...
Sorry. To my defense: I'm no native speaker and complaining has not a negative touch in my native tongue (german). Henne -- http:/opensuse.org -- 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
On Thu, 02 Apr 2009 15:33:55 -0500, Rajko M. wrote:
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.
That's good to know - in English, "Criticize" is the word that we'd typically use, though even that word carries a somewhat negative connotation. Critique might be a more neutral word. My point in posting what I did over to the users list was not to complain (negatively) or to really even criticize, but rather to just say "hey, I think there's an issue here and here's how I see it". I think it's important to provide feedback on things that may be issues. 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
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 Thursday 02 April 2009 07:18:37 pm Alberto Passalacqua wrote:
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_crit ics. 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.
If reading between lines means the same as in my native language (the one of those spoken across Adriatic see) ie. guessing what the other side wanted to say, it is just opposite in multicultural environment where many people use English as a common ground and as a second language. We have to guess a lot and guess good. The only thing that should not happen is to rush with retaliation if something appear as insult. People should not forget the fact that different cultures can have different interpretation for the same symbol, sometimes they are very opposite. Symbol, applied to our circumstances, can be word, phrase, graphic, signature. The danger for misinterpretation is not only between very different cultures, it hurts probably more where differences are subtile, and not very often. While in my language "vrijedan" is diligent, or precious, in Russian "вредний" it is exactly the opposite. When pronounced they sound similar like many other words. In some places people create "o" with fingers to say delicious, in other to say OK, and some do that to tell "zero value". Applied to people and actions it goes from approval to insult. It would be actually good to collect links about customs in other lands, post to wiki and link from Netiquette. -- Regards, Rajko -- 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 Thursday 02 April 2009 09:39:01 pm Jim Henderson 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.
That is exactly what I meant. Take a time and make effort to clarify. Though, like usually in life, one has to know that language is not perfect, before he/she can assume that it may exist communication problem. http://www.cs.tut.fi/~jkorpela/wiio.html -- Regards, Rajko -- 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
Hi, Jim Henderson wrote:
On Thu, 02 Apr 2009 21:10:55 +0200, Henne Vogelsang wrote:
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.
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).
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. 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, Apr 2, 2009 at 1:02 PM, Henne Vogelsang <hvogel@opensuse.org> 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
Hi, PGNet wrote:
On Thu, Apr 2, 2009 at 1:02 PM, Henne Vogelsang <hvogel@opensuse.org> 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.
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?
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. If a developer does that to me frequently i will try to talk to him in a more private fashion (mail, irc whatever) why this is always the case with my bugs. Most times i get an honest answer. In general i try to be as trusting as i can be and talk to people :) 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 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.
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.
From a time perspective, if users are going to ask "why did you close 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:59 PM, Jim Henderson <hendersj@gmail.com> wrote: ...
The problem is often that Normals (and Geeks in some cases)
LOL!! ahhh ... the required, tension-relieving levity. must be 5pm EastCoast time!
assume everyone filters the same way they themselves do.
which is why I stick "my Geeks" in locked offices, and slide pizzas under the door. (just kidding ... !!) p.s. good points, though. -- 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 <hvogel@opensuse.org> 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, 02 Apr 2009 22:02:10 +0200, 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.
I can understand being under time pressure - believe me, most days I don't have the time to turn around. But it seems a disservice to the users (especially those who take the time to report a bug) to just dismiss the bug without explanation. That tells me that either there aren't enough people (and the "many eyes/ hands" theory under which OSS is developed isn't really the case) or the community isn't serious about getting users' issues resolved. I know the latter is unlikely the case. But from the end-user perspective, closure with no comment is a bit of a slap in the face (whether intended or not). Maybe the "standard" should be a quick "I need more information" and a change to NEEDSINFO instead of closing the bug with no further comment. Then at leas there's an appearance that someone's willing to look into the problem, even if it's set to a very low priority. 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. And for many users, feeling that the developers care about their needs is what they're looking for. After all, we all - users and developers - want the best damn distribution on the planet, right? ;-) 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, 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 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 -- 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 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
On Thu, 02 Apr 2009 23:24:05 -0500, Rajko M. wrote:
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.
That's a fair point. Even as an experienced user, I often am puzzled by how to properly enter bugs in bugzilla for some things (generally not openSUSE related).
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?
That could work, at least for getting the bug started. For the Novell forums, this is actually not far off from the way product defects are reported through the Novell forums. Often times the customer may be added to the CC list so they know the status, but this isn't always done. 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 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
On pá 3. dubna 2009, Carlos E. R. wrote:
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.
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. 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 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-----
On Friday 03 April 2009 07:48:41 am Carlos E. R. wrote:
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.
In other words, we need volunteers like you (and many others including me), that already help around to take time and sit on problem until it is solved. Of course these guys would need some help in prompt responses, would have to specialize for some areas in order to learn about upstream projects, some incentive (competition? what it would measure?). -- 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 :
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 Friday 03 April 2009 11:38:10 am jdd wrote:
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
I agree about members, but it would be even better to have BugBusters team of people that are already active. -- Regards, Rajko -- 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
On Friday 03 April 2009 09:54:50 am Vladimir Nadvornik wrote:
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.
Which can be, for untrained people, equally disappointing. Nobody wants to listen to them.
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 that 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.
It is, but to prevent writing basic info how to do that time and again, can we collect that on the wiki on the same pile with currently existing instructions for bug reporting? How often that information should be updated, who should be contacted if info on wiki is not up to date? -- 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 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
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 ? -- "If this is the best God can do, I am not impressed" -George Carlin (1937-2008) Cristian Rodríguez R. Software Developer Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.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 Fri, Apr 3, 2009 at 8:58 AM, Carlos E. R. <carlos.e.r@opensuse.org> 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 ... subsequently heading back downstream, to *SUSE bugzilla, getting a developer involved, and having _them_ re-ask (admittedly, with greater "geek-speak-clarity", all due respect intended ...) the question @ upstream _does_ get results. i'd suggest that if/until that becomes a minority case, that there should be some recognition that user->upstream may not be the best recourse for getting problems solved that benfit the project.
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?
Carlos' question is, imho, quite valid -- and the circumstance is repeatedly demonstrable. 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? -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org
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
On Fri, Apr 3, 2009 at 10:23 AM, Rajko M. <rmatov101@charter.net> wrote:
You can imagine how hot is on a developers side of the wire.
certainly. yes. true enough. that's why we pay $$$ through the various channels we participate in to help increase resources. and, btw, we users very often have our own development efforts -- on other projects etc -- so it's not as if we have no clue of the value, and scarcity, of such resources. at times, i'm just not clear that some of the developers, the project, or the commercial company for that matter, see that it's _also_ "hot" on our 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.
perfectly understood. what's often missing is the recognition that we _ARE_ novell's customers (yes, we buy lots of commercial installs, with commercial support for ourselves and our clients), but that we've been forced (or at least strongly nudged) -- as a result of the "upgrade to the latest-n-greates to get it fixed" catch-22 -- to participate in _this_ project. our perspective -- and yes, i'm fully aware that it maybe _only_ our perspective -- is that by participating (time & $$$) in this project, we are _directly_ helping ensure that problems in the project are solved, and that by virtue of the fact that the project code is (almost always) ahead of the commercial project, those solutions make it into the commercial product as well.
The only solution right now is to have more people from community involved in such activity as friendly bug handling.
i agree that that's a good part of the solution -- just not that it's the _only_ solution. it's an objective concern of mine that such "you don't see it my way ..." discussions end up in us-vs-them thinking. that's not at all intended to be my point, or my goal. rather -- this is project-level, "rising tide floats all boats" discourse. i _know_ this project has both BoardMembers & a CommunityManager that invite user commentary "to the project". i simply don't know whether they read/participate here. or whether they've even time/interest to bother ... or, to be fair, should. -- 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
On Friday 03 April 2009 12:43:41 pm jdd wrote:
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.
Having advantage in code quality doesn't help without letting people know about that, which is marketing effort that needs budget. While volunteer man*hours count, it is not enough. There are free resources, though, but they have to be identified. For instance libraries and non-for-profit organizations here in US, might be good way to go, but I'm not teacher and having free "Introduction in openSUSE" can turn just opposite from what I want.
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
Users are there to ask. If nobody asks, no one will know that somebody needs feature, and that is the reason that we have fantastic development platform, and not so smooth part for end users. -- 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 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
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 ;-) )
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. -- 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
-----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, 2009-04-02 at 15:02 +0200, Carlos E. R. wrote:
On Thursday, 2009-04-02 at 12:57 +0200, Martin Schlander wrote:
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 see bug fixes in the Software Updater all the time coming from openSUSE 11.1 Updates. In fact, openSUSE Updater even shows two different types of updates: Security and Recommended. Recommended are the bug fixes (and other stuff may be included in that - someone who handles the update repo can comment on that).
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 would agree that there is a need to fix major annoying bugs in goldmastered versions if they sneak through. 11.1 has been made much more tolerable than when it first came out, so we're relatively good on that foot.
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.
Well, "all known bugs" is a little strong, there will always be bugs in software. However, if there is a well-known, annoying bug in a GM release, I agree that should be repaired. Especially if the life-cycle of the release until it's successor is quite a long one (for example: 11.1, which will remain the current openSUSE OS until November). -- 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 Thu, 02 Apr 2009 12:57:40 +0200, Martin Schlander wrote:
Onsdag den 1. april 2009 20:50:52 skrev PGNet:
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
participants (15)
-
Alberto Passalacqua -
Carlos E. R. -
Cristian Rodríguez -
Dominique Leuenberger -
Henne Vogelsang -
Jan Kupec -
jdd -
Jim Henderson -
Kevin "Yeaux" Dupuy -
Marcus Meissner -
Martin Schlander -
Michael Schroeder -
PGNet -
Rajko M. -
Vladimir Nadvornik