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, cam.la...@azerttyu.net <cam.la...@azerttyu.net>, 
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
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

Répondre à