Re: [spip-dev] Intervalles de compat et fonctions associées

2021-05-08 Par sujet Eric Lupinacci
Re,

Le sam. 8 mai 2021 à 18:03, Matthieu Marcillaud  a
écrit :

> Et qui dire de la comparaison spip_version_compare('3.0.7', '3.0.*', '=')
>
>
La même chose, c'est la même incohérence

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Intervalles de compat et fonctions associées

2021-05-08 Par sujet Eric Lupinacci
Yop,


Le sam. 8 mai 2021 à 17:57, RastaPopoulos  a écrit :

> Sur les utilisations réelles je ne sais pas, mais sur la logique c'est un
> peu plus compliqué non ? L'étoile devrait représenter le max possible 999
> si c'est la borne sup d'une comparaison MAIS devrait représenter 0 c'est si
> la borne inférieure, non ?
>
> 3.0.* < 3.0.7  ça devrait faire 3.0.0 < 3.0.7 ?
>
>
Ta proposition est logique oui.

Je me disais sinon que l'étoile pourrait ne pas être utilisée en borne inf
mais uniquement la borne sup (ce que je viens de coder en local d'ailleurs).
A priori l'étoile n'est jamais utilisée en borne inf actuellement mais
c'est exact que l'utiliser règlerait le problème des alpha, beta et autres
pré-releases.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

[spip-dev] Intervalles de compat et fonctions associées

2021-05-08 Par sujet Eric Lupinacci
Hello,

J'investigue depuis hier les fonctions associées à la gestion des
intervalles de compatibilité.
J'ai déjà corrigé un bug d'inclusion des bornes dans la fonction
extraire_bornes().

J'étais en train de vérifier/corriger la fonction compiler_branches_spip()
et je suis tombé sur un comportement bizarre de spip_version_compare().
Cette fonction, il y a des lustres, a été mise à jour pour prendre en
compte les versions avec étoile comme 3.0.*.
La fonction compare v1 à v2 selon l'opérateur précisé.
Elle accepte que seule v2 puisse avoir une étoile et dès lors remplace
l'étoile par la valeur idoine issue de v1.
De fait, si on fait le test 3.0.1 < 3.0.* on obtient false car on compare
3.0.1 < 3.0.1.

Dans mon esprit, '*' devrait exprimer la valeur max possible.
Si on parle de versions spip, ça serait donc 3.0.999.

Le souci c'est que je ne sais pas si on utilise spip_version_compare() avec
des étoiles uniquement pour comparer des versions spip provenant des
intervalles de compat ou pas.
Ce qui pose un problème pour décider de la correction à apporter.

Des avis ou des idées ?

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 et la compat des plugins

2021-05-08 Par sujet Eric Lupinacci
Re,


Le sam. 8 mai 2021 à 09:50, Maïeul Rouquette  a écrit :

>
> Je suis plutot d'accord avec la logique de branchement proposé, même si
> je ne suis pas sur qu'il soit pertinent de reduire les branches
> existantes. A voir.
>

 Je n'ai jamais considéré comme une bonne pratique d'avoir des branches qui
se chevauchent en termes de compatibilité. Dans ce cas laquelle choisir ?
Je pense qu'il faut toujours tirer les gens à installer les versions les
plus récentes qui seront dès lors plus à jour et plus fiables.
Dans notre cas, l'intérêt est aussi d'avoir une branche du plugin qui
devient obsolète au même titre que la version spip (spip < 3.2).

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 et la compat des plugins

2021-05-08 Par sujet Eric Lupinacci
Hello,


Le ven. 7 mai 2021 à 23:44, RastaPopoulos  a écrit :

> Là on parle d'une recommandation pour SPIP 4. Grosse version, gros
> changements.
>
> Ça ne me parait pas *du tout* déconnant, et en plus c'est vraiment un
> "incompatibilité" super minime, de dire aux gens : bah oui à partir de
> maintenant arrêtez de laisser votre bordel à la racine et rangez votre
> chambre, merde.
> On va pas s'empêcher d'avoir des noms simples et bien rangés, parce que 3
> pauvres gens laissent leurs chaussettes sales.
>
> Donc pour moi, même prefixe.svg suffit en théorie.
>
> Aux gens qui font des squelettes en bordel de mettre leurs images dans…
> /images. Suffit de l'écrire clairement dans la release.
>
>
+1
prefixe ou prefixe_logo me parait suffisant surtout que comme je l'ai déjà
dit, nous ne ferons pas disparaître l'attribut logo dans la spip 4.0.

Pouvez-vous maintenant donner votre avis sur la logique de branchement
proposée car c'est quand même le sujet principal du fil.
Merci.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 et la compat des plugins

2021-05-07 Par sujet Eric Lupinacci
Re,


Le ven. 7 mai 2021 à 20:06, tcharlss  a écrit :

>
> > Mais je suis aussi d'accord pour ne pas utiliser directement
> > {prefixe}.svg qui me parait un peu trop simple, a première vue...
> Moi c'est pour ça que plugin_.svg me semblait rester simple et
> assez logique.
>

On peut essayer de rester dans la logique existante.
prefixe_logo_plugin.svg ou prefixe_logo.svg ça me parait suffisant.
Et maintenant ça serait bien de revenir au propos principal du fil qui est
la compat :)

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 et la compat des plugins

2021-05-07 Par sujet Eric Lupinacci
Le ven. 7 mai 2021 à 19:41, Bruno Bergot  a écrit :

>
> Claro, newsletter.svg/png à la racine d'un dossier squelettes et paf !
>

On en était à newsletter_logo.svg.
Vous pensez que c'est vraiment un problème ?

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 et la compat des plugins

2021-05-07 Par sujet Eric Lupinacci
Le ven. 7 mai 2021 à 18:41, tcharlss  a écrit :

> Les fichiers php et les images ça n'est pas les mêmes contraintes : les
> plugins ou les gens sont libres de ranger et nommer les images destinées au
> site public comme bon leur semble, il n'y a rien d'imposé.
> Moi le doute de conflit c'est plutôt par rapport à ça : quelqu'un qui
> aurait placé toutes ses images en vrac à la racine dans son dossier
> squelettes. Et quand bien même c'est pas super, il/elle aurait bien le
> droit.
> C'est dans ce sens que ça serait plutôt à nous d'anticiper pour pas
> collusionner.
>
Non il n'y a pas de différence à partir du moment où on définit un nommage
obligatoire pour un plugin.
Je pense que s' il existe des cas tordus ils ne devraient pas être très
nombreux et donc sûrement gérables.
Le but est de simplifier.
Donc pour moi le choix est soit prefixe.svg soit prefixe_logo.svg.
Et pour les cas tordus on gérera ça à la cool.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 et la compat des plugins

2021-05-07 Par sujet Eric Lupinacci
Yo,



Le ven. 7 mai 2021 à 17:49, tcharlss  a écrit :

> Je crois que la remarque d'erational reste valable avec cette option, ça
> ferait aussi des noms d'images possiblement très courants comme
> contact_logo.svg, home_logo.svg, etc.
>
> Sinon par exemple plugin_.svg ?
>
Oui mais là je ne suis pas trop d'accord.
C'est comme si on disait que prefixe_options pourrait être utilisé
autrement.
A partir du moment où pour l'instant il est toujours possible de donner un
nom quelconque et que le paquet possède toujours l'attribut je pense que ce
sera aux plugins de s'adapter si contact_logo ou autre ont été utilisés
hors logo.

On pourra faire ça tranquillement.
Et ensuite l'attribut logo pourra disparaître.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 et la compat des plugins

2021-05-07 Par sujet Eric Lupinacci
Re,


Le ven. 7 mai 2021 à 17:28, erational  a écrit :

> logo-contact.svp c'est aussi très courant 
>
> peut-être prendre "svp" comme préfixe (mi-troll mi-raisin) ?
> svp-saisies.svg
>
>
> Le 07/05/2021 à 17:23, tcharlss a écrit :
>
> Le 07/05/2021 à 16:54, Eric Lupinacci a écrit :
>
> 3- passer le logo à la racine du plugin avec un nom prefixe.svg à partir
> de 3.2
>
> Un doute sur ce point : il serait pas plus prudent de faire plutôt
> logo-.svg ?
> Parceque si des plugins ont des préfixes super génériques, on pourrait se
> retrouver avec des home.svg, login.svg ou je sais pas quoi à la racine, des
> conflits possibles en perspective.
>
> Oui c'est pas idiot.
J'avais proposé un truc comme ça mais Rasta m'a convaincu d'abandonner le
complément du préfixe.
Si on devait le faire je pense qu'il faut garder la logique habituelle à
savoir prefixe_logo.svg comme prefixe_options.php.

++
Eric





> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/irc://irc.freenode.net/spip
>
>
> --
> _https://www.erational.org
>
> ___
> 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

Re: [spip-dev] [cartes] Initialisation du plugin Cartes. Permet de définir des (...) => nom trop générique ?

2021-05-07 Par sujet Eric Lupinacci
Yop,



Le ven. 7 mai 2021 à 17:14, RastaPopoulos  a écrit :

> Le 07/05/2021 à 17:04, Eric Lupinacci a écrit :
> > Oui je vois plus ou moins, la différence c'est que vous ne voulez pas
> être lié à un territoire et à son contour mais à une quelconque forme GIS.
> > Donc c'est exact que c'est moins restrictif.
> > D'ailleurs vous pourriez très bien vous brancher aussi sur un territoire
> qui à déjà son contour...
>
> Ah mais tout à fait, j'y pensais dans le lot :)
> J'ai commencé une architecture, mais j'ai pas encore tout bien calé,
> l'idée c'était déjà de pouvoir partir rapidement sur les options connues de
> GIS (qui comprennent flux de points et contours en fichiers joints), pour
> avoir un truc utilisable rapidement, mais en ayant bien en tête de pouvoir
> aussi ajouter d'autres sources possibles si stockés ailleurs (les contours
> de territoire sont stockés dans quoi ?)
>
>
Dans mon plugin on peut créer un objet carte soit à partir d'autres cartes
ou soit à partir de territoires (j'ai pour l'instant refusé de mélanger).
Par exemple, je fais la carte des pays de l'europe, de l'asie et après je
fais la carte de l'eurasie à partir des deux premières.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] [cartes] Initialisation du plugin Cartes. Permet de définir des (...) => nom trop générique ?

2021-05-07 Par sujet Eric Lupinacci
Le ven. 7 mai 2021 à 17:12, Maïeul Rouquette  a écrit :

>
> > Pas de souci à laisser le préfixe cartes et l'objet carte.
> > Je vais passer le préfixe à "carter" (j'aime les cacahuètes) et la table
> > sera renommée territoires_cartes.
> > Je prends le temps de faire ça la semaine prochaine.
> >
> > ++
> > Eric
> >
> >
>
> j'ai un doute sur le prefix proposé, risque confusion. "cartographier" ?
>

T'inquiète c'était pour rire :)
Je verrais bien en temps voulu.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] [cartes] Initialisation du plugin Cartes. Permet de définir des (...) => nom trop générique ?

2021-05-07 Par sujet Eric Lupinacci
Hello,



Le ven. 7 mai 2021 à 16:23, RastaPopoulos  a écrit :

> il me semble que le nom utilisé ici est vraiment trop générique par
> rapport à l'objet du plugin : ne s'occupe que des objets Territoires du
> plugin éponyme. C'est un sous-plugin (ou connexe) *de Territoires
> uniquement* quoi.
>
>
Oui exact, pour moi une carte c'est un contour de n territoires.



> On avait discuté ya 1 ou 2 mois avec Maieul d'un plugin Cartes vraiment
> générique dans le sens où là il s'agirait d'un plugin qui ajouterait un
> objet "Cartes", permettant essentiellement d'englober des configs de cartes
> dans un objet stocké en base, donc réutilisable facilement, afin de pouvoir
> ensuite l'afficher plusieurs fois à tout moment, c'est-à-dire
> 1) sans retaper à chaque fois tous les params nécessaires du modèle de GIS
> (que ce soit dans un contenu ou dans un squelette)
> 2) avec une interface du coup !
>
> Non-exhaustivement, pouvoir configurer au moins :
> - le titre et une description
> - les params d'affichage (zoom, fonds, cluster ou pas, etc)
> - quel "flux de points" insérer (param objet)
> - quel(s) tracés ajouter en plus (geojson)
> - etc
>

Oui je vois plus ou moins, la différence c'est que vous ne voulez pas être
lié à un territoire et à son contour mais à une quelconque forme GIS.
Donc c'est exact que c'est moins restrictif.
D'ailleurs vous pourriez très bien vous brancher aussi sur un territoire
qui à déjà son contour...


>
> Là l'idée c'est que quand je clique sur "Créer une nouvelle carte", je
> configure vraiment n'importe quelle carte, avec *n'importe quelles sources
> de données*.
>
>
Pas de souci à laisser le préfixe cartes et l'objet carte.
Je vais passer le préfixe à "carter" (j'aime les cacahuètes) et la table
sera renommée territoires_cartes.
Je prends le temps de faire ça la semaine prochaine.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

[spip-dev] SPIP 4 et la compat des plugins

2021-05-07 Par sujet Eric Lupinacci
Hello,

Je commence à mettre à jour la compat des plugins que je maintiens mais je
me pose pas mal de questions.
En outre, je vois passer des mises à jour sur d'autres plugins et on est
pas très raccord sur la stratégie à adopter.
Je me dis que ça serait bien de définir quelques recommandations pour
éviter la joyeuse kermesse à la fin...

En effet, il y a plusieurs "améliorations" qu'il est possible d'amener à
nos plugins qui vont entrer dans le futur:
1- l'abandon du plugin.xml qui n'est plus nécessaire à partir de la branche
3.0
2- l'utilisation d'un logo svg pour le plugin à partir de la branche 3.2
3- passer le logo à la racine du plugin avec un nom prefixe.svg à partir de
3.2
4- l'ajout de necessite vers des plugins-dist retirés depuis la 4.0 (ce qui
aurait toujours dû être le cas même avant la 4.0)

*cas 1: plugin compat [3.2.0;3.2.*]*
Dans ce cas, normalement il n'existe plus de plugin.xml et on peut
appliquer 2 et 3.
Si on ne souhaite pas utiliser des nouveautés spip 4 on peut donc passer à
[3.2.0;4.0.*].
Sinon on crée une branche nouvelle (via le master) [4.0.0-alpha;4.0.*].


*cas 2: plugin compat [3.1.0;3.2.*] ou [3.0.0;3.2.*]*
Dans ce cas, normalement il n'existe plus de plugin.xml, sinon on peut le
virer, ça doit être un oubli.
2 n'est pas applicable pour 3.0 et 3.1 qui ne sont plus supportées par spip
suite à la sortie de la 4.0.
Le mieux est sûrement de créer une nouvelle branche n+1 du plugin
compatible [3.2.0;4.0.*] et d'appliquer 2 et 3 si pas de besoin de
nouveautés spip 4.
La branche n peut être réduite à [3.0.0;3.1.*] ou [3.1.0;3.1.*] selon.
Si on a besoin de nouveautés spip 4 alors on crée une branche nouvelle (via
le master) [4.0.0-alpha;4.0.*], application de 2 et 3 et la branche n ne
change pas.

*cas 3: plugin compat [2.x.y;3.2.*]*
Dans ce cas, il faut créer une branche n+1 comme dans le cas 2 en
appliquant 1, 2  et 3.
La branche n peut rester comme elle est ou être réduite à 3.1 max.

A votre avis ? C'est vraiment une première réflexion à améliorer je pense.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] [Spip-zone-commit] [testbuilder] Un peu de nettoyage, passage en v1 pour SPIP 4+, et (...)

2021-05-07 Par sujet Eric Lupinacci
Petite remarque, tu n'as plus de branche compatible 3.2.

++
Eric


Le ven. 7 mai 2021 à 10:57, Cerdic  a écrit :

> spip-contrib-extensions/testbuilder
> -
> Par Cerdic, le 7 mai 2021 à 10h56min :
>
> Un peu de nettoyage, passage en v1 pour SPIP 4+, et icone
>
>
> *Ajouté*
> prive/themes/spip/images/tb-file-xx.svg
> prive/themes/spip/images/tb-folder-xx.svg
> prive/themes/spip/images/tb-xx.svg
> tb.svg
> *Supprimé*
> images/tb-128.png
> images/tb-16.png
> images/tb-24.png
> images/tb-256.png
> images/tb-32.png
> images/tb-48.png
> images/tb-64.png
> images/tb-file-16.png
> images/tb-folder-16.png
> plugin.xml
> prive/themes/spip/images/tb-16.png
> *Modifié*
> paquet.xml
> prive/exec/testbuilder.html
> prive/style_prive_plugin_tb.html
>
> Détails :
> https://git.spip.net/spip-contrib-extensions/testbuilder/commit/b76fcb866e1335e981b995f3eb6ea39ace5ab7a9
>
> ___
> spip-zone-com...@rezo.net -
> https://listes.rezo.net/mailman/listinfo/spip-zone-commit
>
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] [bellespuces] valide SPIP 4.0

2021-05-07 Par sujet Eric Lupinacci
Hello,


Le ven. 7 mai 2021 à 09:11, chanka...@choc0.net  a
écrit :

> hello
>
> Le 06/05/2021 à 22:42, Maïeul Rouquette a écrit :
> >
> > perso je vire les plugin.xml au fur et à mesure.
> question bête, mais du coup la borne mini de la nouvelle version on met
> quoi ?
> 4.0.0-alpha ?
>

