Il est possible d’archiver des dépôts git sur notre plate-forme. Cela reviens à « geler » en lecture seule des projets, sans rien supprimer. Ni commits, ni issues, ni PRs.
Cela peut avoir plusieurs avantages :
évidement, cela permettrait de mieux identifier les projets actifs
pour des opérations de traitement en masse (ex: mise à jour de compatibilité spip), cela permettrait de filtrer les projets et de gagner en efficacité
ce n’est pas une fatalité, un·e mainteneureuse peut à tout moment rétablir un projet archivé
avec cet état, l’exploiitation de l’API REST de GitLab permettrait d’automatiser des opérations d’archivage sur les sites plugins.spip et contrib.spip
Un premier critère pourrait être la borne max de compatibilité des plugins: si elle est inférieure à 4.1, on archive
Pour ton info, il existe une page sur Plugins SPIP qui retrace ce que j’ai appelé les plugins perdus en route. Elle identifie les plugins qui ne sont plus à jour version après version et remonte même la comparaison à SPIP 3 : Plugins SPIP
Ca doit pouvoir aider pour détecter aussi ces plugins possiblement archivables. On voit d’ailleurs qu’on en a perdu en route depuis très longtemps et ceux-là seraient surement prioritaires à l’archivage.
J’étais au courant, j’ai épluché ces tableaux pendant quelques heures
Merci en tout cas de rappeler leur existence
Le système que tu as mis en place a une granularité beaucoup plus fine (à la branche près, peut-être au tag près ?) que ce que je propose et à ce titre, ça reste pertinent, bien sûr.
Ma proposition est complémentaire: Un dépôt git archivé pourrait ne plus être pris en compte par ton système (et serait, de fait, plus rapide à chaque fois qu’il est exécuté)
Je ne sais pas si le débardeur ne vire pas les zips si le dépôt est archivé. Parfois, on peut être amené à restaurer complètement la base et si le XML ne comprend plus les zips des plugins archivés alors on aura une liste moins-disante.
Le débardeur ne prend pas en compte l’attribut d’archivage de GitLab. Et, sauf erreur de ma part, il n’y a pas d’option de purge ou d’opération de nettoyage du référentiel qu’il produit.
En conséquence, ce qui a été « débardé » avant qu’un projet ne soit archivé ne sera pas effacé et devrait donc toujours être présent sur Plugins SPIP.
Je suis assez d’accord pour archiver également ce qui ne semble plus maintenu, ce qui permettra d’alléger un peu la liste des plugins par défaut montrés sur le Gitlab.
Je serai d’avis d’y aller plus progressivement en n’archivant pas pour le moment les plugins qui ont 4.0 max actuellement, et donc
archiver tout ce qui a SPIP <= 3.2 maxi
ET n’a pas eu de modifications du code récemment ?
Oui je pense que c’est une bonne idée de pas archiver ceux qui ont eu un commit dans les 12 dernier mois par exemple, car il y a encore des vieux tromblons dans la nature et on est parfois obligé de faire du fix legacy.
On désarchivera si nécessaire au cas par cas, mais comme il est quand même un peu plus difficile de trouver un projet archivé dans le git et que le désarchivage n’est il me semble pas permis à tout le monde je pense qu’il faut y aller prudemment et progressivement…
J’ai regardé ça et sur 1388 projets publics et non-archivés, il y a 829 projets sans commit depuis 1 an.
Sur cette base, la communauté ne maintiendrait plus « que » 559 projets (plugin ou pas plugin) soit 40.2% de ce qui a été produit depuis la création de la zone.
Ok pour la prudence, bien sûr, et donc, je vais vous fournir (dans quelques heures) un petit tableau récapitulatif par borne max de compatibilité (quand il y en a une…).
Je ne suis pas convaincu pour ma part de cette nouvelle politique.
Un projet archivé indique que les personnes à l’initiative du dépôt cessent de travailler dessus, cela ne présuppose pas de l’inutilité du projet.
De plus si une personne souhaite désarchiver la procédure n’est pas intuitive, les contributions du dimanches passeront la main et n’ajouteront pas la virgule qui pourraient manquer.
Un archivage a un message assez fort dans l’accès au projet.
C’est une question de bien doser les paramètres pour appliquer ce statut effectivement… mais je t’assure qu’il y a pas mal de vieux plugins que personne ne mettra à jour et qui encombrent un peu les listes. Personne ne s’occupera du plugin CFG, qui a pourtant bien servi à une époque…
On peut faire dans un premier temps <= SPIP 3.1, ou plus ancien si besoin, mais il y a des raisons évidentes pour lesquelles certains plugins n’ont pas été mis à jour sur des versions de SPIP plus récentes également !
C’est comme je dis, l’approche automatique me semble une mauvaise approche. Quand on archive c’est qu’il y a un raison explicite.
Le cas que tu cites avec CFG est un exemple motivé, la fonctionnalité étant intégrée dans le core. De plus les personnes ayant contribué sur ce plugin sont à même de gérer l’archivage.
Il y a probablement d’autres cas comme tu cites mais ce n’est pas une date, ou une limite de compatibilité qui permet de les identifier explicitement.
L’archivage reste un acte fort dans la vie d’un dépôt et dans la manière dont on permet les contributions.
Donc, sur 1388 projets, on a 1370 fichiers xml paquet et/ou plugin dont 85 projets qui ont les 2.
ça fait 1285 plugins sur la plate-forme GitLab.
Répartition par date
J’ai fait le test avec plusieurs dates :
Critère
Date
Plugins avec au moins un commit depuis
Plugins archivables
fin de vie de SPIP2.0
2016-01-06
1257
28
fin de vie de SPIP2.1
2017-10-17
1109
176
fin de vie de SPIP3.0
2019-06-30
962
323
fin de vie de SPIP3.1 et release SPIP4.0
2021-07-09
733
552
il y a 2 ans
2022-05-21
672
613
il y a 18 mois
2022-11-21
620
665
fin de vie de SPIP3.2 et SPIP4.0
2023-02-23
601
684
il y a 1 an
2023-05-21
531
754
La dernière colonne est à prendre comme une hypothèse.
Répartition par borne max de compatibilité avec SPIP
Ici, j’ai parsé tous les fichiers xml de manière auto, corrigé de même quand c’était possible.
Il y a 50 fichiers (des plugin.xml essentiellement) que je vais éplucher à la main …
Mais si on en croit la borne max (soit l’attribut compatibilite, soit la balise <necessite id='spip' ...> ou <necessite id='SPIP' ...>, ça donne la répartition suivante. Et j’ai fait des sous-totaux sur la base des versions maaintenues/non-maintenues de SPIP, pour avoir un ordre d’idée :
borne max
nombre du plugins
(vide)
50
1.9.2
1
2.0.*
3
2.1.*
19
3.0.*
183
3.1.*
91
3.2.*
211
3.3.*
14
4.0.*
52
574
*
4
4.*
561
4.1.*
74
5.*
22
661
Total
1285
4.*, c’est la somme des bornes 4.2.*, 4.3.*, 4.*.* et 4.*
5.*, c’est la somme des bornes 5.0.*, 5.* …
Je ferai un tableau qui mixe les 2 critères un peu plus tard.
Merci pour les stats, si on prend la borne <= SPIP 3.1 comme le proposait @marcimat ça nous permettrait déjà d’archiver 552 plugins d’après ton premier tableau, ça me semble une bonne première étape
Pour information quel impact aura l’archivage sur SVP et plugins.spip.net ?
Il serait bon de laisser quand même les personnes de pouvoir utiliser les plugins malgré tout, me semble t il.
vu
toutefois @JamesRezo émet une hypothèse non confirmée
Si ce n’est pas le cas est ce qu’il est prévu de les restaurer ? ou cela entrera dans la catégorie du « bah tant pis, c’est comme ça » ?
