Am Samstag, 15. September 2012, 22:24:45 schrieb Will Stephenson:

In my humble opinion there is now a false dichotomy between 'community maintained' and 'team maintained' - KR49 as community territory and KDF as the homeland of the SUSE engineer. As there is effectively no dedicated KDE (or GNOME if it makes you feel better) team inside SUSE for openSUSE any more, KDF has to be community maintained. Whether that is Dirk doing bits and pieces on his own time, my small parcels of work time, you, Martin, Raymond, Alin, Todd or Nico, we are the openSUSE KDE team.

But we have different goals. Martin wants a rock stable release and warns of regressions. And don't get me wrong, I do see his point even though I do not want to use it. I just don't see the community to create and maintain it or alternatively the commitment by openSUSE to do so. openSUSE people are concerned with the openSUSE release as well albeit not having time to contribute as much as they want to. They enforce the schedule but lack time to contribute – a pretty "funny" situation. Some from the employed "KDE team" seem to work more on other projects or are suddenly away for "more important" work. Not blaming (maybe the management) but just describing my impression. Raymond and Alin AFAIK do not use any stable KDE, maybe not even a stable openSUSE version. I do not use STABLE either but KRxy, i.e. follow upstream, Todd and Nico probably as well. My conclusion is that very few use and contribute to what is stated as the most important target, i.e. openSUSE release KDE version, aka KDF and STABLE. Most follow upstream one way or another and their work just adds to the openSUSE release KDE version as long and if it concurs with the upstream releases.

The aim of KDE:Release:xy repos is to provide packages of the latest upstream stable release, implemented as a snapshot of our development towards the next openSUSE release. What you suggest is the converse of that, but then we can't use KRxy for feature/packaging/new version development without bombarding 'stable upstream release' users with (broken?) updates.

Currently only important upstream patches are added to KRxy in-between upstream releases and apps that are not part of KDE SC updated to stable releases. That's how the official update channel should work as well, updated pnm in order not to annoy upstream etc. Just that it does not happen because backporting and all that double work is needed. If somebody wants to play wild with patches not tested or applied upstream he can create a devel branch of the KRxy package in KDF. Further, KDF might at some point contain betas, KRxy not. KDF might change from one major version to another, KRxy not. So KRxy is far more reliable and predictable than KDF. And KRxy is only left behind after the last upstream bugfix release and if a new stable upstream release is available for openSUSE users. KRxy is the repo which moves forward continuously, i.e. follows upstream. KDF does not. So why would one branch the former from the latter instead of the other way around? Only because of the "openSUSE KDE release". In the end KRxy has to get "unlinked" from KDF at some point anyway, i.e. as soon as the freeze prevents any updates in KDF. If KDF branches from KRxy that problem does not exist and those maintaining KRxy can just go on with their work as usual without having to care about the dos and dont's of an openSUSE release. And I think the current maintenance of KRxy works really well unlike when it was bound to KDF.

The twin-track situation we ended up with just now in 12.2 arises rarely but can be dealt with the same way again (and automated to a greater extent), but there is no need to make it the default. Otherwise this will divert the team's resources away from openSUSE releases and the KDE on those won't be as good.

I'm not sure about that. As lined out on the factory? list, I think that it would be better to not stick to "openSUSE stable" any longer but simply take a snapshot at some point and add KRxy as official update repo. That way all users would benefit from upstream bugfixing and community packaging efforts. If the repo is set to keep some builds instead of just replacing one can even revert in case a major regression sneaked in. "openSUSE stable" is nice in theory but lacks commitment by paid openSUSE employees as you also stated. And IMHO the community contributing to the KDE repos has a different schedule than openSUSE, i.e. upstream. Hence you would force people to work on something they do not use and leave behind as soon as the next upstream release is out. For 12.2 this would have meant to ship KDE SC 4.9.0 and have 4.9.1-.5 as updates as soon as upstream releases them. All time spent on backporting and messing with KDF could be spent on fixing potential regressions. Now you have 4.8 in 12.2. Who of those contributing to the KDE repos uses KR48 or STABLE and hence contributes to it?

I'd suggest making KR49 links to KDF as soon as possible, giving KR49 maintainers rights in KDF and working together there.

I would not want to work on KDF because of the openSUSE schedules. Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

Am Sonntag, 16. September 2012, 20:31:16 schrieb Christian Trippe:

I also want a rock stable release although I am using KDF all the time, but e.g. my wife is using a plain installation without additional repos (except packman of course). And I still would claim this is true for the majority of users. So Martin is not alone with his goal.

I never said that he is alone. I just claim that most people contributing to KDE packaging do not use STABLE etc. And I doubt that the last openSUSE versions were rock solid regarding KDE. Actually, using KRxy people were better off if they use "all" KDE has to offer, e.g. KDEPIM.

I claim you are wrong. I am quite sure nobody will reject a version update for pnm and would want that you only have single backported patches, if you have a good argument for the update. This update simply did not happen because nobody submitted a fixed package. (This of course may be related to your impression about the time of the employed KDE team, which I share. But nothing has stopped you from submitting a updated package on your own.)

