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