On Fri, Jan 6, 2012 at 21:26, Markus Slopianka wrote:

...

likely to bring several regressions I had no regressions at all and when you think it brings regressions, talk to the upstream KDE release managers.

Second that. I've updated several systems to KDE4.7.4 without problems. No regressions, no drama, no problems (that were not created by me and my fat fingers)

...

* PackageKit will probably explode like it did the last time we did a full KDE update (4.3.1->4.3.5) leading to failed updates

Then fix PackageKit first.... Oh, your example is from years ago... is that all you can come up with? How about facts? Enable the KR47 repo and check for yourself.

No issues there either. C. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On 01/06/2012 11:54 AM, Martin Schlander wrote:

Fredag den 6. januar 2012 14:38:53 skrev Dirk Müller:

...

Currently we have 4.7.4 in KDE:Distro:Factory and in KDE:Release:47. I would like to have your opinion on how to move forward:

a) I copy KDE 4.7.4 from KDE:Distro:Factory to KDE:Distro:Stable, and delink KDE:Release:47 from KDE:Distro:Factory. Then I Import KDE 4.8 into KDE:Distro:Factory and copy whatever is needed from Unstable:SC to make it build and work.

This would mean that future maintenannce updates for 12.1 are based on 4.7.4. I think that is okay, there have even be requests to release 4.7.4 as a maintenance update (in general we're pro this change).

b) I delink KDE:Release:47 from KDE:Distro:Factory and leave it at 4.7.4, and then import KDE 4.8 into KDE:Distro:Factory (and copy whatever is needed from Unstable:SC to make it build and work).

in this case 12.1 updates would stay on 4.7.2, users who want the later fixes would need to switch to KDE:Release:47

I prefer a). any comments?

I prefer b)

* Pushing 4.7.4 as an official update is a huge update/download likely to bring several regressions * PackageKit will probably explode like it did the last time we did a full KDE update (4.3.1->4.3.5) leading to failed updates * If you make an exception and upgrade KDE you open up the pandora's box of version whores who'll flood this list and irc and forums with requests for official upgrades whenever there's an upstream release forever and ever.

Normally, I'd be inclined to agree with Martin about a version bump. However, I too find 4.7.4 very stable and usable on 11.4 and 12.1. I've got the latest 4.8.rc on my netbook and it also seems to work very well already. I am well aware of versionitis, but it seems this upgrade will bring a better experience for many users. Peter -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On Sat, 2012-01-07 at 16:28 +0100, Sven Burmeister wrote:

Am Freitag, 6. Januar 2012, 20:54:45 schrieb Martin Schlander:

...

* Pushing 4.7.4 as an official update is a huge update/download likely to bring several regressions * PackageKit will probably explode like it did the last time we did a full KDE update (4.3.1->4.3.5) leading to failed updates * If you make an exception and upgrade KDE you open up the pandora's box of version whores who'll flood this list and irc and forums with requests for official upgrades whenever there's an upstream release forever and ever.

The complains I remember are as follows:

a) low response/fixing rate for bugs filed at bnc b) slow release of updates c) openSUSE's KDE is out-of-date (lots of bugs fixed upstream) d) shipping upstream version will introduce regressions

Unfortunately I am not well informed about how much time how many people spend on working on KDE within openSUSE or how time-consuming backporting/fixing/packaging updates is. So I might make some wrong assumptions.

Here is my proposal for the rule of thumb. Exceptions should be discussed as they appear, i.e. things like kdepim 4.7 etc.

- create a list of openSUSE patches This will enable users to check whether their bug might be opensuse-specific

- be stricter about upstream bugs in bnc Reality is that most upstream bugs reported at bnc will not get fixed. This means that the reporter will be frustrated because his report stays unanswered and he does not get a fix from openSUSE. Yet it also means that because he did not report upstream, upstream cannot fix it and if it was fixed upstream because somebody else reported it the reporter does not know and cannot report back to openSUSE. So I would suggest to only allow openSUSE-specific bugs and bugs that link to an upstream bug or patch and act as reminder. I agree in most areas, but take huge exception to this. Joe User isn't going to know what is upstream. Heck, even I'm not always able to tell when it is upstream or not. Its better they report it, then be told the issue is upstream. In that case I'd recommend a maintained page on how to report upstream.

