Buxy rêve tout haut

One should never loose hope apparently. After my previous posts on the topic, Sam put some more pressure and expressed strongly his disappointment in the lack of progress on the DSA front and warned that he might have to look for more radical solution.

Phil Hands (who was really quiet in the discussions) decided that the situation had lasted long enough already and proposed to add Peter Palfrader (weasel@debian.org) to the team if nobody expressed any opposition in 24 hours. And this morning, Phil added weasel to the “adm” group… which make of Peter a full DSA member!

I really didn’t expect this outcome after so many months of negociations and discussions. But I’m really relieved to see some new blood in the DSA team. I wish him good luck and I’ll hope he will be able to foster cooperation with non-DSA people like I tried since the beginning of the year.

Thank you Phil!

Partagez cet article / Share This

Malgré ma bonne volonté, je n’arrive pas à maintenir un rythme très régulier pour animer mon blog. Il faut dire que rédiger un bon article (c’est-à-dire avec du contenu intéressant, et avec une relecture pour éliminer la majorité des fautes d’orthographe et de grammaire) cela prend beaucoup de temps, et que le temps je n’en ai pas beaucoup à revendre.

En effet, depuis quelques temps je me suis mis à contribuer à dpkg. J’ai commencé avec un projet plutôt important, à savoir l’amélioration de dpkg-shlibdeps pour qu’il génère des dépendances minimales en fonction des symboles des bibliothèques utilisés par chaque programme. Tout au long, j’ai maintenu à jour une page du wiki avec les détails et l’avancement:
http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps.
Comme le développement était assez important, il a eu lieu sur une branche dédiée qui vient juste d’être intégrée dans la branche master (autrement dit, le résultat sera dans la prochaine version de dpkg, c’est-à-dire la version 1.14.8).

Ce projet représente à mon avis une avancée très importante car si les bibliothèques les plus importantes emploient ce mécanisme rapidement, la majorité des paquets auront des dépendances moins strictes et il sera beaucoup plus souvent possible d’installer un paquet de unstable dans stable sans avoir besoin de le recompiler. Autrement dit, il y aura moins de rétro-portages (”backports”) à compiler et il sera plus facile d’installer la dernière version d’une application donnée.

Ce premier projet étant terminé, je me suis attaqué à un plus petit problème mais qui est intéressant tout de même. Jusqu’à présent, dpkg-gencontrol se contentait de substituer les variables dans les dépendances et d’écrire le résultat bêtement dans le champ correspondant.
Parfois le jeu des substitutions introduit des dépendances en double (parfois plus ou moins stricte). Comme lintian se plaint de ces problèmes, cela a conduit de nombreux mainteneurs à supprimer les variables et à mettre en dur les dépendances souhaitées. Maintenant, cela n’est plus nécessaire. En outre, les dépendances sont optimisées de telle sorte que si une dépendance dans le champ Pre-Depends implique une dépendance du champ Depends, cette dernière est supprimée (il en va de même pour les dépendances plus faibles listées dans Recommends puis Suggests). Je viens de soumettre une série de patchs pour inclure toutes ces fonctionnalités.

Je ne sais pas encore quel sera mon prochain projet, mais les récentes discussions sur un nouveau format de paquet source m’interpellent et peut-être vais-je essayer d’implémenter quelque chose qui combine le support du format wig&pen et les avancées apportées par les VCS distribués.

Ces différents développements concernent le paquet dpkg-dev qui contient essentiellement du perl. Ceux qui ne maîtrisent pas le C et qui n’osaient pas s’approcher de dpkg à cause de cela peuvent retourner leur veste et nous rejoindre sur #debian-dpkg sur irc.debian.org et la liste de diffusion debian-dpkg.
Enfin, http://wiki.debian.org/Teams/Dpkg contient des informations intéressantes pour qui veut débuter sur ce projet.

Partagez cet article / Share This

For once, Clint blogged on something that I can understand.

I don’t buy everything he says, but in the case of DSA, the part where he says “you cannot have a functional and respectable subgroup if it maintains autonomy like that” is a real problem.

The leadership problem I mentioned is real. And it can theoretically be solved by undelegating one of the problematic side of this DSA-internal dispute. But which one? Given the unwillingness of Joey to discuss the problems, he makes an easy target… which would leave DSA up to Ryan, James and Phil.

