Comments on: Is something wrong with KDE patch backport policies? http://pusling.com/blog/?p=89 Seeing stuff the wrong way Wed, 11 Aug 2010 12:53:34 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Dummy00001 http://pusling.com/blog/?p=89&cpage=1#comment-2104 Dummy00001 Wed, 22 Oct 2008 20:36:21 +0000 http://pusling.com/blog/?p=89#comment-2104 In case of KDE4, is it possible to actually have in repos both versions: KDE4 mainline and KDE4 patched to be useful? With some virtual metapackages to install them. Problem with bug reports can be solved on technical level, by making version string distinctive so that upstream can easily filter the invalid bug reports. People who are into testing can try to switch to vanilla KDE4 to see whether the problem is of distro or of KDE4 itself. As developer frankly I have only negative experience with backporting - even when I was in end-user modus operandi. e.g. in RHEL you can never be sure what version of software (gcc, glibc) precisely you are using. SLES and RHEL were running like ages on kernel "2.6.5" which was at a time sort of functional equivalent of 2.6.12. This is nightmarish scenario for development and for users who want to submit bug reports. In part I always preferred Debian because it did least of patching. And in case of KDE4, frankly, I think it should NOT be shipped just yet, since many crucial for desktop applications are not there yet. 3.5.x is safe bet. KDE4: option - yes; default - no. And no backported features - to make future updates from upstream easier. In case of KDE4, is it possible to actually have in repos both versions: KDE4 mainline and KDE4 patched to be useful? With some virtual metapackages to install them.

Problem with bug reports can be solved on technical level, by making version string distinctive so that upstream can easily filter the invalid bug reports.

People who are into testing can try to switch to vanilla KDE4 to see whether the problem is of distro or of KDE4 itself.

As developer frankly I have only negative experience with backporting – even when I was in end-user modus operandi. e.g. in RHEL you can never be sure what version of software (gcc, glibc) precisely you are using. SLES and RHEL were running like ages on kernel “2.6.5″ which was at a time sort of functional equivalent of 2.6.12. This is nightmarish scenario for development and for users who want to submit bug reports.

In part I always preferred Debian because it did least of patching. And in case of KDE4, frankly, I think it should NOT be shipped just yet, since many crucial for desktop applications are not there yet. 3.5.x is safe bet. KDE4: option – yes; default – no. And no backported features – to make future updates from upstream easier.

]]> By: Israel Vinícius Nogueira Miranda http://pusling.com/blog/?p=89&cpage=1#comment-2101 Israel Vinícius Nogueira Miranda Tue, 21 Oct 2008 16:59:11 +0000 http://pusling.com/blog/?p=89#comment-2101 I think we need backports, but the efforts to implement it should be minimal. I think we should try to push the current version of kde into the testing (in debian distro) release. I think we need backports, but the efforts to implement it should be minimal.
I think we should try to push the current version of kde into the testing (in debian distro) release.

]]> By: Fred http://pusling.com/blog/?p=89&cpage=1#comment-2100 Fred Tue, 21 Oct 2008 09:29:28 +0000 http://pusling.com/blog/?p=89#comment-2100 Hi, I think backporting bugfixes is no question. It's a good thing. For features intoduced WHILE the distro lifetime it is a bit different. It is likely that new features introduce new bugs. That's bad for a system that is supposed to work. Backporting features BEFORE releasing the distro has different problems. Like the user beings thrown stones at if he reports bugs upstream. I saw that many times with Firefox a few years ago. It makes you cry a little bit inside. :) My opinion: Please try to stay as close to upstream as possible. Regards Hi,

I think backporting bugfixes is no question. It’s a good thing.
For features intoduced WHILE the distro lifetime it is a bit different. It is likely that new features introduce new bugs. That’s bad for a system that is supposed to work.
Backporting features BEFORE releasing the distro has different problems. Like the user beings thrown stones at if he reports bugs upstream. I saw that many times with Firefox a few years ago. It makes you cry a little bit inside. :)

