voici une discussion que j’ai lancé ailleurs sur l’utilisation actuelle de Subversion, je la repose ici pour que d’autre puissent réagir puisque j’y aborde justement le fait que peu de personnes interviennent sur la partie SPIP core+plugins-dist.
je pense qu’avec le fonctionnement actuel et la responsabilité qu’apportent des modification de LA branche de dev, on est limité côté créativité et qualité.
Avec en pratique un nombre limité de commiteurs actifs.
Créativité :
Selon moi, Subversion est un mécanisme qui fonctionne sur les compromis et la prudence : le changement du code doit être accepté par les autres et ne pas entrainer d’instabilité majeure pour que d’autres puissent bosser en parallèle sur d’autres fonctionnalités.
Actuellement nous n’avons qu’une seule branche de développement. La seule exception récente est la branche de développement qui a servi pour les développement d’ESJ qui n’allaient pas dans le sens de la stabilisation de la branche 3.0-dev
Mais c’est tout.
Et ce n’est pas suffisant à mon avis :
il faudrait pouvoir en créer de nouvelles plus facilement pour explorer de nouvelles pistes. Par exemple une branche de développement pourrait tester l’inclusion de #SAISIE dans le core, et on verrait ce qu’on pourrait faire avec => cela permettrait soit d’améliorer #SAISIE soit d’améliorer le mécanisme de squeletisation de l’interface privée et l’API qui va avec.
Beaucoup de projets qui utilisent Subversion (et qui ont beaucoup de contributeurs) fonctionnent avec une branche stable et de multiples branches de développement qui sont mergées ou purement abandonnées
On peut le faire sans problème et j’incite les futurs commiteurs à le faire - que ce soit pour le core ou les plugins
Qualité :
Développer dans une branche plusieurs fonctionnalités à la fois ne me semble pas être une très bonne pratique car cela ne va pas dans la diminution du nombre de bugs possibles.
A mon avis, la branche de développement principale ne devrait servir que pour des corrections de bugs et des trous de sécu (-> sorties de releases fréquentes)
Les versions mineures qui correspondent à l’ajout d’un machin devraient faire l’objet d’une branche. Mais je suis convaincu que ce n’est possible que si on est nombreux à intervenir (avec des compétences identiques) dans le code, et actuellement ce n’est pas le cas.
Au passage c’est mon avis perso, mais je n’interviens pas du tout encore dans le code (si je le fais, je ferai ma branche perso ), donc ces remarques ne visent absolument pas à critiquer le travail actuel car d’autres personnes ont d’autres habitudes de travail et sont très efficaces dans la façon de coder qu’ils utilisent
Et puis moins souvent on change ses habitudes de travail, moins c’est pénible de créer un code de haute qualité.
Côté nombre :
Certains ont parlé d’auto censure, je pense que c’est le cas (et j’ai repris quelques éléments explicatifs au dessus).
Être peu nombreux à intervenir ne me gène pas : plus les équipes sont nombreuses plus elles doivent s’organiser. On n’écrit pas un logiciel comme on alimente les pages d’un Wiki, c’est plutôt l’inverse. Et puis lire le code source de quelqu’un d’autre peut devenir très pénible s’il n’est pas commenté et/ou ne suit pas une grammaire ou une logique qu’on a l’habitude d’utiliser.
Je serais favorable à ce qu’on définisse un groupe restreint de personnes qui commitent dans la branche de dev principale, les autres commitant dans des branches annexes ou proposant des patchs que ledit groupe valide avant de l’introduire dans le code source du Core.
Et pour détendre atmosphère par une petite touche d’humour, surtout n’utilisez pas git, certaines célébrités l’ont bien compris : http://www.youtube.com/watch?v=CDeG4S-mJts
C’est une spéciale dédicace pour Camille
Au passage c'est mon avis perso, mais je n'interviens pas du tout encore
dans le code (si je le fais, je ferai ma branche perso ), donc ces
remarques ne visent absolument pas à critiquer le travail actuel car
d'autres personnes ont d'autres habitudes de travail et sont très
efficaces dans la façon de coder qu'ils utilisent
[...]
J'interviens juste comme Éric sur la branche de plugins core que tu as faite récemment, avec 2 points :
- Il me semble que passer les plugins du core en branche/trunk serait plus simple pour avoir une gestion sympa des branches par plugin (voire même de les migrer sur _plugins_ pourquoi pas. Mais Cédric (il me semble) faisait très justement remarquer que pour ça, il faut AVANT adapter les scripts qui génèrent je sais plus quoi : certainement les zips de SPIP et peut être certains externals. Et surtout pas avoir à le faire ensuite en urgence.
Il faudrait juste si c'est fait (je n'ai rien contre) que ça ne mette pas trop le bazar dans le suivi des versions de SPIP (je ne sais pas trop ce que ces changement impliquent dans les branches de SPIP, les zips générés)
- Le second point concerne le fait de brancher. Ça me semble une bonne chose comme tu le soulignes pour tester une fonctionnalité. Mais le merge devient très casse pied avec SVN dès lors que le trunk et la branche divergent (il n'y a pas de commande rebase pour que la branche puisse suivre en même temps le trunk, ce qui est, même si c'est un point technique, une fonctionnalité de GIT bien plus pratique que de merger tous les commits). C'est un fait.
Ce n'est certainement pas cela dit la raison pour laquelle on a si peu de branches par fonctionnalité : plus vraisemblablement c'est qu'on a pas - encore - l'habitude de faire comme cela, mais SVN n'y incite pas non plus. Il faut aussi voir que l'usage de branche sur la zone est très récent au bout du compte, à la place des sabots que l'on plaçait sur le zippeur, et que déjà la gestion est plus lourde pour les reports.
Voilà, c'est juste un petit état de mes pensées du moment
Au passage c’est mon avis perso, mais je n’interviens pas du tout encore
dans le code (si je le fais, je ferai ma branche perso ), donc ces
remarques ne visent absolument pas à critiquer le travail actuel car
d’autres personnes ont d’autres habitudes de travail et sont très
efficaces dans la façon de coder qu’ils utilisent
[…]
J’interviens juste comme Éric sur la branche de plugins core que tu as faite récemment, avec 2 points :
Il me semble que passer les plugins du core en branche/trunk serait plus simple pour avoir une gestion sympa des branches par plugin (voire même de les migrer sur plugins pourquoi pas. Mais Cédric (il me semble) faisait très justement remarquer que pour ça, il faut AVANT adapter les scripts qui génèrent je sais plus quoi : certainement les zips de SPIP et peut être certains externals. Et surtout pas avoir à le faire ensuite en urgence.
Il faudrait juste si c’est fait (je n’ai rien contre) que ça ne mette pas trop le bazar dans le suivi des versions de SPIP (je ne sais pas trop ce que ces changement impliquent dans les branches de SPIP, les zips générés)
Je suis tout a fait d’accord.
D’où mon bidouillage (création d’une branche fourre-tout en dehors du plugin) pour que je garde un lien pas trop distant avec le plugin initial.
Ce sera beaucoup plus propre quand ce plugin sera (j’en suis convaincu) sous une forme standard branches/trunk/tags - et que les outils qui décident de quelle version des plugins à utiliser avec SPIP soient au point.
Le second point concerne le fait de brancher. Ça me semble une bonne chose comme tu le soulignes pour tester une fonctionnalité. Mais le merge devient très casse pied avec SVN dès lors que le trunk et la branche divergent (il n’y a pas de commande rebase pour que la branche puisse suivre en même temps le trunk, ce qui est, même si c’est un point technique, une fonctionnalité de GIT bien plus pratique que de merger tous les commits). C’est un fait.
Ce n’est certainement pas cela dit la raison pour laquelle on a si peu de branches par fonctionnalité : plus vraisemblablement c’est qu’on a pas - encore - l’habitude de faire comme cela, mais SVN n’y incite pas non plus. Il faut aussi voir que l’usage de branche sur la zone est très récent au bout du compte, à la place des sabots que l’on plaçait sur le zippeur, et que déjà la gestion est plus lourde pour les reports.
Deux options on développe dans son coin à partir d’une version donnée :
soit on ne se synchronise jamais, et une fois les développements aboutis, il faut faire le merge ma-nu-el-le-ment. Et c’est TRES lourd
soit on se synchronise régulièrement en faisant des merges du dépôt d’origine vers notre branche. Alors il devient beaucoup plus simple de reporter à la fin le modifications effectuées dans notre branche.
La seconde méthode est bien sûr préférable, mais peut-être pas toujours applicable.
), donc ces remarques ne visent absolument pas à critiquer le travail actuel car d’autres personnes ont d’autres habitudes de travail et sont très efficaces dans la façon de coder qu’ils utilisent
), donc ces