Re: traductions.txt vs package/composer.json et git.spip.net

Ah oui mais alors dans ce cas il faut qu’on garde un fichier archivelist manuel quelque part pour déclarer les projets en dehors de git.spip.net
Donc on ferait un mix :
 - pour les projets de git.spip.net il suffit de le déclarer dans le repo selon format à préciser
 - pour les autres projets on a un archivelist

Donc on revient quand même à faire un projet archivelist sur git.spip.net, on y migre le fichier actuel, et quand la feature par repo sera fonctionnelle on pourra le cleaner.
Ça semble le plus robuste

Et on met le projet dans https://git.spip.net/spip-contrib-outils puisque ça sera transversal

--
Cédric
Le 31 janv. 2020 à 11:00 +0100, Bruno Bergot <[email protected]>, a écrit :
> Hop,
>
> Le 31/01/2020 à 10:51, Cerdic a écrit :
> >
> > Je pense aux repos persos.
> >
> > Exemple concret : si je ramène bank sur git.spip.net, pour autant je veux garder la main sur les commits et que les contributions soient en mode PR uniquement, donc pas le mettre dans spip-contrib-extensions.
> >
>
> Autre plan, tu peux laisser bank où il est et demander à salvatore de
> commiter sur github, c'est ce qu'on fait déjà pour geodiv et seenthis cf :
>
> https://zone.spip.net/trac/spip-zone/browser/spip-zone/traductions.txt#L1315
>
> Salvatore a un compte sur github, il suffit de l'ajouter à la liste des
> commiters du repo ou de l'organisation.
>
> > Dans ce cas est-ce qu’il faudra autoriser salvatore au cas par cas, ou est-ce qu'il est possible de lui donner un droit universel sur *tous* les repos ?
> >
>
> Amha oui ça semble logique (espérons que ça soit possible), si le code
> est sur la zone salvatore doit pouvoir commiter dessus.
>
> ++
> b_b