My opinion: Please try to stay as close to upstream as possible.

Regards

]]> By: Malkavian http://pusling.com/blog/?p=89&cpage=1#comment-2098 Malkavian Tue, 21 Oct 2008 01:25:45 +0000 http://pusling.com/blog/?p=89#comment-2098 Debian is released when it is ready. If KDE 4 isn't ready, it isn't for Debian. Would be nice to include KDE4 in next actualization if possible. Stable is stable. I recommend testing for users that want a cool desktop. Debian is released when it is ready. If KDE 4 isn’t ready, it isn’t for Debian. Would be nice to include KDE4 in next actualization if possible. Stable is stable. I recommend testing for users that want a cool desktop.

]]> By: ScottK http://pusling.com/blog/?p=89&cpage=1#comment-2096 ScottK Sun, 19 Oct 2008 22:16:01 +0000 http://pusling.com/blog/?p=89#comment-2096 I think it depends. As an example, the tooltips backport in Kubuntu is probably my fault. I didn't do it, but I convinced someone else to do it. With a 4.1.2 release coming up we have to make some hard choices. 4.1 lacks some features of KDE3. For my use patter the tooltips are a big deal that I would have really missed and so I'm glad their backported. Some things we can squeeze in, not others. I agree that bugs against 4.1 for backported features belong to the distro and not to upstream. I think it depends.

As an example, the tooltips backport in Kubuntu is probably my fault. I didn’t do it, but I convinced someone else to do it. With a 4.1.2 release coming up we have to make some hard choices. 4.1 lacks some features of KDE3. For my use patter the tooltips are a big deal that I would have really missed and so I’m glad their backported. Some things we can squeeze in, not others.

I agree that bugs against 4.1 for backported features belong to the distro and not to upstream.

]]> By: SadEagle http://pusling.com/blog/?p=89&cpage=1#comment-2093 SadEagle Sat, 18 Oct 2008 03:07:02 +0000 http://pusling.com/blog/?p=89#comment-2093 I won't really comment much on the issue of feature backports, but rather an another practice: packages that have lots of patch backports. SuSE does it in some of their package sets (I don't know the detail of what they offer, just that such a set exists), and while it's great to get the bugfixes out there, it's also an utter pain to try to sort things out when something goes wrong. Simply put, when I get a bug report from such a package it can't be correlated easily to any state of SVN --- one has to dig through the RPM for the patch file, the spec files to see what gets applied, etc. Distros picking up patches lightly also makes it much harder to time application of patches --- for example, it may make sense to apply a slightly risky bugfix right after a point release, to give it additional non-developer testing for a month or so from the powerusers who build from SVN... Yet if a distro pulls that in that may go out to a wide audience when something was wrong. So, I guess what I am saying is that even bugfix inclusions have to be prioritized and should not be used lightly. Incorporating a fix for an important bug quickly can be a huge benefit to users, yet incorporating less important changes carelessly can be a detriment to quality. And I guess I should say something with respect to the feature backports: does the person doing the backport have a sufficient understanding of the relevant codebase? I won’t really comment much on the issue of feature backports, but rather an another practice: packages that have lots of patch backports. SuSE does it in some of their package sets (I don’t know the detail of what they offer, just that such a set exists), and while it’s great to get the bugfixes out there, it’s also an utter pain to try to sort things out when something goes wrong. Simply put, when I get a bug report from such a package it can’t be correlated easily to any state of SVN — one has to dig through the RPM for the patch file, the spec files to see what gets applied, etc. Distros picking up patches lightly also makes it much harder to time application of patches — for example, it may make sense to apply a slightly risky bugfix right after a point release, to give it additional non-developer testing for a month or so from the powerusers who build from SVN… Yet if a distro pulls that in that may go out to a wide audience when something was wrong.

