The open source operating system experience exists in pieces, scattered across a world of projects and technologies. Distributions exist because they attempt to create a unified experience from the bits and pieces of open source functionality out in that world, while establishing themselves as a vendor their users can trust. Users might try a few distributions to see which one works for them and settle on one which provides the experience they are looking for. Users build a relationship with their distribution from which they can establish a trust in the packages the distribution ships and the defaults they configure.

So when a user decides they no longer agree with what their distribution ships, and exercise an option to download untrusted packages — risking the failure of future software upgrades and possibly severe security issues — with whom does the fault lie?

Is it reasonable for a distribution to expect a user to visit their website on Release Day to be informed about changes and cautions in the new release? Is it reasonable for a distribution to be alarmed and concerned when rogue packaging interferes with updates, upgrades, and security? Is it reasonable for a distribution to encourage their users to resist or desist using such packages? Is it reasonable for a distribution to encourage users who are not interested in the offerings of the latest release to fall back to the still-supported version? Is it reasonable for the distribution to support their users the best they can while maintaining their own project goals?

I think these are all reasonable expectations. These expectations allow the distribution to to its job: provide a cohesive product which they can reasonably support while protecting its brand and reputation. If users are going to lay the responsibilities of security, stability, and trust on their distribution, then I don’t think it is unreasonable for the distribution to take actions to protect itself and their users.

But what do you do when your users try to reinvent your distribution? There seems to be some confusion as to why the Kubuntu distribution exists and who it exists for.

Kubuntu is a KDE distribution.

Although some would like to say that KDE competes with GNOME (and therefore Kubuntu competes with Ubuntu), I disagree. KDE has completely different market, user experience, and technology goals compared to GNOME. KDE is changing the way people interact and use their Desktop and developing new technologies. KDE also focuses on usable functional design rather than universal usability. One of KDE’s primary user groups is made up of Early Adopters. These are users who are interested in new technology, trying new things, and like to stay on top of what is fresh and new. They don’t necessarily want KDE while it is still breathing and bleeding, but the fresher the kill the better.

I find it ironic how I’m discovering so many “KDE users” who are resistant to change.

Kubuntu attempts to balance itself between its user community and KDE. As an Ubuntu project, we are subject to Ubuntu policies and inherit a very user-driven community. Ubuntu’s strength is in its user community, but so are its weaknesses. There is a necessary balance to everything, and sometimes it is hard to make user goals and project goals even on the scale.

Nearly a year ago last January, KDE 4 was more than fresh — it was still bleeding. 4.0 was clearly a “developers” release, but the excitement surrounding the new and pretty and shiny still drew some users in — at a cost. Kubuntu supported its user community by shipping the stable and reliable 3.5.9 in Hardy instead of adopting the still raw KDE4 technology. We tried to appease traditional KDE users (the early adopters) by also releasing an unsupported KDE4 Remix distribution. Everyone was happy and the world was a good place.

When Intrepid rolled around, it was 10 months since KDE 4 was first released and time for Kubuntu to realigned itself with its goals and focus on KDE. We shipped 4.1.2. This has become a lose-lose situation.

At the time when decisions were made, there were still some bugs we were concerned about in 4.1.2. In an attempt to support our users, we temporarily disabled some not-quite-working functionality until it is fixed in 4.1.3. This pissed off the traditional KDE users.

In the other hand were our traditional 3.5 users. By refocusing our attention from them to KDE and shipping 4.1.2, we pissed them off as well. As a result, instead of sticking with what was known and supported (Hardy), some users installed Intrepid and then resorted to third-party 3.5 packaging which has now damaged their systems.

What’s a distribution to do? There are a large sect of 3.5 users who are not ready or willing to make the move to KDE 4. Continuing to support them stagnates the Kubuntu distribution. Limiting support forces them to resort to other (sometimes damaging or dangerous) sources. It is times like these where you must take a step back and remember what your purpose and goals are.

Kubuntu is a KDE distribution.

As a KDE distribution, it is our responsibility to ship what KDE is developing, not a stagnant branch of what it was. KDE 4 is the future of KDE. It is the purpose and goal of Kubuntu to support, package, and distribute KDE and make it easy to install and fun to use. If some Kubuntu users can’t get over that, then maybe Kubuntu isn’t for them.

Let's talk about bug reporting.

There's something which occurs very often in bug reports by people who mean well. They find a bug, and to avoid making extra work for triagers, they check for a duplicate first. While that's very thoughtful of them, it often ends up getting in the way. So, let's talk about when you should file a duplicate, and when you should not. This is mostly in regard to hardware bugs, since that's where I see this happening the most. Hardware varies so widely, that this becomes a bit of a problem.

