Ecosystème d'une version SPIP

Hop,

Non, rien c’est vrai, sauf peut-être le manque de temps, je crois que tu sais ce que c’est :slight_smile:

Plus sérieusement, ça a été fait pour contrib et spip.net, ce qui est déjà pas mal d’un point vue usage, car ces deux sites sont certainement les plus utilisés par la communauté d’un point de vue rédaction. On peut forcément faire mieux, mais pour ça il faudrait que plus de personnes de l’équipe lèvent la main pour signaler leur envie de participer.

Complètement d’accord pour les plugins utilisés par les sites de la galaxie, cf Tournée de plugins à marquer comme compat 4.1

Par contre moyen chaud pour « les plus utilisés ». Le faire à l’arrache (et si c’est pas fait à l’arrahc qui va s’occuper des tests ?) risque d’entraîner des expériences pas très sympas pour les admins des sites qui les utiliseront, et surtout du support à assurer pour les personnes qui maintiennent ces plugins. Amha c’est à elle de le faire, quand elles pensent que le plugin a suffisamment été testé.

Anecdote perso, le dernier projet sur lequel je bosse a été lancé sur une 4.0 forcément, et ça ne me demandera pas grand chose de le passer en 4.1, et en faisant je pourrai justement tester des plugins et indiquer à leurs auteurs qu’ils fonctionnent en 4.1.

Pas majeures non (ça c’est un saut de version X), c’est bien des versions mineures (saut de Y).

Amha ça n’est pas le même problème ou la même question, cf mise à jour VS création/lancement d’un site. On sait très bien qu’on a une communauté qui a tendance a garder ses sites dans la versions pour laquelle il a été lancé, avec au min des mise à jour de patch (saut de Z).

L’autre partie des gens, c’est les personnes qui lancent de nouveaux sites, et c’est certainement de ce côté qu’on devrait plus communiquer (même si on le fait déjà pas mal) sur la possibilité de déverrouiller la compat max avec le define qui va bien. Ainsi on aurait plus de retours à propos des plugins, et surtout des retours plus sereins que quelqu’un qui panique parce que sont site en prod est pété suite à un passage de 3.2 à 4.1 en mode yolo ou par erreur à cause d’une bourde avec spip_loader ^^

Je n’arrive toujours pas à partager ce constat, et s’il est avéré j’en suis bien attristé.

Je ne souhaite pas donner de « leçon » aux pros (on est bien dans ce domaine là ?), mais ça n’est pas « juste pour rien » que ces sites doivent être mis à jour, ça leur assure une pérennité et certainement moins de mauvaises surprises (et donc des gain de coût) par rapport à un site n’évolue que par « gros paquet » tous les 5 ou 10 ans.

Et oui, on se rejoint, ça n’est pas le même type de chantier, mais les premiers ouvrent la voie aux seconds :slight_smile:

Payer, payer, payer, tout ne se fait pour ça hein ^^ Et puis pour la 3.2, ça sera bientôt réglé, à moins qu’il y ait un nouvel élan de volonté collective dans le core (ou la communauté) pour maintenir cette version en vie :smiley:

Vi, c’est pas le top, mais c’est loin d’être nul (j’insiste là dessus car on est toujours très doué⋅es pour nous auto flageller), non on n’avance pas dans le vide, et re oui il faut aider les personnes qui maintiennent des plugins en les testant, puis en leur remontant les bugs ou juste le fait que ça fonctionne.

Concernant la mise en place de « barrière » ou de seuil à atteindre avant de release, pourquoi pas, mais uniquement pour les plugins utilisés par les sites de la galaxie. Si cela devait concerné les plus utilisés, il faudrait déjà que suffisamment de personnes se déclarent disponibles pour les tester.

À ce sujet, je pense qu’il important qu’on lance une discussion pour qu’on fasse un état des lieux des motivations, disponibilités et surtout des envies des personnes du core. Sans ça, les quelques personnes qui tiennent SPIP (à bout de bras?) risquent de s"épuiser, d’attendre des gens, etc… alors que d’autres n’ont juste pas le temps ou l’envie et peut-être même culpabilisent de ne pas pouvoir donner assez :\

il n’y a rien qui empêche de mettre à jour les sites de la galaxie

