Re: Mise à jour git.spip.net

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, [email protected] 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
----
[email protected] - https://listes.rezo.net/mailman/listinfo/spip-zone