Comme vous savez la refonte de Contrib a commencé sur le site de production.
La phase essentielle de réorganisation des rubriques est en cours et va durer un « certain temps ».
Un aperçu du résultat est visible d’ores et déjà dans le secteur « Auteurs, authentification et autorisation » (catégorie auteur) qui a été entièrement réorganisé (attention le ménage des articles obsolètes et des archives n’a pas été fait, c’est l’étape suivante).
Je trouve le résultat encourageant mais je ne suis peut-être pas totalement objectif ;-).
Des screenshots sont disponibles :
On voit, par exemple, sur le deuxième screenshot que la catégorie est composée de rubriques-plugin bien identifiées (avec un préfixe) et d’autres rubriques dont on ne sait a priori si ce sont des contributions diverses ou des plugins.
En fait, la plupart de ces rubriques sont des plugins mais certains n’étant pas dans le référentiel ne sont pas identifiés automatiquement avec leur préfixe.
C’est le cas de « Accès restreints issus de Giseh ».
Ce plugin est développé en dehors de la zone, est bien documenté sur Contrib, mais ne fait pas partie du référentiel car il n’est fourni par aucun dépôt.
D’autres sont des plugins développés sur la zone, mais obsolètes ou du moins, plus zippés et qui donc n’apparaissent plus dans le référentiel.
Je trouve cela très dommage que ces plugins n’aient plus la même exposition ni traitement que les autres, ne serait-ce que pour conserver un historique.
Et donc j’aimerais trouver une solution pour les intégrer au référentiel.
J’ai identifié quelques pistes à creuser :
Pour les plugins développés hors de la zone, on peut imaginer plusieurs alternatives :
les rapatrier sur la zone (pas toujours possible)
Saisir le champ préfixe manuellement pour ces rubriques-plugin; cela fonctionne en affichage mais le référentiel ne contenant pas le plugin les liens avec les infos du plugin (idem Plugins SPIP mais sur Contrib) ne seront pas disponibles.
Proposer un formulaire complet pour saisir les informations utiles pour remplir les tables spip_plugins et spip_paquets et permettre des mises à jour. Il faudrait aussi « protéger » ces plugins du vidage des tables. Satisfaisant mais manuel.
Utiliser un smart-paquets modifié pour construire le référentiel de ces plugins à partir du zip et non plus du source sous svn ou git. Ce serait le plus pratique.
Pour les plugins développés sur la zone mais plus zippés le plus simple est de recalculer le zip après les avoir insérés dans le dépôt grenier (ou un autre) et faire en sorte que ce dépôt ne soit reconstruit qu’exceptionnellement.
Comme vous savez la refonte de Contrib a commencé sur le site de production.
La phase essentielle de réorganisation des rubriques est en cours et va
durer un "certain temps".
Un aperçu du résultat est visible d'ores et déjà dans le secteur "Auteurs,
authentification et autorisation" (catégorie auteur) qui a été entièrement
réorganisé (attention le ménage des articles obsolètes et des archives n'a
pas été fait, c'est l'étape suivante).
Je trouve le résultat encourageant mais je ne suis peut-être pas totalement
objectif ;-).
Des screenshots sont disponibles :
- Alternatives to
- https://framapic.org/6wqe6UTL7lrF/03SvNGJzK46W.png
Classe, merci pour ça
C'est le cas de "Accès restreints issus de Giseh".
Ce plugin est développé en dehors de la zone, est bien documenté sur
Contrib, mais ne fait pas partie du référentiel car il n'est fourni par
aucun dépôt.
D'autres sont des plugins développés sur la zone, mais obsolètes ou du
moins, plus zippés et qui donc n'apparaissent plus dans le référentiel.
Je trouve cela très dommage que ces plugins n'aient plus la même exposition
ni traitement que les autres, ne serait-ce que pour conserver un historique.
Et donc j'aimerais trouver une solution pour les intégrer au référentiel.
Je ne comprends pas très bien l'intérêt de référencer des plugins qui ne sont plus distribués. Pourquoi donner de la visibilité à un plugin qui ne pourra pas être récupéré par les utilisateurs ?
J'ai identifié quelques pistes à creuser :
Pour les plugins développés hors de la zone, on peut imaginer plusieurs
alternatives :
- les rapatrier sur la zone (pas toujours possible)
- Saisir le champ préfixe manuellement pour ces rubriques-plugin; cela
fonctionne en affichage mais le référentiel ne contenant pas le plugin les
liens avec les infos du plugin (idem Plugins SPIP mais sur Contrib) ne
seront pas disponibles.
- Proposer un formulaire complet pour saisir les informations utiles pour
remplir les tables spip_plugins et spip_paquets et permettre des mises à
jour. Il faudrait aussi "protéger" ces plugins du vidage des tables.
Satisfaisant mais manuel.
- Utiliser un smart-paquets modifié pour construire le référentiel de ces
plugins à partir du zip et non plus du source sous svn ou git. Ce serait le
plus pratique.
Amha c'est la troisième option qu'il faut préférer, mais je me demande si tout ceci est bien nécessaire, car les plugins concernés ne sont à ce jour pas référencés sur plugins.spip, pourquoi cela devrait-il changer ? Devons-nous prendre la charge de référencer "pleinement" des plugins dont les auteurs ont choisi de ne pas utiliser une des méthodes qu'on propose pour le faire ?
Par rapport à la description que tu fais des plugins qui posent
problème, moi il me vient deux remarques :
- S'il s'agit de choses obsolètes ou presque, pourquoi vouloir les
exposer autant que des plugins maintenus ? Qu'ils ne soient pas encore
tout à fait en archive ok, mais bon ça va finir par arriver, donc ils
sont là, moins exposés, et un jour on va finir par mettre le tag
"archive" dessus et ça disparaitra complètement.
- S'il s'agit de choses développées en dehors de la zone ET des
mécanismes de déclarations déjà possibles (on permet DEJA de déclarer
des choses qui sont pas sur le SVN) : pourquoi est-ce qu'on chercherait
à tout pris à mettre en avant des choses où les gens ne jouent pas le
jeu communautaire ? Ils peuvent déjà mettre leur documentation, après si
ça finit pas autant visible que des choses maintenus en commun, ça ne me
choque absolument pas. S'ils veulent que les rubriques soient reconnus
au même niveau de visibilité et de mise en forme automatique, c'est à
eux de faire un effort de participer, pas à nous de gérer tous les cas
possibles manuellement, et du coup de se créer plein d'exceptions et de
choses à maintenir en plus.
Je ne comprends pas très bien l’intérêt de référencer des plugins qui ne
sont plus distribués. Pourquoi donner de la visibilité à un plugin qui
ne pourra pas être récupéré par les utilisateurs ?
Non, non, la plupart sont encore distribués car l’article à un zip joint.
Mais en fait mon idée est plus d’avoir un référentiel « complet » des plugins avant toute chose.
Ensuite, si certains sont taggués obsolète ou archive, ils disparaîtront des affichages standard mais seront toujours accessibles si on passe outre.
Et nous n’avons toujours pas défini dans la refonte la notion et le mécanisme (même manuel) d’archivage.
Cette question a toujours été aussi non répondue pour les plugins et ça serait pas si mal d’ailleurs de s’y pencher à nouveau.
Amha c’est la troisième option qu’il faut préférer, mais je me demande
si tout ceci est bien nécessaire, car les plugins concernés ne sont à ce
jour pas référencés sur plugins.spip, pourquoi cela devrait-il changer ?
Ben justement je ne trouve pas ça satisfaisant aujourd’hui le traitement de Plugins SPIP car c’est « trop déclaratif » et donc restrictif.
Le référentiel des plugins devrait être plus exhaustif et indépendant de son lieu de production.
Devons-nous prendre la charge de référencer « pleinement » des plugins
dont les auteurs ont choisi de ne pas utiliser une des méthodes qu’on
propose pour le faire ?
Ben c’est toi qui me l’a expliqué un jour.
Tu m’as dit que ce n’était pas forcément un choix délibéré et c’est pour ça que j’ai mis en exergue le plugin de Giseh qui est justement dans ce cas.
Et on le fait bien déjà aussi pour les externals.
S’il s’agit de choses obsolètes ou presque, pourquoi vouloir les
exposer autant que des plugins maintenus ? Qu’ils ne soient pas encore
tout à fait en archive ok, mais bon ça va finir par arriver, donc ils
sont là, moins exposés, et un jour on va finir par mettre le tag
« archive » dessus et ça disparaitra complètement.
Oui mais comme je l’ai dit précédemment à b_b je pense qu’il faut faire ça en deux étapes.
je traite tous les plugins de la même façon en les intégrant dans un même référentiel.
je décide que certains sont obsolètes ou archivés et je filtre mon référentiel.
Je trouve cela beaucoup plus cohérent et gérable que d’avoir des plugins qui sont ou pas dans le référentiel, référentiel qui contient déjà des plugins du dépôt grenier qui eux sont référencés.
Je pense qu’il faut justement réfléchir aux conditions du point 2) et pas à ce qu’on met dans le point 1).
Et pour les plugins je trouverais plus logique que le plugin décide de son état « obsolète » ou « non maintenu » ou autre et implique « l’archivage auto » de la rubrique associée.
Mais c’est un point à discuter et il me parait crucial pour la suite.
S’il s’agit de choses développées en dehors de la zone ET des
mécanismes de déclarations déjà possibles (on permet DEJA de déclarer
des choses qui sont pas sur le SVN) : pourquoi est-ce qu’on chercherait
à tout pris à mettre en avant des choses où les gens ne jouent pas le
jeu communautaire ?
Oui et non.
Premièrement comme je l’ai rappelé dans ma réponse à b_b ce n’est pas toujours volontaire de ne pas intégrer la zone.
Dans ce cas pourquoi ne pas aider au référencement.
Maintenant, si on dit pas de zone pas de référencement alors il faut être cohérent et supprimer la documentation de SPIP-Contrib car c’est un référencement mais il reste au milieu du gué.
Après, je pense qu’il ne faut pas se formaliser du fait de jouer le jeu ou pas.
Je trouve que l’intérêt de SPIP est de référencer l’ensemble de ses plugins car c’est une richesse et une source d’inspiration pour tout le monde.
Et je vois que souvent le zip est partagé même si le code ne l’est pas, d’où la logique des propositions.
Ils peuvent déjà mettre leur documentation, après si
ça finit pas autant visible que des choses maintenus en commun, ça ne me
choque absolument pas. S’ils veulent que les rubriques soient reconnus
au même niveau de visibilité et de mise en forme automatique, c’est à
eux de faire un effort de participer, pas à nous de gérer tous les cas
possibles manuellement, et du coup de se créer plein d’exceptions et de
choses à maintenir en plus.
Mon but n’est pas de gérer des exceptions au contraire : si tout est cohérent dans le référentiel et dans contrib il n’y a qu’un seul cas à gérer.
C’est si l’on laisse l’incohérence actuelle que l’on a des exceptions à gérer.
C'est si l'on laisse l'incohérence actuelle que l'on a des exceptions à
gérer.
Yen a forcément car il y a des contenus qui ne sont pas des plugins, et
personnellement je me suis toujours opposé à ce qu'il n'y ait que des
plugins. Si on veut avoir un article de doc, ou un projet non-plugin sur
tel sujet qui correspond pourtant bien à telle grande catégorie
(auteurs, etc), on doit continuer de pouvoir le faire, ya pas que des
projets-plugins. Du coup les trucs qui ne rentrent pas dans le
référentiel automatique, bah ça rentre dans ces exceptions, des contenus
qui ne sont pas reconnus comme des projets-plugins, mais ils ont
toujours le droit d'être là. Si leurs auteurs veulent que ça soit mieux
reconnu et donc profiter des présentations automatiques qu'on mettrait
en place quand c'est bien reconnu comme un plugin : à eux de faire ce
qu'il faut pour que ce soit bien déclaré, d'après moi.
Par ex pour Giseh, il peut pas être sur le SVN car ça doit être maintenu
par un truc du gouvernement ou que sais-je ? => Il peut développer sur
Github, et donc être le seul à contrôler.
Son employeur a déjà un Git à lui où ça doit être ? => C'est Git, il
peut très bien mettre en place une réplication automatique sur un compte
Github (il développe sur le Git de son employeur mais ya une copie
Github en lecture uniquement), et donc pouvoir alors le déclarer en
dépôt reconnu par notre système.
Il me semble que ça concerne assez peu de cas, donc je suis plutôt
d'avis de pas rajouter de la complexité avec certaines données qui vont
venir de script auto et d'autres remplies manuellement… mof. Je suis
plutôt d'avis que pour ce qui concerne les plugins, tout devrait pouvoir
être reconstruit automatiquement à chaque fois (si un jour on change de
système, etc), sans avoir à récupérer des données manuelles.
Yen a forcément car il y a des contenus qui ne sont pas des plugins, et
personnellement je me suis toujours opposé à ce qu’il n’y ait que des
plugins. Si on veut avoir un article de doc, ou un projet non-plugin sur
tel sujet qui correspond pourtant bien à telle grande catégorie
(auteurs, etc), on doit continuer de pouvoir le faire, ya pas que des
projets-plugins. Du coup les trucs qui ne rentrent pas dans le
référentiel automatique, bah ça rentre dans ces exceptions, des contenus
qui ne sont pas reconnus comme des projets-plugins, mais ils ont
toujours le droit d’être là. Si leurs auteurs veulent que ça soit mieux
reconnu et donc profiter des présentations automatiques qu’on mettrait
en place quand c’est bien reconnu comme un plugin : à eux de faire ce
qu’il faut pour que ce soit bien déclaré, d’après moi.
Oui aujourd’hui on voit bien les plugins du reste avec le préfixe qui est rappelé.
Et les autres rubriques non-plugin sont elles bien distinctes mais toujours présentes.
Ce qui est dommage c’est de ne pas repéré ces plugins comme plugin mais bon…
Par ex pour Giseh, il peut pas être sur le SVN car ça doit être maintenu
par un truc du gouvernement ou que sais-je ? => Il peut développer sur
Github, et donc être le seul à contrôler.
Son employeur a déjà un Git à lui où ça doit être ? => C’est Git, il
peut très bien mettre en place une réplication automatique sur un compte
Github (il développe sur le Git de son employeur mais ya une copie
Github en lecture uniquement), et donc pouvoir alors le déclarer en
dépôt reconnu par notre système.
Oui mais c’est dommage surtout que le zip est fourni.
Ils sont plusieurs comme ça avec pas mal de plugins qui ont ou avaient de l’intérêt.
Il me semble que ça concerne assez peu de cas, donc je suis plutôt
d’avis de pas rajouter de la complexité avec certaines données qui vont
venir de script auto et d’autres remplies manuellement… mof. Je suis
plutôt d’avis que pour ce qui concerne les plugins, tout devrait pouvoir
être reconstruit automatiquement à chaque fois (si un jour on change de
système, etc), sans avoir à récupérer des données manuelles.
Ok on en reste là sur ces plugins.
Maintenant, on peut toujours contacter les auteurs pour voir si on peut les accompagner pour intégrer leurs plugins au référentiel d’une façon connue.
Après il reste les autres plugins sur la zone mais non produits.
Là je souhaiterais vraiment les réintégrer dans le référentiel avant de décider comment on gère l’obsolescence ou l’archivage.
Maintenant, on peut toujours contacter les auteurs pour voir si on peut les accompagner pour intégrer leurs plugins au référentiel d'une façon connue.
Après il reste les autres plugins sur la zone mais non produits.
Là je souhaiterais vraiment les réintégrer dans le référentiel avant de décider comment on gère l'obsolescence ou l'archivage.
Plutôt qu'un formulaire plus un moyen de restauration en cas de vidage des tables
ce pourrait être pareil que pour les autres une variante de archivelist
Le mer. 9 oct. 2019 à 17:14, JLuc <jluc@no-log.org> a écrit :
Le 09/10/2019 à 14:58, Eric Lupinacci a écrit :
Maintenant, on peut toujours contacter les auteurs pour voir si on peut les accompagner pour intégrer leurs plugins au
référentiel d’une façon connue.
Après il reste les autres plugins sur la zone mais non produits.
Là je souhaiterais vraiment les réintégrer dans le référentiel avant de décider comment on gère l’obsolescence ou
l’archivage.
Plutôt qu’un formulaire plus un moyen de restauration en cas de vidage des tables
ce pourrait être pareil que pour les autres une variante de archivelist
Oui c’est bien ce que j’ai dit.
Le formulaire ne concernait pas ces plugins.
