Re: Gouvernance/mandat du projet git

Salut

> > 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é. :(

Et oui c'est ainsi :)

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

En partie faux. La méthode url de Composer est partiellement codé en
dur. Ce qui fait que par défaut une forge respectant l'api mais pas sa
numérotation de version coince.
Cela est corrigeable par une redirection dans la config serveur de la
dite forge.
Gitea respecte l'api github. Il est donc possible de corriger ceci sur
une instance gitea pour être compatible sur le chemin sans avoir à
modifier composer.


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

Noté

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

Priorité de qui ?

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

Une fois que ce sera migré il n'y aura pas de retour arrière. La
communauté a une grosse inertie et vu les expériences passées (dont
trac/redmine), une fois sur github cela ne bougera pas.
Donc  j'affirme que c'est faux :) Cela ne bougera pas/plus par la suite.

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

Si cela est en rapport. La communauté spip proposait un dépôt
collaboratif commun (soit en svn) et les projets migrent sur des
instances différentes (github/bitbucket/forge interne, ....) dans les
quelles on oublie l'aspect pot pourri commun.

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

En plus de git.spip.net , il y a :
http://github.com/spip-zone/
http://github.com/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.

Sur ce point github ne permettra pas par défaut d'offrir ce
comportement. Pour avoir un droit commun sur l'ensemble d'une
organisation il faut donner manuellement des autorisations.

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

"auraient pu". Il n'y a aucune obligation et heureusement :)

> Sauf que ce dépôt commun n'existe pas
> encore.)

Faux comme indiqué juste avant. Mais je pense que c'est un problème
d'appréciation sur ce qu'on peut ou pas faire à l'heure actuelle.
Le dépôt git commun existe bien, même si on n'a toujours pas défini
divers aspects d'organisation.


Km