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