Papa est mort d’un cancer des poumons (à petites cellules), 16 mois après le diagnostic de la maladie. Malgré une première chimiothérapie fructueuse, le cancer est réapparu seulement 3 mois après. Aucune des chimio ultérieures n’a réussi à faire régresser le cancer, tout juste à ralentir sa progression. Il était hospitalisé depuis 3 semaines, étant devenu trop faible pour se déplacer seul dans la maison familiale. Il est mort en dormant, il s’est simplement arrêté de respirer.

Papa était apprécié de tout le monde, il était bon-vivant et avait le contact facile. En témoignent les 500 cartes de condoléances que nous avons reçues. Le président du cercle d’histoire de Hésingue (duquel papa était un membre très actif) a même rédigé un article publié dans les DNA et dans l’Alsace pour rendre hommage à son implication dans le milieu associatif (l’article oublie cependant sa participation au sein de la Ligue pour la Protection des Oiseaux).

• translate my Debian book into English and get it published;
• finish the cleanup of the perl API in dpkg-dev in order to create libdpkg-perl;
• create dpkg-buildflags to export default build flags that packages should use (and get rid of the code setting those environment variables in dpkg-buildpackage), needed to properly fix #489771;
• ensure the new source formats continue to gain acceptance by improving whatever is needed;
• design a generic vcs-buildpackage infrastructure to be integrated in dpkg-dev. This design will probably happen through a DEP (Debian Enhancement Proposal) to ensure we have had proper discussion before someone gets to the implementation;
• continue fixing dpkg bugs faster than they are reported;
• enhance our infrastructure to ease interaction between contributors and to have a better view of how each package is maintained (see my last blog entry on this topic);
• update the developers-reference where needed and fix some of the numerous wishlist bugs;
• rewrite in C the last perl scripts provided by the dpkg binary package (update-alternatives/mksplit mainly, for dpkg-divert there’s a preliminary patch available already) so that it’s easier to build a minimal system without perl-base;
• integrate the 3-way merge tool for Debian changelogs in dpkg-dev;

All of this probably doesn’t fit in my free time (being a father since last month does not help increasing my free time ), so if you’re interested in seeing one or more of those projects completed, and if you know some person/company that could sponsor them, get in touch with me!

Given that Freexian is still alive I think I met the first goal. My free software experience allowed me to complete many projects: a large number of development projects for embedded devices running a custom Linux distribution (usually built with debian udebs), the development of a Debian derivative (SLIS) and some recurring tasks of remote system administration.

However, even if I use Debian daily for all my work, very few of the projects that I complete for customers have direct results in terms of improvements for Debian (except some bugreports and some related fixes). And even when I’m able to contribute something back to Debian, it’s usually not in areas that I care about.

My focus within Debian is on the technical and organizational infrastructure of the project: as a dpkg/dpkg-dev maintainer I try to improve the packaging infrastructure, as a QA member I maintain the Package Tracking System to ease collaboration, as an Alioth admin I ensure all DD can host VCS repositories for their Debian related projects, as a developers-reference co-maintainer I try to share good packaging practices, etc. Given this bias, it’s difficult to find customer projects that would let me contribute in those areas. Thus I think I need to try another approach: the simplest solution would be to find sponsors for some of my own Debian-related projects (if you have something else to suggest, please leave a comment — either in the blog or by mail).

That said finding sponsors looks like a difficult task in itself. While I can imagine (for example) a company using Debian on embedded devices that would like to sponsor the rewrite of update-alternatives in C in order to get rid of the perl dependency in the dpkg package (if you know such a company, get in touch with me!), I don’t see who would have an interest in sponsoring the time that I need to contribute new sections to the developers-reference manual. But who knows… maybe I should just try and publicly solicit sponsorship for some of the projects that I care about. In any case, suggestions and comments are welcome!

I have updated the wiki page and the release goal page with latest information. Feel free to convert some of your packages to give it a try. For ftplib, it led me to discover a Debian specific patch that I completely missed when I took the package over. This is precisely the kind of benefit that I expect from generalizing this format, it will encourage us to have separate documented patches instead of keeping everything hidden inside the usual .diff.gz. Combined with DEP-3 (patch tagging guidelines), we have a better infrastructure to share our patches with the rest of the free software community.