Non, rien c’est vrai, sauf peut-être le manque de temps, je crois que tu sais ce que c’est :slight_smile:

Tu coupes un peu l’idée :stuck_out_tongue: qui était de parler de l’ordre (donc pour ce point sans travail vraiment en plus), càd que les sites officiels sont bien mis à jour à la dernière version à un moment, mais du coup s’assurer que dans la todolist ça soit fait avant de publier l’annonce finale.

C’est de l’amélioration continue par rapport à un premier bilan et aux retours des utilisateurices qu’il y a pu y avoir. C’est :

  • faire plaisir aux devs qui veulent avancer en gardant ce rythme, c’est-à-dire renforcer le principe de freezer le contenu à un moment défini (ce que je plussoie totalement), ce qui force à de pas repousser réellement la release car choses en plus à tester, etc
  • mais faire attention à pas décontenancer les utilisateurices en ne lançant pas la toute dernière étape (paquet et annonce sur sites) tant que ya pas une première salve de plugins validés

Par contre moyen chaud pour « les plus utilisés ». Le faire à l’arrache (et si c’est pas fait à l’arrahc qui va s’occuper des tests ?) risque d’entraîner des expériences pas très sympas pour les admins des sites qui les utiliseront, et surtout du support à assurer pour les personnes qui maintiennent ces plugins. Amha c’est à elle de le faire, quand elles pensent que le plugin a suffisamment été testé.

Oui oui… ce qu’on décide d’être à valider avant, j’ai bien dit c’est « à débattre » :slight_smile:

Pas majeures non (ça c’est un saut de version X), c’est bien des versions mineures (saut de Y).

Version mineure c’est plus Z pour moi. Je disais majeure dans le sens grosse version quand même : ya des ajouts fonctionnels (Y) et parfois un peu de cassure/dépréciation. Et en premier lieu des plugins qui se désactivent car pas compat (ce qui n’arrive jamais avec Z, c’est la différence la plus évidente).

Du côté utilisateurices, enfin proprios de sites, une version de SPIP qui n’a aucun plugin disponibles, n’a rigoureusement aucun intérêt et ne permet pas du tout de lancer une mise à jour

Amha ça n’est pas le même problème ou la même question, cf mise à jour VS création/lancement d’un site. On sait très bien qu’on a une communauté qui a tendance a garder ses sites dans la versions pour laquelle il a été lancé, avec au min des mise à jour de patch (saut de Z).

Pas le même problème que quoi ?
Il me semble bien que c’est lié, pourquoi ne font-ils pas les mises à jour Y aussi ? Peut-être faut se poser ces questions aussi… C’est pas propre à notre communauté, c’est pareil pour un site en Drupal etc. On se gargarise (avec raison !) que contrairement aux autres nos mises à jour sont plus facile, qu’on essaye de casser le moins possible. Mais malgré ça, comme tu le dis ça n’empêche pas la majorité de garder le site avec la version X.Y de départ, en ne mettant à jour que les Z. Soit ya une raison sur laquelle on peut agir un peu, soit c’est commun à tout partout en fait.

L’autre partie des gens, c’est les personnes qui lancent de nouveaux sites, et c’est certainement de ce côté qu’on devrait plus communiquer (même si on le fait déjà pas mal) sur la possibilité de déverrouiller la compat max avec le define qui va bien. Ainsi on aurait plus de retours à propos des plugins, et surtout des retours plus sereins que quelqu’un qui panique parce que sont site en prod est pété suite à un passage de 3.2 à 4.1 en mode yolo ou par erreur à cause d’une bourde avec spip_loader ^^

Alors moi il m’était plutôt venu une idée un peu inverse : c’est surtout sur les mises à jour (mais oui ça peut l’être pour nouvelle install aussi), et notamment avec spip_loader qu’on pourrait imaginer des améliorations UX :

  1. dans l’interface de spip_loader, après choix de la version à installer, quand on détecte que c’est un changement Y ou X, afficher un gros message d’avertissement directement dans l’interface : « attention pour un changement important comme ça, veuillez toujours vérifier la disponibilité de l’ensemble des plugins, etc »
  2. dans spip_loader toujours, le mieux du mieux serait de permettre par une case à cocher (avant le début de l’install, justement au moment de l’avertissement par ex, ou sinon à la fin je sais pas) de pouvoir dire : « activer la compatibilité des plugins avec la version précédente de SPIP afin de pouvoir les utiliser même si pas encore compat ». Mais comme mes_options.php est pas forcément en écriture je vois pas comment ça pourrait. À minima en affichant un bloc de code à copier coller avec son explication (qui pourrait aussi contenir un « Si vous utilisez des plugins de la version précédente et que ça marche, nous vous invitons à les signaler sur… »).

