Bonjour
Pour information le serveur git de la communauté a été mis à jour.
Pour la liste des petites avancées (hors correctifs) je vous invite à
lire les information sur :
https://blog.gitea.io/2019/01/gitea-1.7.0-is-released/
La 1.8.0 devrait arriver sous peu (la rc2 est publiée) et apporter des
améliorations sur la gestion des organisations.
Km
Bonjour
Une mise à jour de sécurité a eu lieu. La version 1.7.6 de gitea a été déployée.
Plus d'information sur https://blog.gitea.io/2019/04/gitea-1.7.6-is-released/
Km
Bonjour
Pour information le serveur git de la communauté a été mis à jour.
Pour la liste des petites avancées (hors correctifs) je vous invite à
lire les information sur :
https://blog.gitea.io/2019/04/gitea-1.8.0-is-released/
Km
Bonjour
Nouvelle mise à jour de sécurité avec la version 1.8.1
https://blog.gitea.io/2019/05/gitea-1.8.1-is-released/
Note : le pied de page n'est pas mis à jour et indique toujours 1.8.0
(cela semble un oubli des dev)
Km
Merci pour ton boulot azerttyu !
-----Message d'origine-----
Bonjour
Nouvelles mises à jour avec divers correctifs avec les version 1.8.2
et 1.8.3 (j'ai pris un peu de retard sur le suivi)
https://blog.gitea.io/2019/05/gitea-1.8.2-is-released/
https://blog.gitea.io/2019/06/gitea-1.8.3-is-released/
Note : le pied de page n'est toujours pas mis à jour et indique toujours 1.8.0
Km
Merci azerttyu pour le boulot ! 
Franck
-----Message d'origine-----
Bonjour Gildas
Nouvelles mises à jour avec divers correctifs avec les version 1.8.2
et 1.8.3 (j'ai pris un peu de retard sur le suivi)Merci pour le suivi. Je connaissais son aîné, mais je n'avais pas eu l'occasion de me pencher sur la fourche...
Je dirais que la différence entre gogs et gitea est que le projet est
plus actif et collectif
Dites-moi, si je comprends bien, la communauté Spip est en train de passer à Git et a choisi gitea ?
Non et oui. Depuis un moment il y a une volonté de migrer vers git. De
mon coté j'ai testé diverses forges et j'ai retenu gitea à force
d'essais infructueux.
Est ce qu'au final c'est gitea, github, gitlab, .... qui restera je
n'en ai aucune idée.
De mon coté je pousse gitea malgré ses imperfections car je trouve les
autres solutions inadaptées. Dans tous les cas je ne peux pas parler
au nom de la communauté.
Km
Bonjour
Nouvelles mises à jour de la forge git.spip.net avec la version 1.9.0
On peut noter les améliorations suivantes :
* le support de git-note (qui peut être intéressant pour afficher les notes svn)
* amélioration du moteur de recherche pour les commits avec de
nouveaux filtres (author:, committer:, after:, et before:)
* la possibilité d'importer des dépôts externe avec les tickets, les PR, ...
Il y a d'autres améliorations je vous invite à consulter le blog gitea :
https://blog.gitea.io/2019/07/gitea-1.9.0-is-released/
Km
Hello,
Dites-moi, si je comprends bien, la communauté Spip est en train de passer à Git et a choisi gitea ?
Non et oui. Depuis un moment il y a une volonté de migrer vers git. De
mon coté j’ai testé diverses forges et j’ai retenu gitea à force
d’essais infructueux.
Est ce qu’au final c’est gitea, github, gitlab, … qui restera je
n’en ai aucune idée.
De mon coté je pousse gitea malgré ses imperfections car je trouve les
autres solutions inadaptées. Dans tous les cas je ne peux pas parler
au nom de la communauté.
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 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 ?
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
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.
Yo,
Hello,
1/ Gitea vs autre choseIl faut commencer par dire que Camille a fait un boulot énorme sur la migration a GIT, et l’en remercier.
…
2/ Composer doncQui 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.
…
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.
Oui merci à Camille pour ce boulot énorme sur GIT et merci à toi Cédric pour résumer la situation.
A la lecture de ton résumé résoudre le 1/ n’est pas une montagne techniquement mais qu’il faut juste animer une vraie discussion qui débouche enfin sur une décision.
Si je comprends bien aussi un choix autre que GitHub pourrait ne pas être un frein au 2/ car on pourrait passer (au moins pendant un certain temps) par un mirroring Github qui résoudrait les problématiques packagist.
Donc il faut choisir entre Gitea, Gitlab et Github, je suppose qu’il est inutile d’envisager autre chose.
Peut-on faire faire une liste de critères à analyser pour alimenter la discussion ?
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
Bonjour
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.
J'ai oublié de préciser dans mon précédent courriel que les
contraintes du genre découpage ecrire, prive sont déjà opérationnelles
:
https://git.spip.net/SPIP/prive
https://git.spip.net/SPIP/ecrire
Donc il faut choisir entre Gitea, Gitlab et Github, je suppose qu'il est inutile d'envisager autre chose.
Peut-on faire faire une liste de critères à analyser pour alimenter la discussion ?
Pour partie ils vont être subjectifs difficile d'être factuel. Je vais
essayer de répondre à ces points, à d'autre de compléter pour avoir
une vision plus gloable
- performances serveur
go plus rapide que ruby
- facilité d'administration
équivalente (au finale peu utiliser une fois la configuration mise en place)
- ergonomie de l'interface git
gitea propose la personnalisation (cf l'ajout de la boussole)
- gestion des tickets
équivalent
possibilité de déleguer à un autre gestionnaire avec gitea (par
exemple spip est branché sur le redmine)
- open-source + ou -
gitea open source (+)
gitlab version mixte fermée (-)
- API, langage source
gitea respect de l'api github (objectif)
code gitea plus lisible que celui de gitlab (go vs ruby et ancienneté du code)
- intégration d'outils externes
Pour le cas de la CI je dirais que gitlab a de l'avance car ils ont
développé leurs propres outils gitlab-ci
Gitea réduit son écart avec drone.
A noter qu'en mode miroir on peut exploiter l'écosystème de github.
C'est par exemple le cas avec scrutinizer-ci qui est branche
Il est toujours possible d'utiliser jenkins, travis, ...
indifféremment avec les 2 forges
- ... ?
- Maintenabilité système
Gitea une binaire go à remplacer
Gitlab fournit un mode omnibus
Le mode omnibus est un paquet qui commun à toutes les distributions
linux. De fait il ne cherche pas à respecter l'arborescence propre à
un OS et met ses fichiers comme il l'entend.
De ce que j'ai suivi cela s'est amélioré mais c'est/c'était compliqué
ensuite à maintenir quand ça casse.
J'ai eu une très mauvaise expérience de ce point de vue avec gitlab.
- Montée de version
Gitea est très facile à mettre à jour,
Gitlab fournit un paquet boite noire
Km
James corrigera, mais je voudrais préciser un point qu'il nous semblait
avoir compris et exprimé ici ensuite.
## Composer et Packagist
Composer sait dialoguer avec plusieurs plateformes, mais par défaut SANS
CONFIGURATION à demander aux utilisateurs (sans rien ajouter dans des
json etc), il ne sait installé QUE ce qui est pris en charge par le
dépôt officiel de base Packagist.org, et ce dépôt reconnait tel quel que
DEUX choses : github.com et gitlab.com (pas LES Gitlab : juste
l'instance officielle).
Si on veut que dès le départ les gens puissent installer le noyau ET
n'importe quel plugin plus tard ou distributions (pour l'instant on
parle d'abord du core mais peu importe, ça vaut à long terme pour tout),
alors TOUS ces projets DEVRONT être :
- soit sur github.com
- soit sur gitlab.com
- point.
Ça parait important à clarifier.
## Miroir mon beau miroir
Ensuite il y a la question de maintenir plusieurs dépôts ou pas (un
principal et un miroir).
Moi aussi j'étais plutôt partant pour maintenir notre truc, et avoir un
miroir uniquement lecture sur Github. Mais après les débats lors de la
formation avec James, il en ressortait que :
1) On galère déjà à maintenir de nombreux outils, et nous sommes peu
nombreux (vraiment). Là une forge c'est un gros truc, de l'admin sys,
pas du SPIP (c'est pas comme maintenir Contrib, spip.net, etc). Et très
probablement ça sera sur les épaules d'UNE personne unique (parmi le
déjà peu qu'on est, il y a encore moins d'admin sys), allez deux pour
être gentil. Et quand il y aura un soucis, ça sera de nouveau difficile.
A-t-on vraiment besoin de maintenir 100% des choses ? Avec Git si jamais
il y a un soucis de droit, de coupure, etc, on peut toujours déplacer
ailleurs en très peu de temps !
2) A-t-on vraiment envie de gérer des PR *en plusieurs endroits* ? La
majorité des devs SPIP ont déjà un compte Github. Un des buts de
Composer et de s'insérer dans l'écosystème c'est d'inclure plus
facilement des nouvelles personnes. On ne se leurre pas, on va pas
attirer des milliers de gens, mais la majorité des quelques devs NON
CONNUS qui pourraient proposer des modifs, doivent avoir un compte
Github. Est-ce qu'on veut vraiment obliger les gens à créer un compte
sur notre forge à nous pour proposer des modifs ? (non) Et si on a des
PR en plusieurs endroits, ça va vite être très chiants à maintenir, à
savoir quoi et où relire à temps. Il semblerait mieux de tout
centraliser et de n'avoir qu'un seul lieu où proposer des modifs. Donc
Github.com.
## Votre ticket s'il vous plait
Là on parle du code. La question plus compliqué ce sont les tickets. Si
la forge principale est à nous (Gitea ou un Gitlab perso), la question
ne se pose pas trop, on migre tout dessus et basta.
Mais suivant les arguments précédents, je suis d'avis (et il me semble
qu'on était plusieurs après les explications de James) que ce serait
mieux d'avoir uniquement tout sur Github (se décharger, centraliser, et
inclure facilement quelques nouvelles personnes).
Et du coup là : si on passe nos tickets sur Github, est-ce qu'il est
facile de tous les exporter un jour pour les déplacer ailleurs si on
veut partir ? Si oui alors ok, pas plus de problème que pour le code
sous Git. Sinon il faut réfléchir.
## Nomenklatura
Quelque soit tout le reste et le choix du lieu, je suis d'avis avec
Camille qu'il faut au plus vite clôturer les questions de nommage, pour
le choix des 2 ou 3 organisations officielles de la communauté. Je pense
que c'est mieux de créer un autre fil de discussion pour ça, et qu'on
n'en parle plus.
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.
J'ai peur qu'on se retrouve soit avec des PR et des tickets des deux côtés, soit que ce ne soit pas compréhensible, et obligerait à avoir des comptes à plusieurs endroits.
Tickets et PR c'est quand même étroitement lié, pour moi ça devrait être centralisé.
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.
J'aimerais vraiment que James nous assiste sur ce coup là, pour éviter un piège qu'on ne verrait pas.
Ensuite il y a la question de maintenir plusieurs dépôts ou pas (un
principal et un miroir).Moi aussi j'étais plutôt partant pour maintenir notre truc, et avoir un
miroir uniquement lecture sur Github. Mais après les débats lors de la
formation avec James, il en ressortait que :1) On galère déjà à maintenir de nombreux outils, et nous sommes peu
nombreux (vraiment). Là une forge c'est un gros truc, de l'admin sys,
pas du SPIP (c'est pas comme maintenir Contrib, spip.net, etc). Et très
probablement ça sera sur les épaules d'UNE personne unique (parmi le
déjà peu qu'on est, il y a encore moins d'admin sys), allez deux pour
être gentil. Et quand il y aura un soucis, ça sera de nouveau difficile.
A-t-on vraiment besoin de maintenir 100% des choses ? Avec Git si jamais
il y a un soucis de droit, de coupure, etc, on peut toujours déplacer
ailleurs en très peu de temps !
Absolument +1
Sur Github/Gitlab, zéro maintenance, zéro coût pour nous.
2) A-t-on vraiment envie de gérer des PR *en plusieurs endroits* ? La
majorité des devs SPIP ont déjà un compte Github. Un des buts de
Composer et de s'insérer dans l'écosystème c'est d'inclure plus
facilement des nouvelles personnes. On ne se leurre pas, on va pas
attirer des milliers de gens, mais la majorité des quelques devs NON
CONNUS qui pourraient proposer des modifs, doivent avoir un compte
Github. Est-ce qu'on veut vraiment obliger les gens à créer un compte
sur notre forge à nous pour proposer des modifs ? (non) Et si on a des
PR en plusieurs endroits, ça va vite être très chiants à maintenir, à
savoir quoi et où relire à temps. Il semblerait mieux de tout
centraliser et de n'avoir qu'un seul lieu où proposer des modifs. Donc
Github.com.
Absolument +1 aussi pour la centralisation des PR, et tickets à un seul endroit, les deux sont liés.
Yop,
J’aimerais vraiment que James nous assiste sur ce coup là, pour éviter un piège qu’on ne verrait pas.
Tant qu’à “mettre les pieds dans le plat et appeler un chat un chat”,
la sporadique et évanescente “présence” de James n’est elle pas aussi un problème ?
Je ne suis pas sur du tout que ce soit le sujet du moment.
Cédric a bien expliqué qu’il y avait deux points à traiter même si ces deux points ont une intersection non nulle.
Il nous faut d’abord une forge Git.
Il y en a 3 possibles :
Quand on voit le thread actuel, les précédents, car il y en a déjà eu sur le même sujet avec les mêmes débats, on a l’impression qu’on en sortira jamais et que rien ne réconciliera les avis divergents. il y a des pros pour chaque solution, des réticents pour chaque solution et pas de solution miracle qui réconcilie tout le monde.
Donc je ne vois qu’une seule chose pour sortir de cette solution : lancer un sondage, définir un quorum, voter et ensuite accepter la décision et la mettre tous en place.
La solution est à mon avis dans le fait de jouer en équipe pour sortir de ce trou !
Donc êtes vous d’accord qu’on parte dans ce processus pour en finir avec ce pourrissement ?
Première proposition pour le sondage (pièce à casser bien sur) :
Salut
Sur les suggestions de question, pour la partie Github, je
reformulerai en "passer définitivement sur cette plateforme".
* Les options de bascule sont plus simple pour aller vers Github que
depuis Github. A mon sens il n'est pas pertinent d'avoir l'espoir d'en
revenir facilement.
* Pour la partie backup, c'est une sous question. Il faut aussi
identifier qui voudrait s'en occuper. Bien que très importante on
enlève une grande partie de l’intérêt à maintenir une forge
communautaire. En l'état à titre personnel cela ne m'intéresse pas de
faire ce service.
Concernant gitlab je ne suis pas sur que ce soit, comme tu le notes, à
considérer. Des personnes se sont exprimées pour dire l'apprécier mais
personne pour en faire le suivi. Donc cela risque d'être compliqué si
cette solution est retenue et qu'il n'y a personne pour le prendre en
charge.
Concernant gitea il ne faut pas oublier redmine, c'est lui qui
centralise les tickets. Gitea a cette option mais je ne l'ai pas
activé du fait de l'existant fonctionnel.
Autres points généraux :
* Le passage à github fera perdre l'historique vu que la numérotation
sera nouvelle.
* Les PR ne se résume pas à être valider par une interface graphique,
git propose de base la possibilité de gérer du multi source dont les
mails. Cela demande un peu de travail, mais dans la pratique c'est
rare d'utiliser le bouton valider si on fait une revue correcte du
code proposé.
* Pour les utilisateurs github, il est possible de se connecter à
gitea sans créer de compte, l'oauth est actif. Cela ne devrai pas
changer les pratiques de ces personnes qui utilisent les app (Ci/...)
de github.
* Même une fois le choix défini on aura toujours le problème de la nomenclature
Km
Hop,
Composer sait dialoguer avec plusieurs plateformes, mais par défaut SANS
CONFIGURATION à demander aux utilisateurs (sans rien ajouter dans des
json etc), il ne sait installé QUE ce qui est pris en charge par le
dépôt officiel de base Packagist.org, et ce dépôt reconnait tel quel que
DEUX choses : github.com et gitlab.com (pas LES Gitlab : juste
l'instance officielle).
Merci à Rasta de rappeler ce point qui pourtant était bien mis en avant dans l'article du blog à ce sujet :
https://blog.spip.net/Composer-et-SPIP-sont-dans-un-bateau.html
"Composer par défaut, sans autre configuration, utilise le site Packagist.org. Ce site, qui utilise l’outil libre Packagist, ne sait obtenir les sources avec les zips que depuis github.com ou gitlab.com (ces instances là précisément)."
"De la sorte, aucune configuration supplémentaire n’est nécessaire pour les utilisatrices ou utilisateurs. Mais cela implique de déposer les sources sur github.com ou gitlab.com."
J'ai peur qu'on se retrouve soit avec des PR et des tickets des deux côtés, soit que ce ne soit pas compréhensible, et obligerait à avoir des comptes à plusieurs endroits.
Tickets et PR c'est quand même étroitement lié, pour moi ça devrait être centralisé.
Même si je pense qu'une seule forge doit suffire, on peut très bien utiliser un miroir sur github sans y accepter les PR, ça se configure dans le repo de chaque projet du core et zou. Ainsi on évite le problème des PRs déposées dans plusieurs endroits.
Et du coup là : si on passe nos tickets sur Github, est-ce qu'il est
facile de tous les exporter un jour pour les déplacer ailleurs si on
veut partir ? Si oui alors ok, pas plus de problème que pour le code
sous Git. Sinon il faut réfléchir.
J'ai souvenir de discussions (certainement en off) à ce sujet, et "on" a déjà un plan pour ça : mise en place d'une instance gitlab perso (donc sur une des machines de la communauté), qui par le biais de l'API github ferait des "backups" réguliers des tickets pour les garder au chaud *chez nous*.
Salut
Sur les suggestions de question, pour la partie Github, je
reformulerai en "passer définitivement sur cette plateforme".
* Les options de bascule sont plus simple pour aller vers Github que
depuis Github. A mon sens il n'est pas pertinent d'avoir l'espoir d'en
revenir facilement.
Je ne crois pas, de ce que j'en ai lu, on peut très bien migrer un projet complet (code, tickets, wikis, etc) de github vers une instance gitlab.
* Pour la partie backup, c'est une sous question. Il faut aussi
identifier qui voudrait s'en occuper. Bien que très importante on
enlève une grande partie de l’intérêt à maintenir une forge
communautaire. En l'état à titre personnel cela ne m'intéresse pas de
faire ce service.
C'est noté
Concernant gitea il ne faut pas oublier redmine, c'est lui qui
centralise les tickets. Gitea a cette option mais je ne l'ai pas
activé du fait de l'existant fonctionnel.
Amha, redmine est appelé à disparaître, les tickets doivent être sur la forge principale, quelle qu'elle soit.
Autres points généraux :
* Le passage à github fera perdre l'historique vu que la numérotation
sera nouvelle.
L'historique de quoi ?
Si on parle des commits, le passage de svn à git "assure" déjà cette perte.
Si on parle des tickets, ça nous est déjà arrivé lors de la migration de trac vers redmine (de mémoire), et il y a peut-être des solutions pour mapper les numéros de tickets redmine VS git/hub/lab/tea, une recherche rapide permet de trouver ceci :
- https://github.com/IQSS/redmine2github & https://blogs.harvard.edu/rprasad/2014/07/10/moving-from-redmine-to-github-issues/
- utilisé par QGIS ici https://github.com/qgis/QGIS-Enhancement-Proposals/issues/141
* Les PR ne se résume pas à être valider par une interface graphique,
git propose de base la possibilité de gérer du multi source dont les
mails. Cela demande un peu de travail, mais dans la pratique c'est
rare d'utiliser le bouton valider si on fait une revue correcte du
code proposé.
Un des gros avantages des forges actuelles est justement de permettre aux gens de proposer des patchs en mode "clic & play", je doute fortement qu'on arrive à motiver les contributions et leur intégration par l'équipe si on passe par des patchs envoyés en pièces jointes dans des mails :\
Quant au bouton "valider", il est certainement plus utilisé que tu ne le crois, surtout quand le patch ne concerne qu'une coquille ou une pétouille. À propos de la revue de code, on a il me semble acté (ou au moins à moitié) qu'il serait bien que toutes les modifications (même celles des membres de l'équipe) passent par une PR ayant reçu au moins un ou deux "+1" des autres membres.
* Pour les utilisateurs github, il est possible de se connecter à
gitea sans créer de compte, l'oauth est actif. Cela ne devrai pas
changer les pratiques de ces personnes qui utilisent les app (Ci/...)
de github.
Oui, c'est ce que j'allais rappeler, merci de l'avoir fait
* Même une fois le choix défini on aura toujours le problème de la nomenclature
Sur ce point, on a déjà https://github.com/spip/ qu'on peut "affiner" s'il le faut avec la mention "core" & https://github.com/spip-zone
zoubis tout plein
PS digression : on fait du cross post là, on avait pas dit qu'on ne gardait qu'une seule liste entre dev et zone ?