Re: Proposition pour la génération de archivelist

Hello,



Le mar. 3 mars 2020 à 18:14, Cerdic <[email protected]> a écrit :

> Plus personne n’a envie de faire du bash ! :p
> En php cli c’est très bien, c’est le langage qu’on partage tous…
>

Oui pour le PHP.
Avec le cli je n'ai jamais utilisé mais c'est surement très bien.


>
> Mais comme je te le disais, je sais que @marcimat a commencé à regarder, a
> avancé, mais je ne sais pas où ça en est.
> Et là il est en vacances, amha tu ferais mieux d’attendre qu’il revienne
> pour avoir son feedback
>

Oui il faut en parler avec Matthieu.
Ca nous fera une bonne base de départ.
Je crois qu'il est parti de Satis ou un truc dans ce genre.


>
> Déjà ta convention de départ est sujette à discussion : je pense au
> contraire qu’en git le tag est l’outil indispensable pour signaler un
> package à versionner.
>
C’est la convention que tout le monde utilise, et il me semble qu’on ferait
> beaucoup mieux d'y coller que de continuer à perpétuer des zip sans numéros
> de version correspondant à des branches qui bougent.
> A voir si le trunk doit faire exception...
>
>
Oui je pense finalement qu'il vaut mieux partir de cette hypothèse.
Le trunk on en a besoin en développement et qui dit développement dit git
pas zip.



> 1 question subsidiaire :
> je ne sais pas si ça va remplacer d’un coup l’archiveur svn - peut-être
> cela dit : l’archiveur svn de la zone ne produira plus que des zips pour un
> dépot legacy
>
>
Coté SVN avec SP on peut avoir tous les dépôts logiques qu'on veut.
Donc on pourra garder un dépôt "legacy" généré par SP.


> Et une considération pas du tout subsidiaire :
> la performance (temps pour passer sur tous les repos et charge serveur
> associée) est LE principal problème du générateur de paquets
> ok ici on fait pas les zips, mais a priori il faudra dézipper ou cloner
> chaque repo, ou récupérer le xml et l’icone en http, donc il faut le
> prendre en compte dès le début et concevoir tout en pensant à ce problème,
> vu qu’on est quand même sur un ordre de grandeur du millier de paquets
>

C'est encore plus compliqué car il faut aussi parser les traductions.
Donc ça fait pas mal de fichiers et ça on ne pourra pas s'en passer car ça
nous permet de construire le référentiel des plugins indépendamment de
l'outil d'installation automatique.



> Le gros avantage des tags c’est que ça bouge pas : une fois qu’on a traité
> un tag c’est pour toujours - ad vitam - c’est pour ça que tout le monde
> fait ça.
> Il n’y a qu’a traiter les nouveaux tags à chaque itération
>
> Alors qu’une branche (trunk ou pas), ça suppose d’aller voir son dernier
> commit et de refaire le boulot à chaque fois qu’il y a eu un commit dessus,
> alors même qu’il y a pas forcément volonté du développeur de mettre à jour
> le paquet avec ce zip.
>

+1

++
Eric