Troy Unrau ([info]troy_at_kde) wrote,
@ 2007-08-20 11:57:00
Previous Entry  Add to memories!  Tell a Friend  Next Entry
Entry tags:ars, distro, kde, upstream

A nudge in the right direction
So, I know I'm not alone on this topic but I will represent these opinions as my own for the sake of taking the brunt of the fury upon myself alone. I recently wrote an article about the complex relationship that exists between various open source projects, especially when it comes to dealing with upstream projects.

Now, the reason I wrote this article in the first place is to compliment a few distributions on how they are (as a result of KDE 4.0) sending some of their better work upstream to KDE. Some examples include: Ark Linux's recent announcement that they'd be moving all of their hardware stuff into Solid (which is awesome and I hope all the other KDE distros follow suit), and Kubuntu's contribution of System Settings to fill the void of KControl being mostly decommissioned. We, as the KDE community really need to applaud these distros when they take steps in the right direction and keep the upstream happy, and I for one would be happy to give press to any distro making contributions to KDE *nudge nudge*. This is really the only positive reinforcement that I can offer to the distros to take this action as I am only an individual.

But the way that the distros deal with KDE is not always rosy, and there are a lot of examples in the past where a distro has done its own thing to KDE and their own detriment. I will provide a few example here, but what I'm really looking for is comments on what the KDE developers and users consider to be the worst examples.

Example #1: OpenSuse managed to make it so that KDE 3.5.x does not depend upon aRts for multimedia, which is nice. But instead of making a KDE 3.6.x branch or similar within KDE's sources, they did it in an internal fork of 3.5.x. Now I recognize that KDE is moving fast towards KDE 4.x and would not really want to deal with releasing a KDE 3.6 series at this point, but it would have at least been nice to have it live somewhere within KDE's source trees so that other distros can more easily take advantage of this rather useful improvement. But instead, we now have users joining #kde with multimedia problems on opensuse that we cannot help in any way, since they are using a fork. (On a side note: Phonon should put this problem to rest once-and-for-all in KDE 4, finally!)

Example #2: Kubuntu changes many of the menus in Konqueror, which is designed to simplify the whole interface. This is a noble objective, and is good for their users (as long as their users don't need any support from the KDE community, or don't want to file bugs against KDE). The problem is that they've broken a number of things as a result. For example: in the default Konqueror menu, there's a "Save View Changes per Folder" checkbox in the "Settings" menu - this menu item was removed, and set to True by default. Now the only way for Kubuntu users to change this setting is to edit the config file by hand. A better solution would have been to put this setting into Konq's config dialog, and removed it from the menu upstream, in KDE, so that all users could benefit from removing a seldom used menu item.

These are only two examples, and many distributions are guilty behaving in this fashion. With KDE 4.0 here, it is the perfect chance for these distros to cast aside their patches, or to get them into KDE proper, and I really want to encourage the distros to accomplish this goal.

So, as part of my gentle nudging, I am looking for comments. What do you find are the worst changes that distros have made to KDE in the past (as well as a note if the problem was resolved or not)? What are some of the best changes made by distributions that should have been merged into KDE proper?

And to the distributions, what are the prospects of getting this work moved into KDE? (Remember, I can give good press for these contributions, which makes your distro look more appealing to the general public - mindshare and so forth.) I don't really want to negatively reinforce the major failures so much as I want to positively reinforce good behaviour via press.

Cheers folks

Edit: Oh, by the way, the 'recent' article I refer to in the first paragraph is available at Ars Technica and is only like a day old. It's probably worth reading as I talk about KDE a lot in that one. Inge Wallin tells me I should blog here every time I have an article worth reading, just to draw attention to them - but I'm not sure if that's shameless self-promotion, or just allowing people to find my stuff easier :)




(27 comments) - (Post a new comment)

reply
(Anonymous)
2007-08-20 05:52 pm UTC (link)
You're a bit hard on SuSE there, firstly they contribute more to KDE than any other distro and secondly the kdemm stuff they use in place of arts was developed within KDE as the predecessor to Phonon. You have a point though, SuSE/Novell developments like kpowersave, kio-sysinfo or plugger would arguably be better developed upstream where others can more easily contribute to make them more general.

