Avant un éventuel grand passage à Composer ne faudrait-il pas libérer des ressources, système notamment, mais mentales aussi ?
Avoir 2 repos SVN et Git à gérer, ça fait des infrastructures doublées et une synchronisation complexe et fragile (c'est une impression) et incomplète depuis plusieurs années.
Alors pourquoi pas passer à "tout git" ?
J'imagine :
git est certes un peu plus complexe que svn,
mais ça ne pénaliserait que les devs, or les devs, c'est leur job de se tenir à jour.
git a un modèle de dev éparpillé et individualiste,
il n'y a pas un repo fédérateur communautaire garanti mais une multitude de repo.
Peut être ya tout de même une solution qui au final en vaudrait la peine.
Et puis à l'heure d'une remise en cause des fondamentaux de SPIP aussi importante que le passage à Composer, ya peut être certains anciens arguments qui ne tiennent plus.
> Le fait que SPIPRemix fait cohabiter des fichiers composer.json et paquet.xml me semble prouver que le compromis est déjà trouvé.
Avant un éventuel grand passage à Composer ne faudrait-il pas libérer des ressources, système notamment, mais mentales aussi ?
Avoir 2 repos SVN et Git à gérer, ça fait des infrastructures doublées et une synchronisation complexe et fragile (c'est une impression) et incomplète depuis plusieurs années.
Alors pourquoi pas passer à "tout git" ?
J'imagine :
git est certes un peu plus complexe que svn,
mais ça ne pénaliserait que les devs, or les devs, c'est leur job de se tenir à jour.
oui sur ce point (autant sur composer je suis reservé à du QUE composer, autant sur git, non)
mais un passerelle svn-git en lecture seul pour ne pas casser les gens qui maj via svn up?
git a un modèle de dev éparpillé et individualiste,
non, ce n'est pas lié à git. C'est le modèle github. Mais on peut très bien avoir du git centralisé et collaboratif.
Je le suis très imparfaitement informé :
des discussions entre core devs m'ont donné une idée du truc,
mais ce sont des bribes de discussion saisies au passage
et étalées sur plusieurs années,
donc la vision que j'en tire n'est ni complète ni claire
et à ma connaissance il n'y a pas de doc à jour ou de tableau de bord
pour compléter et éclaircir cette vision.
Je sais qu'historiquement tout est sur svn.
Je sais qu'il y a un dépot git pour le core sur github
(car je me souviens y avoir fait quelques PR)
et il y a aussi un dépot pour une sélection de plugins
(je me souviens avoir vu un gitlab autohébergé à part).
Il y a une synchro qui marche assez bien en général de svn vers git
mais pas trop dans l'autre, ou par moments seulement.
Et je sais que depuis plusieurs années tu t'occupes de tout ça
mettre en place, améliorer, réparer etc.
Au passage merci, et bravo pour tout ce travail
Mais du coup tu es bien mieux informé,
alors peux tu compléter et corriger si j'ai dit une connerie ?
Là où je ne suis pas du tout informé
C'est que je ne sais pas du tout pourquoi on garde cette double architecture.
J'ai évoqué des pistes dans mon précédent mail, mais ça ne semble pas tenir.
Et je sais pas pourquoi c'est "mettre les pieds dans le plat" que d'en parler.
En tout cas cette expression indique que c'est un sujet compliqué,
et ça confirme qu'il y aurait réellement matière à alléger de ce côté
et à gagner en énergie disponible pour tous les autres travaux spipiens.
