[spip-dev] SPIP Zone et Git

Hello,

Je viens de migrer quelques-unes de mes contributions (5 sur whatmille) de la Zone vers Github. Et comme cela pose question à certains, voici quelques explications.

Non, je ne quitte pas la Zone.
En fait, je l’ai « quittée » depuis longtemps :slight_smile:

Vous ne le voyez peut-être pas mais ça fait des années que je contribue via Git que je trouve plus facile. Mes premiers trucs SPIP sous Git datent de 2011 (LucidaSimple, tetue_trousse…). L’inconvénient était qu’ils n’apparaissent consécutivement pas dans les sites de la galaxie SPIP. En réalité, je bosse exclusivement sous Git (Bitbucket, GitLab ou Github peu importe) et si j’ai le courage, mais pas toujours, je dépose ensuite via SVN sur la Zone (TinyTypo, PreCode…). Dès lors, ça devient certes visible de la communauté mais je délaisse la maintenance (pask SVN c’est trop galère).

Je viens donc de rassembler quelques contributions, à titre expérimental d’abord, à leur point d’origine, où j’aurai plus d’aise à les maintenir. Elles restent référencées sur plugins.spip.net (encore imparfaitement mais j’espère que ça s’améliorera) et gentiment documentées sur contrib.spip.net (j’ai hâte que les deux fusionnent : ce sera super !).

Ce rangement a été l’occasion d’apporter 2 nouvelles contributions (HTML5 et NoPub) qui étaient jusqu’alors planquées dans mes repos, youpi, et ce n’est qu’un début :slight_smile:

Pour répondre à d’autres questions (pour lesquelles je n’ai pas la hauteur de vue nécessaire) : je ne sais pas si la zone est caduque ni s’il faut passer tout SPIP sous Git (enfin si : pourquoi n’est-ce pas déjà fait, screugneugneuh ?) et non, je ne préfère pas avoir mes contribs égoïstement dans mon espace à moi rien qu’à moi (si y’avait un dépôt Git commun semblable à la Zone, ce serait sympa).

Rien d’autre à ajouter. Ah si : j’attends vos PR avec impatience :wink:

-- tetue
http://spip.tetue.net

PS : je pars en vacances hors connexion et serai peu réactive dans les 2 semaines à venir.

Coucou tetue,

Hello,

Je viens de migrer quelques-unes de mes contributions (5 sur whatmille) de la Zone vers Github. Et comme cela pose question à certains, voici quelques explications.

Non, je ne quitte pas la Zone.
En fait, je l’ai « quittée » depuis longtemps :slight_smile:

Merci pour ces précisions.
C’est vrai que je me suis posé des questions en voyant le déménagement :p.

Vous ne le voyez peut-être pas mais ça fait des années que je contribue via Git que je trouve plus facile. Mes premiers trucs SPIP sous Git datent de 2011 (LucidaSimple, tetue_trousse…). L’inconvénient était qu’ils n’apparaissent consécutivement pas dans les sites de la galaxie SPIP. En réalité, je bosse exclusivement sous Git (Bitbucket, GitLab ou Github peu importe) et si j’ai le courage, mais pas toujours, je dépose ensuite via SVN sur la Zone (TinyTypo, PreCode…). Dès lors, ça devient certes visible de la communauté mais je délaisse la maintenance (pask SVN c’est trop galère).

J’ai l’impression que cette migration, alternative à SVN, est un mouvement inexorable.
Il va falloir en tenir compte et ce, je pense, assez rapidement.
On a un problème aujourd’hui avec ces contributions Github (pour l’instant on a que du Github d’ailleurs en external, je me demande si ça serait pas bon de renommer archivelist_externals.txt en archivelist_github.txt) : le lien des sources est vérolé et on ne peut référencer qu’un tag via le fichier archivelist_externals.txt. En outre, on regénère un zip alors qu’il est déjà disponible sur Github.

Je ne suis pas très au fait de git et github mais ne pouvons pas imaginer une autre façon de référencer les contributions SPIP sur github sans générer le zip mais en calculant uniquement les liens source et zip, et en incorporant le paquet.xml dans le archives_externals.xml final ?
Bien sur ça demande à revoir le smart-paquets (interface GIT) mais est ce un gros sujet aujourd’hui ?

