Centraliser la gestion des bugs dans un outil unique

Salut les agrumes,

On en a déjà plus ou moins parlé, mais je préfère refaire un sujet propre à partir d'une idée de Kje, qui me paraît de plus en plus intéressante au fur et à mesure que j'y réfléchis.

Il s'agirait de centraliser toute la gestion de bugs et améliorations dans un outil unique

Postulats de base :

• On a des bugs et suggestions à divers endroits : Github, le forum "bugs et suggestions", le forum "Dev zone", parfois d'autres biais (IRC, mails, etc).
• Le système de workflow de Github est vraiment trop simpliste pour notre utilisation¹

Problèmes que ça pose :

• Doublons en tous genres
• Tickets oubliés
• On est jamais certains du périmètre exact d'une release

Proposition de solution : dégainer l'arme thermonucléaire, ce qui reviendrait à :

• Avoir une instance d'un outil de gestion de bug tiers. Lequel ? À définir. Ci-après il est appelé "l'Outil".
• Développement minimal pour lier les comptes ZdS avec ceux de l'Outil (si j'ai un compte sur ZdS, j'en ai automatiquement un sur l'Outil). Connexions liées si c'est facile à faire. But : éviter que les gens doivent s'inscrire à un outil spécifique pour rapporter un bug.
• Pas d'import automatique de bugs sur l'Outil.
• Import manuel de l'important : ZEP, hotfix
• Arrêt du système d'issues Github
• Mise en lecture seule du forum de bugs et suggestions, interdiction d'utiliser le forum de dev pour poster des bugs et suggestions
• Lien bien visible sur le forum bugs et suggestions pour renvoyer vers l'Outil
• On incite la communauté à faire de la migration de tickets qui lui paraissent utiles
• Au bout de trois mois, tout ticket non migré est considéré comme sans importance (puisque personne ne l'a trouvé assez important pour le migrer) : le forum "bugs et suggestions" passe en privé, et on supprime le module de tickets de Gitub

Deux questions :

Personnellement je suis pour. On est encore au stade assez jeune a partir duquel on peut se permettre ce genre de chose. Surtout c'est indispensable. Actuellement il y a des bug, suggestions et zep un peu partout. Plus compliqué, il y a des tickets sur le GH qui datent "d'avant le workflow". En particulier il y a des tickets existant qui mériteraient une zep, qui n'existaient pas à cette époque.

Pour moi c'est la bonne solution a notre problème actuel : on passe de 3 lieux à un seul et on en profite pour faire le grand ménage. Le point le plus critique étant probablement le choix de l'outil.

J'aimerais tellement pouvoir vous proposer Projuice, … Si seulement je pouvais bosser dessus à plein temps… Mais ce ne serait tout de même pas réaliste, il vous faut une solution mûre.

J'espère vraiment que vous trouverez la solution parfaite alliant définition de workflows et multi-rapporteurs (visiteurs, développeurs) et surtout orientés "specs" ce qui est vraiment très complexe à trouver.

Bon courage, et bravo pour l'initiative, c'est maintenant qu'il faut se poser ce genre de questions.

Perso, je ne peux que plucentoyer (hyperbole du plussoiement) sur le fond.

Ceci dit, je tilte sur quelques points:

Je dirais aussi, développement minimal pour adapter l'interface de l'"Outil" au visuel de ZdS (au moins dans les couleurs)

Pas d'import automatique de bugs sur l'Outil.

Je ne comprends pas ce ça veut dire. On pourrait l'interpréter de plusieurs façon :

• on ne devrait pas pouvoir importer un nouveau bug du forum B&S vers l'Outil ?
• on ne devrait pas pouvoir importer la pile de bug existante du forum B&S vers l'Outil ?
• on ne devrait pas pouvoir importer un nouveau bug Github vers l'Outil ?
• on ne devrait pas pouvoir importer la pile de bug existante Github vers l'Outil ?
• tout en même temps ?
• …

Du coup, une précision serait pas de refus.

Arrêt du système d'issues Github

Je suis pour, et tout le monde sait pourquoi

J'aurai dit "Migration des tickets non résolu, puis suppression du forum B&S". Parce que :

• c'est moins frustrant pour ceux qui lisent
• ça n'aide pas à la centralisation
• on évite de développer une fonctionnalité "forum en lecture seule"

Pour moi, si le bug a été signalé, il devrait être migré, sauf si on a décidé qu'il n'est pas important.

Si on n'était pas encore dans le boxon actuel, j'aurai bien vu l'outil sur lequel Javier est train de plancher (Projuice), qui sur le papier correspond bien à ce qui nous serait utile.

Mais là, je vois surtout JIRA, mais quelque soit l'outil, il faudra clairement l'utiliser pendant un moment (~3 semaine pour moi) à coté pour valider son adoption et décider d'appliquer tout ça.

Pas d'import automatique de bugs sur l'Outil.

= Pas d'import automatique de l'existant ou de nouveaux bugs sous quelque forme que ce soit.

J'aurai dit "Migration des tickets non résolu, puis suppression du forum B&S".

C'est pour faire cette migration que je propose de mettre le forum en lecture seule (migration que je propose de faire faire en partie par la communauté en ce qui concerne tout ce qui n'est pas super important).