Let's say you install Intrepid and discover that no sound is coming out of your sound card. So, you look on Launchpad and find a bug conveniently titled "No sound in Intrepid." "Perfect!" you think and join in. Seeing a workaround suggested with no response from the reporter, you think you'll be helpful and answer the question for the triager…

Stop right there.

Now, consider the following:

1. Do you have the exact same hardware?
2. Are you sure you have the exact same bug?

If, after reading all of the information provided on the bug, you can answer "YES!" to both of those questions, look for what we're calling the "Me Too" feature. At the moment, it's the phrase "This bug doesn't affect me" followed by a "Change" link just under where the bug's Importance is listed. Click "Change" and mark that you are affected. It is not necessary (or recommended) to post a comment saying that you are affected. This just clutters the bug reports.

If your answer is "maybe" or "no," file your own bug. If your answer is "I don't know how to answer those questions," read on.

How do you see if you have the exact same hardware? In the case of sound, video, and networking hardware, check the lspci -nv output. The first line of each section tells you what basic model of that hardware you have. The next line lists the subsystem information, or SSID. The SSID has to do with how the hardware was integrated into the motherboard. It is far from unusual for bugs to be introduced at this level. If yours match and are the same revision, you probably have the same hardware. If there is any discrepancy, file your own bug. For webcams, fingerprint readers, and other things that use the USB interface, check the ID listed by lsusb If it seems you have the same hardware, use the Me Too feature and read on.

Double check exactly what the original reporter is experiencing. Read the full version and any responses they've already given. The title is not enough. If you're not seeing the same behavior, assume it's a different bug.

If it turns out to be one bug that affects multiple pieces of hardware we can always mark them as a duplicate later. That's not a problem. That's part of triaging.

But if it turns out that there are 15 different issues being reported in one bug, that is a problem. If we have 2 people saying something fixes it, and one saying it makes it worse, and a few others say they don't have that exact symptom but rather something somewhat different and the fix didn't work for them…that makes the bug very convoluted. We then try to read through the bug and see what's going on, and it's full of conflicting information. How are we supposed to debug then? We have no solid answers.

Something I see in sound bugs a lot is that one person will file a "No Sound" bug or a "Crackly sounds" bug. Everyone with that symptom jumps on that bug, but they don't belong there. There are multiple possible root causes, and many of them are hitting different ones. But they present themselves the same to the user. What we, as triagers, want to see is that these bugs are filed independently. If, after some debugging, we find that a few have the same root cause, we can mark them as duplicates easily. Finding the 1 root cause to 5 separate issues masquerading as one, though? That's not possible, because really there are 5 root causes and thus 5 bugs. Continuing to pretend they are all one bug just clutters the bug report, making it hard to read and hard to understand.

And that is why I say, "'Tis Better to Dup Than to Convolute."

Inspired by many other lists I've seen. This one is mine.

1. Play with it
2. Configure it the way you want it, not the way some list on a blog tells you
3. Play with it some more
4. Join our Community *
5. Turn the computer off and spend some time with your friends and family

* But only y'know, if you want to.

I’d like to second Davyd’s post about the 10th Day of Remembrance. It pains me to know that even today with all the technological and intellectual progress we’ve made, there are people out there who just cannot accept and/or respect other people’s choices.

For those hiding behind a bible to defend their actions, maybe your god should teach you more tolerance…

Yeah, comments will be turned off. I don’t plan to spend my day fending off any comment that will tell me that their rights are more important that somebody else’s.

"With shallow users, everything is a bug."

I'm working with two different Ubuntu teams right now that translate long documents. We have not found a human-friendly tool chain that allows translators to be language experts without having to also be a command line wizard. Each translator is forced to come up with their own way of doing things. Some are able to cope just fine but others are being cut out of the action because they have no sane way of dealing with the source files.

On the list of doc formats to deal with are book-length XML files (broken down by chapter in most cases) and subtitle files (which are basically plain text with time codes). In the interest of using an integrated system I posted a feature request on Launchpad and asked for a sane way to deal with files that were already stored in the code section of Launchpad. Within a day the feature request was flat out rejected and the bug was closed and tossed.

So here is my challenge to everyone out there...if you dared to dream, just a little bit, if you dared to create a system that was easier to use and took advantage of the power of the intarwebs instead of an individual's ability to bang on command line tools, what would the future of translation look like? How would you create a Web-based (or desktop-based) translation toolkit? What would it look like? How would data be pulled in, be worked on in "draft" format and be saved and pushed back out again?

I know how Drupal does it, I know about the tools I've built, and I know about my future plans for audio translations. Now I want to know your dream for dealing with the translation of long documents. Forget the patches... sketches, screenshots and radical dreaming are all welcome!