Attention, tant que la branche concernée est compatible spip 2 il est
nécessaire d'avoir un plugin.xml.
Mon avis est qu'il serait bien de brancher ce type de plugin en se
débarrassant du plugin.xml et de créer une branche uniquement avec un
paquet.xml.
Après cette version peut avoir soit spip 3 comme borne min soit spip 4, ca
c'est une stratégie à définir.
Si par contre tu mets spip 4 en borne mini, il faut mettre 4.0.0-alpha car
elle est inférieure à 4.0.0.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] [saisies] On passe le master de Saisies en spip 4 pour permettre (...)

2021-05-07 Par sujet Eric Lupinacci
Yo,

Le ven. 7 mai 2021 à 09:19, Maïeul Rouquette  a écrit :

>
> Merci Eric, mais il aurait été bien de branche aussi dans le même temps
> une branche v3, puisque, ainsi qu'expliqué hier sur IRC, on ne souhaite
> plus maintenir sur master la compatibilité pour les anciennes branches
> de SPIP.
>
> C'est fait.
>

Oui, désolé, j'ai hésité mais comme on n'en avait pas discuté...
Par contre, tu as mis 3.3.* en borne mini, je pense pour inclure la
3.3.0-dev qui n'a réellement jamais vu le jour.
Je pense que ça ne marchera pas car * ne devrait pas inclure le -alpha : à
vérifier.

Après, franchement, faut-il vraiment intégrer une version fantôme sachant
qu'elle n'apparaît pas dans la liste des branches ?

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Logos SVP

2021-05-07 Par sujet Eric Lupinacci
Yop,


Le ven. 7 mai 2021 à 02:06, nicod_  a écrit :

> Le 06/05/2021 à 18:34, Eric Lupinacci a écrit :
> > Si on passe à composer
>
> Lol.
>
>
Tu m'as l'air bougon ces temps-ci.
Pourtant ça avance et aussi dans ce sens.

Aller haut les cœurs.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Logos SVP

2021-05-06 Par sujet Eric Lupinacci
Hello,


Le jeu. 6 mai 2021 à 18:23, Matthieu Marcillaud  a
écrit :

> Alors je pense que l'icone est peut être pas assez suggestive. 1) y a
> pas de forme de bonhomme (juste un trait vertical), et 2) la main est
> quasi invisible.
>
> Je proposerais bien, tout en conservant donc l'idée d'apporter des
> plugins, de simplifier pour ne conserver que la main, la manche et le
> plateau, un peu comme sur :
>
> - https://www.flaticon.com/premium-icon/drinks_4130409
> - ou https://www.flaticon.com/free-icon/waiter_1378849
>
> Évidemment en changeant le contenu sur le plateau par les icones des
> différents plugins de SVP, notamment la prise, comme il y avait
>
> Un avis Eric, erational ou autre ?
>
>
Le temps a passé.
J'aimais bien le côté isotype de l'icône, ça faisait retro.

Maintenant on a une belle version SPIP 4.0 avec des logos retravaillés.
Donc oui voyons à le retravailler aussi et si en plus il est pas explicite,
aucun souci pour le revoir.
Le seul truc que j'aimerais qu'on conserve c'est que SVP, SVP API, SVP
typologie, SVP Stats et SVP Skel conserve un air de famille.

Après, je me dis que le côté serveur de SVP va un jour disparaître avec
Composer, ne faudrait-il pas mieux insister sur le côté plugins plutôt que
serveur pour préparer la suite ?
Si on passe à composer, il ne restera plus que SVP référentiel,
c'est-à-dire la fonction qui crée et met à jour la BD.

Donc gogogo

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] [Spip-zone-commit] [bellespuces] valide SPIP 4.0

2021-05-06 Par sujet Eric Lupinacci
Ca a encore du sens de mettre à jour le plugin.xml ?
Enfin je veux dire, ne devrait-on pas faire une branche pour ces plugins
avec juste le paquet.xml et le bon intervalle de compatibilité ?

++
Eric


Le jeu. 6 mai 2021 à 16:57, chankalan  a écrit :

> spip-contrib-extensions/bellespuces
> -
> Par chankalan, le 6 mai 2021 à 16h55min :
>
> valide SPIP 4.0
>
>
> *Modifié*
> paquet.xml
> plugin.xml
>
> Détails :
> https://git.spip.net/spip-contrib-extensions/bellespuces/commit/64d4a2a005be7a67ee8b80f98f8a8236c17473a2
>
> ___
> spip-zone-com...@rezo.net -
> https://listes.rezo.net/mailman/listinfo/spip-zone-commit
>
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] [spip-bonux] [ui] logo on laisse tomber la lessive pour une cerise (...)

2021-05-06 Par sujet Eric Lupinacci
Yop,



Le jeu. 6 mai 2021 à 13:36, RastaPopoulos  a écrit :

>
> Là où je me pose plus la question c'est : si l'image est *aussi* déjà
> utilisé dans l'interface pour des liens/boutons, dans ce cas elle va aussi
> être dans prive/theme : est-ce qu'il faut pas prévoir de quand même pouvoir
> déclarer cette image dans le XML dans le futur, histoire de réutiliser une
> existante, sans doublonner ? Sinon on va devoir mettre une même image à la
> fois à la racine et dans prive/theme si on l'utilise aussi ailleurs.
>
>
Oui, parce que sémantiquement ce n'est pas la même.
C'est souvent le cas pour un objet.
Les icones sont dans les thèmes et peuvent très bien avoir la même image
temporairement que le logo mais on sait que cela peut changer dans un autre
thème.

Pour l'instant je ne changerais pas pour l'attribut dans le XML, on pourra
faire en sorte de chercher le logo par défaut plus tard.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] [Spip-zone-commit] [spip-bonux] [ui] logo on laisse tomber la lessive pour une cerise (...)

2021-05-06 Par sujet Eric Lupinacci
Je renouvelle ma demande de passer les logos à la racine du plugin svp.

++
Eric


Le jeu. 6 mai 2021 à 09:26, erational  a écrit :

> spip-contrib-extensions/spip-bonux
> -
> Par erational, le 6 mai 2021 à 09h24min :
>
> [ui] logo on laisse tomber la lessive pour une cerise sur le gateau
>
>
> *Ajouté*
> img_pack/spip-bonux-xx.svg
> *Supprimé*
> img_pack/logo-bonux.gif
> *Modifié*
> lang/paquet-spip_bonux_fr.php
> paquet.xml
>
> Détails :
> https://git.spip.net/spip-contrib-extensions/spip-bonux/commit/5ce760b9920f861559ed2ad7e19b5df2f3f32671
>
> ___
> spip-zone-com...@rezo.net -
> https://listes.rezo.net/mailman/listinfo/spip-zone-commit
>
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] [Spip-zone-commit] [saisies] [ui] icone SVG dans la continuite. si qqun veut (...)

2021-05-04 Par sujet Eric Lupinacci
Hello,

On pourrait pas profiter de la mise à jour des logos de plugin pour les
positionner à la racine du plugin et pas dans les thèmes car un logo n'est
pas thémable ?
Et avec le nommage proposé que je vois ici, il nous sera même possible plus
tard de ne plus utiliser l'attribut logo de la balise paquet.

++
Eric


Le mar. 4 mai 2021 à 13:57, erational  a écrit :

> spip-contrib-extensions/saisies
> -
> Par erational, le 4 mai 2021 à 13h56min :
>
> [ui] icone SVG dans la continuite. si qqun veut changer, ne pas hesiter
>
>
> *Ajouté*
> prive/themes/spip/images/saisies-xx.svg
>
> Détails :
> https://git.spip.net/spip-contrib-extensions/saisies/commit/a42930bb7dc14cd679c6d20b302ae5ce2758f246
>
> ___
> spip-zone-com...@rezo.net -
> https://listes.rezo.net/mailman/listinfo/spip-zone-commit
>
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-05-01 Par sujet Eric Lupinacci
Yo,

Le ven. 30 avr. 2021 à 20:18, Matthieu Marcillaud  a
écrit :

> Le 30/04/2021 à 19:04, Bruno Bergot a écrit :
> J'ai enlevé donc les plugins qui n'étaient pas discutés.
>

+1

Squelettes par rubriques
> 
> Je pense qu'on peut proposer "squelettes par rubriques" uniquement en
> plugin et l'enlever des plugins-dist. La fonctionnalité ne disparait
> pas, et peut être réactivée donc facilement au besoin.
>
>
+1



>
> Compagnon
> -
> On peut peut être ajouter un bouton supplémentaire sur le message de
> bienvenue d'un auteur sur l'accueil (et celui-ci seulement) qui dit en
> gros (formulation sympa à trouver) "Je connais SPIP ! (ne plus
> m'afficher le compagnon nulle part)"
>

+1
Je pense qu'il très chouette ce plugin et peut être utilisé plus
intensément.
Je l'ai utilisé récemment pour prévenir de lancer une action de mise à jour
de la base qu'il n'était pas possible de faire automatiquement.
Et franchement les reproches sur l'UI sont assez incompréhensibles pour moi.


>
>
> Aide
> 
>
> Il semble qu'il faut conserver le plugin au moins pour pouvoir gérer
> l'aide des raccourcis typographique ; potentiellement uniquement
> ceux-là. Mais ça veut dire qu'il faut… revoir le plugin pour que ça soit
> à jour. (je dirais : gasp ! faut un peu de temps quoi !)
>

+1.
Le mieux serait de proposé une alternative simple pour les raccourcis.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-30 Par sujet Eric Lupinacci
Yop,

Le ven. 30 avr. 2021 à 10:05, Matthieu Marcillaud  a
écrit :

>
> > Ou alors faire comme pour Saisies et sa page d'explication accessible
> > via un menu.
>
> Mouais : y a déjà un lien "aide" dans le bandeau. Et ça irait dans quel
> menu ? (en statut rédacteur)
>
>
Non aucun menu comme je le dis après, juste le ?. Je parle juste de la
présentation si on ne garde pas la popup.


> > Là on aurait juste une page qui rappelle les raccourcis et qui serait
> > accessible par le ?.
>
> Alors… je me demandais si le bouton [?] n'était présent qu'en tant
> qu'icone du porte plume (et plus ailleurs), si ça serait suffisant ?
>

Ca pourrait vu qu'on ne s'en sert que là à priori.


>
> > On pourrait même imaginer que certains plugins qui ajoutent des
> > raccourcis puissent s'y insérer pour lister les leurs.
>
> Certes. Enfin encore une fois il faut gérer les traductions également.
> Ça peut être dans les fichiers de langue des plugins aussi.
> Et si tu veux lier des images ou montrer le résultat du code, c'est plus
> difficile je suppose en chaine de langue.
>

Une idée rapide serait un tableau avec un index pour chaque raccourci.
Chaque index contient les items de langue qui expliquent le raccourci. Ce
qui permet de facilement traduire cette aide.
Et le tableau de raccourci peut être complété par un pipeline pour les
plugins qui en rajoutent.
Au moins ça fait une aide complète sur un sujet majeur et facilement
maintenable et évolutive.

C'est déconnant ?

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-30 Par sujet Eric Lupinacci
Le ven. 30 avr. 2021 à 08:50, Arnaud Martin  a
écrit :

>
> Concernant l’aide, en fait il y a *une* seule page qui est franchement
> utile: la page des «raccourcis typographiques». Parce que même après 20 ans
> à faire du SPIP quotidiennement, je connais pas les fusions de cases des
> tableaux, ni les appels de notes de bas de page.
>
> On pourrait quasiment virer l’aide mais ne conserver qu’un lien vers les
> raccourcis. (Actuellement, à côté de «Texte», on a une aide contextuelle
> qui dit «Le texte de l’article […] comme son nom l’indique». Et la plupart
> des entrées sont à l’avenant. Sauf… la page des raccourcis typographiques
> donc…


Ou alors faire comme pour Saisies et sa page d'explication accessible via
un menu.
Là on aurait juste une page qui rappelle les raccourcis et qui serait
accessible par le ?.
On pourrait même imaginer que certains plugins qui ajoutent des raccourcis
puissent s'y insérer pour lister les leurs.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-30 Par sujet Eric Lupinacci
Yop,


Le jeu. 29 avr. 2021 à 23:02, Manu  a écrit :

>
> C'est pas faux, mais, en se faisant un peu l'avocat du diable, on peut
> aussi s'interroger sur l'intérêt de supprimer quelque chose dont on
> reconnait une utilité simple et accessible (et largement utilisée ???)et
> que beaucoup vont réactiver assez vite, pourquoi ne pas le laisser ?
>
>
Pour moi il y a quand même une bonne raison : la maintenance.
Je pense que pour cette raison et donc pour les releases successives
mieux vaut se concentrer sur une liste plus limitée de plugins.

Après on n'échappera jamais à la question de pourquoi l'un et pas l'autre
mais faut faire des choix.
Et c'est le moment pour en faire.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-29 Par sujet Eric Lupinacci
Re,


Le jeu. 29 avr. 2021 à 21:07, Maïeul Rouquette  a écrit :

> Le 29.04.21 à 21:04, nicod_ a écrit :
> > J'avoue que c'est le seul sur lequel j'ai un doute...
> > Il risque de péter des vieux squelettes, et comme tu dis c'est une
> > technique utile.
> > Mais bon, y'a déjà des choses qui cassent, et le plugin compositions est
> > quand même vraiment fait pour ça.
> > Ce sera précisé dans les notes de mises à jour.
> >
> j'ai tendance à dire que oui c'est pratique pour du dev rapide... mais
> ca coince vite les gens sur des choses pas idéales.
>
>
Non mais de toute façon rien ne sera cassé.
Il faut juste installer le plugin hors plugin-dist.
Il n'y a donc aucune régression et tout le monde peut continuer à utiliser
le plugin.

Le seul truc qui peut se passer c'est si quelqu'un ne lit pas l'annonce il
aura une surprise temporaire sur son site.
Mais ça ne durera pas et de toute façon rien n'est rédhibitoire car c'est
juste de l'affichage.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-29 Par sujet Eric Lupinacci
Hello,


Le jeu. 29 avr. 2021 à 17:56, RastaPopoulos  a
écrit :

> Le 29/04/2021 à 17:44, Eric Lupinacci a écrit :
> > Maintenant, franchement je ne vois pas pourquoi le JSON poserait des
> problèmes à partir du moment où obtient les mêmes tableaux de wheels en
> décodant le YAML ou le JSON.
>
> Pour l'instant, un des arguments répondu, était que les wheels font
> parfois de nombreuses choses compliquées, dans un ordre précis, et que le
> YAML permet de faire des commentaires entre chaque morceau, ce qui n'est
> pas le cas du JSON.
>
> https://git.spip.net/spip/textwheel/src/branch/master/wheels/spip/spip-listes.yaml#L31
>
> Après les wheels… c'est un système qui me parait obsolète de nos jours, où
> il y a des vrais parseurs de grammaire désormais performants (avec PHP 7,
> PHP 8), et on devrait utiliser ça dans le futur plutôt que des regexs.
>
> Concrètement les wheels actuelles, donc qui ont des commentaires dans le
> YAML, ces fichiers n'ont pas bougé depuis… 10 ans… 7 ans… suivant les
> fichiers.
> Du coup c'est peut-être pas grave de ne plus avoir ces commentaires. En
> tout cas placés à cet endroit.
>
>
Oui cy_altern a remonté le même sujet.
Après il faut relativiser le nombre de commentaires.
Mais comme le propose cy_altern on peut insérer ces commentaires dans un
index "_commentaires:".
Moi j'avais proposé un readme.

Donc je pense que ça doit pouvoir se gérer facilement.
Après oui c'est obsolète les wheels si on se positionne pour intégrer
markdown mais c'est une première étape de nettoyage.
Je ne suis pas sur qu'on change aussi facilement de langage.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] SPIP 4 — proposition d'enlever quelques plugins-dist par défaut

2021-04-29 Par sujet Eric Lupinacci
Hello,


Le jeu. 29 avr. 2021 à 17:07, Matthieu Marcillaud  a
écrit :

>
> JQuery UI
> -
>
> Déjà avant tout soulignons que nous avons déjà enlevé "jquery-ui" des
> plugins-dist car cette librairie javascript n'est plus maintenue, et
> nous avons ajouté les alternatives JS (un "picker" de date et un
> "sortable") dans le core pour les utilisations principales qu'il y avait.
>
>
Ah c'est une bonne raison, par contre, ce n'est pas la seule dans ce cas,
j'y reviendrai plus loin.



>
> Vertèbres
> -
>
> Un outil de visualisation des tables SQL de SPIP. Ce plugin n'a
> pratiquement pas bougé depuis sa sortie. Il est avantageusement
> remplaçable par le plugin "Adminer".
>
>
+1


>
> Organiseur
> --
>
> Les plugins comme Agenda ou Manuel du site sont parfois selon le besoin
> aussi une alternative.
>
>
Ou Pense-bêtes. Donc +1


>
> Brèves
> --
>
>
+2


> Squelettes par rubriques
> 
>
> Ça permet de faire des squelettes tel que "article=3.html". Gourmands en
> performance pour retrouver ces squelettes, on préfère utiliser
> maintenant d'autres méthodes, notamment avec le plugin Compositions.
>
>
+1


>
> Pétitions
> -
>

+1, c'est rare d'utilisation donc pas forcément nécessaire en Dist.


> Compagnon ?
> -
>
>
Non je pense qu'il faut le garder.


> Aide ?
> 
>
>
Devrait être indispensable mais est-il vraiment consulté dans l'état.
Néanmoins, psychologiquement je dirais qu'il faudrait le garder.

Et donc pour la fin je reviens sur TextWheel et sa librairie sfyaml ultra
moisie en m'inscrustant dans le fil de Mathieu qui a surement plus de
chance d'être répondu que le mien...
Pourquoi la conserver ainsi ?
Donc deux solutions, on prend la branche JSON que j'ai proposé et qui
assure la compatibilité voire le fallback avec l'existant YAML si on
trouvait des problèmes, soit on ajoute le plugin YAML dans le Core puisque
celui-ci nécessite ce format en le mettant à jour de ses librairies.
Maintenant, franchement je ne vois pas pourquoi le JSON poserait des
problèmes à partir du moment où obtient les mêmes tableaux de wheels en
décodant le YAML ou le JSON.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Refonte du jeu d'icônes : retours et commentaires

2021-04-29 Par sujet Eric Lupinacci
Yo,

Le jeu. 29 avr. 2021 à 15:21, Bruno Bergot  a écrit :

> Hop,
> Espérons que les retours resterons dans le cadre que tu indiques :)
>
>
Moi j'aime pas le jaune =>[]

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] TW et YAML

