Yop,
(je démarre un fil parce que c'est pas une réponse à un message en
particulier, et aussi je voudrais sortir du mode "match" avec 2 camps)
En lisant le débat qui échaude en ce moment la liste, je vois plusieurs
choses se passer, qui ne sont en fait pas très graves et qui sont même
très courantes :
- un dev a l'idée d'une solution à un problème existant, il veut la
tester
- un autre dev (ou plusieurs) pense que ce n'est pas une bonne approche
- la partie compliquée : le test est pris comme un truc imposé dans le
code, non discuté, etc.
Mais en fait : avoir une idée dans son coin, être persuadé qu'elle est
bonne, et vouloir la voir en œuvre pour se rendre compte, ce n'est pas
si grave et on devrait pouvoir le faire. Ce n'est pas contraire au
développement collaboratif, même. Tant que c'est vu, dit, et pris comme
juste un test.
Et d'un autre côté : être sûr d'avance que ça ne marchera pas, ce n'est
pas plus fiable qu'être sûr d'avance que si. D'ailleurs, des fois tout
le monde pense que ça va marcher, et après quelques semaines de test on
se rend compte qu'en fait non.
Par contre, que ce qui est une idée arrive direct dans la branche
principale, fût-elle de "dev", c'est déjà trop définitif, car il n'y en
a qu'une, et c'est en réalité la gestation de la future release. Si en
plus de ça le "test" n'est pas présenté comme tel mais comme solution
vouée à rester, c'est la panique : cette fois ça va trop vite.
C'est là que je me dis que c'est peut-être SVN qui pose des
limitations. Du coup, ben forcément je vais reparler de git, parce que
c'est la seule autre alternative que je connaisse. Git permet de créer
des branches en un quart de seconde, de les fusionner aussi simplement,
de les supprimer, etc. à volonté. Une légende dit que dans SVN aussi,
mais tout le monde sait que c'est faux.
Je veux tester une idée, je crée une branche. On finit par se dire que
c'est nul, on efface la branche. Si inversement elle finit par faire
consensus, on fusionne. En attendant, ça se développe tranquillement,
commit par commit. Et surtout : avec git je peux faire mes commits en
*local* donc sans susciter des froncements de sourcil. À la fin de
l'après-midi je me rends compte que c'est pas si chouette, j'efface, ni
vu ni connu. Si inversement je me rends compte que je voudrais montrer
aux gens, je push ma *branche* de test d'un coup avec tous ses commits,
et j'attends les retours, mais au moins ces retours se feront sans
stress parce que tout le monde voit que c'est dans une branche de test
(la branche "master" restant inchangée), avec toute l'humilité et
l'incertitude que ça comporte.
Mine de rien, c'est exactement l'utilisation qui est faite de certains
plugins (par exemple pour le bandeau) : une fonctionnalité est testée
parce que tout le monde a conscience qu'il serait trop abstrait d'en
parler à l'avance dans le vide et que le voir en vrai serait plus
parlant, et quand/si ça semble être une amélioration, ça passe dans le
core. Sauf que créer un plugin, dans la démarche c'est quand même pas
aussi léger que créer une branche de test pour proposer une
fonctionnalité.
Du coup je pose vraiment la question de l'outil. Là je dis git parce
que je connais pas Mercurial, Darcs et consorts, mais de façon
générale je crois vraiment que des commits locaux + des branches faciles
feraient un bien fou au processus de développement de SPIP.
Z'en dites ?
À mon avis on en est pas encore du tout là ; dans la suite