So, I guess what I am saying is that even bugfix inclusions have to be prioritized and should not be used lightly. Incorporating a fix for an important bug quickly can be a huge benefit to users, yet incorporating less important changes carelessly can be a detriment to quality.

And I guess I should say something with respect to the feature backports: does the person doing the backport have a sufficient understanding of the relevant codebase?

]]> By: IAnjo http://pusling.com/blog/?p=89&cpage=1#comment-2092 IAnjo Fri, 17 Oct 2008 18:33:11 +0000 http://pusling.com/blog/?p=89#comment-2092 I think limited backports are a good thing. Plasma backports are very talked about these days, and I can understand the reasons: as much as I know that a feature is coming, and how cool is plasma (I have been using kde 4 apps since the .0 alphas, and have completely switched to a full kde 4 session since 4.0.0, day one), most users regard plasma shortcomings very badly, and feel like plasma is a bit of a regression on some features they find essential, so distros, especially opensuse, try to backport some features to make the user feel more at home, in the current version. For example I know someone that has used kde since 1.x -- he started compiling and using it on a sun workstation. Since a few versions he's been a big opensuse fan, and when opensuse 11.0 came out with kde 4 he quickly upgraded to it, but has since decided to go back to a kde 3 desktop because plasma was lacking a feature he thought has essential: panel hiding. With opensuse's backport of panel hiding, it seems he will be able to use kde 4(.1) and opensuse 11.1 soon, and enjoy all the new kde goodnesses :) So I think opensuse and other distros backporting some features are doing the right thing here. Also, plasma is getting very good nowadays, so I think that soon these backports won't be so needed, because enough infrastructure will be in place that distros can just ship their changes as normal applets, that the user can remove and replace with upstream ones. I think limited backports are a good thing.

Plasma backports are very talked about these days, and I can understand the reasons: as much as I know that a feature is coming, and how cool is plasma (I have been using kde 4 apps since the .0 alphas, and have completely switched to a full kde 4 session since 4.0.0, day one), most users regard plasma shortcomings very badly, and feel like plasma is a bit of a regression on some features they find essential, so distros, especially opensuse, try to backport some features to make the user feel more at home, in the current version.

For example I know someone that has used kde since 1.x — he started compiling and using it on a sun workstation. Since a few versions he’s been a big opensuse fan, and when opensuse 11.0 came out with kde 4 he quickly upgraded to it, but has since decided to go back to a kde 3 desktop because plasma was lacking a feature he thought has essential: panel hiding. With opensuse’s backport of panel hiding, it seems he will be able to use kde 4(.1) and opensuse 11.1 soon, and enjoy all the new kde goodnesses :)

So I think opensuse and other distros backporting some features are doing the right thing here. Also, plasma is getting very good nowadays, so I think that soon these backports won’t be so needed, because enough infrastructure will be in place that distros can just ship their changes as normal applets, that the user can remove and replace with upstream ones.

]]> By: holbach http://pusling.com/blog/?p=89&cpage=1#comment-2091 holbach Fri, 17 Oct 2008 17:29:44 +0000 http://pusling.com/blog/?p=89#comment-2091 Despite liking and using new features I rather have a stable system for several reasons. That is why I use debian stable even for desktops if i can. No other distribution has that high release qualities and I have used gentoo, kubuntu and opensuse and redhat already. It simply keeps the problems out of my way instead of introducing new ones. Giving the fact that especially KDE 4 is still bug prone the decision to keep with 3.5 was a really good one that shows how mature the debian community is. Now there is the backport repository with an explicit backport. If you ship a backported feature by default the average user will *NOT* know this is distro-specific and you will have certainly new bugs (associated to upstream). If you get a release from upstream the payoff between missing features and stability is judged best from the developers, there is nobody else knowing the code as well as they do+they know there targets for the future. This does not state against special mixed distributions in seperate package repositories, but please keep the base as bugfree as possible. Linux (vs. BSD) and KDE (vs. Gnome) are very feature oriented already and we don't want a cloned Windows XP code mess, do we? A stressing bug is a stressing problem, a missing feature is just an invisible possibility and can still be fixed by installing an alternative or if really necessary an upstream source build. Cheers, holbach Despite liking and using new features I rather have a stable system for several reasons. That is why I use debian stable even for desktops if i can. No other distribution has that high release qualities and I have used gentoo, kubuntu and opensuse and redhat already.
It simply keeps the problems out of my way instead of introducing new ones. Giving the fact that especially KDE 4 is still bug prone the decision to keep with 3.5 was a really good one that shows how mature the debian community is.
Now there is the backport repository with an explicit backport. If you ship a backported feature by default the average user will *NOT* know this is distro-specific and you will have certainly new bugs (associated to upstream).
If you get a release from upstream the payoff between missing features and stability is judged best from the developers, there is nobody else knowing the code as well as they do+they know there targets for the future. This does not state against special mixed distributions in seperate package repositories, but please keep the base as bugfree as possible. Linux (vs. BSD) and KDE (vs. Gnome) are very feature oriented already and we don’t want a cloned Windows XP code mess, do we?
A stressing bug is a stressing problem, a missing feature is just an invisible possibility and can still be fixed by installing an alternative or if really necessary an upstream source build.