2021-04-24 Par sujet Eric Lupinacci
Hello,


Le sam. 24 avr. 2021 à 00:23, nicod_  a écrit :

> Le 23/04/2021 à 16:55, Eric Lupinacci a écrit :
> > Hello,
> Attention quand même, y'a des gens (dont moi) qui utilisent Textwheel et
> qui ont créé leurs propres règles YAML/PHP.
>
> Passer sur json me parait une bonne idée (natif et plus rapide en PHP),
> mais faudrait pas tout casser comme ça.
>
>
Tu n'as pas du lire la PR alors où j'explique le principe.
Si tu ne veux pas passer en JSON tu peux, il te suffira juste d'ajouter le
plugin YAML si ce n'est pas déjà le cas.
Le seul truc en rupture est le retrait de la librairie sfyaml mille fois
moisie de TW donc de la Dist.

Après pour migrer, si tu le veux, tu ajoutes la wheel en json et elle sera
prise par défaut.
Sinon ça marche toujours avec la wheel yaml.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

[spip-dev] TW et YAML

2021-04-23 Par sujet Eric Lupinacci
Hello,

Bon j'ai pas suivi l'avis qui m'avait été donné et j'ai fait une PR à TW
sur une branche nommée json.
J'ai gardé une compatibilité suffisante il me semble et franchement je ne
pense pas que ce soit dangereux.
Par contre, je n'ai pas réussi à passer les tests internes de TW car je ne
sais pas comment faire.
Mais ça pourrait confirmer que ça fonctionne si quelqu'un peut les lancer.

Comme ça on se débarrasse de la librairie et je mets à jour le plugin YAML
dans la foulée avec les seules librairies maintenues.
Moi je pense que c'est le moment de le faire

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Pagination nouvelle

2021-04-17 Par sujet Eric Lupinacci
Yo,

Le sam. 17 avr. 2021 à 13:59, nicod_  a écrit :

> Non, la nouvelle spéc est finalement bien d'utiliser une balise
> englobante  au lieu de  class="pagination">, cf :
> https://www.spip.net/fr_article3367.html
>
> Où vois tu une pagination pas stylée (à corriger si besoin) ?
>
>
Par exemple les articles récents sur la page d'accueil.
J'ai pas les CSS pour la nav mais bien pour le div.

Je pige pas, sauf si la PR n'est pas intégrée.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

[spip-dev] Pagination nouvelle

2021-04-17 Par sujet Eric Lupinacci
Hello,

J'avais cru comprendre que l'on passait de la balise p à la balise div pour
la pagination.
Or dans spip je vois une balise nav qui d'ailleurs n'est pas correctement
stylée.
C'est juste temporaire en attente d'une PR ou y a effectivement un souci ?

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Demande de compte sur git.spip.net

2021-04-16 Par sujet Eric Lupinacci
Sujet résolu, le compte existait et provenait du SVN.

++
Eric


Le jeu. 15 avr. 2021 à 12:42, Julien Lanfrey  a écrit :

> Bonjour tout le monde,
>
> Je souhaiterais avoir un compte sur git.spip.net pour pouvoir participer.
> Est-ce possible ? Charte acceptée bien sûr.
>
> Merci,
>
> Julien
> ___
> 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

Re: [spip-dev] Compte sur Git.spip.net

2021-04-08 Par sujet Eric Lupinacci
Le compte existe déjà et fonctionne, Amaury vient de le tester.
Le sujet est réglé.

++
Eric


Le jeu. 8 avr. 2021 à 10:35, Amaury Adon via spip-dev  a
écrit :

> Bonjour le monde,
> je souhaiterai avoir un compte sur le git de SPIP pour pouvoir participer
> à la vie de la communauté. Bien évidemment j’adhère à la charte de celle-ci.
> Bonne journée
> Amaury
> ___
> 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

Re: [spip-dev] [Spip-zone-commit] [polyhierarchie] Des notices PHP en moins dans les PHP récents, mais on (...)

2021-04-02 Par sujet Eric Lupinacci
Hello,

Oui je suis assez d'accord car si on ne le fait pas on va se trainer ce
truc voire plus s'en souvenir.

++
Eric


Le ven. 2 avr. 2021 à 09:17, Bruno Bergot  a écrit :

> Yop
>
> Le 01/04/2021 à 23:52, Matthieu Marcillaud a écrit :
> > spip-contrib-extensions/polyhierarchie
> > -
> > Par Matthieu Marcillaud, le 1er avril 2021 à 23h50min :
> >
> > Des notices PHP en moins dans les PHP récents, mais on garde une compat
> pour SPIP 3.0 :/
> >
>
> Ça serait pas l'occasion de créer une branche ? Sachant que SPIP 3.0
> n'est plus maintenu...
>
> ++
> 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

[spip-dev] SPIP 3.3 - Pb CSS formulaires

2021-03-21 Par sujet Eric Lupinacci
Hello,

Un commit plus ou moins récent doit provoquer une régression dans la
visualisation des groupes de checkbox dans les formulaires du privé.
Ils ne sont plus alignés avec les checkbox mais sont décalés complètement
sur la gauche avec le label de la saisie.

Voir un exemple avec le lien : https://imgur.com/a/AtSKvRQ

Je ne sais pas comment corriger, donc si quelqu'un a une idée.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Acces a git.spip.net

2021-03-17 Par sujet Eric Lupinacci
Oyez, Oyez,

La demande a été traitée.
Vous pouvez vous rendormir ;-)

++
Eric


Le mar. 16 mars 2021 à 11:22, Michael via spip-dev  a
écrit :

> Bonjour,
>
> Je souhaite pouvoir contribuer sur des plugins et souhaiterai avoir un
> acces a git.spip.net.
>
> J'ai lu et accepte la charte.
>
> Pouvez-vous m'ouvrir cet acces ?
>
> Cdt,
>
> Michael
> ___
> 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

Re: [spip-dev] Notre cycle de release

2021-03-15 Par sujet Eric Lupinacci
Le lun. 15 mars 2021 à 17:26, erational  a écrit :

>
> Je suis aussi très motivé pour ces propositions !
>
>
  Go !

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Demande d'inscription

2021-03-09 Par sujet Eric Lupinacci
Hello,



Le mar. 9 mars 2021 à 14:25, nicod_  a écrit :

> Ce serait possible sur Gitea bien sûr, mais c'est développé en Go.
> S'il y a des volontaires... c'est open source :p
> Ceci dit, ça pourrait être un formulaire HTML sur Gitea, avec une action
> POST sur un script PHP hors de Gitea (?).
>
> Avec un formulaire comme ça, on pourrait créer le compte et peut être
> inscrire à la liste de dév automatiquement ?
> Il y a une api REST sur mailman 3 mais pas sur la 2.
> Mais ceci semble pas mal : https://github.com/splattner/mailmanAPI
>
>
Et le jour où on change de forge ?
On recode tout ? On utilise la forge comme elle est et on modifie notre
processus ?
C'est possible mais une forge comme espace user-friendly ça se pose là.

Moi ça ne me choquerait pas de m'inscrire pour "contribuer" à SPIP sur le
site portail des contributions.
Le comment ensuite on contribue, ça a été SVN pendant des années,
maintenant c'est git je dirais que c'est un autre sujet.
J'y vois l'intérêt de regrouper intelligemment les choses et de mettre en
place exactement le processus voulu:
- je choisis mon type d'inscription (ticket, code)
- j'accepte la charte après l'avoir lu
- je fournis les coordonnées qui vont bien et qui évitent des
allers-retours par mail
- je reçois mon mot de passe avec toutes les infos pour contribuer.

Et si j'ai oublié des choses on peut améliorer.
C'est juste un formulaire et une interface avec le Gitea.
J'ai déjà un plugin gitea_maintenance qui permet de "surveiller" la forge,
il peut être utilisé pour accueillir ce workflow et il est déjà déployé sur
Contrib.
C'est sur qu'il faudra trouver un endroit sur la page d'accueil de Contrib
pour aiguiller vers le formulaire.

Je trouve ça mieux.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Demande d'inscription

2021-03-08 Par sujet Eric Lupinacci
Yop,



Le lun. 8 mars 2021 à 19:14, RastaPopoulos  a
écrit :

> C'était pas ma question :)
>

En fait j'ai pas lu ta question, juste le début :)


> J'ai bien dit dans mon message que du coup je l'ai fait, mais donc un par
> un pour chaque team de chaque orga. Ce qui est galère et me parait pas
> solide.
>
> Mais donc ma question c'est ça : c'est quoi le vrai processus officiel ?
> C'est de tout faire un par un ? Ou bien y a une manière d'ajouter la
> personne à un seul endroit et que ça synchronise toutes les teams d'un coup
> ?
>

Via la voie manuelle oui, il faut faire ainsi.
Après je suppose qu'il est possible d'automatiser car l'API REST permet de
tout faire.
D'ailleurs on pourrait mettre en place un processus (formulaire) à partir
d'un autre site comme Contrib en utilisant l'API REST de Gitea.
Ce serait plus pérenne et peut-être que ça nous permettrait de
personnaliser comme on veut.

Camille ?

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Demande d'inscription

2021-03-08 Par sujet Eric Lupinacci
Oui j'ai merdé je suis allé trop vite en créant le compte sans l'affecter.
C'est fait ou pas ?

++
Eric


Le lun. 8 mars 2021 à 18:08, RastaPopoulos  a
écrit :

> Le 01/03/2021 à 19:23, Eric Lupinacci a écrit :
> > Demande traitée et approuvée.
>
> Et… non, pas approuvée justement, jusqu'à tout à l'heure : créer un
> compte dans git.spip ne suffit pas, la personne doit faire partie de toutes
> les orgas de contrib, à l'intérieur d'un sous-concept de team "contrib" qui
> est dans chaque orga.
>
> Soit il manquait une action de la part d'Éric (un script ou je ne sais
> quoi à lancer ?), soit il l'a bien fait mais ça n'a pas fonctionné.
>
> Le processus d'ajout d'une nouvelle personne continue d'être encore
> mystérieux, on dirait. Pour l'instant comme je suis admin, j'ai pu par
> l'interface ajouter Elsa à toutes les teams une par une, mais du coup c'est
> galère et ce n'est pas solide : risque de désynchro, possibilité que pas
> les mêmes gens dans chaque team de chaque orga.
>
> Du coup quel est le vrai processus clean ? Est-ce qu'il y a une liste de
> référence où on doit ajouter la nouvelle personne ? Et alors ça s'ajoute
> auto par un script de synchro ? Est-ce qu'il y a cette synchro ? Manuelle
> ou auto ? Si oui qui peut la lancer ? Que un admin sys sur le serveur ?
>
> Tant de questions :)
>
> --
> RastaPopoulos
>
> ___
> 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

Re: [spip-dev] Un accueil pour réaliser les traductions de SPIP ouvert à toutes et à tous ?

2021-03-08 Par sujet Eric Lupinacci
Hello,

Le lun. 8 mars 2021 à 18:00, Bruno Bergot  a écrit :

> Hop,
>
> Intégré, merci :)
>
> https://trad.spip.net/
>
> Reste à voir comment on indique aux trads que cet éléments a été modifié
> pour que ça soit mis à jour dans les traductions.
>
>
Ouais mais bof.
Il y a une boussole qui est là justement pour ne pas éparpiller les
descriptions, noms, slogans partout et donc aussi éviter d'accumuler les
traductions.
Je serais plutôt d'avis de reprendre les éléments de la boussole non ?

En tout cas, elle aussi a été mise à jour de façon cohérente et va donc
être... traduite comme Touti l'a proposé et on a même fait une passe
complémentaire sur les autres sites.

La bise
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

[spip-dev] La Boussole

2021-03-06 Par sujet Eric Lupinacci
Hello,

Pour la prochaine sortie de la 3.3 et aussi parce que c'est bien ;-), on
pourrait remettre un peu d'ordre dans la boussole SPIP.
Suite à la proposition de Touti sur Traduire SPIP, avec maieul on a fait
une passe "inclusive" sur les descriptions et les slogans des sites.

Maintenant, il est nécessaire de revoir :
- la liste exacte des sites vraiment actifs et déprécier ceux qui ont été
abandonnés pour une raison ou une autre
- revoir les regroupements si nécessaire
- faire une passe sur les logos si besoin
- revoir éventuellement la présentation de boussole.spip.net
- ajouter un lien vers la charte ?
- traduction de la boussole à encourager

Je vous propose ce fil pour collecter les propositions.
Je commence:

1) *Liste*
- *spip-info* : à supprimer de la boussole
- *stats.spip.net * : à ajouter à la boussole
- *git.spip.net  *: à ajouter à la boussole
- *SPIP zone* : ne faudrait-il pas le supprimer de la boussole ?

2) *les regroupements*
On avait initié un fil il y a 2 ans sur ce sujet y compris celui de la
charte.
Je reprends les remarques de Rasta:



*"J'ai un peu du mal avec la typologie en fait : - On ne peut pas vraiment
considérer que dans "Documentation" c'est que des choses du noyau et dans
"Contribution" des trucs de plugins, puisque*





*par exemple dans "Contribution" il y a "SPIP Core" qui concerne uniquement
le noyau/dist et où on peut bien contribuer en faisant des tickets de bugs
ou améliorations. - Mais s'il s'agit vraiment d'une séparation de *type* de
lieu, alors "Code des plugins" n'a rien de contributif : ce n'est ni en
endroit où on peut commiter, ni un endroit où on peut écrire des articles,
il*


*s'agit donc bien uniquement d'un truc en lecture, donc une documentation
(technique, des API). D'ailleurs c'est marqué dans la description "La
documentation de…". Donc soit ya un problème de placement, soit c'est le
découpage qui est à revoir. Je sais pas…"*

3) *Liens particuliers dans la bande de navigation*
Il serait bien d'ajouter un lien vers la charte par exemple avec un item
Charte à droite de la bande ou alors en cliquant sur le logo à gauche.
D'ailleurs je ne vois pas l'intérêt que ce logo renvoie vers spip.net.
Pour ce qui est de la charte, il faudrait que l'affichage soit cohérent
avec la langue utilisée.

Un truc aussi étrange c'est que cette bande ne renvoie jamais vers la
boussole.spip.net qui a l'avantage en une page de visualiser la liste des
sites et leur description.
Peut-être que le logo spip pourrait justement lier le site boussole et pas
spip.net.

A vous lire, pour élaborer une proposition complète.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Un accueil pour réaliser les traductions de SPIP ouvert à toutes et à tous ?

2021-03-06 Par sujet Eric Lupinacci
C'est fait.
En relisant les descriptions il y a encore beaucoup de "utilisateurs" et
"développeurs".
On peut mettre quoi à la place ?

++
Eric


Le sam. 6 mars 2021 à 08:52, Eric Lupinacci  a écrit :

> Hello,
>
> Le sam. 6 mars 2021 à 06:37, Jacques B  a écrit :
>
>> Le 06/03/2021 à 02:32, tout...@free.fr a écrit :
>>
>> B*Proposition*
>>
>> Espace de traduction de SPIP et de ses contributions
>>
>> L’espace de traduction accueille toutes les personnes qui souhaitent
>> aider la communauté SPIP en participant aux travaux de traduction du
>> logiciel et de ses diverses contributions.
>>
>> Bonjour touti,
>> Je trouve cette proposition très bien.
>> Par contre je ne vois pas où sont les chaînes de langue ? Ce serait géré
>> en  dans le descriptif du site ?
>>
>>
> Non c'est le plugin Boussole SPIP.
> Je vais faire la modification.
>
> ++
> Eric
>
>
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Un accueil pour réaliser les traductions de SPIP ouvert à toutes et à tous ?

2021-03-05 Par sujet Eric Lupinacci
Hello,

Le sam. 6 mars 2021 à 06:37, Jacques B  a écrit :

> Le 06/03/2021 à 02:32, tout...@free.fr a écrit :
>
> B*Proposition*
>
> Espace de traduction de SPIP et de ses contributions
>
> L’espace de traduction accueille toutes les personnes qui souhaitent aider
> la communauté SPIP en participant aux travaux de traduction du logiciel et
> de ses diverses contributions.
>
> Bonjour touti,
> Je trouve cette proposition très bien.
> Par contre je ne vois pas où sont les chaînes de langue ? Ce serait géré
> en  dans le descriptif du site ?
>
>
Non c'est le plugin Boussole SPIP.
Je vais faire la modification.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Version PHP minimum SPIP 3.3