But is that a desirable thing? If DSA is perceived as being an “autonomous” group which is not involved in Debian’s main discussions and which is somewhat disconnected from Debian’s day-to-day life, it’s largely due to the behavior of James and Ryan. E-mail communication with them is very difficult as they’ll respond only if they really care about something. And despite the setup of the request tracker, they have barely been able to make proper usage of it… the idea was to use RT tickets to track everything that DSA does but they don’t use it as such. For example, James setup a “wikiadm” group and he never reported anything to the related ticket (#194) (I did it myself once I found out). Also there’s an internal ticket about the replacement of ftp.debian.org (that I created because ftp.d.o ran out of space regularly) and AFAIK Jeroen has been in touch with James to setup that replacement, but nothing got reported to the tracker. Ryan promised me once to put his DSA TODO list in the tracker so that other people can jump in and help out. He never did.

So while Joey is definitely a pain for DSA, at least he’s a visible participant of the team and he interacts with the community. James and Ryan are not, they interact only through private channels and do not share their opinions or their vision of Debian.
I believe this is a real problem. On the other hand, most of the interesting changes in the last months are the results of James’s work. But he’s also implicitly blocking addition of new members as long as the leadership problem is not solved.

I tried to fill the communication void of the DSA team by various means. I follow everything as closely as I can so that I can report changes on other channels, mailing lists when needed. I made efforts to document stuff on the wiki page, etc. But this is not a long term solution, the communication issue must be fixed within the team.

The path ouf of this mess is still not very clear, but something is going to change soon. Not quite sure what though. What would you suggest? And if you were DPL, what would you do?

Since private discussions and negotiations lead nowhere, it’s tempting to bring the issue in the public area. In theory, they have no way to escape discussions and they’ll have to communicate their grudges against the other side if they want to have some fair judgment between both parties. Unfortunately, given the habits of James and Ryan, they probably won’t participate in any public discussion and either resign or stay where they are waiting for any decision…

Comments welcome.

Partagez cet article / Share This

J’attendais avec une certaine impatience cette dernière mouture de Wordpress pour son support des tags. Je viens de l’installer (maintenant que le paquet est dans sid) et cela fonctionne. Il y a tout de même quelques éléments gênants dans cette mise à jour.

Je n’ai pas eu de problèmes avec mes plugins, en revanche lorsque j’ai converti mes catégories en tags, les catégories ont été totalement supprimées ! La page du convertisseur n’était vraiment pas clair sur cet aspect, en outre la présentation laisse à croire qu’il y aura plusieurs étapes dans la conversion alors qu’il n’y en a qu’une. On choisit les catégories à convertir et hop c’est fait. J’aurai aimé quelque chose de plus évolué où je peux choisir un ensemble de tags pour chaque catégorie… et où la catégorie ne disparaît pas !

Bref, la suppression des catégories a aussi cassé les flux RSS associés (/category/debian/feed/)… j’ai réussi à contourner le problème en configurant le préfixe des URL des tag en “category” (et en mettant “old-cat” comme préfixe pour les catégories, désormais inexistantes sur mon site). Ouf, je n’ai pas à tout recatégoriser… d’ailleurs si vous connaissez un plugin qui permet de recatégoriser/retagger un grand nombre d’articles facilement, je suis preneur.

Le côté positif dans tout cela, c’est que je peux enfin proposer des flux qui sont des intersections entre différents tags. Ainsi au lieu d’avoir un tag “DebianFr” dédié, je pourrai utiliser une URL de flux qui représente l’intersection entre “Debian” et “Français”, cela donne par exemple ceci: http://www.ouaza.com/wp/category/debian+francais/feed/
(bon, c’est vide pour le moment car tous les articles taggés “Debian” sont en anglais… les autres sont dans “DebianFr” jusqu’à ce que j’arrive à trouver la motivation pour reclasser tous les articles :-))

On peut aussi faire l’union entre différents tags au lieu d’une intersection, on utilise alors une virgule (,) comme délimiteur au lieu du symbole plus (+).

Partagez cet article / Share This

On m’a récemment demandé s’il existait un outil Debian pour vérifier qu’un ensemble de paquets dérivés de Debian intègrent bien les dernières mises à jour de sécurité. L’idée est d’avoir un fichier listant l’ensemble des paquets personnalisés avec les versions qui ont servi de base aux paquets personnalisés et d’avoir un outil qui va vérifier automatiquement security.debian.org pour voir si de nouvelles versions sont disponibles.

Ma première réponse était de regarder famke un petit script python écrit par James Troup pour les besoins de l’équipe DSA de Debian: il prévient par mail lorsque des mises à jour sont possibles et essaient de les rapprocher avec le fil RDF des mises à jour de sécurité.

J’ai donc repris le principe et réalisé un petit script python un peu plus souple dans la mesure où il ne vérifie pas si les paquets installés peuvent être mis à jour mais si les paquets listés dans un fichier (que j’ai appelé watchlist) peuvent être mis à jour à partir d’un ensemble de dépôts APT que l’on consigne dans un fichier sources.list personnel.

Il peut servir d’exemples à ceux qui cherchent à employer l’interface “python-apt”. Le script est disponible dans un dépôt Git.

Installation et usage par l’exemple :

$ git clone git://git.debian.org/~hertzog/hacks/checkupdate.git
$ cd checkupdate
$ vim checkupdate.conf
# On change les répertoires pour pointer vers `pwd`
$ vim watchlist
# On indique les paquets à surveiller et leur version courante
$ ./checkupdate checkupdate.conf
An update of the package 'rsync' is available: 2.6.9-2etch1
Origin: [component: 'main' archive: 'stable' origin: 'Debian'
label: 'Debian-Security' site 'security.debian.org' isTrusted: 'True']

Partagez cet article / Share This

Seriously. Now that we have been using the request tracker for quite some time, it’s even more obvious that the DSA team is not up to its task.

Use login “guest” and password “readonly” if you want to check the RT tickets linked in this article.

The facts

• 65 public tickets open (and 5 private tickets)
  • Want to help and seek input from DSA? No response.
  • Want to help and you provide patches and/or solutions? Many are still waiting.
  • Security updates? Who cares…
  • Backup of ftp-master (ries)? No reply (though ftp-master stuff is mirrored on merkel)…
  • New alpha machine? No movement despite the fact that we still have no DD-accessible porter machine.
• 68 tickets closed. Here are some unscientific and manual stats (I counted one each time that someone was involved for the work or for closing the ticket):
  • 27 for James Troup (elmo)
  • 26 for Phil Hands (fil)
  • 13 for me (buxy)
  • 3 for Martin ‘Joey’ Schulze (those I manually forwarded him)
  • 3 for Ryan Murray (neuro)
  • 3 for Matt Taggart (taggart)
  • 2 for Josip Rodin (he handles tickets concerning the mirrors until they have a dedicated queue in the RT)

Note that myself and Matt do not have the needed rights to fix most of the tickets, so we provided help on a best-effort basis. Otherwise we would have done more.

The communication problem

It’s a multi-level problem. Each of the members has some problems with one or more other members. Joey’s behavior has been part of the recurring problems mentioned: he doesn’t use the RT, doesn’t read the DSA email alias and doesn’t follow the DSA IRC channel but he still does stuff very regularly without reporting anything and obviously problems happen. Ryan and James tried to impose him a rule to document what he does, without success apparently. On the other side, as far as I know, Ryan and James also don’t impose themselves to document everything in a central changelog. Joey has refused to provide me an explanation for his behavior. He just reminded me that he holds grudges against James and Ryan because as ftpmasters they didn’t cooperate well with him while he was stable release manager.

In general, outside of all personal griefs that they might have, the DSA members do not communicate very much (at least not on their own official channels). Some examples have already been given concerning the request tracker, but it’s not much more effective on IRC. Most of the traffic on the channel is made up by local admins fixing the problems themselves without any intervention by any DSA.

I also use the channel to regularly ping some DSA about simple issues and/or stuff that they usually handle. It used to work somewhat but lately fil has been busy (with the kernel summit and other conferences) and I simply got no answer at all… for example I pinged elmo, neuro and fil several times in the last weeks in the hope that they handle the tickets of the security team (#150, #157, #164) without results.

There’s room for improvement.

The leadership problem

The team has no designated leader and every time that there’s a decision to take, they are blocked. Joey wouldn’t communicate and give his opinion, Ryan is extremely requiring and perfectionist, there’s not much room for compromise…

A long time ago in a galaxy far, far away, Joey and elmo were friends. It’s even Joey who gave root rights to elmo. Nowadays, it’s rather James that is sort-of leading the team but he’s fed up of the situation and hasn’t managed to get out of this mess.

He refuses to take drastic measures by himself because he’s not clearly the leader and doesn’t solicit a decision of the Debian leader (or the project) because he believes that the DSA team is not under the scope of the constitution!

This can’t last any further. We’ll have to do something about it. Stay tuned.

Partagez cet article / Share This

En tant qu’entrepreneur qui a monté une SARL dans le but d’allier travail et passion du logiciel libre, le sujet du financement du logiciel libre m’intéresse au plus haut point. Je sais aussi, par expérience, que ce sujet peut déclencher des réactions extrêmement vives lorsque des questions d’argent s’immiscent dans des communautés bénévoles. Cela ne doit cependant pas nous empêcher de continuer à mener une réflexion pour trouver de nouveaux moyens de financer le logiciel libre.

Cet article s’attache donc à faire un tour d’horizon de l’existant et à identifier les limites des modèles existants. Enfin, pour finir, je vous ferai partager mes réflexions personnelles sur les critères à respecter pour définir une nouveau modèle économique viable.

Les services aux professionnels

C’est sûrement la solution la plus simple et c’est une solution qui marche pour moi à l’heure actuelle. Je vends mes compétences informatiques aux entreprises qui en ont besoin sous forme de formations, conseils et développements spécifiques. La marge que je dégage me permet de consacrer un à deux jours par semaine au logiciel libre (bien sûr cela veut aussi dire que je pourrais gagner plus si j’arrêtais de contribuer à Debian et que je travaillais plus).

Cela marche, mais cela ne me satisfait pas vraiment. J’essaie d’orienter Freexian comme un spécialiste de Debian, mais ce positionnement ne m’a encore jamais permis de faire financer un développement utile à Debian par un client. Par contre, pour des développements sur un Linux embarqué ou des conseils sur Asterisk, là on trouve plus facilement des clients.

Bien sûr, c’est mieux que de devoir travailler avec Windows, mais il n’y a pas de raison qu’on ne puisse pas trouver une solution où les revenus proviendraient plus ou moins directement d’un travail effectué concernant Debian.

La publicité

C’est le mode de financement de tellement de sites web, qu’on se dit qu’il pourrait aussi contribuer à financer le logiciel libre. C’est sûrement vrai dans quelques cas, mais il me semble que cela restera anecdotique comme mode de financement : d’une part, comme Tuxicoman le faisait remarquer, il y a le problème éthique que cela pose, et d’autre part, il faut avoir une audience très importante pour que la publicité rapporte suffisamment (ce qui n’est pas donné à tout le monde).

Les services en ligne

Héberger un service en ligne représente un coût, et si le service est utile, alors il y a des gens qui seront prêts à payer pour en bénéficier. Tuxicoman voit le logiciel libre comme un produit d’appel pour attirer les gens vers votre offre en ligne. Cela peut être un très bon modèle, mais à mon avis il se limite aux logiciels qui sont en rapport direct avec un service en ligne : il est logique de proposer de l’hébergement de blog si on développe Wordpress, mais si vous êtes développeur de dpkg, je ne vois pas quel service en ligne pourra contribuer à financer votre travail.

Compter sur les fans

C’est un peu le principe du “club Mandriva”. Il faut proposer quelques services et compter sur la loyauté des utilisateurs. Mais on retombe sur la problématique de l’audience, si les services ne sont pas intéressants pour ce qu’ils sont, alors l’équilibre est précaire et repose uniquement sur une population limitée.

Autrement dit, cela peut marcher avec des grosses communautés et pas mal de marketing, mais cela restreint le modèle aux seules boîtes qui ont les moyens d’avoir un service marketing conséquent. Bref, ce n’est pas pour tout le monde.

En outre, du point de vue d’un fan qui souscrit plus pour soutenir le projet que pour les services offerts, il ne sait pas exactement ce qu’il finance. Ou plutôt, il sait qu’il finance tout alors même qu’il préférerait peut-être financer plus spécifiquement le développement libre de telle ou telle fonctionnalité.

---

On le voit, la plupart de ces modèles ne sont pas adaptés pour des individus et des petites structures. Comme je me place plutôt dans cette catégorie, je réfléchis à un nouveau modèle plus adapté — essayant d’allier éthique et rentabilité économique. En menant cette réflexion je suis arrivé à une liste de critères à respecter.

Les critères de succès

Un peu dans le désordre, voici différents points qui, si l’on peut les conjuguer dans une solution concrète (que j’appellerai ci-dessous “le service”), en feraient une solution viable :

• Le service doit concerner tous les utilisateurs de logiciels libres, et pas seulement les “fans”. L’équilibre d’une économie autour du logiciel libre passe par un facteur d’échelle, il doit y avoir plus d’utilisateurs que de développeurs.
• Le service doit être de proximité afin que le client puisse s’identifier à la personne qui le fournit. Je ne parle bien entendu pas de proximité physique, mais de proximité virtuelle. Il faut juste que le client puisse avoir un contact direct avec le développeur et qu’il sache de manière concrète ce à quoi servent les bénéfices réalisés autour du service.
• Le service doit être très lié avec les compétences et les centres d’intérêts du développeur de logiciel libre, afin qu’il prenne plaisir à le fournir.
• En même temps, le service ne doit pas avoir une influence directe sur le projet libre auquel le développeur contribue habituellement.
• Bien entendu, le service doit être utile sur le long terme, car un revenu ponctuel ne permet pas de financer durablement un développeur (sauf don de centaines de milliers d’euros, mais on sort du cadre là :-D).

Pfiou, rien que çà ! Visiblement ce n’est pas facile, mais cela fait quelques temps que j’y réfléchis, et j’ai un projet dans les cartons. Il est trop tôt pour en parler mais je ne manquerai pas d’y revenir en temps voulu.

Partagez cet article / Share This

Toute distribution Linux est personnalisée pour y intégrer des éléments visuels distinctifs. Cela inclut les écrans de démarrage, l’aspect de l’installateur, l’écran de connexion (thème gdm), les fonds d’écrans, les thèmes Gtk+ et j’en oublie sûrement. Tous les artistes qui souhaitent contribuer à Debian dans ces domaines sont les bienvenus sur http://www.debianart.org/, ils peuvent soumettre librement leurs œuvres et les mettre à disposition de tout le monde.

En plus des éléments intégrés à la distribution, il y a l’apparence du site web. Il est de renommée mondiale que son look “années 1990″ laisse à désirer et qu’il est possible de faire plus joli sans pour autant sacrifier les aspects positifs (traduction, accessibilité, usage de tout l’espace, etc.). Certains s’y attellent : la page LayoutProposal du wiki regroupe quelques propositions. Les dernières, comme celle-ci, sont d’ailleurs assez prometteuses. Pourtant ce n’est pas la première fois que je vois des maquettes qui ne passent jamais à l’étape de “production”. Des volontaires motivés pour mener à terme ce projet sont donc toujours les bienvenus sur la liste debian-www. Le site web contient les explications nécessaires pour comprendre son fonctionnement actuel.

Dernier élément relevant du “visuel”, il y a les jaquettes de CD/DVD (exemple de contribution). Là aussi, n’hésitez pas à laisser parler vos talents d’artiste!

Cet article fait partie d’une série expliquant - par des exemples - comment contribuer à Debian.

Partagez cet article / Share This

A few days ago I created a planet for French Debian users, and the interest is slowly growing. In fact, I just received a request to add an English-speaking blog!

So the question is: why not creating (and hosting) an English-speaking planet for Debian users that would allow only Debian-related articles. Developers are also users and if they have a feed dedicated to their Debian posts, they could add it of course. It would be handled like the current planet and a few volunteers could collect and process the requests to add new feeds for non-developers.

This would provide the much-requested alternative of filtering planet Debian… and also encourage some of our users to blog about Debian and how they use it.

What do you think of this idea?

Partagez cet article / Share This

Depuis quelques jours mon blog est syndiqué sur Planète Libre une planète qui regroupe divers blogs francophones traitant du logiciel libre. J’apprécie cette planète car cela permet de s’ouvrir un peu plus au reste du milieu du logiciel libre alors que j’ai tendance à toujours être plongé à 100% dans Debian.

Vous ne comprenez pas le titre de l’article ? Pourtant, c’est assez simple : planète libre n’est pas encore libre. Son créateur, Sébastien Bilbeau, n’en publie pas encore les sources qui permettraient à d’autres d’utiliser le même logiciel pour créer d’autres planètes. Comme j’ai vraiment apprécié le look de la planète et sa fonctionnalité de votes, je me suis mis à chercher les sources avec l’idée éventuelle de l’employer pour les planètes Debian francophones — en vain. J’ai alors contacté Sébastien pour me faire confirmer qu’elles n’étaient pas disponibles.

Suite à cette déception, j’ai hésité à faire dans la presse à scandale (”Planète libre, la planète qui n’a de libre que le nom !”) mais je me suis dit que cela serait contre-productif et dommageable pour tout le monde.

Du coup, je préfère féliciter Sébastien pour ce qu’il a créé, et l’encourager à libérer le code source de planète libre ! Je vous invite à en faire de même en votant nombreux pour cet article afin qu’il pénètre dans les tops du site (l’article le plus populaire est à 35 votes à l’heure actuelle) et que Sébastien n’oublie pas notre souhait.

Partagez cet article / Share This