Cheers,
holbach

]]> By: Javier Berezovsky http://pusling.com/blog/?p=89&cpage=1#comment-2090 Javier Berezovsky Fri, 17 Oct 2008 14:44:56 +0000 http://pusling.com/blog/?p=89#comment-2090 @gunni I agree and disagree at the same time. I understand that the idea of having bug reports seems good, but the bug reports are being sent to KDE and not the distro, and when that happens, it is for a feature that was implemented against earlier code than it should have been, and most likely the bugs might already be fixed in the proper code in which the feature had been added. In that case, the bugs would be caused because of the backport itself and the reports would only confuse developers trying to find and fix those bugs. @gunni

I agree and disagree at the same time. I understand that the idea of having bug reports seems good, but the bug reports are being sent to KDE and not the distro, and when that happens, it is for a feature that was implemented against earlier code than it should have been, and most likely the bugs might already be fixed in the proper code in which the feature had been added.
In that case, the bugs would be caused because of the backport itself and the reports would only confuse developers trying to find and fix those bugs.

]]> By: Manabu http://pusling.com/blog/?p=89&cpage=1#comment-2089 Manabu Fri, 17 Oct 2008 13:54:43 +0000 http://pusling.com/blog/?p=89#comment-2089 I like the idea of "Aways Summer (or better, spring) on the Trunk" using git, mercury, bazaar, whatever. So there is no waiting for an new release to get an new feature. You can get as soon as the upstream feels that it is ready. Then distros should only take the latest snapshot possible. If an distro wants to add an new untested feature, they should work with upstream sending their improviments and waiting to it reach trunk. If the upstream is too slow, thinks that the feature isn' t mature yet, or simply reject the paches, the distro can release their own flavor, but clearly stating so (Ktorrent 3.2.distroxyz, for example). Then asking that bugs be reported to the distro. I generaly report bugs to developers because I don't know wether my binary is modified by my distro or not. That is my 2 cents. I like the idea of “Aways Summer (or better, spring) on the Trunk” using git, mercury, bazaar, whatever. So there is no waiting for an new release to get an new feature. You can get as soon as the upstream feels that it is ready. Then distros should only take the latest snapshot possible.

If an distro wants to add an new untested feature, they should work with upstream sending their improviments and waiting to it reach trunk. If the upstream is too slow, thinks that the feature isn’ t mature yet, or simply reject the paches, the distro can release their own flavor, but clearly stating so (Ktorrent 3.2.distroxyz, for example). Then asking that bugs be reported to the distro. I generaly report bugs to developers because I don’t know wether my binary is modified by my distro or not.

That is my 2 cents.

]]>