October 26, 2010
"In his keynote address at the Ubuntu Developer Summit Mark Shuttleworth has announced that Ubuntu 11.04 will use a new desktop version of Unity for the default desktop environment."

—

From OMG! Ubuntu!

The stress is in by default, and I think it will be easy to go back to classic Gnome or Gnome Shell anytime.

It’s a bold move anyway, but I don’t agree with Mark Shuttleworth when he says it doesn’t have to be seen as Ubuntu moving away from Gnome. Don’t subestimate the defaults!

The whole plan is interesting, because we’re going to see the reaction of a large community to the changes dictated by Canonical (a company) in Ubuntu, a distribution that used to focus on community, and now it looks more like a product focused on differentiation.

Update:

Unfortunately, this choice of Unity as the desktop user interface, instead of supporting the steadily progressing GNOME Shell project and trying to influence the direction of that project, is another step on the path to the siege mentality.

From Ubuntu to move to Unity as default desktop for 11.04 by Dave Neary. Interesting reading.

by jjm on 9:31am  |   URL: http://tmblr.co/ZPorZy1Jmv4T
(View comments) 
Filed under: Ubuntu 11.04 Gnome Gnome Shell Unity upstream Canonical 
September 29, 2010
Fedora Updates Policy

Yes, finally there’s an updated updates policy for Fedora.

I think it’s worth reading because, as the announcement says, it can be improved, clarified and adjusted; but it’s a very good starting point.

I was writing a more or less deep review of the document, but my internet connection failed, Chromium crashed (!), and here I am writing this post again, so instead of explaining something that you can read yourself in the policy page, I’m going to focus in the most interesting part: the releases.

The updates on the branched release are divided into pre beta, beta to pre release, pre release and release. Although the updates policy helps to have a more solid release, the updates after the release are a very important part of the user experience (for example, it’s an excellent way to polish the rough edges of the release).

Basically the policy says that the updates after the release must be primary bugfixes, so any updated package must avoid major releases with new features because that can introduce new bugs or instabilities. Moreover a release doesn’t need to track upstream changes to provide latest versions of the packages, because there’s a development branch (rawhide) to do that.

I would clarify the part of the major version number referring to a new release that introduces new features, because the version numbering in OSS isn’t that uniform (for example, in Cherokee every 1.0.X release may introduce new features), but since the rest of the philosophy section it’s well explained, it’s not a big deal.

The part that worries me most it’s the one that says:

Whenever possible packagers should work with upstream to come up with stable branch releases or common patches for older releases, particularly when rebasing would require large dependency chain updates.

That’s unlikely to happen, because in the same way the distributions doesn’t have resources to backport fixes, upstream can’t support all distributors providing backports to the stable releases that are being packaged and distributed (btw, this could be an interesting role in every upstream project).

So we may end at the same position Ubuntu it’s running for some time: there are bugs that won’t be fixed until next release, because there aren’t resources to backport the fixes and it’s too risky pushing an update with new features (that would include a fix).

Of course I’m not talking about security issues of critical bugs, but it’s somewhat frustrating when it’s something that makes a productivity application crash or misbehave, and you know that problem it’s going to be there for six months until next release (and certainly there’s a chance to have new of those never fixed bugs in the next release). So updates stop working as a tool to polish rough edges in a release (and I don’t know if this is related to the worst release ever meme), and that’s bad.

In fact, that’s one of the best features of Fedora when I moved from Ubuntu because of my frustration with broken Pulseaudio deployments release after release.

Currently I’m running Fedora 12 and I’m very happy with it, and I’m not planning to upgrade until its EOL arrives. I wonder if that will be posible with the new updates policy. What do you think?

by jjm on 8:39am  |   URL: http://tmblr.co/ZPorZy185PTr
(View comments) 
Filed under: FESCo Fedora updates updates policy upstream 
June 22, 2010
"The number one reason why Sun bought StarDivision in 1999 was because, at the time, Sun had something approaching forty-two thousand employees. Pretty much every one of them had to have both a Unix workstation and a Windows laptop. And it was cheaper to go buy a company that could make a Solaris and Linux desktop productivity suite than it was to buy forty-two thousand licenses from Microsoft."

—

OpenOffice at the crossroads, a conversation with Michael Meeks by Richard Hillesley.

The quote is from Simon Phipps, an ex-Sun employee.

by jjm on 7:28am  |   URL: http://tmblr.co/ZPorZyhBsz5
(View comments) 
(Notes: 1)
  
Filed under: SUN OpenOffice.org every bug is a feature Meeks Oracle upstream 
April 19, 2010
Why My Bug isn’t Being Fixed?

Today I was chatting with a workmate about some problems we’re having with different SIP softphones in Linux and the sound support, specially with Ekiga, Ubuntu and Pulseaudio.

But it’s not about that what I want to talk today, but about the feeling of my workmate that filing a bug report is useless: I’ve done it in the past, without positive results, he said.

That’s very intringuing for me, because I’ve been involved in several success stories of bugs being fixed, even in hours. Yes, Open Source rocks, but we must know how to deal with it.

So, the question is: why my bug isn’t being fixed? Let’s try to answer this question.

Nowadays it’s very frequent to use a distribution, in my case I run Fedora at home (and Ubuntu and CentOS at work), and when something fails, I usualy file a bug report. The first problem is to find where I must report.

I usually look in Fedora’s Bugzilla, to see if someone has found the same problem. If I find something that may be it’s the same bug, I add myself to the CC list and I try to add useful information in a new comment. In that way I can follow the bug evolution, and may be help.

But sometimes I can’t find something related, so I file a new bug; and the difficulties start.