This proves my point. The community quickly provided packages for the repos it uses. After that work is done, it's done. There was/is nobody left to submit those packages from KDF to openSUSE – not even the paid staff, e.g. the one who accepted the SR to KDF for pnm, not within weeks until today. Pick your reason, bottom-line is: those SR/updates don't happen. As I stated, I am not willing to go through the extra work which is put on contributors. I contribute to KRxy because IMO that's the repo openSUSE users should use for KDE. One might improve its "security" by keeping old versions of packages allowing user to revert.

...

"openSUSE stable" is nice in theory but lacks commitment by paid openSUSE employees as you also stated. And IMHO the community contributing to the KDE repos has a different schedule than openSUSE, i.e. upstream. Hence you would force people to work on something they do not use and leave behind as soon as the next upstream release is out.

I hope that you are wrong at this point, because if this is true for KDE this is probably also true for many other parts of openSUSE and then the only maintained versions would be Tumbleweed and Factory, which both I would not call stable.

I cannot judge other projects. My impression though is that KRxy repos are stable, in some cases even more stable than STABLE, certainly not less stable. And there are a lot of people who want to contribute to them. Hence why destroy that phenomenon instead of embracing it and supporting them? If there is a need for KDF, that's perfectly fine, use the work done within UNSTABLE and KRxy and improve on it.

I don't want to work on KRxy because I don't think it adds value for the typical user.

That's fine, KDF needs people that submit updates like pnm to the official update channel. Just don't try to force people to work on something they do not want to work on. KRxy has shown that it works very well on its own, not being linked to KDF.

In the end I think you are right with pointing out that within the openSUSE KDE community people have different goals and we have to find a way to work which is the most efficient to reach most of them.

They have already been reached. They work on the projects they use. Just check out KRxy and how well it was established and maintained – almost without any openSUSE staff. There are people updating apps, updating KDE and even submitting important patches from upstream. That's how well the community works – today! The community does work already, just not as the management and those demanding the "openSUSE stable" would like it to. Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

Mandag den 17. september 2012 18:15:49 skrev Will Stephenson:

S2 "KRxy follows a predictable, continuous update policy" S3 "KDF imposes artificial restrictions on tracking upstream" W2 KDF follows the same policy except for a short phase during the end of the release cycle.

Let me propose an alternative, lock-free yet releasable approach where we can all work together:

Give KDF access to proven KRxy maintainers. KRxy(for latest stable KDE x.y) links KDF packages. As soon as the openSUSE release cycle locks the KDE version down, KDF is copied to KDS, and release development (high prio bugfixing) happens in KDS. Any maintenance work for the released openSUSE happens via branches. The team continues to do version updates and upstream patches in KDF and updates links in KRxy until KRxy+1 is released, at which point the old codebase is moved to a new project, same as always.

Sounds like a very good idea that should fit everyone's needs. The challenge is just to make anyone care about KDS for the two month freeze period every eight (12?) months. Of course caring about KDS would also imply caring about what's best for the openSUSE project, the openSUSE distribution, KDE and end users more than version numbers, so it's an uhill battle.

S4 "KDF might ship a beta" W4 Highly unlikely at this stage in the KDE 4 cycle, really. When we do ship KDE5 beta it will be from a different devel project, we'll keep stable KDE4 as a default.

Say 12.3 will be released in March with 4.10, there would be very little time to test 4.10 if 4.10beta wasn't allowed in KDF. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

Am Montag, 17. September 2012, 19:54:41 schrieb Will Stephenson:

On Monday 17 Sep 2012 19:38:19 Martin Schlander wrote:

...

The challenge is just to make anyone care about KDS for the two month freeze period every eight (12?) months. Of course caring about KDS would also imply caring about what's best for the openSUSE project, the openSUSE distribution, KDE and end users more than version numbers, so it's an uhill battle.

Indeed. Either it stays the way it is now, shifting repos a bit here and there will not change anything, then participation will stay the same. The same for KDS, KDF and KRxy (if it's not just links). Or "what's best for the openSUSE x" changes. As noted many times I disagree that KDS is best for end users but a relict from the SuSE times when a paid KDE team existed and had to care about backporting etc. IMO upstream bugfix releases are best for end users.

Should only be one month according to the original 12.2 cycle: http://turing.suse.de/~coolo/opensuse_12.2/ And unless that period straddles an upstream .y release, it should be the same cherrypicking upstream patches work that KR49 will be doing anyway. So not so much different from just tracking upstream.

It is different because you have to care about cherry picking for KDS on top of working within KDF or KRxy, update links etc. People could have contributed (and probably did) to KDS via SRs in the past. I do not see a reason why contributions to that repo would suddenly increase. You can try to force contributors to work on KDS, either morally pointing to the users who want the so called "rock solid openSUSE" or by doing away with repos, but I doubt that people will change their habits since they picked them for a reason.

...

Say 12.3 will be released in March with 4.10, there would be very little time to test 4.10 if 4.10beta wasn't allowed in KDF.

I expect the release schedule and overall strategy for 12.3 will change following the discussions on -project and at osc. But if it hypothetically didn't, comparing the 4.9 and 4.10 schedules http://techbase.kde.org/Schedules/KDE4/4.9_Release_Schedule http://techbase.kde.org/Schedules/KDE4/4.10_Release_Schedule the overlap between 4.10 beta 1 (the first one we could put in KDF) and 4.9.4 (final) is 2 1/2 weeks. We could delink KR49 early, around Nov 15, and then update to 4.9.4 directly in KR49 (the amount of changes by then is going to be modest), other suggestions? I suspect by then Sven will start finding the new stuff in 4.10 branch interesting to work on.

I don't understand this. If I understood Martin correctly he asks about testing 4.10 before it gets shipped as part of the openSUSE release. And I guess he fears that there will be bugs because of the immature 4.10. Hence there is a risk in shipping that KDE version with the 12.3 openSUSE release. This means that either backporting all sorts of stuff is needed (won't happen IMHO) or only major bugs are fixed until the following upstream bugfix release and the latter is shipped as normal update to openSUSE users. In the latter case users who think that whatever KDE version was shipped with openSUSE is not stable enough simply wait until the more stable KDE release is available via the update repo. To sum-up: I would have to agree that shipping 4.10 with 12.3 is not a very good idea with the current philosophy of "openSUSE stable". Only if all upstream bugfix releases are shipped as official updates it makes sense to ship an immature 4.10.0 instead of a mature 4.9.4/5. Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

