I've seen some Debian people doing DWN-like posts and I thought it'd be a nice way to let people know about what I (or others) have been doing lately. Okay, this will probably not be in the real DWN format, but it doesn't matter that much. And don't think the next posts like this one will be as lengthy: I'm cheating and talking about old stuff in this one :-)

Foundation elections

Looks like I'm running again this year. At first I didn't really want to do it, but after talking with a few people and after seeing there were not enough candidates, I sent my candidacy. Of course, many people nominated themselves within the last hour before the deadline :-)

Instead of having big plans for next year, I've thought it might be better to focus on little things that are helpful. This is probably what I should have done this year. It's also nice to see some new candidates running: it makes me feel that you can get involved in GNOME and feel part of the community quite fast (and we can still improve a lot here)

Membership Committee

Good to see that Barış completed the new membership management system. This is something I really wanted to finish before I left the committee last January, but I couldn't achieve it. Now applications can be processed quite easily and are all tracked with rt3. I've seen the committee in action (you can look at the membership-committee archives) and it's quite impressive.

gnome-desktop

I've been cleaning the gnome-desktop bugs lately. Now most of the bugs are related to the fact that we're using GnomeCanvas (I can't wait for a canvas in GTK+ :-)). I've also deprecated GnomeDItemEdit since nobody uses this anymore and it's just not GNOME-y.

The next big thing is killing most of the icons we ship in this tarball. I've discussed this a bit with Andreas (who nearly died of horror when he looked at the icons). The hard issue here is that people are using those icons for their launchers and we don't want to break their configuration (you know, compatibility, etc.), so we can't simply remove them. Having symlinks to icons in the gnome icon theme or a gnome-compatibility module sounds like two possible solutions.

I guess I can also ask for help to our translators to fix this bug.

gnome-session

Some cool action happening here. First, Tom Tromey started triaging bugs for gnome-session. What most people probably don't know is that Tom is one of the first guy who worked on gnome-session in 1998. In the last few weeks, he's done a wonderful job with the bugs, and even started writing some patches. I seriously hope he'll maintain this module soon (he needs help from the sysadmin team to update his ssh key).

There's also Dan's work on session management. The goal is to get session-related code right for 2.20. Rock!

As for me, I've been reviewing and committing patches. I also started rewriting the session properties capplet in python. In its current incarnation, the capplet looks bad:

• most items in the "Session Options" doesn't mean anything for most users
• I don't know of anybody using multiple sessions
• the "Current Session" tab should probably be a view of gnome-system-monitor

So we're left with the "Startup Programs" tab, which needs a lot of work anyway. The thing is, a capplet with only this doesn't look really nice, and I didn't feel motivated enough to finish it. I should still do it.

freedesktop.org specs

In the last few months, we've been slowly improving some specs, The desktop entry spec saw the most work, and it's starting to look really good now. The autostart spec has seen discussions (thanks Dan!), but we need to agree on some stuff before updating it. We should also probably look at the menu spec which could do with some love, I suppose.

I also intend to update desktop-file-utils since it's probably not doing a perfect job at following the spec (especially since we updated the spec ;-)).

CVS cruft

The sysadmins moved 200 old modules to the archives repository. I'm sure there are still many modules in the 600+ ones we have in CVS that could be moved there. In fact, I even started a list of modules that we could move there, but it would need confirmation from each maintainer. If someone wants to help here (by sending a mail to the relevant maintainers), just contact me. We'll then be able to enjoy a CVS with less cruft. And maybe, one day, a faster conversion to SVN :-)

Release Team

