Le 11/04/2011 09:30, Cristian Morales Vega a écrit :

(...)nc ;-) I closed it as invalid because it's not an openSUSE bug... and then I fixed the Packman package.

why? if the legal problem involved also hitting bug fixes? why not close it as fixed in packman?? jdd (just curious) -- http://www.dodin.net http://www.dailymotion.com/video/xgxog7_clip-l-ombre-et-la-lumiere-3-bad-pig... http://www.youtube.com/watch?v=FGgv_ZFtV14 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

2011/4/11 Per Jessen :

Cristian Morales Vega wrote:

...

2011/4/11 jdd :

...

I just want to say that we should change a bit the release agenda. It's pretty evident that nobody can use factory seriously before late in the process. It's also obvious from my experience that nobody used some applications (if somebody did, a non starting application should have been noted).

How would you modify the release agenda to make more people test?

I would add some quality assurance criteria that unless met would postpone a release.  For example:

A great way to... postpone a release, but I fail to see how that would make more people test the development versions. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Per Jessen wrote:

Cristian Morales Vega wrote:

...

2011/4/11 jdd :

...

I just want to say that we should change a bit the release agenda. It's pretty evident that nobody can use factory seriously before late in the process. It's also obvious from my experience that nobody used some applications (if somebody did, a non starting application should have been noted).

How would you modify the release agenda to make more people test?

I would add some quality assurance criteria that unless met would postpone a release. For example:

criteria 1: "X bugs per Y changes have been reported". criteria 2: "X bugs per Y changes have been closed with status=MM" criteria 3: "X bugs per Y changes have been closed with status=NN" criteria 4: "X bugs per Y changes are currently open"

I wanted to add - obviously, a set of QA criteria does not automagically "make more people test". What it does is put some more focus on the ones actively testing - "the testers are holding back alpha4", "openSUSE xx.y RC1" being delayed due to lack of testing". However, anyone waiting for alpha4 or a release-candidate would him/herself be a tester, so .... -- Per Jessen, Zürich (20.1°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 11/04/2011 17:40, Sid Boyce wrote:

On 11/04/11 07:20, jdd wrote:

...

Hello,

This mail is not intended to launch a flame war, but to make proposals.

[pruned]

I've been running factory on several boxes (now only 4) going way back. Problems have been few and allows me to file bugs so that the next final release is as solid as possible.

If you read what the OP stated, he did not install a factory version but the one from the final release of 11.4 on DVD. The only "error" he made - and which automatically sent people off in the wrong direction :-) - is that he posted his statement in the opensuse-*factory* list :-) . What he was stating is that the 'factory' may be too close to release time for people to pay close attention to the crap which may finally be foisted on the unsuspecting public who want to try openSUSE, as an alternative to other OSs, for installation and which will not install properly and therefore tarnish (polite term used here) the image of openSUSE. BC -- Great Man reaches complete understanding of the main issues; Petty Man reaches complete understanding of the minute details." Confucius -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 11/04/2011 18:19, jdd wrote:

Le 11/04/2011 10:01, Basil Chupin a écrit :

...

If you read what the OP stated, he did not install a factory version but the one from the final release of 11.4 on DVD.

yes, or from the demo dvd

"demo dvd"? I didn't know such a thing existed. The only "demo" thingie I know is the Live CD.

...

The only "error" he made - and which automatically sent people off in the wrong direction :-) - is that he posted his statement in the opensuse-*factory* list :-) .

it's not an error. I just want to quote that the debugging workflow is not complete, and try to find some way of making it better (I don't ask for help in debugging right now, this I will do on appropriate supprot if necessary).

Relax, take a deep breath :-) . Some people may respond that you what you wrote should belong in something like opensuse-project and not 'factory'. That's what I meant. BC -- Great Man reaches complete understanding of the main issues; Petty Man reaches complete understanding of the minute details." Confucius -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hi jdd, On Apr 11, 11 19:51:22 +1000, Basil Chupin wrote:

On 11/04/2011 18:19, jdd wrote:

...

Le 11/04/2011 10:01, Basil Chupin a écrit :

...

If you read what the OP stated, he did not install a factory version but the one from the final release of 11.4 on DVD.

yes, or from the demo dvd

"demo dvd"? I didn't know such a thing existed. The only "demo" thingie I know is the Live CD.

