Deux points de discussions qu’il serait intéressant d’aborder ; en priorité sur la doc d’upgrade.
Docs Upgrade
Au fil des travaux de SPIP 5-dev, le fichier UPGRADE_5.0.md est une excellente base bien pratique à remplir au fil de l’eau, mais devient assez gigantesque et du coup pas très pratique.
On se proposerait bien de créer un dépot spip/docs avec différents fichiers markdown découpés avec une architecture telle que
fr/upgrade/index.md + autres fichiers_spécialisés.md dans une branche 5.x ou 5.0 à voir,
ou fr/5.0/upgrade/index.md
Le fichier UPGRADE_5.0.md aurait des liens pointant vers ce dépot de doc. Ça permettrait de séparer différents aspects de la migration en autant de plus petits fichiers.
Des contre-indications ?
Historique du dépôt spip/spip
Le dépot spip/spip a un historique conséquent (tout l’historique git+svn de SPIP) mais n’utilise plus que quelques fichiers depuis quelques versions de SPIP ; ecrire/ et prive/ ayant leur dépots respectifs.
C’est beaucoup de code téléchargé (en git) inutilement. On se disait qu’on pourrait ne plus l’utiliser en SPIP 5, ce qui pourrait entrainer quelques nouvelles problématiques de migration tout de même.
Soit avoir un spip/qqc (spip/kit, spip/base, spip/project, … ?) à la place sur le même serveur git.spip.net ;
Soit avoir ce spip/spip sur Codeberg : depuis tout récemment, cette plateforme peut se synchroniser avec Packagist (comme github et gitlab.com), ce qui pourrait faciliter une installation fraîche : un simple composer create-project spip/spip (sans déclaration à composer de notre dépôt Satis spécifique à SPIP ; donc pas besoin de passer --repository=https://get.spip.net/composer ). Évidemment, cela oblige à créer des comptes là bas pour les PR et merges sur ce dépôt si ce choix est fait. Mais en délégant à spip/docs notamment l’upgrade, il pourrait n’y avoir que bien moins de modifications également dans le cadre général.
Ce point est néanmoins à traiter avec précaution car influe aussi sur d’autres outils utilisés (checkout, spip-realase) notamment.
Ce point n’est pas spécialement prioritaire, mais une réflexion à mener au moins.
Quelque soit le lieu, ça me parait quand même bizarre et problématique, pour le même unique logiciel d’avoir des morceaux sur une plateforme et des morceaux sur une autre (on ne parle pas de tel logiciel d’un côté et des extensions ailleurs, mais bien de la même distribution).
Je n’ai probablement pas compris ta réponse ? Tu parlais juste d’avoir des bouts sur le gitlab et d’autres sur codeberg ? tu peux développer ?
Là on télécharge 76Mo de .git (juste le spip/spip) et 23000+ historique de commits pour 20 fichiers restants maintenant. Si on veut mettre une CI pour les tests d’intégration, ça pourrait aussi lui faire un peu d’économies.
Là je disais soit on bascule sur spip/project (ou autre nom) sur ce gitlab. Ce n’est pas très problématique je pense un tel changement (l’usage de spip/spip disparaîtrait au fil des ans et nouvelles versions et pourrait être archivé par exemple dans x années). La question d’où mettre ou déplacer les tickets se pose aussi.
Soit on conserve spip/spip sur un autre lieu (Codeberg) en améliorant la découvrabilité de SPIP sur Packagist en bonus, ce qui serait aussi une très bonne chose.
Bah tu proposes (l’une des pistes) de mettre uniquement spip/spip sur codeberg, dans ce cas ça serait une nouvelle version plus légère sans l’historique c’est ça ? et ça serait le dépôt de référence pour spip/spip ? Si c’est ça, je dis donc qu’avoir un morceau de SPIP ailleurs, et d’autres morceaux chez nous, c’est bizarre à mon sens, pour un même logiciel entier.
Mais du coup c’est peut-être ta proposition qui n’était pas claire (au moins pour moi).
Je dis peut-être du caca mais comme autre piste plutôt que de changer de nom, est-ce qu’on pourrait pas :
archiver l’actuel spip/spip dans un autre nom (spip/spip_avec_tout_historique :p)
refaire notre spip/spip plus léger à zéro (ou avec qu’un historique récent de X mois)
et donc garder la même url, même nom etc sans rien changer
Oui, ça serait une version neuve, sans historique pour SPIP 5+. (sur le même principe qu’un éventuel spip/project suggéré aussi donc)
Bah là le problème à résoudre devient différent : tous les SPIP déjà clonés ne fonctionneraient plus : Gitlab saura bien gérer la migration spip/spip vers spip/autre-chose (même sur les git pull / clone des gens ayant l’ancienne URL), mais dès que tu auras le nouveau dépot spip/spip quasi vide de recréé, gitlab ne fera plus de redirection, très logiquement, alors toutes ces gits dans la nature ne fonctionneraient plus (en tout cas ne pourraient plus faire leur git pull correctement, sans déclarer le bon remote ou remplacer le remote origin devenu erroné donc).
J’ai pas l’impression que ce soit un problème puisque si le dépôt de référence spip/spip part ailleurs OU si on change pour spip/projet, dans les deux cas, tous les gens vont devoir changer des choses dans leurs installations pour continuer à pouvoir mettre à jour.
Donc leur faire changer le remote ou autre commande git pour se mettre sur le bon commit final, ne pose pas plus de problème il me semble.
Cela dit pourquoi il faudrait changer le remote, puisque si on recrée spip/spip avec même orga et même nom de dépôt, l’URL sera la même, et donc le remote sera le même qu’avant non ? Je loupe un truc ?
Ce n’est pas tout à fait la même chose de passer de 4.4.x à 4.4.x+1 , que de passer de 4.4 à 5.0… On pourrait s’attendre à ce que rien ne change pour passer à 4.4.x+1 donc ; c’est dans ce sens là que c’est plus ennuyant.
Si tu gardes spip/spip (SPIP 5+)(pas de branches <= 4.4) avec un spip/spip-legacy (toutes les branches SPIP <= 4.4), il te faut modifier le remote pour faire git pull en SPIP 4.4, le nouveau spip/spip n’ayant plus connaissance de cette branche.
Cela dit en disant cela je me dis qu’on peut aussi mettre la branche 4.4 dedans d’ailleurs aussi (qui a quasi rien également), cela serait plus simple. Alors disons pour les branches 4.3 et antérieures qui n’y seraient pas.
Ah oui sur la version « recréée légère » je pensais pas à que 5+, mais au moins 4.4 entier puisque LTS + les tags importants éventuellement. Et donc ça casserait rien chez personne à priori.
Je préfèrerais fr/5.0/upgrade/, qui serait donc présent et lisible dans toutes les branches, plus facile pour accéder à la doc (me semble).
Pour l’autre point, comme @rastapopoulos je trouve bizarre d’avoir une partie du code hébergée ailleurs.
La solution dont vous discutez dans le fil me parait préférable, un « nouveau » dépôt spip/spip 4.4+, avec une info diffusée sur les listes (discuter pardon, je m’y fais pas) sur le changement de remote pour 4.4-
Sur le sujet de la découvrabilité / rézosocial (EDIT : et composer sans Satis), c’est un argument, mais est ce qu’une synchro git.spip → codeberg (comme vers github), si ça existe et si c’est simple à gérer, n’est pas suffisante ?
C’est une question à laquelle je n’ai pas la réponse là. Peut être. La réactivité des pages sur Codeberg n’avaient pas l’air fulgurantes non plus cela dit, donc peut être pour spip/spip, mais pas synchroniser tous les dépôts. L’histoire de nos synchros avec Github a montré aussi que ça ne fonctionnait pas toujours correctement également (elles ont d’ailleurs été enlevé), mais ça peut se tenter certainement, si c’est effectivement possible.
Un autre point non abordé d’ailleurs, c’est que si du symfony/flex était en place, il n’y aurait besoin que d’1 seul fichier composer.json dans le dépôt (bon, 2 avec le Readme quand même), le reste serait injecté via des recettes Flex. Ce ne s’est pas mis place dans tous les cas ; mais il ne faut pas non plus surcoter ce dépot : son contenu est devenu très minime.
Par ailleurs on ne peut pas créer un nouveau dépot en conservant une partie de l’historique 4.4 ou les tags avec les mêmes hash de commits ; git status, git pull ne vont pas aimer d’ailleurs une fois le nouveau remote configuré. A priori il faut git fetch origin (le nouveau remote configuré), git reset --hard origin/X , sinon git est tout perdu ; et si tu avais des branches locales, j’imagine qu’il faut les recréer en repartant du nouveau X et faire des cherry-pick des commits que tu avais ajoutés dans ta branche… C’est quand même un peu de réflexions pour ça. Ou il faut reclone si tu n’avais rien d’important dans ton dépot local. Ce n’est pas forcément trivial.
Bref, cela ne me paraît pas super propre de modifier le dépot spip/spip actuel (ou d’en recréer un sous ce nom là donc dans gitlab une fois celui-ci renommé). J’ai l’impression que ça va amener plus d’embrouilles que d’améliorations cette solution.
Top, merci.
Et je ne désespère pas de prendre le temps d’un programmer5.spip.net tout en markdown, histoire de valider aussi en « réel » les plugins adhoc.
Mais je suis un peu sous l’eau en ce moment…
Je réagis un peu tardivement mais merci beaucoup @marcimat pour la mise en place de spip/docs et pour les perspectives pour SPIP! Et je dois avouer que la découvrabilité de ce dernier via packagist me semble intéressante et importante. Je suis donc clairement favorable à la migration de spip/spip, même si comme tu le mentionnais se posent aussi d’autres questions comme la gestion des tickets, etc.
Et je réitère ici tout l’intérêt que j’avais pour symfony/flex et que ce mécanisme est vraiment d’un confort incroyable lors du développement avec Symfony…
J’ai commité quelques trucs python associés (mkdocs, material, mike) pour générer des pages statiques avec recherche sur ces fichiers markdown. Avec un peu de chance on pourrait activer docs.spip.net pour gérer des Gitlab Pages sur le gitlab git.spip.net (Il faut cela dit configurer le Gitlab pour cela, c’est un peu moins mon truc…).
Mais donc un exemple de rendu possible: https://spip-docs-e757b5.gitlab.io/fr/5.0/
J’ai mis quelques fichiers en 4.4 histoire de voir avec plusieurs versions (ça complique pas mal la gestion du site statique, en plus du multilinguisme qui lui-même complique aussi).
Mais ça donne une recherche top je trouve en plus. Ça motiverait peut être à écrire plus de choses en markdown dans ce dépot et traduire (c’est des stub actuellement)
Et juste alléger l’historique en ne gardant que les diffs autour des qq tags utiles, pour que ça soit le même repo, mais léger ? avec git filter-repo --refs refs/tags/v1.0 refs/tags/v2.0 ...
Il me semble que tout filter-repo réécrit les hash de commits. Donc a priori mauvaise idée de faire cela sur le dépot actuel. Et on perdrait tout l’historique par ailleurs qu’on veut justement conserver quelque part (enfin on pourrait le dupliquer ailleurs avant)
J’ai modifié la génération de doc, qui est passé de mkdocs + material + mike à uniquement zensical + make (zensical étant le successeur autoproclamé de mkdocs en cours de développement). J’anticipe. Il y a un seul point qui est moins bien (une mutualisation de config commune, mais sera corrigé par zensical plus tard) et déjà des trucs mieux, notamment le thème système par défaut pour light/dark ; il y a donc auto/light/dark quoi, et une navigation qui modifie le header au scroll.
Générer le site localement est assez simple ma foi avec ça
Et donc, on a configuré notre Gitlab pour autoriser des Pages, par défaut sur pages.spip.net/{organisation}/{projet} et pour ce spip/docs précis on a créé un raccourcis https://doc.spip.net/ ; C’est pas trop mal.
Il y a quelques pétouilles à faire côté CSS possiblement, et à améliorer la doc
sur SPIP 5 c’est donc la doc de notre branche de travail config_plugin qu’il va d’ailleurs falloir intégrer bientôt
sur SPIP 4.4 si des gens se sentent motivé·es mais ce qui est là est déjà un pas intéressant (ça reprend l’article de release de spip.net)
