Mieux gérer les choses à faire avant la prochaine release
Nous avons actuellement un test sur le cpp qui ne passe pas, 88c6e924 lié à #2003.
Ce n'est pas sain d'avoir des tests qui ne passent pas : cela rend difficile le développement d'autres features, et on ne bénéficie pas beaucoup de l'intégration continue. Par définition, notre branche principale doit toujours passer les tests. Et puis une décision à un moment "on doit absolument fixer cela" peut évoluer quelques temps plus tard (je ne parle pas nécessairement de #2003).
Mais c'est fantastique d'identifier des bugs et de faire des tests qui ne vont pas marcher dans un premier temps. Pour les tests should-get, il y a la syntaxe f1 qui permet d'ignorer un tel test, et des choses similaires pour les autres types de tests. Cependant, @mikael-s faisait justement remarquer, il y a quelque temps, qu'on peut oublier de tels tests, d'où 88c6e924 qui casse le build mais qui permet de s'en souvenir.
Proposition de meilleur workflow pour cela, grâce à gitlab : un bug "that should be fixed for the next release" conduit à un test ignoré avec une issue tagguée d'un milestone de la release. Voir par exemple #2157 (closed) et la release %Algo 2017.03. Et le build de dev doit toujours passer.
Pour l'instant cela s'appliquerait au cpp, où l'on fait des releases, mais on pourrait aussi utiliser des milestones pour des déploiements client / serveur, à moins qu'on préfère rester en intégration continue.