2021-03-05 Par sujet Eric Lupinacci
Hello,


Le ven. 5 mars 2021 à 09:51, RealET  a écrit :

> RastaPopoulos a écrit le 05/03/2021 à 08:46 :
> > Le 04/03/2021 à 17:54, RealET a écrit :
> >> Après, d'un point de vue politico-phylosophique, SPIP a toujours
> cherché à pouvoir être utilisé dans des environnements accessibles au
> maximum de personnes et de pays.
> >> De ce point de vue, la compatibilité PHP 5.6 est peut-être bienvenue.
>


>
> Et pour eux, changer de version de PHP, c'est pas facile...
>
>
*S*ystème de *P*ublication pour un *I*nternet *P*aléolitique
 =>[]

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Amélioration de l'accueil des nouvelles personnes suite à git.spip.net

2021-03-03 Par sujet Eric Lupinacci
Yop,



Le mar. 2 mars 2021 à 19:24, Maïeul Rouquette  a écrit :

> Bah en gros
> 1. C'est pas documenté (mais bon ca on pourrait résoudre)
> 2. Quand je contribue à un projet libre juste pour ouvrir des tickets
> (parce que je connais pas le language derrière, parce que j'ai pas envie
> de m'impliquer en codant), j'ai pas forcément envie de me taper tous les
> commits et les discussions de tout le monde sur les avancés : je veux
> juste ouvrir un ticket.
>
>
Soit, mais je ne vois pas le rapport avec l'inscription ouverte.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Amélioration de l'accueil des nouvelles personnes suite à git.spip.net

2021-03-02 Par sujet Eric Lupinacci
Hello,


Le mar. 2 mars 2021 à 17:58, RastaPopoulos  a
écrit :

> Le 02/03/2021 à 17:53, nicod_ a écrit :
> > Juste un bémol : quand les inscriptions étaient ouvertes, ça spammait
> grave, il faut donc résoudre ça d'abord.
>
> Oui je me souviens effectivement.
>

Oui c'est clair.
On avait nettoyé ça avec Camille.
C'est dingue comme les Russes aimaient spip...
Franchement c'est pas super cool comme boulot de vérifier les usera après
coup.


>
> Mais du coup : pourquoi ? Je veux dire : pourquoi plus que sur nos autres
> sites (et que toutes les autres forges du monde qui ont toutes des
> inscriptions ouvertes) ? Si les autres forges y arrivent, on devrait
> pouvoir non ?
>
> Au pire, même si on trouve mieux plus tard, mais pour avoir un truc qui
> marche plus vite : j'ai tendance à penser que c'est mieux un captcha ou ce
> genre de crotte, que pas d'inscription à cause des spams et donc rien du
> tout et des complications encore plus rebutantes pour les gens comme
> actuellement.
>

Oui ça pourrait être une façon.
Mais en quoi c'est rebutant aujourd'hui ?
On a des retours ?
Parce qu'en général on réagit assez vite pour l'ouverture du compte et il
n'y a pas des tonnes de demandes.

En tout cas, sans protection en tout je ne suis pas vraiment favorable à
une inscription ouverte.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Demande d'inscription

2021-03-01 Par sujet Eric Lupinacci
Demande traitée et approuvée.

++
Eric


Le lun. 1 mars 2021 à 14:34, Elsa Delmas 
a écrit :

> C'est tout bon, merci beaucoup !
>
> À bientôt,
> Elsa
>
> Le lun. 1 mars 2021 à 14:31, Eric Lupinacci  a écrit :
>
>> Voilà.
>>
>> J'ai mis la seconde adresse car en général on évite les adresses pro.
>> Le mot de passe est spip2021, tu dois le changer.
>> Tu peux aussi rajouter un nom complet si tu veux.
>>
>> Dis-moi quand tout est ok.
>> Merci.
>>
>> ++
>> Eric
>>
>>
>> Le lun. 1 mars 2021 à 14:27, Elsa Delmas <
>> elsa.del...@monde-diplomatique.fr> a écrit :
>>
>>> Bonjour Éric,
>>>
>>> Merci pour ta réponse ! Pour le mail, elsa.del...@mondediplo.com (si le
>>> fait que ce soit une adresse professionnelle liée à une organisation ne
>>> pose pas de problème ; sinon elsa.del...@protonmail.com), et elsadl en
>>> username.
>>>
>>> Bonne journée,
>>> Elsa
>>>
>>> Le lun. 1 mars 2021 à 13:40, Eric Lupinacci  a écrit :
>>>
>>>> Hello,
>>>>
>>>> Peux-tu me donner :
>>>> - le username voire le nom que tu souhaites voir affiché
>>>> - l'email
>>>>
>>>> Je t'enverrais les coordonnées de connexion et tu changeras le mot de
>>>> passe pour en prendre un définitif.
>>>>
>>>>
>>>> ++
>>>> Eric
>>>>
>>>>
>>>> Le lun. 1 mars 2021 à 12:54, Elsa Delmas <
>>>> elsa.del...@monde-diplomatique.fr> a écrit :
>>>>
>>>>> Bonjour à toutes et à tous,
>>>>>
>>>>> Est-ce que je pourrais avoir un accès à git.spip.net ? J'ai lu et
>>>>> accepté la charte, et j'envisage de collaborer à des plugins.
>>>>>
>>>>> Merci !
>>>>> Elsa
>>>>> ___
>>>>> 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

[spip-dev] Paramètres des fonctions appelées par job

2021-02-27 Par sujet Eric Lupinacci
Hello,

Pour effectuer un traitement lourd asynchrone j'utilise job_queue_add()
comme indiqué dans l'API.
Néanmoins, la fonction appelée à comme prototype :

function territoire_peupler($type, $pays, $options = array())

Je passe donc les arguments $type, $pays et $options dans un tableau comme
demandé par l'API  des jobs.
Le job semble bien créé et on le voit dans la liste mais la page part en
erreur car on utilise un implode() sur les arguments et cela provoque une
erreur sur le troisième qui est un array.

Donc je me demande si c'est un cas non prévu uniquement à l'affichage ou si
par définition l'API s'attend toujours à des arguments dont le type n'est
jamais tableau ?

Merci d'avance.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

[spip-dev] Gestion des icones - SPIP 3.3

2021-02-20 Par sujet Eric Lupinacci
Hello,

Je viens de mettre à jour mon site spip en 3.3 avec les dernières mises à
jour ainsi que tous les plugins utilisés (Z-Core, Compositions,
noiZetier...).

Quand j'affiche la page des compositions j'obtiens des erreurs sur les
icones : https://imgur.com/a/ZccyNmN
Quand j'affiche le bloc de compositions dans un objet j'obtiens:
https://imgur.com/vidneYj

J'ai loupé un truc ou il y a un bug ou quelque chose de non mis à jour dans
un plugin ?

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] [Avenir de Multiflex] Re: [Spip-zone-commit] Accès git

2021-02-03 Par sujet Eric Lupinacci
Hello,

Le jeu. 4 févr. 2021 à 08:46, BERTRAND Joël  a
écrit :

> nicod_ a écrit :
> > J'ai reçu la réponse de "Bertrand Joel" sur ma boite perso mais je ne la
> > vois pas ici, je me permets de la transférer.
>
> Vous ne la voyez pas parce qu'une fois de plus, la modération est
> passée par là (mais cette fois-ci, au moins, j'ai un motif de rejet
> surréaliste d'en-têtes de mail non conformes, mais ce n'est toujorus pas
> signé). C'est bien, on me jurai encore il y a quelque temps que mes
> propos n'étaient pas censurés et que personne, au grand jamais, n'avait
> censuré quiconque. Lorsque vous censurez quelqu'un, merci au moins
> d'avoir le courage de le faire au grand jour et non par derrière. Là,
> j'ai la preuve de la censure qui lave plus blanc. Je vous laisse donc
> entre vous, entre gens bien pensants. Je constate que la discussion est
> totalement impossible. Le déviant que je suis va donc se retirer. Vous
> ferez ce que vous voulez de l'accès au git.
>

De quoi parle-t-on là ?
Quelle censure ?


>
> Je suppose que vous n'aurez pas le courage de publier ce message
> sur la
> liste, comme vous n'avez pas eu le courage de publier le dernier.
>

Ben non la preuve...

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Multiflex ou oswd_3626_multiflex-3

2021-01-19 Par sujet Eric Lupinacci
Hello,

Les dépôts sont identiques, même contenu, même nombre de révisions et de
branches et pas de tag.
Je pense qu'il avait été migré une première fois et quand j'ai passé les
squelettes au peigne fin j'ai dû recréer le dépôt avec le nom oswd étant
donné la structure en svn.

Vu le nombre de dépôts que j'ai migré à la main, il est possible qu'il y
ait des erreurs.
Mais mon suivi ne montre aucune autre raison pour expliquer cette situation
autrement que par une erreur.

Donc si vous voulez utiliser le dépôt "multiflex" dites le moi et on
archivera ou détruira l'autre dépôt.


++
Eric


Le mar. 19 janv. 2021 à 15:46, tcharlss  a
écrit :

> Le 19/01/2021 à 15:18, BERTRAND Joël a écrit :
> >   Certes ;-)
> >
> >   Mais ça ne répond pas à la question. Est-ce qu'on laisse tomber le
> OSWD ?
>
> Ah ben je sais pas, il y a quand même un petit peu anguille sous roche.
>
> On peut voir les infos détaillées des 2 repos là :
> https://git.spip.net/api/v1/repos/spip-contrib-squelettes/multiflex et
> là :
>
> https://git.spip.net/api/v1/repos/spip-contrib-squelettes/oswd_3626_multiflex-3
>
> Le repo multiflex a été crée *avant* oswd_3626_multiflex-3 (le 1er en
> janvier, l'autre en mars).
> Et ils semblent tous les 2 issus de la synchro svn (original_url:
> /tmp/subgit/_squelettes_/oswd/3626_multiflex-3)
>
> À ce compte là, il y en a bien un qui semble en trop, à n'en garder
> qu'un seul autant prendre multiflex tout court je dirais.
> Mais bon, je laisse celles et ceux qui s'en occupent confirmer ou pas :)
>
> ___
> 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

Re: [spip-dev] [Spip-zone-commit] Accès git

2021-01-18 Par sujet Eric Lupinacci
Bon on va se calmer là un peu tous.
Moi je suis d'accord avec... Camille, puisque c'est nous qui nous occupons
des comptes.
Si le compte n'a pas été créé sur git ou si il a été supprimé c'est une...
*ERREUR* (mode Rasta ;-))

Donc non Joel tu n'es pas une victime d'un autoritarisme et d'un sectarisme
sournois mais de deux péquins qui se sont plantés malgré leur cerveau
démesurément développé.
Je sais qu'à un moment j'ai aussi demandé à Camille de supprimer une liste
de fake users.
Donc on a probablement dérapé mais c'était avant le grand incident du point
médian qui a depuis refondé le monde que nous connaissons.

Nous nous excusons platement pour cet impair (donnable) et acceptons
d'emblée notre sentence.

++
Eric


Le lun. 18 janv. 2021 à 17:02, Maïeul Rouquette  a
écrit :

> Le 18/01/2021 à 16:09, RastaPopoulos a écrit :
> > Le 18/01/2021 à 16:02, tcharlss a écrit :
> >> Et bien si c'était le cas, sur le principe je trouverais ça très gênant.
> >> Supprimer un compte en catimini sans prévenir personne ? Pas très
> classe, j'espère que ça a pas été le cas ici.
> >
> > Moi non plus je ne trouverais pas ça légitime si ça a été fait sans
> annoncer clairement.
> >
> > Mais là priori il n'y a très probablement rien eu de bizarre :
> > - rien n'a changé sur les listes et il peut parfaitement poster
> puisqu'on voit et répond à ses messages… donc aucun rapport sur ce point
> > - Camille a clairement expliqué que *pour les anciens comptes de la
> forge*, donc spécifiquement pour le code, lors du passage en Git il y a eu
> du nettoyage de certains comptes non utilisés depuis fort longtemps et que
> donc il faut juste lui re-créer un compte pour le Gitea
> >
> > … si la charte est acceptée.
> >
> Je plussoie. Quoi que l'on pense du comportement de Joël (et je pense
> que j'étais en première ligne pour montrer que je le trouvais totalement
> inadapté) aucune décision unilatérale à ce sujet (aka sans commission)
> serait contraire à la charte.
>
> Mais cela tombe bien, cela n'a pas été le cas.
>
> Cela étant, La piqûre de rappel de Cédric était sans doute nécessaire
> sur le fond, même si la forme a pu semer le trouble le trouble.
>
> La charte de SPIP rappel des valeurs historiques de SPIP qui n'ont été
> formalisées que récemment dans cette charte. La modalité d'emploi de la
> charte, et notamment de la manière de gérer les violations de la charte,
> reste encore à mesurer à l'épreuve des faits. J'espère que le cas Joël
> ne nous y obligera pas.
> ___
> 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

[spip-dev] Saisies en PHP

2021-01-16 Par sujet Eric Lupinacci
Hello,

Je n'arrive pas à choper la documentation si elle existe sur la mise en
place de saisies en PHP en passant par la fonction
formulaire_xxx_saisies_dist().
Je n'ai pas de souci pour créer les saisies mais ce que je n'arrive pas à
faire c'est à fournir les valeurs courantes (enregistrées en BDD) pour les
fournir à chaque saisie.

Quand on passe par #GENERER_SAISIES on passe ces valeurs dans le ENV et la
balise se débrouille pour affecter les valeurs courantes à chaque saisie.
Quand tout se fait en PHP existe-t-il une fonction à appliquer aux saisies
pour le faire ou doit-on faire une boucle pour affecter l'option "defaut"
de chaque saisie concernée ?

Merci d'avance

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Gitea et le débardeur

2021-01-05 Par sujet Eric Lupinacci
Cool, c'est dur la vieillesse... désolé

++
Eric


Le mar. 5 janv. 2021 à 19:07, Bruno Bergot  a écrit :

> Hop,
>
> Le 05/01/2021 à 18:52, Eric Lupinacci a écrit :
> > Yop,
> >
> > Le mar. 5 janv. 2021 à 17:57, RastaPopoulos  a
> > écrit :
> >
> >> Le 05/01/2021 à 17:13, Eric Lupinacci a écrit :
> >>> 1) Le problème ne concerne pas les tags ni la génération systématique
> >> des zips par le débardeur. On pourrait même étendre à l'ensemble des
> tags
> >> si on voulait... Maintenant, ne pourrait-on pas éviter de regénérer les
> >> zips existant sur Gitea ?
> >>
> >> C'est pas déjà le cas, genre si le débardeur voit que ça existe sur
> gitea,
> >> il le récupère tel quel ?
> >>
> >>
> > Ben tu me mets le doute en fait.
> > Cédric ou Matthieu doivent savoir confirmer ou infirmer.
> >
>
> Le README du débardeur répond à la question :p
>
> https://git.spip.net/spip-contrib-extensions/debardeur
>
> "qui récupère les tags et les zips par l'API de Gitea"
> "qui récupère les tags et les zips par l'API de Github"
>
> Bref, si ça vient de gitea ou github, le débardeur ne génère pas les zips.
>
> ++
> 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

Re: [spip-dev] Gitea et le débardeur

2021-01-05 Par sujet Eric Lupinacci
Yop,

Le mar. 5 janv. 2021 à 17:57, RastaPopoulos  a
écrit :

> Le 05/01/2021 à 17:13, Eric Lupinacci a écrit :
> > 1) Le problème ne concerne pas les tags ni la génération systématique
> des zips par le débardeur. On pourrait même étendre à l'ensemble des tags
> si on voulait... Maintenant, ne pourrait-on pas éviter de regénérer les
> zips existant sur Gitea ?
>
> C'est pas déjà le cas, genre si le débardeur voit que ça existe sur gitea,
> il le récupère tel quel ?
>
>
Ben tu me mets le doute en fait.
Cédric ou Matthieu doivent savoir confirmer ou infirmer.



>
> - https://core.spip.net/issues/3017 dont la conséquence est que SVP
> devrait être amélioré pour connaitre plus qu'une unique mise à jour
> existante : en effet à un instant T, un plugin peut avoir une version
> majeure sortie X+N *et* une version Y+N ou même juste Z+N, et l'utilisateur
> ne veut PAS forcément changer de X, mais bien changer que Y voire même ne
> changer que Z pour être sûr de ne rien casser et avoir juste les
> corrections. Au niveau ergonomique, le travail est en gros fini, mais par
> contre, la conception de SVP ne le permet pas, donc pas possible de générer
> plusieurs boutons de mises à jour différentes à la fois. (Exemple de Sézi
> dans la maquette, qui a 4 mises à jour possible à la fois)
>
> Ce dernier point est le plus compliqué il me semble, car SVP c'est
> compliqué et qu'il y a eu un gros angle mort de conception sur ce point on
> dirait. Cependant j'ai l'impression que pour les utilisateurs finaux (qui
> ne suivent pas le code), c'est encore bien plus important qu'avoir le
> changelog complet : les gens devraient absolument pouvoir faire des mises à
> jour mineures, sans qu'on leur montre uniquement la majeure, et illes sont
> capables de choisir l'option la moins dangereuse pour elleux même sans
> changelog complet avec les phrases claires et simples (on comprend la
> différence entre "màj corrective/fonctionnelle/majeure" et donc la
> dangerosité ou pas à changer sans tout péter).
>

