Re: Composer, Packagist, gitea, gitlab et github sont dans un bateau

Le 22/10/2019 à 13:20, [email protected] a écrit :
>> Oui, sauf que tous les plugins (zone) ne sont pas sur gitea
>> actuellement, loin de là.
> 
> Oui de mémoire on doit dans l'équivalent de 1700 dépots à traduire.

Ça fait beaucoup. Tu comptes l'intégralité de la zone ?

>> Ils y sont ajoutés à la main par camille ou tcharlss je crois, selon les
>> besoins.
> 
> C'est documenté sur https://git.spip.net/contrib/importToGitea
> La zone manquant de structure cohérente, la traduction se fait sur la
> base de modèle. Cela permet d'indiquer comment un répertoire dans le
> svn sera traduit. (présence de master, tags, branches). C'est ainsi
> qu'on peut traiter des cas simple comme  "trunk", ou bien "trunk/,
> branches/, tags/" et enfin les cas complexes des plugins-dists
> Je crois qu'on couvre les différents cas type et qu'on peut traiter la
> zone dans sa grande majorité.

Ok je comprends, c'est ce qu'on retrouve donc dans saisies avec les 
branches git master, v1 et v2 en fonction des répertoires svn.

> Pou le moment je préfères que ce soit traité encore à la main pour :
> * être sur qu'on couvre bien tous les cas
> * gérer les ressources du serveur (pour le moment il est sous dimensionné)

Si on décide de passer sur Gitea, il faudra qu'il le soit (c'est un peu 
lent parfois, en ce moment).
Est ce que Gitea peut gérer autant de projets ? il y a des retours là 
dessus ?

>> Et je ne sais pas (c'est une de mes questions justement) s'il est prévu
>> qu'il y ait effectivement une synchro totale à un moment, et si Gitea
>> est capable de gérer tous ça.
> 
> Comme je l'ai déjà indiqué le principal problème n'est pas de savoir
> si c'est possible, il me semble qu'on a la preuve que si. Et faire une
> boucle d'un svn ls pour un traitement massif me semble assez facile à
> faire vu tout le reste.
> Le problème est organisationnel, entre autre comment ranger l'ensemble
> ? Il y a une discussion sur ce point qui n'est pas encore stable (je
> ne pense pas qu'on pourra la finaliser, il est probable que cela doive
> évoluer dans le temps). Pour le moment l'organisation sur git.spip.net
> est un compromis arbitraire du moment de ce qui a été discuté.

Merci pour ces précisions.

De ce que j'en comprends, on pourrait au moins automatiser un import de 
_plugins_ non ?

Pour les autres, il faut en discuter oui, et est ce qu'il faut tout 
importer ?
grenier, acotes, contribs, doc, graphismes, qui ne bougent plus du tout, 
on peut en laisser certains sur svn

Par contre, ce paragraphe m'interpelle :

> Subgit permet de gérer la synchronisation dans les 2 sens. Toutefois il faut prendre en compte qu’il est préférable de considérer un seul dépot de référence, le second étant un miroir. Pour les personnes ayant demandé la mise en place de cette fonctionnalité, il est fortement conseillé d’indiquer dans les informations du projet si celui ci priviligie git ou svn. Le chapitre suivant peut être pris comme base et amélioré.

Ça me parait assez casse gueule de gérer au cas par cas.
Est ce qu'on ne pourrait pas décider qu'à un moment, c'est le dépôt git 
qui fait référence *dans tous les cas*, à partir du moment ou il existe ?
Ce serait une règle beaucoup plus simple et claire pour tout le monde.


-- 
nicod_
_______________________________________________
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip