Full disclosure: I am a Canonical employee and a GNOME Foundation member.
Caveat: The opinions expressed in this post are solely my own, and should not be construed as representative of Canonical’s corporate policy or ethos, nor as representative of the Ubuntu or Kubuntu projects’ ideals or policies.
This recent post is not the first time that the Ubuntu project and its sponsor, my employer, have been accused of neglecting Kubuntu. And it may not be the last. But please allow me to make some points.
First, Ubuntu is a project. If Ubuntu “ignores” Kubuntu, the reason is simple. They are different projects. I’ll be attending the GNOME Boston Summit 2008 this weekend. If I don’t find a lot of KDE developers there, can I then posit that KDE “ignores major trends and issues related to the free Unix desktop?” Clearly not. And I wouldn’t expect to find large numbers of GNOME developers at Akademy. Although GNOME and KDE have similar aims, there is no reason to expect the two projects to mutually support each other in absolutely everything they do. When such mutual support happens, it’s very, very nice. I value my friendships with many people in the KDE community, but I wouldn’t seek out a KDE developer when I have issues with GNOME. By extension, I wouldn’t blame Ubuntu developers and packagers when things break in Kubuntu. If Kubuntu is broken, then Kubuntu developers, MOTUs, bug triagers, and all Kubuntu community members are responsible for fixing it.
Second, looking at the issue of Konqueror and the Ubuntu wiki, I am unable to find Jonathan Thomas’ reports, suggestions, or potential fixes. In fact, I can’t even see that he’s subscribed to the bug. It’s one thing to complain about an issue not being addressed. It’s quite another to complain about an issue you yourself have not taken the time to address. If the issue is that important to you, get involved. Not to belabor the “separate projects” point, but it’s not the responsibility of GNOME developers to make sure their stuff works in KDE (and vice versa). Thus, at the desktop/UI level, it’s not the responsibility of Ubuntu developers to ensure their stuff works in Kubuntu. Don’t get me wrong, I think it’s fantastic when this happens, and we should always strive to allow this kind of cooperation. But demanding that one project alter its needs and the needs of its users based on the requirements of a different project does a disservice to both projects involved, never mind the users that depend upon them. Now, be aware, if the Linux kernel deployed in Ubuntu breaks KDE functionality for Kubuntu, that’s the responsibility of the kernel team. But if GNOME features do not translate well to another desktop environment, that’s not necessarily GNOME’s, and by extension the distros that use GNOME, problem.
Finally, I don’t see any suggestions from Jonathan as to how things might be improved in the future. Criticism is always difficult to hear, but when such criticism is in no way constructive, it’s difficult to find a reason to listen at all. Not to mention that unconstructive criticism probably violates the spirit, if not the letter, of the Ubuntu Code Of Conduct. Simply put, “lead, follow, or get out of the way.” It’s also especially interesting that two-thirds of the issues Jonathan cites (Konqueror vs. Moin, KNetworkManager vs. NetworkManager) are actually already fixed, and were prior to his post.
I apologize if this post comes off as somewhat harsh, it is not my intention to be so. But clearly it is not the responsibility of the Camry assembly plant to ensure the Prius meets delivery requirements, despite both being owned by Toyota. In the case of Ubuntu and Kubuntu, this distinction is even more clear, as no single company “owns” either. Kubuntu belongs to you, the Kubuntu community of users and developers. If something is missing, broken, or needs polish in Kubuntu, it is the responsibility of the Kubuntu community to address these issues. While it’s always desirable for the different desktop environment projects to work together, this obviously cannot happen all of the time. And GNOME is not going to ask “How does this affect KDE?” every time a feature is added to GNOME. Conversely, I wouldn’t expect KDE developers to worry much about GNOME’s needs.
Jonathan, I understand your frustration. But be aware, Kubuntu is not a product as much as it is a project. You’re able, at any time, to get involved and make the changes you deem necessary. If you don’t, it’s a bit unfair to ask other people to address your specific needs and issues without your involvement. I’m aware of this because I often have to censor myself when I encounter a piece of missing or broken functionality. For instance, the UPnP browser plugin in Rhythmbox simply does not work with MediaTomb UPnP shares. It really annoys me, as I have to run both MediaTomb and Firefly/mt-daapd on my media server. But I don’t have the time or skills necessary to address this issue myself, so I find myself having to squelch my dissatisfaction to some degree. I’d love to file bug reports, participate in triaging of these bugs, and test potential fixes. But my work and personal commitments have thus far prevented me from doing so. Thus, since I’m not part of any potential solution, complaining about this broken functionality simply would make me part of the problem.
Personally, I don’t think that’s helpful or constructive. Flame on.
I don’t see how Kubuntu should be responsible for Ubuntu breaking things by uploading unstable svn snapshots of the libraries our frontends use that break the stable versions of said frontends. In this case, one *would* expect mutual cooperation since the two frontends are using the same backend. (KNetworkManager and Network-manger-applet both use the Network Manager libraries)
The problem in most cases is not the problem is never fixed, but of the attitude taken in addressing the problem as well as the reason for the problem’s introduction in the first place. The attitude/responses usually boil down to Kubuntu is not equal to Ubuntu, a notion which Canonical has claimed to the contrary.
If Kubuntu is indeed not an equal to Ubuntu, then *nobody* should say otherwise. If Kubuntu is “just a derivative project” then Canonical, et al should not pretend that Kubuntu is equal in order to score PR/marketing brownie points.
I don’t see how Kubuntu should be responsible for Ubuntu breaking things by uploading unstable svn snapshots of the libraries our frontends use that break the stable versions of said frontends. In this case, one *would* expect mutual cooperation since the two frontends are using the same backend. (KNetworkManager and Network-manger-applet both use the Network Manager libraries)
You cite an issue that has been fixed by the Kubuntu team, and was prior to your post. Thus, I fail to see the relevance of this example.
Indeed, the fact it was fixed in a timely manner before release seems indicative of a high level of cooperation between the two projects.
One man’s opinion.
Hi,
> Now, be aware, if the Linux kernel deployed in Ubuntu
> breaks KDE functionality for Kubuntu, that’s the
> responsibility of the kernel team.
And before it breaks anything, it should be tested on both, to make sure it doesn’t break either, right? As they both use the same kernel?
By the same logic, if you make a change to NetworkManager, check that it doesn’t break either Ubuntu or Kubuntu network access.
Also, if you change the (desktop agnostic) bluetooth framework, test that it doesn’t break either Ubuntu or Kubuntu bluetooth features.
That’s what the linked blog is saying.
Correct, it should be tested on both.
It should be tested on KDE by the Kubuntu development team. If it breaks functionality, they should work to ensure that either the package is excluded, or make it work.
It is not the responsibility for ubuntu-desktop developers to test kubuntu-desktop packages.
Of the examples given, I’m only familiar with the bluetooth example. I must preface this by saying that I think it’s crazy that the bluetooth transition was approved so late in the game.
I think it’s downright stupid to blame Canonical or “Ubuntu” for what happened to Kubuntu. The driver of the project was superm1, who is neither a Canonical employee (I believe he works for Dell) nor a principle Ubuntu GNOME desktop developer. superm1 started Mythbuntu, and is interested in Bluetooth as a result of that use case. Obviously he’s dependent on GNOME as a result, but if nothing was done to fix bluetooth keyboards and mice, we could be reading the following the following blog headline instead: “Mythbuntu, the black-headed stepchild”.
@mneptok, @Steve
We’re not talking about just standard testing, the bluez upload was a KNOWN API CHANGE. This is not about testing, you can be 100% sure the API changes will break anything that use them.
I have a certain amount of sympathy for your position for things that are spec’ed and uploaded prior to feature freeze. Ubuntu/Kubuntu shoule be aware of such things and working together.
In the case of Bluetooth, it is a change very late in the release cycle and, as such, I think whoever is pushing the change has a responsibility not to harm other projects.
The Knetworkmanager problem did get fixed, but it was a significant enough problem that Kubuntu shipped the Gnome Network Manager applet instead of the KDE one for part of the development cycle.
If a week from now I have an Amarok patch that really improved Amarok/KDE integration, I guess I don’t need to care if it makes the application unusable in Ubuntu? I really don’t think that’s how we want to work together.
Either we have a collective responsibility to be considerate of the impacts on each other or we don’t. I don’t think “It’s not my problem is $DISTRO is broken” is a very Ubuntu approach to this problem at all.
My assessment is that the vehemence of the reaction to this and similar posts is because the truth hurts.
Suprm1 is a friend of mine as well and don’t want to bash him, but he is a core-dev now and core-devs should test both kubuntu and ubuntu when something they upload would affect both.
also when the kubuntu team uses the core of ubuntu the comparision between prius and camary breaks down. if something core affects both, both should be tested and an excemption shouldn’t have been made for upload unless both have been tested.
“But clearly it is not the responsibility of the Camry assembly plant to ensure the Prius meets delivery requirements”
Bad analogy.
What Camry (Ubuntu) is doing here is taking a common component they both share (say… the lugnuts) and making a Camry-specific change to that component which impacts Prius (Kubuntu) adversely, causing it to have a non-functional end product. The fault is Camry’s, and Prius is left to clean up the mess with a “Dude, that’s *your* problem.”
Not cool.
Furthermore,
The criticism on the early post by Jonathan Thomas should be met with a little more good faith than the defensive display shown here.
I read and reread the post and I fail where it lacks constructive criticism. It’s (was) an issue, it’s real and should be at the very least be discussed for what it may be worth. Accusing the author of said criticism not providing a service because they don’t offer solutions or participate on them is the equivalent attitude of a gag order that I would wish once and for all to see irradiated from the linux community.
As a systems user I have the right to discuss what I may or may not like and dislike, and the reasons behind these feelings. I have the right to, if I so wish, criticize my provider decisions and actions. I don’t have to have a programmer’s degree.
>It is not the responsibility for ubuntu-desktop >developers to test kubuntu-desktop packages.
No, it’s not their responsibility to test, but one would think they could at least have the courtesy to ask, “Hey, we’d like to push this updated, common framework forward. Is it working on your end?” before it gets pushed out. I agree with ScottK: although the developers of the respective DE’s shouldn’t worry about testing the others packages, there should some coordination that underlying, desktop-agnostic frameworks are functioning properly.
If I were Mark I’ll take the developers of the both sides for a weekend so they can learn a bit more about team work.
Brothers will usually fight, but if they act together they will be able to accomplish greater things.
As a systems user I have the right to discuss what I may or may not like and dislike, and the reasons behind these feelings. I have the right to, if I so wish, criticize my provider decisions and actions. I don’t have to have a programmer’s degree.
And people have a right to reply. And if you don’t file any bug reports before lambasting the project publicly, it’s pretty bad form. It does not require programming experience to report bugs and subscribe to them on Launchpad.
[i]And people have a right to reply. And if you don’t file any bug reports before lambasting the project publicly, it’s pretty bad form.[/i]
I still fail where Jonathan lambasted the project publicly. Certainly not more than he was himself lambasted here… publicly. His words were cautious. So cautious that I as a reader felt he was eerie of discussing it. Probably already feeling this type of reaction.
Nowhere in his post, I — a reader — felt he was diminishing the work of those involved. He was complaining about something that affected his Kubuntu end-user experience. And was careful enough to address it in a respectful way to all involved. His opinions, if not shared (and was left unsaid on my previous comment I happen to not share them) should be addressed in that context only. Not as I witnessed here.
Meanwhile, no. I’m not obliged to fill bug reports before discussing anything related to said bug. Certainly not when someone else did it already. But I’m not also in any kind of obligation to join said bug report. My right to voice my opinion is encompassing of my right to say good or bad. If I don’t need to join a bug report to congratulate the speedy resolution that is an usual characteristic of the (x)Ubuntu distribution, I don’t need to join a bug report to criticize when its not. We definitely need to take another stance towards our users if we happen to meet more and newer smiles.
You do have the right to reply to his opinion, certainly. What I feel is that you were too harsh, which on my particular case left a long lasting impression you got defensive. And it’s left to my imagination why you did. Which results in the unfortunate consequence that your article here raised more questions than it answered…
Verbs like “neglect” are not moderate speech. If someone said “you neglect your children,” I think it likely that you’d characterize such sentiments as lambasting.
And I never said you don’t have the right to complain. You most assuredly do. I simply said it’s bad form to complain publicly, use loaded words like “neglect,” and not even bother to subscribe to the bugs you are talking about so that you may be assured that your criticisms are justified.
Let’s be clear, 67% of the issues raised in the original post were fixed before the post was made (the NetworkManager and Firefox issues). And once the bluez issue was brought to the fore, it is being addressed, as well.
This is “neglect?”
You can discuss all you want.
The fact is:
General feeling/point of view/perseption is:
kubuntu is a second class derivaive.
I’ve always found it interesting (and somebody correct me if I’m wrong) that there’s never been a Ubuntu-desktop developer agreeing with the Kubuntu-desktop developers and users that the current system in Ubuntu regarding these two projects and its relationship to the core of Ubuntu is inappropriate.
Every time something like this is highlighted by the Kubuntu side nobody on the other group pipes up saying “You know, if Mark ever decided to switch Ubuntu to KDE I wouldn’t want to be treated like that. What changes can we suggest to him that will make this more of a level playing field?”
The way this situation even occurred really highlights the disparity here. The Ubuntu distribution IS Ubuntu-desktop + the core of Ubuntu while Kubuntu-desktop is not. Core changes are implicitly validated against Ubuntu-desktop. There doesn’t appear to be a process in place to isolate or highlight breaking changes that affect Kubuntu-desktop (or the other for that matter but the practicalities of the situation really make this a one-way street).
Avenues for resolving this require that the Ubuntu-desktop developers cede control and power which is why they’ll not make suggestions to Mark on their own. It’s really up to him to arrange the kinds of changes required to resolve this continually unresolved issue. That it continues to plague us, all of us who really want to stand for more than just a specific DE, is truly disheartening to me (and hopefully to us all). But until the SABDFL makes a call we’re just stuck in this situation.
Can we genuinely have a three fold (or whatever multi-faceted one should be established) where the core of the distribution is developed alongside equally staffed and supported DEs? Could we even see a DE releases separate from a core release? It’s up to Mark to decide.
Matt,
Interesting point, and well said. Perhaps a “Desktop Stability Team” is in order, that straddles DEs and ensures all supported variants have equally robust testing of major changes.
Hmmm ….
Yes… but what will be the answer to “oh, look. It’s good, but it’s breaking [insert DE here]”?
Because a true Desktop Stability Team would under this notice, no doubt delay inclusion. And it’s been my experience (observation-wise), similar attempts have been met with initial excitement, slowly degraded into annoyance and — guess what — more bickering, and finally abandoned over the fact they slowdown the release pace.
And this gets us to where I don’t agree with Jonathan. But probably where you folks don’t agree with me either:
Accept the simple fact Ubuntu is the flagship product and Kubuntu is a child project with its own timeline and make this clear both publicly and organizationally. As a KDE user I have no issues with this. Probably some KDE users will. But a clear stance is better than a foggy one. And I think the notion of sibling projects couldn’t be described in any other way than wishful thinking.
I apologize for the bluntness. Particularly testy considering the fact I don’t know the Canonical innards. But as a corporate software developer for >20 years, I have an hard time seeing Ubuntu and Kubuntu as equals in a development-wise sense. Canonical will always move at the pace of the slowest one.
Mneptok, (are you supposed to capitalize it like that? :-))
Thanks, it’s good to hear people agree with me so I haven’t gone off the deep end.
I imagine an Ubuntu-core, Ubuntu-desktop-common(X11, D-Bus, etc), Ubuntu-desktop-{DE name} groups/metapackages (like Ubuntu-desktop-GNOME or Ubuntu-desktop-KDE which would probably be an alias for Kubuntu-desktop) plus Ubuntu-server that would be Ubuntu-core plus the special stuff they’re whipping up like installers that pulled down LAMP (which was awesome for me when I repurposed an old desktop at work but would be mostly useless for most people on their netbooks).
It seems like an iteresting idea to me to stage this out. Ubuntu-core release at time-0, maybe alongside Ubuntu-server since it’s pretty lightweight in additional dependencies. Ubuntu-desktop-common releases time+2 months (or whatever), Ubuntu-desktop-{DE} releases happen time+3 or you could even expect them to cooperate before release but have a friendly competition when they’re ready and not be required to release together at all.
You’d know things were working right when the KDE desktop release and the GNOME release don’t necessarily come in a fixed order. One time KDE gets out first, the next GNOME and so on. If over time the releases were as likely to come before the one than after the other then no one team had an advantage over the other.
@Mario
You’ve got a very good point especially because the staffing levels between the two groups are so different. KDE *will* be the brake on progress until that problem is resolved (Mark if you’re reading, resume available upon request).
I can’t help think that if the SABDFL says to a group of his employees that they’re now developing for the generic desktop platform instead of directly into a GNOME desktop then they’ll start developing that way. That doesn’t prevent new innovation (even innovation initially exposed via GNOME) but it tries to bring things to the point that they’re exposed into a common platform/interface so no one group/DE has much of a leg up on any other group/DE.