I wrote a lengthy reply but in the end it did not make sense to me to repeat my arguments. Thus I will try to keep it short and summarise the answers: If there is no openSUSE KDE team employed at openSUSE we should get rid of most of http://en.opensuse.org/openSUSE:KDE_team since reading things like "SUSE employees working mainly on maintaining and extending KDE for openSUSE and SUSE Linux Enterprise:" or even "And from other SUSE teams:" triggers wrong hopes if one wants to put it nicely. -"You" are the community: as part of that I vote for getting rid of "openSUSE stable" since it does not work anyway the way it is supposed to. I did mention that opinion in the thread on factory, that's my vote. -Contribution: I do not see how shifting around a few repos will suddenly increase contribution to e.g. KDS. People could have done that in the past via SRs already. One might argue back and forth about whether "real" commitment includes the willingness to deal with osc, i.e. the command line. IMHO those that are willing and able to use osc do so already. Having a GUI lowers the hurdles to contribute. Yet anything related to linking is not maintainable with the webgui. In the past, doing a SR and others updating the link after accepting the SR, did not work well. Whatever repo consists of links will suffer compared to the "real" repo. KR48 has proved this in the past, I do not see why it should be different with KR49. -Other desktops' teams provide stable releases: That might be the case, I only use KDE and hence cannot comment on the stability and update policy of other DEs. As long as they follow "openSUSE stable" instead of "upstream stable", i.e. shipping all bugfix releases as regular updates, they are on a different schedule than the one I support. Other distros do ship bugfix releases and are also successful. I was told that a fixed set of bugs is better than shipping dozens of bugfixes with the potential danger of a regression as update – even if the latter would get fixed within a reasonable amount of time and the possibility to revert until the regression is fixed. I do not agree with that. For me a stable openSUSE consists of the base system and a repo with the latest minor upstream KDE release. That's the stable release I want to contribute to. KDS is not stable for me but simply frozen and kind of unmaintained. -Without KDF there would be no room for large packaging changes etc.: I'd assume that this kind of change does not happen within the schedule of minor upstream releases, i.e. it would happen in KUSC and not KRxy. -There is no evidence that KDF worked worse than KR49 does now and you have not experienced any nasty issues in KR49 yet: I mentioned the pnm example. People submitted the update to KDF it was accepted but never made it to the user, because there is an extra mile which not even the paid employee did want to go. In KRxy the new pnm was submitted, got accepted and shipped to the user. There were some packages broken in KDF for weeks or e.g. calligra not updated for months. KR49 is not worse than that but rather better. KR48 had similar issues as KDF because links were not updated. Sure there could be some nasty issues in the future, but "KDF SR to official update" even failed for simple issues. And my claim is that most people concentrate on one repo + a few extra packages here and there. But not KDS + KDF + updating links to KRxy, always switching back an forth updating a link here, doing a backport there, making sure it gets into the official updates etc. Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On Tuesday 18 Sep 2012 12:20:01 Markus wrote:

Am Montag, 17. September 2012, 18:15:49 schrieb Will Stephenson:

...

There hasn't been an 'employed "KDE team"' since all the desktop teams were rolled up into the Boosters team. We were all doing KDE (or GNOME for that matter) stuff, more or less successfully, on the side of our Boosters projects. After 2 years, nobody thought the team as a whole was working so it's now been made clear by management that with the exception of essential 'release engineering' the team will work together on making openSUSE cool, whether it's release PR, events, or big picture engineering, and stuff like packaging desktops is a job for the community.

So, this means that Kubuntu and ROSA Linux are the last two distributions with paid KDE personnel?

Define 'paid KDE personnel'. A full time KDE engineering team? Employees with @kde.org? Redhat have Lukas Tinkl, Jaroslaw Reznik, Than Ngo. I'm not sure whether they all work 100% on KDE. Blue Systems (Bitrunner, based on Kubuntu ) have Alex Fiestas, Jonathan Riddell, Aurelien Gateau, Vishesh Handa, Aleix Pol, Harald Sitter, Rohan Garg, Jonathan Thomas at least. They seem to be aiming to do a benevolent desktop polish play based on 'doing Kubuntu right'. Dunno anything about ROSA. And 'big picture engineering' in my list will include some KDE projects, and that will include the openSUSE team, not just me. Will -- Will Stephenson, openSUSE Board, Booster, 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 Tuesday 18 September 2012 14:27:58 Luca Beltrame wrote:

Thus, I'd argue for cooperation of everyone with their limited time rather than pointing out the differences in employment status and supposed devoted time vs leisure time: united we stand, divided we fall.

Together with Luca, I want to pull the emergency break on this discussion. It seems that this type of heated discussions are becoming a common thing on the opensuse mailinglists and I rather see that we spend this time on something usefull. After reading the full discussion I believe that both Sven and Will brought in some good points. As Sven indicated I also have my doubts if KDE:Distro:Stable is really being used by anybody. It just contains the KDE version that was shipped with the latest openSUSE version and then compiled for all the supported openSUSE version. I doubt that this is really a maintained repo and I would rather see that this repo is replaced with one of the KR:xy repo. The usage of KDF is out of the question for me. This IS and WILL ALWAYS be the development repo to support the KDE version in the next openSUSE release. However if we start utilizing the KR:xy repo's correctly and keep them up-to- date with the monthly minor releases, then KDF doesn't require to be build against the 11.4, 12.1, 12.2 repo's. KDF could just be build against Factory as that this is the one that matters. However as a process we should establish that once the new openSUSE release is announced, we as the community team should indicate what our target is for the KDE release. So for 12.3 we should already now indicate whether we target KDE 4.10 or KDE 4.9.5. Then we eliminate the discussions just before the feature freeze, but have them already early in the process. KUSC has always been the repo where we look forward to the next release of KDE. With it's weekly snapshots it is possible to follow closely the developments on the new KDE Release, but also to react when new packages are defined or when existing packages are split in multiple (last example the move of KDEGAMES to git and being split into about 15 separate packages). Sven is right that people will always tend to spend their time on the area/repo that they are using as that changes there directly affects them. So we should utilize this and make it work for us, instead of seeing it as a bad thing. Maybe it would also be a good idea to assign a kind of coordinator per repo ? (e.g. One for KDF, one for KUSC and one for the KRxy repo's). I know that I haven't been a big help in the area of KDF maintenance, but as Luca indicated all the volunteers have only a certain amount of time that they can spend. I have been focussing on Plymouth and Chromium for 12.2 and tried to keep KUSC as up-to-date as possible, Let's been supportive of eachother !! In the past the KDE community team managed to accomplish a lotand it would be a real shame to see this go to waste. Raymond -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

Am Dienstag, 18. September 2012, 16:38:23 schrieb Luca Beltrame:

In data martedì 18 settembre 2012 15:12:18, Raymond Wooninck ha scritto:

...

As Sven indicated I also have my doubts if KDE:Distro:Stable is really being used by anybody. It just contains the KDE version that was shipped with the Working with stats in my day job, I ask: can we get some numbers out of usage of KDS versus KRxy? That would probably help in making a decision.

AFAIK there are only download numbers and nobody really knows what they mean, i.e. they could depend on the number of updates in a repo rather than its number of users, certainly the number of packages etc. The only thing I would boldly state from those numbers is that KUA is _very_ popular and hence indicates that people do want updates that openSUSE does not offer in their official update repo. KUA has only a small number of packages compared to other KDE repos. So if one would divide the number of downloads by the number of packages (assuming there is a relation), its usage would become even more impressive. KUA is part of the community repo list, i.e. easy to add. I wonder were KRxy usage would be if it was as easy to add as KUA. 27966773 KDE:Extra::openSUSE_12.1 21854756 KDE:UpdatedApps::openSUSE_12.1 2485050 KDE:Extra::openSUSE_11.4 2560126 KDE:Release:48::openSUSE_12.1 2127425 KDE:Release:49::openSUSE_12.1 2124572 KDE:Release:49::openSUSE_12.2 2026886 KDE:Extra::openSUSE_12.2 1870427 KDE:UpdatedApps::openSUSE_11.4 1625850 KDE:Distro:Stable::openSUSE_12.1 1569690 KDE:Release:47::openSUSE_12.1 1263681 KDE:Extra::KDE_Release_48_openSUSE_12.1 1119764 KDE:UpdatedApps::openSUSE_12.2 827931 KDE:Distro:Factory::openSUSE_12.1 http://www.suse.de/~coolo/repo.list http://en.opensuse.org/openSUSE:Statistics might help to estimate the number of potential users.

...

So for 12.3 we should already now indicate whether we target KDE 4.10 or KDE 4.9.5. Then we eliminate the discussions just before the feature

As part of upstream, I think it's not just a discussion of simply "newer but untested" and "older but tested". I say so because on the KDE Forums we have a fair share of Debian users which are locked on "prehistoric" versions and suffer bugs that are long fixed upstream.

You misunderstand them! They are using a rock-solid KDE version! :|

On the other hand, of course, there may be rough edges in a newer release that may be unnecessarily pushed onto users.

.0 maybe – but since users are free to chose when to update/upgrade they can wait until e.g. 12.3 gets KDE 4.10.2 or even until it gets to .4.

- Are there any known regressions?

This is something upstream has to take part. Either upstream complains about users reporting old bugs because of using old KDE versions or they prioritise regressions and hence make them a non-issue. The latter would help downstream to ship KDE updates. Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

Hi KDE team members I would like to organize an openSUSE KDE team again, to discuss two changes that are having an impact on our old way of working. The biggest change is the new organization within SUSE and that we no longer have dedicated KDE team members (particular Will). This requires us to be organized a bit different and it would be good to discuss this. The other change is the current ongoing discussion with regards to the KDE repositories. In the light of Tumbleweed, the new Maintenance process for openSUSE releases, etc, we need to validate the usage of the current repositories and how we want to continue. Therefore I would like to propose a proper KDE team meeting with the following agenda: 1) Team organization. + Election of an Overal Team Coordinator + Election of a responsible person per repository. + .. 2) KDE repositories + What do want to achieve and how + development workflow for new openSUSE releases + Targetted KDE version for openSUSE 12.3 + Improvement points for KDE in openSUSE 12.3 + .. 3) ...... Proposal for a date would be either Wednesday 26 September 14:00 UTC or Thursday 27 September 14:00 UTC Please send me a personal email which date is most suitable for you. I will then organize it. Also I will update our meeting wikipage with the above agenda so that people can add to it. Looking at the past the team has achieved a lot and I believe that we are in a very good position as that the team itself has members that are focussed on the current versions, but also has members that are looking already at the upcoming release. In the past Will has done a great job in coordinating all our activities and being our voice within SUSE. Now it is our turn to get our confidence back together and start acting as a team to make KDE even better in 12.3 and to provide a better KDE experience for those users that wants a newer KDE version, without the hassle of upgrading the whole system. I know that we can achieve this if we set our minds to it. Regards Raymond -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On Tue, 18 Sep 2012 20:46:45 +0200 Luca Beltrame wrote:

Since 4.6 we have dedicated "beta" forums which I or the other staff members open when the first beta hits the mirrors and close when the final release is out.

Unfortunately the last two iterations yielded poor participation: ...

Open-close could be one of reasons for poor participation. People that test software like that, and depriving them from fun will push them elsewhere. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

Am Dienstag, 18. September 2012, 20:37:04 schrieb Sven Burmeister:

Am Dienstag, 18. September 2012, 16:38:23 schrieb Luca Beltrame:

...

In data martedì 18 settembre 2012 15:12:18, Raymond Wooninck ha scritto:

...

As Sven indicated I also have my doubts if KDE:Distro:Stable is really being used by anybody. It just contains the KDE version that was shipped with the

Working with stats in my day job, I ask: can we get some numbers out of usage of KDS versus KRxy? That would probably help in making a decision.

AFAIK there are only download numbers and nobody really knows what they mean, i.e. they could depend on the number of updates in a repo rather than its number of users, certainly the number of packages etc.

The only thing I would boldly state from those numbers is that KUA is _very_ popular and hence indicates that people do want updates that openSUSE does not offer in their official update repo. KUA has only a small number of packages compared to other KDE repos. So if one would divide the number of downloads by the number of packages (assuming there is a relation), its usage would become even more impressive. KUA is part of the community repo list, i.e. easy to add. I wonder were KRxy usage would be if it was as easy to add as KUA.

27966773 KDE:Extra::openSUSE_12.1 21854756 KDE:UpdatedApps::openSUSE_12.1 2485050 KDE:Extra::openSUSE_11.4 2560126 KDE:Release:48::openSUSE_12.1 2127425 KDE:Release:49::openSUSE_12.1 2124572 KDE:Release:49::openSUSE_12.2 2026886 KDE:Extra::openSUSE_12.2 1870427 KDE:UpdatedApps::openSUSE_11.4 1625850 KDE:Distro:Stable::openSUSE_12.1 1569690 KDE:Release:47::openSUSE_12.1 1263681 KDE:Extra::KDE_Release_48_openSUSE_12.1 1119764 KDE:UpdatedApps::openSUSE_12.2 827931 KDE:Distro:Factory::openSUSE_12.1

I personally think that the great usage of UpdatedApps comes from the fact that people want to use some newer releases of some applications but don't want to risk or don't neat a newer release of the Desktop enviroment. (Maybe this assumption is drawn form the fact that I started like this to use non-official repos.) However looking at a IMHO typical user, who uses -Firefox for the web -Thunderbird for emails there is probably not much reason to update the SC, but he still may wish to have a newer amarok or kile. Christian -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

In data martedì 18 settembre 2012 16:56:37, Martin Schlander ha scritto:

Does that imply you also want to ship KRxx as official updates to the distribution?

I don't think it would be a wise choice. For updates I would not use anything else than the official update channel.

Or does it mean you don't want to have a place to test official KDE patches at all?

Isn't that a place for KDF?

Maybe with the staging stuff o:F will become less painful - but currently you need to be a real masochist to use o:F for 5-6 months of the 8 month

Such people are plenty around. ;)

I think Will's proposal (always summer in KDF, branch to KDS when o:F freezes) did that very well.

As I said before, only (possibly) hard numbers will tell us more about the state of KDS. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79

On Tue, Sep 18, 2012 at 05:06:30PM +0200, Luca Beltrame wrote:

In data martedì 18 settembre 2012 16:56:37, Martin Schlander ha scritto:

...

Does that imply you also want to ship KRxx as official updates to the distribution?

I don't think it would be a wise choice. For updates I would not use anything else than the official update channel.

Then do what everyone else does, use Tumbleweed, which I put the KDE releases into all the time. That's one of the main reason people like using Tumbleweed, or so they tell me :) thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

Tirsdag den 18. september 2012 20:14:00 skrev Sven Burmeister:

Am Dienstag, 18. September 2012, 16:56:37 schrieb Martin Schlander:

...

Does that imply you also want to ship KRxx as official updates to the distribution?

Meaning that every casual non-KDE fanboy user - including my mother - would be burdened with 500 megs of updates every 2-4 weeks with regressions and changed behaviour - unless of course the user stops using openSUSE and/or KDE.

This would only be true if updates would be forced on users. Yet as they are optional it is every users' choice to update or not. openSUSE would just change the default from "hardly any updates at all because nobody backports" to "regular bugfix releases".

You can lock one or two packages, after that it becomes unmanagable. And you might as well fight with the regressions as fighting against the updates - or just switch to an OS that intends to let you be productive.

Same old, same old killer argument about regressions. When was the last one

I for one lost ffmpegthumbnail support in Dolphin with the 4.8.5 update which is rather annoying, and cost me at least 30 minutes of troubleshooting. KWin (Aurorae) had some bad ones very recently causing a flood of support queries in #kde and #suse. Also I guess you have some filter which hides all the e-mails to this list starting with "After the last update..." or similar. And it's not just the fact that upstream code always has some regressions - big or small - there's also the packaging level with dependency issues and other packaging bugs.

and what did it take to fix it?

It's already too late at this point. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On Wed, 19 Sep 2012 10:32:35 +0200 Nico Kruber wrote:

openSUSE:Update uses delta RPMs so it shouldn't be that big

Note that delta rpm saves for sure only on a download traffic, nothing else. As it is now, it will reassemble rpm right after a download, which with slower machines can take some time, keeping computer busy with update longer then plain rpm. So far I understand, process is: * download delta to temp copy on a disk, * load previously saved rpm, * apply delta, * save new rpm for installation and later updates. Even if it is using RAM as much as possible disk IO is bottleneck that didn't improve much in last 10 years on consumer class computers. When we update package that was never updated we don't have a copy on disk, so we have to use plain rpm file. Deltas can kick in on next update, which may, or may not happen. In other words savings that delta rpm offers are not that big in a practice. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On Wed, 19 Sep 2012 18:13:27 +0200 Nico Kruber wrote: ...

I'm not sure if copies of all installed rpms are stored on disk, but at least after the last step, the old rpm can be deleted

Default is not to keep rpm files, but as I can find some in older installation with a lot of updates, it seems that it keeps last version for delta rpm process. General default can be changed, but it is: * not obvious how to do that, * not advertised as an option to save bandwidth. Majority of users will leave default. Even those that can profit from smaller downloads, like people with ISPs that sell metered connection with download caps. (One good thing out of this discussion is that I'll update http://en.opensuse.org/SDB:Installation group of articles with this) ...

You must have a very slow computer and a very fast broadband connection not to benefit from delta rpms for packages over a certain size.

As you state, it is all relative to what you have, so besides sure gain eg. saving SUSE some money that can be used elsewhere, there is no good approach for everybody.

... I assumed that "burdened with 500 megs of updates every 2-4 weeks" means traffic - anyway,

It means discomfort: * Lower bandwidth left for other activities, * Servicing package management application requests: licenses, solving package selection problems, broken network connection problems, etc. so it is good to avoid it in order to get more users aboard.

used space on the HDD should be rather constant after having the package installed once

Right, although from my perspective HDD is not worth to think about. Some people are sensitive on size of installation, but that is either memory leftover from old times when HDD was a limitation, or special needs installation on a small media. Neither is relevant to mainstream use cases that Martin mentioned.

Nico

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

On Thu, 20 Sep 2012 10:57:42 +0200 Nico Kruber wrote:

I still don't know exactly, how this delta rpm process works.

Me neither; which is obvious when you read: http://doc.opensuse.org/documentation/html/openSUSE/opensuse-startup/cha.sw_... and /usr/share/doc/packages/deltarpm/README Without your question I would think that my experience with deltaiso is sufficient. For deltaiso utility you needed old.iso and delta.iso to create new.iso. I extrapolated that on delta rpm process, which is not wrong, but not complete either. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

Onsdag den 19. september 2012 12:42:52 skrev Sven Burmeister:

The number of regressions is far smaller than the number of fixes. Or to put it the other way around, there are less regressions in an update than bugs in the shipped version. And more importantly, regressions get fixed, shipped bugs not.

The whole point is that the regressions do much more harm, than the fixes do good (to non-fanboy users trying to be productive with KDE). -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On Wednesday 19 Sep 2012 17:51:36 Luca Beltrame wrote:

In data mercoledì 19 settembre 2012 16:45:07, Martin Schlander ha scritto:

...

The whole point is that the regressions do much more harm, than the fixes do good (to non-fanboy users trying to be productive with KDE).

that depends on the regression or the bugfix - there are a lot of nasty bugs, e.g. in kdepim, which do harm in a way, that if people need to suffer too much they simply switch to another application

Keeping better in touch with upstream will at least reduce their impact on the userbase. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On Wednesday 19 Sep 2012 17:51:36 Luca Beltrame wrote:

P.S.: Can we avoid terms like "fanboy"?

Or we can set offensive terms them as our official jargon to refer to our user market segments. It will convince casual readers that we are complete assholes and stop them adding noise to productive discussions. I propose the following segmentation (British humour alert!): "Cold-Dead-Hands" - Users with an instinctive hatred of anything new we do. Doesn't consider an openSUSE version stable until the following release has superceded it, then complains about the length of maintenance. Still upgrades every 8 months like everyone else. "Stable Sheep" - Installs a new release, removes PackageKit, Apper and PulseAudio then only updates Firefox and Thunderbird and KDE:ExtraApps until the next release. "KDE Fanboy Version Whore" - Wants the latest upstream stable release on the same morning the release is announced. May perform cybersex acts to get it. "Bleeding Gits" - Anything not from master is obsolete but kdesrc-build is too scary. Spends 4 hours a day pulling rebuilds from OBS, 4 hours a day troubleshooting broken IM clients and browsers on IRC, 4 hours on bugs.kde.org, goes to bed and repeats the next day. Bugzilla.novell.com is beneath them. Joking aside, the way to win this discussion with the maximum number of satisfied users and hence the most potential contributors to improve things, is to recognise that our users have different demands on us. Cold-Dead-Hands will never be happy, the best thing to do is politely ignore their complaints. Bleeding Gits satisfy their own needs. If we can find a way to keep the two middle groups fed without burning ourselves out with work so we have time to fix the odd bug and innovate to make openSUSE interesting and relevant, we're good. Will -- Will Stephenson, openSUSE Board, Booster, 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 Tuesday 18 Sep 2012 23:47:49 Markus wrote:

...

Meaning that every casual non-KDE fanboy user - including my mother - would be burdened with 500 megs of updates

The size can (and should) be significantly reduced by blocking rebuilding artwork packages. No need to ship unchanged wallpapers and icons.

AFAIK the problem is that we package tarballs of artwork and icon packages that have new version numbers, and that's enough to make the package differ. We could just diff the package contents and not update those packages at all. WIll -- Will Stephenson, openSUSE Board, Booster, 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 Tuesday 18 Sep 2012 21:14:55 Christian Trippe wrote:

Am Dienstag, 18. September 2012, 15:12:18 schrieb Raymond Wooninck: So one idea might be to declare the KRxy repo with the the openSUSE release KDE version as a KDE devel project for that openSUSE version and submit updates to the official update repo from there.

+1

If this happens there are IMHO two things to discuss: 1.) Should every minor update of the KDE SC be released as an official update? Personally I would say that the last minor update should be mandatory and everything else could be dealt with on a case by case basis.

