Or Is distro’s backporting of features a good thing or Distro A is much better than Distro B because of the cool features
So. Advantages when backporting features
- Your distro is part of the “cool ones” amongst the users
Disadvantages:
- Upstreams dislike you because the code might be a weird mix that they never wanted to release, but they still get the bug reports
- Error prone work for distros
- Issues with new untranslated strings
- More maintainance work for distributers
In KDE4, several distros backports loads of features (Plasma panel autohide, plasma tooltips, kwin “cube” effect and other things).
Several distros include mandriva, suse, kubuntu and fedora.
So should we in Debian follow the other distros? Should KDE change policies? Should distros stop backporting features? Something else? Sharing the patches among the distributions is of course easy.
(Please note: I’m only talking about features, not bugfixes
I remember when distros started shipping Pilot Link 0.12 preview releases against the Pilot Link developers’ wishes, the PL people pulled the easy code downloads and made it impossible for anyone who wasn’t a “pro” to get the code. There wasn’t even repository information available for potential contributors.
I don’t really have a point or agenda behind bringing this up. It’s just the only example of this type of thing I’m familiar with is all.
The most important thing is that the end user gets an honest release. Which means something that upstream was satisfied with and actually did release for users to use.
Anything else the distros should not call a kde release.
People using suse with broken autohide in something called kde4.1 are not using a kde4.1 release. But all impressions of that end user will be about 4.1
We already had reviews of KDE being completely biased because the reviewer was using a rather broken distro.
I don’t know the solution, but I do know its a big problem when distros ship unreleased and unfinished code. Sadly thats becoming the norm and both KDE and the Linux images suffer.
Distros should do whatever they like best. They should, also, insist that users always report bugs with their own bug trackig system and concentrate on working with upstream.
Freeing the user from the necessity of cobbling together their system from various sources is, after all, the main motivation for having a distribution at all, so why not extend this to the bugs? (I have the distinct impression that, at least in Debian, upstream bugs are often not much liked in the bts…)
Hello,
distro should only distribute approved upstream bundle. The job of the distro is only to assemble bundle, not backporting feature etc…
When i’am using kde 4.1 for example i want to use the real 4.1 not some 4.1+my distro backported feature with some bugs …
Hi,
@Benoit Sorry, but I have to disagree. It’s (L)GPL, everybody is allowed to whatever they want. I welcome any backporting as long as it is well tested and supported from my distribution. It is a privilege to be able to use some feature without having to wait a few months for the next release. Any bug-reports should go to the distribution, of course, and the distribution must take the responsibility to sort through bug-reports and figure out which bugs should be forwarded up-stream.
Hi,
While i agree with backports, generally speaking, i also think that those backports should be done with extreme care… I’d rather use a somewhat-older-but-stable software than a mix-the-old-with-this-new-hyped-feature-but-not-tested version of the said program…
I’m runing KDE4 on both gentoo and opensuse, and as a user I’m actually annoyed at opensuse’s backported features, which I blame for the instability.
I know autohide is comming, and I can easyly wait a few months to get a clean version of it.
If a distro follows upstream releases, I can rejoice at the same time as everyone else, and read the changelog to know what I’m installing. There’s less re-downloading of the “same” upstream version, and when there is I have great confidense that it’ll do more good than harm.
I had decided to try opensuse on my new laptop because it was touted to have the best KDE4 around. After seeing at what price it comes, I’m going to switch to a purer binary distro (thanks for pointing out “bad” distros in this post).
Please, do not stop back porting all together.
For business users (like me), sometimes back porting gives access to features that we seriously need, without having to perform re installation and / or without abandoning stable and well tested platforms.
If the back ported application is then unstable or does not work appropriately, we can then uninstall and reinstall older stable versions.
It is very important that back ports are kept SEPARATE (that is in a separate repository, that may be switched on / off on need), so that we may easily go back to the previous stable version of the application, and are only released when they are STABLE
It would be very nice if we could have the back ports installed in a separate folder (for example: /opt/), without overwriting the older version (with the possibility of running the older version of the application). For example: kdewebdev / kdewebdev-backport, with separate icons.
What do you think?
PS: bug fixes should always be back ported, in my opinion.
I think backporting features has more advantages than disadvantages.
More features mean more bugs and maybe more bugreports, but bugreports are good as long as they are handled correct, i.e. user -> distro -> upstream
A user that misses a feature may be unhappy, a user getting a demanded feature, knowing about the backporting will not be to angry about 1 or 2 more bugs.
But all that depends much on each ones preferences and opinion, so i think the solution is to leave that decision to the packagers and users.
If the packager puts a feature the user has to decide if he accepts or leave to an other distro. You wont get all to the same opinion on that.
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.
@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.
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
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 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 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.
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.
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
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.
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.