Je ne suis pas sur que ce soit si compliqué en fait sauf peut-être pour la
logique de dépendances.
On a commencé une réflexion avec Matthieu (qui a aussi débuté le codage)
pour continuer le découpage de SVP en un plugin chargé de construire le
référentiel (unique sur un serveur donné) et le plugin SVP d'installation
présent sur chaque site qui lit les informations en provenance du premier
(avec l'idée du passage à composer in fine).
Je pense qu'on peut réfléchir à introduire une logique plus large sur le
choix des versions mais il faut spécifier exactement ce que l'on veut
réaliser.


>
>
> Mais faisons déjà les choses "simples", sur lesquelles on a la main plus
> vite.
>
>
Ok, on s'y prend comment pour lancer ce chantier ?

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Gitea et le débardeur

2021-01-05 Par sujet Eric Lupinacci
Hello,

Si je résume un peu ce qui a été dit.

1) Le problème ne concerne pas les tags ni la génération systématique des
zips par le débardeur. On pourrait même étendre à l'ensemble des tags si on
voulait... Maintenant, ne pourrait-on pas éviter de regénérer les zips
existant sur Gitea ?
2) Il faut adapter les affichages sur Plugins SPIP (et bientôt Contrib)
pour mettre en avant les dernières versions de chaque branche et en second
rideau les autres versions (ergo à définir).
3) Un changelog serait utile à la fois dans les affichages Plugins SPIP et
dans SVP afin de décider de la mise à jour en connaissance de cause.
4) Le plus simple et portable serait de créer un fichier CHANGELOG.txt ou
.md à la racine des plugins qui pourrait être utilisé par Plugins SPIP ou
SVP sous un forme à définir.
5) le format du changelog pourrait s'inspirer de :
https://keepachangelog.com/fr/1.0.0/
6) l'existence du changelog est facultative.

Ca peut faire une roadmap sympa il me semble non ?


++
Eric


Le mar. 5 janv. 2021 à 10:20, cam.lafit  a écrit :

> Hello
>
> La notion de release n'est pas un concept git. Cela est propre aux
> forge. À ma connaissance toute les forges proposent cette fonctionnalité
> (gitea, gogs, gitlab, github, ...)
>
> La différence réside dans le principe de diffusion du code. Un tag est
> un marqueur dans le code tandis qu'une release est une version prête à
> l'emploi.
> Les release peuvent être de simple zip mais on peut aller plus loin. Par
> exemple chez alternc on exploite les releases pour fournir directement
> des paquets debian.
> Pour les projets en go, comme gitea, sont proposés les executables pour
> chaque plateforme (linux, mac, bsd, )
>
> Dans notre cas, on a juste besoin de zip et cela ne change pas grand
> chose à ce que proposait trac avec les urls de téléchargement.
>
> Une release est reproductible, c'est toujours une même recette appliquée
> sur un tag.
>
> Km
>
>
> Le 05/01/2021 à 02:49, Gildas Cotomale a écrit :
> > Bonsoir la liste,
> >
> > Le lun. 4 janv. 2021 à 14:02, Eric Lupinacci a écrit :
> >>
> >> Re,
> >>
> >> Le lun. 4 janv. 2021 à 13:16, nicod_  a écrit :
> > […]
> >>>
> >>> Sur ta proposition d'utiliser les versions de Gitea, si c'est une
> >>> fonctionnalité spécifique à Gitea je ne suis pas chaud : on ne pourrait
> >>> pas la reproduire si on devait changer de forge, ou bien sur un miroir.
> >>
> >>
> >> A priori Github a aussi cette notion de release et Gitlab un notion
> d'étiquette.
> >> Je n'ai pas vérifié si cela coïncide exactement.
> >
> > Attention, il y bien les étiquettes (tags) qui sont une fonctionnalité
> > de Git qu'on retrouve dans beaucoup de systèmes de gestions de
> > versions.
> > Il y a aussi les publications/versions (releases) qui s'appuient sur
> > les précédents en y ajoutant la génération des artéfacts et une note
> > de publication… On retrouve cela dans les principales forges basées
> > sur Git
> > - https://docs.gitlab.com/ee/user/project/releases/
> > -
> https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/managing-releases-in-a-repository
> > - Gitea reprend des fonctionnalité de Github que ne reprend pas Gogs,
> > et les versions sont maintenant automatiquement générée
> > https://christine.website/blog/gitea-release-tool-2020-05-31
> >
> > Pour passer d'une forge à une autre, il y a un travail d'adaptation à
> prévoir…
> >
> >
> > […]
> > ___
> > 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
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Gitea et le débardeur

2021-01-04 Par sujet Eric Lupinacci
Re,

Le lun. 4 janv. 2021 à 13:16, nicod_  a écrit :

> On pourrait n'afficher par défaut que la dernière version de la branche
> x, les autres étant masquées par défaut dans un bloc déroulant.
> Ce serait beaucoup plus lisible, tout en donnant accès a tous les zips
> pour qui en aurait besoin.
>
>
Oui, tout à fait.
Je dirais même que le bloc actuel de Plugins SPIP avec tous les détails ne
devrait être affiché que pour la dernière version d'une branche.
Les autres versions avec le même x et des y.z différents devraient être
listées simplement avec un lien de téléchargement et une façon simple de
faire apparaître le changelog entre les versions.


> > Après le deuxième problème ergonomique que l'on a aussi sur SVP c'est
> > pourquoi on fait la maj ?
> Ça, c'est un vrai et vieux problème.
> On pourrait utiliser le log de commit du tag et l'afficher dans SVP ?
>
>
Le log de commit est un pis-aller mais il ne correspond pas pour moi à un
changelog compréhensible pour tous.



> Sur ta proposition d'utiliser les versions de Gitea, si c'est une
> fonctionnalité spécifique à Gitea je ne suis pas chaud : on ne pourrait
> pas la reproduire si on devait changer de forge, ou bien sur un miroir.
>

A priori Github a aussi cette notion de release et Gitlab un notion
d'étiquette.
Je n'ai pas vérifié si cela coïncide exactement.
Après, il y a une façon simple de faire un changelog c'est un fichier...
changelog (d'ailleurs y a une option dans Gitlab pour en ajouter un au
repo).
Il suffirait qu'il ait une structure standard pour servir partout où on en
aurait besoin comme le paquet.xml d'ailleurs.
Sans être obligatoire néanmoins.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Gitea et le débardeur

2021-01-04 Par sujet Eric Lupinacci
Hello,


Le dim. 3 janv. 2021 à 21:18, RastaPopoulos  a
écrit :

> Le 03/01/2021 à 20:26, Eric Lupinacci a écrit :
> > Là je suis vraiment fatigué.
> Bah si on va par là, moi je suis fatigué de rien comprendre à un problème
> qui n'est pas vraiment expliqué, ou pas assez bien expliqué.
> Déso mais je comprends RÉELLEMENT PAS où est le problème. Peut-être je
> suis débile.
>

Non mais tu as très bien compris même si je ne l'ai pas exprimé clairement
il est vrai.
Mais si ton expression était plus amène ça serait mieux pour tout le monde
et plus serein.
Il n'y a aucune polémique dans le sujet abordé, on est pas obligé d'en
créer par une expression brutale ou ironique.


>
> Ça affiche TOUS les "y" existants, dans leur dernière version "z" (ou dit
> à l'envers : le dernier "z" de chaque "y" existant). Sachant qu'un "y"
> c'est un changement important (normalement pas cassant, mais important),
> pas juste une correction de bug. Donc totalement légitime de voir chaque
> "y" ayant existé. Entre deux "y" il peut y avoir de grosses différences, de
> gros ajouts.
>

La notion d'important pour le y est quand même floue et à l'adresse de tout
un chacun.
Donc qualifier le subjectif ce n'est pas simple surtout quand on n'a aucun
changelog humainement compréhensible qui va avec.


>
> Qu'on décide ergonomiquement d'afficher la plus récente en plus énorme, et
> les autres en pitit pitit, c'est une chose, un guide pour le choix. Mais
> c'est juste de l'ergonomie (et ce n'est pas fait actuellement). Ça ne
> change rien qu'on ne supprime jamais une release (et le fait de décider de
> faire un tag = c'est qu'on veut publier), et que ça doit rester dispo à
> l'avenir.
>
>
Oui le problème est ergonomique au sens large.
Et oui, ça concerne plus les utilisateurs "standard" de SPIP que les dev et
les intégrateurs qui sont aujourd'hui qu'on le veuille ou non ceux à qui on
s'adresse le plus au détriment des autres.
Pour ces utilisateurs "standard" le fait de voir une page comme celle de
Saisies sur Plugins SPIP, avec ces dizaines de versions à la suite dans
lesquelles on ne distingue même plus le moment où l'on passe de la branche
3 à la branche 2, ça doit interroger.
Et pas besoin d'avoir 50 versions pour avoir ce sentiment de fouillis.

Alors je ne dis pas qu'il ne faut pas zipper les tags (c'est là où je pense
que mon expression était brumeuse) et de toute façon les zips existent par
défaut dans la forge, je dis qu'il n'est pas nécessaire d'embrouiller tout
le monde sur des sites où l'on veut être simple pour ceux qui ne sont pas
développeurs.
Après le deuxième problème ergonomique que l'on a aussi sur SVP c'est
pourquoi on fait la maj ?
Et la à part lire un log de commit (pas disponible sous SVP) pas toujours
très disert on a rien de très lisible.
Et savoir à quoi s'attendre, si on va devoir ajouter un nécessite (qui ne
justifie pas une nouvelle branche) ou autre serait un plus.


> Et c'est bien ça la norme dans tous les projets PHP bien carrés, sur
> composer, sur github, et donc sur packagist ensuite.
>
> https://github.com/symfony/routing
> => 488 releases ! : 100% des tags et donc y compris tous les Z !
>
> https://packagist.org/packages/symfony/routing
> => central = dernière version puis sur le côté droit un bloc avec toutes
> les précédentes versions : 100% des tags aussi (normal vu que ça vient de
> la même source que le github à priori)
>
>
Mais là on ne parle pas du même type de logiciel. On ne peut pas comparer
le framework Symfony et SPIP en particulier pour les gens qui utilisent
SPIP pour faire de la publication uniquement.
Donc non, ce n'est pas la norme sauf pour les développeurs.


> J'irais même jusqu'à dire que chez nous on n'en affiche *pas assez* même !
> Et que donc oui il faudrait tous les Z justement, comme les autres projets
> Composer. Mais ensuite c'est à l'ergonomie d'être adaptée et bien pensée
> pour mettre en avant ce qui est le plus pertinent en gros en premier, et en
> plus petit/replié ce qui est passé.
>
> Et que donc pour moi le problème est inverse :
> 1) Il manque les Z, il devrait tout y avoir, pas moins.
> 2) C'est l'ergonomie (donc juste du squelette SPIP, pas l'empaqueteur) qui
> devrait être revue pour vraiment fortement en avant les derniers X/Y les
> plus pertinents et en petit voire replié les archives du passé, une vraie
> hiérarchisation pas tout au même niveau.
>
>
Qu'il manque des Z c'est vrai et c'est faux : pour la forge, le débardeur
refait le travail il me semble alors que tous les zips de tous les tags
sont déjà disponibles sur Gitea. Mais par contre il crée ceux qui ne sont
pas sur Gitea ce qui est nécessaire.
Il filtre justement sur le z parce que l'on distribue/affiche tous les zips
sortis du débardeur; on pourrait fil

Re: [spip-dev] Gitea et le débardeur

2021-01-03 Par sujet Eric Lupinacci
Re,

Le dim. 3 janv. 2021 à 20:16, RastaPopoulos  a
écrit :

> Avant de réfléchir à quoi faire pour que ce soit mieux, la question à
> préciser d'abord c'est : c'est quoi vraiment le problème ?
>

Relis mieux, tu commences bien l'année...


>
> Pour la génération des zips précisément, ça ne se base sur sur "x" et "y"
> particulièrement, ça se base sur : dès qu'il y a un tag. Un nouveau tag =
> un zip, non ?
>

Non. On ne zippe pas les n tags ayant les mêmes x et y.
Par contre, on génère les tags x.y et x.y+1.
Tu peux le voir sur Rainette par exemple, on a la 3.11.2 et la 3.12.1 mais
pas la 3.11.1.
C'est déjà bien mais la 3.11 et 3.12 ne sont pas incompatibles et la 12 est
une amélioration de la 11.
Quand on voit les deux laquelle prendre ?
Et dans ce cas pourquoi ne pas voir tous les tags dans ce cas ?


>
> Bé oui, toutes les versions considérées comme "à rendre publique" sont là,
> et c'est la plus récente en premier, donc je ne vois toujours pas où est le
> problème. 3.12.1 est bien affiché prioritairement à 3.11.X, donc c'est bien
> ça qu'on voit en premier. Et il n'y a pas de raison à ce que les versions
> d'avant disparaisse, peut-être qu'un bug existe en 3.12.1 et qu'il FAUT
> pouvoir revenir (y compris ceux qui ne sont pas en git !) à la version
> précédente. Qu'après au niveau ergonomie c'est à nous d'afficher de la
> manière qu'on veut, pas forcément tout au même niveau (la version la plus
> haute de chaque Y en plus gros, etc), ça c'est un autre problème : ça
> n'empêche en rien que tout ce qui a un tag est considéré comme "pertinent à
> rendre public", donc avec un ZIP en rapport.
>
>
C'est un point de vue que je ne partage pas d'autant que si on devait
revenir en arrière je ne vois pas pourquoi on ne verrait pas dans ce cas
tous les tags z compris ?
Donc ce n'est pas une justification valable.



>
> Qui fait ça ? Pourquoi ? Je n'ai jamais eu l'idée de faire ça, et je ne
> saisis absolument pas l'intérêt.
>
>
pfff je fatigue.


> Vraiment je n'arrive pour le moment pas à comprendre ce qui est
> spécialement pénible, ni pour qui.
>
>
Là je suis vraiment fatigué.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Gitea et le débardeur

2021-01-03 Par sujet Eric Lupinacci
Re,


Le dim. 3 janv. 2021 à 16:17, Maïeul Rouquette  a écrit :

>
> Oui ca pourrait être effectivement pour moi la seule bonne raison :
> avoir un système de changelog qui pourrait ensuite servir aussi lors de
> la mise à jour via SVP et co.
>

Seule raison non.
Les trucs tout auto c'est bien mais y a des limites et la distribution des
zips est à mon avis une limite quand on a aucune possibilité d'expliquer
simplement les modifications. On a effectivement ce souci sur SVP et les
updates y ou z.

Je viens de vérifier et l'API Gitea permet facilement de récupérer ces
versions (appelées release en Gitea).
Il faut faire :

https://git.spip.net/api/v1/repos/spip-contrib-extensions/rainette/releases?access_token=

et on récupère un tableau des release en JSON avec pour chaque release le
contenu suivant :

"id": 6700,"tag_name": "v1.5.4","target_commitish":
"master","name": "v1.5.4","body": "Archive de la version 1 de
Rainette dont l'utilisation n'est plus conseillée sauf pour les sites
dont la version SPIP est inférieure ou égale à 3.0.","url":
"https://git.spip.net/api/v1/repos/spip-contrib-extensions/rainette/releases/6700;,
   "html_url": 
"https://git.spip.net/spip-contrib-extensions/rainette/releases/tag/v1.5.4;,
   "tarball_url":
"https://git.spip.net/spip-contrib-extensions/rainette/archive/v1.5.4.tar.gz;,
   "zipball_url":
"https://git.spip.net/spip-contrib-extensions/rainette/archive/v1.5.4.zip;,
   "draft": false,"prerelease": false,"created_at":
"2020-02-06T11:10:17+01:00","published_at":
"2020-02-06T11:10:17+01:00","author": {  "id": 167,
"login": "Eric",  "full_name": "Eric Lupinacci",  "email":
"xxx",  "avatar_url": "xxx",  "language": "fr-FR",
"is_admin": true,  "last_login": "2020-12-27T09:35:43+01:00",
"created": "2017-05-26T10:41:58+02:00",  "username": "Eric"},
  "assets": []

On voit que body contient le texte saisi. On a également le tag associé et
le titre et pleins d'infos sur l'état, la date de création...
Tout ce qu'il faut pour améliorer les changelogs de commits.
Je trouve cela vraiment pas mal.

On a d'ailleurs l'url des zips ce qui permettrait même de ne plus les
construire non ?


++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Gitea et le débardeur

2021-01-03 Par sujet Eric Lupinacci
Yop,


Le dim. 3 janv. 2021 à 15:30, Maïeul Rouquette  a écrit :

>
> 1. Est-ce possible de d'éditer les releases gitea facilement en ligne de
> commande sans passer par du clicodrome
>

Je ne comprends pas le clicodrome (deux clics et une saisie).
Si c'est comme je pense une notion Gitea et pas git oui il faut passer par
l'UI Gitea.
Mais Camille doit pouvoir te répondre mieux que moi.


> 2. Est-ce que cela ne serait juste pas plus simple de se dire qu'on
> publie tous les tags, mais qu'on ne distribue que les plus récent, à
> savoir pour chaque x, celui ayant le plus haut y, et pour chaque y,
> celui ayant le plus grand z? Typiquement ce qu'on a retenu comme
> affichage sur contrib.spip.net, et que le débardeur devrait se contenter
>

Oui ça serait mieux mais alors pourquoi on ne le fait pas ?

Après c'est pas mal aussi la notion de version Gitea car on peut saisir du
texte pour expliquer.
Je me suis rendu compte qu'on a aucun moyen simple de faire un changelog
"plus disert" et plus compréhensible que les commits.
Quand je fais ça sur Contrib je me retrouve à mettre une liste bof bof dans
l'article principal alors qu'il serait plus logique d'avoir un changelog
explicatif dans un article à part.
En gros, on n'est pas prévenu des évolutions et si il faut prévenir d'un
changement important on ne sait pas où le faire.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

[spip-dev] Gitea et le débardeur

2021-01-03 Par sujet Eric Lupinacci
Hello,

Je suis toujours embêté par notre méthode de génération des zips basés sur
les composants x et y d'une version x.y.z.
On se retrouve avec des versions 3.11.1 et 3.12.1 par exemple visibles sur
Plugins SPIP, accessibles indépendamment alors que dans ce cas, 3.12.1 est
à utiliser préférentiellement.
On en vient à éviter de faire un y+1 pour ne pas avoir ce type de
désagrément.
Et plus on va avancer, plus cela sera pénible.

Le fait de créer un tag git pour publier une version via le débardeur n'est
pas à remettre en cause, ça me parait la bonne approche. En effet, on doit
faire une action volontaire pour publier une version.
Mais le problème actuel c'est que "publier" équivaut à "distribuer" (zip,
SVP et Plugins SPIP).
Or à mon avis il faudrait aussi avoir une possibilité de décider si une
version publiée doit être distribuée.

Il existe sous Gitea une notion de version qui s'appuie sur les tags.
La version semble être un objet composé d'un titre, d'une description, d'un
état et d'un tag.
Il est possible d'éditer cette version à tout moment et de la supprimer
simplement en un clic.
Voir ici : https://git.spip.net/spip-contrib-extensions/rainette/releases
Il est impératif de mettre un titre à la version créée sinon elle n'est pas
modifiable par la suite (voir 3.11.2 par exemple), sauf à la recréer avec
le même tag.

De mon point de vue, cette notion de version correspond bien au besoin de
distribution si on y liste que les versions à distribuer.
Si le débardeur lisait cette liste plutôt que les tags il pourrait ne
produire que cette liste en zip.
Et si on supprime une version comme la v3.11.2 par exemple, cela ne modifie
pas le tag qui reste utilisable via git si besoin mais ça retire la
distribution du zip.

On pourrait peut-être évoluer vers cette logique petit à petit en modifiant
le débardeur pour qu'il utilise d'abord les versions Gitea si disponibles
et sinon les tags.
Qu'en pensez-vous ?


++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Plugin Massicot et gestion des autorisations

2020-12-31 Par sujet Eric Lupinacci
Hello,


Le jeu. 31 déc. 2020 à 12:15, RastaPopoulos  a
écrit :

> Le 31/12/2020 à 11:23, glopg...@riseup.net a écrit :
>
Au passage, ya vraiment des incohérences du "nombre de membres" entre les
> différentes orgas "de contrib", qui pourtant devraient toutes avoir le même
> nombre exactement.
> spip-contrib-extensions 2 équipes   460 membres
> spip-contrib-graphismes 2 équipes   467 membres
> spip-contrib-outils 2 équipes   468 membres
> spip-contrib-squelettes 2 équipes   467 membres
> spip-contrib-themes 2 équipes   467 membres
>
>
Oui c'est récurrent, Camille refait une synchro régulièrement.



> Et pareil pour le core : spip 33 membres VS galaxie 35 membres
> )
>
>
Non, la c'est logique.
Il y a des personnes hors du Core qui participent à la Galaxie.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Migration Git - Galaxie - Scories

2020-12-27 Par sujet Eric Lupinacci
Hello,

Ce n'est pas le sujet du fil.
Faire un autre fil pour ça merci.

++
Eric


Le dim. 27 déc. 2020 à 11:26, Franck  a écrit :

> Concernant le ficher de traduction, il y a aussi d’autres incohérences que
> je voudrais bien résoudre 
>
> Exemple (il n’est pas le seul dans ce cas) :
>
>
> https://git.spip.net/spip-contrib-outils/archivelists/src/branch/master/traductions.txt#L479
> Il est dit « deprecated » mais il y a https://plugins.spip.net/forms.html
> qui pointe vers d’autres versions qui sont uniquement sur svn…
>
> Faudrait être sûr que tous les plugs qui étaient fait via svn sont aussi
> fait via git, car sans quoi, ceux qui voudront mettre un très vieux spip
> (1.9 ou 2.0 par exemple) à jour vont avoir des problèmes pour faire des
> installations en local afin de faire des upgrades
>
>
>
> Franck
>
>
>
>
>
> *De :* Eric Lupinacci 
> *Envoyé :* dimanche 27 décembre 2020 10:41
> *À :* SPIP-Dev 
> *Objet :* [spip-dev] Migration Git - Galaxie - Scories
>
>
>
> Hello,
>
>
>
> Francky, via la liste des traductions, a mis en exergue que certains
> plugins étaient encore sous SVN uniquement.
>
> C'est le cas des plugins-squelette de mediaspip
> (_squelettes_/mediaspip/, 4 sous dossiers) et qui sont bien référencés
> dans mon suivi comme "on en fait quoi ?".
>
> J'ai vérifié que ces plugins sont bien utilisés sous medias.spip.net mais
> je ne vois pas le rapport avec le squelette que l'on a aujourd'hui dans git
> sous l'organisation galaxie, à savoir, medias.spip.net.
>
> J'en ai profité pour refaire un état de migration de la galaxie sous git
> en sortant mes archives de suivi et j'en ai tiré quelques actions à
> effectuer car tout n'est pas encore propre.
>
>
>
> *Renommer des repos*:
>
> Pour être plus lisible et cohérent avec le reste il faudrait renommer les
> repos galactic_ du nom de l'url:
>
> - *contrib* devrait devenir contrib.spip.net
>
> - *galactic_spip_net* en www.spip.net
>
> - *galactic_programmer* en programmer.spip.net
>
> - *galactic_forum* en forum.spip.net
>
> - et aussi *univers_spip* en stats.spip.net
>
> Ça peut se faire rapidement mais y a-t-il des conséquences et où ?
>
>
>
> *Déprécier des repos*:
>
> - *galactic_pluginspip* : début de passage à galactic de Plugins SPIP, à
> supprimer car il ne servira jamais étant donné que Contrib inclura Plugins
> SPIP à terme
>
> - *spip-info* : archiver le repo
>
>
>
> *Supprimer ou rajouter de la boussole*:
>
> - *spip-info* : à supprimer de la boussole
>
> - *stats.spip.net <http://stats.spip.net>* : à ajouter à la boussole
>
> - *git.spip.net <http://git.spip.net> *: à ajouter à la boussole
>
> - *SPIP zone* : ne faudrait-il pas le supprimer de la boussole ?
>
>
>
> *Migrer des repos dans Galaxie*:
>
> - rapatrier les repos *mediaspip* listés ici :
> https://pic.infini.fr/WjHjXWPV/aksPYu6u.png. Ce sont les repos utilisés
> sur medias.spip.net et qui sont au format trunk/branches.
>
> - rapatrier les repos *_squelettes_/spip.zone.trac* et 
> _*squelettes_/trac.rezo.net
> <http://trac.rezo.net>* pour mémoire et les archiver. Ce n'est pas grand
> chose mais ça me parait plus cohérent.
>
>
>
> Ca serait bien qu'on en profite là pour finir ça avant la fin de l'année,
> c'est pas grand chose mais au moins on aura un truc fini.
>
>
>
>
>
> ++
>
> Eric
>
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

[spip-dev] Migration Git - Galaxie - Scories

2020-12-27 Par sujet Eric Lupinacci
Hello,

Francky, via la liste des traductions, a mis en exergue que certains
plugins étaient encore sous SVN uniquement.
C'est le cas des plugins-squelette de mediaspip
(_squelettes_/mediaspip/, 4 sous dossiers) et qui sont bien référencés
dans mon suivi comme "on en fait quoi ?".
J'ai vérifié que ces plugins sont bien utilisés sous medias.spip.net mais
je ne vois pas le rapport avec le squelette que l'on a aujourd'hui dans git
sous l'organisation galaxie, à savoir, medias.spip.net.
J'en ai profité pour refaire un état de migration de la galaxie sous git en
sortant mes archives de suivi et j'en ai tiré quelques actions à effectuer
car tout n'est pas encore propre.

*Renommer des repos*:
Pour être plus lisible et cohérent avec le reste il faudrait renommer les
repos galactic_ du nom de l'url:
- *contrib* devrait devenir contrib.spip.net
- *galactic_spip_net* en www.spip.net
- *galactic_programmer* en programmer.spip.net
- *galactic_forum* en forum.spip.net
- et aussi *univers_spip* en stats.spip.net
Ça peut se faire rapidement mais y a-t-il des conséquences et où ?

*Déprécier des repos*:
- *galactic_pluginspip* : début de passage à galactic de Plugins SPIP, à
supprimer car il ne servira jamais étant donné que Contrib inclura Plugins
SPIP à terme
- *spip-info* : archiver le repo

*Supprimer ou rajouter de la boussole*:
- *spip-info* : à supprimer de la boussole
- *stats.spip.net * : à ajouter à la boussole
- *git.spip.net  *: à ajouter à la boussole
- *SPIP zone* : ne faudrait-il pas le supprimer de la boussole ?

*Migrer des repos dans Galaxie*:
- rapatrier les repos *mediaspip* listés ici :
https://pic.infini.fr/WjHjXWPV/aksPYu6u.png. Ce sont les repos utilisés sur
medias.spip.net et qui sont au format trunk/branches.
- rapatrier les repos *_squelettes_/spip.zone.trac* et
_*squelettes_/trac.rezo.net
* pour mémoire et les archiver. Ce n'est pas grand
chose mais ça me parait plus cohérent.

Ca serait bien qu'on en profite là pour finir ça avant la fin de l'année,
c'est pas grand chose mais au moins on aura un truc fini.


++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Critères optionnel avec opérateur : doc imprécise ou bug?

2020-12-18 Par sujet Eric Lupinacci
Yop,

Le ven. 18 déc. 2020 à 14:45, Cerdic  a écrit :

> franchement, non, on va pas compliquer ce critère déjà incompréhensible.
> Limite toi à {id_bidule?} et pour le reste du fait un critère personalisé
> si besoin.
>
> Le jour où on saura faire un critère conditionnel compréhensible et
> utilisable avec un opérateur, on aura pas de remords à casser la compat vu
> comment l’existant ne fonctionne pas vraiment
>
>
Oui absolument.
Mais dans ce cas je serais même d'avis de déprécier l'écriture avec le #ENV.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Demande de compte https://git.spip.net/

2020-12-17 Par sujet Eric Lupinacci
Ok mais peux-tu nous donner ton pseudo et ton adresse email pour
l'inscription stp ?

Le jeu. 17 déc. 2020 à 16:19, Ludovic CHEVALIER 
a écrit :

> Bonjour,
>
> Pour faciliter mes éventuelles futures contributions au projet, j'aurais
> besoin d'un accès à https://git.spip.net/ .
>
> J'ai déjà pris connaissance de la charte qui me convient.
>
> Est-ce qu'il est possible de me créer un accès?
>
> Merci.
>
> --
> Ludo
> ___
> 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

Re: [spip-dev] Critères optionnel avec opérateur : doc imprécise ou bug?

2020-12-16 Par sujet Eric Lupinacci
Le mer. 16 déc. 2020 à 13:53, Bruno Bergot  a écrit :

> > Si je prend la doc ici
> > https://programmer.spip.net/Criteres-optionnels-avec
> >
>
> Est-ce que cette doc est plus claire ?
>
> "Le critère ne sera pris en compte par la boucle que si une variable de
> même nom est présente dans l’environnement."
>

Oui c'est plus clair.
Néanmoins, les exemples de l'article montrent que le cas de Maieul n'est
pas bon avec le #ENV{toto}.

En fait, je ne sais pas si je dis une connerie (c'est possible hein) mais
le #ENV{variable} est presque inutile puisqu'on va chercher une variable de
même nom que le critère lui-même ?

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] [HS] Re: Écriture inclusive (!)

2020-12-14 Par sujet Eric Lupinacci
Le lun. 14 déc. 2020 à 16:19, jacques  a écrit :

>
> Quant au projet politique que je découvre avec un peu d'effroi vu la
> réaction de certains, à ceux qui pensent qu'on consomme SPIP comme un
> produit (voir ref +haut ;-) )
>

On ? C'est qui ? Tu te sens visé ?
Par contre "certains" c'est moi :).
Remarque c'est hyper inclusif ta phrase...


> Je n'ose pas mettre que je m'arrête là car il y en a encore un qui va
> dire *bon débarras*
>

Non pas du tout, je me demande juste à quoi sert ton mail si ce n'est à en
remettre un couche en essayant d'expliquer que c'est pas le cas...

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] [HS] Re: Écriture inclusive (!)

2020-12-14 Par sujet Eric Lupinacci
Hello,


Le lun. 14 déc. 2020 à 15:14, jacques  a écrit :

>
> Quelles valeurs, sont-elles mises en avant sur le site de SPIP? Je ne
> sais pas si je suis d'accord ou pas avec, car visiblement il y a des
> valeurs de SPIP qui ne sont accessibles qu' à un groupe d'initié.e.s.
>
>
Mais qu'est ce que tu racontes ?
Ton mail n'existe que pour mettre de l'huile sur le feu : tu cherches quoi
en disant que la charte ne décrit pas le projet politique ?
Tu veux un parchemin signé avec notre sang ?

Je suis d'accord qu'on peut toujours échanger avec plus de modération mais
je trouve que l'hypocrisie de certains écrits ou "éléments de langage"
comme on le dit aujourd'hui sont bien plus violents qu'un "va chier" qui
n'a le tort que de fâcher les egos...
Donc à se polariser sur la forme on oublie le fond, c'est d'ailleurs ton
cas car le premier mail de ce fil était tout sauf amène.

Et franchement, en remettant en cause sans rien proposer de positif sauf à
dire que la démarche était débile, quelle réaction était attendue de la
part de personnes qui se battent depuis des années pour une cause juste ?
Et SPIP permet toujours de faire ce que l'on veut, il suffit d'y mettre les
mains et d'arrêter de se plaindre en mode consommateur.


> Donc, si je comprends bien, et comme je l'ai déjà écrit:
> Si on n'est pas d’accord, on se fait lyncher, ou sinon on la ferme.
>
> Je dois donc choisir de la fermer car je ne pense pas comme toi, car tu
> penses que je ne suis pas d'accord avec toutes tes valeurs.
>

Après le mode consommateur, voilà le mode Calimero.
Si il y a bien un truc que SPIP fait depuis des années c'est laisser le
libre arbitre de son utilisation.
Tu peux t'exprimer mais tu dois aussi tolérer les contradictions.
Et non ce n'est pas la forme qui fait la contradiction c'est le fond !

Et pour finir, relis les mails et extrait les phrases positives de ceux qui
ont remis en cause l'approche inclusive de SPIP.
Après on en rediscute, plus calmement

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] [Spip-zone-commit] [formidable ↪ limitons_les_points_medians] précisons *personnes* gestionnaire (@marcimat) et (...)

2020-12-04 Par sujet Eric Lupinacci
A partir du moment où tu utilises "personnes" il n'y a plus besoin du
"gestionnaire" qui vient rajouter une notion pas forcément claire si les
gens pensent à l'administrateur par exemple.
Tu peux dire les "personnes gérant les formulaires".

Le ven. 4 déc. 2020 à 12:19, Maïeul Rouquette  a
écrit :

> spip-contrib-extensions/formidable
> -
> Par Maïeul Rouquette, le 4 décembre 2020 à 12h18min :
>
> précisons *personnes* gestionnaire (@marcimat) et évitons les passifs
>
>
> *Modifié*
> lang/formidable_fr.php
>
> Détails :
> https://git.spip.net/spip-contrib-extensions/formidable/commit/a58f9c3693ccc0fed400dd6378b448cd79bae5da
>
> ___
> spip-zone-com...@rezo.net -
> https://listes.rezo.net/mailman/listinfo/spip-zone-commit
>
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Dépôt pour les éléments de l'identité graphique

2020-12-03 Par sujet Eric Lupinacci
A partir du moment où on est dans une organisation de type "contrib"
ouverte à tous et pouvant accueillir des contributions variées je serais
d'avis de préciser que le dépôt concerne spip, comme identite-spip.
Après si c'est vraiment que du spip, pourquoi ne pas le mettre dans un
dépôt comme spip ou Galaxie ?

++
Eric


Le ven. 4 déc. 2020 à 08:14, erational  a écrit :

> Hello tcharlss
>
> Très bonne idée de dépôt pour caler le graphisme
>
> Pour le mot "identité", c'est peut être un terme un trop connoté
> sinon il y a "charte", "charte-graphique", 'references",
>
> Sur les autres dépôts, je suis OK avec toi.
>
> merci
>
> Le 03/12/2020 à 20:07, tcharlss a écrit :
> > Glop,
> >
> > Je voulais déposer sur gitea une version de bonne qualité de la
> > gravure du polatouche utilisée sur spip.net (trouvée après moultes
> > fausses pistes).
> > Pour l'instant il n'y a pas de dépôt adéquat dans l'orga
> > https://git.spip.net/spip-contrib-graphismes, donc je propose d'en
> > ajouter un.
> >
> > L'idée est d'y déposer tous les éléments qui constituent l'identité
> > graphique de Spip : le logo et toutes ses variantes, des images, les
> > polices, et éventuellement plus tard un styleguide, etc.
> >
> > Et donc pour moi la gravure du polatouche est un élément iconique de
> > l'identité graphique de Spip, pas uniquement restreinte à l'histoire
> > du site spip.net : elle aurait toute sa place dans ce dépôt.
> >
> > Donc comment le nommer ?
> > Je pensais à « identite » tout simplement, puisqu'il se trouvera dans
> > l'orga « graphismes ».
> > Des objections, d'autres idées ?
> >
> > Ps. : sur le svn il y a un dépôt mais uniquement pour le logo :
> >
> https://zone.spip.net/trac/spip-zone/browser/spip-zone/_graphismes_/logos/spip/spip_2017
> > Je ne pense pas qu'il faille le reprendre tel quel avec les mêmes
> > sous-dossiers : il s'agit de mettre tout ce qui fait partie de
> > l'identité graphique, le logo est un élément parmi d'autres.
> > Donc l'idée serait de migrer également ce contenu dans le nouveau
> > dépôt git, mais avec un autre rangement interne, je pensais à quelque
> > chose comme ça :
> >
> > - logo
> > - polices
> > - styleguide
> > - images (ou visuels)
> >
> > ___
> > liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> > doc: https://www.spip.net/
> > dev: https://core.spip.net/
> > irc://irc.freenode.net/spip
>
> --
> _
> https://www.erational.org
>
> ___
> 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

Re: [spip-dev] Plugin Archive

2020-11-22 Par sujet Eric Lupinacci
Il me semble qu'il fonctionne.
Sinon j'ai créé un autre plugin de Archivage des objets pour l'utiliser sur
Contrib.
Tu peux essayer aussi mais la logique est différente.

++
Eric


Le dim. 22 nov. 2020 à 23:50, Stephane Santon  a
écrit :

> Bonjour,
>
> Qu'en est-il du plugin "Archive" qui ajoute un statut aux objets ?
> https://contrib.spip.net/Plugin-Archive
>
> Il est marqué fort en chantier et la doc parle de SPip 1.9.2, mais
> compatible Spip 3.2...
>
> Merci
>
> --
> Stéphane
> 17 Charente-Maritime
> ___
> 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

Re: [spip-dev] Git et twgit

2020-11-13 Par sujet Eric Lupinacci
Yop,

Le ven. 13 nov. 2020 à 17:23, Ybbet SPIP  a écrit :

> J'avoue qu'aujourd'hui je ne vois pas ce qu'on faisait avec svn qui ne
> soit pas possible avec git.
>
> En complément de la réponse de RealET, le fait de faire un svn checkout,
> ça ne ramène pas des Go de données (selon l’ancienneté et le type de
> données historisées). Et si dans le dépôt SVN, je ne désire qu’un
> répertoire, ben, je peux prendre ce répertoire uniquement sans problème.
> Sur git, je dois prendre l’entièreté du projet pour pouvoir récupérer ledit
> répertoire.
> Pour le « Go de données », j’ai eu des collègues juniors qui, sans le
> faire exprès, versionnaient le contenu des répertoires « IMG », « local »
> et « tmp »… Quand je m’en rendais compte en faisant git clone xx,
> c’était un peu « trop tard » ou demandait bcp de manipulation.
>
>
Que RealET vive dans le passé et surtout s'y accroche en ne ratant aucune
occasion de le rappeler c'est pas nouveau.
Après, le coup de Go c'est pas un peu une galéjade ?
J'ai l'ensemble du Gitea sur mon ordi et ça pèse 1,7 Go.


Oui alors moi ça me pose un problème ça.
Je ne suis pas chaud à ce que pour certains plugins on ait une branche
master qui ne soit plus le master ou qui doublonne avec une autre branche
de temps en temps.
A mon avis un outil perso ne doit pas imposer un formalisme.


Je n’ai pas trouvé comment changer cette dépense à « stable ». Mais comme a
pu dire RastaPopoulos, un mouvement s’interroge sur le bien fondé du terme
« master ».

Bien fondé ou pas ça va pas changer demain sous git.
Donc on va devoir vivre avec un moment...


>
>
>> >
>> > (même si pour le coup, probablement sans le faire exprès, ielles
>> éliminent le problème de terminologie master/slave...).
>>
>> En effet, je n’ai jamais aimé cette terminologie de « master » qui
>> sous-entend « slave » habituellement dans ce contexte.
>> Si nous avions plutôt utilisé le terme de « master » en tant que « maître
>> », « expert », ou tout autre synonyme, cela aurait été moins subversif.
>>
>
> En anglais ça veut dire "principal".
> Il n'y a donc aucune autre connotation.
>
>
> Cela dépend du contexte et de la sensibilité des uns et des autres. :-)
> Personnellement, de mon Histoire, quand je lis « master », je pense
> inconsciemment à « slave ».
>

Moi ça me fait plus penser à servant, mais c'est mon époque ;-)

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Git et twgit

2020-11-13 Par sujet Eric Lupinacci
Waouh tu maitrises la langue de cheik spire...
En fait, il y a tellement d'autres traductions possibles que principal est
un mot compliqué à traduire en anglais.
Il est très contextuel.
J'avoue que je ne suis pas aussi péremptoire que toi sur l'origine de
master vs principal (master bedroom for instance, est ce celle du maitre ?)
mais ça serait intéressant de connaitre le fin mot de l'histoire.

++
Eric


Le ven. 13 nov. 2020 à 15:41, RastaPopoulos  a
écrit :

> Le 13/11/2020 à 14:44, Eric Lupinacci a écrit :
> > Il nous faut un linguiste anglophone !
>
> Comme je le disais, et c'est pour ça que je le disais, c'est en travail
> pour changer ça chez les anglophones eux-mêmes, dans un très très grand
> nombre de logiciels, donc c'est sans rapport à la traduction. Le mot
> principal pour dire… principal, c'est "main" ou "primary", et non pas
> "master" du tout.
>
>
> https://www.zdnet.com/article/github-to-replace-master-with-alternative-term-to-avoid-slavery-references/
>
> --
> RastaPopoulos
>
> ___
> 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

Re: [spip-dev] Git et twgit

2020-11-13 Par sujet Eric Lupinacci
Yop,



Le ven. 13 nov. 2020 à 10:10, RastaPopoulos  a
écrit :

> Le 13/11/2020 à 08:44, Eric Lupinacci a écrit :
> > En anglais ça veut dire "principal".
> > Il n'y a donc aucune autre connotation.
>
> Si si :)
> ça veut dire "principal" *parce que* historique depuis master/slave et
> justement absolument dans toutes les communautés *anglophones* il y a un
> mouvement social pour supprimer totalement cette notion de master. Donc
> bien sûr que si il y a une connotation et un mouvement pour ne plus
> l'utiliser, de manière internationale.
>
>
Je ne vois pas ce qui fait référence à maitre/esclave dans ce contexte ci.
Si on parlait de redondance je pourrait comprendre mais là ce n'est pas le
sujet.
Quant au fait que master est traduit par principal parce que ça fait
référence à maitre/esclave j'en suis encore plus étonné.
Il nous faut un linguiste anglophone !

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Git et twgit

2020-11-12 Par sujet Eric Lupinacci
Hello,



Le jeu. 12 nov. 2020 à 18:57, Ybbet SPIP  a écrit :

> Merci pour ta réponse.
> > Le 12 nov. 2020 à 12:45, Matthieu Marcillaud  a
> écrit :
> Je suis tout à fait d’accord avec l’analyse et le retour d’expérience de
> cette personne.
> Ce n’est pas parce qu’on utilise un outil « git » que nous connaissons
> Git. Personnellement, c’est exactement pour ça que j’utilise lesdits
> outils! Git n’étant pas ma tasse de thé. Je vois ses avantages mais des
> choses me manquent de SVN. Bref. Pas de débat, c’est juste une affinité. ;-)
>
>
J'avoue qu'aujourd'hui je ne vois pas ce qu'on faisait avec svn qui ne soit
pas possible avec git.


> >
> > L'existence de
> >>> la branche "stable" (nécessaire à twgit) casserait ce processus ?
> >
> > A priori non, ça ne casse pas le processus de tag => zip.
>
> C’est ce qu’il me semblait mais je préférais demander l’avis et
> l’autorisation de la communauté.
>

Oui mais ça ne doit pas devenir systématique non plus aujourd'hui.
On ne doit pas imposer un commit une montée de version.


>
> >
> > Cela étant dit, pourquoi diable n’ont-ielles pas conservé "master". Elle
> devient quoi cette branche "master" dans tout ça ?
>
> « Master » devient une branche morte en quelques sortes. Mais, ici, dans
> la communauté, on utilise la branche master. Je verrai (soit par un hook,
> soit manuellement) a faire un merge de la stable dans le master
> régulièrement.
>

Oui alors moi ça me pose un problème ça.
Je ne suis pas chaud à ce que pour certains plugins on ait une branche
master qui ne soit plus le master ou qui doublonne avec une autre branche
de temps en temps.
A mon avis un outil perso ne doit pas imposer un formalisme.


> >
> > (même si pour le coup, probablement sans le faire exprès, ielles
> éliminent le problème de terminologie master/slave...).
>
> En effet, je n’ai jamais aimé cette terminologie de « master » qui
> sous-entend « slave » habituellement dans ce contexte.
> Si nous avions plutôt utilisé le terme de « master » en tant que « maître
> », « expert », ou tout autre synonyme, cela aurait été moins subversif.
>

En anglais ça veut dire "principal".
Il n'y a donc aucune autre connotation.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

[spip-dev] Plugin Licence

2020-11-01 Par sujet Eric Lupinacci
Hello,

Je regarde le plugin Licence qui fournit aujourd'hui une licence à un objet
article ou document.
Il est très simple et fonctionne à priori correctement.

Néanmoins, il date, il a des scories SPIP 2...
Je me disais qu'il serait pas mal de le faire évoluer tant techniquement
que fonctionnellement.

*Techniquement*
- passage en spip 3.2 minimum (abandon plugin.xml, pipelines...)
- abandon de la globale au profit d'un support de stockage différent en
considérant une licence comme un objet ce qui permettrait de le lier à plus
de types d'objet simplement, ou alors une liste dans un YAML importé dans
une meta...
- peut-on choisir les objets qui portent une licence ? Si oui, à quel
moment ?

*Fonctionnellement*
- Tetue avait demandé la possibilité d'ajouter une licence par défaut à un
auteur qui serait utilisée pour ses articles sauf choix différent.
- permettre d'éditer une licence ? choisir un logo alternatif ?
- autres idées ?

Voilà.
Qu'en pensez-vous ? Avez-vous d'autres idées ?

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Doc sur contrib

2020-10-14 Par sujet Eric Lupinacci
J'en ai profité pour mettre le préfixe et ajouter la catégorie squelette
editorial qui correspond à sa rubrique d'appartenance.
De cette façon le lien est créé avec le plugin et doit se voir dans la
boite d'info de la rubrique.

Le mer. 14 oct. 2020 à 11:25, erational  a écrit :

> Coucou
>
> C'est fait
> https://contrib.spip.net/ecrire/?exec=rubrique_rubrique=2138
>
> Merci !
>
> Le 14/10/2020 à 11:14, jeanmarie a écrit :
> > Salut,
> >
> > je voudrais commencer la doc pour le thème HTML5up Escape Velocity
> > (https://git.spip.net/spip-contrib-squelettes/html5up_escape_velocity)
> > mais je n'ai pas/plus la main pour créer la rubrique ici
> > https://contrib.spip.net/ecrire/?exec=rubrique_rubrique=781
> > Quelqu'un·e peut me le faire ?
> >
> > Merci,
> >
> > jeanmarie
> >
> > ___
> > liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> > doc: https://www.spip.net/
> > dev: https://core.spip.net/
> > irc://irc.freenode.net/spip
>
> --
> _
> https://www.erational.org
>
> ___
> 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

Re: [spip-dev] Refonte Mediabox [wip]

2020-10-10 Par sujet Eric Lupinacci
Oui je trouve ça nickel là.

Le sam. 10 oct. 2020 à 05:36, nicod_  a écrit :

> Le 09/10/2020 à 23:19, Cerdic a écrit :
> > C’est corrigé et je viens d’ajouter une fonction diaporama.
>
> Top avec toutes ces modifs.
>
> Comment ça marche ta fonction diaporama ? Je ne vois pas ça sur la démo.
> Niveau accessibilité, on n'est pas censés déclencher une animation
> automatiquement, et au pire il doit y avoir un bouton pour l'arrêter.
>
> > Je crois qu’avec ça on a toutes les features. Il reste à gérer les
> > quelques configs et on aura une bonne base
> > (il y aura surement aussi une passe à faire d’affinage des styles en
> > petit écran)
>
> Je vais tester ça sur crossbrowsertesting asap.
>
> --
> nicod_
> ___
> 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

Re: [spip-dev] Refonte Mediabox [wip]

2020-10-09 Par sujet Eric Lupinacci
Hello,

Un petit truc.
Quand on est sur une image le fait de cliquer en dehors de l'image ferme la
popup. Ok.
Quand on est dans une galerie le fait de cliquer en dehors de l'image est
équivalent aux boutons suivant et précédent.
C'est voulu ? normal ? Parce que je trouve ça déroutant la première fois
par rapport au comportement des images.





Le ven. 9 oct. 2020 à 16:59, Cerdic  a écrit :

> Hello,
>
> merci pour vos retours.
>
> Les points suivants sont donc corrigés :
> - le signalement du focus des boutons close/prev/next est forcé dans la
> css de la box, et non hérité par défaut du site
> - les boutons prev/next sont en position fixed dans l’écran et ne bougent
> donc plus. Ils sont par ailleurs visible immédiatement et plus seulement au
> survol
> - il y a un background sur les images
> - on peut fermer la box pendant son chargement si c’est trop long
>
> --
> Cédric
> Le 9 oct. 2020 à 15:11 +0200, pierre laszczak ,
> a écrit :
>
> Hello,
>
> Super! je viens de tester à l'instant sur contrib et je suis du même avis
> que tcharlss
>
> Une petite suggestion d'UX : pour les galeries, est-ce que c'est possible
>> de mettre les flèches de navigation en position fixe sur les côté (et ce de
>> base, sans avoir à bidouiller les styles) ?
>> Là elles sont collées par-dessus l'image, ce qui fait qu'avec des images
>> de tailles différentes elles changent constamment de place, ce qui rend la
>> navigation à la souris moins facile.
>>
>
> *Il y a un autre soucis sur les connexions lentes, je pense notamment au
> diaporama:*
> -> Une fois qu'une action js est lancée on ne peut pas l'annuler en
> cliquant sur close ou hors de la fancybox! on est obligé d'attendre que la
> requête ajax soit terminée.
>
> Le ven. 9 oct. 2020 à 00:48, nicod_  a écrit :
>
>> Le 07/10/2020 à 23:59, nicod_ a écrit :
>> > Il faudrait pouvoir la faire tester par un·e expert·e accessibilité.
>> >
>> > Peut être Roman, s'il nous lit ici ?
>>
>> Un premier retour de notabene :
>>
>> > Au clavier c'est tout bon (sauf le bouton "fermer" qui n'a pas
>> d'outline perceptible). On cycle dans la popin sans en sortir, pas de perte
>> de focus, etc. Quand on ferme la popin ça remet le focus sur le lien
>> ouvrant. Tout bon.
>> >
>> > Les flèches ne sont affichées qu'au survol, ça n'aide pas
>> l'utilisateur pour voir que la popin est un carrousel (il peut pas deviner
>> tout seul gauche/droite).
>> >
>> > J'essaie de tester bientôt avec mon lecteur d'écran. Mais déjà c'est
>> bien cool.
>>
>> https://toot.cafe/@accessiblestef/105000951846500269
>>
>> Ça sent bon tout ça, en plus elle est vachement plus light et jolie
>> cette box :)
>>
>> --
>> nicod_
>> ___
>> 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
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Renommages branches & tags SPIP + plugins-dist

2020-09-26 Par sujet Eric Lupinacci
Yes !

Gogogo
Tant qu'à faire appelle le fichier plugins-dist.json ça sera plus explicite.

La bise
Eric


Le sam. 26 sept. 2020 à 13:56, Matthieu Marcillaud  a
écrit :

> Hello everybody !
>
> Il est probable qu’on s’occupe dans le week end (demain?) de renommer
> les branches & tags de SPIP et des plugins-dist, tel que proposé dans un
> thread précédent (Release, Git, Composer - du 14 septembre dernier).
>
> Tout le monde semblait partant (je n’ai pas vu de contre indication en
> tout cas !).
>
> Je pense ajouter également, enfin remplacer plutôt, le fichier
> .gitsvnextmodules par un fichier spip_modules.json ou quelque chose
> comme ça dans les branches 3.1+. Ce fichier listerait simplement l’url
> des Gits des plugins-dist (sans préciser la branche ou tag) et le
> répertoire destination. Encore une fois ce n’est pas quelque chose (ce
> fichier) qui sera pérennisé (l’idée est tout de même pour les futurs
> développement d’aller vers un composer.json)
>
> Les outils checkout et spip-cli seront temporairement cassés et devront
> être mis à jour. J’essaierai de m’occuper de checkout.
>
> Voilà, j’espère que vous avez la forme !
>
> Tendresse à toutes & tous,
>
> Matthieu.
>
> ___
> 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

Re: [spip-dev] [fontawesome5] mise à jour du plugin picto à la version fontawesome (...)

2020-09-26 Par sujet Eric Lupinacci
Hello,

