@cgeek nous avais habitué à des cycles de releases long d’environ 6 mois ou chaque nouvelle version 1.x comportais beaucoup de features.
Cela fait un moment que je me renseigne sur cette question, que j’expérimente différent rythmes (en 17 mois dans une entreprise j’ai travaillé sur 4 projets différents aux rythmes et méthodes assez différentes) et je suis désormais convaincus qu’adopter un cycle de releases court me conviendrai mieux, et serait également bénéfique pour la communauté.
Je souhaiterai donc sortir une nouvelle version 1.x de Duniter tout les 1 à 2 mois environ quitte a monter à 1.50 ou au delà, j’y vois plusieurs avantages :
Permet de jouer fréquemment les processus de livraison en prod, et donc d’éviter qu’il ne se « rouillent » avec le temps. Quand ça fait plus de 6 mois qu’on a pas livré en prod, on a parfois des mauvaises surprises au moment de livrer.
Permet de livrer moins de features en prod, or qui dit moins de features dit généralement moins de bug, donc moins de hotfix, donc un réseau de prod plus stable.
Avec un cycle court, il est plus facile de reporter une feature à la release d’après, ce qui évite de retarder une release a cause d’une feature qui traîne, ou au contraire de bacler une feature parce que l’on trouve trop coûteux de la reportée et que la nouvelle version doit sortir incessamment sous peu car elle embarque d’autres changements urgents.
Permet de mobiliser plus régulièrement les bêta-testeurs, pour ceux qui ne sont pas très proche du code (qui ne sont pas alpha-testeurs), il ne sont pas ou très peu sollicité entre 2 versions, si le temps entre 2 versions est long ils peuvent se lasser et passer a autre chose, avoir l’impression que le projet est moins vivant, finir par partir où lorsqu’une nouvelle version sort enfin ils ont oubliés comment on teste et c’est plus « coûteux » pour eux de se replonger dedans.
Le projets paraît plus vivant aux yeux des autres contributeurs ainsi que des utilisateurs, ce qui est plus motivant pour s’impliquer comme pour utiliser.
Dans la pratique ce n’est pas plus de boulot, c’est juste des versions plus petites, avec moins de changements.
Je prévois d’appliquer cela dès à présent et de sortir une version 1.8 très prochainement.
Je souhaiterai juste finir l’oxydation de la PoW avant, ce que j’ai déjà quasiment terminé, c’est une affaire de jours je pense.
DUBPv13 attendra donc Duniter 1.9, qui arrivera cependant très vite derrière (peut-être seulement 1 mois après).
Du coup je suis en train de passer au peigne fin une partie des 230 tickets ouverts… j’en clôture certains, sur d’autre je les passe en « demande de plus d’informations auprès de l’auteur », sur d’autre encore je fais une pré-analyse de 10/15 min max dans le code pour voir si c’est facile a corriger, si le bug est toujours là, etc.
Beaucoup de tickets sont probablement obsolètes, il y a un tri a faire, c’est long donc je ne ferai pas tout d’un coup, je dépilerai au fur et à mesure, mais du coup ne soyez pas surpris vous allez peut être recevoir un mail de gitlab parce que je vous pose une question sur un ticket que vous avez ouvert il y a des années
En revanche, ma priorité étant l’oxydation de Duniter, si je vois qu’un bug est causé par une brique de Duniter que je compte bientôt oxyder et que ce bug n’est pas bloquant, je ne le corrigerai pas.
Tu as peut-être raison, disons que je vais expérimenter et que je verrai bien, si c’est trop galère ou que ça ne me convient plus je rallongerai les cycles
Tout les tickets qui était jalonné 1.7 ou 1.8 ont été reportés ou clôturés ou traités.
Pour livrer la 1.8 il me reste encore à :
Mettre a jours la documentation de Duniter dans le dossier doc : c’est ce que j’ai commencé a faire cet après-midi, je compte continuer (et probablement finir) demain
Rédiger le changelog
Finaliser l’oxydation de la pow : en fait c’est fini, je rédigerai un post détaillé dans le fils duniteroxyde demain (là il est tard).
Il est dit dans le texte d’ajouter son pseudo utilisateur en préfixe de branche, mais pas dans les exemples.
Je suis allez voir les branches en cours pour constater qu’aucune n’avait de pseudo. Donc j’ai suivi la pratique et les exemples sans pseudo plutôt que le texte.
Je suis justement en train de mettre à jours ce fichier pour l’adapter a la pratique, je viens tout juste de reprendre la gestion du dépôt, il me faut un peu de temps pour expérimenter et voir quelles pratiques vont finalement se dessiner, patience
Je suis en train d’utiliser la fonctionnalité “move issue” de gitlab pour déplacer les tickets relatif à duniter-ui dans le dépôt de duniter-ui directement. C’est une fonctionnalité bien pratique et très propre, un seul inconvénient: elle notifie par mails les mainteneurs du dépôt de destination.
Donc @cgeek et @Moul vous allez vous faire spammer de 20 mails pour les 20 tickets que je suis en train de déplacer, dsl pour ça
mais ça me semble beaucoup plus clair comme ça, je préfère que chaque dépôt porte les tickets relatif a sa codebase, je déplacerai au bon endroit les nouveaux tickets ouvert dans le dépôt Duniter.
As-tu un article qui parle de cette fonctionnalité ? C’est intéressant. J’ai découvert qu’il est possible de sélectionner plusieurs tickets et de faire de l’édition en masse. Par exemple, sur ce label “move to duniter-ui”, en cliquant sur le bouton “Édition”. Mais, je ne vois pas de possibilité de déplacer en masse. Juste déplacer au un part un, semble possible. As-tu réussi à les déplacer ? À ce que j’ai vu ça n’est pas encore fait.
Je les déplaces a la main un par un, il n’y a que 19 tickets concernés, j’en ai déjà déplacé la moitié puis je suis parti sur autre chose entre temps.
S’il y avait eu des centaines de ticket a déplacer j’aurais chercher un moyen de le faire en masse, mais moins de 20 tickets à traiter, le temps de chercher comment le faire en masse ils seront déjà déplacés.