Je viens donc de rassembler quelques contributions, à titre expérimental d’abord, à leur point d’origine, où j’aurai plus d’aise à les maintenir. Elles restent référencées sur plugins.spip.net (encore imparfaitement mais j’espère que ça s’améliorera) et gentiment documentées sur contrib.spip.net (j’ai hâte que les deux fusionnent : ce sera super !).

Oui on est en cours, c’est long mais surement prometteur.

Rien d’autre à ajouter. Ah si : j’attends vos PR avec impatience :wink:

Ca c’est le sujet qui me chagrine le plus par rapport à ces migrations vers GIT.
Depuis des jours je passe tous les plugins en revue pour revoir la catégorisation des plugins.
Cela m’amène à découvrir des plugins et aussi des manques/erreurs dans les paquet.xml en particulier pour le slogan, la description et le lien de doc.
Ayant la zone en SVN sur mon ordi j’ai pu faire les corrections dans la foulée en quelques secondes.
Et puis je suis tombé sur certains plugins uniquement sur GIT et là… je n’ai rien pu faire car il aurait fallu que je clone le repo, je fasse la modification, la PR et ensuite attendre qu’un jour elle soit prise en compte. C’est un peu dommage.
Si en plus, chaque auteur de plugin a son propre repo par plugin plus on aura de plugin plus cela sera « non collaboratif ».

Il me parait donc important de réfléchir à une « zone git SPIP » rapidement qui nous permettre de continuer à améliorer les plugins facilement et proposer que les contributions SPIP y soient regrouper plutôt que de laisser faire le mouvement actuel dans pleins de repo « privés ».

github fournit des zip de chaques branches. On pourrait imaginer que smart paque reécupère directement les zips plutot qu'un svn up puis zippage

Yo!

Rien d’autre à ajouter. Ah si : j’attends vos PR avec impatience :wink:

Ca c'est le sujet qui me chagrine le plus par rapport à ces migrations vers GIT.
Depuis des jours je passe tous les plugins en revue pour revoir la catégorisation des plugins.
Cela m'amène à découvrir des plugins et aussi des manques/erreurs dans les paquet.xml en particulier pour le slogan, la description et le lien de doc.
Ayant la zone en SVN sur mon ordi j'ai pu faire les corrections dans la foulée en quelques secondes.
Et puis je suis tombé sur certains plugins uniquement sur GIT et là... je n'ai rien pu faire car il aurait fallu que je clone le repo, je fasse la modification, la PR et ensuite attendre qu'un jour elle soit prise en compte. C'est un peu dommage.

Non, tu peux éditer les fichiers et faire les PR directement sur le site, trop easy : il suffit de cliquer le petit crayon en haut à droite de chaque fichier consulté !
À défaut, ouvre au moins une Issue pour que le gars sache.

Au fait, la PR n’est pas systématique : j’ai contribué à des projets sur GitHub en commitant direct (sans PR donc).

Si en plus, chaque auteur de plugin a son propre repo par plugin plus on aura de plugin plus cela sera "non collaboratif ».

C’est une autre façon de collaborer, moins centralisée, ouverte à bien davantage de contributions. C’est différent.

-- tetue

Github permet de mettre en place des automatismes pour produire tout ce qu'on veut
avec travis ci :
https://github.com/marketplace/travis-ci
https://github.com/apps/travis-ci
Certains softs s'en servent pour compiler leur source et fournir un exécutable,
mais ça peut faire ce qu'on veut et produire ce qu'on veut.
Une part de l'archi smart paquet svp etc pourrait donc être déportée sur ces outils
si c'est pertinent, et, en tout cas, des outils mis en place avec Travis CI
sur la zone git peuvent produire tout ce dont les outils spip ont par ailleurs
besoin pour fonctionner au mieux.

JL

Eric Lupinacci a écrit le 04/05/2019 à 14:59 :

Coucou tetue,

Le sam. 4 mai 2019 à 13:46, tetue@rezo.net <mailto:tetue@rezo.net> <tetue@rezo.net <mailto:tetue@rezo.net>> a écrit :

    Hello,

    Je viens de migrer quelques-unes de mes contributions (5 sur
    whatmille) de la Zone vers Github. Et comme cela pose question à
    certains, voici quelques explications.

    Non, je ne quitte pas la Zone.
    En fait, je l’ai « quittée » depuis longtemps :slight_smile:

