Re: Contrib et fichiers des plugins

Maïeul Rouquette <[email protected]>
Newsgroups gmane.comp.web.spip.devel
Message-ID <[email protected]>
Le 12/04/2020 à 19:45, Bruno Bergot a écrit :
> Hop,
> 
> Le 12/04/2020 à 16:53, Maïeul Rouquette a écrit :
>> En attendant une refont de la maquette filaire de contrib, j'ai 
>> discuté avec Eric, et nous avons décidé de mettre en œuvre un quickfix 
>> pour retrouver correctement les zip des plugins.
>>
> 
> Merci :)
> 
> Quelques remarques et commentaires, désolé par avance si vous pensez 
> qu'il faut poster sur un autre canal.
> 
>> - on n'a pas l'info sur la taille au niveau de svp / débardeur, du 
>> coup on l'affiche plus, on va pas s'amuser à faire des requêtes juste 
>> pour ça (mais peut être une fonction à ajouter dans le futur=
> 
> Amha ça n'est pas vital, on peut très bien s'en passer ça permet 
> d'alléger le contenu des pages.
> 
je suis assez d'accord
>> - tous les docs distants dépendant de files.spip.net/org sont 
>> automatiquement masqués. En fait on pourrait carrément les supprimer 
>> en base, vu que ce sont les documents ajoutés auparavent par le 
>> synchronisateur
> 
> Gogogo, mode ménage de printemps, ça fera ça de moins dans la base :)
> 
oui mais j'ai pas l'accès pour ca :)
enfin je pourrais m'amuser à le faire à la main, mais des gens qui ont 
un accès sql pourraient le faire en deux couprs de cuillère à pot
>> - les mots clés sur les versions de SPIP ne sont *a priori* plus 
>> utiles, à part pour les articles qui ne concernent pas des plugins. On 
>> les garde donc, mais sauf exception on n'aura plus à se préoccuper de 
>> les poser.
> 
> Pas certain de parler de la même chose, mais j'ai un doute sur le 
> résultat, exemple avec GIS 4 qui indique être compatible de SPIP 1.9 à 
> SPIP 3.2 :
> 
> https://contrib.spip.net/GIS-4
> 
> Je pense que ça vient du fait que dans 
> https://git.spip.net/spip-galaxie/contrib.spip.net/src/branch/master/aside/article.html#L10 
> tu boucles sur le plugin et non le paquet. À froid je n'ai pas d'idée 
> concrète pour améliorer ça, mais peut-être faut il chercher directement 
> dans les paquets en fonction de l'url de doc (qui est celle de l'article 
> en cours), sauf que très souvent les paquets référencent l'adresse en 
> mode lien court, etc.
> 
a oui, j'avais pas prévu le cas des articles qui recensent une version 
particulière du plugin. COmme tu peux voir, l'article a beau s'appeler 
Gis 4, il recense toutes les versions.

C'était pas le cas avant avec le synchronisateur, qui effectivement 
s'appuyait sur les urls (y compris en gérant les liens courts etc.).

Je sais pas quoi en penser en fait :
- on pourait se rebaser sur documentation, mais je suis pas sur que ce 
soit une bonne idée :
   - à mon avis le lien de doc dans svp devrait être déterminer 
automatiquement à partir du référentiel de plugins qu'Eric veut 
construire, et plus dépendre du paquet
   - si on modifie la maquette, bien possible qu'en fait on présente 
autrement les choses, en disant "versions du plugins" et pas "doc joint 
à cet article", du coup peut être attendre la nouvelle maquette
- si on décide de bien séparer la liste des fichiers selon l'article où 
l'on est actuellement, faudrait peut être repenser le lien

DOnc je dirais : pour ces cas particulier avec des articles 
correspondant à une version particulière du plugin, attendons le travail 
des maquetistes. Là ca fait des choses un peu bizarre, mais comme on 
l'info sur la compat pour chaque version du plugin, c'est pas non plus 
hyper grave. Si on lit l'article Gis 4 , on sait qu'on veut la version 4 
de Gis, et donc on peut voir les compatibilités.

>> - on n'utilise plus la syndication pour afficher le lien vers le 
>> code/la dernière mise à jour, mais uniquement les infos fournies par 
>> le débardeur
> 
> Top !
> 
>> - on pourrait désabonner tous les flux de commit pour économiser des 
>> ressources
> 
> Idem que pour ma seconde remarque, délestons-nous des infos qui ne sont 
> plus utiles, ça permettra économiser de l'espace en base et de la 
> ressource.
> 
même réponse qu'avant : oui mais je peux pas le faire
>> - pour la future version vraiment refondue fusion plugins/contrib, 
>> sans doute devrait-on remettre, mais en se basant sur l'API de gitea, 
>> et en voyant comment gérer le cache
> 
> Amha osef, l'info de dernière mise à jour est présente, le lien vers la 
> code source aussi et il permet de consulter les logs de commits, ça fait 
> très bien le job.
> 
oui je pense aussi, mais attendons les maquetistes :)

>> - je ne sais pas si c'est utile de faire une page qui liste tous ces 
>> plugins ? à voir
> 
> Non.
> 
>> Enfin j'ai profité pour améliorer la dispersion des chaines de 
>> langues, en mettant tout ce qui était dans local dans galactic_contrib 
>> + en branchant galactic_contrib sur salvatore.
> 
> Todobien :)
> 
> ++
> b_b
> _______________________________________________
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip

_______________________________________________
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.