Re: Gouvernance/mandat du projet git

Le 30/04/2019 à 15:25, [email protected] a écrit :
> Bon je vois que la question ne soulève aucun intérêt pratique malgré
> toutes les prises de becs/discussion/interrogation/négociations/... de
> ces derniers mois.

Je pense que les gens qui ont manifesté de l'intérêt pour travailler sur
Composer et Git le sont toujours mais il y a eu plusieurs événements
depuis. Des trucs persos qui ont un moment éloigné de l'ordi pour
certains, et aussi le projet de refonte de Contrib qui prend du temps et
de l'énergie à une partie des gens qui s'y sont lancés. C'est difficile
d'être sur plusieurs chantiers à la fois, désolé. :(

> La tendance est de migrer ses projets personnels sur github sans autre
> forme de procès.
> 
> On peut donc oublier cette proposition.

Après la formation sur Composer, il a été très clairement expliqué que
Packagist.org (l'installation par défaut officielle reconnue
automatiquement par la commande Composer) ne sait reconnaitre QUE
github.com et gitlab.com par défaut, sans demander aux gens de
configurer des choses en plus.

Il a donc été décidé que tant que Packagist.org fonctionne comme cela
(on peut imaginer qu'un jour il sache détecter sans aucune config
n'importe quelle installation de gitlab, mais ce n'est pas le cas), le
noyau et la nouvelle zone en Git irait sur Github.

Je peux dire ça d'autant plus que je faisais parti de ceux qui étaient
le plus opposé à faire cela, et avoir notre propre installation. Mais
les explications sur Composer étaient très claire et m'ont bien fait
comprendre que la priorité ça va avant tout être de faciliter la
maintenance et l'utilisation de Composer.

Si un jour Packagist.org permet plus de choses facilement, tant mieux,
et on pourra alors décider si on remigre sur un truc à nous, Git le
permet facilement. (La question principale n'était pas un problème du
code source, mais des tickets à bien pouvoir récupérer et remettre
ailleurs.)

Pour ce qui est de passer sur des dépôts *perso* de Github (comme c'est
le cas pour des trucs de Romy aujourd'hui) c'est un tout autre problème
qui n'a rien à voir.

Mais un peu quand même. Car il se trouve qu'avec ces retards, nous
n'avons toujours pas terminé la Nomemklatura, et la décision finale des
deux ou trois noms d'organisations à maintenir sur Github pour la
communauté SPIP.

On doit *absolument* finaliser ça, ce qui permettra déjà d'avoir de
nouveau un système *commun* de maintenance de plugins à plusieurs, avec
pour tout le monde les mêmes droits comme pour le SVN. (Et donc
normalement les plugins de Romy auraient dû être déplacés sur ce dépôt
commun si le but c'est toujours d'être dans un fonctionnement
démocratique et non pas libéral. Sauf que ce dépôt commun n'existe pas
encore.)

-- 
RastaPopoulos