- create a list of patches to STABLE This enables testers to check what they should test and users to check whether their issue was already taken care of.

- release updates quicker. Patches are put into STABLE and I claim that leaving them in there for more than two weeks will not increase their testing or feedback. Or to put it in other words: if a patch did not cause any trouble within two weeks – ship it. This means that there will be more updates with less patches and hence users can revert easier in case one of them causes any issues. Further users will get more "feedback" and thus feel that there is work going on.

- ship the last minor release for openSUSE's KDE major version as optional update To me it feels that after two or three months after an openSUSE release the number of updates for KDE drops to ~0. Mostly because the major crashes and issues are resolved and everything else won't be backported. Shipping the last minor release as optional update will not worsen that state because it is optional, i.e. only those that want it install it and it can be reverted easily. Due to the KRxy repos the update would get testing and the packages could be taken from there e.g. four weeks after the upstream release.

I think this would cover: a) low response/fixing rate for bugs filed at bnc b) slow release of updates c) openSUSE's KDE is out-of-date (lots of bugs fixed upstream) d) shipping upstream version will introduce regressions

Sven

-- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On Sat, 2012-01-07 at 18:07 +0100, Sven Burmeister wrote:

Am Samstag, 7. Januar 2012, 08:27:02 schrieb Roger Luedecke:

...

I agree in most areas, but take huge exception to this. Joe User isn't going to know what is upstream. Heck, even I'm not always able to tell when it is upstream or not. Its better they report it, then be told the issue is upstream.

This relies on the wrong assumption that they are told that their issue is upstream. What happens in reality is that those bugs remain unanswered and unfixed in bnc. How is that helping anybody? Reporting upstream increases the chances of getting a response – which does help. Upstream has more KDE developers and those devs know the app they maintain, unlike openSUSE staff who mainly act as packagers.

Don't get me wrong, in an ideal world openSUSE users would report every issue to openSUSE and it would be evaluated and forwarded to the suitable place. But that's not going to happen unless there is a group of people from the openSUSE community who takes that job.

IMHO it is a no-go for openSUSE staff to spend time on bug triaging – simply because their time is too precious (because there are too few). Combine this with >90% bugs reported being upstream issues or issues that whose fix will never be backported and off you go with lots of wasted time that cannot be spent on packaging and fixing downstream issues.

...

In that case I'd recommend a maintained page on how to report upstream.

How is reporting upstream different from reporting at bnc – given users get a link to bko?

Sven Reporting upstream by default seems counter-intuitive to me. Maybe we just need to make a call to form a bug taskforce of people like me who aren't skilled enough to code but know enough to determine if an issue is an upstream one. We could peruse each one, go "hey this looks like it," check with bko to confirm, then help the reporting user get the report upstream.

-- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

Am Samstag, 7. Januar 2012, 09:16:11 schrieb Roger Luedecke:

Reporting upstream by default seems counter-intuitive to me.

That might be the case. For me it's: I'm using KDE thus I report to KDE. For you it is: I use openSUSE thus I report everything to openSUSE.

Maybe we just need to make a call to form a bug taskforce of people like me who aren't skilled enough to code but know enough to determine if an issue is an upstream one. We could peruse each one, go "hey this looks like it," check with bko to confirm, then help the reporting user get the report upstream.

Good idea. But nobody was ever held back from triaging bugzilla or work on the wiki, blog howtos etc. So I would assume that if there are people willing to do so, they would have started already. :-) Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

Dnia sobota, 7 stycznia 2012 o 18:16:11 Roger Luedecke napisał(a):

Reporting upstream by default seems counter-intuitive to me. Maybe we just need to make a call to form a bug taskforce of people like me who aren't skilled enough to code but know enough to determine if an issue is an upstream one. We could peruse each one, go "hey this looks like it," check with bko to confirm, then help the reporting user get the report upstream.

Note that KDE applications invite the operator to report to KDE by default. Sometimes it does not work at all, due to bad discontinuation policy at KDE (like Kmail, KPackageKit), which is something we should explicitly condemn (and replace the broken links with BNC). Chris -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On 07.01.2012 21:48, Christian Trippe wrote:

The rule here is already there, see http://en.opensuse.org/openSUSE:Bugreport_KDE and especially http://en.opensuse.org/openSUSE:Bugreport_KDE#Report_at_bugzilla.novell.com_... But there are a few reasons why it does not always work

