using bugzilla, the right way

Yes, I admit it, I hate bugzilla. I mean, the bug tracking is something indispensable for every software project, but digging in its web interface for quick searches, I just find it unbearably awful.

But I guess I came across with the right tool for overcome this web madness: pybugz

On the other hand, I’ve to say that I agree about using bugzilla to keep track of patches, it’s a bad idea too. A properly organised mailing list and maybe a patchwork, if the traffic is massive, as helper.

GCDS ramblings

The last two years the GUADEC has been pushing the geographical limits of Europe: in 2008 in Istambul, more near to Asia, and now, in 2009, in Canarias, more near to Africa. And that’s OK, I like it actually, is better than repeating the old hosts of the conference.

Comparing my impressions with that two last GUADECs, I found something interesting: In Istambul the new ideas were boiling the environment, bold proposals: the seminal concepts for Gnome Shell, Zeitgeist, Gnome 3.0, and so on. And now, in Gran Canaria, the spirit was an evaluation the development of those ideas, a revision of where the project is and what’s missing to achieve the goals.

In Istambul, the hackers takeoff. In Gran Canaria, the hackers landed.

Nokia stepped back from GTK+ in their products and announced their official support to its recently acquired Qt framework. And that announcement staggered the gnome mobile gang, forcing to rethink their objectives.

The online desktop died and from its rotten corpse a new flower appeared: Gnome Shell: The desktop is a canvas driven by javascript applets, just like the Web 2.0. Moblin also adopted that idea, and many other are going in that path.

The Federico’s crazy idea about a chronological desktop evolved into Zeitgeist, which is taking over as the Tracker user interface for Gnome.

The furor unleashed in Istambul with the announce of the efforts for Gtk+-3.0 had been diminished in this time. Nevertheless, Garnacho showed in the GUADEC-ES some of his unfinished branches, some of them quite amazing, but unmerged into mainstream yet.

Almost of the attention was hogged by Clutter, and the Moblin guys are using this to push the rest of their framework. I guess that everybody is waiting a miraculous merge among Gtk+ and Clutter, but that’s really hard to happen.

Vincent is still pushing for Gnome 3.0. And I really wish for that to happen. And Gnome 3 means GnomeShell, Zeitgeist, and possible Gtk+ 3.0 and GStreamer 1.0. Those new versions doesn’t mean necessary new features, but more clean ups in the code.

What excited me the most was the discussion towards GStreamer 1.0. There’s plenty of work to do. Hopefully I’d find a spot to collaborate on it.

Also I went the ConMan talk and a couple about WebKit, DBus, and a couple more.

The big patch theory

It is well known that the free/open source software major asset is the sense of community surrounding each project. That idea is the constant in almost all the promotional videos which participate in the Linux Foundation contest We’re Linux.

A community driven project, exposed to the masses by Eric Raymond in his paper The Cathedral and the Bazaar, has been gaining moment, turning the software development, rather than a isolated, almost monastic, craft work, into a collaborative, openly discussed, engineering task.

All those ideas sound exciting and appealing, but from the trenches, how is it done? How does a bunch of hackers collaborate all together to construct a coherent and useful piece of software?

We could be tempted to think about complex, full solution, software such as forges, distributed revision control software, etc. But I won’t go there. That’s buzzword. From my point of view, the essence of any collaborative software project is the patch.

According the software engineering, an important activity, in the software development process, is the peer reviewing. Even ESR gave a name to it: the Linus’s Law. But the software peer review is not an task done once or periodically, it would be an almost impossible duty, or at least impractical, because it’d imply read and analyse thousands of lines of code. Instead of this, the peer review it’s a continuum, it’s a process that must be carried on during all the code writing.

So far we stated two purposes for a patch file: collaborative software construction and peer review. For the first purpose the activities implied are, from the developer point of view, modifying the code, extract the diff file and hand it out; from the integrator point of view, the application of the patch and keep a register of it. It’s relatively simple process, and it can be automatised in some degree with the help of a SCM software. But there’s hidden trick: the patch must be small and specific enough to survive several changes in the base code, and could be applied cleanly even if the surrounding code had changed since it was created.

Nevertheless, for the second purpose, the process from the developer point of view, is more complex; the crafting of a patch for peer review is not a trivial task, quite the opposite, good patches are fruit of experience.

A good patch has set of subjective and objectives values that the reviewers and the integrator will take in count at the moment to commit it in the official repository. A patch must be small enough to be easily understandable, attack a single issue, self-contained (in must have all it needs to solve an issue), well documented, complete, honour the project code-style, and so on.

A perfect patch must transmit the needed confidence to the maintainer, with a simple glance, to apply it immediately. And only the experience can give this skills. There’s not a Patch 101 lecture, but maybe is a interesting idea.

Coroutines, closures and continuations