De cette façon c’est directement à la source, au bon moment de la mise à jour, qu’on explique le problème en avance et ce qu’il faut faire. C’est toujours le meilleur endroit, par rapport à des articles de doc/annonce qui ne sont pas lus par tous, ou lus mais sans retenir tout par cœur non plus (et donc une fois devant l’écran en train de mettre à jour, on ne pense plus à tout : l’interface devrait être auto-suffisante au max).

fort peu se fait bénévolement pour le loisir

Je n’arrive toujours pas à partager ce constat, et s’il est avéré j’en suis bien attristé.

Tu te voiles la face mon pauvre José… :stuck_out_tongue:
M’enfin je vois pas ce qu’il y a de si compliqué à voir, faire du logiciel pour le loisir, comme partout ailleurs, pas juste chez SPIP, c’est l’intérêt d’une minuscule minorité. Personne ne dit que ça n’existe pas, mais c’est une minuscule minorité. Pour la plupart c’est soit durant le temps de travail, ou soit même hors travail, c’est pas un loisir, c’est une utilisation « utilitaire » parce que tel logiciel (SPIP ou Ubuntu ou Framatruc) sert, est utile, aux assocs auxquelles on participe. Ça ne veut pas dire pour autant que c’est un loisir, un plaisir. Donc quand ya des mises à jour à faire, bah non, on fait pas ça sur notre temps le plus libre :

  • quand c’est pour le travail, on fait ça sur le temps de travail donc, et pas gratuitement à priori : parce que des proprios de sites nous payent pour passer du temps à tester que ça marche et à le faire en prod (et si ces derniers veulent pas, bah la mise à jour attendra)
  • quand c’est pour nos assocs, on fait ça quand on est vraiment obligé, ya déjà mille autres choses à faire concernant les vrais activités de l’assoc et ses besoins, donc quand le site marche, on n’y touche pas généralement

Mais en dehors de ça, bah on jardine, on fait du basket avec le gosse, on cuisine, on est en famille, on va voir un concert, faire un vide-greniers, etc.

Je ne souhaite pas donner de « leçon » aux pros (on est bien dans ce domaine là ?), mais ça n’est pas « juste pour rien » que ces sites doivent être mis à jour, ça leur assure une pérennité et certainement moins de mauvaises surprises (et donc des gain de coût) par rapport à un site n’évolue que par « gros paquet » tous les 5 ou 10 ans.

C’est là où il y a une incompréhension : c’est JAMAIS les pros qui choisissent de mettre à jour, sauf cas extrême où c’est obligé de chez obligé. Mettre à jour ça reste toujours in fine le choix des proprios des sites, car ça signifie toujours de passer du temps à tester que tout marche dans la version supérieure (core et plugins), corriger quand il faut, puis le faire en prod. Du temps donc de l’argent à payer aux prestataires qui vont le faire. Et donc une décision de le faire ou pas. Le « juste pour rien » il est jamais dit pas « les pros » mais bien par les proprios de site qui n’en voient pas l’intérêt. Et tant que le site marche tel quel et que la version est encore maintenue, bah généralement on le fait pas, on y reste.

Alors on peut argumenter, conseiller. Mais ça reste toujours leur décision.

Et si tu mets à jour gratuitement des sites de clients, par loisir, sur ton temps libre… bah t’es bien Gentil lol. :smiley:

Payer, payer, payer, tout ne se fait pour ça hein ^^ Et puis pour la 3.2, ça sera bientôt réglé, à moins qu’il y ait un nouvel élan de volonté collective dans le core (ou la communauté) pour maintenir cette version en vie :smiley:

Cf plus haut, si, ça se paye, que ce soit les sites de clients qui payent un prestataire pour maintenir le site, ou asso qui va pas « dépenser du temps » en tests et mise à jour, tant que pas vraiment obligé, car ce temps est plus important à être passé sur les vraies activités de l’asso.

