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é 
Je me demandais un truc d’ailleurs : le fait de les archiver sous Gitlab ne changerait rien sur leur présence sur Plugins SPIP ?
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.
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.
Je checkerai le débardeur aussi alors.
paquet.xml dans la branche par défaut
SPIP4.0 maxplugin.xml 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 :
SPIP4.1 max,SPIP4.* etLe 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
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…
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…).
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.
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 !
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.
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.
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.
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 
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.
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 » ?
Données ajustées en date du 24 mai 2024 (hier soir)
Dans ce tableau, le nombre de plugins avec une borne de compatibilité SPIP max avec une version SPIP maintenue ou en developpement
| borne max | nombre du plugins maintenus |
|---|---|
| 4.* | 563 (+2) |
| 4.1.* | 74 |
| 5.* | 22 |
| Total | 659 |
4.*, c’est la somme des bornes 4.2.*, 4.3.*, 4.*.* et 4.*,4.1.*, comme son nom l’indique,5.*, c’est la somme des bornes 5.0.*, 5.* …Je ne conserve que 2 dates :
| critère | date | plugins avec au moins un commit depuis cette date | plugins éligibles à l’archivage |
|---|---|---|---|
| fin de vie de SPIP3.1 et release SPIP4.0 | 2021-07-09 | 734 | 551 |
| fin de vie de SPIP3.2 et SPIP4.0 et release SPIP4.2 | 2023-02-23 | 603 | 682 |
Tous plugins dont la borne max est 4.*, 4.2.*, 4.*.*, 4.3.*, 4.1.* ou 5.* sont considérés comme maintenus
puisque compatibles avec des versions SPIP maintenues.
| borne max | nombre du plugins éligibles à l’archivage | pas de commit depuis le 2021-07-09
|
pas de commit depuis le 2023-02-23
|
|---|---|---|---|
| (vide) ou * | 54 | 49 | 50 |
| 1.9.2 | 1 | 1 | 1 |
| 2.0.* | 3 | 3 | 3 |
| 2.1.* | 19 | 18 | 19 |
| 3.0.* | 183 | 178 | 182 |
| 3.1.* | 91 | 87 | 90 |
| 3.2.* | 209 (-2) | 184 | 203 |
| 3.3.* | 14 | N/A | 0 |
| 4.0.* | 52 | 17 | 49 |
| Total | 626 | 537 | 597 |
Conclusion, y a moins de 600 plugins à archiver selon la date qu’on choisit, autant prendre la plus récente, qui se rapproche de la proposition de @cerdic
À noter :
quand on compare, on observe que :
spip-contrib-extensions, spip-contrib-squelettes, spip-contrib-themes spip-galaxie et spip-grenier.Si personne n’y voit d’inconvénient, archivage dans la soirée des 600 plugins qui répondent aux critères (dernier commit avant le e23 février 2023 sur des branches non-maintenues)