![]() Registered Member ![]()
|
Aaron Seigo had an interesting blog post some time ago about how many distros backport unfinished features before they are actually released, and I was wondering what everyone thinks of it.
Get problems solved faster - get reply notifications through Jabber!
|
![]() KDE Developer ![]()
|
From a developer's point of view:
- I'd rather not have things backported as it allows easier debugging of older bugs and keeps the older releases stable and less complaints from users. - I'd rather things be backported so we have more testing done before the next release. If the code is buggy then only one distribution will have those bugs while all others are safe. Meh. Best solution: Before code is backported distributions should check with the developers to see if it's safe to do so.
Last edited by Zarin on Sun Nov 02, 2008 6:36 am, edited 1 time in total.
|
![]() Registered Member ![]()
|
I'd rather wait. I like to play with the new features as much as the next guy, but I've noticed too many bugs when backports have been introduced into the distros I've tried.
OpenSUSE 11.4, 64-bit with KDE 4.6.4
Proud to be a member of KDE forums since 2008-Oct. |
![]() Registered Member ![]()
|
I think it's better to wait the official release by the KDE developers
Amine27, proud to be a member of KDE forums since 2008-Oct.
![]() |
![]() Registered Member ![]()
|
What are his toughts on removing something like kubuntu did with activity?
The distro have to deliver a product that is usable and there users request options they need, and for something i see a need to backport.
Last edited by Dryfit on Sun Nov 02, 2008 9:00 am, edited 1 time in total.
Dryfit, proud to be a member of KDE forums since 2008-Oct.
|
![]() KDE Developer ![]()
|
This thread outlines the reasons why we disabled the ZUI for 8.10:
http://dot.kde.org/1225379191/1225390809/1225398281/ |
![]() Registered Member ![]()
|
I know the reason, but if its a problem to put some backporting in i can understand that taking something out can also be. Because now you don't get reports in og that piece that is taken out. I would be better to solve that problem then take it out and submit it up.
Dryfit, proud to be a member of KDE forums since 2008-Oct.
|
![]() Administrator ![]()
|
I'm not too fond on excessive backporting. Especially when feature backports come from a trunk that's not feature frozen yet, so the things may still changing.
"Violence is the last refuge of the incompetent."
![]() Plasma FAQ maintainer - Plasma programming with Python |
![]() Registered Member ![]()
|
Imho it is double work. But if it is as bugless as in Trunk and if Devs dont get distracted im ok with it.
PeperJohnny, proud to be a member of KDE since 2006-Dec.
Do you dare? ![]() |
![]() Registered Member ![]()
|
Backporting is a symptom of the fact that KDE 4.1 is not feature-complete for a significant amount of users. I personally have had to download a lot of alpha plasmoids from kde-look just to get the features I was used to in 3.x.
Distros want a feature-complete desktop to offer their users. They also want something new to offer users in the new release. When you hear about features going into 4.2, and you know it's not going to be out until (at least) January, I can see how it's tempting to want to have backported features to give out *now*. Of course I don't want to second-guess the intentions of the distro folks, but that's how I'd see it. I guess if the KDE team wants bug reports based on their official releases, they need to either work with a distro to provide a vanilla kde release, or release packages for popular distros themselves. Expecting any great amount of users to compile KDE from source is not realistic; I've compiled a lot of things, but I gave up trying to do KDE.
admoore, proud to be a member of KDE forums since 2008-Oct.
|
![]() KDE Developer ![]()
|
I don't think this is realistic in any case, there will always be changes, customizations, etc. All bug reports for software from distribution packages should always go to the distribution bugtracker first, so their developers can figure out if the had any changes there and if they could cause the problem. When they are certain it is an upstream problem, they can always forward the bug, probably with additional information gained during their screening process. Backports just make the problem of downstream bugs in KDE's bugtracker more obvious. Cheers, _
anda_skoa, proud to be a member of KDE forums since 2008-Oct.
|
![]() KDE Developer ![]()
|
Problem: Bugs are rarely forwarded. Whenever I go make a random visit to a distro's tracker I always see one or two valid bugs that are not on the KDE tracker. The more people that a report needs to go through the less likely it will make it to the end. |
![]() KDE Developer ![]()
|
True. Will also depend very much on the activeness of the distributor's KDE team. Ideally all bugtrackers would be linked so forwarding would be an easy task for the downstream developer and probably allow an upstream developer to claim a bug from the downstream database.
Also true, but as the amplified situation with backports show, the more bugs are actually the fault of downstream changes, the more the developers are likely to ignore any report from users of those distributions. Another option might be to have all bugs upstream but keep them at "UNCONFIRMED" until at least one downstream developers has confirmed it. Cheers, _
anda_skoa, proud to be a member of KDE forums since 2008-Oct.
|
Registered users: Bing [Bot], Evergrowing, Google [Bot]