Re: Mise à jour git.spip.net

Pour faire avancer le schmilblick (ou pas), je note quand même ici pour les records que techniquement, seul le paquet principal root spip/spip a besoin d’être sur Packagist.org et donc sur github
Car il peut ensuite déclarer le dépot https://packages.spip.net sur lequel on retrouvera tout SPIP et la zone et tuti quanti
https://getcomposer.org/doc/04-schema.md#repositories

Ça veut donc dire qu’on peut très bien avoir notre git et mirorer simplement spip/spip sur github, ce qui n’est pas la mort
Après la question est donc de ce qu’on veut faire, de ce qu’on a l’energie de faire, de si on préfère se faire hoster par le grand capital-que-quand-même-finalement-ils-sont-gentils on si on a encore un petit peu d’idéaux etc…

(ou alors j’ai pas bon ?)

Des bises en tout cas
(c’est le seul truc qui marche encore un peu)

--
Cédric
Le 9 août 2019 à 02:09 +0200, Bruno Bergot <[email protected]>, a écrit :
> 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

----
[email protected] - https://listes.rezo.net/mailman/listinfo/spip-zone