Mais oui 3.2 bientôt finie, mais justement ça va avec ce que je dis : j’attends donc ça avec impatience car ça permettra enfin de « forcer » les proprios à mettre à jour en pouvant leur annoncer que c’est plus maintenu du tout.

À ce sujet, je pense qu’il important qu’on lance une discussion pour qu’on fasse un état des lieux des motivations, disponibilités et surtout des envies des personnes du core. Sans ça, les quelques personnes qui tiennent SPIP (à bout de bras?) risquent de s"épuiser, d’attendre des gens, etc… alors que d’autres n’ont juste pas le temps ou l’envie et peut-être même culpabilisent de ne pas pouvoir donner assez :\

un Grand Débat National ? :stuck_out_tongue:
un sondage ? une visio ?


RastaPopoulos

Actuellement le planning volontariste de release des SPIP ne considère que les versions de PHP mais ignore les plugins. Il faut les y intégrer. La mise à jour des plugins doit être prise en compte dans ce planning.

b_b « il faut aider les personnes qui maintiennent des plugins en les testant, puis en leur remontant les bugs ou juste le fait que ça fonctionne. »

Par exemple Jack31 sur irc vient d’indiquer « On vient de passer un site en 4.1.1 et du coup sarkaspip 4.0 est compat 4.1.1 » mais qu’est ce que ça va devenir ce constat ?
Sur irc ce test ne va rien produire du tout, il va se perdre, il ne « remonte » pas.

cy_altern a indiqué qu’il avait testé une version récente de facteur en 4.1 et qu’il n’avait pas rencontré de problèmes… mais que ça ne lui permettait pas d’affirmer que c’était compat 4.1. C’est tout de même un test réel, et un résultat « intermédiaire » encourageant qui, s’il était connaissable, contribuerait à d’autres tests ou utilisations réelles.
Mais perdu dans les archives (inexistantes) d’irc, cette info n’est pas partagée et ne « remonte » pas non plus.

Alors comment on fait en pratique pour que « ça remonte » ?

Dans la discussion sur irc hier plusieurs pistes ont été évoquées :

  • créer un thread dédié pour chaque plugin sur discuter.spip pour signaler les tests réalisés et les changements de borne
  • créer un ticket dédié sur le repo git.spip de chaque plugin pour ces mêmes sujets
  • créer un framacalc pour tous les plugins

Je précise que c’est suite à discussion sur IRC/Discord hein :grinning_face_with_smiling_eyes:
Pas sûr que ça soit la bonne solution car ça ne permet pas de confirmer/infirmer par d’autres, les 3 autres pistes sont plus adaptées je pense.

Un ticket dédié sur chaque répo pour centraliser + une annonce sur Discuter pour diffuser l’info ?
Mais ça veut dire qu’il faut un compte git pour participer ou à reporter les infos manuellement pour celles et ceux qui n’en ont pas.

Perso j’aimerai qu’on puisse faire une rencontre entre les membres de la team (pour commencer ?) car c’est bien ces personnes qui sont cernées. Après, si on y arrive pas dans l’année, il faudra au moins plusieurs visios par petits groupes, car un visio générale va vite tourner en discussion de comptoir :stuck_out_tongue:

A y réfléchir, un ticket dédié dans chaque plugin aurait l’avantage de ne pas s’éparpiller (il risque d’avoir plusieurs threads sur discuter). L’inconvénient serait de devoir reporter pour les personnes non inscrites sur la forge (ou l’occasion pour elles de s’y inscrire).

Et en ajoutant une étiquette dédiée, ça permettrait de les retrouver facilement et d’avoir une bonne vision d’ensemble.

Ah non surtout pas !
Je pense qu’il faut absolument éviter de disséminer cette information dans tous les plugins et ce à chaque version.

Je rappelle que le lieu des plugins c’est Plugins SPIP et surement encore pour longtemps vu comme on avance sur la fusion avec Contrib et qu’il existe sur ce site des pages de stats comme celles-ci qui sont construites automatiquement : Plugins SPIP

Je pense qu’il suffirait d’imaginer une page de ce type pour chaque version qui permette de suivre l’avancement de la mise à jour des plugins en ajoutant un tag sur les plugins du type dist, galaxie, populaire, etc.
Et pour ça, si il existe une logique de catégories pour les plugins il est aussi possible de définir des tags et de les affecter aux plugins que l’on souhaite. C’est possible depuis des mois…
De fait, on pourrait organiser cette page en distinguant les mises à jour par tag de plugin.

