Je suis revenu samedi soir d'une petite promenade à Montpellier. Plus qu'une promenade, en réalité, puisqu'il s'agissait des Journées du Libre de Montpellier. J'avoue y être allé avec une toute petite motivation, car la semaine avait déjà été longue, très longue. Mais la motivation a vite atteint son plus haut niveau.

Il faut dire qu'il y a de bons arguments qui vous poussent à aimer cet évènement : les organisateurs sont fantastiques (vraiment accueillants), la ville est très jolie, il y a des intervenants de qualité (ah, j'ai fait baissé la moyenne, je vous le garantis), la nourriture est excellente (que je regrette de n'avoir pas choisi le moelleux au chocolat !), les organisateurs sont fantastiques, etc. Je sais, je me répète sur les organisateurs, mais c'est tout simplement parce qu'ils ont réalisé un travail fantastique, à prendre comme modèle.

Il faut dire que l'accueil fut chaleureux : à mon arrivée, et après que j'ai donné mon nom, on me reconnait comme l'homme au chapeau bleu. Tout de suite, je me suis senti bien, un peu comme à la maison. J'ai pu prendre le temps de discuter avec de nombreuses personnes (organisateurs et non-organisateurs), et il y avait ce petit côté familial qui est fort agréable. Cela donne envie de revoir tout le monde aux Solutions Linux.

Mais je ne suis pas allé là-bas seulement en touriste, puisque j'y suis allé représenter GNOME/GNOME-FR et Ubuntu/Ubuntu-fr. J'ai fait une démonstration de GNOME, et plus particulièrement de Sabayon et de l'accessibilité de GNOME, ainsi qu'une démonstration d'Ubuntu pour montrer à quel point Ubuntu est utilisable par tout le monde. Les démonstrations se sont plutôt bien passées, mais c'est plus aux gens qui y ont assisté d'en juger. Il y avait aussi un stand commun GNOME/Ubuntu qui a rencontré un certain succès, puisqu'il y avait presque toujours du monde devant le stand.

La première conclusion de tout cela est qu'il ne faut vraiment pas faire des démonstrations avec un système de développement (Dapper m'a joué quelques mauvais tours, pas très graves). La seconde conclusion est vivement l'an prochain ;-)

Un grand merci à Fabrice pour m'avoir guidé dans cette magnifique ville et pour son aide, et aussi un grand merci à Canonical pour avoir envoyé des CD Ubuntu et du matériel de promotion (dont de magnifiques autocollants) !

Three weeks ago, Elijah asked me to write an entry explaining how to participate in the release process. I told him I'd do it the next day. So, here we are, three weeks later :-)

It all started with a discussion in the release team about how we could involve more people in the release process. Sometimes after the discussion, Elijah sent this mail. But I believe not enough people have seen it and I'm pretty sure there are a lot of people reading the planet who wonder what can I do for GNOME?. If you're wondering this, search no further.

There are a lot of ways to contribute to GNOME, and GNOME Love is well known. Some people think it's difficult to get in, but it's not. It's really easy and you can even help with our release process. There are many areas where you can help for the release process, but three of them are the most important:

• Writing release notes. The release notes are essential in our releases: this is the first thing people read, to know what's new in the latest GNOME. The notes need to be clear, list all the cool new features and enhancements. They need to be ready a few days before the release, in order to enable translators to translate them. Everyone can help with the release notes. It's really easy. You can do some screenshots or you can write the text. We even have a page on the wiki listing the release notes items. There are already some volunteers ready to help for the release notes, but a small team would be fantastic! If you're interested in this, please contact marketing-list.

• Bugs and patches nagging. There are a lots of bugs in bugzilla. In fact, there are so many bugs that, sometimes, the maintainers can't look at all of them. And they forget some bugs. Big crashers. Localization/internationalization bugs. Patches. Even approved patches. Some of those bugs are easy to fix, some are showstoppers. If we want to have really good releases, we need to fix these bugs. But this implies that we need to find them and know about them. This is where the nagging game is: someone sends a list of bugs to the right mailing list and after a while, maintainers get so ashamed that they have to fix the bugs ;-) Good examples of nagging are: showstopper bugs, internationalization bugs (they have to be fixed before the string freeze), bugs with an approved but not committed patch, bugs with unreviewed patches, etc. You can easily generate some useful list of bugs with bugzilla, so it's not hard. Interested in this? Send a mail to gnome-bugsquad!

• Testing the releases before they go out (smoketesting). Before we do the actual release, we always build the whole GNOME and test it a bit to verify there's no huge crasher. That's what we call smoketesting. It's really easy: you only need to use jhbuild for this and Elijah wrote a nice howto. So, here's the deal: before each release, the release team issues some module sets for jhbuild. Everyone can then build what will be the next GNOME release and verify it compiles fine and works. If it doesn't compile or if there's a showstopper bug, then contact the release team or the maintainer of the relevant module. It should help make our releases be more solid. And with more people smoketesting, the releases should be rock solid! I'll post a blog entry tomorrow to let everyone be able to smoketest GNOME 2.13.2.

See, there is a lot of stuff where you can help. If you want to help in some other way but don't know how, look at this page. And if after this you're still lost, don't be afraid: ask. If you don't want to send a mail to a mailing list, send a mail to someone. If you don't get an answer, try again. You know, GNOME contributors are busy people. But also nice people :-)

Do you want to contribute? I know you want.