* Lack of manpower

* Sometimes, at least for me, it is not always clear, if a bug is caused by KDE or lower in the stack. So if you have no time to do some tests such a bug easily remains unanswered.

But many bugs are closed as upstream and people are told to report bugs first upstream and to reopen if a fix is available there.

It can also happen that one leaves some clearly upstream reports open, after they have been reported there, so that they are more easily found and avoiding duplicated reports on bnc by this.

And IMHO the number of useful reports, this means with a link to a fixed upstream report and the commit has increased with 12.1. So this works to some extend already today.

Of course it would really help if there were a few people more doing bug triage.

If someone wants to helps, here is the howto for KDE on openSUSE: http://en.opensuse.org/openSUSE:Bug_Screening_KDE

It is a bit out of date in some of the details, but one should get the idea.

Christian

So either people post problems on that list to discuss if it's upstream or not, or we find something that real solves the problem. I'm really not that good in writing a bugreport and haven't done it that often in my live, so I probably miss the point completely, anyway, we might should work together with the upstream developers more often then we do now. How? Well, I know many KDE guys are using openSUSE due to a) SUSE is traditionally one of the biggest KDE supporters b) Both KDE and openSUSE are Europe-founded projects. I'd rather suggest to ask KDE people to join our list, and work as "upstream experts". The KDE guys know their own code best, so they can decide best if it's upstream or openSUSE-related. Our KDE-team is patching KDE. That's good since KDE becomes a lot more useful due to the patches. Anyway, the devs would do very well by publishing a list of patches and changes they did. I know, this would be hard work, but might be a good chance to find out if something's upstream related, or not. So far, this is everything I'd suggest, hope it helps --kdl -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On Sun, 2012-01-08 at 10:47 +0100, Christian Trippe wrote:

Am Samstag, 7. Januar 2012, 22:25:17 schrieb Kim Leyendecker:

...

On 07.01.2012 21:48, Christian Trippe wrote:

...

The rule here is already there, see http://en.opensuse.org/openSUSE:Bugreport_KDE and especially http://en.opensuse.org/openSUSE:Bugreport_KDE#Report_at_bugzilla.novell. com_or_bugs.kde.org.3F But there are a few reasons why it does not always work

* Lack of manpower

* Sometimes, at least for me, it is not always clear, if a bug is caused by KDE or lower in the stack. So if you have no time to do some tests such a bug easily remains unanswered.

But many bugs are closed as upstream and people are told to report bugs first upstream and to reopen if a fix is available there.

It can also happen that one leaves some clearly upstream reports open, after they have been reported there, so that they are more easily found and avoiding duplicated reports on bnc by this.

And IMHO the number of useful reports, this means with a link to a fixed upstream report and the commit has increased with 12.1. So this works to some extend already today.

Of course it would really help if there were a few people more doing bug triage.

If someone wants to helps, here is the howto for KDE on openSUSE: http://en.opensuse.org/openSUSE:Bug_Screening_KDE

It is a bit out of date in some of the details, but one should get the idea.

Christian

So either people post problems on that list to discuss if it's upstream or not, or we find something that real solves the problem.

I'm really not that good in writing a bugreport and haven't done it that often in my live, so I probably miss the point completely, anyway, we might should work together with the upstream developers more often then we do now.

How? Well, I know many KDE guys are using openSUSE due to a) SUSE is traditionally one of the biggest KDE supporters b) Both KDE and openSUSE are Europe-founded projects.

I'd rather suggest to ask KDE people to join our list, and work as "upstream experts". The KDE guys know their own code best, so they can decide best if it's upstream or openSUSE-related.

No the problem is not so much if something is upstream or not, but more where is the correct upstream. Sure a crash in plasma is easy, but what with a bug in apper?

Is it a bug in apper, in the packagekit-zypp backend or in packagekit itself. This can at least to some degree be checked when testing with the GNOME equivalent. This needs to be done by us and not (KDE)-Upstream.

So this is not so much about fixing a bug, but help in triaging which everybody can do. Sure upstream knowledge is sometimes useful, but often it is not needed, because you simply need time

Christian Agreed.

-- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On Sun, Jan 8, 2012 at 11:34 AM, Sven Burmeister wrote:

Am Sonntag, 8. Januar 2012, 10:47:02 schrieb Christian Trippe:

...

No the problem is not so much if something is upstream or not, but more where is the correct upstream. Sure a crash in plasma is easy, but what with a bug in apper?

Isn't this the exception to the rule? Most bugs are within KDE apps that do not have opensuse-specific backends, apper is the exception to the rule, as is policykit if it comes to the rules set-up by default.

Sven

The problem is that KDE is sitting on a huge software stack, other parts of which also have openSUSE-specific patches and configurations. -Todd -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

todd rme said the following on 01/08/2012 05:42 AM:

The problem is that KDE is sitting on a huge software stack, other parts of which also have openSUSE-specific patches and configurations.

To the degree that is true, to the degree that even to edit the source and recompile any part of KDE or change the scripts, you are sitting on the stack of text mode tools, compilers and more, all of which have support in different areas, this is how KDE and Linux is different from Windows. There are arguments for an against diversification, for an against single sourcing. Even with Linux we have some critical paths that are only mitigated by having the sources widely duplicated. But the degree that Todd's case is true can best be shown by hard evidence. Sven - and others - how many of the bugs that get reported to bugs.kde.org are nothing to do with KDE, are bugs in MAKE, GCC, X or the kernel? How many are actually runtime/installation configuration issues? Because I wonder how much of Todd's 'stack' is 'runtime' as opposed to the 'stack' that's needed to run Linux as a development platform? Reality often bits and many plausible conjectures fall in the face of evidence. Sven, what's the hard evidence here? -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

Am Sonntag, 8. Januar 2012, 07:55:54 schrieb Anton Aylward:

But the degree that Todd's case is true can best be shown by hard evidence. Sven - and others - how many of the bugs that get reported to bugs.kde.org are nothing to do with KDE, are bugs in MAKE, GCC, X or the kernel? How many are actually runtime/installation configuration issues?

Because I wonder how much of Todd's 'stack' is 'runtime' as opposed to the 'stack' that's needed to run Linux as a development platform?

Reality often bits and many plausible conjectures fall in the face of evidence. Sven, what's the hard evidence here?

You will have to query upstream. I can only speak for the bugs I report and there was not a single gcc or make issue around. Configuration (if it is a KDE apps config) is upstream as well. Kwin has some issues depending on the xorg/graphics stack but with exceptions those are still not openSUSE-specific but valid for other distros as well and it's good upstream knows about them. No arch, fedora or whatever user will query bnc for issues and hence "same stack"-users will never meet. Very few issues are really openSUSE-specific. apper + zypper-backend is one of them. The nvidia one back in the days was one as well AFAIK. As I mentioned before, most bugs reported are normal KDE bugs so as a rule of thumb upstream is the correct place to report – even if it only helps to check which distros have the same issue and what stack versions they share. I mean, does anybody really doubt that >50% of KDE bugs reported are not openSUSE-specific? Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

Am Sonntag, 8. Januar 2012, 08:28:06 schrieb Anton Aylward:

If anything, my complaint is along the lines of ... well we've had this discussion recently about flipping the repositories. Since I have .8 on Fedora for a few weeks now my reaction is "about time too!".

So you want the packages from UNSTABLE to move to e.g. KR48 earlier? Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

Am Sonntag, 8. Januar 2012, 11:34:59 schrieb Sven Burmeister:

Am Sonntag, 8. Januar 2012, 10:47:02 schrieb Christian Trippe:

...

No the problem is not so much if something is upstream or not, but more where is the correct upstream. Sure a crash in plasma is easy, but what with a bug in apper?

Isn't this the exception to the rule? Most bugs are within KDE apps that do not have opensuse-specific backends, apper is the exception to the rule, as is policykit if it comes to the rules set-up by default.

No of course not. But usually these bugs often require more work to even upstream them. So they often remain mostly untouched and clutter up bugzilla. And it is not only apper, but every *Kit, graphics/Xorg related things, etc. Everything alone is not that much but all together, it easily leads to a growing number of untouched bugs, where you then easily overlook also a simple one, where it is for example clear that it belongs upstream. Christian -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On Tuesday 10 Jan 2012 15:23:48 Dirk Müller wrote:

On Friday 06 January 2012, Markus Slopianka wrote:

...