I received a double-sided 11.4 DVD -- not sure if it is a live DVD, but you can install from that medium, sometimes... Issues are: - it needs good drives to read the data. The i586 side appears to be much harder to read than the x86_63 side. I succeeded only with one portable drive, after external power was connected. - the bootsector should have a lower sector number for some older systems. With regard to improving multimedia experience on openSUSE: - any plans to get together at Linuxtag? I'll be there. cheers, JW- -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de back to ascii! __/ _---|____________\/ \ | 0911 74053-508 __/ (____/ /\ (/) | _____________________________/ _/ \_ vim:set sw=2 wm=8 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) SuSE. Supporting Linux since 1992. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Cristian Rodríguez wrote:

El 11/04/11 03:20, jdd escribió:

...

Hello,

This mail is not intended to launch a flame war, but to make proposals.

Yet again, I fail to see any proposal, or fact to make the supposed problem any better.

Maybe jdd meant to say solicit or invite proposals ? -- Per Jessen, Zürich (20.5°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

jdd wrote:

Le 11/04/2011 19:20, Per Jessen a écrit :

...

...

Yet again, I fail to see any proposal, or fact to make the supposed problem any better.

Maybe jdd meant to say solicit or invite proposals ?

I at least asked to have a web site/page with the bstatus of an application: tested, when, by howmany people

this at least would allow to know if anybody use it :-)

it seems to me obvious than an app that simply don't load was not tested at all

I agree - amazingly it can't have been tested much by whoever is maintaining it. Maybe we need a sign-off-like procedure from maintainers before something goes into the release-cycle? -- Per Jessen, Zürich (20.0°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hello, on Montag, 11. April 2011, jdd wrote:

anyway, the testers/users have no present way to figure what applications are very well tested and wich are not.

<BOfH mode> There is a way: "If it's totally broken, nobody tested it"

But the chance was I had just to build a dvd and could test them with real data.

That's probably the most important point: People test what they use/need. They don't test something they will never need or use. This is especially true for community (aka "non-paid") testers. (But you would have to pay a lot to make me testing beer *g*) (At least that's how I see it. There might be exceptions, of course.) The good thing is that we have lots of testers in our community and get a good coverage because of the different things everybody needs for his daily work (or fun - games have to be tested as well ;-)

We also should have a better understanding of who is in charge of what.

Now reporting on a mailing list (not this one!) or a forum makes sure you didn't simply made a typo.

Yes, but it also adds some additional work to the bugreporter. Therefore I'd say that step is optional.

Then if it's really a bug, how to report it?

at present, one can report:

* to some user mailing list (opensuse@, forum) and hoping somebody will followup. Most non tech people do so, it's difficult to manage

Short answer: forget it. This will not work. (Someone might in theory work as "bugzilla relay", but that makes things more difficult. What if the developer has a question? NEEDINFO to the "relay", who then has to ask the person who reported the bug in the forum...)

* to bugzilla, but who is in bugzilla? Is the problem a packaging problem, then it's probably one directly for opensuse (or packman). Is it an application problem? is there anybody to report upstream and follow the situation? It's not easy

General rule of thumb: Report it in bugzilla.novell.com. If it is really an upstream issue, the openSUSE developer/packager can still ask you to report it upstream. An additional advantage is that the bug gets known to the openSUSE packager, which can be important too (otherwise he might simply miss the bugfix because he never heard about the bug). Exceptions might apply when it comes to typos etc. (- in this case direct upstream reports might make sense.

* upstream.When I have a problem with an application I know really well, I usually report upstream, for example digikam

Yes, that's always an option if you know it's an upstream bug. It also makes sense for enhancement requests. Nevertheless, for critical bugs you should also open a bug in bugzilla.novell.com with a link to the upstream report to make the openSUSE packager aware of it.

I don't know, for example, if there is a programmer in the openSUSE team for any given application. Can we have a list (even partial). I mean something like "if you find a bug on kde or gnome, you can report on bugzilla, we have specialists, if you have a bug on kdenlive, report it upstream, noboy here can manage it" (*just examples, don't take it as is*) - the page about list of tested apps could have a mark saying: report to bugzilla, report to packman, report upstream...

You'll have a lot of fun in managing this list and keeping it up to date ;-) and as I said above, pointing bugreports to upstream by default (even if only for some packages) isn't the best idea IMHO. Nevertheless, such a list (better: a flag in the buildservice for each package) would be quite interesting. Regards, Christian Boltz -- By the way, it's a sign of how good the distribution is that we're arguing about the name and not dealing with problems in the essence of the thing. Even the overloaded servers are what an old boss of mine would have called a "success problem." [Randall Schulz in opensuse] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Mon, Apr 11, 2011 at 5:29 PM, Cristian Rodríguez wrote:

El 11/04/11 18:11, Christian Boltz escribió:

...

Hello,

on Montag, 11. April 2011, jdd wrote:

...

anyway, the testers/users have no present way to figure what applications are very well tested and wich are not.

<BOfH mode>     There is a way: "If it's totally broken, nobody tested it"

...

But the chance was I had just to build a dvd and could test them with real data.

That's probably the most important point: People test what they use/need. They don't test something they will never need or use. This is especially true for community (aka "non-paid") testers. (But you would have to pay a lot to make me testing beer *g*)

Heh :) In any case, totally broken stuff should never get published in the first place, packages usually come with a test suite, that should be run during build.