I deliberately removed a bunch of items from Konqueror's menus as part of a much needed simplification in Kubuntu. Where people have complained loud enough that they need a particular feature back I've put it back but I've not heard of anyone missing this feature which I take to mean that it just does the right thing.


(Reply to this) (Thread)

Re: reply
[info]troy_at_kde
2007-08-20 06:04 pm UTC (link)
The above was written by Riddell, who forgot to sign his name :P

(Reply to this) (Parent)

Re: reply
[info]eeanm
2007-08-20 10:40 pm UTC (link)
I agree with you. Its important to ignore critics calling who might call you a Gnome and remove silly options.

The best way to remove a feature is to just remove it and then see if anyone complains, in my experience. :)

(Reply to this) (Parent)

Re: reply
(Anonymous)
2007-08-20 11:11 pm UTC (link)
> Where people have complained loud enough that they need a particular feature back I've put it back but I've not heard of anyone missing this feature which I take to mean that it just does the right thing.

The problem is that a number of our Kubuntu users, specially those new to Linux or KDE, never actually know that some things are missing, causing them to think that there is no such feature. For example, some users think that Konqueror has no History and think that it sucks, or that they don't know that you can simply split a Konqueror window horizontally or vertically.

Our more seasoned/familiar users have already just accepted the fact that Kubuntu has changed it and it will remain to be so. Most of them just reverted to the old Konqueror configuration and just keep silent. But they do grumble once in a while, perhaps not loud enough to be heard?

- Jucato

(Reply to this) (Parent)(Thread)

Re: reply
[info]eeanm
2007-08-20 11:22 pm UTC (link)
I just looked for History in the menus of my (KUbuntu) Konqueror and it can't be found. You have to Show Navigation Panel and then click on a (unlabeled) clock. The [removed] Go menu does seem handy especially for the novice user.

I know Apple has a theory that everything should be accessible from the main menu. I don't agree, just look at iTunes. But certainly common tasks should all be accessible.

The split stuff is still there under View, makes sense.

(Reply to this) (Parent)

Re: reply
(Anonymous)
2007-08-21 11:58 am UTC (link)
This is not really true. There are things that SUSE does because they improve the linux experience. Those are for example kpowersave and sysinfo:/. Those are not portable to non-Linux, and shouldn't therefore be maintained as part of KDE.

Not having them in KDE is perfectly fine you know, the only thing that might be missing is some cross-distribution collaboration on those projects that do not fit into KDE upstream, instead of silently taking over suse patches and then bitching about them not being upstream.

(Reply to this) (Parent)(Thread)

Re: reply
(Anonymous)
2007-08-21 09:27 pm UTC (link)
Oh, if you think this way I wonder what they should do with kwin or plasma?

(Reply to this) (Parent)

Re: "not portable to non-Linux"
(Anonymous)
2007-08-24 09:35 am UTC (link)
> Those are not portable to non-Linux, and shouldn't therefore be maintained as part of KDE.

You're wrong here. This is just the definition of compile-time configuration. Include it upstream and enable it to be disabled.

(Reply to this) (Parent)(Thread)

Re: "not portable to non-Linux"
(Anonymous)
2008-01-09 08:25 am UTC (link)
ok

(Reply to this) (Parent)

Re: reply
(Anonymous)
2007-08-21 11:36 pm UTC (link)
> You have a point though, SuSE/Novell developments like kpowersave,
> kio-sysinfo or plugger would arguably be better developed upstream
> where others can more easily contribute to make them more general.

We're working on doing just that with respect to powermanagement. For KDE4, the plan is to have one good powermanagement solution to rule them all. The basis for that will be kpowersave. Danny, I and Kevin have discussed that during aKademy, details can be found on the hardware-devel (http://lists.kde.org/?l=kde-hardware-devel&m=118374720211142&w=2) list.

-- sebas (with kubuntu powermanager hat on)

(Reply to this) (Parent)

elveo
(Anonymous)
2007-08-20 07:59 pm UTC (link)
kubuntu changes to konqueror task bars / interface is much cleaner than the default. should go upstream, imho. good work!

(Reply to this) (Thread)

