[opensuse-kde] KDE 4.8 and KDE:Distro:Factory
Hi, I would like to put KDE 4.8.0 (or 4.8 RC3 rather for now) into KDE:Distro:Factory. The reason is the sooner we start, the better we find the problems. Currently we have 4.7.4 in KDE:Distro:Factory and in KDE:Release:47. I would like to have your opinion on how to move forward: a) I copy KDE 4.7.4 from KDE:Distro:Factory to KDE:Distro:Stable, and delink KDE:Release:47 from KDE:Distro:Factory. Then I Import KDE 4.8 into KDE:Distro:Factory and copy whatever is needed from Unstable:SC to make it build and work. This would mean that future maintenannce updates for 12.1 are based on 4.7.4. I think that is okay, there have even be requests to release 4.7.4 as a maintenance update (in general we're pro this change). b) I delink KDE:Release:47 from KDE:Distro:Factory and leave it at 4.7.4, and then import KDE 4.8 into KDE:Distro:Factory (and copy whatever is needed from Unstable:SC to make it build and work). in this case 12.1 updates would stay on 4.7.2, users who want the later fixes would need to switch to KDE:Release:47 I prefer a). any comments? Thanks, Dirk -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Hi; On 01/06/2012 02:38 PM, Dirk Müller wrote:
Hi,
I would like to put KDE 4.8.0 (or 4.8 RC3 rather for now) into KDE:Distro:Factory. The reason is the sooner we start, the better we find the problems.
Currently we have 4.7.4 in KDE:Distro:Factory and in KDE:Release:47. I would like to have your opinion on how to move forward:
a) I copy KDE 4.7.4 from KDE:Distro:Factory to KDE:Distro:Stable, and delink KDE:Release:47 from KDE:Distro:Factory. Then I Import KDE 4.8 into KDE:Distro:Factory and copy whatever is needed from Unstable:SC to make it build and work.
This would mean that future maintenannce updates for 12.1 are based on 4.7.4. I think that is okay, there have even be requests to release 4.7.4 as a maintenance update (in general we're pro this change).
This is probably the best. Regards. -- İsmail Dönmez - openSUSE Booster SUSE LINUX Products GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Fri, Jan 6, 2012 at 14:38, Dirk Müller
I would like to put KDE 4.8.0 (or 4.8 RC3 rather for now) into KDE:Distro:Factory. The reason is the sooner we start, the better we find the problems.
Currently we have 4.7.4 in KDE:Distro:Factory and in KDE:Release:47. I would like to have your opinion on how to move forward:
a) I copy KDE 4.7.4 from KDE:Distro:Factory to KDE:Distro:Stable, and delink KDE:Release:47 from KDE:Distro:Factory. Then I Import KDE 4.8 into KDE:Distro:Factory and copy whatever is needed from Unstable:SC to make it build and work.
This would mean that future maintenannce updates for 12.1 are based on 4.7.4. I think that is okay, there have even be requests to release 4.7.4 as a maintenance update (in general we're pro this change).
KDE4.7.4 is working fine - yes a few known bugs, but in my opinion (not that it counts for a lot) it's definitely safe/stable enough to push out to the general user base.... in fact it's a significant improvement over what was shipped with 12.1 and would be a welcome maintenance update.
b) I delink KDE:Release:47 from KDE:Distro:Factory and leave it at 4.7.4, and then import KDE 4.8 into KDE:Distro:Factory (and copy whatever is needed from Unstable:SC to make it build and work).
in this case 12.1 updates would stay on 4.7.2, users who want the later fixes would need to switch to KDE:Release:47
I prefer a). any comments?
Huge preference for a) And.. I'd like to get rolling on KDE4.8RC3 ASAP in Factory too :-) C. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Fri, Jan 6, 2012 at 2:41 PM, Ismail Dönmez
On 01/06/2012 02:38 PM, Dirk Müller wrote:
Hi,
I would like to put KDE 4.8.0 (or 4.8 RC3 rather for now) into KDE:Distro:Factory. The reason is the sooner we start, the better we find the problems.
Currently we have 4.7.4 in KDE:Distro:Factory and in KDE:Release:47. I would like to have your opinion on how to move forward:
a) I copy KDE 4.7.4 from KDE:Distro:Factory to KDE:Distro:Stable, and delink KDE:Release:47 from KDE:Distro:Factory. Then I Import KDE 4.8 into KDE:Distro:Factory and copy whatever is needed from Unstable:SC to make it build and work.
This would mean that future maintenannce updates for 12.1 are based on 4.7.4. I think that is okay, there have even be requests to release 4.7.4 as a maintenance update (in general we're pro this change).
This is probably the best.4
Agreed. This may be a bad idea, but once that is done, perhaps the relevant packages from KDE:Distro:Factory can be copied to KDE:Unstable:SC (only the ones relevant for the latter repo, of course) so we are working off a common set of spec files and subpackages. I made a lot of changes to the package structure of KDF for 12.1 and so I think it would be a good idea to sync the repos up again. I did it a little already, but only for packages that were clearly causing problems. -Todd -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Dnia piątek, 6 stycznia 2012 14:38:53 Dirk Müller pisze:
Hi,
I would like to put KDE 4.8.0 (or 4.8 RC3 rather for now) into KDE:Distro:Factory. The reason is the sooner we start, the better we find the problems.
Currently we have 4.7.4 in KDE:Distro:Factory and in KDE:Release:47. I would like to have your opinion on how to move forward:
a) I copy KDE 4.7.4 from KDE:Distro:Factory to KDE:Distro:Stable, and delink KDE:Release:47 from KDE:Distro:Factory. Then I Import KDE 4.8 into KDE:Distro:Factory and copy whatever is needed from Unstable:SC to make it build and work.
This would mean that future maintenannce updates for 12.1 are based on 4.7.4. I think that is okay, there have even be requests to release 4.7.4 as a maintenance update (in general we're pro this change).
+1
b) I delink KDE:Release:47 from KDE:Distro:Factory and leave it at 4.7.4, and then import KDE 4.8 into KDE:Distro:Factory (and copy whatever is needed from Unstable:SC to make it build and work).
in this case 12.1 updates would stay on 4.7.2, users who want the later fixes would need to switch to KDE:Release:47
I prefer a). any comments?
Thanks, Dirk -- Pozdrawiam / Best regards, Mariusz Fik openSUSE Community Member GPG: 5FCE 7241 B3B9 32FD 455B C30E 42D6 6C88 9E83 7C3D
Fredag den 6. januar 2012 14:38:53 skrev Dirk Müller:
Currently we have 4.7.4 in KDE:Distro:Factory and in KDE:Release:47. I would like to have your opinion on how to move forward:
a) I copy KDE 4.7.4 from KDE:Distro:Factory to KDE:Distro:Stable, and delink KDE:Release:47 from KDE:Distro:Factory. Then I Import KDE 4.8 into KDE:Distro:Factory and copy whatever is needed from Unstable:SC to make it build and work.
This would mean that future maintenannce updates for 12.1 are based on 4.7.4. I think that is okay, there have even be requests to release 4.7.4 as a maintenance update (in general we're pro this change).
b) I delink KDE:Release:47 from KDE:Distro:Factory and leave it at 4.7.4, and then import KDE 4.8 into KDE:Distro:Factory (and copy whatever is needed from Unstable:SC to make it build and work).
in this case 12.1 updates would stay on 4.7.2, users who want the later fixes would need to switch to KDE:Release:47
I prefer a). any comments?
I prefer b) * Pushing 4.7.4 as an official update is a huge update/download likely to bring several regressions * PackageKit will probably explode like it did the last time we did a full KDE update (4.3.1->4.3.5) leading to failed updates * If you make an exception and upgrade KDE you open up the pandora's box of version whores who'll flood this list and irc and forums with requests for official upgrades whenever there's an upstream release forever and ever. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Am Freitag 06 Januar 2012, 20:54:45 schrieb Martin Schlander:
* Pushing 4.7.4 as an official update is a huge update/download Leave out the artwork packages. There is no need to push unchanged artwork to users just because OBS found it necessary to give it a new version number. Without artwork the download size is manageable.
likely to bring several regressions I had no regressions at all and when you think it brings regressions, talk to the upstream KDE release managers.
* PackageKit will probably explode like it did the last time we did a full KDE update (4.3.1->4.3.5) leading to failed updates
Then fix PackageKit first.... Oh, your example is from years ago... is that all you can come up with? How about facts? Enable the KR47 repo and check for yourself.
* If you make an exception and upgrade KDE you open up the pandora's box of version whores who'll flood this list and irc and forums with requests for official upgrades whenever there's an upstream release forever and ever.
As long as it's an actual bugfix release and not a new feature release: Why not? I mean, openSUSE already allows untested alpha snapshots of Chromium into the main distribution as well as the official update channel (the latest version can't even download files). 4.7.4 as official update can't be worse than that. Markus -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Am Freitag 06 Januar 2012, 14:38:53 schrieb Dirk =?ISO-8859-1?Q?M=FCller?=:
I would like to put KDE 4.8.0 (or 4.8 RC3 rather for now) into KDE:Distro:Factory. The reason is the sooner we start, the better we find the problems.
Does that also mean KR48? KR48 looks pretty broken right now. I found it unfortunate that with the 4.8 RC openSUSE couldn't be mentioned as distributor to pick up the packages. Being the first and making it into the "how to obtain" part of KDE release announcements is a great way to promote ourselves. I was about to start a similar thread with suggestions/reminders which packages should come into KR48 -- esp. the app-menu stuff now that Qt 4.8 is the default Qt version.
This would mean that future maintenannce updates for 12.1 are based on 4.7.4. I think that is okay, there have even be requests to release 4.7.4 as a maintenance update (in general we're pro this change).
That should be OK. Leave artwork packages unupdated to cut file size. Wallpapers ect. AFAIK aren't updated anyway. Markus -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Fri, Jan 6, 2012 at 21:26, Markus Slopianka
likely to bring several regressions I had no regressions at all and when you think it brings regressions, talk to the upstream KDE release managers.
Second that. I've updated several systems to KDE4.7.4 without problems. No regressions, no drama, no problems (that were not created by me and my fat fingers)
* PackageKit will probably explode like it did the last time we did a full KDE update (4.3.1->4.3.5) leading to failed updates
Then fix PackageKit first.... Oh, your example is from years ago... is that all you can come up with? How about facts? Enable the KR47 repo and check for yourself.
No issues there either. C. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On 01/06/2012 11:54 AM, Martin Schlander wrote:
Fredag den 6. januar 2012 14:38:53 skrev Dirk Müller:
Currently we have 4.7.4 in KDE:Distro:Factory and in KDE:Release:47. I would like to have your opinion on how to move forward:
a) I copy KDE 4.7.4 from KDE:Distro:Factory to KDE:Distro:Stable, and delink KDE:Release:47 from KDE:Distro:Factory. Then I Import KDE 4.8 into KDE:Distro:Factory and copy whatever is needed from Unstable:SC to make it build and work.
This would mean that future maintenannce updates for 12.1 are based on 4.7.4. I think that is okay, there have even be requests to release 4.7.4 as a maintenance update (in general we're pro this change).
b) I delink KDE:Release:47 from KDE:Distro:Factory and leave it at 4.7.4, and then import KDE 4.8 into KDE:Distro:Factory (and copy whatever is needed from Unstable:SC to make it build and work).
in this case 12.1 updates would stay on 4.7.2, users who want the later fixes would need to switch to KDE:Release:47
I prefer a). any comments?
I prefer b)
* Pushing 4.7.4 as an official update is a huge update/download likely to bring several regressions * PackageKit will probably explode like it did the last time we did a full KDE update (4.3.1->4.3.5) leading to failed updates * If you make an exception and upgrade KDE you open up the pandora's box of version whores who'll flood this list and irc and forums with requests for official upgrades whenever there's an upstream release forever and ever.
Normally, I'd be inclined to agree with Martin about a version bump. However, I too find 4.7.4 very stable and usable on 11.4 and 12.1. I've got the latest 4.8.rc on my netbook and it also seems to work very well already. I am well aware of versionitis, but it seems this upgrade will bring a better experience for many users. Peter -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On 07/01/12 09:58, C wrote:
likely to bring several regressions I had no regressions at all and when you think it brings regressions, talk to the upstream KDE release managers. Second that. I've updated several systems to KDE4.7.4 without
On Fri, Jan 6, 2012 at 21:26, Markus Slopianka
wrote: problems. No regressions, no drama, no problems (that were not created by me and my fat fingers)
Ditto here - no hassles at all (this on a 32-bit system).
* PackageKit will probably explode like it did the last time we did a full KDE update (4.3.1->4.3.5) leading to failed updates
Then fix PackageKit first.... Oh, your example is from years ago... is that all you can come up with? How about facts? Enable the KR47 repo and check for yourself. No issues there either.
C. BC
-- What religion were Adam and Eve? -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Am Freitag, 6. Januar 2012, 20:54:45 schrieb Martin Schlander:
* Pushing 4.7.4 as an official update is a huge update/download likely to bring several regressions * PackageKit will probably explode like it did the last time we did a full KDE update (4.3.1->4.3.5) leading to failed updates * If you make an exception and upgrade KDE you open up the pandora's box of version whores who'll flood this list and irc and forums with requests for official upgrades whenever there's an upstream release forever and ever.
The complains I remember are as follows: a) low response/fixing rate for bugs filed at bnc b) slow release of updates c) openSUSE's KDE is out-of-date (lots of bugs fixed upstream) d) shipping upstream version will introduce regressions Unfortunately I am not well informed about how much time how many people spend on working on KDE within openSUSE or how time-consuming backporting/fixing/packaging updates is. So I might make some wrong assumptions. Here is my proposal for the rule of thumb. Exceptions should be discussed as they appear, i.e. things like kdepim 4.7 etc. - create a list of openSUSE patches This will enable users to check whether their bug might be opensuse-specific - be stricter about upstream bugs in bnc Reality is that most upstream bugs reported at bnc will not get fixed. This means that the reporter will be frustrated because his report stays unanswered and he does not get a fix from openSUSE. Yet it also means that because he did not report upstream, upstream cannot fix it and if it was fixed upstream because somebody else reported it the reporter does not know and cannot report back to openSUSE. So I would suggest to only allow openSUSE-specific bugs and bugs that link to an upstream bug or patch and act as reminder. - create a list of patches to STABLE This enables testers to check what they should test and users to check whether their issue was already taken care of. - release updates quicker. Patches are put into STABLE and I claim that leaving them in there for more than two weeks will not increase their testing or feedback. Or to put it in other words: if a patch did not cause any trouble within two weeks – ship it. This means that there will be more updates with less patches and hence users can revert easier in case one of them causes any issues. Further users will get more "feedback" and thus feel that there is work going on. - ship the last minor release for openSUSE's KDE major version as optional update To me it feels that after two or three months after an openSUSE release the number of updates for KDE drops to ~0. Mostly because the major crashes and issues are resolved and everything else won't be backported. Shipping the last minor release as optional update will not worsen that state because it is optional, i.e. only those that want it install it and it can be reverted easily. Due to the KRxy repos the update would get testing and the packages could be taken from there e.g. four weeks after the upstream release. I think this would cover: a) low response/fixing rate for bugs filed at bnc b) slow release of updates c) openSUSE's KDE is out-of-date (lots of bugs fixed upstream) d) shipping upstream version will introduce regressions Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Sat, 2012-01-07 at 16:28 +0100, Sven Burmeister wrote:
Am Freitag, 6. Januar 2012, 20:54:45 schrieb Martin Schlander:
* Pushing 4.7.4 as an official update is a huge update/download likely to bring several regressions * PackageKit will probably explode like it did the last time we did a full KDE update (4.3.1->4.3.5) leading to failed updates * If you make an exception and upgrade KDE you open up the pandora's box of version whores who'll flood this list and irc and forums with requests for official upgrades whenever there's an upstream release forever and ever.
The complains I remember are as follows:
a) low response/fixing rate for bugs filed at bnc b) slow release of updates c) openSUSE's KDE is out-of-date (lots of bugs fixed upstream) d) shipping upstream version will introduce regressions
Unfortunately I am not well informed about how much time how many people spend on working on KDE within openSUSE or how time-consuming backporting/fixing/packaging updates is. So I might make some wrong assumptions.
Here is my proposal for the rule of thumb. Exceptions should be discussed as they appear, i.e. things like kdepim 4.7 etc.
- create a list of openSUSE patches This will enable users to check whether their bug might be opensuse-specific
- be stricter about upstream bugs in bnc Reality is that most upstream bugs reported at bnc will not get fixed. This means that the reporter will be frustrated because his report stays unanswered and he does not get a fix from openSUSE. Yet it also means that because he did not report upstream, upstream cannot fix it and if it was fixed upstream because somebody else reported it the reporter does not know and cannot report back to openSUSE. So I would suggest to only allow openSUSE-specific bugs and bugs that link to an upstream bug or patch and act as reminder. I agree in most areas, but take huge exception to this. Joe User isn't going to know what is upstream. Heck, even I'm not always able to tell when it is upstream or not. Its better they report it, then be told the issue is upstream. In that case I'd recommend a maintained page on how to report upstream.
- create a list of patches to STABLE This enables testers to check what they should test and users to check whether their issue was already taken care of.
- release updates quicker. Patches are put into STABLE and I claim that leaving them in there for more than two weeks will not increase their testing or feedback. Or to put it in other words: if a patch did not cause any trouble within two weeks – ship it. This means that there will be more updates with less patches and hence users can revert easier in case one of them causes any issues. Further users will get more "feedback" and thus feel that there is work going on.
- ship the last minor release for openSUSE's KDE major version as optional update To me it feels that after two or three months after an openSUSE release the number of updates for KDE drops to ~0. Mostly because the major crashes and issues are resolved and everything else won't be backported. Shipping the last minor release as optional update will not worsen that state because it is optional, i.e. only those that want it install it and it can be reverted easily. Due to the KRxy repos the update would get testing and the packages could be taken from there e.g. four weeks after the upstream release.
I think this would cover: a) low response/fixing rate for bugs filed at bnc b) slow release of updates c) openSUSE's KDE is out-of-date (lots of bugs fixed upstream) d) shipping upstream version will introduce regressions
Sven
-- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Am Samstag, 7. Januar 2012, 08:27:02 schrieb Roger Luedecke:
I agree in most areas, but take huge exception to this. Joe User isn't going to know what is upstream. Heck, even I'm not always able to tell when it is upstream or not. Its better they report it, then be told the issue is upstream.
This relies on the wrong assumption that they are told that their issue is upstream. What happens in reality is that those bugs remain unanswered and unfixed in bnc. How is that helping anybody? Reporting upstream increases the chances of getting a response – which does help. Upstream has more KDE developers and those devs know the app they maintain, unlike openSUSE staff who mainly act as packagers. Don't get me wrong, in an ideal world openSUSE users would report every issue to openSUSE and it would be evaluated and forwarded to the suitable place. But that's not going to happen unless there is a group of people from the openSUSE community who takes that job. IMHO it is a no-go for openSUSE staff to spend time on bug triaging – simply because their time is too precious (because there are too few). Combine this with >90% bugs reported being upstream issues or issues that whose fix will never be backported and off you go with lots of wasted time that cannot be spent on packaging and fixing downstream issues.
In that case I'd recommend a maintained page on how to report upstream.
How is reporting upstream different from reporting at bnc – given users get a link to bko? Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Sat, 2012-01-07 at 18:07 +0100, Sven Burmeister wrote:
Am Samstag, 7. Januar 2012, 08:27:02 schrieb Roger Luedecke:
I agree in most areas, but take huge exception to this. Joe User isn't going to know what is upstream. Heck, even I'm not always able to tell when it is upstream or not. Its better they report it, then be told the issue is upstream.
This relies on the wrong assumption that they are told that their issue is upstream. What happens in reality is that those bugs remain unanswered and unfixed in bnc. How is that helping anybody? Reporting upstream increases the chances of getting a response – which does help. Upstream has more KDE developers and those devs know the app they maintain, unlike openSUSE staff who mainly act as packagers.
Don't get me wrong, in an ideal world openSUSE users would report every issue to openSUSE and it would be evaluated and forwarded to the suitable place. But that's not going to happen unless there is a group of people from the openSUSE community who takes that job.
IMHO it is a no-go for openSUSE staff to spend time on bug triaging – simply because their time is too precious (because there are too few). Combine this with >90% bugs reported being upstream issues or issues that whose fix will never be backported and off you go with lots of wasted time that cannot be spent on packaging and fixing downstream issues.
In that case I'd recommend a maintained page on how to report upstream.
How is reporting upstream different from reporting at bnc – given users get a link to bko?
Sven Reporting upstream by default seems counter-intuitive to me. Maybe we just need to make a call to form a bug taskforce of people like me who aren't skilled enough to code but know enough to determine if an issue is an upstream one. We could peruse each one, go "hey this looks like it," check with bko to confirm, then help the reporting user get the report upstream.
-- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On 07.01.2012 18:16, Roger Luedecke wrote:
Reporting upstream by default seems counter-intuitive to me. Maybe we just need to make a call to form a bug taskforce of people like me who aren't skilled enough to code but know enough to determine if an issue is an upstream one. We could peruse each one, go "hey this looks like it," check with bko to confirm, then help the reporting user get the report upstream.
I'd agree with it. Isn't there a chance to assign the bug also to a kde list? If *they* would support that thought. --kdl -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Am Samstag, 7. Januar 2012, 09:16:11 schrieb Roger Luedecke:
Reporting upstream by default seems counter-intuitive to me.
That might be the case. For me it's: I'm using KDE thus I report to KDE. For you it is: I use openSUSE thus I report everything to openSUSE.
Maybe we just need to make a call to form a bug taskforce of people like me who aren't skilled enough to code but know enough to determine if an issue is an upstream one. We could peruse each one, go "hey this looks like it," check with bko to confirm, then help the reporting user get the report upstream.
Good idea. But nobody was ever held back from triaging bugzilla or work on the wiki, blog howtos etc. So I would assume that if there are people willing to do so, they would have started already. :-) Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Sat, 2012-01-07 at 19:09 +0100, Sven Burmeister wrote:
Am Samstag, 7. Januar 2012, 09:16:11 schrieb Roger Luedecke:
Reporting upstream by default seems counter-intuitive to me.
That might be the case. For me it's: I'm using KDE thus I report to KDE. For you it is: I use openSUSE thus I report everything to openSUSE. Basically, yeah.
Maybe we just need to make a call to form a bug taskforce of people like me who aren't skilled enough to code but know enough to determine if an issue is an upstream one. We could peruse each one, go "hey this looks like it," check with bko to confirm, then help the reporting user get the report upstream.
Good idea. But nobody was ever held back from triaging bugzilla or work on the wiki, blog howtos etc. So I would assume that if there are people willing to do so, they would have started already. :-) Its easier to do these sorts of things when you are a platoon, and not just a lone vigilante. As for the wiki, folks don't know HTML and whatnot... thus no contribution.
Sven
-- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Am Samstag, 7. Januar 2012, 16:28:32 schrieb Sven Burmeister:
Am Freitag, 6. Januar 2012, 20:54:45 schrieb Martin Schlander: - be stricter about upstream bugs in bnc Reality is that most upstream bugs reported at bnc will not get fixed. This means that the reporter will be frustrated because his report stays unanswered and he does not get a fix from openSUSE. Yet it also means that because he did not report upstream, upstream cannot fix it and if it was fixed upstream because somebody else reported it the reporter does not know and cannot report back to openSUSE. So I would suggest to only allow openSUSE-specific bugs and bugs that link to an upstream bug or patch and act as reminder.
The rule here is already there, see http://en.opensuse.org/openSUSE:Bugreport_KDE and especially http://en.opensuse.org/openSUSE:Bugreport_KDE#Report_at_bugzilla.novell.com_... But there are a few reasons why it does not always work * Lack of manpower * Sometimes, at least for me, it is not always clear, if a bug is caused by KDE or lower in the stack. So if you have no time to do some tests such a bug easily remains unanswered. But many bugs are closed as upstream and people are told to report bugs first upstream and to reopen if a fix is available there. It can also happen that one leaves some clearly upstream reports open, after they have been reported there, so that they are more easily found and avoiding duplicated reports on bnc by this. And IMHO the number of useful reports, this means with a link to a fixed upstream report and the commit has increased with 12.1. So this works to some extend already today. Of course it would really help if there were a few people more doing bug triage. If someone wants to helps, here is the howto for KDE on openSUSE: http://en.opensuse.org/openSUSE:Bug_Screening_KDE It is a bit out of date in some of the details, but one should get the idea. Christian -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On 07.01.2012 21:48, Christian Trippe wrote:
The rule here is already there, see http://en.opensuse.org/openSUSE:Bugreport_KDE and especially http://en.opensuse.org/openSUSE:Bugreport_KDE#Report_at_bugzilla.novell.com_... But there are a few reasons why it does not always work
* Lack of manpower
* Sometimes, at least for me, it is not always clear, if a bug is caused by KDE or lower in the stack. So if you have no time to do some tests such a bug easily remains unanswered.
But many bugs are closed as upstream and people are told to report bugs first upstream and to reopen if a fix is available there.
It can also happen that one leaves some clearly upstream reports open, after they have been reported there, so that they are more easily found and avoiding duplicated reports on bnc by this.
And IMHO the number of useful reports, this means with a link to a fixed upstream report and the commit has increased with 12.1. So this works to some extend already today.
Of course it would really help if there were a few people more doing bug triage.
If someone wants to helps, here is the howto for KDE on openSUSE: http://en.opensuse.org/openSUSE:Bug_Screening_KDE
It is a bit out of date in some of the details, but one should get the idea.
Christian
So either people post problems on that list to discuss if it's upstream or not, or we find something that real solves the problem. I'm really not that good in writing a bugreport and haven't done it that often in my live, so I probably miss the point completely, anyway, we might should work together with the upstream developers more often then we do now. How? Well, I know many KDE guys are using openSUSE due to a) SUSE is traditionally one of the biggest KDE supporters b) Both KDE and openSUSE are Europe-founded projects. I'd rather suggest to ask KDE people to join our list, and work as "upstream experts". The KDE guys know their own code best, so they can decide best if it's upstream or openSUSE-related. Our KDE-team is patching KDE. That's good since KDE becomes a lot more useful due to the patches. Anyway, the devs would do very well by publishing a list of patches and changes they did. I know, this would be hard work, but might be a good chance to find out if something's upstream related, or not. So far, this is everything I'd suggest, hope it helps --kdl -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Am Samstag, 7. Januar 2012, 22:25:17 schrieb Kim Leyendecker:
On 07.01.2012 21:48, Christian Trippe wrote:
The rule here is already there, see http://en.opensuse.org/openSUSE:Bugreport_KDE and especially http://en.opensuse.org/openSUSE:Bugreport_KDE#Report_at_bugzilla.novell. com_or_bugs.kde.org.3F But there are a few reasons why it does not always work
* Lack of manpower
* Sometimes, at least for me, it is not always clear, if a bug is caused by KDE or lower in the stack. So if you have no time to do some tests such a bug easily remains unanswered.
But many bugs are closed as upstream and people are told to report bugs first upstream and to reopen if a fix is available there.
It can also happen that one leaves some clearly upstream reports open, after they have been reported there, so that they are more easily found and avoiding duplicated reports on bnc by this.
And IMHO the number of useful reports, this means with a link to a fixed upstream report and the commit has increased with 12.1. So this works to some extend already today.
Of course it would really help if there were a few people more doing bug triage.
If someone wants to helps, here is the howto for KDE on openSUSE: http://en.opensuse.org/openSUSE:Bug_Screening_KDE
It is a bit out of date in some of the details, but one should get the idea.
Christian
So either people post problems on that list to discuss if it's upstream or not, or we find something that real solves the problem.
I'm really not that good in writing a bugreport and haven't done it that often in my live, so I probably miss the point completely, anyway, we might should work together with the upstream developers more often then we do now.
How? Well, I know many KDE guys are using openSUSE due to a) SUSE is traditionally one of the biggest KDE supporters b) Both KDE and openSUSE are Europe-founded projects.
I'd rather suggest to ask KDE people to join our list, and work as "upstream experts". The KDE guys know their own code best, so they can decide best if it's upstream or openSUSE-related.
No the problem is not so much if something is upstream or not, but more where is the correct upstream. Sure a crash in plasma is easy, but what with a bug in apper? Is it a bug in apper, in the packagekit-zypp backend or in packagekit itself. This can at least to some degree be checked when testing with the GNOME equivalent. This needs to be done by us and not (KDE)-Upstream. So this is not so much about fixing a bug, but help in triaging which everybody can do. Sure upstream knowledge is sometimes useful, but often it is not needed, because you simply need time Christian -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Am Samstag, 7. Januar 2012, 16:28:32 schrieb Sven Burmeister:
Am Freitag, 6. Januar 2012, 20:54:45 schrieb Martin Schlander:
Here is my proposal for the rule of thumb. Exceptions should be discussed as they appear, i.e. things like kdepim 4.7 etc.
- create a list of openSUSE patches This will enable users to check whether their bug might be opensuse-specific
This also exists to some extend, see http://en.opensuse.org/openSUSE:KDE_openSUSE_modifications This is of course only about added features and not (backported) fixes. Christian -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Sun, 2012-01-08 at 10:47 +0100, Christian Trippe wrote:
Am Samstag, 7. Januar 2012, 22:25:17 schrieb Kim Leyendecker:
On 07.01.2012 21:48, Christian Trippe wrote:
The rule here is already there, see http://en.opensuse.org/openSUSE:Bugreport_KDE and especially http://en.opensuse.org/openSUSE:Bugreport_KDE#Report_at_bugzilla.novell. com_or_bugs.kde.org.3F But there are a few reasons why it does not always work
* Lack of manpower
* Sometimes, at least for me, it is not always clear, if a bug is caused by KDE or lower in the stack. So if you have no time to do some tests such a bug easily remains unanswered.
But many bugs are closed as upstream and people are told to report bugs first upstream and to reopen if a fix is available there.
It can also happen that one leaves some clearly upstream reports open, after they have been reported there, so that they are more easily found and avoiding duplicated reports on bnc by this.
And IMHO the number of useful reports, this means with a link to a fixed upstream report and the commit has increased with 12.1. So this works to some extend already today.
Of course it would really help if there were a few people more doing bug triage.
If someone wants to helps, here is the howto for KDE on openSUSE: http://en.opensuse.org/openSUSE:Bug_Screening_KDE
It is a bit out of date in some of the details, but one should get the idea.
Christian
So either people post problems on that list to discuss if it's upstream or not, or we find something that real solves the problem.
I'm really not that good in writing a bugreport and haven't done it that often in my live, so I probably miss the point completely, anyway, we might should work together with the upstream developers more often then we do now.
How? Well, I know many KDE guys are using openSUSE due to a) SUSE is traditionally one of the biggest KDE supporters b) Both KDE and openSUSE are Europe-founded projects.
I'd rather suggest to ask KDE people to join our list, and work as "upstream experts". The KDE guys know their own code best, so they can decide best if it's upstream or openSUSE-related.
No the problem is not so much if something is upstream or not, but more where is the correct upstream. Sure a crash in plasma is easy, but what with a bug in apper?
Is it a bug in apper, in the packagekit-zypp backend or in packagekit itself. This can at least to some degree be checked when testing with the GNOME equivalent. This needs to be done by us and not (KDE)-Upstream.
So this is not so much about fixing a bug, but help in triaging which everybody can do. Sure upstream knowledge is sometimes useful, but often it is not needed, because you simply need time
Christian Agreed.
-- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Am Sonntag, 8. Januar 2012, 10:47:02 schrieb Christian Trippe:
No the problem is not so much if something is upstream or not, but more where is the correct upstream. Sure a crash in plasma is easy, but what with a bug in apper?
Isn't this the exception to the rule? Most bugs are within KDE apps that do not have opensuse-specific backends, apper is the exception to the rule, as is policykit if it comes to the rules set-up by default. Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Sun, Jan 8, 2012 at 11:34 AM, Sven Burmeister
Am Sonntag, 8. Januar 2012, 10:47:02 schrieb Christian Trippe:
No the problem is not so much if something is upstream or not, but more where is the correct upstream. Sure a crash in plasma is easy, but what with a bug in apper?
Isn't this the exception to the rule? Most bugs are within KDE apps that do not have opensuse-specific backends, apper is the exception to the rule, as is policykit if it comes to the rules set-up by default.
Sven
The problem is that KDE is sitting on a huge software stack, other parts of which also have openSUSE-specific patches and configurations. -Todd -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Am Sonntag, 8. Januar 2012, 11:42:06 schrieb todd rme:
The problem is that KDE is sitting on a huge software stack, other parts of which also have openSUSE-specific patches and configurations.
And you think that most KDE bugs result from that stack rather than being KDE bugs? If so I wonder why 99% of the bugs I report upstream are accepted as real KDE bugs and not due to opensuse-specific patches. Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Am Sonntag, 8. Januar 2012, 11:34:59 schrieb Sven Burmeister:
Am Sonntag, 8. Januar 2012, 10:47:02 schrieb Christian Trippe:
No the problem is not so much if something is upstream or not, but more where is the correct upstream. Sure a crash in plasma is easy, but what with a bug in apper?
Isn't this the exception to the rule? Most bugs are within KDE apps that do not have opensuse-specific backends, apper is the exception to the rule, as is policykit if it comes to the rules set-up by default.
No of course not. But usually these bugs often require more work to even upstream them. So they often remain mostly untouched and clutter up bugzilla. And it is not only apper, but every *Kit, graphics/Xorg related things, etc. Everything alone is not that much but all together, it easily leads to a growing number of untouched bugs, where you then easily overlook also a simple one, where it is for example clear that it belongs upstream. Christian -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
todd rme said the following on 01/08/2012 05:42 AM:
The problem is that KDE is sitting on a huge software stack, other parts of which also have openSUSE-specific patches and configurations.
To the degree that is true, to the degree that even to edit the source and recompile any part of KDE or change the scripts, you are sitting on the stack of text mode tools, compilers and more, all of which have support in different areas, this is how KDE and Linux is different from Windows. There are arguments for an against diversification, for an against single sourcing. Even with Linux we have some critical paths that are only mitigated by having the sources widely duplicated. But the degree that Todd's case is true can best be shown by hard evidence. Sven - and others - how many of the bugs that get reported to bugs.kde.org are nothing to do with KDE, are bugs in MAKE, GCC, X or the kernel? How many are actually runtime/installation configuration issues? Because I wonder how much of Todd's 'stack' is 'runtime' as opposed to the 'stack' that's needed to run Linux as a development platform? Reality often bits and many plausible conjectures fall in the face of evidence. Sven, what's the hard evidence here? -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Apologies: I think I need a new keyboard. Some keys are sticking. Its must be the coffee I've splurted out over it while reading some of the more outrageous postings I've read here and elsewhere. Please insert 's' 'd' 'e' 'f' 'c' and the occasional 'x' as needed to make up for what appears to be simple illiteracy. Thank you. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Am Sonntag, 8. Januar 2012, 07:55:54 schrieb Anton Aylward:
But the degree that Todd's case is true can best be shown by hard evidence. Sven - and others - how many of the bugs that get reported to bugs.kde.org are nothing to do with KDE, are bugs in MAKE, GCC, X or the kernel? How many are actually runtime/installation configuration issues?
Because I wonder how much of Todd's 'stack' is 'runtime' as opposed to the 'stack' that's needed to run Linux as a development platform?
Reality often bits and many plausible conjectures fall in the face of evidence. Sven, what's the hard evidence here?
You will have to query upstream. I can only speak for the bugs I report and there was not a single gcc or make issue around. Configuration (if it is a KDE apps config) is upstream as well. Kwin has some issues depending on the xorg/graphics stack but with exceptions those are still not openSUSE-specific but valid for other distros as well and it's good upstream knows about them. No arch, fedora or whatever user will query bnc for issues and hence "same stack"-users will never meet. Very few issues are really openSUSE-specific. apper + zypper-backend is one of them. The nvidia one back in the days was one as well AFAIK. As I mentioned before, most bugs reported are normal KDE bugs so as a rule of thumb upstream is the correct place to report – even if it only helps to check which distros have the same issue and what stack versions they share. I mean, does anybody really doubt that >50% of KDE bugs reported are not openSUSE-specific? Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Sven Burmeister said the following on 01/08/2012 08:17 AM:
I mean, does anybody really doubt that >50% of KDE bugs reported are not openSUSE-specific?
Not me, but then regular readers will know that I run other distributions as well as openSuse. If anything, my complaint is along the lines of ... well we've had this discussion recently about flipping the repositories. Since I have .8 on Fedora for a few weeks now my reaction is "about time too!". -- STATUS QUO is Latin for "the mess we're in." -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Am Sonntag, 8. Januar 2012, 08:28:06 schrieb Anton Aylward:
If anything, my complaint is along the lines of ... well we've had this discussion recently about flipping the repositories. Since I have .8 on Fedora for a few weeks now my reaction is "about time too!".
So you want the packages from UNSTABLE to move to e.g. KR48 earlier? Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Sven Burmeister said the following on 01/08/2012 08:50 AM:
Am Sonntag, 8. Januar 2012, 08:28:06 schrieb Anton Aylward:
If anything, my complaint is along the lines of ... well we've had this discussion recently about flipping the repositories. Since I have .8 on Fedora for a few weeks now my reaction is "about time too!".
So you want the packages from UNSTABLE to move to e.g. KR48 earlier?
Sounds like http://ozyandmillie.org/2000/07/24/ozy-and-millie-440/ No, actually I was thinking of .8 replacing .7 ... -- A generation which ignores history has no past and no future. Robert Heinlein (1907 - 1988), The Notebooks of Lazurus Long -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Friday 06 January 2012, Markus Slopianka wrote:
Does that also mean KR48? KR48 looks pretty broken right now. I found it unfortunate that with the 4.8 RC openSUSE couldn't be mentioned as distributor to pick up the packages. Being the first and making it into the "how to obtain" part of KDE release announcements is a great way to promote ourselves.
Hi, well, my plan was to build KDE:Release:48 based on KDE:Distro:Factory packages, so it is depending on the solution to my question above. Meanwhile, I've fixed some of the issues in KDE:Release:48, but so far it is still a playground, and anyone interested is welcome to submit fixes via osc submitrequests. Thanks, Dirk -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Tuesday 10 Jan 2012 15:23:48 Dirk Müller wrote:
On Friday 06 January 2012, Markus Slopianka wrote:
Does that also mean KR48? KR48 looks pretty broken right now. I found it unfortunate that with the 4.8 RC openSUSE couldn't be mentioned as distributor to pick up the packages. Being the first and making it into the "how to obtain" part of KDE release announcements is a great way to promote ourselves.
Hi,
well, my plan was to build KDE:Release:48 based on KDE:Distro:Factory packages, so it is depending on the solution to my question above.
I'd get on with a) asap. Although it wastes a lot of post-12.1 release fix backporting work that I did. Perhaps we should consider shipping all .z releases as version bumps, delayed a couple of weeks after release so KR4* testing will show regressions. Yes, this sucks for those on low bandwidth but generally the regression-to-fix ratio is low. Will -- -- Will Stephenson, KDE Developer, openSUSE Boosters Team SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Am Dienstag, 10. Januar 2012, 22:17:54 schrieb Will Stephenson:
I'd get on with a) asap. Although it wastes a lot of post-12.1 release fix backporting work that I did. Perhaps we should consider shipping all .z releases as version bumps, delayed a couple of weeks after release so KR4* testing will show regressions. Yes, this sucks for those on low bandwidth but generally the regression-to-fix ratio is low.
I would say it depends on the packaging/backporting resources available. Shipping a .z release as update saves a lot of backporting and extra-packaging effort. Shipping the update as optional leaves it up to the user whether to use it or not and enables him to revert. Hence potential regressions are not forced on anyone. The question though is, how does this affect the update policy for the .z release shipped with openSUSE? Currently people get official updates for major/security bugs without the need to update to a new .z. So let's assume the new policy would have been in place for 12.1 already, how would that work? a) no/less updates for 4.7.2 but just 4.7.3/4 as optional update b) almost the same amount of fixes for 4.7.2 and additionally 4.7.4 as optional update Given the freeze period for a new openSUSE release, on release day there would already be a new .z release that was tested for a few weeks. Sven -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
Dnia sobota, 7 stycznia 2012 o 18:16:11 Roger Luedecke napisał(a):
Reporting upstream by default seems counter-intuitive to me. Maybe we just need to make a call to form a bug taskforce of people like me who aren't skilled enough to code but know enough to determine if an issue is an upstream one. We could peruse each one, go "hey this looks like it," check with bko to confirm, then help the reporting user get the report upstream.
Note that KDE applications invite the operator to report to KDE by default. Sometimes it does not work at all, due to bad discontinuation policy at KDE (like Kmail, KPackageKit), which is something we should explicitly condemn (and replace the broken links with BNC). Chris -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Friday 06 Jan 2012 14:38:53 Dirk Müller wrote:
I would like to put KDE 4.8.0 (or 4.8 RC3 rather for now) into KDE:Distro:Factory. The reason is the sooner we start, the better we find the problems.
Currently we have 4.7.4 in KDE:Distro:Factory and in KDE:Release:47. I would like to have your opinion on how to move forward:
a) I copy KDE 4.7.4 from KDE:Distro:Factory to KDE:Distro:Stable, and delink KDE:Release:47 from KDE:Distro:Factory. Then I Import KDE 4.8 into KDE:Distro:Factory and copy whatever is needed from Unstable:SC to make it build and work.
This would mean that future maintenannce updates for 12.1 are based on 4.7.4. I think that is okay, there have even be requests to release 4.7.4 as a maintenance update (in general we're pro this change).
Max Lin noticed these packages became downgraded in KDE:Release:47 clemantine 1.0 -> 0.7.3 digikam 2.3.0 -> 2.2.0 kipi-plugins 2.3.0 -> 2.2.0 kmymoney 4.6.1 -> 4.6.0 libbluedevil 1.9.1 -> 1.9 oxygen-gtk 1.1.5 -> 1.1.4 oxygen-icons 4.7.4 -> 4.7.2 parley 4.7.4 -> 4.7.2 perl-kde4 4.7.4 -> 4.7.2 perl-qt4 4.7.4 -> 4.7.2 phonon 4.6.0 -> 4.5.0 plasma-addons 4.7.4 -> 4.7.2 python-kde4 4.7.4 -> 4.7.2 rekonq 0.8.1 -> 0.8.0 rocs 4.7.4 -> 4.7.2 ruby-kde4 4.7.4 -> 4.7.2 ruby-qt4 4.7.4 -> 4.7.2 step 4.7.4 -> 4.7.2 (original list: http://susepaste.org/71467458) Can you see what has happened here? 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 12 January 2012, Will Stephenson wrote:
Max Lin noticed these packages became downgraded in KDE:Release:47
clemantine 1.0 -> 0.7.3
That was linked from K:D:F before, which had a version upgrade. I think it makes sense to upgrade also to 1.0 in K:D:S, so thats why I did that.
digikam 2.3.0 -> 2.2.0 kipi-plugins 2.3.0 -> 2.2.0
Not really sure if we want to ref digikam to the latest release in KDE:Distro:Stable ??!
kmymoney 4.6.1 -> 4.6.0 libbluedevil 1.9.1 -> 1.9 oxygen-gtk 1.1.5 -> 1.1.4
same here. however here I think it makes sense, so I did that.
oxygen-icons 4.7.4 -> 4.7.2 parley 4.7.4 -> 4.7.2 perl-kde4 4.7.4 -> 4.7.2 perl-qt4 4.7.4 -> 4.7.2 phonon 4.6.0 -> 4.5.0 plasma-addons 4.7.4 -> 4.7.2 python-kde4 4.7.4 -> 4.7.2 rekonq 0.8.1 -> 0.8.0 rocs 4.7.4 -> 4.7.2 ruby-kde4 4.7.4 -> 4.7.2 ruby-qt4 4.7.4 -> 4.7.2 step 4.7.4 -> 4.7.2
Those were bugs, now fixed. Thanks for checking! Greetings, Dirk -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Viernes, 6 de enero de 2012 14:38:53 Dirk Müller escribió:
Hi,
I would like to put KDE 4.8.0 (or 4.8 RC3 rather for now) into KDE:Distro:Factory. The reason is the sooner we start, the better we find the problems.
Currently we have 4.7.4 in KDE:Distro:Factory and in KDE:Release:47. I would like to have your opinion on how to move forward:
a) I copy KDE 4.7.4 from KDE:Distro:Factory to KDE:Distro:Stable, and delink KDE:Release:47 from KDE:Distro:Factory. Then I Import KDE 4.8 into KDE:Distro:Factory and copy whatever is needed from Unstable:SC to make it build and work.
This would mean that future maintenannce updates for 12.1 are based on 4.7.4. I think that is okay, there have even be requests to release 4.7.4 as a maintenance update (in general we're pro this change).
b) I delink KDE:Release:47 from KDE:Distro:Factory and leave it at 4.7.4, and then import KDE 4.8 into KDE:Distro:Factory (and copy whatever is needed from Unstable:SC to make it build and work).
in this case 12.1 updates would stay on 4.7.2, users who want the later fixes would need to switch to KDE:Release:47
I prefer a). any comments?
+1 for a) If by delinking you mean copying (aggregates too, especially libqt4), sounds good to me. Greetings, -- Javier Llorente -- Javier Llorente -- Javier Llorente -- Javier Llorente -- Javier Llorente
On Wednesday, January 18, 2012 10:36:04 PM Javier Llorente wrote:
On Viernes, 6 de enero de 2012 14:38:53 Dirk Müller escribió:
Hi,
I would like to put KDE 4.8.0 (or 4.8 RC3 rather for now) into KDE:Distro:Factory. The reason is the sooner we start, the better we find> the problems.
Currently we have 4.7.4 in KDE:Distro:Factory and in KDE:Release:47. I> would like to have your opinion on how to move forward: a) I copy KDE 4.7.4 from KDE:Distro:Factory to KDE:Distro:Stable, and> delink KDE:Release:47 from KDE:Distro:Factory. Then I Import KDE 4.8 into KDE:Distro:Factory and copy whatever is needed from Unstable:SC to make it build and work.
This would mean that future maintenannce updates for 12.1 are based on> 4.7.4. I think that is okay, there have even be requests to release 4.7.4 as a maintenance update (in general we're pro this change).> b) I delink KDE:Release:47 from KDE:Distro:Factory and leave it at 4.7.4,> and then import KDE 4.8 into KDE:Distro:Factory (and copy whatever is needed from Unstable:SC to make it build and work).
in this case 12.1 updates would stay on 4.7.2, users who want the later> fixes would need to switch to KDE:Release:47
I prefer a). any comments?
+1 for a) If by delinking you mean copying (aggregates too, especially libqt4), sounds good to me.
Greetings, -- Just two cents from a user. /KDE47 appears to have 4.7.4-4.22.1 now but before this last week I thought I had download 4.7.4-6.4 from that repo. Since 4.7.4-6 corrected several problem I had, it would bad if the new 4.7 you are proposing it not at least up to that level. This is repo I use but it wants to downgrade now.
Other than take it appears your Idea would simplify a lot of confusion. http://download.opensuse.org/repositories/KDE:/Release:/47/openSUSE_12.1/ -- Russ -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Thu, Jan 19, 2012 at 2:35 AM, upscope
On Wednesday, January 18, 2012 10:36:04 PM Javier Llorente wrote:
On Viernes, 6 de enero de 2012 14:38:53 Dirk Müller escribió:
Hi,
I would like to put KDE 4.8.0 (or 4.8 RC3 rather for now) into KDE:Distro:Factory. The reason is the sooner we start, the better we find> the problems.
Currently we have 4.7.4 in KDE:Distro:Factory and in KDE:Release:47. I> would like to have your opinion on how to move forward: a) I copy KDE 4.7.4 from KDE:Distro:Factory to KDE:Distro:Stable, and> delink KDE:Release:47 from KDE:Distro:Factory. Then I Import KDE 4.8 into KDE:Distro:Factory and copy whatever is needed from Unstable:SC to make it build and work.
This would mean that future maintenannce updates for 12.1 are based on> 4.7.4. I think that is okay, there have even be requests to release 4.7.4 as a maintenance update (in general we're pro this change).> b) I delink KDE:Release:47 from KDE:Distro:Factory and leave it at 4.7.4,> and then import KDE 4.8 into KDE:Distro:Factory (and copy whatever is needed from Unstable:SC to make it build and work).
in this case 12.1 updates would stay on 4.7.2, users who want the later> fixes would need to switch to KDE:Release:47
I prefer a). any comments?
+1 for a) If by delinking you mean copying (aggregates too, especially libqt4), sounds good to me.
Greetings, -- Just two cents from a user. /KDE47 appears to have 4.7.4-4.22.1 now but before this last week I thought I had download 4.7.4-6.4 from that repo. Since 4.7.4-6 corrected several problem I had, it would bad if the new 4.7 you are proposing it not at least up to that level. This is repo I use but it wants to downgrade now.
Other than take it appears your Idea would simplify a lot of confusion.
http://download.opensuse.org/repositories/KDE:/Release:/47/openSUSE_12.1/
Those numbers are generated automatically, I am not sure you can compare them across repositories like that in a meaningful manner unless one repository directly depends on another, which is not the case here. -Todd -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On Wednesday 18 January 2012 19:23:48 Dirk Müller wrote:
On Thursday 12 January 2012, Will Stephenson wrote:
Max Lin noticed these packages became downgraded in KDE:Release:47
clemantine 1.0 -> 0.7.3
That was linked from K:D:F before, which had a version upgrade. I think it makes sense to upgrade also to 1.0 in K:D:S, so thats why I did that.
digikam 2.3.0 -> 2.2.0 kipi-plugins 2.3.0 -> 2.2.0
Not really sure if we want to ref digikam to the latest release in KDE:Distro:Stable ??!
That's not what I'm suggesting, these downgrades are in KDE:Release:47 after the unlink from KDF.
kmymoney 4.6.1 -> 4.6.0 libbluedevil 1.9.1 -> 1.9 oxygen-gtk 1.1.5 -> 1.1.4
same here. however here I think it makes sense, so I did that.
oxygen-icons 4.7.4 -> 4.7.2 parley 4.7.4 -> 4.7.2 perl-kde4 4.7.4 -> 4.7.2 perl-qt4 4.7.4 -> 4.7.2 phonon 4.6.0 -> 4.5.0 plasma-addons 4.7.4 -> 4.7.2 python-kde4 4.7.4 -> 4.7.2 rekonq 0.8.1 -> 0.8.0 rocs 4.7.4 -> 4.7.2 ruby-kde4 4.7.4 -> 4.7.2 ruby-qt4 4.7.4 -> 4.7.2 step 4.7.4 -> 4.7.2
Those were bugs, now fixed. Thanks for checking!
Great, thanks for fixing. Will -- Will Stephenson | openSUSE Board, openSUSE Boosters Team, KDE Developer SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
On 07/01/12 00:38, Dirk Müller wrote:
Hi,
I would like to put KDE 4.8.0 (or 4.8 RC3 rather for now) into KDE:Distro:Factory. The reason is the sooner we start, the better we find the problems.
Currently we have 4.7.4 in KDE:Distro:Factory and in KDE:Release:47. I would like to have your opinion on how to move forward:
a) I copy KDE 4.7.4 from KDE:Distro:Factory to KDE:Distro:Stable, and delink KDE:Release:47 from KDE:Distro:Factory. Then I Import KDE 4.8 into KDE:Distro:Factory and copy whatever is needed from Unstable:SC to make it build and work.
This would mean that future maintenannce updates for 12.1 are based on 4.7.4. I think that is okay, there have even be requests to release 4.7.4 as a maintenance update (in general we're pro this change).
b) I delink KDE:Release:47 from KDE:Distro:Factory and leave it at 4.7.4, and then import KDE 4.8 into KDE:Distro:Factory (and copy whatever is needed from Unstable:SC to make it build and work).
in this case 12.1 updates would stay on 4.7.2, users who want the later fixes would need to switch to KDE:Release:47
I prefer a). any comments?
Thanks, Dirk
Hi Dirk, You raised this issue on 7 January and I see that there are 43 posts in this thread - and, unfortunately, I just am not able to wade thru all of them to see what the final outcome is of your proposal. So, what is the final outcome? Where is KDE 4.8 available or is it not available, please? BC -- It is in the nature of things that every time you try to avoid one danger you run into another. Niccolo Machiavelli -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
participants (20)
-
Anton Aylward
-
Basil Chupin
-
C
-
Christian Trippe
-
Dirk Müller
-
Dirk Müller
-
Ismail Dönmez
-
Javier Llorente
-
K. Dennis Leyendecker
-
Kim Leyendecker
-
Křištof Želechovski
-
Mariusz Fik
-
Markus Slopianka
-
Martin Schlander
-
Peter Linnell
-
Roger Luedecke
-
Sven Burmeister
-
todd rme
-
upscope
-
Will Stephenson