Awesome mail from Andre (why aren't you on Planet GNOME???). This is really something where we sucked in the past, and I'm glad that our newest release team member is doing the bug nag work. It didn't get a lot of replies, though.

I've also been amazed that releasing the latest GNOME versions has been simpler than ever. I guess there are two reasons for this: our external dependencies list and the build brigade. We should give more love to Frederic for tracking HEAD buildability.

GNOME Goals

Wow. Long time since the last one. We really need to get another one out soon. The one about the About Dialogs looks good, but is blocked by this bug. Or maybe we can simply try to finish the gnome-doc-utils migration?

JDLL 2006

I didn't blog about this, but GNOME-FR was present at the JDLL. It's always fun to be there. We had a nice booth thanks to our volunteers and the GNOME Event Box. We got some ideas on how to improve the booth and ideas of things that should happen in GNOME (probably more on this later). I'm a bit sad that we didn't think about having a wall of love, though.

INBOX

I'm now trying to clean my GNOME INBOX. There are many mails there that probably need answering, and I feel bad about this. If you're waiting for an answer, don't hesitate to send a ping!

Je résiste à l'envie de créer un compte sur linuxfr pour répondre à ce journal. Mais du coup, je réponds ici :-) Il y a beaucoup de faux problèmes, rumeurs et incompréhensions, et quelques vrais problèmes.

Je colle l'extrait :"New modules may be accepted into the desktop or admin releases with a dependency on gtk#/mono"

Beaucoup ne savent pas comment GNOME est découpé. Il y a quatre regroupements de logiciels :

• la plate-forme : il s'agit des bibliothèques de base comme GTK+, gnome-vfs, etc. ;
• le desktop : cela contient toutes les principales applications (tableaux de bord, gestionnaire de fichiers, navigateur, client mail, etc.) et c'est généralement à ceci qu'on pense quand on parle de GNOME ;
• la partie admin : quelques outils pour faciliter la vie des administrateurs ;
• les bindings : ils permettent de développer des applications GNOME dans d'autres langages que le C.

Cette décision ne concerne donc que le desktop et la partie admin. La plate-forme n'est pas concernée. Je précise car c'est important : si mono était accepté dans la plate-forme, alors la dépendance serait vraiment présente. En l'état actuel, il ne s'agit que d'applications. Voir ci-dessous pour mieux comprendre cet argument.

Cela va donc obliger les utilisateurs de Gnome à avoir Mono et le binding GTK# sur leur ordi.

C'est faux. GNOME est modulaire : on peut tout à fait installer 99% de GNOME sans avoir mono. En l'occurence, actuellement, il n'y a que Tomboy, qui est un tout petit programme, qui dépend de mono. Il n'y aura en outre pas de grosse migration vers mono (du type : on réécrit tout), sauf peut-être pour quelques modules si les mainteneurs en voient le bénéfice. Dans ce cas, il faudra l'accord de la release team.

C'est une décision très controversé du fait de l'incertitude juridique et technique autour de Mono

Oui, c'est une décision controversée. Mais ce n'est pas à cause de l'incertitude juridique : depuis que l'OIN existe, ce point n'inquiète presque plus personne. Red Hat était plus que réticent à l'idée d'utiliser mono, mais cela a changé.

Les principales controverses, à mes yeux, concernaient les performances de mono et le fait qu'accepter d'utiliser mono dans GNOME signifie que nous acceptons d'utiliser un autre framework complet, alors que GNOME a pour but d'être un tel framework. Il y a eu de longues discussions sur ces points et donc la décision en a tenu compte. Il faut noter que l'aspect performance est un faux problème car pour tout module proposé pour inclusion dans GNOME, la performance est évalué. Que le module dépende de mono ou non, cela ne change rien lors de l'évaluation.

Pour les irréductibles réfractaires à Mono il reste XFCE qui devient vraiment bien et dont la release 4.4 promet de roxer. Il va également y avoir beaucoup de changements dans KDE avec le passage en version 4.0 et les gnomistes réfugiés peuvent espérer une grosse refonte de l'interface utilisateur afin de se rapprocher de la simplicité de Gnome.

XFCE 4.4 va être très bien, et KDE 4.0 le sera sans doute aussi. Mais parler de gnomistes réfugiés me semble un peu extrême. Pour les utilisateurs qui ne s'intéressent pas au côté technique, cette décision ne change strictement rien. Pour les utilisateurs s'intéressant au côté technique, je doute que cela change grand chose pour bon nombre d'entre eux. Il faut aussi voir ce point de l'autre point de vue : des gens auraient quitté GNOME si cette décision n'avait pas été prise.

Passons aux commentaires de ce journal...

Il est évident que cette dépendance introduite ici va être utilisée par pleins de logiciels et qu'il va devenir impossible d'être un gnomiste sans utiliser Mono.

On ne contrôle pas le langage qui est choisi par les développeurs de logiciels libres. Il existe déjà de nombreuses applications utilisant mono dans le monde GNOME, et ce, indépendamment de la décision concernant GNOME. Cela ne veut pas dire que toutes les nouvelles applications utilisent mono, loin de là (beaucoup de gens préfèrent PyGTK).

C'est si lent que ça une application développée en Mono ? Tu as un exemple en tête ?
beagle? Et ca en bouffe de la ressource en plus et ca marche meme pas bien qui plus est.

ou encore :

>> As tu seulement utilisé mono
Oui et j'ai viré Beagle vite fait.

On voit souvent cet argument/cette confusion. Beagle n'est pas l'exemple le plus adapté pour juger des performances d'une application mono en raison de tout ce que beagle essaie de faire. Et beagle n'est pas lent en tant que tel, mais a une consommation mémoire horrible. Quelqu'un a d'ailleurs bien relevé ce point :

Ça fait plusieurs fois que je vois des gens juger Mono à partir de Beagle ou F-Spot... vous avez vu le numéro de version de ces logiciels ? Beagle est une 0.2.x, et fspot une 0.1.x.

Après avoir viré l'applet mini-commander pour la remplacer par la deskbar-applet et sa dépendance à python,
Voilà qu'il vire l'applet pense-bête pour la remplacer par tomboy et sa dépendances à mono.
et en plus, imposer ces mastodonde au coeur du projet GNOME :((

J'ai du mal à comprendre comment une applet peut se trouver au cœur du projet GNOME, mais bon... Tout d'abord, l'applet pense-bête va rester un certain temps avant d'être disponible séparément. Donc il ne devrait pas y avoir de problème, si ?

La méthode pour imposer mono est très Crosoftienne. D'ailleurs je ne suis pas étonné de voir que cela vienne des marionnettes et autres proxy open source de Crosoft (il paraît qu'il y en a qui doutent encore :p ).

Alex Graveley travaille pour VMware et a développé Tomboy sur son temps libre. Est-ce que cela fait de lui une marionnette de Microsoft ? Si oui, il faut vraiment m'expliquer :-)

Le principe est simple: tu prends un composant logiciel qui marchent (sticky notes), tu le re-écrits en ajoutant 3 features à 2 balles mais avec le framework qui arrange tes affaires (tomboy)... et SURTOUT tu n'améliores pas la version qui existe en avançant des arguments coup de point, genre "je sais pas coder, alors j'utilise mono.net!". Résultat, tu fais dégager une appli qui marche et tu imposes ton framework... magie!

Je comprends un peu mieux comment naissent les rumeurs désormais :-) Le fait est que presque personne ne travaillait sur l'applet pense-bête. Il aurait certainement été possible de l'améliorer et de ne pas accepter Tomboy mais personne n'a été là pour le faire... Alex a travaillé sur Tomboy de manière indépendante, sans toucher l'applet pense-bête (probablement car Tomboy était un essai au début). C'est le logiciel libre, les gens décident parfois de commencer un nouveau projet au lieu d'en améliorer un existant.

Dans une grosse entreprise, disons que tu veux "vendre" (et oui... il faut bouffer un jour) du desktop libre... bin avec mono dans gnome tu te retrouves sur le terrain technique où Crosoft est leader dans l'esprit des décideurs (.NET=Crosoft, JAVA=Sun)... résultat, tu donnes un paquet de billes pour te faire orbitaliser par les commerciaux de Crosoft... mais ça, j'ai l'impression que peu de gens comprennent.

Il faudra expliciter le raisonnement car je n'arrive pas à le suivre. Les décideurs qui vont décider pour le choix d'un environnement de bureau ne s'intéressent pas à mono, mais à l'environnement de bureau. Si c'est à propos du développement de logiciel, j'arrive déjà mieux à comprendre, mais les décideurs ne seront-ils pas intéressés de voir qu'ils peuvent envisager de migrer vers autre chose que Windows sans changer de code ? (réelle question de ma part)

Par contre en faisant entrer Mono par la petite porte, il y a des chances que certains essaient d'en profiter pour l'imposer comme pilier de Gnome 3.

GNOME 3 ne sera pas un changement technique, mais un changement dans l'ergonomie et la façon de penser le bureau. Je suis de ceux qui pensent qu'on peut faire tout ce que GNOME 3 pourrait être dans GNOME 2.x, donc il est vrai que je suis peu réceptif quand on parle de GNOME 3 ;-)

Pour conclure, le débat GNOME/mono a fait rage depuis quelques années. Aujourd'hui, rien de majeur n'empêchait cette décision et la release team savait très bien qu'il y aurait des mécontents, quelqu'aurait été la décision. GNOME reste libre et s'ouvre à de nouveaux développeurs. Est-ce vraiment une mauvaise chose ?