A propos de la distribution des « modules à installer »

J’insiste sur le fait qu’il s’agit seulement de ce que j’ai compris, pas plus, et que c’est rédigé du point de vue « consommateur pas forcément au courant mais qui essaye de comprendre ».

Une situation actuelle transitoire

Actuellement certains modules à installer sont proposés au téléchargement au format zip sur Spip-Zone, qui est l’espace de développement des contributions (tout ce qui n’est pas le core) de Spip ... Les projets en cours sont visibles dans l’explorateur de la Zone, et certains (et seulement certains) d’entre eux sont accessibles en zip dans la Zone de téléchargement>. Les autres projets ne sont accessibles que par le mécanisme SVN de chargement des fichiers source, qui est l’outil normal de la Zone pour ce faire.

Le choix de mettre ou non, à disposition en téléchargement au format zip son module, est à la discrétion de chaque développeur, et à sa charge via l’inscription par lui même de son projet dans archivelist.txt. C’est sur cette base que le serveur de la Zone va générer les fichiers zip toutes les demi-heures (à l’heure et à la demie en fait). Ce filtrage est volontaire et nécessaire, par exemple pour les raisons suivantes (cas des plugins) :

• La spécificité des plugins placés en "dev" (encore pire en « dev_/_ze_laboratoire_ » [1]) c’est que justement ils ne sont pas utilisables sans précautions, ni sans un minimum de compétences. Ils peuvent être incomplets, comme il peut y avoir des trous de sécurité par exemple. Ou ils peuvent être associés à la branche SPIP en développement et en évolution constante (SPIP SVN). Par ailleurs les développeurs ne veulent assurer à ce stade, ni de SAV (SAD plutôt pour Service Après Don), ni de documentation. Bref le principe est que si vous êtes capable, en pleine connaissances de cause, de travailler sur un plugin en version "dev" alors vous êtes aussi capable de mettre en oeuvre son suivi via SVN.
• Certains développeurs souhaitent mettre à disposition leur code, mais ne souhaitent pas pour autant assumer le « SAD-consommateur » ensuite, et c’est leur plein droit ... voir par exemple ce débat sur les conditions de documentation des plugins

En l’état ce mécanisme, pas vraiment satisfaisant pour les utilisateurs consommateurs (liste incomplète des modules « stables » en zip, manque de lisibilité, etc ..) n’est que transitoire, pour les raisons suivantes :

• la Zone n’est pas destinée à l’usage des utilisateurs consommateurs, elle est clairement organisée par et pour les développeurs, pour satisfaire leurs besoins propres, avec leurs outils, dans leur jargon, selon leurs règles pratiques, et leur charte de fonctionnement . Entre autres choses toute personne qui s’y aventure est supposée avoir les compétences pour ce faire (par exemple savoir utiliser SVN).
• Les ressources serveur de la Zone ne sont pas illimitées ... la fabrication des zip occupe déjà 10% du temps total du serveur, c’est chaud, sans parler des processus svnserve qui tournent en permanence, et de google qui indexe tout Trac (Source : voir ce fil de discussion)

Enfin un module peut très bien être développé ailleurs que sur la Zone, ne serait-ce que parce que son auteur ne souhaite pas utiliser SVN, la question peut se poser alors pour lui de savoir comment le mettre à disposition de la communauté.

Pour la documentation, la situation actuelle est aussi parfois assez confuse. aussi bien pour l’utilisateur que pour le développeur d’ailleurs. Même quand elle existe, la difficulté est de la trouver pour le consommateur, et pour le développeur de savoir ou il peut la déposer et en assurer le suivi sans trop de complications. A titre d’exemple les informations sur le plugin « mots-partout » (en phase « test » à ce jour) sont répartis entre une page pas tout à fait à jour sur spip-contrib, un texte idem sur le wiki de la zone et des compléments d’informations sur les dernières évolutions sur la liste spip-user. Il y a les mêmes flottements pour savoir ou poser et répondre aux questions d’ailleurs (sur Spip-User, sur Spip-Zone, sur Spip-Contrib ???).

Pour mémoire concernant les plugins, à défaut d’autre renseignement, le premier réflexe de l’utilisateur doit être d’aller voir dans le fichier « plugin.xml » inclus nécessairement dans le répertoire de chaque plugin (c’est une convention pour les plugins SPIP), et qui contient des pistes précieuses si le développeur à fait l’effort de bien le commenter. On y accède par lecture directe ou par l’onglet de gestion des plugins de l’espace privé.

La situation souhaitable