Merci pour ces précisions.
C'est vrai que je me suis posé des questions en voyant le déménagement :p.

    Vous ne le voyez peut-être pas mais ça fait des années que je
    contribue via Git que je trouve plus facile. Mes premiers trucs SPIP
    sous Git datent de 2011 (LucidaSimple, tetue_trousse…).
    L’inconvénient était qu’ils n’apparaissent consécutivement pas dans
    les sites de la galaxie SPIP. En réalité, je bosse exclusivement
    sous Git (Bitbucket, GitLab ou Github peu importe) et si j’ai le
    courage, mais pas toujours, je dépose ensuite via SVN sur la Zone
    (TinyTypo, PreCode…). Dès lors, ça devient certes visible de la
    communauté mais je délaisse la maintenance (pask SVN c’est trop galère).

J'ai l'impression que cette migration, alternative à SVN, est un mouvement inexorable.
Il va falloir en tenir compte et ce, je pense, assez rapidement.
On a un problème aujourd'hui avec ces contributions Github (pour l'instant on a que du Github d'ailleurs en external, je me demande si ça serait pas bon de renommer archivelist_externals.txt en archivelist_github.txt) : le lien des sources est vérolé et on ne peut référencer qu'un tag via le fichier archivelist_externals.txt. En outre, on regénère un zip alors qu'il est déjà disponible sur Github.

Il y a aussi le problème avec le mode de téléchargement SVN de SVP :
https://core.spip.net/issues/3927

Eric Lupinacci a écrit le 04/05/2019 à 14:59 :

Et puis je suis tombé sur certains plugins uniquement sur GIT et là... je n'ai rien pu faire car il aurait fallu que je clone le repo, je fasse la modification, la PR et ensuite attendre qu'un jour elle soit prise en compte. C'est un peu dommage.

GitHub permet aussi d'utiliser directement leur éditeur en ligne (dans le navigateur) ce qui permet de faire un fork, et un PR sans rien avoir eu à mettre sur son ordinateur.

C'est prévu, ça va venir (au sens : le truc officiel qui ne va plus du
tout bouger pendant longtemps), dans pas si longtemps on espère :slight_smile:

Cousou,

merci pour vos efforts de développement des services et infrastuctures
autour de SPIP.

A mon avis la zone constitue un endroit central important pour SPIP qui
souffre depuis toujours de l'eparpillement de sa documentation. Comment
cette fonction essentielle sera réalisée avec GIT ?

Comment se présentera dans l'avenir l'ensemble des projets et recueils
de code en rapport avec SPIP ?

Je crains que la création d'un compte Github pour chaque projet se
transforme en coup de poignard pour SPIP.

Si la communauté SPIP abandonne sa propre infrastructure elle se rend
très vulnérable et perd une partie de son identité.

Enfin il se pose la question de la dépendance d'un monopole étatsunien.

:-)k++

Bonjour

Je me permets juste de dire que les personnes intéressées peuvent
toujours tester
https://git.spip.net
Cet espace est à disposition de toutes personnes voulant jouer avec
expérimenter, ....

Comme personne n'a défini le nommage définitif des projets, c'est pour
le moment une reprise du nommage actuel de la zone. Elle peut évoluer
selon les inspirations de chacun.

Pour ma part je prends tout retour. A noter que l'évolution et la
maintenance sont uniquement sur mon temps libre et qu'actuellement
SPIP n'est plus ma priorité. Mais je serais heureux que cette forge
reste dans le giron de la communauté.

Km

Ça a déjà été expliqué plusieurs fois sur cette liste dans les
discussions précédentes sur Composer : il s'agit de faire une
Organisation commune pour "spip-zone" (mais qui pourrait s'appelait
autrement, c'est ça qu'il reste à fixer une fois pour toute), et qui
contiendra tous les projets à maintenir en commun comme actuellement
dans le SVN de spip-zone. Donc c'est très exactement le même
fonctionnement avec les mêmes droits de modif pour tous le monde comme
actuellement, mais en Git.

Merci pour tous ces services.

Pour l'instant c'est surtout le trac qui est gênant
car selon les moments, l'affichage plante entre 1 fois sur 2 et 19 fois sur 20
ce qui veut dire qu'il faut F5 entre 1 et 19 fois pour avoir la page affichée
par exemple, là : https://zone.spip.org/trac/spip-zone/changeset/115252
C'est pénible.

Or il y a bien des alternatives pour les dépots : svn, git.spip, github/spip,
mais le trac est un outil central pour les devs spip.

Pourrais tu, dans l'immédiat, concentrer ton libre dédié à SPIP
à la remise sur pied d'un trac pleinement opérationnel ?