One of the GSoC projects is to work on spec-cleaner. Is it feasible to update the spec for specfiles and get a %test section added. Then have rpmlint complain if it empty. I'm not sure where spec-cleaner would fit in, but maybe it could at least ensure "cleaned" specfiles had a empty %test section. Just seeing that might be enough of a prompt to get more self-tests into specfiles. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Tue, 12 Apr 2011 13:02:32 +0200 Juergen Weigert wrote:

Yes, this is important. We lack an easy to use harness, to test run GUI applications.

Well, there is also software that needs services like d-bus and hardware. I'd be interested in a "make check" that verifies that e.g. bluetoothd works correctly ;-) -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Apr 11, 11 19:44:30 +0200, Per Jessen wrote:

jdd wrote:

...

Le 11/04/2011 19:20, Per Jessen a écrit :

...

...

Yet again, I fail to see any proposal, or fact to make the supposed problem any better.

Maybe jdd meant to say solicit or invite proposals ?

I at least asked to have a web site/page with the bstatus of an application: tested, when, by howmany people

this at least would allow to know if anybody use it :-)

it seems to me obvious than an app that simply don't load was not tested at all

I agree - amazingly it can't have been tested much by whoever is maintaining it. Maybe we need a sign-off-like procedure from maintainers before something goes into the release-cycle?

Add a trivial test suite, like launching an app with --version option, or whatever is available. Then you know that it at least starts. cheers, JW- -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de back to ascii! __/ _---|____________\/ \ | 0911 74053-508 __/ (____/ /\ (/) | _____________________________/ _/ \_ vim:set sw=2 wm=8 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) SuSE. Supporting Linux since 1992. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Le 11/04/2011 16:56, Greg KH a écrit :

Not true at all, this is up to the Packman developers, nothing the openSUSE developers can do about this for lots of various legal reasons, as has been stated numerous times here.

