Archivage git des projets sans activité depuis un moment

Dev
#1

Hello,

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

Des avis ?

Bornes max des plugins compat 4.2
#2

Hello,

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.

1 « J'aime »
#3

J’étais au courant, j’ai épluché ces tableaux pendant quelques heures :slight_smile:
Merci en tout cas de rappeler leur existence :wink:

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é)

#4

Ouais absolument je suis d’accord.
Je te donnais la page pour justement faciliter la détection mais a priori tu avais déjà trouvé :wink:

Je me demandais un truc d’ailleurs : le fait de les archiver sous Gitlab ne changerait rien sur leur présence sur Plugins SPIP ?

#5

Faut que je regarde comment tu t’y prends. Mais le but est bien qu’ils soient conservés sur Plugins SPIP, bien sûr.

Je comptais checker ça avant toute action, de toute façon.

#6

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.

#7

Je checkerai le débardeur aussi alors. :wink:

#8
  • 1598 projets git, tous groupes publics, internes ou privés confondus
  • 210 projets « persos », privés, internes ou déjà archivés
  • 1388 projets publics et non-archivés
    • 1082 paquet.xml dans la branche par défaut
      • 405 plugins compatibles jusqu’à SPIP4.0 max
    • 288 plugin.xml dans la branche par défaut
      • 85 avec les 2 fichiers présents dans la branche par défaut

Ça ferait 607 projets git archivables.

J’ajoute que ça fait aussi 678 plugins effectivement maintenus (SPIP4.1 ou plus) dont :

  • 116 compatibles SPIP4.1 max,
  • 545 pouvant être mis à jour pour être compatibles SPIP4.* et
  • 17 déjà mis à jour (à la mimine).
#9

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.

#10

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 ?
1 « J'aime »
#11

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…

#12

Hello,

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…).

#13

Bonjour

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.

#14

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 !

#15

Hello

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.

#16

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.

#17

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 :slight_smile:

#18

Bonjour

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.

#19

See Archivage git des projets sans activité depuis un moment - #9 par JamesRezo

#20

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 » ?