Konqueror changes in Kubuntu
(Anonymous)
2007-08-21 09:49 am UTC (link)
On the whole I would agree with one notable exception - the changes to the "View mode" behaviour, which I have tried and tried to overcome without success. The policy of one button for all the view modes is a disaster is my opinion - having three is much better, and is notably the policy of Dolphin which makes it very easy to switch between icons and list mode, and even has keyboard shortcuts.

By all means get rid of the seldom used modes, but changing modes is a very frequent operation that should be easier than moving the mouse, clicking on an icon, waiting for the drop-down list to appear (or move the mouse downwards), and then selecting an item from the list. I have tried the unofficial patch, via the bug tracker, I have tried switching back to Konqueror defaults, even copying across other distro config files.

If I have one request for the Kubuntu team, it is please make changing views in Konqueror easier! Thank you!

(Reply to this) (Parent)(Thread)

Re: Konqueror changes in Kubuntu
(Anonymous)
2007-08-24 07:43 am UTC (link)
I believe this has been reverted in the next release (Kubuntu 7.10 Gutsy Gibbon). Sometimes developers only get so little feedback with new features that they are introducing. Very few people help in running/testing alpha/beta releases, so mass feedback sometimes comes a bit too late.

The good news is that they often get the message, loud and clear. :)

- Jucato

(Reply to this) (Parent)

It's not like the sources are not available
(Anonymous)
2007-08-20 08:05 pm UTC (link)
I agree that keeping things in separate KDE trees can be very handy, but let us be clear here -- everything that openSUSE change is fully available; the RPM sources are all online, etc. Nothing is exactly being done in secret. If others would particularly like it all developed somewhere in KDE's svn I genuinely wonder if anyone asked them. If not, I wonder why we're complaining already. Have you?

> With KDE 4.0 here, it is the perfect chance for these distros to cast aside their patches, or to get them into KDE proper, and I really want to encourage the distros to accomplish this goal.

Distributions will _always_ have patches, and I really think it would be horrible if this was not the case. One of the glories of trying out distributions is seeing what extra little things have been added in, but also -- modifying software and distributing it such a core component of what free software is all about. Of course, there is a line here. Large and controversial KDE changes can be a really bad call sometimes. We want KDEs on different distributions to in general behave the same way, but I hardly think we should be in the business of not promoting the idea of distributions adding in their little patches. Obviously there is a lot more to be said on this.

Just a small note also that you have not appropriately written 'openSUSE'; I only mention it because you also wrote it that way in your Ars Technica article. :)

~ apokryphos

(Reply to this)


[info]eeanm
2007-08-20 11:14 pm UTC (link)
A good example of downstream mucking things up is Fedora taking some code gstreamer code out of SVN, enabling its compilation (it was disabled) and then we find ourselves dealing with Fedora users wondering why things don't work right.

This ended up with a private amicable email exchange with the Fedora maintainer who actually flat out said Fedora doesn't care much about multimedia. I wrote a blog about it.

Another example would be Suse using I think Akode as the default engine during 1.2 or 1.3 or something. At that point at least, akode and/or our akode engine was very buggy. At some point they also had an Amarok engine which acted as a 64-bit wrapper around the 32-bit Helix engine, (since Helix is 32 bit only). It was really quite buggy, in its early (released!) state it wouldn't go to the next track when the track that was playing finished.

They got better with this sort of thing though, Suse did submit their Yauap engine to Amarok during 1.4 and it still lives in our SVN, though I don't know quite what its for.

Anyways... I'm somewhat scared of not being able to control the engines with Phonon due to the history of distros making bad decisions (since the corporate distros have lawyers nagging them instead of users). Currently we just have a phonon-xine engine, so so-far so good. :)

(Reply to this)

Great debate. Here are my suggestions and experiences
(Anonymous)
2007-08-20 11:19 pm UTC (link)
I definitely agree with the spirit of your post. From the point of view of someone who has been administering, supporting and implementing kde-based solution for over 5 years, one of the hardest things to deal with is the fact that each distribution often appear like totally distinct operating systems. While under the hood, the tools are very similar, when you are trying to walk someone over the phone on how to do accomplish something, it is harder when Debian's KDE menu is different from Suse's which is different from Mandriva's.

Of course Suse's Control Center (YAST) is different from Mandriva's and if you happen to be away from your computer and need to walk someone over a specific task, it doesn't help.

Creating training documentation is another area where this phenomenon manifests itself. So while distributions may see the lack of a common control center as a differentiator, people in the trenches like me just see them as a pain in the ass. Why? Because if I file a bug against Suse's partitioners, I have no way of expecting that Mandriva's partitioner may not show the same or similar bug in the future.

In my opinion, distributions should differentiate themselves in package quality assurance, support terms, research and development and community outrage. In the visible areas, the more standardization the better.

This is one of the things that the Gnome people seem to have gotten right as many of the administration tools are now part of the standard gnome desktop. As a KDE user and administrator, I hope that we do the same. System settings is a good beginning, but we need something as complete and coherent as Yast in KDE. By the way, having two control centers as it often happens with Mandriva and Suse does not help KDE at all. It is very confusing for end users.

It might appear that I have singled out Mandriva and Suse in my post, but in fact I love those distributions and they did and do a lot to advance the linux and kde desktop. There are historical reasons that explain how we ended up with drakconf and Yast, but it is time to consolidate and merge these projects upstream (ideally, into system settings) so that KDE's control center sees wider testing, usage and it becomes easier to support the KDE desktop.

So Troy, thanks for bringing up a difficult topic. I think it would be a major breakthrough if we managed to get distributions to think about their role in the free software ecosystem in slightly different terms.

Take care,

Gonzalo Porcel

(Reply to this)

Well
(Anonymous)
2007-08-21 11:43 am UTC (link)
The sources are there, why don't you just grab them and add that stuff to KDE? Distros are free to fork and maintain their own code. If you don't want that, I guess the GPL is the wrong licesne for KDE...

(Reply to this) (Thread)

Re: Well
(Anonymous)
2007-08-21 02:26 pm UTC (link)
Its a bit boldly stated, but in general I agree with the parent post. Its not so much about allowing the distros to tweak it for their end users as it is that the maintainers of the software (konq developers etc) can not easily see what kind of patches are out there.

Or, in other words, distros hack on software and make things better, but don't have time to integrate it. The answer to push distros to do so anyway is not the right answer as anyone that tried to get his patch into open source projects knows. Its hard work and lots of communication. You can't force a company with a bottom line to do that, if you want to, then GPL isn't what you should have chosen.

So, ok. Just asking or forcing are not the answers; I won't be a complainer that just states all the impossibilities, I'll give you what I think would actually help. Maybe you can run with it :)

What I'd like to see more is that there is a kubuntu or a suse or a red-hat branch published somewhere with the changes for that distro. This allows the 'upstream' to cherry pick the changes that the users like or are clearly ok. So, make the process more transparent instead of forcing people to talk more. Since the former means the whole community can help.
Naturally this idea is only possible after KDE has a proper distributed source repository system (like git) since each distro making a branch is just not practical in a centralized repository.

What do you think?

ThomasZ

(Reply to this) (Parent)

Only one distribution?
(Anonymous)
2007-08-21 11:48 am UTC (link)
Quote from article;
"Only one distribution seems to be relatively immune to this process, that being Slackware."

That is a very bold statement, because there are hundreds of distributions. With this line the author acts like he knows them all. I know for a fact that Gentoo has a policy to stay as close as upstream as possible. This is not only for KDE, but for most/all projects as well (wine, kernel, openoffice, firefox, etc. etc.). Most of the time a custom patch is applied if it has been accepted upstream, but upstream hasn't released a new version yet (e.g. patches applied to the Gentoo version of KDE 3.5.6 are already in KDE 3.5.7, but at the time 3.5.7 hasn't been released yet).

This is just one example, there are probably lots of distributions out there that follow upstream as close as possible.

(Reply to this) (Thread)

Re: Only one distribution?
[info]troy_at_kde
2007-08-21 02:02 pm UTC (link)
Gentoo is a support nightmare of its own, due to its powerful USE flags. Each and every gentoo user pretty much as a unique distro due to this reason. People in #kde see gentoo, and usually end up frustrated trying to help because the problem is a result of a USE flag.

(Reply to this) (Parent)(Thread)

Re: Only one distribution?
(Anonymous)
2007-08-22 09:10 am UTC (link)
You can't blame Gentoo for this, Gentoo is just following upstream as close as possible. If upstream (e.g. KDE) provides (a lot of) configure options (Gentoo USE-flags) then upstream shouldn't "complain" that these configure options are used. If upstream wants a "single state" then remove the configure options. Corresponding Gentoo USE-flags will then disappear as well.

(Reply to this) (Parent)

A KDE Distro
(Anonymous)
2007-08-21 07:48 pm UTC (link)
Btw, what I forgot to say.

If KDE released its own distro, this wouldn't be a big issue... ;)

(Reply to this)

Thanks for saving me... and my own thoughts
(Anonymous)
2007-08-24 07:29 am UTC (link)
Thanks Troy for blogging about this and saving me from having to say it first and turning into a flame magnet (although the responses from your blog tell me that I’m to paranoid). Now I can just blog and say that I’m reacting to you. :)

Since my reply is rather lengthy, I'll just link it here: http://jucato.org/blog/like-a-river-flows-upstream-and-downstream/

But in summary, I believe both sides, downstream and upstream, have valid positions. Downstream has the right to modify software in order to make them work in a complete operating system and to give their target audience a great user experience. At the same time, upstream also has the right to be concerned over changes and fragmentation, since it is their software and their integrity that is also at stake, and since they also believe that their design decisions sufficiently address the needs and concerns of their users. Unfortunately, there is no clear-cut right or wrong way in this. I don't think that the world would be better if downstream simply just resembled upstream. There is always room for change and innovation, on both ends of the river.

What I think is needed is better communication between upstream and downstream, on a technical level and on a personal/social level. On a technical level, we probably need a sort of collaborative or collective source code tracking system, or at least a centralized location to monitor and manage all of these different bug tracking systems and accounts. Perhaps we could take a cue from what Mark Shuttleworth aims with Launchpad (not that I'm advertising Launchpad as *the* solution). On a personal/social level, both sides should communicate more regarding what changes are made and why. They may end up not reaching a consensus, but both sides will walk away knowing the other side's rationale. I think the burden of starting such a conversation falls on the downstream side, though. Perhaps someone could act as liaison or point-man between the two.

P.S. I don’t agree with you that KDE developers usually recommend the that keeps KDE the purest, if Behind KDE is any indication at all of their personal preferences, unless of course that developer recommends a distro that he isn’t using at all. Developers are equally as picky as other normal users. They will choose a distro that will let them get to work as soon as possible. Whether that means they choose a binary distro or a source distro, the answer is as varied as the stars in the sky. :)

- Jucato

(Reply to this)

Продаю сертификаты Вебмани.
(Anonymous)
2007-10-05 05:52 am UTC (link)
Привет.
Продаю персональный сертификат WebMoney за $99.
Можете проверить: WMID 322973398779 Redfern
Всё чисто, не одной жалоб. Сделан на утерянные документы. Всё законно.
Если нужно, то есть сертификаты ещё.
Стучацо в личную почту на Вебмани.

Это не спам. Не пишите на мой WMID жалобы в арбитраж Вебмани.

(Reply to this)

Проститутки Днепропетровска досуг dosug sex Девочки
(Anonymous)
2008-02-04 08:06 am UTC (link)
Проститутки Киева интим intim sex Индивидуалки
c ув http://kurtizanka.com.ua
kurtizanka.com.ua

(Reply to this)

Bad help NoushstafJoth
(Anonymous)
2008-09-09 06:23 pm UTC (link)
h i. If somebody knows, tell me! I trying to find an information about tasty food. What can I cook on my birthday? Tell me please, who knows! My cat GerhOvance I will be grateful

(Reply to this)

супер игры кино
[info]mwjpzvwixf
2009-10-08 01:54 pm UTC (link)
Скачать нужное кино c kinoruwelt супер игры кино + фильмы 2009 скачать

(Reply to this)


(27 comments) - (Post a new comment)

Create an Account
Forgot your login or password?
Login w/ OpenID
English • Español • Deutsch • Русский…