well, if the legal problem impacts not only the distribution but also the bugreports, this is a bad news. It's almost impossible to know from the user point of view if a bug come from the package, the application itself or any other thing. It's already very difficult to make users report in bugzilla, then it's not surprising if there are so many problems in multimedia applications if it's necessary to report again. elsewhere. may be, for a beginning, we could close the bug with "report upstream"? "Invalid" is not very rewarding for the reporter :-( or will it be possible to add in the doc: "look at the package name - in zypper or yast; If the name have a "pm" in it, please ask first packman at packman@links2linux.de I add packman as "to" for this mail. thanks jdd -- http://www.dodin.net http://www.dailymotion.com/video/xgxog7_clip-l-ombre-et-la-lumiere-3-bad-pig... http://www.youtube.com/watch?v=FGgv_ZFtV14 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Apr 11, 11 09:28:53 -0700, Greg KH wrote:

On Mon, Apr 11, 2011 at 05:40:24PM +0200, jdd wrote:

...

Le 11/04/2011 16:56, Greg KH a écrit :

...

Not true at all, this is up to the Packman developers, nothing the openSUSE developers can do about this for lots of various legal reasons, as has been stated numerous times here.

well, if the legal problem impacts not only the distribution but also the bugreports, this is a bad news.

No, the issue is that packman bugs belong to packman, not to the main openSUSE bugzilla, as the openSUSE developers can do nothing about packman packages.

It's just that simple, sorry.

How are the odds that we gain control over our bugzilla? Interconnect with packman would come to mind then. cheers, JW- -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de back to ascii! __/ _---|____________\/ \ | 0911 74053-508 __/ (____/ /\ (/) | _____________________________/ _/ \_ vim:set sw=2 wm=8 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) SuSE. Supporting Linux since 1992. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Apr 11, 11 13:59:44 -0400, Jeff Mahoney wrote:

...

How are the odds that we gain control over our bugzilla? Interconnect with packman would come to mind then.

One of our goals with the prototype bugzilla is to add interconnect to it. It's sort of in a holding pattern right now, though.

Cool. Good news! thanks, JW- -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de back to ascii! __/ _---|____________\/ \ | 0911 74053-508 __/ (____/ /\ (/) | _____________________________/ _/ \_ vim:set sw=2 wm=8 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) SuSE. Supporting Linux since 1992. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 4/11/2011 12:28 PM, Greg KH wrote:

On Mon, Apr 11, 2011 at 05:40:24PM +0200, jdd wrote:

...

Le 11/04/2011 16:56, Greg KH a écrit :

...

Not true at all, this is up to the Packman developers, nothing the openSUSE developers can do about this for lots of various legal reasons, as has been stated numerous times here.

well, if the legal problem impacts not only the distribution but also the bugreports, this is a bad news.

No, the issue is that packman bugs belong to packman, not to the main openSUSE bugzilla, as the openSUSE developers can do nothing about packman packages.

It's just that simple, sorry.

greg k-h

You can't say that. There are countless examples of software that has to operate with other software, and the cause of a bug that the user sees may completely be in the "supported" software even though it only appears when used in concert with some "unsupported" software. At the very least such things should at least be investigated to determine where the bug really is. Supported app crashes on start when unsupported library is used. The easy answer is "Doesn't crash with the supported library, therefor not our problem." Wrong for at least two reasons: * The user doesn't care about this distinction, they just won't use the system any more if there is any other system that supports it's _users_ better. A system that is so closed to the rest of the world is _not useful_. A system that users do not want to use is not useful to the vendor or anyone else involved in creating the system. * The bug could absolutely be in the _supported_ app rather than in the unsupported library. Regardless, it must _at least_ be investigated enough to find out which part of the two-part system is in error. Do you ignore all samba bug reports that involve Windows clients? After all the same bug doesn't appear in kde on a suse desktop? Do you ignore all Apache bug reports that come from IE or Safari users? After all the same bug doesn't appear in mozilla on a suse desktop? Real example, less than perfectly clearly described, http://unix.derkeiler.com/Newsgroups/comp.unix.sco.misc/2006-11/msg00115.htm... The point was you have 3 pieces of software, the OS itself, ksh, and filePro. Individually they each can be said to have been "proven" working correctly. I "proved" it myself with special tests that exercise the particular thing I was trying to do. Yet together, doing something that they are definitely supposed to be able to do, nothing unsupported, they absolutely always fail in exactly the same way. _someone_ has to step up and figure out what the problem is or else it will never get fixed. And it never was, and I simply no longer use 2 of those 3 components any more. I have to use filePro, but I don't have to use SCO Unix or ksh. All 3 components in the original scenario were closed source commercial software so I as a user was helpless to the vendors to fix it. Without access to the source, or even debug-enabled binaries, all I could do was construct and perform the tests I did to reproduce/exhibit the problem and isolate it from any other factors. But the vendors of all 3 parts had more than enough "proof" to make exactly the argument you just made. Well that was certainly easy for them but it didn't solve the problem and now the user has gone elsewhere, which doesn't sound like much of a solution. Once all the users go elsewhere you can just stay home on your couch and not even write any software at all, that's even easier. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 4/11/2011 3:16 PM, Greg KH wrote:

On Mon, Apr 11, 2011 at 03:09:20PM -0400, Brian K. White wrote:

...

On 4/11/2011 12:28 PM, Greg KH wrote:

...

On Mon, Apr 11, 2011 at 05:40:24PM +0200, jdd wrote:

...

Le 11/04/2011 16:56, Greg KH a écrit :

...

Not true at all, this is up to the Packman developers, nothing the openSUSE developers can do about this for lots of various legal reasons, as has been stated numerous times here.

well, if the legal problem impacts not only the distribution but also the bugreports, this is a bad news.

No, the issue is that packman bugs belong to packman, not to the main openSUSE bugzilla, as the openSUSE developers can do nothing about packman packages.

It's just that simple, sorry.

greg k-h

You can't say that.

Yes I can, and I did :)

