[spip-dev] On en est où avec git ?

Yop,

ça discutait ce soir sur IRC, et je crois qu'on est plusieurs à être un peu dans le flou.

Le code de spip (core + plugins) serait donc maintenant sur git.spip.net, avec une passerelle unidirectionnelle vers svn, mais il semblerait que ce ne soit pas si unidirectionnel que ça.
De plus, il a été acté (il me semble) qu'on basculait sur github comme dépot principal (pour le core, je répète).

James a retravaillé sur des scripts qui transforment core + plugins sur SVN vers des dépots semver git, mais je ne sais pas trop où ça en est, s'il manque des choses à faire.

Probablement les trads restent un problème à régler.

Est ce qu'on pourrait faire un point là dessus ?

Haut les cœurs,
la bise,

Bonjour

Je vais répondre sur ce que je peux.

Le code de spip (core + plugins) serait donc maintenant sur
git.spip.net, avec une passerelle unidirectionnelle vers svn,

Uniquement core comme discuté en début d'année.

Mail de Cerdic, le mar. 18 déc. 2018 11:02

Je reprends donc la synthèse des derniers échanges et je résume,
pour voir si j’ai (on a) bien tout compris :
* la forge git.spip.net basée sur gitea tourne ici
spip / spip · GitLab
* chacun doit se créer un compte dessus - en fait il y a des chances
que vous ayez déjà un compte avec votre email - j’ai testé, ça
marche, et j’ai même relié avec mon compte github, donc je peux me
connecter avec github, ce qui m’épargne de gérer un mot de passe
de plus !
* du coup on peut ajouter notre clé SSH dans notre compte
* et git clone le core sans problème.
[...]
En vertu de quoi, je propose donc, pour stopper l’immobilisme (sic)
qu’à partir du 1er janvier 2019 le dépôt de référence de SPIP
(uniquement le core donc, pour commencer, et pas les plugins du
core) soit git.spip.net, qu’on coupe le commit sur le SVN du core qui
ne servira plus qu’à checkout, et on essaye pas de maintenir une
synchro svn->git trop hasardeuse

Mail de Km, le 4 janv. 2019 13:56

Salut

Le premier [commit] est passé, je viens donc de couper l'accès svn pour le core.
Seuls les bots (git, salvatore et amemo) ont encore le droit de passer
par svn. Leur script n'étant pas à ma connaissance à jour. Pour les
humains plus de passe droit :slight_smile:
A terme seul git aura droit d'écriture, pour maintenir la copie à jour.

Je vous invite à vérifier que votre compte est bien présent sur
git.spip.net avec les droits de la team.

Mail de Cerdic, le lun. 7 janv. 11:26

Hello,

bonne année sous vos palmiers ! (au moins ça rime)

Merci Camille pour le switch du core, donc.
[...]

mais il
semblerait que ce ne soit pas si unidirectionnel que ça.

Le contrôle n'est pas strict, c'est à dire que si une personne
souhaite quand meme passer par svn il peut forcer.
Ce point peut etre modifié pour forcer complément le blocage.

De plus, il a été acté (il me semble) qu'on basculait sur github comme
dépot principal (pour le core, je répète).

Je te laisse reprendre les courriels de l'époque, à aucun moment cela
n'a été abordé.
Pour le moment github est un mirroir de git.spip.net

James a retravaillé sur des scripts qui transforment core + plugins sur
SVN vers des dépots semver git, mais je ne sais pas trop où ça en est,
s'il manque des choses à faire.

Pour le core, il ne me semble qu'il n'y a rien de plus à faire que ce
qui est en ligne.
Pour les dist, actuellement est proposé une copie à l'identique de svn
sur git.spip.net
Ces copies posent un problème car les tags ne respectent pas un bon
versionnage (tag sur les version spip et non du plugin)
De mon coté j'ai un script qui corrige ce point.

Complément j'ai un script qui reprend les retours concernant la
conversion svn>git.
Il manquait les tags semver des plugins. J'ai un script qui fonctionne
sur les dépots git qu'on peut tester quand on aura un retour.

Mail de km, le 27 mai 2019

J'ai un script qui permet de poser correctement les tags sur les
plugins dist.
Par facilité de code cela part du dépôt git. Le script parcourt les
commits de master du plus ancien au plus récent. Il considère
d'abord paquet.xml et sinon plugin.xml
Cela tague sous la forme attendu par composer : vX.Y.Z

Le commit le plus ancien est pris en compte pour une version
donnée.

Mail de Nicod, le le 27 mai 2019

Salut,

James travaille là dessus aussi mais je ne suis pas au courant des
derniers développements.
Peut être pourra il nous éclairer ?

cf https://www.mail-archive.com/spip-dev@rezo.net/msg67029.html

Pas de retour depuis.

Dans tous les cas restera un problème dans le nommage des
organisations quelque soit la forge retenue.

Probablement les trads restent un problème à régler.

Si tu penses à tradlang en l'état cela peut fonctionner tant par svn
que par git.

En espérant pu éclairer certains points

Km

Je vais répondre sur ce que je peux.

Merci pour ta réponse.

De plus, il a été acté (il me semble) qu'on basculait sur github comme
dépot principal (pour le core, je répète).

Je te laisse reprendre les courriels de l'époque, à aucun moment cela
n'a été abordé.
Pour le moment github est un mirroir de git.spip.net

Je n'ai pas ré-épluché les courriels mais il me semble qu'il y a bien un consensus parmi les devs core pour basculer core et plugins dist sur Github, choix fait en rapport avec Composer et pour en simplifier le fonctionnement et l'adoption.

