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

Oui, je comptais attendre de toute manière l'avis de Marcimat :) 
J'ignorais juste qu'il était en vacances. De même je compte attendre 
l'avis d'Eric.

Allons pour le PHP cli (j'ai jamais fait, mais je vais apprendre).

Concernant le tag : effectivement je suis d'accords que c'est plus 
propre. Mais comment détermine-t-on alors quel tags doit fournir 
archivelist.xml ? On va pas fournir tout les tags de tout les plugins non ?

Ou bien on considère qu'on fournit pour chaque numero de x?
genre v1.3.4 mais pas v1.3.2, ainsi que v2.2.0 mais pas v2.1.9 ?

Concernant les perfs, effectivement le système de tag est sans doute 
meilleurs. A priori je pensais récupérer paquet.xml et image en http, 
via l'API.

Concernant le svn actuel
1. Je serais d'avis de le garder pour un dpot legacy pendant quelque temps
2. Et effectivement remplacer l'existant par "on part depuis git, depuis 
paque.xml"





Le 03/03/2020 à 18:14, Cerdic a écrit :
> Hello,
> 
> 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…
> 
> 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
> 
> 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...
> 
> 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
> 
> 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
> 
> 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.
> 
> -- 
> Cédric