Hop,

Le 07/08/2019 à 16:21, RastaPopoulos a écrit :

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


Le 08/08/2019 à 14:45, nicod_ a écrit :
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.

Le 07/08/2019 à 16:21, RastaPopoulos a écrit :
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*.

Le 08/08/2019 à 17:53, cam.la...@azerttyu.net a écrit :
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 ?

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

Répondre à