on évite de développer une fonctionnalité "forum en lecture seule"

Je pensais que ça existait déjà ?!

Pour moi, si le bug a été signalé, il devrait être migré, sauf si on a décidé qu'il n'est pas important.

Dans tout projet on a des tas de bugs et surtout de suggestions faites, mais qui finalement n'intéressent réellement personne. C'est normal et fait partie de la vie d'un projet. Une bonne pratique est de périodiquement dégager tous les tickets sans aucune activité depuis X temps, en considérant que finalement ça n'intéresse pas et donc qu'on a pas à garder le ticket actif.

Là c'est une variante brutale de la chose : on ne conserve même plus le ticket dans le nouvel outil.

C'est valable avec les bugs : un bug présent que personne ne s'est donné la peine de corriger en 6 mois, c'est que tout le monde s'en fiche et donc que c'est pas vraiment un bug.

Hmmm, pas trop pour. Un bug peu rester pendant 6 mois pour moi, sans être traité parce qu'il n'est pas prioritaire. Je trouve que supprimer une déclaration de bug (qui demande tout de même un effort) parce que personne ne s'en est occupé c'est pas cool. Après ce n'est que mon point de vue.

Quitte à rester chez nos amis de Jetbrains, pourquoi ne pas tester YouTrack.

Après avoir lu en diagonale: licence gratuite pour les projets Open Source, personnalisation du workflow pour le cycle de vie des bugs et gestion des utilisateurs via une API REST.

Il y a un outil de gestion de projet open source, complet et assez user-friendly (mais qui a évidemment un module pour la gestion des bugs) développé avec Django + AngularJS : Taiga.io

Je ne suis pas un expert Django, mais ça devrait être facilement jouable d'intégrer l'issue tracker au site et d'avoir un truc bien ficelé avec une connexion unique pour le site et l'outil voire d'étendre l'outil pour inclure une timeline pour les ZEPs, etc. Et comme c'est open source, on pourra aussi aider au développement de l'outil if needed. Seul hic : étant donné que c'est plus récent que des outils comme JIRA, c'est forcément moins connu (j'ai pas regardé la doc) et c'est en bêta mais ça me parait jouable.

Alors je trouve que c'es tune bonne idée car ça permetrait d'avoir un truc bien intégré à moindre coup. Ça a l'air bien fait et moderne. Le projet ce sépare en 2, l'un avec Django pour le back qui expose une api, et le front qui ne necessite rien coté serveur et utilise Angular pour le front. Du coup on pourrait très bien intégré la partie back dans notre code et faire un front qui utilise ces API, voir temporairement s'occuper uniquement de l'authentification et utiliser leur front. Le seul soucis est que le projet fonctionne uniquement sur Python 3.4+, ce qui n'est pas notre cas

Va falloir accélérer la migration à Python3 alors ! Plus que 2 libs qui font chier !

Lesquelles d'ailleurs ?

Oui enfin dans l'une des deux il y a pygit qui n'est pas la plus simple à virer. Mais en soit si on pouvait passer à libgit2 ce serait bien.

C'est laquelle la deuxième?

C'est ce qui a été acté (zds-meeting 2 si mes souvenirs sont bons) mais faut que quelqu'un prenne le courage de faire ça. Perso je connais encore trop mal cette partie du code pour avoir le courage et le temps de me consacrer à ça :/

Pour la seconde je ne me rappelle plus laquelle c'est.

Si je me fit à https://caniusepython3.com , dans le requirements.txt principal :

• django-munin

En non vérifié :

• GitPython
• python-zmarkdown (nos extensions seulement, assez rapide à faire, je crois qu'un membre l'a déjà fait)

dans le requierement de dev (requirements-dev.txt):

• faker

edit:

A noter cependant que :

• django-munin fait que quelques centaines de lignes, il serait ultra rapide à porter si il n'est pa déjà compatible (pas d'info)
• faker est un faux positif, il est en réalité compatible.

Bref il ne semble y avoir que GitPython de problématique

edit2:

Le développement de GitPythons semble avoir repris. Du coup le support de python 3 est prévu dans une release proche. On aura peut être bientot nos dépendances de migrés sans avoir rien a faire.

Comme quoi, rien ne sert de courir…

Indeed. De toute façon le plus morceaux est et restera notre base de code à nous. Même avec toutes les dépendances de migrés, il nous faudra un peu de travail et pas mal de tests pour être sûrs que ça fonctionne…

Il y a tant que ça à faire pour passer à python 3?

Pas forcément mais notre appli est très "string-centered". En fait en soit c'est assez facile de migrer mais ça peut générer plein de petits bugs qu'il va falloir trouver.

Ok, ca sent la v2.0 ça

Disons que ça justifie un passage en pré prod uniquement pour ça sans nouvelle fonctionnalités.