Pour les dist, actuellement est proposé une copie à l'identique de svn
sur git.spip.net
Ces copies posent un problème car les tags ne respectent pas un bon
versionnage (tag sur les version spip et non du plugin)
De mon coté j'ai un script qui corrige ce point.

Complément j'ai un script qui reprend les retours concernant la
conversion svn>git.
Il manquait les tags semver des plugins. J'ai un script qui fonctionne
sur les dépots git qu'on peut tester quand on aura un retour.

James a travaillé là dessus depuis un moment, conversion SVN -> Git et SEMVER pour le core et les plugins (cf la maquette spipremix).
Je ne sais pas ce qu'il y manque, ni s'il y manque quelque chose.

Quid de la suite / de la fin de la migration ?

Hop,

Je te laisse reprendre les courriels de l'époque, à aucun moment cela
n'a été abordé.
Pour le moment github est un mirroir de git.spip.net

Je n'ai pas ré-épluché les courriels mais il me semble qu'il y a bien un consensus parmi les devs core pour basculer core et plugins dist sur Github, choix fait en rapport avec Composer et pour en simplifier le fonctionnement et l'adoption.

Je cite Composer et SPIP sont dans un bateau - SPIP Blog

"On propose de déplacer le code SPIP (ainsi que les tickets) et les plugins-dist sur Github, en s’assurant d’avoir une sauvegarde des tickets et des repos Git."

Et il semble bien que l'équipe et les membres actifs de la communauté ne soient pas contre ce déménagement après réflexion.

Faut-il lancer un sondage interne à l'équipe du core ou ouvert à tout le monde pour valider ce point ?

Pour les dist, actuellement est proposé une copie à l'identique de svn
sur git.spip.net
Ces copies posent un problème car les tags ne respectent pas un bon
versionnage (tag sur les version spip et non du plugin)
De mon coté j'ai un script qui corrige ce point.

Complément j'ai un script qui reprend les retours concernant la
conversion svn>git.
Il manquait les tags semver des plugins. J'ai un script qui fonctionne
sur les dépots git qu'on peut tester quand on aura un retour.

James a travaillé là dessus depuis un moment, conversion SVN -> Git et SEMVER pour le core et les plugins (cf la maquette spipremix).
Je ne sais pas ce qu'il y manque, ni s'il y manque quelque chose.

Pas mieux, James a déjà fait un script similaire pour la démo de SPIP Remix et il nous le rappelle dans son mail du 13 mai :

https://www.mail-archive.com/spip-dev@rezo.net/msg67029.html

S'il faut trancher la question (et il le faut), par consensus serait mieux.

Mais si on veut le faire de façon "stricte", avec un quorum sur la base de l'équipe du core (telle que définie dans Redmine [1]), il y a plein de gens dedans qu'on ne voit plus ou qui ne s'expriment plus.

Donc pourquoi pas un sondage après tout, et pourquoi pas ouvert, je serais plutôt pour.

Mais pour que les gens s'impliquent un minimum, il faudrait préciser l'argumentaire et le contexte en plus de la question, et que les réponses oui/non soient motivées, avec un commentaire obligatoire.

[1] https://core.spip.net/projects/spip

Hello,

S’il faut trancher la question (et il le faut), par consensus serait mieux.

Mais si on veut le faire de façon « stricte », avec un quorum sur la base
de l’équipe du core (telle que définie dans Redmine [1]), il y a plein
de gens dedans qu’on ne voit plus ou qui ne s’expriment plus.

Donc pourquoi pas un sondage après tout, et pourquoi pas ouvert, je
serais plutôt pour.

Mais pour que les gens s’impliquent un minimum, il faudrait préciser
l’argumentaire et le contexte en plus de la question, et que les
réponses oui/non soient motivées, avec un commentaire obligatoire.

Et si on faisait simple et rapide ?
On a eu ces débats n fois et comme il y a toujours quelqu’un qui n’est pas d’accord on stoppe tout.
C’est devenu presque insupportable et surtout totalement démotivant pour tout le monde.
Moi je fais confiance à l’équipe qui oeuvre depuis des années pour ne pas faire n’importe quoi quelque soit la direction qui sera prise mais de grâce bougeons un peu.

Donc l’objectif est de prendre cette décision !
Alors prenons là, prenons la vite avec un quorum limité aux gens du Core (ou plus) qui sont encore présents et intéressés à ce débat.

Donc on fait une inscription au sondage pendant 2 à 3 jours et 1 ou 2 jours derrière pour le sondage : en une semaine c’est plié (c’est un peu le style framavox).
Non ?

La chose la plus difficile, c’est de prendre la décision d’agir ; la suite n’est qu’une affaire de ténacité.

Plus ou moins d'accord, pour deux points :

1) Dans tous les cas, là il s'agit d'une décision majeure du noyau, donc
c'est à l'équipe du noyau de décider, car pour le moment il n'a pas été
question de modifier la gouvernance (juste de l'expliciter clairement
car elle était cachée avant la Charte publiée).
2) Pour faire plus réduit encore (et plus rapide normalement), c'est
justement le fait de mandater un groupe qui s'occupe d'un chantier
précis. Là le fait de déplacer le noyau sur Github, c'est issu des gens
qui bossent sur l'introduction de Composer dans SPIP, et il a été
clairement expliqué qu'en l'état de Composer, Github était vraiment la
plus simple solution pour tout le monde.

Même si on dit que c'est pas encore totalement clair, on retombe sur le
point 1, c'est à l'équipe du noyau de débattre (avec les arguments du
groupe Composer en tête) et prendre cette décision.

Yop,

Ben si ça ne concerne que la team core, c'est encore plus simple : si quelqu'un est contre, qu'il/elle le dise.

S'il y a des avis contre, à ce moment là on demande les avis pour, et on compte.