La situation souhaitable est d’arriver pour chaque module à une répartition séparée des tâches, y compris physiquement parlant, comme c’est le cas pour le core de SPIP soit, d’un coté un espace de développement ou le module est en évolution (la Zone bien sûr, mais d’autres peuvent exister), de l’autre un accès public « utilisateurs consommateurs » pour le téléchargement, la documentation, et le forum de question-réponses de sa dernière version stable (Spip-contrib par exemple, mais d’autres peuvent exister).

Du point de vue développeur l’enjeu va être de faciliter le suivi des mises à jour de son module d’un espace à l’autre. Et aussi de lui proposer des espaces de travail adéquats s’il le souhaite (un pour développer, un pour le téléchargement, un pour la documentation)

Du point de vue utilisateur-consommateur l’enjeu va être de lui permettre de s’y retrouver alors que les étapes de mise en oeuvre d’un module peuvent très bien ne pas être physiquement regroupées (serveurs différents par exemple pour le téléchargement, la documentation, etc ...), et que les modules peuvent aussi être physiquement éparpillés à droite et à gauche.

Pour ceux qui pratiquent Firefox, la problématique ressemble à celle des extensions de ce navigateur.

Les recherches en cours pour améliorer les choses

A ma connaissance il n’y a rien de stabilisé à ce jour, mais des travaux prometteurs sont en cours. J’insiste sur le fait que rien n’est finalisé.

Outil pour s’y retrouver : voir les plugins c’est plus la Zone, comme illustration d’un endroit ou les auteurs de plugins centraliseraient les données sur les versions qu’ils diffusent. L’idée est créer un système semi-automatique de gestion des mise à jour, avec diffusion par RSS de la dernière version des plugins. Si j’ai bien compris l’idée est d’utiliser ce qui existe déjà, à savoir le fichier « plugin.xml » de chaque plugin, et la syndication de spip. Je n’ai pas compris si les modules type squelettes pouvaient s’insérer dans ce mécanisme.

Espace de documentation : L’équipe de Spip-contrib est en pleine réflexion pour faire évoluer ce site en fonction de ces besoins. Il s’agit tout autant de modifier l’arborescence du site, son squelette, que les règles de gestion et de validation des contributions. Les tendances principales qui se dégagent pour l’instant sont en résumé :

• Un module à installer (squelette, plugin, etc ...) = une sous-rubrique spécifique regroupant tout ce qui le concerne (doc, forum, téléchargement, archives), avec liberté de gestion par le développeur (pratiquement il aurait des droits d’admin restreint sur sa rubrique) ... à lui de la faire vivre et de la tenir à jour.
• Navigation par mots clefs thématiques pour permettre aux différents utilisateurs de trouver plus facilement ce qui les intéresse.
• Assouplissement des règles de première validation (plus rapides en particulier) ... les modalités précises sont encore à aboutir
• ligne éditoriale « post spip 1.9 » : compte-tenu des proonds changements introduits dans le mode de contribution, tout ce qui n’est plus utilisable en spip 1.9 serait basculé en archive.
• Nouveau squelette adapté, en particulier au multilinguisme.

Téléchargement : A ma connaissance rien de précis n’est encore en cours concernant la forme définitive de production des paquets zip (automatique ???) et de mise à disposition sur des serveurs eux mêmes à préciser. Avec les exemples cités plus haut, si j’ai bien compris il revient à chaque développeur de générer et placer manuellement son zip sur un espace de téléchargement (Spip-Contrib par exemple ???) .... est-ce vraiment fiable à terme ???

Annexe

A titre d’illustration de la situation actuelle, et si ça peut être utile, au 19 octobre j’ai listé que sauf erreurs de ma part :

• plugins "stable", il manque dans les zip individuels : coloration_code ; corbeille ; dav ; desactiver_flash ; formulaire_personnalisation ; frimoussesIV ; modeles_liste ; profil_etendu ; push ; spip-lettres ; spip-meteo ; spip-sondages ; squelettes_update ; svn_update ; tidy ; version_texte
• plugins "test", il manque dans les zip individuels : checklink ; ConfigurationSpipClear ; decoration ; exif ; decoration ; fading_rollover ; flash_flv_player ; formulaire_editer_auteur ; mail_smtp ; memobox ; ; menu_deroulant ; miroir_syndic ; mnogosearch ; pagination_ahah ; portfolio ; recommander ; sktheme ; splickrbox ; target ; verifcore
• je n’ai pas listé les plugins en "dev" qui généralement sont volontairement uniquement disponibles via svn à ce que j’ai compris (en fait il y a quelques exceptions disponibles en zip)

Fin (provisoire)