[opensuse-kde] Missing package/update in KDF
Hi, after the updated of KDF to KDE 4.9.1 I noticed that translations were not updated and are still at 4.8.5. Also the calligra-doc package is missing, it already exists in Factory and 12.2. This only needs to be a link to the calligra package AFAIU. Regards, Christian -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Am Samstag, 15. September 2012, 09:50:55 schrieb Christian Trippe:
after the updated of KDF to KDE 4.9.1 I noticed that translations were not updated and are still at 4.8.5.
Also the calligra-doc package is missing, it already exists in Factory and 12.2. This only needs to be a link to the calligra package AFAIU.
KDF also still holds calligra 2.4.3 while KR49 already has 2.5.1 and 2.5.2 as SR. Just switch to the community maintained KR49. KDF is just too bound to the openSUSE releases, i.e. freezes for "openSUSE stable" etc. When working on KDF you have to keep all these things in mind and even have to "stop" working on it when a freeze comes up. For KRxy you just have to stick to upstream stable and release plans. For the next openSUSE release, KDF can pull a snapshot of KRxy some days before the freeze. IMHO that makes more sense than KRxy pulling from a repo which stops being current at some time. KDF is just the "openSUSE release branch" of KRxy. Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Saturday 15 Sep 2012 12:38:45 Sven Burmeister wrote:
Am Samstag, 15. September 2012, 09:50:55 schrieb Christian Trippe:
after the updated of KDF to KDE 4.9.1 I noticed that translations were not updated and are still at 4.8.5.
Also the calligra-doc package is missing, it already exists in Factory and 12.2. This only needs to be a link to the calligra package AFAIU.
KDF also still holds calligra 2.4.3 while KR49 already has 2.5.1 and 2.5.2 as SR.
This is just an oversight - until now we've been too busy on the 12.2 release to update KDF, which was (like openSUSE:Factory) in limbo since 12.2 was forked and we put the final touches to KDE packages in KDS.
Just switch to the community maintained KR49.
KDF is just too bound to the openSUSE releases, i.e. freezes for "openSUSE stable" etc. When working on KDF you have to keep all these things in mind and even have to "stop" working on it when a freeze comes up. For KRxy you just have to stick to upstream stable and release plans.
For the next openSUSE release, KDF can pull a snapshot of KRxy some days before the freeze. IMHO that makes more sense than KRxy pulling from a repo which stops being current at some time. KDF is just the "openSUSE release branch" of KRxy.
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. 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. 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'd suggest making KR49 links to KDF as soon as possible, giving KR49 maintainers rights in KDF and working together there. 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 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, 13:11:12 schrieb Sven Burmeister:
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.
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.
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.
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.)
"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.
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.
I don't want to work on KRxy because I don't think it adds value for the typical user. 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. I am not so active lately that I could tell what is the best approach for this. Christian Ps: I actually did not want to start such a thread but simply point out some oversights with regards to KDF. -- 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
On Sunday 16 Sep 2012 13:11:12 Sven Burmeister wrote:
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.
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. This shouldn't come as a shock to you - in fact, while we were called the Boosters Team, I justified my KDE work to managers as saying it was essential heavy lifting to support a working community team. However I fear that by doing so much, we inhibited an independent community team from forming to work on KDE for openSUSE releases, so everyone got used to doing their personal luxury contributions without any constraints.
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.
Even if your conclusion is correct, which I doubt - the point I tried to make is that you* are the openSUSE community so you get to agree and set the targets and the policy that determines "openSUSE release KDE version". Look at how Dominique (community) just got made part of the checkin team, enforcing the schedule. Look at the discussion that is happening on opensuse-project@ about schedules and development and you'll see that variations on the release schedule that would allow more flexible version updates and more frequent releases are being discussed and refined. If you're not part of that discussion, others (who you are just as well qualified as) will shape those decisions. There's no need to go from where we are now to being a dissident Kubuntu to "openSUSE"'s Ubuntu. If you are content to tinker away in the KDE: namespace without caring about schedules, keep in mind that other desktops' community teams will happily work together provide a stable release and maintain it and KDE will be relegated to being an alternative option. * I include myself in 'the openSUSE community' but write 'you' instead of 'we' - as an individual I'm in the minority.
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.
So if I may paraphrase and answer you point by point:
S1 "KRxy is an alternative stable update channel because official updates are
restricted by lack of resources"
W1 The work you're doing is exactly what would be needed for official updates.
Do it in our devel repos and link it to KRxy and everyone wins. Or play at
project level instead of KDE: and get the maintenance policy changed.
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.
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.
Conversely, doing development work directly in KRxy limits you to not doing
any significant packaging changes, eg to track upstream changes such as the
kdegames move to git. You want to be able to leave it publish-enabled so you
and others can test your own work easily, but you don't want to have the
responsibility of not being able to break things while working. As soon as you
want to work on something that affects >1 package, you have to make a devel
branch and you're effectively the same as
S5 "KRxy maintenance works better that it did when linked to KDF"
W5 I don't see evidence to support this claim, and anyway you haven't been
doing it long enough to face some nasty, complex issues to maintain yet.
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
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.
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.
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.
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. 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 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
Tirsdag den 18. september 2012 08:38:14 skrev Sven Burmeister:
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.
I never said shipping 4.10 would be a bad idea - it would be the same as the last March release - 4.6.0 in 11.3 - of course the plasma in that release was the worst since 4.2 or so. It's mostly a problem if 4.10 would not be accepted in KDF/Factory until it's officially released upstream in late January, which would leave only a few weeks for testing before the mid March release of 12.3. -- 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
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? -- 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
In data martedì 18 settembre 2012 12:37:31, Will Stephenson ha scritto:
Define 'paid KDE personnel'. A full time KDE engineering team? Employees with @kde.org?
IMO I think the discussion "full time" vs "volounteer" is kind of bikeshedding (notice: I'm not referring to this specific message, but to the whole discussion). My take is that everyone won't have full time on KDE, SUSE or volounteer status notwithstanding. 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. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79
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
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.
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
I think this is a very good idea. I think the message that should come out from KDF is: it's used to hack on the KDE for the next oS iteration, including but not limited to packaging adjustments etc.
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. On the other hand, of course, there may be rough edges in a newer release that may be unnecessarily pushed onto users. So, to go more practical, once the schedule is out, my rundown would be: - What does 4.10 bring to the user? (me, Alin and Raymond run off the latest git, so we would be able to tell, I guess) - Are the new features compelling for it being 4.10? - Are there any known regressions? If we could get Live CDs out of KUSC when the betas (KDE betas) start to appear, we could have more of the interested parties here to check the new upstream release for evaluation as well. Thoughts? -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79
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
In data martedì 18 settembre 2012 20:37:04, Sven Burmeister ha scritto:
http://en.opensuse.org/openSUSE:Statistics might help to estimate the number of potential users.
I'll try to take a look.
.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.
Yes you are right, but snags can potentially enter even point releases (see the KWin regression). Note: I'm not advocating "not doing anything, think of the regressions", but objectively it's one side of the coin we have to take into account.
This is something upstream has to take part. Either upstream complains about users reporting old bugs because of using old KDE versions or they
That's what I'm trying to do at the KDE forums, actually. 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: that's why I wanted stuff like a liveCD for betas so that they could be easily tested (and yes, I encourage everyone who's testing betas to use those forums when they're open ;) Some KDE developers do hang quite often around the forums: the Telepathy guys, the Calligra people and the KWin people are particularly active on that regard. So I think there's some potential for upstream-downstream communication there. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79
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 Tuesday 18 September 2012 21:36:07 Raymond Wooninck wrote:
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.
To support the process, I have created a doodle for the meeting. The link to your poll is: http://doodle.com/h5uvnvixs4bp3r7v Please use this instead of emails to me. Thanks 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
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
In data martedì 18 settembre 2012 21:04:24, Rajko ha scritto:
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.
To be honest, also distributions are less interested in providing the betas/RCs nowadays. But anyway, I still think it might be a good point of contact with upstream. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79
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
Tirsdag den 18. september 2012 15:12:18 skrev Raymond Wooninck:
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.
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. Or does it mean you don't want to have a place to test official KDE patches at all?
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.
I think it's very valuable that people can test KDF on (some) older distros. 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 release cycle.
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.
I think Will's proposal (always summer in KDF, branch to KDS when o:F freezes) did that very well. At least we should keep infrastructure in place so that _if_ one day someone comes along, with good packaging skills and who also cares about creating stable, polished, productive openSUSE releases with KDE, he can. -- 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
Tirsdag den 18. september 2012 17:06:30 skrev Luca Beltrame:
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.
Historical statistics are not relevant since it would be a completely different situation. Under Will's proposed regime o:F users would "automatically" test KDS during the last couple of months leading up to a new openSUSE release. And of course non-o:F users who care about polished, stable openSUSE releases would test KDS on older distros too. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
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
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". Same old, same old killer argument about regressions. When was the last one and what did it take to fix it? I remember nvidia. What else? 12.1 never got kdepim 4.7.4 and probably never will. That is a real issue and burden which would not have happened if that killer argument was not used to fight away the community effort to offer bugfix releases.
Or does it mean you don't want to have a place to test official KDE patches at all?
You assume that there are patches and you assume that those are tested. My claim: if anything is put in there it is either never shipped or shipped some time after it was put in there. Check 12.1's history. Sven -- 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 Tuesday 18 Sep 2012 22:06:48 Martin Schlander wrote:
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?
not necessarily, but we could ship all point releases tested in the appropriate KRxy as updates at some point
be burdened with 500 megs of updates every 2-4 weeks
openSUSE:Update uses delta RPMs so it shouldn't be that big
with regressions
and (more importantly) bugfixes
changed behaviour
hopefully not in point-releases :)
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.
you can also lock updates with "zypper addlock" but the UIs should easily support that, too. Blocking an update in Yast Online Update doesn't really work atm and I'll not get started with apper... Nico -- 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
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 Wednesday 19 Sep 2012 10:44:28 Rajko wrote:
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.
correct, but download bandwidth is probably the limitating factor, not (temporary) hard disk free space
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.
correct, for slower CPUs, the actual gain in terms of overall processing time may be lower. If you're on a very fast line, it may actually be better for you to just download the whole package instead of applying the delta rpm. However, OBS- mirrors probably pay for the traffic and they'll thank you for downloading the deltas :)
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.
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
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.
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.
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.
I assumed that "burdened with 500 megs of updates every 2-4 weeks" means traffic - anyway, used space on the HDD should be rather constant after having the package installed once Nico -- 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
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 Wednesday 19 Sep 2012 13:45:59 Rajko wrote:
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)
I still don't know exactly, how this delta rpm process works. 1) are copies of the installed rpms kept on disk so that a delta-rpm can apply its changes on it? or 2) do the delta rpms apply changes directly to the files on disk? or 3) are the rpms re-assembled from the files on disk if their metadata still matches, e.g. hash sums? and if not, is the rpm loaded instead of the delta rpm? Nico -- 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
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
Am Dienstag, 18. September 2012, 22:06:48 schrieb Martin Schlander:
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.
You don't lock packages but updates, i.e. one update includes more than one package. Or alternatively, you disable the KDE update repo.
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.
Didn't you test the update before it was shipped? I did not because I use KRxy. But those clinging to "openSUSE stable" should at least test the repos that belong to that scheme. If not even they can be bothered we can get rid of them right away and not longer stick to the myth that KDE versions from KDS and KDF are more tested than those from KRxy.
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.
As Nico pointed out. The point is not that there are no bugs but that you ignore the fixes and the possibility to fix bugs. In fact, having KDE updates officially gets rid of all the problems people report because they messed-up their repos etc.
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.
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. Sven -- 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
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).
Keeping better in touch with upstream will at least reduce their impact on the userbase. P.S.: Can we avoid terms like "fanboy"? -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79
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
Onsdag den 19. september 2012 17:51:36 skrev Luca Beltrame:
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).
Keeping better in touch with upstream will at least reduce their impact on the userbase.
P.S.: Can we avoid terms like "fanboy"?
I'm a KDE fanboy myself. I just would like for openSUSE/KDE to be attractive also to people who are not already KDE fanboys. -- 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
Am Dienstag, 18. September 2012, 16:56:37 schrieb Martin Schlander:
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. Kubuntu ships only updated packages that actually changed and I've read a discussion in the archives of the KDE release mailing list to follow that model.
every 2-4 weeks
Since when do SC updates take fewer than 4 weeks?
with regressions and changed behaviour - unless of course the user stops using openSUSE and/or KDE.
Fedora-KDE skips 4.y.0 versions and updates from 4.x.4 to 4.y.1 to minimize regressions. They argue that SC has matured enough to not contain disruptive changes in workflow anyway and I think the point is valid. The last big change was Dolphin 2.0 and at worst individual applications can be blocked for update. -- 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
Am Dienstag, 18. September 2012, 15:12:18 schrieb Raymond Wooninck:
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.
Not having any statistics here about the usage I agree that with the KRxy repos KDS hast lost a bit of its justification. But I still think it is of some use: - usage as a devel project for the last oS release. I personally always felt better when a sr first went to KDS instead directly to the update repo as it is an additional quality check for contributions of an not so experienced packager - The usage of providing the latest stable KDE for older versions of openSUSE is of course also fulfilled by the KR repos. 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. 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. 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. And one should probably be a bit more conservative as it is the case fpr KRxy at the moment.
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.
Here I would agree with Martin that KDF should still be build also for older releases as independent of what comes out in the discussion how KDF and the most recent KRxy repo should be related, it will always be the packages from KDF which will be submitted to Factory and there still might be small differences between these repos maybe because of mistakes because of linking one to the other.
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.
+1 Christian -- 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
Am Mittwoch, 19. September 2012, 10:47:18 schrieb Nico Kruber:
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.
The only solution would be to backport patches which is out of scope given the current resources. And since KUA is very popular updates for those apps seem to make sense.
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. 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: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
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. 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 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
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. Christian -- 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 Thursday 20 Sep 2012 10:27:18 Nico Kruber wrote:
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
From http://en.opensuse.org/Portal:Maintenance, see the "Maintenance Process" box.
See also http://en.opensuse.org/openSUSE:Maintenance_policy note, "no new dependencies, no new sub-packages, no version updates for the sake of version update" 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 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
On Tuesday 18 Sep 2012 15:12:18 Raymond Wooninck wrote:
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.
guilty as charged ;) and this is the reason we should keep the number of repos to maintain down a bit Additionally, OBS currently doesn't offer an easy way to compare whole repositories with each other or get notified of base package changes. E.g. merging back the changes from KR49 into KDF is a rather big manual task and at the moment I don't have an overview of the packages that still differ. E.g. Last month, I updated digikam in KR49 but didn't push it to KDF because the merge was happening already. However, it was not pushed there and someone else updated it in KDF leaving a conflict and unnecessary double work. Same if someone else pushed a patch into KDS - I wouldn't be aware of that and would only be when I try to merge something into KDS. 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? Intermediate patches in KR49 should only be accepted on a per-case basis. This way, as long as KR49 and KDF share the same KDE base version (4.9.x) development should only happen in KDF. Otherwise I lose track of the changes in all the repos. But we can discuss that at the KDE meeting hopefully taking place next week :) Nico -- 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
Am Mittwoch, 19. September 2012, 12:31:13 schrieb Sven Burmeister:
It is not possible to manage links with the webgui.
A lot is not possible with the web interface. Eg there's an option toauto- generate.spec files that never worked. -- 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 12:31:13 Sven Burmeister wrote:
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.
Realistically KDE:* project maintainers should be comfortable working with osc fulltime - it's just not efficient to click click click through build.opensuse.org. F5ing the monitor page to check if a build is green is an exception. We should document frequent workflows to reduce the mistakes, given that everyone working in KDE:* has forgotten at least once to disable publishing of dependent repos in other subprojects ;). 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 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
On Thursday 20 Sep 2012 17:21:30 Will Stephenson wrote:
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.
I ran into some problems trying to merge KR49 with KDF again: development diverged at some time and I'm not sure whether or how I should merge the .changes files e.g. see this one: https://build.opensuse.org/request/show/135283 The revoked sr's imply that only the changes from KDF should prevail and the ones from KR49 be removed. Is that right? Nico -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
participants (11)
-
Christian Trippe
-
Greg KH
-
Luca Beltrame
-
Luca Beltrame
-
Markus
-
Martin Schlander
-
Nico Kruber
-
Rajko
-
Raymond Wooninck
-
Sven Burmeister
-
Will Stephenson