Le sam. 26 sept. 2020 à 12:35, RealET  a écrit :

> RastaPopoulos a écrit le 26/09/2020 à 12:05 :
> > Je sais qu'un argument est que ça empêche les gens de mettre à jour
> "automatiquement" vers une version majeure différente qui casserait leur
> site. Mais on a alors ce problème pour TOUS les plugins du monde qu'on a et
> qui changeraient de version X. Pourtant on ne le fait pas pour chaque
> plugin du monde. Quand le plugin Patates passe de 2.3.4 à 3.0.1, on ne fait
> pas un prefix="patates2" et un prefix="patates3", même quand ça casse le
> fonctionnement (ce qui est souvent le cas si on décide de changer X).
> >
> > Si on a un problème ergonomique avec SVP quand il gère et prévient les
> gens des mises à jour : c'est ça qu'il faudrait corriger absolument, pas
> faire un préfixe par version majeur de plugin, non ?
>
> Dans la mesure où SVP a un bouton "Cocher toutes les mises à jour", et
> un comportement identique quel que soit les risques de la mise à jour,
> je trouve que le choix de changer de préfixe est tout à fait cohérent.
>
> Entre autre, parce que ça permet de faire avancer un plugin sur 2
> branches, tout en permettant de faire les mises à jour sans se poser de
> questions.
>
> (PS : c'est la même chose avec le plugin foundation)
>
>
Parfois il faut voir plus loin que le bout de SON nez.
J'ai expliqué maintes fois pourquoi c'est une mauvaise pratique en général.
Il y a des exceptions soit mais encore faut-il qu'elles soient justifiées.

Tu iras expliquer au gens qui cherchent les mises à jour qu'ils doivent
changer de page sur plugins spip ou sur contrib ou ne pas installer le
nouveau préfixe sur l'ancien.

Bon aller j'arrête ça me gonfle trop.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Release, Git, Composer

2020-09-14 Par sujet Eric Lupinacci
Yop,

Le lun. 14 sept. 2020 à 11:10, Cerdic  a écrit :

> Je suis d’accord qu’il faut remettre au carré la convention de nommage des
> tags et branches, tant sur le core que sur les plugins du core.
> On peut décider d’utiliser une convention propre à partir de la prochaine
> version 3.3, ou de remettre au propre toutes les branches et tags sur
> toutes les versions 3.x (ou tout, si on est courageux), ça me va.
>
> Par contre, avant de releaser une 3.3 bta et vu qu’on a déjà bien
> attendu, je règlerai bien cette histoire de mediabox pour éviter de
> s’embarquer 5 ans de plus avec une colorbox qui n’est plus du tout à jour...
>
>
Oui mais c'est deux sujets distincts qui se rejoignent dans une même action.

1) Périmètre fonctionnel de la 3.3 : on a des PR en cours, des tickets et
ce nouveau sujet mediabox et la question est que prend-on en compte ?
2) Périmètre technique : qu'améliore-t-on sur la gestion des tags et des
release pour la suite ?

Pour 2) je suis ok de faire ça maintenant.
Pour 1) je suis aussi d'accord pour la colorbox mais il faudrait aussi
qu'on se détermine sur les autres sujets déjà bien murs et les PR non
encore traitées.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Soyez sympa, arrêtez de rembobiner...

2020-09-03 Par sujet Eric Lupinacci
Je recommence car les touches m'ont joué des tours.

On a dit qu'on couperait au 1 juillet.
On a fermé le SVN en écriture le 1 juillet mais le subgit est resté branché.
Ca fait deux mois qu'on ne s'en sert plus et que personne n'en a eu besoin
comme prévu.

Donc je souhaiterais maintenant qu'après tous les efforts qu'on a fait on
finisse enfin quelque chose jusqu'au bout et donc que l'on coupe le subgit
ce qui nous permettra aussi d'éviter d'avoir 100Mo pour un repo de 1 Mo.

Et comme le dit Cédric on a peut être mieux à faire de se prendre la tête
et la gueule sur un tel sujet pendant que Contrib et SPIP 3.3 s'épuisent
dans leur coin...

Donc on dit début de la semaine prochaine ?

Le jeu. 3 sept. 2020 à 20:57, Eric Lupinacci  a écrit :

> Hello,
>
> On a dit qu'on couperait au 1 juillet.
> On a fermé le SVN en écriture le 1 juillet mais le subgit est resté
> branché.
> C
>
> Le jeu. 3 sept. 2020 à 17:03, Cerdic  a écrit :
>
>> Bon donc hier j’ai envoyé 2 commits sur spip sur les branches spip 3.2 et
>> master.
>>
>> Et au moment de pousser une branche de dev et de faire une PR aujourd’hui
>> je vois que ces deux commits ont disparus de master et de la branche 3.2.
>>
>> De fait, quand je pioche dans les mails d’hier et que je clic sur les
>> liens, les commits sont bien dans l’arbre, mais dans des branches
>> subgit/unsynced/...
>>
>>
>> https://git.spip.net/spip/spip/commit/9825b8b5874043fa987dfa5f6120bd04a2246e9d
>>
>> https://git.spip.net/spip/spip/commit/06da062331024d62cf80d1ed06c3f5125816c783
>>
>> Je constate que les 2 commits ne sont pas non plus sur le mirroir.
>>
>> J’ai essayé de les repousser en regardant aussitot sur le git.spip.net :
>> mes 2 commits arrivent bien sur les branches, puis après pfiout ils
>> disparaissent.
>>
>> Ce qui m’amène aux reflexions et questions suivantes :
>>
>> - jamais aucune forge git ne m’avait perdu des commits avant que de
>> bosser sur git.spip.net !
>> - on avait dit qu’on se débarassait de subgit au 1er juillet, non ?
>> - qu’est ce que ce truc fait encore à nous pourrir la vie alors que plus
>> personne n’en veut et qu’il ne nous sert plus à rien ?
>>
>> On a pas autre chose à faire de notre peu d’énergie que de passer notre
>> temps à récupérer les oups et les foirures de subgit, ou à s’écharper à son
>> sujet ?
>>
>> On a essayé, aussi fort et autant qu’on a pu.
>> Ça ne marche pas de façon satisfaisante.
>> Donc on va pas encore se farcir le truc des mois, on coupe et on arrête
>> les frais.
>>
>> Je comprends même pas que ce soit encore un sujet...
>>
>> --
>> Cédric
>> ___
>> 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

Re: [spip-dev] Soyez sympa, arrêtez de rembobiner...

2020-09-03 Par sujet Eric Lupinacci
Hello,

On a dit qu'on couperait au 1 juillet.
On a fermé le SVN en écriture le 1 juillet mais le subgit est resté branché.
C

Le jeu. 3 sept. 2020 à 17:03, Cerdic  a écrit :

> Bon donc hier j’ai envoyé 2 commits sur spip sur les branches spip 3.2 et
> master.
>
> Et au moment de pousser une branche de dev et de faire une PR aujourd’hui
> je vois que ces deux commits ont disparus de master et de la branche 3.2.
>
> De fait, quand je pioche dans les mails d’hier et que je clic sur les
> liens, les commits sont bien dans l’arbre, mais dans des branches
> subgit/unsynced/...
>
>
> https://git.spip.net/spip/spip/commit/9825b8b5874043fa987dfa5f6120bd04a2246e9d
>
> https://git.spip.net/spip/spip/commit/06da062331024d62cf80d1ed06c3f5125816c783
>
> Je constate que les 2 commits ne sont pas non plus sur le mirroir.
>
> J’ai essayé de les repousser en regardant aussitot sur le git.spip.net :
> mes 2 commits arrivent bien sur les branches, puis après pfiout ils
> disparaissent.
>
> Ce qui m’amène aux reflexions et questions suivantes :
>
> - jamais aucune forge git ne m’avait perdu des commits avant que de bosser
> sur git.spip.net !
> - on avait dit qu’on se débarassait de subgit au 1er juillet, non ?
> - qu’est ce que ce truc fait encore à nous pourrir la vie alors que plus
> personne n’en veut et qu’il ne nous sert plus à rien ?
>
> On a pas autre chose à faire de notre peu d’énergie que de passer notre
> temps à récupérer les oups et les foirures de subgit, ou à s’écharper à son
> sujet ?
>
> On a essayé, aussi fort et autant qu’on a pu.
> Ça ne marche pas de façon satisfaisante.
> Donc on va pas encore se farcir le truc des mois, on coupe et on arrête
> les frais.
>
> Je comprends même pas que ce soit encore un sujet...
>
> --
> Cédric
> ___
> 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

Re: [spip-dev] Bel_env et debug

2020-08-12 Par sujet Eric Lupinacci
Hello,

Le mer. 12 août 2020 à 20:28, Bruno Bergot  a écrit :

> Hop,
>
> Le 11/08/2020 à 21:49, nicod_ a écrit :
> > Ça serait plus cohérent oui, mais pourquoi garder les deux ?
> >
>
> Je pense comme toi qu'il est temps de mutualiser, notamment sur le point
> qui fait que ces filtres n'affichent l'info que pour les webmestres, les
> visiteurs des sites s'en cognent un peu de l'env et de nos debugs :p
>
> Par contre, il faudra choisir un nom pour le filtre qui prendra le
> relai, ou alors garder debug qui a l'avantage d'être connu car
> documenté, et mettre à jour sa doc.
>
>
Ah oui j'avais pas vu ça comme ça.
On pourrait effectivement mutualiser debug et bel_env qui traite plus que
le env.
Et oui, il faut garder debug qui est explicite.
Par contre, il faut garder aussi le code de bel_env car il y a des
améliorations que j'avais faites qui sont intéressantes.

Mais oui, très bonne idée.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

[spip-dev] Bel_env et debug

2020-08-11 Par sujet Eric Lupinacci
Hello,

Une petite remarque avant la prochaine release 3.3.
Dans le code on a ajouter il y a déjà longtemps le filtre |debug qui permet
de faire du... debug dans les squelettes.

Dans le plugin dev, on a un autre filtre très utile qui s'appelle |bel_env
et qui permet d'afficher un tableau dans un format HTML lisible quelque
soit son imbrication. C'est donc un outil de debug au même titre que le
filtre |debug.

Je trouve que c'est incohérent d'avoir l'un dans spip et l'autre dans dev
qui ne fait plus partie d'ailleurs des plugins-dist.
Je proposerais bien d'intégrer le filtre |bel_env dans spip en le renommant
par exemple en |debug_table.

Vos avis ?

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Écriture inclusive

2020-08-05 Par sujet Eric Lupinacci
Hello,

Le mer. 5 août 2020 à 11:09, RealET  a écrit :

>
> PS : merci d'avoir lancé ce thread ici qui m'a permis de faire plus
> attention à un sujet sur lequel je ne m'étais pas assez penché.
> Pour l'instant, plus je creuse le sujet, plus je découvre que l'écriture
> inclusive systématique est contre productive (en particulier quand le
> genre est hors du sujet, et qu'elle met l'accent sur une distinction de
> sexe)
>
>
A mon avis tu fais un amalgame entre écriture inclusive et point médian.
Quand tu lis le fameux document officiel dont Matthieu nous avait fourni le
lien, il est assez peu utilisé.
Je ne vois pas par contre ce qui est contre-productif dans "ceux ou celles"
ou d'autres expressions de ce genre.
C'est plus un état d'esprit d'y penser ou pas.

Après moi je ne suis pas fan des celleux ou autres raccourcis inutiles
(sauf pour twitter peut-être) à partir du moment où on peut écrire depuis
toujours "celles ou ceux".

Déjà sans point médian, on peut avancer et il ne faut pas prendre l'excuse
de ce fameux point pour refuser tout en bloc.

++
Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Je commence avec GIT

2020-08-03 Par sujet Eric Lupinacci
A terme oui.
Pour l'instant il est bloqué en lecture seule.

Le lun. 3 août 2020 à 16:19, Luis  a écrit :

> On 03/08/2020 14:57, Bruno Bergot wrote:
> > Hop,
> >
> > Le 03/08/2020 à 14:55, Luis a écrit :
> >> J'ai fait un clone de SPIP
> >> git clone https://git.spip.net/SPIP/spip.git
> >>
> >> mais je ne vois pas les plugins-dist
> >>
> >> Comment faire?
> >>
> >
> > Suivez le guide...
> >
> > https://blog.smellup.net/spip.php?article117
> >
> > ++
> > b_b
>
> Et bien… Dernière question : le serveur SVN va-t-il disparaître ?
>
> ___
> 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

Re: [spip-dev] Compte Gitea

2020-07-24 Par sujet Eric Lupinacci
Il me faudrait un un nom d'utilisateur et un email stp.

++
Eric



Le ven. 24 juil. 2020 à 12:32, CSI  a écrit :

> Bonjour,
>
> Òk merci. Je ne pense pas avoir jamais eu de compte SVN.
>
> Le 23/07/2020 à 20:22, RastaPopoulos a écrit :
> > Le 23/07/2020 à 19:29, CSI a écrit :
> >> Quelle est la procédure pour avoir un compte sur git.spip.net ? pour
> >> l’instant j'en ai besoin pour ouvrir un ticket (ou une demande de
> >> fonctionnalité plutôt) ...
> > Si tu avais un compte sur la zone SVN, c'est pareil.
> >
> > Sinon un admin ici va te créer tout ça.
> --
> Pierre
>
> ___
> 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

Re: [spip-dev] Plugins hors https://git.spip.net/explore/organizations

2020-07-23 Par sujet Eric Lupinacci
On peut éventuellement profiter du passage sous Git pour lui demander si
cela ne l'intéresse pas de mettre ces plugins dans la forge surtout qu'ils
sont connus et documentés depuis des années.

Si quelqu'un le connait et sait le contacter ça peut être une idée.

++
Eric


Le jeu. 23 juil. 2020 à 09:49, teamspipfact...@gmail.com <
teamspipfact...@gmail.com> a écrit :

> Merci a vous
>
> Bon et bien on s'en passera, :-[
> >
> > teamspipfact...@gmail.com a écrit le 23/07/2020 à 09:23 :
> > > Bonjour
> > >
> > > je constate que les plugins suivant
> https://contrib.spip.net/Equipement
> > > ne sont pas sur https://git.spip.net/explore/organizations
> > .../...
> > >
> > > *que puis je faire ?, existe t'il un équivalent ?, pourquoi sont il
> > absent ?*
> > Tu auras des éléments de réponse ici :
> >
> https://contrib.spip.net/cipr-plugin-Previsualisation-etendue#comment484479
> >
> >
> >
>
> Le 23/07/2020 à 09:38, Manu a écrit :
> > Ces plugins ne sont pas accessibles sur git pas plus qu'ils ne
> > l'étaient sur svn. C'est un choix du développeur.
> > Pour leur mise à jour, la procédure est donc toujours la même : le
> > classique tranfert par FTP
>
> --
> spipfactory.fr
> 
> Perdu dans la Galaxie SPIP ? : https://boussole.spip.net/
> ---
> Tout SPIP(eur)-(euse), qui fait quelquechose,
> à contre lui ceux qui voudraient faire la même chose, ceux qui font
> précisément le contraire,
> et surtout la grande armée des gens, beaucoup plus sévéres, qui ne fait
> rien.
> Merci a ceux qui font.
>
> ___
> 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

Re: [spip-dev] UI gitea

2020-07-12 Par sujet Eric Lupinacci
Normalement tu as un bouton Paramètres en haut à droite de la page de ton repo.
En cliquant tu arrives à une page ou à la fin tu peux supprimer le repo.


> Le 12 juil. 2020 à 10:04, JLuc  a écrit :
> 
> Bonjour
> 
> Je voudrais supprimer un repo inutile (JLuc/bigup) et créer un ticket sur un 
> autre,
> mais je ne trouve pas moyen de le faire.
> 
> Je n'utilise pas git.spip tous les jours et je ne sais pas bien où ça en est.
> L'UI de git.spip.net traverse t elle actuellement une période d'état dégradé ?
> Sinon comment faire ?
> 
> Pour info voici ce que je vois : https://pic.infini.fr/qWUSB2o6/VuDrLzUs.jpg
> Les 2 premieres lignes sont générales et ne concernent pas le repo courant.
> JL
> 
> 
> ___
> 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


Re: [spip-dev] Import de dépôts qui n'ont pas fonctionné

2020-07-09 Par sujet Eric Lupinacci
Yep,

> Le 9 juil. 2020 à 15:54, Stephane Santon  a écrit :
> 
> Ne pourrait-on pas mettre ce lien dans la signature automatique de spip-dev ?
> 

Je ne pense pas que ce soit une bonne idée.
Ce n’est pas un lien « officiel » pour ce sujet.
Il est ou sera plutôt sur spip;net et j’espère que ce moment là ce morceau de 
carnet aura aussi été transféré.

++
Eric

___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Import de dépôts qui n'ont pas fonctionné

2020-07-09 Par sujet Eric Lupinacci
Re,

> Le 9 juil. 2020 à 12:08, jeanmarie  a écrit :
> 
> Je ferai pareil pour https://framagit.org/zzzazzz/html5up_escape_velocity ça 
> ne pose pas de problème
> J'arrête de bosser dessus histoire que mes commits ne se croisent pas quand 
> tu recréeras le dépôt.
> 

J’ai créé le repo html5up_escape_velocity sur Gitea.
Il est vide car je n’arrive pas à pousser ma copie locale clonée de framagit 
sur Gitea.
Si tu peux essayer ça serait bien.

Comme ça on aurait clôturé ces sujets.

++
Eric



___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

  1   2   3   4   5   6   7   >