Re: [SPIP Zone] Mise à jour git.spip.net

Hello,

il y a en effet deux sujets distincts mais avec une intersection non nulle ce qui pollue le débat.

Je vais donc mettre les pieds dans le plat et appeler un chat un chat.

1/ Gitea vs autre chose
Il faut commencer par dire que Camille a fait un boulot énorme sur la migration a GIT, et l’en remercier.

Mais le choix de Gitea est uniquement fait sur des critères techniques, pour faciliter l’admin sys, et non sur des critères d’utilisabilité ou de fonctionnalités (peut-être aussi pour des contraintes liés à la synchro svn-git, mais qui n’est plus à l’ordre du jour).

La dernière fois qu’on a changé d’outil (passé de Trac à Redmine), il y avait eu une discussion et un choix collectif, sur des critères fonctionnels et de pérénité de l’outil, pas sur des critères d’admin sys (parce que croyez moi ou non, mais la maintenance de Redmine c’est quand même une sacré merde dans son genre,  à moins peut-être d’être sur un serveur configuré spécifiquement pour la pile Ruby On Rail)

Là l’outil est imposé et manque de chance ça ne plait pas à grand monde, d’autant plus qu’à côté on est beaucoup à être très contents de Gitlab (libre) ou de Github (qui a l’avantage de ses défauts), qu’on utilise à côté sur plein de projets

Du coup personne n’a envie d’y aller, on traine des pieds, on louvoie, voire on essaye d’esquiver en profitant du sujet N°2, à savoir Composer

2/ Composer donc
Qui impose de son côté des contraintes sur l’import Git, le découpage du core et d’autres petits tracas techniques que James saurait mieux expliquer. Rien d’insurmontable, mais aussi une migration vers Git un peu différente de ce qu’avait préparé Camille du coup dans le découpage - mais je comprends que dans les derniers travaux de Camille ça s’unifie.

La publication des paquets et les mécanismes Packagist ne sont pas compatibles avec Gitea, moyennement compatibles avec Gitlab, mais totalement Github.
Du coup il est tentant de dire : hop passons à Github, c’est facile pour ce point Composer, et ça esquive Gitea sans trop en avoir l’air.

Mais voilà, on sent bien que c’est quand même une façon un peu moisie de résoudre 1/ et du coup on tourne autour du pot.

Parce qu’on pourrait très bien avoir notre dépôt principal sur un Gitea ou un Gitlab SPIP (avec tout ce qui va bien, les tickets etc) et juste un mirroring automatique vers Github, tant pour la publication vers Packagist que pour la visibilité et les PR.

Je crois qu’on est tous à peu près OK pour composer, en faisant confiance à ceux qui on vraiment travaillé sur le sujet, parce que d’un peu loin on voit pas très bien toutes les implications et les contraintes qui vont venir avec.


Mais le point 1 reste à résoudre par une vraie discussion et un consensus, sinon on restera dans cette situation moisie où rien ne bouge.

--
Cédric
Le 6 août 2019 à 16:02 +0200, [email protected] <[email protected]>, a écrit :
> Salut
> > Cette discussion tombe à pic car j'avoue ne plus être sur de la fin de la saison précédente et je me demande si les producteurs ont décidé ou pas de renouveler la série "Git & Composer" pour une nouvelle saison.
> >
> > Si je résume (surement très approximativement) ce que je comprends de la situation :
> > - le "groupe de travail Composer" propose de passer SPIP (core + plugins-dist ?) sous Composer et donc pour faciliter l'administration (et patati patata) de migrer les sources sur la plateforme GitHub qui simplifie l'utilisation de Packagist. Le hic semble être GitHub pour certains même si on y a tous un compte...
> > - Camille a tout préparé pour que les sources de SPIP soit sous GIT avec la plateforme open-source Gitea qui n'est pas totalement compatible avec Packagist en l'état. Et Camille fait remarquer que si on migre sous GitHub on ne reviendra jamais sur Gitea, si dans le futur, Gitea devient "compatible Packagist" ou le contraire.
> >
> > Le problème c'est que personne n'a vraiment tort et donc résultat : on est bloqué comme cela nous est déjà arrivé et j'ai l'impression que cette idée de Composer est repoussée aux calendes grecques alors qu'elle est prometteuse et permettrait de sortir un peu de notre torpeur estivale.
> >
> > Aussi, a-t-on une porte de sortie rapide à cette situation ?
> > Je trouve la situation actuelle plus délétère qu'une potentielle "erreur" d'aiguillage.
> > Le choix GitHub est-il vraiment si terrible ?
> >
> >
> > Vos avis ?
>
> Comme depuis un moment les 2 trucs sont compatibles et n'ont pas grand
> chose à voir.
> Par exemple wordpress refuse composer et travaille avec svn et
> pourtant il existe une solution composer
>
> Parmi les freins identifiés (et que j'ai compris)
> * le problème des versions, dans le svn les tags sont relatifs à SPIP
> et non au plugin lui même
> * la possibilité de télécharger les zip (raison de github)
> * une nomenclature des organisations pour respecter la logique de
> nommage de composer.
> * le choix de la forge
> * la mise à disposition des paquets au format composer
>
>
> Pour le premier point, cela est réglé via
> https://git.spip.net/_outils_/creer_tags (il y a déjà un mail
> spécifique pour expliquer son comportement)
>
> Pour le second point, le plus simple serait de fournir un driver gitea
> pour composer qui permettrait de choisir git ou zip.
> Ce point me semble mineur car si on utilise composer on a très
> probablement la main sur la machine cible et donc la possibilité
> d'installer aussi git
> L'api de gitea est proche de celle de de github, on peut donc
> envisager de proposer le dit driver à composer pour supporter les
> archives zip.
> Enfin il est toujours possible d'avoir github en miroir de gitea
> (c'est déjà le cas pour la partie core de spip)
>
> Pour le troisième point, il n'y a toujours pas eu de décision aux
> diverses questions soulevées par mail. Cette non décision bloque la
> pérennité de nommage dans les dépôts git ( peu importe la forge)
> Ce point me semble le plus problématique car il est uniquement organisationnel
>
> Pour le quatrième point, je pense toujours que github est un mauvais
> choix par défaut
> Ce mois ci une partie des contributeurs ont été bloqués juste pour
> une histoire de politique américaine
> Ensuite il est tout à fait possible d'avoir github en miroir, c'est
> déjà le cas
> git.spip.net fonctionne
> De mon coté j'aurais le même discours pour toute autre forge
> propriétaire qui aurait pour vocation de gérer une communauté
> complète. Il n'y a pas de transparence, pas de maîtrise, ...
>
> Pour le cinquième point, packagist, satis simplifient énormément
> l'écriture du fichier composer.json (car ils fournissent les
> correspondances de téléchargement/version/paquet).
> On peut s'en passer à condition d'écrire un fichier assez verbeux
> (ce que j'ai testé et qui fonctionne)
> De ce que j'ai identifié il y a 2 morceaux importants
> https://github.com/spipremix/composer-installer pour ranger les
> différents projets git à leur place et le metapaquet pour piloter tout
> ça
>
>
> Actuellement il est possible d'utiliser composer (certes c'est un gros
> fichier) d'autant plus qu'il est tout à fait possible d'améliorer
> l'existant sans remettre en cause et tout casser car le futur c'est
> mieux.
> En tout cas de mon coté je travaille sur les différents points qui
> seraient considérés comme bloquant.
>
>
> Km
> _______________________________________________
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: http://www.spip.net/
> dev: http://trac.rezo.net/trac/spip/
> irc://irc.freenode.net/spip