Ma réflexion était « en l’état actuel des choses » et dans l’idée d’avoir un système opérationnel tout de suite, sans rien à développer par ailleurs :slight_smile:

Je te rejoins sur le fait que plugin.spip peut déjà servir à ça, mais…

Je ne pense pas qu’un tag posé sur un plugin (paquet) suffira. Oui ça règle la question du « suivi » global" depuis plugins.spip, mais ça ne remplace pas le fait de créer un ticket sur le repo du plugin, chose qui permet aux personnes qui maintiennent le plugin de savoir qu’une mise à jour est possible ou souhaitée. À moins qu’on acte que ces personnes doivent surveiller cette page de suivi sur plugins.spip, qui serait complétée par le fait que des personnes aient « tagué » le plugin dans le repo (on y revient).

Donc, oui pour utiliser plugins.spip pour le suivi global, et oui aussi pour la discussion et le signalement de compat avec la branche n+1 dans un ticket sur le repo de chaque plugin :slight_smile:

Oui et non, ou l’inverse…
En fait, l’idée que j’ai commencé à mettre en place le week-end dernier c’est de définir des groupes de plugins via des tags : dist, ancien dist, galaxie et fréquemment utilisé.
J’ai taggué les dist, les anciens dist et une bonne partie des galaxie.

Ce week-end je vais créer les pages et on verra pour chaque tag les plugins compatibles ou pas.
Je pense que ça suffit largement pour suivre l’avancement et savoir si on a besoin d’upgrader un plugin ou pas et c’est surtout automatique !

Super, hâte de voir ça :slight_smile:

Tant que tu travailles sur plugins.spip, on a remarqué un ty bug à corriger ce matin, cf #4804 - Le lien "flux des plugins" renvoie sur un vieux backend - plugins-spip-net - SPIP on GIT

Et bien voilà : Plugins SPIP

C’est basé sur des tags sur les plugins usage-dist, usage-dist-grenier, usage-galaxie et usage-frequent.
J’ai créé les 3 premiers ensembles sachant que pour la galaxie j’ai recensé les plugins des sites Contrib, spip.net, Plugins SPIP, Boussole, SPIP-blog et Programmer (les autres sont toujours en 3.2).

Il faut maintenant taguer les plugins que l’on considère comme fréquemment utilisés et qui ne sont paq déjà dans les autres ensembles.
Ca peut se faire tranquillement, sachant que SVP Typologie permet de charger un json pour faciliter les affectations.

Je pense qu’on peut améliorer la présentation mais comme c’est pas ma tasse de thé, je vous laisse le proposer voire le faire :wink:

A vous lire.

Sympa cette page !

Top, merci tout plein :slight_smile:

Bon j’ai rajouté une liste de 120 plugins compatibles SPIP 4.0 et avec un nombre d’utilisations important. On pourra en ajouter d’autres en leur affectant le tag « usage-frequent ».
On peut déjà suivre simplement plus de 200 plugins parmi les plus utilisés.

Super boulot. Un grand merci pour ça.

Où peut-on signaler qu’un plugin non déclaré compatible 4.1 l’est en fait sans souci ?

Je dirais bien dans un ticket sur le repo du plugin, et si aucune personne ne le maintient activement faire un rappel ici.

1 « J'aime »

Je ne pige pas trop la question à laquelle @b_b a répondu, la liste permet de voir les plugins non encore réputés compatibles 4.1 : deux cas de figure, il l’est mais le tag n’a pas été fait, il ne l’est pas et alors il faut tester.
Une fois le zip compatible créé, la page sera mise à jour automatiquement.

Bé la question a l’air simple : comment on fait pour dire qu’un plugin fonctionne ? sous entendu quand on est pas l’auteur évidemment ! quand on est un utilisateur, et qu’on veut dire que le plugin fonctionne bien en 4.1 pour nous, c’est ça qu’il demande à priori


RastaPopoulos

Ben je pensais pas que @J-C se positionnait en utilisateur.
Parce que pour les gens qui ont accès à la forge le plus simple c’est de créer le tag qui va bien.