Salut

> Je vais donc mettre les pieds dans le plat et appeler un chat un chat.
>
> 1/ Gitea vs autre chose
> 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).

Désolé mais je vais être en désaccord :)
J'ai regardé et testé plusieurs forges gitolite, gitosis, gitlab,
phabricator, redmine et gitea. J'en oublie peut être d'autres.

Sur toutes les solutions testées gitea me semble le meilleurs compromis :
du point de vue technique:
* il s'installe et se met à jour facilement
* la présence des fichiers sont unifiés et n'a pas ce mode omnibus de
gitlab qui en met de partout
* le suivi/disponibilité des mainteneurs du projet

du point de vue utilisateur :
* la page d'accueil peut être personnalisée (pendant longtemps c'était
uniquement dans l'offre payant de gitlab)
* le support multilangue
* la personnalisation du theme (boussole qui sert à naviguer dans notre galaxie)
* le suivi/disponibilité des mainteneurs du projet (oui je me répete
car cela impacte aussi l'usage quotidien)

Si on avait voulu rester sur du pure technique facilement à maintenir
git over ssh c'était le mieux.

> 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)

Sur point je ne peut être que d'accord je continue à payer les pots
cassés de la maintenance de core.spip.net . D'autant plus que trac est
toujours là car on n'a pas réussi à la tuer.

> 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

Mais ça sera toujours le problème aucune solution ne plaira, il faut
trouver un équilibre/compromis

>
> 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.

Oui car les aspects dit techniques de composer ne sont pas des vrais
blocages, en tout cas sur les points que j'ai vu.
Comme par exemple versionner correctement un plugin sans casser tout
l'historique cela se fait.

Pour moi le problème principal reste les conventions dans le nommage
des différents projets (coté git , composer , ....)

> 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.

Composer est compatible avec n'importe quel vcs. C'est juste que si on
utilise github on peut se passer du vcs pour télécharger le zip en
direct. (les numéros de versions sont prédictibles)
Cela peut posera un problème dans le cadre d'une diffusion large.
Dans le cas actuel ce n'est pas le cas, on propose nous même le zip
unifié grand public cela n'est pas un point bloquant.
Et pour les développements si on est capable d'installer composer et
svn on est capable d'installer git.

> 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.

Ce qui pose problème c'est un tiers qui n'est pas de confiance (on en
a eu la preuve dernièrement) Il est pratique et monopolistique (et
pour moi assez éloigner de l'esprit communautaire de SPIP). Donc comme
point d'entrée et base de travail je coince beaucoup.

Cela n'empeche pas d'avoir une meilleure visibilité et une
simplification d'échange avec d'autres. Et pour rappel SPIP est déjà
sur github depuis des plombes. Le miroir est actif et fonctionnel.

> 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.

Toutefois le problème de nomenclature n'est toujours pas réglé github ou pas.

> 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.

Sur ce point la proposition que je propose c'est une forge maintenue
par la communauté git.spip.net et un miroir sur github pour la
visibilité.
Les organisations git (que ce soit gitea ou github) ne sont pas figées
et en théorie devraient évoluer (pour simplifier l'usage de composer)
mais sur ce point il faudrait savoir vers quoi.

Km
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

Répondre à