J’hé­ber­geais jusqu’à ré­cem­ment l’en­semble de mes pro­jets sur des ins­tances de Trac sur un ser­veur dé­dié. Tou­te­fois, de­puis quelques mois, le spam dans les ti­ckets de­ve­nait en­va­hissant.

Le spam & Trac#

Les mécanismes pour combattre le spam#

Par dé­faut, Trac ne pro­pose pas de mé­ca­nisme pour lut­ter contre le spam. Il existe ce­pen­dant des plu­gins qui per­mettent de conju­guer plu­sieurs mé­ca­nismes pour ar­rê­ter le spam.

Un de ces mé­ca­nismes est Akis­met, un web ser­vice qui dé­cide si le contenu sou­mis est un spam ou non. Ce ser­vice per­met de cap­tu­rer la ma­jo­rité du spam. En com­plé­ment, il est pos­sible de mettre en œuvre un filtre bayé­sien. Ce der­nier né­ces­site un ap­pren­tis­sage pour être ef­fi­cace, ce qui peut s’avé­rer dif­fi­cile quand la ma­jeure par­tie du contenu est du spam. Ce sont ces deux mé­ca­nismes que j’uti­li­sais sur mes ins­tances de Trac.

Une autre ap­proche est d’im­po­ser la créa­tion d’un compte pour pos­ter des ti­ckets. C’est une ap­proche que je ne vou­lais pas uti­li­ser. En ef­fet, il est as­sez pé­nible de de­voir s’ins­crire sur un site rien que pour pou­voir en­voyer un rap­port de bug. Une so­lu­tion al­ter­na­tive était de créer un compte gé­né­rique avec des ins­truc­tions quelque part sur la page pour in­di­quer aux per­sonnes sus­cep­tibles de créer un ti­cket qu’il était pos­sible d’uti­li­ser ce compte.

Retirer le spam#

Mal­gré les di­verses pro­tec­tions, deux ou trois spams par­ve­naient à pas­ser par jour. Je les voyais pas­ser dans mon flux RSS, par­fois dans ma boîte email s’ils n’étaient pas consi­dé­rés comme des spams.

Une fois le spam re­péré, il y a deux étapes dis­tinctes à ef­fectuer :

• in­di­quer au filtre bayé­sien que le ti­cket en ques­tion est un spam en se ren­dant dans le pa­nel d’ad­mi­nis­tra­tion de l’in­ter­face web,
• re­ti­rer le ti­cket de la base de don­nées à l’aide de quelques com­mandes SQLite di­rec­te­ment sur le ser­veur hé­ber­geant l’ins­tance Trac.

En ef­fet, Trac ne pro­pose pas la pos­si­bi­lité pour un ad­mi­nis­tra­teur de sup­pri­mer un ti­cket. Il existe bien sûr des plu­gins, mais il faut les ins­tal­ler, les main­te­nir, etc.

Bref, c’était pénible.

GitHub#

GitHub est une pla­te­forme d’hé­ber­ge­ment de code très pri­sée et cen­trée au­tour de Git. Mal­gré le fait qu’il s’agisse d’une plate-forme fer­mée, beau­coup de pro­jets libres ont été sé­duits par les fonc­tion­na­li­tés et les per­for­mances de celle-ci.

Tout le monde est sur GitHub. Voilà l’oc­ca­sion d’y pas­ser aussi.

Fonctionnalités#

Avant tout, GitHub est un hé­ber­ge­ment de dé­pôts Git. On y pousse une co­pie de ses dé­pôts Git. Il pro­pose de plus une in­ter­face web as­sez sympa et ré­ac­tive pour na­vi­guer de­dans. Je garde tou­te­fois mon ins­tance de cgit.

En­suite, GitHub s’est rendu très po­pu­laire en pous­sant au maxi­mum les gens à for­ker les pro­jets. Ainsi, en un seul clic, il est pos­sible de clo­ner un pro­jet qui nous pa­raît sym­pa­thique et le voilà dans notre liste de projets.

GitHub pro­pose éga­le­ment un pe­tit wiki ac­cep­tant di­verses syn­taxes. Ce wiki est éga­le­ment ac­ces­sible via Git.

En­fin, GitHub pro­pose une ges­tion des ti­ckets très mi­ni­ma­liste. On ouvre un ti­cket, on com­mente un peu, on peut ajou­ter des tags et on peut fer­mer le ti­cket. Rien de plus. C’est par­fois un peu lé­ger, mais cela per­met de s’en sor­tir pour des pro­jets as­sez simples.

Ce n’est pas tout. Si on veut pro­po­ser un patch, in­utile d’ou­vrir un ti­cket. D’ailleurs, on ne peut pas at­ta­cher de fi­chiers quand on ouvre un ti­cket. Ce qu’il faut faire, c’est for­ker, créer une branche, mettre son patch et ré­cla­mer une « pull re­quest » sur la branche en ques­tion. Cela crée au­to­ma­ti­que­ment un ti­cket avec les ré­fé­rences de la branche. L’au­teur peut in­té­grer le patch avec un simple clic et le bug se ferme à ce mo­ment là. Très pra­tique. Faut juste jon­gler avec les branches.

Ni­veau so­cial, on peut com­men­ter les com­mits, les ti­ckets, les pro­jets et s’abon­ner à tout un tas d’évè­ne­ments. Il n’est pas né­ces­saire de se col­ti­ner l’in­ter­face web toute la jour­née puisqu’il est pos­sible d’in­ter­agir par mail avec le sys­tème de ti­ckets en ré­pon­dant sim­ple­ment aux mes­sages que l’on reçoit.

No­tons tou­te­fois qu’il faut avoir un compte pour ou­vrir un ti­cket. Ce­pen­dant, cela de­vient as­sez cou­rant de nos jours et cela ser­vira pour tout un tas d’autres projets.

Bref, bien que pro­prié­taire, GitHub pro­pose des fonc­tion­na­li­tés très in­té­res­santes et bien réa­li­sées. On voit de plus en plus de pro­jets qui migrent de Google Code vers GitHub bien que ce der­nier soit beau­coup plus basique.

Migration#

J’ai cher­ché des ou­tils per­met­tant de mi­grer au­to­ma­ti­que­ment les bugs en­re­gis­trés au ni­veau de Trac dans le pro­jet cor­res­pon­dant sur GitHub. Il existe no­tamment SD.

Au fi­nal, j’ai tout fait à la main en re­co­piant les quelques pages des wi­kis et les ti­ckets quand ceux-ci étaient en­core ou­verts. L’API de GitHub est certes bien do­cu­men­tée (il existe des ou­tils pour l’uti­li­ser) mais elle est on ne peut plus mi­ni­ma­liste. On ne peut pas choi­sir le nu­méro du ti­cket qu’on ouvre, ni sa date.

J’ai éga­le­ment ré­écrit les fi­chiers README des dif­fé­rents pro­jets pour ex­ploi­ter la syn­taxe mark­down et évi­ter l’uti­li­sa­tion du wiki si possible.

En­fin, j’ai mis en place une re­di­rec­tion des ins­tances Trac vers GitHub au ni­veau du nginx.

Au fi­nal, même si cela n’était pas beau­coup de tra­vail, plus be­soin de main­te­nir les ins­tances Trac. Et, a priori, pas de spam sur GitHub.