A full working operative system it’s a complex software, and there are different components that interact together to make possible, for example, that I open an FTP session in Nautilus.

So, when it doesn’t work, first I must guess what component has the problem, and this may not be easy.

Then, I must distiguish between two actors:

  • The distributor: thus, Fedora. Packages and integrates software, and provides a full working operative system.
  • Upstream: the people that actually develops the software (ie. Gnome, Mozilla, etc).

Let’s say Nautilus has the problem. The next step is to decide who is more likely to fix the problem:

  1. Is upstream managing bug reports with Fedora’s Bugzilla instance?
  2. Is a problem related to packaging and, then a problem of the distributor?
  3. Is it none of the above?

If we’re in case 1 or case 2, we file a bug in Fedora bugtracking and we’re done. Sometimes happens, like most problems with SELinux, or when it’s a problem introduced by the distributor when packaging the software.

Moreover there are chances that, if you blamed the wrong component, someone will point you the right one, and eventually the bug will get the required attention.

But If we file the bug in Fedora, and we are in case 3, most likely our bug won’t be fixed. We’re asking in the wrong place, and it’s possible that nobody will help us.

Every distribution has resources assigned to interface the distribution with upstream, but a Linux distribution is a huge project, and there are chances that these resources are busy.

In those cases, where the bug must be fixed in other place, we must look for the bugtraking for upstream, and file the bug there too, adding a reference in the bug in Fedora’s Bugzilla, so the distributor is aware of the problem (even it has to be fixed in another place).

Let’s see an example: Bug 542205.

  • 2009-11-28: I filed a bug, but in the wrong component, and wrong place!
  • 2010-02-05: I realized my mistake, so I filed a upstream bug #609085 (in the right component!).
  • 2010-02-07: A developer upstream asks for information, I help in everything I can (just two comments). The bug gets fixed the same day.
  • 2010-02-09: A package with the fix hits Fedora testing.
  • 2010-02-23: The package it’s pushed to updates!

I think we can verify a couple or more things:

  • The bug in the wrong place (and in the wrong component!) will get rotten without any hope of being fixed.
  • After the bug was in upstream, I got a fix in about 2 days, and 2 days later I had a package to test it in my system (actually it fixed the problem).
  • Once QA it’s done, it hit updates and all the Fedora 12 users would benefit of my bug report.

To sum up, I would say that the main reason your bug isn’t being fixed is: the bug report is in the wrong place, and nobody is there to help you!

I know there may be other factors, but overall I think everything I have explained makes sense. I have experience with QA and QC, and open source software adds some complexities because of its bazaar nature that doesn’t exist in a privative world. What do you think?

Disclaimer: I’m not involved in Fedora QA team, and this post it’s result of my own experience.

by jjm on 5:15pm  |   URL: http://tmblr.co/ZPorZyVpCot
(View comments) 
(Notes: 2)
  
Filed under: Fedora QA upstream bug open source bugtracking 
December 22, 2009
OpenOffice.org announces "end-of-life" for version 2.x of its productivity suite

Via OpenOffice 2.x End Of Life at Hellow’s Blog.

I’ve found pretty interesting the FAQ part:

What does end-of-life status mean? Is the software unusable now?

So, can I go on using the old version?

I’m a Linux user, and my copy of OpenOffice.org comes from my distributor’s repository. Am I affected?

Why can’t the community support older releases for a longer period of time?

Check it, because it’s very interesting. The End Of Life concept it’s very often misunderstood, because people tend to not get the difference between vendor support (also called upstream), and the distributor support.

by jjm on 6:48pm  |   URL: http://tmblr.co/ZPorZyHcrfB
(View comments) 
Filed under: OpenOffice.org support End Of Life deistribution upstream Fedora 
December 11, 2009
"It didn’t attract that much attention at the time, but this setting was changed by the small group who maintain GNOME Control Center. They claimed that text-only interfaces were better."

—

From Get your icons back, where Adrew brings some light to the “dude, where are my icons?” story in latest Gnome.

That was IMHO one of the weird things in Fedora 12; and even after reading the release notes and realizing that it was a decision/change from upstream, I must admit I got pissed off at first with Fedora.

My fault, because I’m not the kind of person that reads the release notes before upgrading. I thought the upgrade broke something. OK, shoot me :D.

Sometimes something it’s broken in a release, and the user that puts all his confidence in a distribution gets disappointed. Shall the answer from the distribution be it’s broken upstream?

Although the release note it’s OK and explains everything, I’m not sure. It isn’t good to disappoint your users.

by jjm on 6:03pm  |   URL: http://tmblr.co/ZPorZyGexcY
(View comments) 
Filed under: Gnome Icons Fedora Upstream Distribution broken 
December 25, 2008
"Everyone who’s worked with open source projects know that if you’re going to make use of it, the least you can do is send any, if not all, improvements made back to the source. It doesn’t necessarily mean that your patch/work will be taken or incorporated but it is something a good citizen from the open source world should do, specially a project like Ubuntu that is so popular among the generic GNU/Linux user base!"

—

from A few reasons why Rosetta should not be considered as a translation platform for existing open source projects, by Og Maciel.

Interesting thoughts (and facts!) about translations in Open Source projects, Rosetta (Canonical’s tool for translating), and the need of upstream collaboration.

I agree with Maciel about the problems that (sometimes) has caused the inefficiency of Ubuntu distribution to send back the improvements they made. Right now comes to my mind the early problems with Debian.

by jjm on 7:56pm  |   URL: http://tmblr.co/ZPorZy3_jV7
(View comments) 
Filed under: Ubuntu Rosetta open source translation upstream