+1

2.) How to deal with packages not being part of KDE SC, e.g. amarok? Here my personal opinion would be that as KRxy would be used as a devel project also only bugfix release should be allowed.

That is easier said than done, because e.g. amarok and digicam don't really offer bugfix releases - during the last official releases, not only bugfixes were introduced, but also new features. Since a potential bug only influences that particular application, it is not as big of a deal as a bug in a kde lib or kwin etc... This is similar to the Firefox,Thunderbird release cycle for which new versions are also shipped in openSUSE:Update.

Here I would agree with Martin that KDF should still be build also for older releases

If so, I'd suggest to only build for the latest release (currently 12.2) + Factory to keep build server use down Nico -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On Wednesday 19 Sep 2012 12:22:15 Sven Burmeister wrote:

Am Mittwoch, 19. September 2012, 10:47:18 schrieb Nico Kruber:

...

Since a potential bug only influences that particular application, it is not as big of a deal as a bug in a kde lib or kwin etc... This is similar to the Firefox,Thunderbird release cycle for which new versions are also shipped in openSUSE:Update.

If you enable the repo to keep the last x built rpms users can revert as they can now with the updates from the official repo.

This is actually something that I came around several times now: I updated multiple packages and something stopped working but I wasn't able to revert to the previous ones (it should be possible with btrfs but this is still unstable). Only 2 options are available now: 1) revert to distro versions 2) live with the bugs Some more elegant way to revert to (any previous) version should be available though as the first option is rather inconvenient. Take X11:XOrg for example: I have been using the repo on 12.1 but several packages have been split or newly introduced in that repo. Switching back without leaving packages from X11:XOrg was only possible manually and is not that comfortable! This is something we should request from the zypper team though - leaving old build packages in the repo (or some sort of repo snapshots) is just one part of the deal... Nico -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On Wednesday 19 Sep 2012 13:01:15 Sven Burmeister wrote:

Am Mittwoch, 19. September 2012, 12:37:39 schrieb Nico Kruber:

...

This is something we should request from the zypper team though - leaving old build packages in the repo (or some sort of repo snapshots) is just one part of the deal...

The update repo contains multiple builds of the same package version and multiple versions of the same package. So this is possible already, yet I do not know how.

Alternatively we could add something to the version if the KDE update repo is updated, i.e. something like KDE 4.9.1.1 and the next time links are updated 4.9.1.2 etc. If 4.9.1.1 does not allow 4.9.1.2 reverting one package should drag the rest with them.

Of course a more convenient solution would be better but as long as there is no need it will not be created.

I was thinking about a simple button in the web UI allowing me to snapshot a whole (completely build and published) repo so that all currently published packages are left even in case of rebuilds. Also something like a one-click- install installing (up/downgrading) packages to exactly those versions Nico -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On Wednesday 19 Sep 2012 21:07:05 Christian Trippe wrote:

Am Mittwoch, 19. September 2012, 10:47:18 schrieb Nico Kruber:

...

On Tuesday 18 Sep 2012 21:14:55 Christian Trippe wrote:

...