Does that also mean KR48? KR48 looks pretty broken right now. I found it unfortunate that with the 4.8 RC openSUSE couldn't be mentioned as distributor to pick up the packages. Being the first and making it into the "how to obtain" part of KDE release announcements is a great way to promote ourselves.

Hi,

well, my plan was to build KDE:Release:48 based on KDE:Distro:Factory packages, so it is depending on the solution to my question above.

I'd get on with a) asap. Although it wastes a lot of post-12.1 release fix backporting work that I did. Perhaps we should consider shipping all .z releases as version bumps, delayed a couple of weeks after release so KR4* testing will show regressions. Yes, this sucks for those on low bandwidth but generally the regression-to-fix ratio is low. Will -- -- Will Stephenson, KDE Developer, openSUSE Boosters Team SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On Wednesday 18 January 2012 19:23:48 Dirk Müller wrote:

On Thursday 12 January 2012, Will Stephenson wrote:

...

Max Lin noticed these packages became downgraded in KDE:Release:47

clemantine 1.0 -> 0.7.3

That was linked from K:D:F before, which had a version upgrade. I think it makes sense to upgrade also to 1.0 in K:D:S, so thats why I did that.

...

digikam 2.3.0 -> 2.2.0 kipi-plugins 2.3.0 -> 2.2.0

Not really sure if we want to ref digikam to the latest release in KDE:Distro:Stable ??!

That's not what I'm suggesting, these downgrades are in KDE:Release:47 after the unlink from KDF.

...

kmymoney 4.6.1 -> 4.6.0 libbluedevil 1.9.1 -> 1.9 oxygen-gtk 1.1.5 -> 1.1.4

same here. however here I think it makes sense, so I did that.

...

oxygen-icons 4.7.4 -> 4.7.2 parley 4.7.4 -> 4.7.2 perl-kde4 4.7.4 -> 4.7.2 perl-qt4 4.7.4 -> 4.7.2 phonon 4.6.0 -> 4.5.0 plasma-addons 4.7.4 -> 4.7.2 python-kde4 4.7.4 -> 4.7.2 rekonq 0.8.1 -> 0.8.0 rocs 4.7.4 -> 4.7.2 ruby-kde4 4.7.4 -> 4.7.2 ruby-qt4 4.7.4 -> 4.7.2 step 4.7.4 -> 4.7.2

Those were bugs, now fixed. Thanks for checking!

Great, thanks for fixing. Will -- Will Stephenson | openSUSE Board, openSUSE Boosters Team, KDE Developer SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On Wednesday, January 18, 2012 10:36:04 PM Javier Llorente wrote:

On Viernes, 6 de enero de 2012 14:38:53 Dirk Müller escribió:

...

Hi,

I would like to put KDE 4.8.0 (or 4.8 RC3 rather for now) into KDE:Distro:Factory. The reason is the sooner we start, the better we find> the problems.

Currently we have 4.7.4 in KDE:Distro:Factory and in KDE:Release:47. I> would like to have your opinion on how to move forward: a) I copy KDE 4.7.4 from KDE:Distro:Factory to KDE:Distro:Stable, and> delink KDE:Release:47 from KDE:Distro:Factory. Then I Import KDE 4.8 into KDE:Distro:Factory and copy whatever is needed from Unstable:SC to make it build and work.

This would mean that future maintenannce updates for 12.1 are based on> 4.7.4. I think that is okay, there have even be requests to release 4.7.4 as a maintenance update (in general we're pro this change).> b) I delink KDE:Release:47 from KDE:Distro:Factory and leave it at 4.7.4,> and then import KDE 4.8 into KDE:Distro:Factory (and copy whatever is needed from Unstable:SC to make it build and work).

in this case 12.1 updates would stay on 4.7.2, users who want the later> fixes would need to switch to KDE:Release:47

I prefer a). any comments?

+1 for a) If by delinking you mean copying (aggregates too, especially libqt4), sounds good to me.

Greetings, -- Just two cents from a user. /KDE47 appears to have 4.7.4-4.22.1 now but before this last week I thought I had download 4.7.4-6.4 from that repo. Since 4.7.4-6 corrected several problem I had, it would bad if the new 4.7 you are proposing it not at least up to that level. This is repo I use but it wants to downgrade now.

Other than take it appears your Idea would simplify a lot of confusion. http://download.opensuse.org/repositories/KDE:/Release:/47/openSUSE_12.1/ -- Russ -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org