The next step is to fix all bugs listed here and make dpkg-source use the new source formats by default (#553928). Feel free to help by preparing patches (and offering NMUs), it’s a release goal to have all packages buildable with new source formats.

I’ve just gone ahead, so let me introduce you git-merge-dch. Grab it with git clone git://git.debian.org/~hertzog/git-merge-dch.git, you can build a package if you wish. Beware, you need to have a dpkg-dev 1.15.5 that is not yet published (so you need to build dpkg from its git repository, git clone git://git.debian.org/dpkg/dpkg.git) as I rely on features that I introduced recently… you will also need the libalgorithm-merge-perl package.

Using it in a git repository requires two changes:

• defining a new merge driver somewhere in the git configuration (in .git/config or ~/.gitconfig for example):

  [merge "git-merge-dch"]
          name = debian/changelog merge driver
          driver = git-merge-dch -m %O %A %B %A
  

• defining the merge attribute for debian/changelog files either in .gitattributes in the repository itself or in .git/info/attributes:

  debian/changelog merge=git-merge-dch
  

Now you can safely maintain two branches of a package with changelog files evolving separately and merge one into the other without creating undue conflicts. Suppose you created an experimental branch for version 2.28 (you use a version 2.28-1~exp1) when 2.26.2 was current stable in the master branch. In the mean time, 2.26.3 got out and was packaged in master. Next time you merge stable into experimental, the changelog entries for 2.28 and 2.26.3 won’t collide despite being at the same place in the changelog file compared to the common ancestor.

Let’s continue with this example, 2.28 is out. Instead of adding a new changelog entry with « New upstream release » without further changes, you keep the current changelog entry and simply change the version into 2.28-1. While preparing this you discover a branch with fixes that was based on 2.28-1~exp1, if you merge it it will reintroduce a 2.28-1~exp1 entry that you don’t want. Fortunately you can use the --merge-prereleases (-m) option of git-merge-dch so that it strip the prerelease part of the version string and considers 2.28-1~exp1 and 2.28-1 to be the same entry really.

The only limitation is that this merge tool will remove any lines which are not parsed by Dpkg::Changelog (and which in theory are not supposed to be there).

Feel free to test, share your comments, report bugs and send patches!

When thinking of this idea, I only saw the QA side of ensuring good maintenance on all packages, however I believe that the root problem lies further and this project would not be enough: we are interdependent but we are not equipped to deal with this reality. Martin’s only merit has been to mention that we are interdependent, but it’s worth analyzing a bit.

Our organization is centered around individuals acting as package maintainers, and in theory each package maintainer can work on his corner and all goes well. We know that this model doesn’t hold any more: transitions to testing require coordination of uploads and timely fixes of RC bugs, keeping up with the work frequently requires several volunteers that have to coordinate, etc. More and more of the work requires a level of availability that a single individual can’t offer, yet in our day-to-day work we mainly interact with individuals. Wouldn’t it be better if we could immediately know what we can expect from any Debian developer:

• mean time to reply to Debian mail (reading every day or once a week is not the same);
• amount/periods of time spent on Debian (knowing that they spend up to 4 hours mainly on Saturday can be useful);
• current availability for Debian (if they are currently busy with life, we should be able to know it, if they know when it will end, it would also be good to share);
• best way to get in touch for issues (they might have preference between IRC or mail);
• kind of relationship they have with packages where they are listed in Maintainer/Uploaders (an active maintainer that uses the software daily is not the same than a passive maintainer that only packaged the software because it was a build-dependency for some other software that they care about);
• any other information that the maintainer wants to share (about his habits/constraints/values/goals/whatever).

All this information should be shared by all Debian maintainers (some of it is already available but either not publicly or not in any machine-parseable way) and we should actively use it. Here are some examples of use: for each RC bug report, you could look up if at least one maintainer is available and you could ping him explicitly if needed. When you plan an NMU, you could look up if the maintainer is likely to respond in the next day or not, and possibly adjust the number of days spent in the DELAYED queue. When organizing a large-scale transition, you could extract a list of packages whose maintainers are not available and arrange immediate NMUs.

Furthermore there are many cases where the project’s usual expectation exceed what the maintainer is ready to do. Documenting what part of the job is done (or not) by the maintainer makes it clear for volunteers whether their help is needed and whether they could/would be a better maintainer for a given package.

Designing solutions to all these problems is going to be the scope of the DEP2 that I reserved some time ago. It’s likely to be some sort of dedicated web interface. I would welcome supplementary drivers for this DEP, so if you’re interested, get in touch with me.

Je vous propose à nouveau une lecture pour cet été, ca parle de vacances mais pas seulement…

Thimoty Ferriss s’appuie sur sa propre expérience pour expliquer comment tout un chacun peut essayer de devenir un « Nouveau Bienheureux », une de ces personnes qui profitent de la vie maintenant au lieu de se contenter d’une perspective de retraite encore lointaine. Partant de là, il nous invite à réfléchir sur nos rêves et sur ce que nous souhaitons réellement réaliser dans la vie. Une étude détaillée de ces derniers nous apprend qu’ils ne sont souvent pas si inaccessibles que nous voulons bien le croire. Simplement notre mode de vie et nos préjugés nous empêchent de les considérer comme réalistes. De plus, leur coût paraît souvent rédhibitoire.

L’auteur entreprend donc de nous guider pas à pas pour résoudre ces différents problèmes. Il remet en cause notre mode de vie et nous incite à devenir propriétaire d’une entreprise dont l’objectif ultime est d’assurer le financement de nos rêves tout en ne nécessitant qu’un minimum de travail. Les chapitres se succèdent pour expliquer les modalités : trouver une idée de produit à marge importante, automatisation de tout ce qui peut l’être, externalisation du reste… le tout saupoudré de conseils concrets pour obtenir une efficacité maximum. Efficacité d’autant plus importante lorsque l’on est salarié, et qu’il faut être meilleur que ses collègues pour mettre toutes les chances de son côté en vue d’une négociation d’un accord de télétravail. En effet, la mobilité fait partie intégrante de l’art de vivre des nouveaux bienheureux. Le livre se termine sur des conseils pratiques pour organiser ses voyages et profiter pleinement des nombreuses mini-retraites que ce nouveau mode de vie rend désormais possibles.

En achetant ce livre, je n’en attendais pas grand chose… je suis habitué aux livres de boursicotage faisant miroiter des perspectives alléchantes mais dont la mise en œuvre est très délicate pour ne pas dire impossible. J’ai pourtant été agréablement surpris, ce livre ne se concentre pas uniquement sur la partie entrepeneuriale du projet, il distille des conseils applicables à tous et nous pousse à remettre en cause notre situation… certaines de ses recommandations recoupent d’ailleurs les principes énoncés dans Les 7 habitudes de ceux qui réalisent tout ce qu’ils entreprennent. Ayant lu la semaine de 4 heures avant ce dernier, les réflexions de Thimoty Ferriss ont réellement attisé un désir de réfléchir sur ma situation et mon mode de vie.

Travailler quatre heures par semaine n’est pas réaliste pour tout le monde, mais tout le monde a la possibilité de changer son mode de vie pour l’améliorer et ce genre de livres est là pour nous le rappeler.

Ensuite chaque nouvelle version devrait freezer en décembre des années impaires, donc squeeze+1 freezerait en décembre 2011, squeeze+2 en décembre 2013. Cela permet une meilleure coopération avec Ubuntu puisqu’ils prépareront leur version LTS en même temps que Debian préparera sa nouvelle version.

Voilà une nouvelle inattendue dont il est difficile d’évaluer les conséquences à ce point. Les prochains mois promettent d’être intéressants…

Bien que le titre laisse craindre un énième livre avec des recettes miracles, il n’en est rien. Le terme d’habitude signale simplement qu’il est important d’assimiler les principes énoncés pour que les mettre en œuvre devienne naturel. Ces principes ne sont pas des recettes mais des lignes directrices qui doivent nous guider dans chacun de nos choix pour tirer le meilleur de nous-mêmes et des autres. Voici un bref résumé.

Habitude 1 : soyez proactifs

De choix il est justement question dans la première habitude. Celle-ci nous explique en effet qu’à chaque « stimulus » nous pouvons choisir notre réaction. Ainsi, lorsqu’un événement nous énerve ou nous agace, il en va ainsi parce que nous l’avons choisi. Bien souvent la société ou notre entourage nous fournit des réactions toutes faites (et dans ce cas nous ne faisons pas réellement usage de notre possibilité de choisir), mais elles ne sont que rarement en concordance avec nos objectifs personnels.

Habitude 2 : sachez dès le départ où vous voulez aller

La deuxième habitude s’attache justement à définir nos objectifs personnels. L’auteur nous invite à nous projeter dans le futur le plus lointain possible : « que voulez-vous qu’on dise de vous le jour de votre décès ? ». Ainsi pour chaque rôle que l’on assume (employé, parent, ami, membre d’une association, etc.), il faut trouver des objectifs qui nous motivent réellement et dont on serait fier. Puis il faut les formaliser dans un énoncé de mission personnel. Cette capacité à se projeter dans le futur et à imaginer les conséquences de ses actes est le fondement de cette habitude. Les choix quotidiens sont plus faciles à faire si l’on sait où l’on va.

Habitude 3 : donnez la priorité aux priorités

La troisième habitude nous aide à gérer notre temps. Nous avons tous des longues listes de choses à faire et il est facile de se laisser submerger malgré une organisation méthodique. L’auteur nous invite à évaluer toutes les tâches selon deux axes, l’urgence et l’importance. La première s’évalue selon le délai disponible et la seconde selon la contribution de la tâche à nos objectifs personnels. À partir de là, il faut consacrer son temps aux tâches importantes (qu’elles soient urgentes ou non) et limiter le temps alloué aux tâches non-importantes. Il est important de passer du temps sur les tâches importantes non-urgentes car celles-ci contribuent généralement à l’amélioration de la situation à long terme (ex : prévenir les problèmes au lieu de les gérer).

Ces trois premières habitudes sont centrées sur l’individu et permettent normalement à tout un chacun de mieux appréhender sa vie. Mais la vie humaine se conçoit avant tout en société, c’est pourquoi les trois habitudes suivantes concernent les relations avec les autres.

Habitude 4 : pensez gagnant/gagnant

La quatrième habitude nous invite à dépasser les situations inutilement manichéennes. Lorsqu’une décision ne convient pas à l’une des parties, il est souvent possible de prendre une autre décision qui convienne à tout le monde. Il ne s’agit pas forcément de compromis : une fois les attentes de chacun clairement formulées, notre imagination peut trouver des solutions inattendues. Enfin, en dernier recours, on peut aussi envisager le statu-quo pour éviter de faire un perdant.

Habitude 5 : cherchez d’abord à comprendre, ensuite à être compris

La mise en œuvre de la 4ème habitude requiert une volonté de satisfaire les attentes des autres et cette 5ème habitude en est un prolongement naturel. L’écoute par empathie suppose d’aller dans le sens de son interlocuteur pour mieux connaître son mode de pensée, le paradigme dans lequel il évolue. Cela permettra aussi de formuler nos attentes de manière à ce qu’elles résonnent plus dans son esprit.

Habitude 6 : profitez de la synergie

La sixième habitude nous laisse miroiter des perspectives aussi intéressantes qu’inattendues. Créer des situations synergiques nécessite que les différents participants aient bien acquis les principes 4 et 5 et qu’ils se fassent confiance pour trouver collectivement une solution innovante. En effet, un processus de création synergique est dirigé par tout le monde et personne à la fois, il est donc difficile de prévoir les résultats mais ils sont bien souvent meilleurs qu’espérés car l’ensemble forme un tout bien plus important que la somme des parties.

Habitude 7 : aiguisez vos facultés

Enfin, la septième et dernière habitude est probablement une des plus importantes. Elle nous rappelle que nous devons chercher un équilibre conjuguant le physique, le mental, le social et le spirituel. Nous ne pouvons aller de l’avant que si nous le voulons et cela n’est possible que si l’on est bien dans sa peau. Il est donc important de passer du temps à s’entretenir physiquement, à apprendre de nouvelles choses, à faire le point sur ses objectifs, c’est un investissement sur soi-même — le plus rentable qui soit.

Avis personnel

Je ne saurai que vous recommander ce livre de Stephen R. Covey. En le lisant je me demandais pourquoi notre éducation à l’école ne passait pas par la lecture de ce genre de témoignages, tant il me semble que ce livre peut aider à se forger une identité et à donner du sens à nos vies. Quoi qu’il en soit, même si l’on n’adhère pas forcément à cette vision des choses, l’exploration de ces principes reste intéressante, d’autant plus qu’ils sont agrémentés d’exemples très concrets.

Pour la première fois depuis longtemps, le stand Debian a pu proposer des articles de merchandising : t-shirts, badges, stickers et mêmes quelques livres (anciens cahiers de l’admin bradés) ont ravis les nombreux utilisateurs venus nous voir. Nous avons également récolté une dizaine d’adhésions à l’association Debian France qui prend enfin son départ officiel après deux ans de stand-by à cause d’un malentendu avec le ministère des finances.

La présence sur ces événements permet aussi de nous faire entendre au sein de la communauté du libre, plusieurs d’entre nous ont répondu à des interviews et nous avons pu ainsi défendre le point de vue du projet Debian. Pour ma part, j’ai été interviewé 20 minutes par Radio RMLL et j’ai également été filmé par Annexe21. Dans les deux cas, j’ai pu expliquer ce qu’était le projet Debian et éclaircir les raisons qui font que nous n’avons pas Firefox mais Iceweasel.

Face à ce bilan plutôt positif, j’espère que les utilisateurs qui rejoignent Debian France permettront d’assurer une présence de notre projet sur de nombreux événements locaux afin de renouveler cette expérience et nous rendre plus visible. Dans cette optique, Aurélien Couderc vient de rejoindre l’association pour prendre le rôle de responsable Merchandising.

Ils gagnent un cahier de l’admin Debian et un abonnement d’un an à une revue des éditions Diamond.

Le prix réduit devrait permettre de toucher un public plus large, c’est en tout cas l’esprit de cette collection. La dernière édition (traitant de Lenny) reste réservée à la collection Cahier de l’Admin.

%:
	dh --with quilt $@

There’s also dh_quilt_patch and dh_quilt_unpatch for those who don’t use tiny rules files.

Enjoy !

Je suis heureux d’annoncer que GNU/Linux Magazine France se joint à cette initiative en relayant l’appel dans un article de 2 pages paru dans l’exemplaire d’avril (reçu hier dans ma boîte aux lettres) et en doublant la mise : pour chaque livre offert, la rédaction ajoute un abonnement d’un an au magazine de son choix (Linux-Pratique, GLMF, Misc).

Il y a 10 livres et autant d’abonnements en jeu, et tout juste 10 participants inscrits pour le moment. Les chances de gagner sont donc nettement supérieures au Loto, alors motivez-vous et rejoignez la communauté des contributeurs à Debian. N’hésitez pas à faire la promotion de cette opération, c’est aussi un moyen (indirect) de contribuer à Debian.

Note : les prochains numéros de Linux-Pratique et GLMF contiendront des articles détaillant un peu plus comment contribuer à Debian. Si vous voulez aider à leur rédaction (les délais sont assez courts : 1 semaine pour le premier et 2 semaines pour le second), n’hésitez pas à me contacter.

I’m glad that I can attend again this year. I’m sure it will be very productive. At least concerning dpkg it will be good to meet Guillem Jover IRL.

Aujourd’hui je vous présente screenshots.debian.net une initiative permettant de collecter des captures d’écran de tous les logiciels présents dans Debian. Tout un chacun peut réaliser des captures d’écran de ses logiciels favoris et les envoyer par un simple formulaire web. Synaptic sait déjà présenter les captures d’écran aux utilisateurs, vos contributions seront donc quasi-immédiatement employées (elles doivent tout de même être validées par les administrateurs du site avant publication effective).

Quelques recommandations sont données sur le site : il faut employer le format PNG, il faut lancer le logiciel en anglais (on peut utiliser LANG=C nom-du-logiciel dans un terminal pour cela), il ne faut capturer que l’application et pas le bureau en entier, et il vaut mieux faire une capture du logiciel en usage réel (avec un document ouvert, en cours de partie pour un jeu, …).

Difficile de faire plus simple pour contribuer, il suffit de vérifier si vos logiciels préférés ont des captures satisfaisantes en allant sur la page de consultation, puis de faire vos captures et les envoyer. Il est parfaitement possible d’avoir plusieurs captures par logiciel pour illustrer différents écrans/fonctionnalités, donc même si une capture est déjà présente, vérifiez si vous ne vous souhaitez pas compléter les captures actuelles.

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

Profitez de cette opportunité pour vous lancer et rejoindre le rang des contributeurs ! Mêlez-vous à la communauté (sur les listes de diffusion, sur IRC, sur les blogs Debian), et trouvez un domaine où vous pouvez vous épanouir en contribuant. Parlez avec d’autres contributeurs pour vous faire une idée de ce qu’ils font, et expérimentez vos idées d’améliorations pour Debian.

Vous ne savez pas comment contribuer à Debian ? Ce n’est pas grave, tous les contributeurs actuels seront heureux de vous guider pour que vous puissiez vous rendre utile, à commencer par Roland et moi-même. D’ailleurs la catégorie « Contribuer » de ce blog regorge d’exemples. Pour les plus motivés, j’encadre volontiers ceux qui veulent travailler sur un des projets qui me tiennent à cœur. Enfin, si vous ne trouvez pas votre bonheur (ou si vous avez des questions), vous pouvez toujours vous tourner vers la liste debian-devel-french@lists.debian.org pour expliquer ce que vous savez faire et on essaiera de vous guider vers une équipe qui saura mettre à profit vos talents.

Pour essayer de gagner un livre, il suffit donc de contribuer régulièrement à Debian d’ici à fin juin (et n’avoir pas contribué de manière régulière avant cette année). Quatre des livres seront attribués aux contributeurs les plus méritants (d’après le jugement de Roland et moi-même) et six autres seront répartis au hasard entre les contributeurs qui peuvent justifier de contributions réparties sur plus de 6 semaines (minimum 30 minutes de temps consacré à Debian sur la semaine).

Pour participer à ce jeu il faut se créer un compte sur le wiki Debian et noter sur la page http://wiki.debian.org/RaphaelHertzog/NewContributorGame) toutes les contributions effectuées. Chaque fois que possible merci d’inclure un lien afin que l’on puisse vérifier la véracité de votre contribution. Une fois inscrit sur cette page, il suffit de laisser un commentaire sur cet article de blog (merci de saisir correctement l’e-mail pour que je puisse vous recontacter) et votre inscription sera enregistrée.

Merci de faire circuler cette annonce afin de recruter le plus grand nombre de contributeurs possible !

Mise à jour du 7 mars: La procédure d’inscription a été modifiée à la demande de l’équipe de maintenance du wiki Debian.

Mise à jour du 27 mars: Les éditions Diamond s’associent à cette opération et offrent en complément du livre un abonnement d’un an (au choix entre Linux-Pratique, GNU/Linux Mag et Misc) à chaque gagnant de ce jeu. Merci à eux !

Cette nouvelle édition a été entièrement revue pour correspondre aux versions des logiciels présents dans Debian 5.0. On y trouve également quelques nouvelles sections dont une consacrée à OpenVPN et une autre aux partitions chiffrées. Comme d’habitude vous pouvez consulter le sommaire complet ainsi que des extraits sur le site du livre.

Disponible immédiatement en version électronique (PDF) sur Izibook, les libraires proposeront la version papier à partir du 19 mars (ou alors on peut le réserver dès maintenant sur Amazon et le recevoir dès que disponible). La version papier est accompagnée d’un DVD-Rom « multi-arch » i386/amd64/source de Debian 5.0.0. On peut donc installer sa machine au choix en mode 32 ou 64 bits, tout en disposant sur un seul disque de tous les paquets installés en standard (toutes tâches confondues).

PS: Découvrez aussi le jeu associé pour gagner un exemplaire du livre.

Au delà de cet événement, je constate avec plaisir que nombre de problèmes internes que j’ai pointé du doigt au cours des années (et des plate-formes de candidature au poste de leader) sont résolus ou en passe d’être résolus. Oui, Debian est de nouveau en état pour aller de l’avant sur de nombreux fronts. Cette année, pour la première fois depuis bien longtemps, les débats autour de l’élection ne tourneront plus forcément sur le problème des « core-teams » sclérosées.

Je suis particulièrement satisfait de l’évolution de l’équipe d’administration (DSA) avec 4 nouvelles recrues très actives et des nombreux projets en cours (déploiement de puppet, mise en place d’un cluster de serveurs mails pour centraliser le filtrage anti-spam). Je suis également heureux que Ryan Murray ait fini par reconnaître qu’il ne pouvait plus gérer buildd.debian.org tout seul. Une nouvelle équipe est en place et se structure progressivement. Fini le problèmes des alias « trous noirs » où personne ne répond, il y a toujours la nouvelle équipe vers qui se retourner en cas de problème. Fini aussi le problème du sbuild « maison » pas disponible en téléchargement, la nouvelle équipe emploie le paquet officiel. L’équipe ftpmaster a connu des changements positifs également (mais n’a toujours pas résolu durablement le problème de l’attente trop longue dans NEW) ainsi que celle des Debian Account Managers et celle de keyring-maint.

Au delà des équipes internes il y a le travail de maintenance des paquets, et de ce côté là aussi ca bouge pas mal. Le premier jour après la sortie de Lenny a connu pas moins de 237 uploads dans unstable et cela ne prend pas en compte de nombreuses mises à jour toujours en attente dans experimental (mais qui doivent être coordonnées pour ne pas bloquer trop largement la migration automatique vers Squeeze). D’ailleurs Squeeze contient déjà plus de 2500 mises à jour comparées à Lenny (mais la plupart sont des mises à jour qui ont été préparées dans unstable pendant la freeze de Lenny). Bref, Debian ca bouge et vous êtes les bienvenus pour avancer avec nous.

J’ai ressenti le besoin d’écrire ce billet après avoir mis à jour la page retraçant mon historique au sein de Debian. En regardant mes premières contributions (il y a plus de 10 ans!) et l’évolution des problématiques rencontrées dans cette période, on se rend compte que malgré les critiques et les problèmes, le chemin parcouru est énorme. Et il n’y a pas de raison que cela s’arrête.

D’ailleurs je ne manque pas de projets pour Debian, seulement de temps pour les réaliser. J’ai mis à jour la page sur laquelle je décris l’ensemble des projets que j’aimerai pouvoir mener ou faire avancer. Pour qu’ils avancent plus vite, il suffirait souvent que je puisse y consacrer une partie de mon temps de travail, alors si vous connaissez un moyen de financer ce temps, contactez-moi.

I have ranked misleading options (“Reaffirm social contract“ at least) lowest and below “Further discussion“ and sorted all the other options according to my preference, and ranked some of them equally when the choices answer different questions (where I can not prioritize any preferred outcome). I’m not yet sure if I put “Further discussion“ first or not.

There’s some hope that the vote will be cancelled and redone with separate ballots but I’ve lost trust in Manoj’s abilities to do his job properly. I’m sure he’s convinced that he’s doing the right thing but that doesn’t help at all, on the contrary. It also means we probably should fix the constitution to make it crystal-clear how the secretary should decide whether 3:1 ratio is needed for a given resolution or not. Not really the kind of thing I enjoy within Debian, but that’s the price to pay if we want to continue to work together. On this and much more I agree with Russ Alberry.

Update: Manoj resigned as secretary. I want to thank him for having taken this hard decision. And I sincerely hope he doesn’t resign from Debian completely as our strength is also in our diversity of opinions.