JLuc

Pour ma part je prends tout retour. A noter que l'évolution et la
maintenance sont uniquement sur mon temps libre et qu'actuellement
SPIP n'est plus ma priorité. Mais je serais heureux que cette forge
reste dans le giron de la communauté.

Merci pour tous ces services.

Pour l'instant c'est surtout le trac qui est gênant
car selon les moments, l'affichage plante entre 1 fois sur 2 et 19 fois sur 20
ce qui veut dire qu'il faut F5 entre 1 et 19 fois pour avoir la page affichée
par exemple, là : Connexion · GitLab
C'est pénible.

Or il y a bien des alternatives pour les dépots : svn, git.spip, github/spip,
mais le trac est un outil central pour les devs spip.

L'alternative c'est la ligne de commande :
svn log -c115251
et
svn diff -c115251

Merci, alors je vais me mettre à explorer git.spip.net
Si jamais j'arrive à me débrouiller avec, ce sera bon signe :wink:

:-)k++

klaus++ a écrit le 06/05/2019 à 10:54 :

Je crains que la création d'un compte Github pour chaque projet se
transforme en coup de poignard pour SPIP.

Je le crains aussi : ce matin, j'ai fait un svn up sur ma machine de dev de mon dossier plugins/
J'y avais en SVN favicon et figures
Ils ont disparus.

Et comme j'utilise le mode d'installation SVN de SVP, je ne peux pas les récupérer par SVP (cf https://core.spip.net/issues/3927).

Bon, je vais réussir à les retrouver.
Mais si après la doc qui est morcelée, retrouver les plugins devient tout aussi difficile, il ne va bientôt rester que les vieux de la vieille, et la courbe d'apprentissage/utilisation de SPIP tant chérie sera un lointain souvenir :frowning:

Hop,

Bruno Bergot a écrit le 06/05/2019 à 18:11 :

Hop,

klaus++ a écrit le 06/05/2019 à 10:54 :

Je crains que la création d'un compte Github pour chaque projet se
transforme en coup de poignard pour SPIP.

Je le crains aussi : ce matin, j'ai fait un svn up sur ma machine de dev de mon dossier plugins/

Comme on te le disait sur IRC, si tu installes des plugin par svn sur ton serveur c'est que tu sais ce à quoi tu t'exposes.

Les plugins en question sont toujours disponibles en zip et donc par le biais de SVP :slight_smile:

Justement non !
Pas si SVP est en mode d'installation par SVN.
Et c'est bien là le problème.

- Il me semble me rappeler que cette fonctionnalité (SVP_PREFERER_TELECHARGEMENT_PAR_VCS) était arrivée suite à ta demande à l’origine.
- Il me semble qu’il n’y a quasiment que toi qui l’utilise actuellement.
- Ça ne fonctionne pas avec les externals github...

-> Propose des solutions pour améliorer la situation

Pour ma part je préfèrerais trouver des solutions pour passer à Composer (qui lui gère correctement ces changements de VCS lorsqu’on utilise son option --prefer-source).

MM.

Et beh alors, comment on fait et qu'est ce qu'on fait pour ça ?

JLuc

Matthieu Marcillaud a écrit le 07/05/2019 à 09:01 :

Bruno Bergot a écrit le 06/05/2019 à 18:11 :

Les plugins en question sont toujours disponibles en zip et donc par le biais de SVP :slight_smile:

Justement non !
Pas si SVP est en mode d'installation par SVN.
Et c'est bien là le problème.

- Il me semble me rappeler que cette fonctionnalité (SVP_PREFERER_TELECHARGEMENT_PAR_VCS) était arrivée suite à ta demande à l’origine.

Je veux bien te croire, mais ça n'est pas le souvenir que j'en ai.
Mon souvenir, c'est d'avoir découvert dans la doc que c'était possible et me dire que c'était pratique pour :
- récupérer le chemin svn facilement
- pour ensuite mettre à jour par SVN

- Il me semble qu’il n’y a quasiment que toi qui l’utilise actuellement.

C'est aussi l'impression que j'ai :wink:

- Ça ne fonctionne pas avec les externals github...

Oui, c'est l'objet du ticket.

-> Propose des solutions pour améliorer la situation

C'est aussi l'objet du ticket

Pour ma part je préfèrerais trouver des solutions pour passer à Composer (qui lui gère correctement ces changements de VCS lorsqu’on utilise son option --prefer-source).

:wink: