On Friday 09 July 2010 20:15:02 Markus Slopianka wrote:

Hi. I don't know if the 11.3 Goldmaster image has already been created. If it's already too late for two K3b fixes to be included on the image, they should at very least be offered as online update for 11.3.

The first fix is a crash when ripping an audio CD: https://bugs.kde.org/show_bug.cgi?id=236466

The second one fixes a bug that prevents files to be added to a K3b project via Dolphin: https://bugs.kde.org/show_bug.cgi?id=242745

Links to the diffs are provided in the comments.

Thanks for the report. I've just added these patches to the k3b package in KDE:Distro:Stable - can you test it when it builds? TIA Will -- Will Stephenson, openSUSE Team SUSE LINUX Products GmbH - Nürnberg - AG Nürnberg - HRB 16746 - GF: Markus Rex -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

On Friday 16 July 2010 18:54:44 Will Stephenson wrote:

I've just added these patches to the k3b package in KDE:Distro:Stable - can you test it when it builds?

I see that you only ship 1.93 (aka 2.0 RC 4). I guess it's bearable, since the only differences between RC4 and 2.0.0 are a few fixes to the German translation, but we (K3b team) don't maintain a stable 2.0 branch just for fun. Strings and features are frozen there, so please don't hesitate to adopt 2.0.1 and subsequent 2.0.x releases as official updates once they are out (I guess 2.0.1 is due in a few weeks). I'll poke you for new releases or if major bugs are fixed in the stable branch in between bugfix releases. Once I understand OBS, I'll do submit requests as Lubos suggested. Markus -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

On Saturday 17 July 2010 10:17:26 Sven Burmeister wrote:

For the official updates there might be no update to 2.0 unless k3b has a security issue or major bug. That's openSUSE policy.

OK, then. I won't mention individual crash bugs any longer and not point to specific patches in the future, because when I don't do it, openSUSE will adopt official 2.0.x updates and include fixes for minor bugs as a side effect. Stupid policy, but if that's the way to get more bugfixes in people's hands and relieve us K3b team members from reports against bugs that are already fixed, that's the only way to go..... -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

2010/7/18 Sven Burmeister :

Am Sonntag, 18. Juli 2010, 00:12:03 schrieb Markus Slopianka:

...

On Saturday 17 July 2010 10:17:26 Sven Burmeister wrote: Stupid policy, but if that's the way to get more bugfixes in people's hands and relieve us K3b team members from reports against bugs that are already fixed, that's the only way to go.....

INew versions may introduce regressions, so unless you can guarantee this won't happen with k3b, you should not blame a policy that strives to provide users with a stable distro.

To be sincere, in this case I tend to agree with Markus. In general update libraries is somehow dangerous, OK. But with applications that can only cause problems to themselves the policy makes less sense. Now upstream comes here to explain us they have a branch where "Strings and features are frozen". Can they still introduce regressions? Sure, nobody is perfect. But IMHO the real question is: it is possible that they break more things than they fix? We only provide patches, no version upgrades? Well, that's exactly what the k3b team is doing here! The only difference is that when we provide those patches we create a new package with a higher *release* number. When they provide those patches they create a new tarball with a higher *version* number. The difference is just cosmetic, the real work is the same... well, with the difference that the k3b team is more qualified for the work. If there is a problem it is with trust. And since we trust them enough to put his program as the default for CD brurning, we probably should trust them enough to do the work of maintaining a branch with just bugfixes (i.e. basically to maintain the package for us). Isn't this the wet dream of every distro? Upstream maintaining your packages! My vote is to trust them here. If they ever break something ok, rethink this... but give them an opportunity. But anyway, users that want to have the latest versions of KDE applications can just use the KDE:UpdatedApps. That will update to not just the 2.0 branch but to whatever the latest official release is. Markus, to solve your problem I suggests you write somewhere, very clearly, that openSUSE users should test with the k3b version from the KDE:UpdatedApps repository before reporting a bug. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

Am Sonntag, 18. Juli 2010, 10:54:58 schrieb Cristian Morales Vega:

2010/7/18 Sven Burmeister :

...

Am Sonntag, 18. Juli 2010, 00:12:03 schrieb Markus Slopianka:

...

On Saturday 17 July 2010 10:17:26 Sven Burmeister wrote: Stupid policy, but if that's the way to get more bugfixes in people's hands and relieve us K3b team members from reports against bugs that are already fixed, that's the only way to go.....

INew versions may introduce regressions, so unless you can guarantee this won't happen with k3b, you should not blame a policy that strives to provide users with a stable distro.

To be sincere, in this case I tend to agree with Markus. In general update libraries is somehow dangerous, OK. But with applications that can only cause problems to themselves the policy makes less sense. Now upstream comes here to explain us they have a branch where "Strings and features are frozen". Can they still introduce regressions? Sure, nobody is perfect. But IMHO the real question is: it is possible that they break more things than they fix? We only provide patches, no version upgrades? Well, that's exactly what the k3b team is doing here! The only difference is that when we provide those patches we create a new package with a higher *release* number. When they provide those patches they create a new tarball with a higher *version* number. The difference is just cosmetic, the real work is the same... well, with the difference that the k3b team is more qualified for the work. If there is a problem it is with trust. And since we trust them enough to put his program as the default for CD brurning, we probably should trust them enough to do the work of maintaining a branch with just bugfixes (i.e. basically to maintain the package for us). Isn't this the wet dream of every distro? Upstream maintaining your packages!

My vote is to trust them here. If they ever break something ok, rethink this... but give them an opportunity.

I understand him and you, but the problem is, a policy with a lot of exceptions won't work. Thus it is not about trusting project x or y. And it's not like openSUSE would not offer current packages of k3b including all fixes from upstream. I might be wrong but this policy is not that uncommon. In fact ubuntu ships some beta package of digikam, which does not make sense to me. And distros like debian do not do version updates for their stable releases either. openSUSE is not a rolling distro, so one would have to push it that way if one wants those kind of updates.

But anyway, users that want to have the latest versions of KDE applications can just use the KDE:UpdatedApps. That will update to not just the 2.0 branch but to whatever the latest official release is. Markus, to solve your problem I suggests you write somewhere, very clearly, that openSUSE users should test with the k3b version from the KDE:UpdatedApps repository before reporting a bug. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

Am Sonntag, 18. Juli 2010, 13:53:23 schrieb Markus Slopianka:

I agree that blindly updating platform components (eg. KDE SC, GNOME, GTK, Qt, glibc,..) can be risky, but completely separate apps?

You might have a point, yet this is something for an IRC meeting and after that the opensuse-project mailinglist.

openSUSE 11.2 (and I'd guess SLED as well) ships an *ALPHA* release of K3b 2.0! (officially numbered 1.6x) Countless bugs have been fixed since then. All bug reports we from K3b get for outdated versions increases our workload.

Does it not use the KDE3 k3b as default?, AFAIR it was shipped as well. And I agree that default packages that were shipped as non-final versions should get official updates to the final version.

...

And distros like debian do not do version updates for their stable releases either. openSUSE is not a rolling distro, so one would have to push it that way if one wants those kind of updates.

I think you don't know what a rolling distro is. I never wrote that openSUSE should adopt new major versions (eg. K3b 2.1). Rolling distros do that. But is a distributor decides to ship a pre-release (!!) of some package, there should be at very least be willingness to upgrade to an official stable release.

I agree, so what are the differences between what 11.3 ships and 2.0, i.e. the official stable release?

I think I'll get in touch with Fedora/Red Hat, Mandriva, and Kubuntu. If they have the same upstream-hurting policy, I'll suggest to my fellow K3b team members to scrap to whole stable branch altogether. Unlike Novell (or Red Hat or any other commercial distributor) we don't have paid developers.

Sounds a bit dramatic. KDE has a stable branch, digikam, any other package but they seem to cope with it and not have that serious issues with downstream.

We created a stable branch out of consideration for distributions to give them a safe place to update from. If our work (or to be more precise: Michal's work, because he's the programmer -- I'm just a guy who lends a hand where he can such as going through bug reports) isn't appreciated, why should we do it anyway? So if distribution-internal policies hurt us, downstream should assign someone to watch all commits into K3b trunk and hand-pick patches individually.

I think you throw out the baby with the bath water. As if those distros did not offer packages of your stable branch. They do and they ship them by default if their release cycle allows them to. The fact that alphas and RCs were shipped was also due to 2.0 taking that long and distros moving to KDE4. So for the future this won't be an issue because there is a stable version available for KDE4 no matter what release cycle a distro has. Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

Am Montag, 19. Juli 2010, 15:32:19 schrieb Markus Slopianka:

On Monday 19 July 2010 10:27:38 Sven Burmeister wrote:

...

I agree, so what are the differences between what 11.3 ships and 2.0, i.e. the official stable release?

In that specific case the difference is minor: I received a report of a few minor errors in the German translations. Those are fixed. Beside that they are identical (which, btw, I wrote in an earlier mail).

Which is why I do not get why not shipping 2.0 as official update such an issue. The whole thing started because although openSUSE never did so you asked to officially ship every update of the stable branch. And further if distros won't do that but simply pick one version of that stable branch and stay with it it would not make sense to maintain such a stable branch.

...

The fact that alphas and RCs were shipped was also due to 2.0 taking that long and distros moving to KDE4.

I don't find it an issue to ship 2.0 pre-releases (old KDE3-based 1.0 isn't maintained at all which is why Fedora 12 hurt us even more). I find it an issue when distributors refuse to ship the updates for the pre-releases (which sadly includes openSUSE for the 11.2 release cycle).

True. Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org

On Monday 19 July 2010 14:37:00 Will Stephenson wrote:

Markus, would you accept a patch into k3b that puts the k3b icon and others it uses into hicolor so that they are visible on !kde sessions?

Go ahead and commit it. IMO trivial changes don't need asking. :-) Just be sure to commit to http://websvn.kde.org/branches/k3b/2.0/ as well as http://websvn.kde.org/trunk/extragear/multimedia/k3b/ and extend both change logs. Bye, Markus -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kde+help@opensuse.org