Je sais que Romain avait fait beaucoup pour TIGCC/*nix à une époque, mais ça fait longtemps qu'il n'est plus un développeur actif, or il se trouve qu'il utilisait abusivement son accès CVS:
* Il a importé le répertoire Debian alors que je lui ai dit explicitement de ne pas le faire:
> je suis en train de builder un paquet debian pour ktigcc; est-ce que je
> peux faire un commit du répertoire debian pour ktigcc ?
Bah, tu es censé faire des paquetages non-native de toute façon, alors
pourquoi pas rajouter le répertoire avec le diff.gz comme c'est fait
normalement? Le problème du répertoire Debian dans le repo, c'est qu'il a
tendance à ne pas être à jour quand je veux releaser. :-( (D'ailleurs je me
demande si je ne devrais pas resortir les .spec des sources de
libti*/tilp/tiemu et les gérer ailleurs, pour la même raison.)
et:
Personellement, je suis plutôt contre les trucs dans le CVS qui ne sont pas
distribués, aussi parce que j'utilise cvs2cl pour générer automatiquement les
changelogs de KTIGCC (donc aussi attention à tes commit messages si tu
committes qqch., ils se retrouveront tels quels dans le changelog).
(mails du 9 décembre 2007).
* Il l'a fait sans faire attention à ce qu'il committe, et du coup il a pollué mes sources upstream avec un patch Debian-local (un retour en arrière pour gérer le KDE antique (< 3.5.7) de Debian, réintroduisant un hack affreux et lent que le nouveau KDE m'a permis de virer, donc je n'ai aucune intention de faire ce retour en arrière dans mes sources officielles, il faut mettre à jour son KDE!) pas une fois, mais deux et il n'a même pas corrigé son erreur la deuxième fois.
Donc je n'ai pas eu d'autre choix que de le retirer. (Et cette discussion ne se ferait pas en public si ce n'était pas l'intéressé direct à nous tenir cette discussion ici...)
D'ailleurs, les dossiers Fedora vont disparaître aussi, je vais mettre un dépôt central avec tous les specfiles du dépôt Fedora sur CalcForge quelque part, ce sera plus pratique pour moi et ça évitera de polluer les sources avec des specfiles qui auront forcément au moins une release de retard (parce qu'un RPM, ça se met à jour juste après la release, pas avant).