I ought start with a disclaimer: I don’t have experience with functional programming. I never studied it. Nevertheless recently I have had some contact with some of its concepts, specially with the idea of continuations and closures. From these contacts came up a question, an hypothesis: by definition, continuations ⊆ closures ⊆ coroutines?.

The first step should be find their formal definitions and establish their relationship as subsets. But find and understand formal definitions is not a piece of cake, at least for me, so I will try to expose the most clear definitions, in simple words, which I found in
the net:


A coroutine is a generalization of a subroutine which can be paused at some point and returns a value. When the coroutine is called again, it is resumed right from the point it was paused and its environment remains intact.

In other words, a coroutine is a subroutine which has multiple entry points and multiple return points. The next entry point is where the last return point occurred or at the beginning of the coroutine if it reached its end previously. Meanwhile a subroutine only has one entry point and one or more return points.


In this example, the pause and return point is controlled by the token yield.

coroutine foo {
yield 1;
yield 2;
yield 3;

print foo (), "n";
print foo (), "n";
print foo (), "n";
print foo (), "n";
print foo (), "n";
print foo (), "n";

This code will print:



A closure is a block of code (can be anonymous or a named subroutine) which can contains variables defined out of its lexical scope (free or bound variables). When that block of code is evaluated, all the external variables and arguments are used to resolve its free variables.


function foo (mylist) {
threshold = 150
return ({ myitem, myitem.value > threshold })

In this example, the closure is the block code of { e, e.salary > threshold } which is evaluated for every item in the list (the select method traverse the list executing the passed closure for each element), and the free variable of threshold is resolved in
the lexical scope of the foo subroutine.


A continuation is a subroutine which represents the rest of the program.

In order to visualize this, you must break with the concept of the return of a subroutine, the subroutines don’t return values, they continue the execution of the program with another subroutine. The continuation, obviously, must receive the whole state of the program.

In other words, a continuation is a glorified “goto” sentence, where the execution pointer is transfered from a subroutine to another subroutine. The concept of the function stack and their dependency relationships are removed.

function foo (value, continuation) {
continuation (value + 1)

In the previous example, the continuation is passed to the foo subroutine as an argument, an contains, besides the next subroutine to execute, the whole state of the program, and receives the an argument which is processed by foo.


Each concept, although extends or modifies the wide-used concept of a lexical scoped subroutine, is independent among them, but not mutually exclusive: in terms of implementation you may have a coroutine which is a closure, a continuation which is a closure, a coroutine which is a continuation or vice versa.

So, my hypothesis is incorrect, we must rephrase it as, by definition coroutine ∩ closure ∩ continuation = ∅

But, by implementation, ∃ coroutine ∪ closure ∪ continuation


what the heck is: a coroutine

Wikipedia Coroutine


A Definition of Closures

Wikipedia Closure

Fake threads

Continuations made simple and illustrated

Wikipedia Continuations

Guadec 2008

Last week I attended the Guadec 2008 in Turkey. It was my second Guadec. The first one was in Sevilla in 2002, when I was backpacking Europe. The big difference between my previous and this last guadec is that now I have a better understanding of the state of the art, so I could appreciate more the talks and proposals done, which I will try to summarize in this post.

The Gnome community faces new and not so new challenges. The framework is trying to push its limits to new frontiers besides renovate its own core.

First there is the discussion about the strategy for Gtk+. Imendio is pushing for a ABI breakage in order to polish the API, sealing the private data in the components, among other things. Nevertheless, Miguel, being the voice of several ISV, is disagree with proposed path.

In the Gtk+ road map, a great discussion has been raised about the new canvas. Seems that the favorite contender is Clutter, pushed by OpenedHand.

In other front, Mark Shuttleworth came up with the idea to integrate QT in Gnome, replacing Gtk+ in the long term.

Alp Toker presented the advances in WebKit development, and in my perception, a lot of gnomies are webkit enthusiast, because have a tighter integration with the Gtk+ widgets and better performance than Firefox currently (which is always temporal). So I expect more applications using webkit rather than embedded Mozilla.

Following the web area, there’s a big effort, basically from the RedHat guys for the online desktop, integrating the desktop with different and heterogeneous web feeds. I think this is a must for the next desktop environment. More and more applications are web integrated, and give a framework to do this and mix all that information smartly is a huge need.

All the multimedia stack is healthy managed by the guys at Collabora and Fluendo. There’s an important effort in data communication (Telepathy and Farsight) using the GStreamer framework. Meanwhile another project, Ekiga, which doesn’t use GStreamer is steady and currently the better application for VoIP in Gnome.

Finally, Miguel is pushing for a HTTP desktop applications model, using Moonlight as front end machinery, and a custom HTTP server as gluing proxy for the back end systems applications. A bold idea with not too many supporters.

As colophon we must say in the mobile area are great efforts (Nokia as main bidder) to keep sync with the mainstream development and improve the performance in both fronts.

The ideas are in the table, the discussion is on going, and the code being committed. Where do you want to work in?