Gnome Bugsquad

The first talk was about bug triaging in Gnome. I can't believe there are only 5 active bug triagers in the project (as in, people fully focused on cleaning up the bug database). Tobias Mueller, the happy and dynamic speaker, made a good job explaining why this is such an important task, as the bug tracker is basically a window to the world. This is what people will be confronted with when they try to interact with the project, and having unanswered bugs lingering around doesn't give a very good impression.

In itself, bug triaging is a great entry point into the project because it doesn't require in-depth knowledge and it brings you closer to the community as you get to know the developers by name, so it's a good way to get involved, learn more about Gnome and help out.

The way triaging work:

• There are bugs. People find them and complain about them in the bug tracker.
• We need to understand and get all the necessary information for the developer to be able to fix it.
• So the status of the bug needs to be kept accurate (more on that later)
• And bug triagers can identify severe issues, such as bugs that come back often or many times so we can inform the adequate people.

I love that quote: "Bug triaging is about making people happy." We want our users to be happy, Gnome is about the people in the end!

Some other happy mottos:

"Be nice, be friendly, be happy."

"Answer early, answer often."

There are several ways to get in touch, through IRC, the mailing list, they're trying to hold bug days but currently lack the manpower to do so. They have a triage guide that is apparently so awesome even the KDE guys use it! :D Here's a link, I have to carve out time to read it.

After showing us some tools to find duplicate bugs and what sort of information to ask for, Toby walked us through the different statuses and how to use them, like what to do if you can't get information from the bug reporter after 6 weeks (the assumption is that this is not a problem anymore so resolve the bug), or if you're triaging a bug from more than 2 releases ago (resolve it as obsolete). Some statuses are reserved for the module maintainers. It's all summarised in a shiny diagram available on the wiki. When you start out you actually can't modify the status yourself, so you should add a comment explaining why you think the status should be updated and someone with the Power on #bugs will change it for you. Quickly enough, once you've shown you understand how this works, you can ask for the ability to change statuses yourself.

The final statement was that they need people and it's a good way to start if you want to get involved, it's not too hard for beginners and it doesn't cost too much time or requires that much knowledge. And you get to know the people and projects.

To get started:

1. Create a Bugzilla account,
2. Read the wiki,
3. Ask questions on IRC,
4. Get started. You can't do anything yet, so write it in the comments,
5. If it all makes sense ask for access to do it yourself.

At the end, he asked who he convinced, I think he should have asked who would consider contributing to bug triaging, that's less commitment while still showing interest :) I joined the ML while he was speaking but I didn't raise my hand when he asked, because my way of doing things is to lurk for a while and then see if/how I can fit something in my schedule, rather than making promises I will break. We'll see how that one goes! I'd love to get more involved with Gnome.

Adding plugins to your Gnome apps

Steve Frécinaux talked to us about libpeas, a framework being developed to make plugin development within Gnome applications easier and more consistent across applications.

Building a plug-in API is very, very hard, and having dissimilar APIs makes it harder -- that is, if you write a plugin for Nautilus, you will have to relearn from scratch to build a plugin for gedit. There's a heavily duplicated code base as well, as most projects seem to have taken the gedit plugin framework as a basis, but it's all slightly different because of bug fixes and fitting their own special needs that are not transmitted upstream.

Libpeas aims to fix all this. Plugins are good because they enable the main codebase to remain simple and clean while allowing for lots of additional functionality.

The goals are:

• Ease of use: the framework should be minimalist with little boilerplate code
• Extensible: different applications have different needs, not every project is like gedit
• Lightweigth: it should only load what you use, e.g. not load python if it's not needed by any plugin

Plugins can be written in C, Python, or Javascript.

A plugin is what you install, which can consist of one or more extension. An extension is the implementation of an extension point (hooks). So plugins can register extensions with several extensions points within the application.

The speaker walked us through the different principles of plugins vs extensions, and finally showed us the steps to follow to make your applicable extensible and create hooks.

I can't find a page for the project on the Gnome wiki though, which is not cool :/

Gnome Development Tools: High-Level Debugging and the Misha Research IDE

To be honest I'm not sure this was particularly Gnome-specific, although it WAS written using Gtk tools :) Nick Papoylias introduced us to a new genre of IDE, based on the premise that debugging hasn't really evolved in the past 20 years when really, there are many ways it could be used besides stepping line-by-line through a program after encountering a problem. Debuggers can be integrated to different phases of the development life cycle, and there are many ideas that academia has put forward that are slow to be adopted, if at all (reverse debugging just made it into the latest gdb for instance).

He admitted that they didn't respect every Gnome UI guideline but as they were experimenting with a new approach to IDE and programming workflow, it made sense to experiment with a different UI as well to save space. The interface felt really busy but I'm not particularly worried about that, that's how IDE tend to be by nature.

They are adding new things to rethink the debugging workflow, that work together with the symbol debugger (gdb).

• Syntax parser: Navigate code in terms of structures, loop iteration, functions -- not only line by line
• Data visualisation
• General purpose extension language: Python
• Reverse debugging

It supports stepping through the syntactic structure while having a up-to-date data visualisation. This is a very nice way to see what is happening as we run through the code, he showed an example of variable insertion in a Binary Search Tree and it was amazing to see the tree be updated for every iteration of the loop. That'd be a much faster way to catch silly little bugs that tend to creep up as you develop (so you can catch them even before writing lengthy unit tests).

The presentation ended by showing us what the extension language could do and wow. Was that impressive. You can use Python functions to call your C code, for both simple and elaborate calls. The Python code directly calls C functions with no intervention from the developer. And through the debugging console we can visualise what's going on (e.g. the tree that is created through Python).

Additionally, if you create a main.py in your project, you can attach callbacks buttons to the IDE. This is really cool. He had it call a plotting application to display random results in a graph and check the distribution or whatever. It was really impressive.

So Python can be used to make inter-language calls, import external libraries, add functionality to the IDE, and call C programs directly. Check out the project website.