2.) How to deal with packages not being part of KDE SC, e.g. amarok? Here my personal opinion would be that as KRxy would be used as a devel project also only bugfix release should be allowed.

That is easier said than done, because e.g. amarok and digicam don't really offer bugfix releases - during the last official releases, not only bugfixes were introduced, but also new features.

Since a potential bug only influences that particular application, it is not as big of a deal as a bug in a kde lib or kwin etc... This is similar to the Firefox,Thunderbird release cycle for which new versions are also shipped in openSUSE:Update.

Sure I know this. It was more a meant like this: If you want to use KR:xy as a devel project for updates for an openSUSE release you should only update, e.g. amarok in this repo, if you really are fine to release this also as an online update. Otherwise this workflow will not work for non SC packages.

I'm not quite sure of the update workflow - I did however see an Update:Test repo - but I don't know exactly what purpose it has My guess was that the devel project submits to this repo and then after testing, eventually it gets released as an update

I agree with you that as this only effects one specific application and is easily to revert one can probably accept it. But it is IMHO also more likely to cause new bugs when doing this, see e.g https://bugzilla.novell.com/show_bug.cgi?id=780628 for an amarok 2.6 bug on plain 12.2 which is not there with 2.5. So maybe a general rule of thumb how to handle this non-SC apps would be good.

I see... those interdependencies are bad and need to be aware of (I saw that there were some notes in the release notes about the new gstreamer fixing some bugs though) But you are right: the applications are only tested in the particular environment, i.e. in this case KR49. So in terms of testing updates before releasing them, it is better to ship the whole repo contents as updates instead of single apps unless these updates are tested again with a plain openSUSE(:Update) repo, e.g. in Update:Test. Nico -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On Wednesday 19 Sep 2012 21:07:05 Christian Trippe wrote:

Am Mittwoch, 19. September 2012, 10:47:18 schrieb Nico Kruber:

...

On Tuesday 18 Sep 2012 21:14:55 Christian Trippe wrote:

...

2.) How to deal with packages not being part of KDE SC, e.g. amarok? Here my personal opinion would be that as KRxy would be used as a devel project also only bugfix release should be allowed.

That is easier said than done, because e.g. amarok and digicam don't really offer bugfix releases - during the last official releases, not only bugfixes were introduced, but also new features.

Since a potential bug only influences that particular application, it is not as big of a deal as a bug in a kde lib or kwin etc... This is similar to the Firefox,Thunderbird release cycle for which new versions are also shipped in openSUSE:Update.

Sure I know this. It was more a meant like this: If you want to use KR:xy as a devel project for updates for an openSUSE release you should only update, e.g. amarok in this repo, if you really are fine to release this also as an online update. Otherwise this workflow will not work for non SC packages.

I agree with you that as this only effects one specific application and is easily to revert one can probably accept it. But it is IMHO also more likely to cause new bugs when doing this, see e.g https://bugzilla.novell.com/show_bug.cgi?id=780628 for an amarok 2.6 bug on plain 12.2 which is not there with 2.5. So maybe a general rule of thumb how to handle this non-SC apps would be good.

As well as regressions, minor version updates outside the SC can be problematic because apps like amarok and digikam sometimes introduce new dependencies for their new features, which is a harder thing to persuade maintenance to accept. Also consider that our users who use the original KDE version shipped with a given openSUSE release and don't upgrade using KRxy are typically a lot more sensitive to regressions than our version whores are. Will -- Will Stephenson, openSUSE Board, Booster, 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

Am Mittwoch, 19. September 2012, 11:12:37 schrieb Nico Kruber:

So, at the moment, it would be important to fix every package in KR49 to be a (fixed) link to KDF. Development would then only happen in KDF and KR49 links will be updated after a new KDE 4.x release, right?

Just that people keep it in mind: It is not possible to manage links with the webgui. So everything resulting from links will have to be done by those that use osc. Or to put it differently. Using links increases the burden to participate and hence decreases the number of potential contributions. Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On Wednesday 19 Sep 2012 12:31:13 Sven Burmeister wrote:

Am Mittwoch, 19. September 2012, 11:12:37 schrieb Nico Kruber:

...

So, at the moment, it would be important to fix every package in KR49 to be a (fixed) link to KDF. Development would then only happen in KDF and KR49 links will be updated after a new KDE 4.x release, right?

Just that people keep it in mind:

It is not possible to manage links with the webgui.

to some extend it is... not the work needed above though (or at least not as simple as via osc)

So everything resulting from links will have to be done by those that use osc. Or to put it differently. Using links increases the burden to participate and hence decreases the number of potential contributions.

that's no problem for the occasional users as they shouldn't fiddle with links other than their own branches. The important thing though is that development only happens in one repo and users know where to branch from / submit to in order to keep our overhead low. Nico -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On Wednesday 19 Sep 2012 11:12:37 Nico Kruber wrote:

So, at the moment, it would be important to fix every package in KR49 to be a (fixed) link to KDF.

Yes.

Development would then only happen in KDF and KR49 links will be updated after a new KDE 4.x release, right?

After a new KDE 4.9.z release, yes. After 4.10 comes out KR49 will be finished, and we dereference KR49 by copying the KDF contents there.

Intermediate patches in KR49 should only be accepted on a per-case basis.

Agreed, like with the KWin hang bug in 4.9.0 Will -- Will Stephenson, openSUSE Board, Booster, 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