...

There are countless examples of software that has to operate with other software, and the cause of a bug that the user sees may completely be in the "supported" software even though it only appears when used in concert with some "unsupported" software. At the very least such things should at least be investigated to determine where the bug really is.

Supported app crashes on start when unsupported library is used.

The easy answer is "Doesn't crash with the supported library, therefor not our problem."

Yup.

...

Wrong for at least two reasons:

Nope, for the reason you forgot, "We limit our scope of testing and support to the supported repositories". Just like any other distro does, you have to draw the line somewhere, and this is where it is drawn.

Again, like all other distros.

Note, we will of course do our best to try to resolve issues whenever possible, but please, understand the issues here and the fact that "we will support any library from any repo combined with any application" is something that NO ONE does.

Or if they do, they are insane, or lying, or both.

thanks,

greg k-h

Every system needs to support basic interoperability with other software. It's part of the very definition of practically every piece of software anywhere. OpenSUSE is not an embedded system with every byte of code absolutely fixed. It is a general purpose unix-like operating system, and using external software on it is part of the definition of that. If it turns out that an external replacement for some normally supplied part behaves incorrectly that's one thing. But you can't avoid the need to find out which part is misbehaving. It's not automatically always the external part just because it's external. Or, put it this way, does suse add a suse tag to the name or version numbers of the supplied libraries and compile all the supplied binaries to require those suse-versioned libraries explicitly? No they do not. If the supplied binaries really did require suse-supplied libraries and _only_ those, the makefiles could absolutely be made to enforce that. If I purchase a replacement math library that runs 200% faster from a 3rd party, it's entirely possible that this external thing is wrong in some way. It's just exactly as possible that the replacement library adheres to the specs of the original correctly, only the original has a bug that the replacement does not have. That is a difference in behaviour that might adversely affect some app. So, suse app + suse lib = no problem suse app + other lib = problem Except that's dumb simplistic short sighted logic. It's dumb for suse to blindly support the bug in the broken library rather than fix the app that expects a bug or the stock library that supplies it. True, stuff like that is generally for upstream to duke-out, not a distributor, but it's still true that the bug could just as easily be in the distribution as in the evil external file. The distributors role may be as little as just to report the discovery upstream and try to incorporate any fix as soon as one is delivered from upstream, but the distributors role is _at least _ that, not just to ignore the problem without looking. Or else, it's just not a very useful distribution. It may be pretty, and it may all work perfectly as long as you are willing to restrict the definition of "works" so narrowly, but that's not generally useful. Is the point of the distro to make the distributor feel good or is it to be useful to users? -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Tue, Apr 12, 2011 at 10:03:23PM +0200, Detlef Reichelt wrote:

Am Mon, 11 Apr 2011 09:28:53 -0700 schrieb Greg KH :

...

No, the issue is that packman bugs belong to packman, not to the main openSUSE bugzilla, as the openSUSE developers can do nothing about packman packages.

No, PackMan is a member of the openSUSE Community, and the openSUSE-Community drives openSUSE. So, please accept us as a member of the community!

Sorry, I didn't mean it to say that you are not part of the community at all, my appologies for having it come out that way. You are greatly appreciated and needed by the whole community, myself included.

A bug, thats hurt many 3rd party packages, but it is an openSUSE bug, not PackMan: https://bugzilla.novell.com/show_bug.cgi?id=680959

True, and it looks like it will be fixed in openSUSE, which is great.

Why not assign PackMan related bugs to packman@links2linux.de in bugzilla?

Fine with me, but triaging them is difficult at times, we need all the help we can get in that area. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 04/11/2011 06:28 PM, Greg KH wrote:

No, the issue is that packman bugs belong to packman, not to the main openSUSE bugzilla, as the openSUSE developers can do nothing about packman packages.

It's just that simple, sorry.

greg k-h I belong to Packman (recently joined up) and maintain mltimedia:apps/libs therefore I can take action on both Packman and openSUSE multimedia bugs.

Dave P -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org