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

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

2020-07-09 Par sujet Eric Lupinacci


> Le 9 juil. 2020 à 11:46, jeanmarie  a écrit :
> 
> 
> Le 09/07/2020 à 11:26, chanka...@choc0.net a écrit :
>> Le 07/07/2020 à 21:20, chanka...@choc0.net a écrit :
>>> Le 07/07/2020 à 18:27, jeanmarie a écrit :
 J'en profite : il y avait également celui là qui coinçait 
 https://www.mail-archive.com/spip-dev@rezo.net/msg69254.html
 A voir si chan souhaite toujours l'importer. 
>>> Mais oui bien sûr, si c'est le moment allons-y : faut commencer par 
>>> supprimer le dépôt existant ou bien le renommer ?
>>> Merci de l'aide, j'ai pas l'accès nécessaire pour faire ça...
>> https://git.spip.net/spip-contrib-squelettes/html5up_spectral
>> youpie !
> 
> Super :)
> 
> et argh :( les tickets et PRs n'ont pas suivis
> https://framagit.org/chankalan/html5up_spectral/-/merge_requests
> https://framagit.org/chankalan/html5up_spectral/-/issues
> 
> C'est pas grand chose, je vais les reprendre...

Non j’ai pas fait une migration.
Juste une création.

++
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 sous Git - Bascule finale au 1 juillet 2020 - suite

2020-07-01 Par sujet Eric Lupinacci
Yep,

> Le 1 juil. 2020 à 17:28, Amaury Adon  a écrit :
> 
> Salut
> Je viens de voir qu’il y avait epilogue dans la liste. S’il n’est pas trop 
> tard, ce serait bien de le migrer. J’en profiterai pour lui faire un bon 
> nettoyage de printemps et un article sur contrib

Fait.
A toi de jouer maintenant.

++
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 sous Git - Bascule finale au 1 juillet 2020 - suite

2020-06-30 Par sujet Eric Lupinacci
Re,

> Parcourant la liste je vois markdown
> pourtant ç'a l'air bien vivant 
> https://plugins.spip.net/markdown.html?compatible_spip=3.2
> 

C’est pas la version à conserver.
Elle est sur GitHub la bonne.

++
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 sous Git - Bascule finale au 1 juillet 2020 - suite

2020-06-30 Par sujet Eric Lupinacci
Hello,

Un petit récapitulatif de la journée.
Les plugins suivants ont été migré sous git (30 sur les 153 d’hier):

agenda_dates_floues
amappca
api_syntaxe
app
askwiki
aspirateur
ayants_droit
chats
cornertease
date_connexion
depublication
devis
doc2article
filtres_images_vectorise
formidable_inscription
gabarits
horloge_flash
isocode
knacsss
menus_partager
mesfavoris_collections
porte_plume_blocs
porte_plume_codes_spip
porte_plume_gbe
porte_plume_liens_internes
prestations
styleguide
syndic_etendue
tout_partout

La liste des restants est disponible ici : http://spip.pastebin.fr/63338 



++
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 sous Git - Bascule finale au 1 juillet 2020 - suite

2020-06-30 Par sujet Eric Lupinacci
Re,

> Le 30 juin 2020 à 13:18, tout...@free.fr a écrit :
> 
> Bonjour,
> 
> Repéré quelques plugins en sus, je suis ok pour ne pas les passer sur
> GIT si vous considérez qu'ils sont obsolètes ou que conserver leur
> historique est inutile, dans ce cas autant supprimer aussi leurs docs
> sur contrib ?
> 
> 
> - abonnement-z plugin de gestion des abonnements pour SPIP2 doc sur
> https://contrib.spip.net/Abonnements-avec-Z intéressant sur l'historique
> des commits et sa doc, longue conception qui a servi à Rastapopoulos
> pour baser ensuite le plugin abonnement (non compatible avec celui-ci)
> - relances https://contrib.spip.net/Relances permet de relancer un·e
> abonné·e à une date donnée (intégré dans abonnement SPIP3)
> - walma galerie photo
> https://zone.spip.org/trac/spip-zone/browser/_plugins_/walma_192
> 

En fait, je suis parti des plugins qui avaient une compatibilité spip 3 (de 3.0 
à 3.2).
On a fait abstraction de tous les plugins qui n’avaient jamais passé le cap de 
spip3.
C’est le cas de ces plugins, je serais d’avis d’en rester là.


> 
> Merci de passer montants sur GIT qui pourrait resservir un jour
> 
> - montants Configurer le prix par defaut des objets (articles) suivant
> leurs branches exemple création de produits à la volée
> 

C’est aussi un plugin spip2.
Je peux le faire oui si tu veux continuer son développement.


> 
> Concernant l'effacement de l'historique par exemple pour le plugin
> participation, est-ce normal de ne pas retrouver les premiers commits ?
> voir par exemple avec formidable_participation
> https://zone.spip.org/trac/spip-zone/log/spip-zone/_plugins_/formidable_participation?rev=113448
> 
> https://git.spip.net/spip-contrib-extensions/formidable_participation/
> 

Ca arrive quand il y a eu une changement de dossier.
C’est en général récupérable mais il faut passer le script mergehistory qui 
parfois ne permet pas d’obtenir l’ensemble des commits non plus.
Si on en voit je peux encore essayer de corriger.

++
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 sous Git - Bascule finale au 1 juillet 2020 - suite

2020-06-30 Par sujet Eric Lupinacci
Hello,

> champs_extras_import_export

Non, inutile

> cornertease
> horloge_flash

Faits.

> porte_plume_liens_internes

Pas encore fait car j’ai une erreur subgit depuis quelques minutes.
Je prendrait tous les PP restants.

> tout_partout

Déjà fait et identifié par Rasta.

++
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 sous Git - Bascule finale au 1 juillet 2020 - suite

2020-06-30 Par sujet Eric Lupinacci
Yep,

> 
> - doc2article, compat spip 3 max mais portable facilement, permet d'importer 
> l'ensemble des fichiers du répertoire tmp/upload et de créer un article par 
> fichier automatiquement
> - gabarits, trunk début de portage pour SPIP 3.1 jamais terminé, mais le 
> plugin peut être utile et il est documenté
> 

Fait avec tous les commits !

++
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 sous Git - Bascule finale au 1 juillet 2020 - suite

2020-06-30 Par sujet Eric Lupinacci
Hello,

> 
> agenda_dates_floues : permet de préciser qu'une date est floue (mai 2020, 
> printemps 2021, etc), et filtre pour afficher
> amappca : début de conception pour gérer amap ou autre circuit court avec une 
> archi tentant de pouvoir gérer plein de cas
> api_syntaxe : donne accès à des fonctions de transformation de texte (propre, 
> _T, typo, etc) par API
> app : API Atom, lecture seulement mais pourrait gérer l'écriture (APP est 
> standardisé)
> ayants_droit : gérer des ayants droit sur n'importe quel contenu (objet lié), 
> avec les dates de validité, etc
> devis : objet simple représentant un devis
> menus_partager : insérer un menu déclaré dans un autre site SPIP
> mesfavoris_collections : pouvoir organiser ses favoris en collections
> prestations : lister des prestations dans n'importe quel contenu (objet lié)
> styleguide : à la base pour essayer de générer un guide de style, en suspens 
> mais à garder
> tout_partout : appliquer {tout} partout
> 

Fait

> 
> acces_restreint_date : configurable par rubrique, restreindre auto les 
> articles suivant leur date, avant ou après une période
> acces_restreint_ip : donner accès à des IP ou tranche d'IP, sans même avoir à 
> se connecter
> acces_restreint_videos : obliger à faire partie d'une zone pour voir un doc 
> inséré

Sont déjà dans git

> souhaits : gérer des listes de souhaits, avec lien, prix, et form pour 
> proposer d'offrir, y compris par cagnotte, afin de ne pas donner ces infos 
> très persos à des services "gratuits"
> 

Fait

++
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 sous Git - Bascule finale au 1 juillet 2020 - suite

2020-06-30 Par sujet Eric Lupinacci
Hello Touti,

> - askwiki, qui est censé permettre de récupérer les données d'une page wiki 
> pour remplir les contacts (date naissance etc)
> - aspirateur, tentative d'aspiration de pages en vue d'archives
> 
> - depublication qui tourne bien et possède sa doc sur contrib
> 
> - formidable_inscription qui permet de brancher une mailing list dessus
> 
> - knacsss / jeu css pour sass
> 

Ils sont désormais tous sous git.

++
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 sous Git - Bascule finale au 1 juillet 2020 - suite

2020-06-30 Par sujet Eric Lupinacci
Yep,

> Le 29 juin 2020 à 22:28, Jean-Philippe Guihard  a écrit 
> :
> 
> Bonsoir,
> 
> La structure n’est pas n’importe quoi, elle est juste en l’état de mes 
> maigres connaissances, et donc pas conforme.
> 

Si tu veux mais il y a des gens ici pour aider.


> Ce qui est OK dans tout cela, c’est :
> 
> branches/spip2/ pour la version adaptée à Spip v2
> branches/spip3/apropos_3/ qui est la version uptodate adaptée pour Spip v3. 
> Effectivement, cela devrait être branches/spip3/ tout court.
> 
> Je suis bien incapable de faire le ménage dans le SVN ne maitrisant pas la 
> chose.
> 

Ce que je propose :
- on vire alpha2 
- renomme et restructure les branches spip2 en v0 et spip3/apropos_3 en v1
- et on transfère.
Le risque est de perdre de l’historique

Sinon plus simple on ne transfère que le trunk car de tout façon spip 2 n’est 
plus maintenu.

Ton choix ?

++
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 sous Git - Bascule finale au 1 juillet 2020 - suite

2020-06-29 Par sujet Eric Lupinacci
Fait.

++
Eric 

 

Le 29/06/2020 19:49, « Charles Razack »  a écrit :

Je vote pour migrer le plugin chats, même s'il est plus ou moins
obsolète depuis la fabrique.
C'est un repère historique majeur ^^

Le 29/06/2020 à 19:25, Eric Lupinacci a écrit :
> Hello,
>
> Avec quelques regex sur _plugins_ j'ai identifié des plugins
> compatibles spip 3 mais non migrés.
> Il y a en environ 150.
> La liste est ici : http://spip.pastebin.fr/63331
>
> J'ai mis un commentaire sur certains qui me paraissent obsolètes.
> Pour le reste il faut décider mais au moins on a une liste.
>
> ++
> 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 sous Git - Bascule finale au 1 juillet 2020 - suite

2020-06-29 Par sujet Eric Lupinacci
Le problème de Apropos c’est que la structure SVN est n’importe quoi.
- Il existe un dossier Alpha/ : c’est quoi ?
- un dossier branches/ avec des sous-dossiers spip2/ et spip3/ (qu’il faudrait 
renommer en v0 et v1) et sous spip3/ on retrouve un dossier apropos_3/ qui ne 
devrait pas y être
- un dossier trunk/ qui semble ok.

Donc qu’est ce qui est à jour ?
Est-il besoin de récupérer tout ou peut-on admettre de perdre des commits ?

++
Eric


De : Jean-Philippe Guihard 
Date : lundi 29 juin 2020 à 20:00
À : Eric Lupinacci 
Cc : "YannX SPIP(hot)" , SPIP-Dev 
Objet : Re: [spip-dev] Migration sous Git - Bascule finale au 1 juillet 2020 - 
suite

Bonsoir,

je veux bien migrer apropos sous git, mais j’ai envoyé un message il y’a 
quelques semaines pour connaitre la méthode, mais sans réponse. Comment faire 
pour migrer mon plugin compte tenu de ma maigre connaissance de tous ces 
environnements ?

Merci à vous.

Le 29 juin 2020 à 19:25, Eric Lupinacci 
mailto:smel...@gmail.com>> a écrit :

Hello,

Avec quelques regex sur _plugins_ j'ai identifié des plugins compatibles spip 3 
mais non migrés.
Il y a en environ 150.
La liste est ici : http://spip.pastebin.fr/63331

J'ai mis un commentaire sur certains qui me paraissent obsolètes.
Pour le reste il faut décider mais au moins on a une liste.

++
Eric


Le lun. 29 juin 2020 à 18:15, YannX SPIP(hot) 
mailto:yannx.s...@hotmail.fr>> a écrit :
Bonsoir

  je trouve le plugin GMAP
https://contrib.spip.net/Plugin-GMap-geolocalisation-et-cartographie
- en version 0.2.1 compatible SPIP 2 en
https://zone.spip.org/trac/spip-zone/browser/spip-zone/_plugins_/gmap/branches
(avec un  ; manquant enboucle/gmap_boucle.php [617])
- une version 1.0 compatible SPIP 3 sur SVN
https://zone.spip.org/trac/spip-zone/browser/spip-zone/_plugins_/gmap/trunk?order=name
(que j'aimerais télécharger)
- mais rien dans Git (sauf  ): normal ? ou oubli ? ou remplacé par.

C'est d'autant plus genant que
https://git.spip.net/spip-contrib-extensions/gmapmxn/src/branch/master/plugin.xml
demande/necessite gmap ?

Merci d'avance du retour

--
YannX
http://www.spippourlesnuls.fr<http://www.spippourlesnuls.fr/>
___
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] Migration sous Git - Bascule finale au 1 juillet 2020 - suite

2020-06-29 Par sujet Eric Lupinacci
Hello,

Avec quelques regex sur _plugins_ j'ai identifié des plugins compatibles
spip 3 mais non migrés.
Il y a en environ 150.
La liste est ici : http://spip.pastebin.fr/63331

J'ai mis un commentaire sur certains qui me paraissent obsolètes.
Pour le reste il faut décider mais au moins on a une liste.

++
Eric


Le lun. 29 juin 2020 à 18:15, YannX SPIP(hot)  a
écrit :

> Bonsoir
>
>   je trouve le plugin GMAP
> https://contrib.spip.net/Plugin-GMap-geolocalisation-et-cartographie
> - en version 0.2.1 compatible SPIP 2 en
>
> https://zone.spip.org/trac/spip-zone/browser/spip-zone/_plugins_/gmap/branches
> (avec un  ; manquant enboucle/gmap_boucle.php [617])
> - une version 1.0 compatible SPIP 3 sur SVN
>
> https://zone.spip.org/trac/spip-zone/browser/spip-zone/_plugins_/gmap/trunk?order=name
> (que j'aimerais télécharger)
> - mais rien dans Git (sauf  ): normal ? ou oubli ? ou remplacé par.
>
> C'est d'autant plus genant que
>
> https://git.spip.net/spip-contrib-extensions/gmapmxn/src/branch/master/plugin.xml
> demande/necessite gmap ?
>
> Merci d'avance du retour
>
> --
> YannX
> http://www.spippourlesnuls.fr
>
>
___
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] Faut pas pusher mémé dans les orties

2020-06-29 Par sujet Eric Lupinacci
J’ai eu ça hier aussi sur Nomenclatures et c’est revenu comme par miracle…
Camille n’a rien vu de spécial.


> Le 29 juin 2020 à 14:27, Cerdic  a écrit :
> 
> Et c’est pareil sur pages, c’est donc généralisé...
> 
> $ git push --set-upstream origin master
> Enumerating objects: 7, done.
> Counting objects: 100% (7/7), done.
> Delta compression using up to 6 threads
> Compressing objects: 100% (4/4), done.
> Writing objects: 100% (4/4), 431 bytes | 431.00 KiB/s, done.
> Total 4 (delta 3), reused 0 (delta 0)
> remote:
> remote: SubGit ERROR REPORT (SubGit version 3.3.9 ('Bobique') build #4351):
> remote:
> remote: You've received this message because SubGit (http://subgit.com/ 
> ) is installed in your repository
> remote: and an error that needs to be dealt with has occurred in SubGit 
> translation engine.
> remote:
> remote: TEMPORARY ERROR:
> remote: Unable to parse pid file 
> /var/git/gitea/spip/repositories/spip-contrib-extensions/pages.git/./subgit/daemon.pid
> remote:
> remote: CURRENT STATE:
> remote: Both Git and Subversion repository are open for pushes or commits.
> remote: Your commit was not committed, but you may retry it.
> remote:
> remote: TO RECOVER:
> remote: A) Address the problem if possible and then retry commit
> remote: OR
> remote: B) Run on the server
> remote: $ subgit uninstall 
> /var/git/gitea/spip/repositories/spip-contrib-extensions/pages.git/.
> remote:
> remote: IMPORTANT: As soon as SubGit is uninstalled, both Git and Subversion 
> repositories
> remote: will become open, but no synchronization will take place.
> remote:
> remote: TO REPORT:
> remote: Report an issue at http://issues.tmatesoft.com/ 
> 
> remote: You may find logs on the server at 
> '/var/git/gitea/spip/repositories/spip-contrib-extensions/pages.git/./subgit/logs'
> remote:
> remote: THANK YOU!
> To git.spip.net :spip-contrib-extensions/pages.git
>  ! [remote rejected] master -> master (pre-receive hook declined)
> error: failed to push some refs to 'g...@git.spip.net 
> :spip-contrib-extensions/pages.git'
> 
> --
> Cédric
> Le 29 juin 2020 à 14:25 +0200, Cerdic , a écrit :
>> et polyhierarchie non plus visiblement
>> 
>> $ git push origin master
>> Enumerating objects: 7, done.
>> Counting objects: 100% (7/7), done.
>> Delta compression using up to 6 threads
>> Compressing objects: 100% (4/4), done.
>> Writing objects: 100% (4/4), 424 bytes | 424.00 KiB/s, done.
>> Total 4 (delta 3), reused 0 (delta 0)
>> remote:
>> remote: SubGit ERROR REPORT (SubGit version 3.3.9 ('Bobique') build #4351):
>> remote:
>> remote: You've received this message because SubGit (http://subgit.com/ 
>> ) is installed in your repository
>> remote: and an error that needs to be dealt with has occurred in SubGit 
>> translation engine.
>> remote:
>> remote: TEMPORARY ERROR:
>> remote: Unable to parse pid file 
>> /var/git/gitea/spip/repositories/spip-contrib-extensions/polyhierarchie.git/./subgit/daemon.pid
>> remote:
>> remote: CURRENT STATE:
>> remote: Both Git and Subversion repository are open for pushes or commits.
>> remote: Your commit was not committed, but you may retry it.
>> remote:
>> remote: TO RECOVER:
>> remote: A) Address the problem if possible and then retry commit
>> remote: OR
>> remote: B) Run on the server
>> remote: $ subgit uninstall 
>> /var/git/gitea/spip/repositories/spip-contrib-extensions/polyhierarchie.git/.
>> remote:
>> remote: IMPORTANT: As soon as SubGit is uninstalled, both Git and Subversion 
>> repositories
>> remote: will become open, but no synchronization will take place.
>> remote:
>> remote: TO REPORT:
>> remote: Report an issue at http://issues.tmatesoft.com/ 
>> 
>> remote: You may find logs on the server at 
>> '/var/git/gitea/spip/repositories/spip-contrib-extensions/polyhierarchie.git/./subgit/logs'
>> remote:
>> remote: THANK YOU!
>> To git.spip.net 
>> :spip-contrib-extensions/polyhierarchie.git
>>  ! [remote rejected] master -> master (pre-receive hook declined)
>> error: failed to push some refs to 'g...@git.spip.net 
>> :spip-contrib-extensions/polyhierarchie.git'
>> 
>> 
>> Plus que 48h à tenir et on se débarasse de ce fucking subgit qui nous 
>> pourrit la vie !
>> 
>> --
>> 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

___
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

2020-06-21 Par sujet Eric Lupinacci


> Le 21 juin 2020 à 21:00, Eric Lupinacci  a écrit :
> 
> On a fait un pas de géant ! Merci.
> 
>> Le 21 juin 2020 à 20:59, RealET  a écrit :
>> 
>> Eric Lupinacci a écrit le 21/06/2020 à 16:17 :
>>> Les derniers commits sur Bonux sont complètement foireux.
>>> Je n’arrive pas à faire marcher mon site en local.
>>> Il est urgent de remettre la dernière version qui fonctionne à savoir 3.5.4 
>>> et de debug les ajouts si ceux-ci sont pertinents.
>>> Je répète aussi que les tests doivent être faits avant les commits et avec 
>>> toutes les notices.
>>> Je suis revenu en 3.5.4 pour restaurer le fonctionnement du site.
>> Chez moi ça marche™
>> Et j'ai étudié le diff sans les espaces : la seule change qui change, c'est 
>> une ligne de commentaires (l'url dans le commentaire).
>> Pour le reste, c'est identique (puisque JLuc a rajouté puis enlevé quelque 
>> chose, pour revenir à l'état initial).
>> 

Je viens de réessayer :

Warning: Cannot modify header information - headers already sent by (output 
started at 
/Users/eric/Sites/ZONEGIT/gitea/spip-contrib-extensions/spip-bonux/spip_bonux_options.php:1)
 in /Users/eric/Sites/SPIP/ecrire/inc/actions.php on line 141

En plus l’indentation a changé et d’ailleurs elle est foireuse sous phpstorm.
Donc tant qu’à faire faut revenir vraiment à la version précédente du fichier 
svp.

++
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-Bonux

2020-06-21 Par sujet Eric Lupinacci
On a fait un pas de géant ! Merci.

> Le 21 juin 2020 à 20:59, RealET  a écrit :
> 
> Eric Lupinacci a écrit le 21/06/2020 à 16:17 :
>> Les derniers commits sur Bonux sont complètement foireux.
>> Je n’arrive pas à faire marcher mon site en local.
>> Il est urgent de remettre la dernière version qui fonctionne à savoir 3.5.4 
>> et de debug les ajouts si ceux-ci sont pertinents.
>> Je répète aussi que les tests doivent être faits avant les commits et avec 
>> toutes les notices.
>> Je suis revenu en 3.5.4 pour restaurer le fonctionnement du site.
> Chez moi ça marche™
> Et j'ai étudié le diff sans les espaces : la seule change qui change, c'est 
> une ligne de commentaires (l'url dans le commentaire).
> Pour le reste, c'est identique (puisque JLuc a rajouté puis enlevé quelque 
> chose, pour revenir à l'état initial).
> 
> 
> -- 
> RealET
> 
> 
> ___
> 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-Bonux

2020-06-21 Par sujet Eric Lupinacci
Les derniers commits sur Bonux sont complètement foireux.
Je n’arrive pas à faire marcher mon site en local.

Il est urgent de remettre la dernière version qui fonctionne à savoir 3.5.4 et 
de debug les ajouts si ceux-ci sont pertinents.
Je répète aussi que les tests doivent être faits avant les commits et avec 
toutes les notices.
Je suis revenu en 3.5.4 pour restaurer le fonctionnement du site.


++
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 sous Git - Bascule finale au 1 juillet 2020 - suite

2020-06-16 Par sujet Eric Lupinacci
Hello,


> 
> Pour résumé, il faut qu'on revalide notre process d'accueil, car j'allais 
> enfin prendre le temps de le faire pour Rémi (cf le fil à propos de 
> html5up_lens) et je me rends compte que je ne sais plus quelle est la 
> démarche maintenant qu'on est sous git, et surtout, je n'ai pas les droits 
> pour lui créer un compte sur gitea...
> 

Autre sujet aussi.
Sur la zone il nous reste encore les répertoires racine suivants qui ont été 
peu explorés:
- _acotes_ : dernière modification il y a 3 ans
- _composer_ : les tests de James
- _contribs_ : dernière modification il y a 5 ans
- _dev_ : on a récupérer Salvatore et univers_spip
- _doc_ : dernière modification il y a 7 ans
- _graphismes_ : dernière modification il y a 3 ans
- _modeles_ : dernière modification il y a 4 ans

Et _REGLES_DE_COMMIT et autodoc.txt

Je ne sais pas si il y a des choses récupérables d’emblée mais surtout on a 
_graphismes_ et _doc_ qui ne sont pas du tout du code et ne rentrent dans 
aucune organisation sous Gitea.
Ne faudrait-il pas créer un dernière organisation spip-contrib-annexes pour ce 
type de contributions graphiques ou autres ?
Et alors on y verserait quelques repos actuels à définir.

Pour _dev_ et _outils_ je renouvelle aussi ma proposition de faire une passe 
sur tous ces outils pour éventuellement faire des imports avant fin juin.

++
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 sous Git - Bascule finale au 1 juillet 2020 - suite

2020-06-15 Par sujet Eric Lupinacci
Hello,

Je me reponds déjà pour un point.

> Donc je relance un fil pour savoir si vous voyez des opérations préalables à 
> faire dans les 15 jours.
> Si c’est le cas il est temps de les identifier et de les faire.
> 

L’autodoc des plugins n’est pas migré (je sais pas d’ailleurs pour spip).
Le fichier autodoc.txt est aussi lui toujours sous svn.

A ne pas oublier donc.

++
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 sous Git - Bascule finale au 1 juillet 2020 - suite

2020-06-15 Par sujet Eric Lupinacci
Hello,


Je fais suite à mon mail du 28/05 sur la bascule finale sous Git au 1 juillet.
Je rappelle que c’est toujours l’objectif.

Donc je relance un fil pour savoir si vous voyez des opérations préalables à 
faire dans les 15 jours.
Si c’est le cas il est temps de les identifier et de les faire.

Moi j’ai une question.
Si on découvre le 2 juillet que le plugin « smoutch » qui a été développé sous 
svn en 1515 pourrait être repris avec bonheur aujourd’hui sous git.
Est ce que le script de migration fonctionnera bien encore même sans subgit ?

A vous lire.

++
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-06-15 Par sujet Eric Lupinacci
Hello,

> 
> Retenons donc, en tentative de conclusion de ce fil, et si vous le voulez 
> bien, que chacun•e est (fermement) invité•e à utiliser dans la communauté 
> SPIP, et sur les listes en particulier, mais non exclusivement, une forme 
> d’expression écrite dite « inclusive » (même si le terme peut faire débat), 
> et que tout le monde doit être garant de ça, en rappelant à l’ordre si besoin 
> celles et ceux qui s’oublient.
> 

Yep.
Et je pense qu’il ne faut pas oublier une des expressions SPIP les plus lues : 
les items de langue.
Une passe sur ces items serait pas forcément une mauvaise 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] Écriture inclusive

2020-06-07 Par sujet Eric Lupinacci
Yep,

> Le 7 juin 2020 à 20:19, nicod_  a écrit :
> 
> Ce qui peut poser des problèmes avec la restitution par un lecteur d'écran, 
> ce sont les formules plus compliquées avec répétitions de points médians, sur 
> des noms suivis d'adjectifs par exemple, qui donnent un texte complètement 
> haché.
> 

Ben justement, dans le texte indiqué par Matthieu 
http://www.haut-conseil-egalite.gouv.fr/IMG/pdf/guide_pour_une_communication_publique_sans_stereotype_de_sexe_vf_2016_11_02.compressed.pdf
 

 on remarque que dans le texte il n’y a que le substantif qui est écrit de 
cette façon et que dès qu’il est suivi d’un adjectif, celui-ci est écrit 
explicitement au féminin et au masculin dans un ordre d’ailleurs quelconque.
Je trouve que c’est une bonne pratique justement qui évite la répétition qui 
peut devenir cette fois pénible.

++
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] r125010 - in _core_/plugins/svp

2020-06-06 Par sujet Eric Lupinacci
Ça va être à peine suffisant 

Le sam. 6 juin 2020 à 20:55, Cerdic  a écrit :

> Je ferai un préfixe à 3 lettres sur le prochain plugin pour rattraper la
> moyenne, promis !
>
> --
> Cédric
> Le 6 juin 2020 à 15:33 +0200, Eric Lupinacci , a écrit :
>
> Ben je le dis.
> C'est juste n'importe quoi !
> Et de toute façon j'ai toujours considéré qu'n préfixe ne devrait pas
> avoir de _ alors tu imagines...
>
> Enfin, puisque tout est permis continuons on verra où ça pétera et si
> c'est dans un de mes plugins et bien on s'en tape...
>
> ++
> Eric
>
>
>
> Le 06/06/2020 15:29, « Matthieu Marcillaud »  a écrit
> :
>
> Le 06/06/2020 à 15:00, Eric Lupinacci a écrit :
>
> Ca ne me parait pas une bonne idée.
> Je pense que cette taille est aussi utilisée ailleurs.
> C'est un préfixe pas une phrase.
>
> Donc je ne suis pas trop pour.
>
>
> A proprement parler, il n’y a rien qui limite dans SPIP la taille du
> préfixe. C’est «juste» la copie en bdd des plugins dans SVP.
>
> Et va dire ça donc au plugin
>
> https://git.spip.net/spip-contrib-extensions/paniers_commandes_quantites_decimal
> .
>
> MM.
>
> ___
> 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] r125010 - in _core_/plugins/svp

2020-06-06 Par sujet Eric Lupinacci
Ben je le dis.
C'est juste n'importe quoi !
Et de toute façon j'ai toujours considéré qu'n préfixe ne devrait pas avoir de 
_ alors tu imagines...

Enfin, puisque tout est permis continuons on verra où ça pétera et si c'est 
dans un de mes plugins et bien on s'en tape...

++
Eric 

 

Le 06/06/2020 15:29, « Matthieu Marcillaud »  a écrit :

Le 06/06/2020 à 15:00, Eric Lupinacci a écrit :
> Ca ne me parait pas une bonne idée.
> Je pense que cette taille est aussi utilisée ailleurs.
> C'est un préfixe pas une phrase.
> 
> Donc je ne suis pas trop pour.

A proprement parler, il n’y a rien qui limite dans SPIP la taille du 
préfixe. C’est «juste» la copie en bdd des plugins dans SVP.

Et va dire ça donc au plugin 

https://git.spip.net/spip-contrib-extensions/paniers_commandes_quantites_decimal
 
.

MM.

___
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] r125010 - in _core_/plugins/svp

2020-06-06 Par sujet Eric Lupinacci
Ca ne me parait pas une bonne idée.
Je pense que cette taille est aussi utilisée ailleurs.
C'est un préfixe pas une phrase.

Donc je ne suis pas trop pour.

++
Eric 

 

Le 06/06/2020 12:45, « spip-zone-com...@rezo.net »  
a écrit :

Author: Matthieu Marcillaud
Date: 2020-06-06 10:44:30 + (Sat, 06 Jun 2020)
New Revision: 125010

Modified:
   _core_/plugins/svp/
   _core_/plugins/svp/base/svp_declarer.php
   _core_/plugins/svp/paquet.xml
   _core_/plugins/svp/svp_administrations.php
Log:
Certains s'amusent a mettre des prefixes a rallonge. On augmente un peu la 
taille de ce champ.


Details: https://zone.spip.org/trac/spip-zone/changeset/125010

___
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] Écriture inclusive

2020-06-05 Par sujet Eric Lupinacci
Yep,

> Le 5 juin 2020 à 12:05, RastaPopoulos  a écrit :
> 
> Le 05/06/2020 à 10:42, Eric Lupinacci a écrit :
>> On pourrait aussi édicter quelques recommandations sur l’écriture des items 
>> de langue pour homogénéiser les habitudes.
> 
> On parlait aussi l'autre jour d'augmenter un peu la charte pour être plus 
> explicite sur ce point. Après elle doit rester concise, le but n'est pas de 
> faire une formation à l'écriture dans la charte, mais on doit pouvoir 
> l'augmenter d'une ou deux phrases pour être plus clair sur l'écriture.
> 

Oui surement mais je vois aussi un truc plus précis avec des exemples pour 
privilégier telle écriture ou telle autre.
Parce que si certaines mettent des () d’autres des ‘.' ou autre chose ça va 
être la kermesse et c’est pas super pédagogique.

++
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-06-05 Par sujet Eric Lupinacci
Hello,

Je ne me considère pas comme un exemple sur ce sujet.
J’ai même parfois pas mal de réticence.
Mais je crois qu’on ne peut plus aujourd’hui faire abstraction du sujet juste 
pour des considérations de simplicité, beauté ou autre.
Je conseille d’ailleurs à ceux qui ne l’ont pas fait de lire de document que 
Matthieu a posté sur IRC : 
http://www.haut-conseil-egalite.gouv.fr/IMG/pdf/guide_pour_une_communication_publique_sans_stereotype_de_sexe_vf_2016_11_02.compressed.pdf
Il est très bien fait et assez éclairant.

Mais plutôt que d’en parler de temps en temps dans des mails ou des posts quand 
Touti nous le rappelle jsutement, ça serait bien d’être plus exemplaire dans 
les milliers d’items de langue que nous avons générés dans SPIP et dans les 
plugins.
Je serais aussi d’avis de ne plus avoir de fr_fem ou autre car justement ça me 
parait aller à l’encontre de ce que l’on veut.
On pourrait aussi édicter quelques recommandations sur l’écriture des items de 
langue pour homogénéiser les habitudes.


++
Eric


De : Cédric Morin 
Date : vendredi 5 juin 2020 à 10:21
À : "spip-dev@rezo.net" , Christian Marget 
Objet : Re: [spip-dev] Écriture inclusive

Sans verser dans le troll, je pense que cette position n’est juste pas tenable.

Le monde doit changer, le comportement des hommes doit changer, et le fait 
qu’il faille s’habituer à une forme d’écriture qui nous plait pas trop est un 
infime détail dans tout ce qui doit changer.
Donc si on commence à argumenter et pinailler là dessus c’est une façon très 
claire de dire haut et fort « vous devrez vous battre sur chaque pouillème de 
place que vous voulez avoir dans cette société, on ne lâchera rien sans verser 
de sang ».

Aka, si on voulait faire autrement, on (en tant que hommes faisant partie d’une 
société dominée par les hommes) a eu des siècles pour ça, et on a rien fait de 
significatif.
Donc maintenant on a juste à se taire, écouter et faire de la place, en 
commençant donc par cesser d’invisibiliser la moitié de la société, en 
particulier lorsqu’elle nous le demande.

Et donc quand quelqu’une nous demande de changer de mode d’expression parce 
qu’elle se sent blessée et ignorée par la façon dont on s’exprime, répondre 
qu’on a pas trop envie parce que ça nous plait pas trop est une forme de 
violence en cela que c’est la négation même de son ressenti.

--
Cédric
Le 4 juin 2020 à 23:03 +0200, Christian Marget , a écrit :

Le 04/06/2020 à 22:22, RastaPopoulos a écrit :

Le 04/06/2020 à 19:53, Christian Marget a écrit :

- si je trouve une parenthèse comme dans technicien(-ne), la parenthèse
se transforme à l'oral en «ou technicienne» qui me vient naturellement.
Ce qui n'est pas le cas du «technicien.ne», excusez-m'en.

Sommet de mauvaise foi
Remarque parfaitement stérile, et saugrenue de la part de quelqu'un qui
ne me connaît pas. Ça m'apprendra à vouloir apporter mon témoignage et
mon ressenti.

Je ne vois pas l'intérêt de poursuivre cette discussion dans ces
conditions. Bye

CM
___
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] Nomenclatures et serveur de données

2020-06-01 Par sujet Eric Lupinacci
Yep,


> Le 1 juin 2020 à 14:51, nicod_  a écrit :
> 
> pour ma part, comme ce sont des données pas très volumineuses, je préfère 
> qu'un site intègre lui même les données dans ses tables plutôt que de 
> dépendre d'une API distante qui peut être indisponible à un moment donné.
> 

C’est pas vraiment la question.
L’API n’est pas utilisée tout le temps de la même façon que les plugins ne 
peuplent leur table qu’à l’installation.
Donc ce n’est pas une question de dépendance à mon avis.

Par contre quand tu en as besoin tu as un truc unique à jour.

++
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] Nomenclatures et serveur de données

2020-06-01 Par sujet Eric Lupinacci
Hello,


J’ai réalisé il y a déjà pas mal de mois (voire d’années) un plugin 
confidentiel nommé Nomenclatures (préfixe isocode) qui rassemble des data 
normatives sur les langues, les unités monétaires, les pays et autres zones 
géographiques…
Le but à l’origine était de pouvoir contrôler les étiquettes de langue SPIP et 
de proposer un renommage, ce qui a été fait dans des articles de la Taverne (à 
intégrer à SPIP pour la 4.0).

Il y a quelques temps j’ai doté Nomenclature d’une API REST basée sur REST 
Factory de façon à offrir ces données à l’ensemble de la communauté et des 
plugins qui pourraient en avoir besoin.
En particulier, les plugins Continents, Pays et Géographie pourraient y puiser 
les données de peuplement des tables.

Donc, je me dis que ça serait bien d’installer ce plugin sur un site de la 
Galaxie et de s’en servir.
On pourrait aussi ajouter une page d’affichage brute des données dans des 
tableaux.
Et donc à partir de là envisager de modifier les plugins de géographie pour 
l’acquisition des données.

Qu’en pensez-vous ?
Si vous pensez que c’est une bonne idée dans quel site de la galaxie 
trouverait-il sa place ?


++
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 - Migration de _dev_

2020-06-01 Par sujet Eric Lupinacci
Ok, c’est ce que j’imaginais.

> Le 1 juin 2020 à 13:34, Cerdic  a écrit :
> 
> Non plus besoin de salvatore de _dev_ c’est la vieille version. 
> Salvatore est maintenant intégré dans le plugin trad-lang
> 
> --
> Cédric
> Le 1 juin 2020 à 13:26 +0200, Eric Lupinacci , a écrit :
>> Hello,
>> 
>> On vient de migrer le repo _dev_/univers_spip qui était uniquement sous SVN. 
>> Il est maintenant dans l’organisation spip-contrib-galaxie.
>> Il reste encore un Salvatore dans _dev_ : est-il utile ou pas ?
>> 
>> Une petite chose encore : ne serait-il opportun de transférer le débardeur 
>> dans spip-contrib-outils ?
>> 
>> ++
>> 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

___
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 - Migration de _dev_

2020-06-01 Par sujet Eric Lupinacci
Hello,

On vient de migrer le repo _dev_/univers_spip qui était uniquement sous SVN. Il 
est maintenant dans l’organisation spip-contrib-galaxie.
Il reste encore un Salvatore dans _dev_ : est-il utile ou pas ?

Une petite chose encore : ne serait-il opportun de transférer le débardeur dans 
spip-contrib-outils ?

++
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 sous Git - Bascule finale au 1 juillet 2020

2020-05-28 Par sujet Eric Lupinacci
Yo,

> Le 28 mai 2020 à 13:45, Stephane Santon  a écrit :
> Le 28/05/2020 à 13:32, Eric Lupinacci a écrit :
>>> Mais en terme de lisibilité de la communication communautaire, de respect 
>>> des pratiques de déploiement mises en place par beaucoup, je trouve ça 
>>> n'est ni rassurant, ni sécurisant.
>> Je trouve ce mail proprement scandaleux et j’en suis offusqué.
>> C’est franchement un manque de considération et une vision égocentrique qui 
>> me sidère.
>> Ca fait plus de deux ans que ce passage sous git est envisagé.
> 
> OK OK. On va pas se taper sur la gueule non plus !??
> 
> RealET ne juge pas la qualité du travail accompli, mais évoque le ressenti 
> possible de personnes tierces qui ne suivent pas l'évolution de Spip à la 
> culotte.
> 

Merci de ton éclairage!
Et donc ?
Tu peux me dire ce que c’est « un ressenti possible » ?

Ben moi aussi en lisant le mail j’ai un ressenti et il est pas possible il est 
sur.

++
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 sous Git - Bascule finale au 1 juillet 2020

2020-05-28 Par sujet Eric Lupinacci
Hello,


> C'est clair, mais c'est pas fair play.
> 
> Initialement, on avait dit que seul le core passait en Git.
> Puis, ça a été tout en Git, mais avec la décision que SVN serait en lecture 
> seule pour tout le monde, sauf git qui ferait la synchro uniquement dans le 
> sens Git->SVN (donc simplification puisque plus de synchro bidirectionnelle).
> Finalement, on va fermer SVN.
> 
> Il y a un pragmatisme que je peux comprendre et même y adhérer.
> 
> Mais en terme de lisibilité de la communication communautaire, de respect des 
> pratiques de déploiement mises en place par beaucoup, je trouve ça n'est ni 
> rassurant, ni sécurisant.
> 

Je trouve ce mail proprement scandaleux et j’en suis offusqué.
C’est franchement un manque de considération et une vision égocentrique qui me 
sidère.

Ca fait plus de deux ans que ce passage sous git est envisagé.
Ca fait 6 mois que ça a vraiment commencé.
On a expliqué la démarche à chaque étape, tenu les gens au courant des avancées 
avec des mails (si tu veux je les ressors).

Le constat est qu’aujourd’hui le svn est un boulet qui pèse sur notre 
environnement et donc sur sa maintenance.
T’es tu un jour posé la question du temps passé sur cette maintenance et aussi 
d’une chose sale dont il faut jamais parler, à savoir, son financement ?
Et oui, en migrant on s’est rendu compte de certaines difficultés non 
anticipées… Et alors, tu nous avais prévenu ?

On a encore beaucoup de choses à faire pour améliorer notre environnement, il 
est donc temps de se simplifier la vie avant que beaucoup jettent l’éponge à 
force de ramer.
C’est sur que c’est pas ton cas.


++
Eric, furieux.

___
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 sous Git - Bascule finale au 1 juillet 2020

2020-05-27 Par sujet Eric Lupinacci
Yep,

> Le 27 mai 2020 à 16:12, nicod_  a écrit :
> 
> Le 27/05/2020 à 11:56, Eric Lupinacci a écrit :
>> Après, on pourra s’occuper de la dernière grosse opération de migration, à 
>> savoir les tickets redmine.
> 
> L'idée serait de les basculer sur Gitea ?
> 

Oui, on aura tout au même endroit.
On a déjà les tickets pour tous les repos plugins et franchement ça change la 
vie de pouvoir les utiliser pour les remontées de bug ou les features à venir.

++
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 sous Git - Bascule finale au 1 juillet 2020

2020-05-27 Par sujet Eric Lupinacci
Hello,


Aujourd’hui la migration sous git est bien avancée:

- les plugins SPIP 3 sont tous migrés sur le Gitea à l’exception de certains 
qui sont passés sous le radar car non zippés.
- le débardeur construit les zips pour tout type de repo
- tradlang utilise git
- Plugins SPIP est donc correctement alimenté par les zips du débardeur
- les logs de commits sont maintenant générés par le débardeur également à 
partir du Gitea
- subgit permet de synchroniser git et svn
- il existe un backup complet sous GitHub de la zone svn
- on des ressources scripts et docs pour travailler sous git

On est donc largement opérationnel pour travailler sous git même si tout n’est 
pas encore parfait.

Néanmoins, la synchronisation svn-git est complexe, fragilise notre système et 
devient finalement plus nécessaire aujourd’hui.
Il faut alléger nos environnements tant en complexité qu’en maintenance.
Il est donc proposer de couper définitivement le lien svn à partir du 1 
juillet. A cette date:

- la synchronisation svn-git serait coupée et on arrêterait le subgit
- la zone svn serait fermée en écriture, donc plus aucun commit ne sera 
possible en svn
- tout commit se ferait via git et si certains plugins ont été oubliés ou 
ressortis du placard il sera possible de les importer sous gitea à la demande.

Cela laisse le mois de juin pour basculer les environnements svn en git pour 
ceux qui n’ont pas encore fait le pas.

Après, on pourra s’occuper de la dernière grosse opération de migration, à 
savoir les tickets redmine.


Vos avis?

++
Eric

PS: on pourrait peut-être aussi sortir la 3.3 en même temps ou c’est trop ?
___
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] Grille boostrap 4 / SpipR

2020-05-25 Par sujet Eric Lupinacci
Hello,

> Le 25 mai 2020 à 13:50, Stephane Santon  a écrit :
> 
> Désolé de relancer le débat ;-)
> Une rubrique Contrib est-elle directement liée à un plugin ??
> 

Y a pas de débat, c’est plutôt factuel.
Dans la refonte de contrib et dans le but d’intégrer simplement Plugins SPIP 
dans Contrib à terme, j’ai fait coïncider les rubriques de niveau 2 des 
secteurs accueillant des plugins avec un plugin, donc un préfixe.
De fait, ici il y a deux plugins.
Pour comprendre la refonte lire : 
https://docs.google.com/document/d/1LorPbF10xe5JsWkvze8_r8Y81qvHxLFcNW-JX_yUBaA/edit?usp=sharing
 



> La rubrique s'appelle BootStrap-v2-pour-SPIP :
> Accueil > Développement de sites et de plugins > Framework CSS > BootStrap v2 
> pour SPIP > BootStrap v2 pour SPIP
> 
> et n'a qu'un article BootStrap-v2-pour-SPIP (il me semble)
> 
> Donc on pourrait renommer la rubrique en :
> BootStrap pour SPIP (sans numéro de version)
> 
> et avoir 2 articles :
> 
> BootStrap v2 pour SPIP
> et
> BootStrap v4 pour SPIP
> 

Donc 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] Grille boostrap 4 / SpipR

2020-05-25 Par sujet Eric Lupinacci
Hello,

> Le 25 mai 2020 à 08:47, Cerdic  a écrit :
> 
> oui, c’est ça que je voulais dire mais que j’ai oublié :p
> il faut surtout pas modifier l’article de documentation de bootstrap2 pour 
> documenter bootstrap4, il y a trop de différence, même si cette partie sur la 
> grille est assez similaire.
> 
> J’ai d’ailleurs renommé la rubrique et l’article sur contrib en ajoutant le 
> v2 dans le titre, pour eviter les ambiguité
> On peut créer une nouvelle rubrique et un nouvel article pour Bootstrap 4
> 

Non on doit !
C’est pas le même préfixe, donc pas le même plugin, donc pas la même rubrique.
Comme ça ça simplifie le débat, y en a pas :)

++
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] Lien entre les articles du Wiki et les articles de doc

2020-05-20 Par sujet Eric Lupinacci
Hello,

Une dernière pour la route.

> Le 20 mai 2020 à 11:18, YannX SPIP(hot)  a écrit :
> 
> Bonjour,
> 
> je voudrais apporter un complément (expérience) à J-Luc, et un soutien a 
> cette idée démarche de documentation (avec aussi l'approche SPN),
> car il n'est pas seul à privilégier cette approche : en effet, le respect 
> 'extrémisé' du droit d'auteur me semble expliquer ce principe (un peu 
> contre-evolutif) des articles *figés* dans SPIP.
>  Il est sûr que la qualité rédactionnelle des articles validés sur Contrib 
> apporte une information pertinente (l'attention avec laquelle ont pu etre 
> scrutés quelques articles est positive), mais des compléments pertinents se 
> trouvent aussi en Carnet (je pense immédiatement à Saisis découvert par 
> hasard...).
> Et quand on relit les intervenants, manifestement  il y a aussi bcp 
> de"sachants" à intervenir dans le Carnet.
> 
> Or au bout d'un certain temps sur SPIP, je constate encore le besoin d'un 
> espace d'information intermediaire entre spip.net et programmer, et j'insiste 
> aussi : un espace d'information evolutive, qui permet de 
> compléter/mémoriser/capitaliser les elements indiqués en réponse..par exemple 
> sur IRC
> 
> Le Carnet propose cette solution wiki (ou le plugin "Nouvelle Version" qui 
> manque encore d'une option "annuler")  et donc permet d'apporter  :
> - un complément collaboratif d'information
> - une mise en commun progressive
> Tout le monde n'a pas un site de doc a disposition à compléter (comme SPN, 
> Cym ou autres.. de moins en moins nombreux)
> 

Une doc pour expliquer ce n’est pas, vu de ma fenêtre en tout cas, un carnet de 
voyage où l’on relate sa propre expérience.
Ca a un but, un auditoire et en fonction de ça on réfléchit à la meilleure 
façon de faire comprendre l’essentiel du message.
Ton carnet de voyage il ne correspond pas forcément au mien, je ne vais donc 
pas forcément m’y retrouver.
Mais faire une doc c’est plus complexe, plus long et plus prenant...

> 
> Je regardais justement la https://contrib.spip.net/Saisies-1347
> - déjà 8 articles (et au moins 4 dans le Carnet /je m'en suis aussi créé 
> trois perso/),
>   donc la documentation descriptive -tres bien fournie pourtant- n'est pas 
> toujours  suffisante.
> 

Mais purée pour laisser dans le carnet une doc qui pourrait compléter une 
rubrique existante.
Faut quand même être tordu.
Et en plus pour couronner le tout on se fait des liens avec le carnet parce que 
c’est chouette d’en avoir un peu partout...


> Donc je soutiens cette demande :
> - avoir un pavé "voir aussi" pour indiquer des articles du carnet
> Et plutôt que de l'avoir au niveau de l'article (comme proposé par A2A),
> je proposerais de rajouter l'affichage de ce pavé dans la page Rubrique, 
> puisque justement la structure de Contrib est structurée par les rubriques 
> (cela contribuerait à établir le lien formel de redaction des carnets vers 
> les rubriques traditionnelles de Contrib).
> Cela impliquerait de rajouter un cartouche de selection de la rubrique de 
> rattachement dans la page d'article...
>ce qui inviterait a compléter la rédaction...
> 
> 
> PS : j'aurai aussi deux interrogations sur cette page "rubrique" finale
> - l'ordre, le role, l'index ou l'angle d'approche des divers articles (j'ai 
> oublié les réflexions déjà à ce sujet)
> - redonnant plus d'importance à cette page rubrique (sauf cas de 
> Court-Circuit),
>   certaines rubriques (au moins) pourraient mériter un texte d'introduction
> 
>-> mais ce sera un autre fil, peut-etre...

Y a un groupe de travail sur l’ergo de Contrib…
Désole il est pas dans le Carnet !
Et cette fois c’est bien 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] Lien entre les articles du Wiki et les articles de doc

2020-05-20 Par sujet Eric Lupinacci


> Le 20 mai 2020 à 10:06, JLuc  a écrit :
> 
> **Et pour cela il faut arrêter de le dénigrer**
> **et le valoriser comme espace de coopération**

Je ne dénigre pas je constate.


> et favoriser les rencontres sur ces docs,
> entre besoins-initiateurs-de-pages et sachants-finalisateurs-de-pages.
> 

Qui empêche les gens de créer des groupes de travail, de poser des questions à 
d’autres pour essayer de compléter les articles du carnet ? Qui ?
Or ce n’est jamais fait, on pose c’est souvent un peu fini.


> Pistes : des docathons ? des pages highlightées avec appel à finalisation ?
> 

Why not. Mais pareil pourquoi attendre pour organiser ?

>> Il faudrait surtout que leur auteurs aient envie de la finir…
>> Peut-être aussi un peu de courage et de temps à donner...
> 
> Il est certain que l'envie, le courage et le temps permettent de terrasser 
> bien des dragons.
> Mais confier cette charge aux auteurs seuls c'est accorder peu d'intérêt au 
> pouvoir de la collaboration.
> Chacune de ces pages est un appel à coopération.
> 

Ben oui mais c’est le point de désaccord majeur je pense.
Tout le monde en a plein la bouche de la collaboration en oubliant quand même 
que la base c’est une équipe tendue vers un même objectif.
Ce n’est pas des individus qui déposent quand ils le souhaitent, ce qu’ils 
souhaitent où il le souhaitent.
Pour moi c’est une différence fondamentale et je ne crois pas qu’un jour on se 
retourne sur ce point.

J’ai passé des mois sur Contrib.
J’ai eu l’aide de Maieul.
On est loin d’avoir fini mais ça n’intéresse personne de finir le boulot c’est 
tellement plus simple de continuer le carnet.

Alors bon courage pour la suite mais moi Contrib c’est du passé, je vous le 
laisse.

++
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] Lien entre les articles du Wiki et les articles de doc

2020-05-19 Par sujet Eric Lupinacci
Hello,


> Le 19 mai 2020 à 18:01, JLuc  a écrit :
>> Je ne suis pas d'accord avec cette compréhension du wiki, et de fait il y a 
>> plein d'articles dans le wiki qui y restent longtemps et n'en sortent jamais.

Et oui, éternel débat et éternel désaccord.
Je suis absolument en ligne avec Maieul et je pense que si toi et d’autres 
tenants du wiki à outrance vous passiez un peu de temps à maintenir l’éditorial 
de ce site (au sens large) vous changeriez peut-être d’avis.
Il y a une facilité à l’utilisation du wiki qui malheureusement confine à 
éterniser le temporaire, à disperser l’information, à la rendre presque 
invisible, donc inaccessible, donc inutile in fine.
Quand j’ai rangé (euphémisme) Contrib j’ai justement déplacé de la doc 
finalisée sur des plugins stables depuis des années. Alors oui il existe le 
lien de doc dans la paquet.xml mais c’est quand même mieux quand tout plus 
accessible.

Je sais qu’on est pas d’accord.


> 
> Quand de plus certaines personnes s'érigent en gardiennes intransigeantes de 
> l'orthodoxie de la documentation,
> et refusent toute entrave à leur propre conception de ce que doit être une 
> doc (cf autre thread récent),
> il est clair que les pages du wiki ne sont pas prêtes d'en sortir : elles 
> dérangeraient trop !
> 

Tu exagères.
Comme je te dis mets les mains dans laye cambouis de Contrib comme le fait 
Maieul et après on en discute.
Aider c’est aussi participer à une logique qui n’est pas personnelle et qui 
peut obliger parfois à se plier à des règles pour le bien de tous.


> Pour un grand nombre de page, ce n'est que justice, car ces pages sont des 
> bribes, des balbutiements, des tâtonnements, des notules ou de grands chaos 
> informes.
> 
> Parfois tout de même, c'est dommage, car ok le contenu n'est pas au point,
> mais la page témoigne d'un besoin réel qui n'est pas satisfait par la doc 
> "officielle".
> 
> Mais pour qu'une page sorte du wiki, il faudrait
> - que leurs auteurs accèdent à la connaissance complète et sans entrave de ce 
> qu'ils documentent
> - complètent leur documentation d'une manière acceptable pour être rendue 
> visible au grand jour
> - ou bien que des mieux-sachants acceptent de considérer les interrogations 
> qui se posent, et de corriger les errements
> tant dans la forme que dans le contenu.
> 

Il faudrait surtout que leur auteurs aient envie de la finir…
Peut-être aussi un peu de courage et de temps à donner...

++
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] Cloner tout git.spip.net

2020-05-16 Par sujet Eric Lupinacci
Yep,


> Le 16 mai 2020 à 11:40, Cerdic  a écrit :
> 
> Là ça utilise clone_url de la réponse de l’API, qui est une url https, mais 
> il y a une autre entrée qui donne l’url ssh, donc on pourrait ajouter une 
> option pour cloner tout en ssh
> 
> Fais-toi plaisir ! :)
> 

C’est commité, une option —ssh.

++
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] Cloner tout git.spip.net

2020-05-16 Par sujet Eric Lupinacci
On peut faire du ssh et du https ?

> Le 15 mai 2020 à 21:28, nicod_  a écrit :
> 
> Le 15/05/2020 à 09:38, Cerdic a écrit :
>> Ah oui le .gitignore j’y ai pensé et puis j’ai oublié parce que chez moi je 
>> clone à coté (j’ai mis un lien symbolique sur le mirror.php), mais je pense 
>> que ce serait bien en effet.
> 
> Pour info :
> https://git.spip.net/spip-contrib-outils/gitea_mirror/pulls/1
> 
> (ton README était en iso-8859)
> 
>> Et oui pour ajouter une ligne dans le readme a propos de checkout.php 
>> j’avais oublié ça aussi
> 
> J'ai pas mis à jour le README mais je propose un test :
> https://git.spip.net/spip-contrib-outils/gitea_mirror/pulls/2
> 
> -- 
> 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] Meta dans une table spécifique

2020-05-15 Par sujet Eric Lupinacci
Hello,

> Le 15 mai 2020 à 15:10, Eric Lupinacci  a écrit :
> 
> J’essaye de mettre en place une configuration de plugins dans une table 
> différente que spip_meta et je me heurte à quelques incohérences dans les API 
> SPIP.
> ...
> Donc il me semble qu’il y a plusieurs incohérences voire bugs :
> - l’API Config et Meta ne fonctionnent pas de la même façon vis-à-vis d’un 
> table différente de spip_meta
> - l’upgrade fait appel à l’API meta et pas à l’API Config ce qui provoque en 
> partie le problème.
> - l’attribut meta ne semble pas être utilisé correctement lors de 
> l’installation.
> 

Premiers éléments de réponse :

La fonction qui permet d’installer ou de dés installer un plugin est dans la 
plupart des cas spip_plugin_install().
Cette fonction a le code suivant :

function spip_plugin_install($action, $infos, $version_cible) {
   $prefix = $infos['prefix'];
   if (isset($infos['meta']) and (($table = $infos['meta']) !== 'meta')) {
  $nom_meta = "base_version";
   } else {
  $nom_meta = $prefix . "_base_version";
  $table = 'meta';
   }
   switch ($action) {
  case 'test':
 return (isset($GLOBALS[$table])
and isset($GLOBALS[$table][$nom_meta])
and spip_version_compare($GLOBALS[$table][$nom_meta], 
$version_cible, '>='));
 break;
  case 'install':
 if (function_exists($upgrade = $prefix . "_upgrade")) {
$upgrade($nom_meta, $version_cible, $table);
 }
 break;
  case 'uninstall':
 if (function_exists($vider_tables = $prefix . "_vider_tables")) {
$vider_tables($nom_meta, $table);
 }
 break;
   }
}
C’est donc elle qui appelle les fonctions contenues dans 
_administrations.php.
On voit aussi qu’elle examine la paquet du plugin pour savoir si l’attribut « 
meta » a été rempli avec une table autre que meta.
Et donc la chose importante est que le prototype de la fonction upgrade ou 
vider_tables possède toujours un argument $table à la fin qui indique la table 
des metas pour le plugin.
Et cet argument est systématiquement absent de tous nos plugins et cela est 
renforcé par le fait que la Fabrique et Programmer n’en font pas référence.

Donc une bonne pratique serait maintenant de rajouter cet argument dans ces 
fonctions.
Cet argument $table devant être passé à la fonction maj_plugin() ou à 
effacer_meta par exemple.

Après ces modifications, il ne reste plus qu’un seul problème : la table 
spécifique des meta n’existe pas la première fois et comme l’API meta ne la 
crée pas au contraire de l’API config on a une erreur SQL. Je pense que c’est 
sur ce point qu’il faut faire une correction.

++
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] Meta dans une table spécifique

2020-05-15 Par sujet Eric Lupinacci
Hello,

J’essaye de mettre en place une configuration de plugins dans une table 
différente que spip_meta et je me heurte à quelques incohérences dans les API 
SPIP.

1) L’API Config.
Les fonctions lire_config(), ecrire_config() et effacer_config() permettent 
aujourd’hui de spécifier la table dans laquelle lire ou écrire une variable de 
configuration.
Il suffit pour ça de rajouter /nom_table_sans_spip/ devant le nom de la 
variable.
Cela fonctionne parfaitement surtout que l’API gère également la création 
automatique de la table voire sa suppression quand cela est nécessaire.

2) L’API Meta et les upgrade de base
C’est là que ça se gâte.
Après avoir créé une meta de configuration dans une table autre que spip_meta 
pour mon plugin, appelons-la spip_mameta, je me suis dis que pour être cohérent 
il serait mieux de mettre la meta standard du plugin préfixe_base_version.

Donc j’ai utilisé la déclaration meta du paquet.xml (attribut de la balise 
paquet) qui est censée indiquer justement que les metas du plugin doivent être 
stockées dans une table donc le nom est celui de l’attribut préfixé par meta.
Donc j’ai ajouté cet attribut dans le paquet.xml, meta=« mameta » et lancé 
l’installation. Résultats des erreurs : 
https://framapic.org/JsNg3KT0MQmw/qceJT2ZbZuzM.png 
 et pourtant un plugin 
installé mais aucune table créée, ni la meta mameta_version_base. Par contre, 
la configuration écrite via l’API Config est bien dans spip_mameta et la meta 
tables_config contient bien cette table.

Néanmoins, il existe dans la fonction maj_plugin() un quatrième argument qui 
permet de passer justement la table meta à utiliser : elle devrait être déduite 
par l’attribut mais pour essayer je saisis donc mameta dans l’appel de 
maj_plugin().
Le résultat semble plus probant mais les écritures dans la table spip_mameta ne 
se font pas car la table n’est pas créée automatiquement si elle n’existe pas 
comme pour l’API  Config.
Donc il me semble qu’il y a plusieurs incohérences voire bugs :
- l’API Config et Meta ne fonctionnent pas de la même façon vis-à-vis d’un 
table différente de spip_meta
- l’upgrade fait appel à l’API meta et pas à l’API Config ce qui provoque en 
partie le problème.
- l’attribut meta ne semble pas être utilisé correctement lors de 
l’installation.

Est-ce que j’utilise mal les API ou confiez-vous les bugs ?
Si bug, il serait bon de les corriger en 3.3.

++
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] Cloner tout git.spip.net

2020-05-15 Par sujet Eric Lupinacci
Hello,

> Le 15 mai 2020 à 09:38, Cerdic  a écrit :
> 
> Ah oui le .gitignore j’y ai pensé et puis j’ai oublié parce que chez moi je 
> clone à coté (j’ai mis un lien symbolique sur le mirror.php), mais je pense 
> que ce serait bien en effet.
> 

Je pige pas.
Le .gitignore de SPIP doit suffire non, pourquoi le copier dans chaque repo 
puisque qu’on devrait pas en avoir besoin ?

++
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] Config et meta

2020-05-13 Par sujet Eric Lupinacci
Hello,


J’ai remis le nez un peu dans les fichiers inc/config et inc/meta pour relire 
certaines fonctions.
Je suis tombé sur deux trucs un peu faisandés même si ça ne pose pas de 
problème pour l’instant:

La fonction lister_configurer() de inc/config qui fait direct un return 
array(); sans dérouler un seul code et qui ne semble plus utilisée dans SPIP.
Un appel à spip_query dans inc/meta : spip_query("SELECT nom,valeur FROM 
spip_$table »)

Vu qu’on a la version 3.3 en vue :

Pour 1) ne faudrait-il pas supprimer cette fonction dans SPIP et la mettre je 
ne sais où d’ailleurs ?
Pour 2) ne devrait-on pas utiliser sql_fetsel ?

A ce sujet, je ne sais pas ce qu’on utilise tous comme IDE mais ce genre de 
scories se voit souvent dans les inspections par défaut sans lancer un fixer.
Ca serait bien de les corriger quand on les identifie.

Voilà voilà pour la route.

++
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] problème de tag

2020-05-13 Par sujet Eric Lupinacci
Hello,

> Le 13 mai 2020 à 14:35, Cerdic  a écrit :
> 
> Calomnie !
> je vois ici
> https://plugins.spip.net/escal.html?compatible_spip=3.2 
> 
> la version 4.3.73
> 
> correspondant au dernier tag
> et au fichier 
> https://files.spip.org/spip-zone/spip-contrib-squelettes/escal-79c88-v4.3.73.zip
>  
> 
> 
> Pour répondre à ta question :
> - le debardeur passe tous les 1/4h pour mettre a jour les zips sur les 
> projets modifiés depuis la dernière fois, un zip est donc en principe 
> disponible très vite
> - le référencement sur plugins.spip.net peut prendre un peu plus de temps car 
> il ne remets pas à jour son xml aussi vite

Sur Plugins SPIP le CRON passe toutes les 6 heures.

++
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] html5up_spectral : comment faire pour changer le dépôt

2020-04-29 Par sujet Eric Lupinacci
Hello,



> Le 29 avr. 2020 à 10:06, chanka...@choc0.net a écrit :
> 
> hello,
> je me suis mis à jour, j'avais pas pu suivre les nouveautés au moment où 
> elles arrivaient, désolé... donc comme maintenant débardeur (j'ai pas encore 
> compris le nom, mais c'est pas très grave)

https://www.cnrtl.fr/definition/d%C3%A9barder 



> J'ai nettoyé le dépôt frama https://framagit.org/chankalan/html5up_spectral 
> 
> Si ça va comme ça, faudrait renommé le projet sur git.spip.net, mais j'ai pas 
> trouvé comment faire depuis mon accès...
> 

J’ai peut-être pas tout suivi mais:
- Pourquoi renommer le projet sur le Gitea ?
- Pourquoi conserver deux repos ?

++
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] Problème enregistrement clé SSH sur git.spip

2020-04-25 Par sujet Eric Lupinacci
Hello,

Je pense que c’est un peu normal qu’il n’accepte plus une clé qu’il considère 
avoir déjà été utilisée.
Plutôt que de passer des heures à se demander pourquoi ou si c’est un bug, je 
serais toi, j’en recréerais une et je l’associerais à ton compte gitea et basta.

++
Eric


> Le 25 avr. 2020 à 09:07, JLuc  a écrit :
> 
> Pour commiter sur git.spip depuis la ligne de commande
> pouvez vous me confirmer qu'il faut avoir enregistré une clé SSH dans les 
> paramètres perso de gitea ?
> 
> Actuellement, je n'ai aucune clé enregistrée et je n'arrive pas à commiter.
> Mais quand j'ajoute ma clé publique, gitea indique
> "Cette clef SSH a déjà été ajoutée au serveur."
> ce qui n'est pas faux puisque je l'avais ajoutée il y a longtemps,
> mais elle a été supprimée depuis et n'est plus enregistrée actuellement.
> 
> C'est un problème gitea et camille peut régler ça ?
> Il faut que je signale un bug sur le bugtracker de gitea ?
> Il faut que je crée une nouvelle clé pour contourner ce bug ?
> Ou il y a qqchose de préférable, qui m'échappe ?
> 
> 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] html5up_spectral : comment faire pour changer le dépôt

2020-04-23 Par sujet Eric Lupinacci
Je ne comprends pas du tout ta demande ???

> Le 23 avr. 2020 à 09:11, chanka...@choc0.net a écrit :
> 
> salut,
> queqlu'un aurait-il une bonne idée pour remplacer un dépôt git par un autre, 
> car celui sur git.spip.net est plutôt une catastrophe :
> https://framagit.org/chankalan/html5up_spectral 
> 
> alors qu'il en existe un tout joli ici :
> https://git.spip.net/spip-contrib-squelettes/html5up_spectral 
> 
> 
> En tentant de prendre la branche de l'un pour la mettre dans l'autre ça va 
> pas :
> fatal: refus de fusionner des historiques sans relation
> 
> Question naïve : est-ce qu'on peut simplement supprimer le dépôt et reprendre 
> le bon ?
> 
>  -- 
> 
> 
> chan
> ___
> 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] Colorscope et Salvatore

2020-04-21 Par sujet Eric Lupinacci
Yep,

> Le 21 avr. 2020 à 10:26, Cerdic  a écrit :
> 
> Je pense qu’il faut peser ça à l’aune de l’usage du plugin :
>  - si c’est un plugin assez utilisé je dirai oui
>  - si tu as concrètement des utilisateurs de langue étrangère, je dirai oui
>  - si il y a des demandes explicites, je dirai oui
> 
> Mais bon souvent, si c’est juste pour le paquet.xml, ajouter manuellement une 
> traduction [en] du slogan et descriptif ça se fait très bien, ça couvre 
> l’essentiel du besoin, et ça nécessite pas forcément de charger les 
> traducteurs avec ça…
> 


Oui, tout à fait.
Je pense qu’il faut traduire les slogan et la description qui sont les 
premières choses lues sur un plugin mais c’est exact qu’il n’y a souvent pas 
besoin de faire appel à TradLang pour ça surtout pour de l’anglais même si 
parfois les traductions sont un peu aléatoires ;-)

++
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] Colorscope et Salvatore

2020-04-21 Par sujet Eric Lupinacci
Hello,

> 
> +1 j'ai remarqué ça aussi depuis un moment, des plugins ajoutés aux trads en 
> mode "yolo" (v'là la misère pour traduire un truc sans doc) alors que tout ça 
> génère du travail pour les personnes qui traduisent.
> 
> Bref, rappelons que l'ajout d'un plugin aux trads n'est pas un geste "anodin" 
> et respections les trads :)
> 

+1 avec un mais.
Certains plugins peuvent ne pas avoir de fichier de langue spécifique autre que 
celui du paquet.
Et si on a créé un paquet-préfixe c’est pour traduire les noms, slogans et 
descriptions.

Donc faut quand même considérer que ces plugins sont aussi à traduire (j’ai pas 
regardé si c’est le cas de Colorscope, je réponds plus généralement).

++
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] rang_auteurs pas sur Gitea ?

2020-04-20 Par sujet Eric Lupinacci
Fait.

> Le 20 avr. 2020 à 15:40, Eric Lupinacci  a écrit :
> 
> Toujours pareil je pense, il ne doit pas être zippé donc il apparaissait pas 
> dans ma liste SPIP 3.
> Je vais te faire rapidement.
> 
>> Le 20 avr. 2020 à 15:25, nicod_  a écrit :
>> 
>> Dites, je ne vois pas le plugin rang_auteurs sur git.spip.net, c'est normal ?
>> 
>> On l'a bien sur la zone :
>> https://zone.spip.org/trac/spip-zone/browser/spip-zone/_plugins_/rang_auteurs
>> 
>> Mais rien sur Gitea :
>> https://git.spip.net/spip-contrib-extensions/?q=rang_auteurs==recentupdate
>> 
>> -- 
>> 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] rang_auteurs pas sur Gitea ?

2020-04-20 Par sujet Eric Lupinacci
Toujours pareil je pense, il ne doit pas être zippé donc il apparaissait pas 
dans ma liste SPIP 3.
Je vais te faire rapidement.

> Le 20 avr. 2020 à 15:25, nicod_  a écrit :
> 
> Dites, je ne vois pas le plugin rang_auteurs sur git.spip.net, c'est normal ?
> 
> On l'a bien sur la zone :
> https://zone.spip.org/trac/spip-zone/browser/spip-zone/_plugins_/rang_auteurs
> 
> Mais rien sur Gitea :
> https://git.spip.net/spip-contrib-extensions/?q=rang_auteurs==recentupdate
> 
> -- 
> 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] r124262 - in _plugins_/scssphp/trunk

2020-04-20 Par sujet Eric Lupinacci
Mais, justement, on ne doit pas privilégier $var === null d’après le PSR ou 
autre ?

++
Eric


> Le 20 avr. 2020 à 13:28, Cerdic  a écrit :
> 
> Hé oui, 
> https://github.com/scssphp/scssphp/pull/98/commits/5b898b75438164d8d3510dd3233ec4b92d3f58d5
>  
> 
> 
> (c’est la découverte du week end pour moi aussi, mais ça concerne pas trop le 
> code de SPIP car on utilise pas de namespaces)
> 
> --
> Cédric
> Le 20 avr. 2020 à 13:08 +0200, Maïeul Rouquette , a écrit :
>> Le 20/04/2020 à 12:49, spip-zone-com...@rezo.net a
>> écrit :
>>> Author: Cerdic
>>> Date: 2020-04-20 10:48:50 + (Mon, 20 Apr 2020)
>>> New Revision: 124262
>>> 
>>> Modified:
>>> _plugins_/scssphp/trunk/
>>> _plugins_/scssphp/trunk/lib/scssphp/src/Cache.php
>>> _plugins_/scssphp/trunk/lib/scssphp/src/Colors.php
>>> _plugins_/scssphp/trunk/lib/scssphp/src/Compiler.php
>>> _plugins_/scssphp/trunk/lib/scssphp/src/Formatter.php
>>> _plugins_/scssphp/trunk/lib/scssphp/src/Formatter/Nested.php
>>> _plugins_/scssphp/trunk/lib/scssphp/src/Node/Number.php
>>> _plugins_/scssphp/trunk/lib/scssphp/src/Parser.php
>>> _plugins_/scssphp/trunk/lib/scssphp/src/SourceMap/SourceMapGenerator.php
>>> _plugins_/scssphp/trunk/lib/scssphp/src/Version.php
>>> _plugins_/scssphp/trunk/paquet.xml
>>> Log:
>>> Mise a jour de la lib ScssPHP avec notamment de belles optimisations de 
>>> rapidite
>>> 
>>> 
>>> Details: https://zone.spip.org/trac/spip-zone/changeset/124262
>>> 
>> C'est normal tout ces antislashs ?
>> 
>> ___
>> 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] Pusher un tag

2020-04-17 Par sujet Eric Lupinacci
Yep,

> Le 17 avr. 2020 à 12:24, nicod_  a écrit :
> 
> Le 16/04/2020 à 23:08, Maïeul Rouquette a écrit :
>> Le 16/04/2020 à 22:40, Eric Lupinacci a écrit :
>>> Je pense que git push pousse par défaut uniquement ton master. Or la tu 
>>> veux pousser un tag. Donc il faut pousser tous les tags en faisant git push 
>>> --tags
>>> 
>>> 
>> oui, et je conseillerai de faire dans l'ordre
>> git push
>> git push --tags
>> et pas l'inverse (je crois que j'ai eu des problèmes de synchros svn dans 
>> l'autre sens)
> 
> Chez moi un simple git push envoie les tags aussi.
> 

Je crois qu’il est possible d’avoir une config générale pour ça.
Dans les GUI comme sourceTree tu as une case à cocher qui dit « envoyer tous 
les tags » en gros.
Mais par défaut, tu n’envoies que le master il me semble.

Tu peux regarder ton gitconfig pour voir stp ?

++
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] Pusher un tag

2020-04-16 Par sujet Eric Lupinacci
Je pense que git push pousse par défaut uniquement ton master. Or la tu
veux pousser un tag. Donc il faut pousser tous les tags en faisant git push
--tags

Le jeu. 16 avr. 2020 à 21:53, JLuc  a écrit :

> Bonjour,
>
> suite à un petit fix sur facteur, j'ai créé hier localement un tag :
> git tag -a v4.0.4 -m "Les sujets des mails peuvent désormais contenir des
> '?' même avec l'option 'convertir en iso'"
> que j'ai ensuite pushé
> git push
> mais aprés 24h+ il n'est pas arrivé sur git.spip :
> https://git.spip.net/spip-contrib-extensions/facteur#
>
> que faire ?
> 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] HTML5up hyperspace : deux prefix différents, donc deux plugins différents

2020-04-15 Par sujet Eric Lupinacci
Yep,

> Le 15 avr. 2020 à 13:51, Cerdic  a écrit :
> 
> Si les anciennes versions sont totalement incompatibles je suis pas sur qu’il 
> soit pertinent de renommer le prefixe, c’est un nid à emmerdes.
> 
> J’en veux pour preuve le cas contraire où la v2 de spipr-dist conserve le 
> même prefixe que la v1 et je le regrette déjà : SVP propose la mise à jour, 
> les gens cliquent et leur site est tout cassé, ils s’en sortent pas et ils 
> galèrent à revenir en arrière car rien n’est prévu pour ça...
> 

Oui mais là on est dans un cas différent.
Si tout est incompatible on peut dire que c’est bien deux plugins différents.
On devrait même les appeler différemment comme on a fait pour Sarka-SPIP 
(sarkaspip) et Sarka-SPIP Reloaded (sarkaspipr)

> Je pense que là il faut juste supprimer les tags de l’ancienne version.

Oui, c’est le plus simple.
Surtout que contrairement au cas que tu cites le renommage était plus « 
cosmétique ».


> Et faut être un peu souple avec les règles. 
> Oui c’est mieux en règle générale de pas changer de préfixe, et oui ça 
> complique des choses quand on le fait. 
> Mais c’est parfois bien pire de conserver un prefixe artificiellement alors 
> que le code n’a rien a voir, l’historique technique non plus, et que rien 
> n’est compatible…
> 

Moi je veux bien être souple et tout ce qu’on veut.
Mais je vous laisserez alors gérer la cohérence d’ensemble car c’est trop 
chronophage quand personne n’y met du sien et j’ai donné avec Contrib.


++
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] HTML5up hyperspace : deux prefix différents, donc deux plugins différents

2020-04-15 Par sujet Eric Lupinacci
Hello,

> Le 14 avr. 2020 à 23:57, Maïeul Rouquette  a écrit :
> 
> Jean-Marie, lorsque tu a préparé la version 3.0 du squelette Html5up 
> hyperspace v3, tu a changé le préfix.
> 
> Ce qui explique qu'on ait à la fois
> 
> https://plugins.spip.net/hyperspace
> 
> et
> 
> https://plugins.spip.net/html5up_hyperspace
> 

Ces changements de préfixe sont une plaie, je l’ai déjà dit et répété maintes 
fois.
Le préfixe c’est juste un id on se fout qu’il soit beau, lisible avec des 
underscores (pour qu’on ne sache plus où est le préfixe et le reste du nom de 
fonction ou de fichiers)...
Donc de grâce stop !

> Pour quel raison avoir changé de préfix ?
> - parce que ce sont deux squelettes vraiment différent ? si tel est le cas, 
> ils devraient avoir des noms différents, et pas juste des numero de version, 
> et on devrait créer des rubriques différentes sur contrib + tu devrais 
> expliquer dans l'article le pourquoi du changement
> - parceque tu voulais mettre de la cohérence au niveau des nomenclatures? 
> Mais dans ce cas, tu sais que
>   1. Tu casse la possibilité d'une recherche de mis à jour par SVP
>   2. Tu casse les éventuels appel de dépendance
> 

Et dans Contrib on va choisir une rubrique (on en fera pas deux) pour le même 
squelette.

> En fonction de la réponse à la question du pourquoi du changement de préfixe, 
> on pourra trouver la bonne solution :
> 
> - revenir pour la nouvelle version à l'ancien préfixe

Oui, s’il vous plait et me le dire afin que j’adapte la rubrique sur Contrib si 
elle existe.

++
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] Effet de bord du Débardeur

2020-04-15 Par sujet Eric Lupinacci
Yo,


> Le 14 avr. 2020 à 18:16, Cerdic  a écrit :
> 
> Hello,
> j’ai ajouté une option exclude pour exclure spip,ecrire,prive du depot core, 
> ça doit résoudre le problème de SPIP qui était remonté dans SVP (c’était 
> ecrire en fait)
> 

Impec.


> Pour le reste oui on peut faire une liste de tags a exclure par projet.
> Ou peut-etre simplement supprimer ces vieux tags ?
> 

On peut dans un premier temps supprimer ces vieux tags pour se débarrasser de 
ce problème immédiat, mais je pense qu’on risque in fine d’avoir le besoin 
d’exclusions.
Je serais donc favorable à rajouter cette options d’exclusion de tags après 
avoir supprimé les tags en question.

++
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] Référentiel des plugins

2020-04-13 Par sujet Eric Lupinacci
Hello,


Sur la route de la Refonte de Contrib, le moment est venu de s’attaquer aux 
pages elles-mêmes et d’intégrer Plugins SPIP.
Je rappelle que ceux qui souhaitent y participer peuvent s’inscrire sur le 
Framablog et fournir leur idée, maquette et plus si affinité.
Maintenant, comme disait un certain « bip » : shit in shit out !

J’ai fait un rapide tour d’horizon des plugins / paquets inclus dans le 
référentiel et il y a encore beaucoup de plugins sans slogan, sans description 
et sans documentation.
Et franchement c’est chiant et très démotivant pour ceux qui s’échinent à 
améliorer tous les jours l’écosystème SPIP. Il y a 120 plugins sans slogan et 
au moins autant de paquets sans descriptions.

Quelques règles que l’on pourrait tous adopter :
- si un plugin a un nom composé d'un acronyme ou d’un terme générique ou 
obscur, il est essentiel de l’affubler d’un slogan. Cela permet de rapidement 
capter de quoi on parle. Personnellement j’en met toujours et c’est ce que je 
conseille.
- dans tous les cas, qu’il existe un slogan ou pas, il faut écrire une petite 
description du plugin qui a l’avantage de pouvoir être traduite.
- enfin, slogan et description ne remplacerons jamais une documentation : un 
article sur Contrib est le bienvenu voire un readme dans le plugin avec le lien 
de doc dans le paquet.xml.

Je ne sais pas si c’est possible mais un plugin qui n’a ni slogan, ni 
description et ni documentation ne devrait pas être référencé dans l’annuaire 
des plugins de SPIP.

Donc si vous pouvez y faire attention à l’avenir voire corriger l’existant, ce 
serait vraiment cool.


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] Effet de bord du Débardeur

2020-04-13 Par sujet Eric Lupinacci
Hello,

On a maintenant un beau débardeur qui nous concocte des zips à gogo.
C’est excellent car on a un écosystème Git qui fonctionne complètement.

Néanmoins, on a quelques petits effets de bord :
- les zips de spip sont inclus dans la base des plugins. C’est pas top.
- certains plugins du Core remontent à la surface avec un ancien préfixe : 
c’est le cas de Pétitions dont le tag 1.0 remonte avec un préfixe « pétition » 
et le plugin Sites dont le tag 1.0 remonte avec un préfixe « syndic ». Inutile 
de dire que vu la vétusté du tag, la compatibilité n’est pas définie...

En fait, la logique de calcul des zips à partir de x.y est un peu violente car 
souvent on a besoin que du dernier x mais pas toujours ce qui fait que la 
logique des zips basée sur x uniquement n’est pas suffisante.
Donc je ne sais pas trop comment régler ce souci.

Ne pourrait-on pas imaginer un archivelist un peu inversé ou on pourrait 
exclure des tags ?

++
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] Contrib et fichiers des plugins

2020-04-13 Par sujet Eric Lupinacci
Hello,

Le 12 avril 2020 à 21:37:16, Maïeul (mai...@maieul.net) a écrit:

Le 12/04/2020 à 20:33, Maïeul Rouquette a écrit : 
> Le 12/04/2020 à 20:19, RastaPopoulos a écrit : 
>> Le 12/04/2020 à 19:45, Bruno Bergot a écrit : 
>>> À froid je n'ai pas d'idée concrète pour améliorer ça, mais peut-être 
>>> faut il chercher directement dans les paquets en fonction de l'url de 
>>> doc (qui est celle de l'article en cours), sauf que très souvent les 
>>> paquets référencent l'adresse en mode lien court, etc. 
>> 
>> Tout à fait d'accord avec ce point car le lien on l'a, chaque 
>> paquet.xml référence bien l'article le plus pertinent pour sa version 
>> précise, donc on doit être capable d'afficher les infos de cette 
>> branche en question, et non du plugin général. 
>> 
> je ferais un quickfix ce soir ou demain 
bon c'est fait 

et demain Eric affichera uniquement les version X majeures, en attendant 
la refonte totale. 

evidememt comme le dit eric, et comme je le met dans mon message de 
commit, je suis pas convaincu que la manière dont on gère la doc par 
paquet.xml soit la bonne solution. 
On a eu la discussion avec Maieul déjà.

Je ne trouve pas que ne faire apparaitre que le zip correspondant au lien de 
doc soit une bonne solution:

1- ça n’est pas « l’esprit » du bloc de droite qui décrit les informations de 
base du plugin et pas du paquet lié parfois à l’article affiché.

2- pour les articles du plugin qui ne sont pas des liens de doc, on a aucun zip 
alors que les autres informations sur le plugin sont bien présentes.

Donc je trouve que ce n’est pas cohérent du tout et je proposerais même avant 
la refonte globale de visualiser les zips du plugin  pour tous les articles du 
plugin sachant que j’ai modifié l’affichage pour ne voir qu’un seul zip par X.

A la limite, on pourrait « enrichir » l’affichage du zip lié au lien de doc sur 
les articles concernés pour bien pointer la correspondance.

J’attends vos retours pour commiter la modification pour les X.

++

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] Contrib et fichiers des plugins

2020-04-12 Par sujet Eric Lupinacci
Yo,

Le 12 avril 2020 à 20:19:52, RastaPopoulos (rastapopou...@spip.org) a écrit:

Le 12/04/2020 à 19:45, Bruno Bergot a écrit :  
> À froid je n'ai pas d'idée concrète pour améliorer ça, mais peut-être faut il 
> chercher directement dans les paquets en fonction de l'url de doc (qui est 
> celle de l'article en cours), sauf que très souvent les paquets référencent 
> l'adresse en mode lien court, etc.  

Tout à fait d'accord avec ce point car le lien on l'a, chaque paquet.xml 
référence bien l'article le plus pertinent pour sa version précise, donc on 
doit être capable d'afficher les infos de cette branche en question, et non du 
plugin général.  


C’est déjà ce que je fais dans le privé si j’ai bien suivi.
Par contre, je ne pense pas que le lien de doc soit pertinent dans le 
paquet.xml car il n’est pas mis à jour systématiquement.
Dans la page privée d’un plugin j’affiche les informations comme le slogan ou 
le descriptif en prenant le paquet le plus à jour.

En tout cas, aujourd’hui sur Contrib on a toutes les informations des plugins 
et on peut faire les mêmes choses que sur Plugins SPIP en mieux car on a les 
rubriques-plugin au même endroit.

++
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] Recherche dans SVP...

2020-04-10 Par sujet Eric Lupinacci
Oui,

Le 10 avril 2020 à 15:06:20, nicod_ (ni...@lerebooteux.fr) a écrit:
J'ai compris, c'est à cause de Fulltext.  

Je viens de le désactiver sur Plugins SPIP.

++
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] Recherche dans SVP...

2020-04-10 Par sujet Eric Lupinacci
Oui, essaye sur Plugins SPIP qui est en 3.2 pour voir si tu as le même résultat 
stp.

Le 10 avril 2020 à 15:01:23, Matthieu Marcillaud (marci...@rezo.net) a écrit:

Le 09/04/2020 à 21:53, nicod_ a écrit :  
> Yop,  
>  
> je suis perplexe : je cherchais à installer photoswipe par SVP.  
>  
> Je cherche "photo", je trouve "Outdoor" et "Metadonnées photo"  
> Je cherche "swipe", je ne trouve rien.  
> Avec "photoswipe", il apparait bien.  
>  
> C'est une recherche par mot exact ?  

Sqlite ? Mysql ?  

Je viens de tester en 3.3-dev à jour sur mysql, et mise à part devoir  
supprimer le dépot principal et le remettre pour avoir les logos des  
plugins, rien de particulier : la recherche fonctionne.  

MM.  
___  
liste: https://listes.rezo.net/mailman/listinfo/spip-dev  
doc: https://www.spip.net/  
dev: https://core.spip.net/  
irc://irc.freenode.net/spip  
++
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] Recherche dans SVP...

2020-04-10 Par sujet Eric Lupinacci
Ben justement, Plugins SPIP est en SPIP 3.2.7

Le 10 avril 2020 à 12:01:54, JLuc (j...@no-log.org) a écrit:

Le 10/04/2020 à 09:45, Eric Lupinacci a écrit :
> Non je ne pense pas que ce soit spécifique.
Suspense... Qu'est ce qui te fait penser ça ?

> Par contre faudrait comparer les versions de SPIP.
Demo.spip est en SPIP 3.3.0-dev SVN [24556]
Sur un de mes sites en SPIP 3.3.0-dev [24422] c'est pareil, la recherche de
plugins marche comme il faut.

JL

>> Le 10 avr. 2020 à 09:32, JLuc  a écrit :
>>
>> Le 09/04/2020 à 21:53, nicod_ a écrit :
>>> je suis perplexe : je cherchais à installer photoswipe par SVP.
>>> Je cherche "photo", je trouve "Outdoor" et "Metadonnées photo"
>>> Je cherche "swipe", je ne trouve rien.
>>> Avec "photoswipe", il apparait bien.
>>> C'est une recherche par mot exact ?
>>
>> Sur demo.spip.net, ça se passe mieux :
>> "photo" renvoie 5 plugins, dont photoswipe.
>> "swipe" renvoie 2 plugins : photoswipe et swiper.
>>
>> Ça semble un problème spécifique à ton site ?
>>
>>
>> JLuc
>>
>> ___
>> 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] Recherche dans SVP...

2020-04-10 Par sujet Eric Lupinacci
Non je ne pense pas que ce soit spécifique.
Par contre faudrait comparer les versions de SPIP.

> Le 10 avr. 2020 à 09:32, JLuc  a écrit :
> 
> Le 09/04/2020 à 21:53, nicod_ a écrit :
>> je suis perplexe : je cherchais à installer photoswipe par SVP.
>> Je cherche "photo", je trouve "Outdoor" et "Metadonnées photo"
>> Je cherche "swipe", je ne trouve rien.
>> Avec "photoswipe", il apparait bien.
>> C'est une recherche par mot exact ?
> 
> Sur demo.spip.net, ça se passe mieux :
> "photo" renvoie 5 plugins, dont photoswipe.
> "swipe" renvoie 2 plugins : photoswipe et swiper.
> 
> Ça semble un problème spécifique à ton site ?
> 
> 
> JLuc
> 
> ___
> 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] Recherche dans SVP...

2020-04-10 Par sujet Eric Lupinacci
Hello,



Le jeu. 9 avr. 2020 à 21:54, nicod_ mailto:ni...@lerebooteux.fr>> a écrit :
Yop,

je suis perplexe : je cherchais à installer photoswipe par SVP.

Je cherche "photo", je trouve "Outdoor" et "Metadonnées photo"
Je cherche "swipe", je ne trouve rien.
Avec "photoswipe", il apparait bien.

C'est une recherche par mot exact ?

Non je ne crois pas.
Peux-tu essayer la même chose sur Plugins SPIP ?
J'ai été surpris ces derniers jours justement d'avoir le même problème en 
essayant de retrouver un préfixe non entier.

Je me demande si il n'y a pas eu une régression quelque part car j'ai aussi 
l'impression que ça a eu marché (impression ou réalité ?).

++
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] moicubitus et les zips et le wiki et ...

2020-04-09 Par sujet Eric Lupinacci
Le jeu. 9 avr. 2020 à 16:05, Maïeul Rouquette  a écrit :

> le plus important serait d'avoir rapidement un groupe qui se penche szr
> les maquettes filaires du nouvau site contrib/plugins
>

Tcharlss s'occupe de monter un groupe pour ça (enfin une action dans le
groupe Contrib du framavox).

++
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] moicubitus et les zips et le wiki et ...

2020-04-09 Par sujet Eric Lupinacci
Je ne suis pas sur qu'il faille se polariser sur ce sujet.
La refonte de Contrib qui va se poursuivre par l'espace public et
l'intégration de Plugins SPIP doit régler ce sujet :
1- arrêter la synchro avec Plugins SPIP
2- ne plus attacher des zips manuellement à un article.

Tout se fera par la liste des paquets disponibles pour un plugin qui est
connue vie les tables de SVP.
On pourrait d'ailleurs patcher ça rapidement mais je pense qu'on peut
attendre que le groupe de travail sur l'espace public rende sa copie.

++
Eric


Le jeu. 9 avr. 2020 à 13:52, YannX SPIP(hot)  a
écrit :

> Le 09/04/2020 à 12:13, JLuc a écrit :
> > Petit problème sur l'article « La mutualisation facile : modifications
> > manuelles »
> > https://contrib.spip.net/ecrire/?exec=article_article=2192
> > où un utilisateur moicubitus ajoute depuis peu des zips 1.4.5 et 0.10.4
> > sans retirer leur version précédente.
> >
> > PS :
> > Ce 1er article est sur le wiki, c'est une "Documentation provisoire du
> > Plugin « mutualisation »
> > décrit [finalement] dans la Ferme à SPIP"
> > Ce 2eme article "https://contrib.spip.net/Ferme-a-SPIP; propose lui
> > aussi ces zips,
> > mais en un seul exemplaire pas mis à jour récemment.
> >
> > Il est certainement possible de virer ponctiuellement les différents
> > zips de la version wiki
> > mais peut être y a t il quand même un problème plus général à régler...
>
> Meme constat de versions multiples sur
> https://contrib.spip.net/Spout_SPIPCSV-export-CSV-ameliore-pour-SPIP
>
> Et une situation encore plus tordue pour
>
> https://contrib.spip.net/Plugin-Colorscope-Pour-visualiser-les-codes-couleur
>
> une version sur la zone [2.1;3.1] et j'ai joint une seconde version 3.2+
> (compatible 2.1.3.1) comment faire
> (mais là je plaide coupable : je n'ai reçu d'accès GIT que ce matin !
> (et comme je suis sur de n'avoir pas encore bien compris les (nombreuses
> / merci) docs d'Eric,
> (et je ne trouve plus de bac a sable )
> >
> > 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
> > .
>
>
> --
> YannX
> http://www.spippourlesnuls.fr
>
> ___
> 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] r124090 - in _plugins_/google-viewer

2020-04-08 Par sujet Eric Lupinacci
Yop Joseph,

Le plugin est sur Git.
Donc pas besoin de trunk svn.
Il a été migré sans.

Faut repartir du master git maintenant c'est bien mieux.

++
Eric


Le mer. 8 avr. 2020 à 12:10,  a écrit :

> Author: Joseph Larmarange
> Date: 2020-04-08 10:08:31 + (Wed, 08 Apr 2020)
> New Revision: 124090
>
> Added:
>_plugins_/google-viewer/images/
>_plugins_/google-viewer/lang/
>_plugins_/google-viewer/lang/paquet-gviewer_fr.php
>_plugins_/google-viewer/modeles/
>_plugins_/google-viewer/modeles/emb_google.html
>_plugins_/google-viewer/modeles/media_application_ai.html
>_plugins_/google-viewer/modeles/media_application_doc.html
>_plugins_/google-viewer/modeles/media_application_docx.html
>_plugins_/google-viewer/modeles/media_application_eps.html
>_plugins_/google-viewer/modeles/media_application_pdf.html
>_plugins_/google-viewer/modeles/media_application_ppt.html
>_plugins_/google-viewer/modeles/media_application_pptx.html
>_plugins_/google-viewer/modeles/media_application_ps.html
>_plugins_/google-viewer/modeles/media_application_ttf.html
>_plugins_/google-viewer/modeles/media_application_xls.html
>_plugins_/google-viewer/modeles/media_application_xlsx.html
>_plugins_/google-viewer/modeles/media_google.html
>_plugins_/google-viewer/modeles/media_image_psd.html
>_plugins_/google-viewer/paquet.xml
>_plugins_/google-viewer/plugin.xml
> Removed:
>_plugins_/google-viewer/trunk/
> Log:
> Revert "creation repertoire trunk"
>
> This reverts commit 11800da563466a5e8a23e0e1b583d7e8bc5de4c5.
>
>
> Details: https://zone.spip.org/trac/spip-zone/changeset/124090
>
> ___
> 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] r122733 - _squelettes_/escal/trunk

2020-04-08 Par sujet Eric Lupinacci
Hello,


Le mer. 8 avr. 2020 à 09:31, Cerdic  a écrit :

> Il y a aussi SourceTree publié par Atlasian (Bitbucket) qui est gratuit,
> disponible aussi bien sur windows que mac, et qui marche très bien
> https://www.sourcetreeapp.com/
>
> Je l’avais testé il y a longtemps et retenu comme une bonne solution, et
> je crois que Eric utilise ça régulièrement aussi maintenant
>

Oui, il est pas mal du tout surtout sur Mac.
Il y a Tower aussi mais il n'est pas gratuit.


>
> Peut-être ça vaudrait le coup de faire une page sur le wiki qui pointe
> vers des ressources utiles
> (cours gratuit d’utilisation à git, outils, tuto, cheat sheet…) et réponds
> aux questions principales ?
>
> Et aussi du coup transférer le wiki de spip
> https://core.spip.net/projects/spip/wiki
> vers
> https://git.spip.net/spip/spip
> car vu le nombre de page ça peut se faire à la main et ce sera l’occasion
> de mettre à jour les contenus sans doute ?
>

J'ai l'impression que tous les articles du Guide Git sur la taverne ne sont
pas connus.
Il faudrait les mettre ailleurs où ils seraient plus accessibles
naturellement.
J'ai prévu d'ailleurs de faire un article d'installation de SourceTree pour
compléter ceux actuellement disponibles sur la ligne de commande.

++
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] Squelettes et thèmes sur contrib

2020-04-07 Par sujet Eric Lupinacci
Re,

Je ne suis pas super chaud de faire juste une refonte pour les squelettes
et les thèmes.
Il y 4 actions sur le framavox qui concerne les pages publiques et ça
serait bien de faire une refonte qui tienne compte de l'ensemble des
problématiques.

++
Eric


Le mar. 7 avr. 2020 à 09:29, Jean Marie Grall <
jeanmarie.lis...@cousumain.info> a écrit :

> Salut,
>
> alors déjà, + 1000 pour le lancement de ce chantier, merci pour la
> relance !
>
> Et d'accord avec le constat général et les propositions. J'aurais juste
> 2 détails :
>
> 1. Il faudrait effectivement les mettre en avant dès l'accueil de
> contrib (Niveau -1 donc). Mais plutôt que de ressortir les derniers
> créés (ça montre la nouveauté mais pas forcément l'intérêt pour le
> visiteur), j'aurais plutôt vu quelque chose "d’éditorialisé" : soit les
> mieux notés (plugin Notation), soit les plus utilisés. Et dans l'idéal,
> que ça change régulièrement pour voir que ça bouge. L'accueil sera
> l'endroit le plus visible pour ces squelettes, il me parait risqué de
> prendre les derniers créés sans "filtres".
>
> 2. Le filtrage sur la liste de tous les squelettes (Niveau 1) pourrait
> se faire sur des mots clefs en plus des catégories / famille de
> squelettes (= les sous-rubriques) pour plus de possibilités.
>
> On avait commencé un pad avec des exemples chez d'autres (j'ai ajouté
> les tiens) et des pistes de mise en avant et filtrage :
> https://annuel.framapad.org/p/mise-en-valeur-des-themes-et-squelettes
>
> Dispo aussi pour échanger sur ce dossier.
>
>  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
___
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] Squelettes et thèmes sur contrib

2020-04-07 Par sujet Eric Lupinacci
Hello,

Comme j'ai raté le début du fil je vais répondre d'abord au premier mail de
Charles.
Ca me parait important de faire un état des lieux de la refonte de Contrib
qui comme l'a dit Rasta s'est un peu arrêtée depuis que je suis passé sur
la migration Git.
Néanmoins, il y a pas mal de choses de faites sauf la refonte ergo mais qui
ne doit pas juste se limiter aux squelettes et aux thèmes.



Le lun. 6 avr. 2020 à 23:34, Charles Razack  a
écrit :

> Anecdote du soir : en voulant dépanner un⋅e primo arrivant⋅e qui cherchait
> des squelettes et des thèmes, j'ai voulu l'aiguiller sur la bonne page dans
> contrib et là je me suis retrouvé pris au dépourvu, depuis la page
> d'accueil je n'ai pas retrouvé où ils étaient non plus. Un petite recherche
> et j'ai fini par voir que c'était dans l'entrée de menu « interface
> publique ».
>
> Attention je ne viens pas remettre en question l'énorme travail de
> classement fait par eric :)
> Cette discussion ne porte pas spécifiquement sur les catégories et le
> classement des articles.
>
Aujourd'hui l'état de la refonte de Contrib est le suivant :
- les catégories ont été revues sur deux niveaux
- elles sont affectées à chaque plugin
- cette *affectation ne se fait plus dans le paquet.xml mais via une page
de Contrib ce qui permet de modifier simplement lesdites affectations*.
Contrib est la référence de la catégorisation
- le rubricage colle à l'organisation des catégories
- aucune refonte des pages n'a eu lieu, ce qui fait que l'actuel menu des
rubriques est devenu le menu des catégories (qui à mon avis est surement
peu utilisé depuis des années).
- l'ensemble des plugins du référentiel (ceux qui sont zippés) est installé
sur Contrib comme sur Plugins SPIP dans le but de *remplacer à terme les
pages de Plugins SPIP*.

En outre, j'ai développé un plugin spécifique permettant de créer et de
lancer des contrôles pour s'assurer que les mécanismes qui lient les
catégories et les rubriques sont bien respectés et de pouvoir dès lors
faire les corrections nécessaires.
Et il existe aussi un nouveau plugin d'archivage pour traiter la
problématique de l'archivage des contributions.

Si techniquement ces articles relèvent effectivement de l'« interface
> publique », par contre sur le site public personne ne va penser à aller
> chercher ces contenus là-dedans.
> Ceux qui découvrent SPIP cherchent tout simplement des « thèmes » ou des «
> templates » – ou des squelettes s'ils ont commencé à se documenter sur
> spip.net.
> C'est même valable pour les ancien⋅nes aussi :)
>
Oui, l'organisation interne a un but mais pas celui de fournir la structure
ergonomique du public.
Il existait d'ailleurs un menu de navigation général dans une version
précédente ou l'on voyait il me semble Plugins, Squelettes et Thèmes (à
vérifier).
On est donc tout à fait d'accord qu'il faille renouer avec ce type de liens.

Mais attention, ce n'est pas suffisant.
Il faut absolument faire ce travail conjointement avec l'intégration des
pages de Plugins SPIP sinon on va faire n fois le boulot.


> Ensuite une fois arrivé dans ce secteur, on a l'arborescence classique de
> rubriques et d'articles, avec parfois plusieurs niveaux de sous-rubriques :
> il faut aller tout au bout de la navigation jusqu'à l'article final pour
> enfin avoir éventuellement une capture d'écran et voir à quoi ressemble tel
> squelette ou tel thème. Ça doit en décourager pas mal.
>
Oui alors là c'est le serpent de mer du site de thèmes...
Je pense que tu as qu'il faut le faire sur Contrib mais en cohérence avec
l'intégration de Plugins SPIP.


> Je pense qu'au-delà de donner accès à la documentation, cette partie de
> contrib a un rôle de vitrine et devrait se rapprocher de l'herbier.
> Bref il s'agirait de mettre les thèmes et squelettes en avant et permettre
> de les retrouver de façon intuitive. Pas exactement un mini site dans le
> site, mais quelque chose entre les 2.
>
> Quelques premières pistes de réflexion :
>
> *1) Navigation*
>
> La navigation sur le site public n'a pas a refléter systématiquement le
> rangement dans le privé. C'est une bonne règle générale, mais on peut y
> déroger selon les cas.
> Il pourrait par exemple y avoir une limite à 2 niveaux de profondeur :
>
>- Niveau 0 : en page d'accueil, 2 entrées « Thèmes » et « Squelettes »
>à la racine dans le menu de navigation (à la place de « Interface publique
>» donc).
>- Niveau 1 : ces liens mènent directement à une liste filtrable de
>tous les thèmes ou squelettes.
>- Niveau 2 : enfin en cliquant sur un thème/squelette on arrive à
>l'article de documentation.
>
> Je ne crois pas qu'il faille se polariser sur ce menu des catégories.
Et même je ne pense pas qu'il faille le modifier.
Il faut proposer une navigation alternative qui permet d'aller directement
sur une vision spéciale du référentiel de thèmes et de squelettes.
Et ne pas oublier qu'un theme ou un squelette étant un plugin il aura aussi
sa page "plugin" mais en plus une page 

Re: [spip-dev] Fin de migration vers Gitea

2020-04-05 Par sujet Eric Lupinacci
Voilà fait !
Deux de plus.
Il faut maintenant créer les tags git pour que le débardeur s'occupe de
leur zip.

++
Eric


Le dim. 5 avr. 2020 à 10:53, Eric Lupinacci  a écrit :

> Yop,
>
> Le dim. 5 avr. 2020 à 10:42, Cerdic  a écrit :
>
>> Faut surtout pas bouger les dossiers sur le svn !
>>
>
> Sauf quand on ne peut pas faire autrement.
> Hier je l'ai fait pour un plugin tordu, ça m'a permis de faire le
> transfert et ensuite le mergehistory pour récupérer les commits.
> Par contre, oui tu as raison, comme je l'ai dit, le transfert de plugins à
> squelettes est lui rédhibitoire même pour le mergehistory.
>
>
>
>>
>> Quand tu importes un projet tu désignes d’un côté le chemin sur le svn et
>> de l’autre côté l’organisation, donc oui tu peux importer directement dans
>> spip-contrib-squelettes (et au pire on aurait importé dans extensions et
>> changé d’organisation ensuite côté git)
>>
>
> Oui je m'en doutais mais je préférais une confirmation. Peut etre que le
> seul effet de bord sera dans le cas où on crée une branches sous git et
> sa synchro avec svn mais je dirais qu'avec le débardeur ce problème n'en
> est plus un.
> Je vais envoyer ça et on va voir le résultat.
> C'est le problème de ma stratégie SPIP 3 basée sur les zips : si non zippé
> alors non 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] Fin de migration vers Gitea

2020-04-05 Par sujet Eric Lupinacci
Yop,

Le dim. 5 avr. 2020 à 10:42, Cerdic  a écrit :

> Faut surtout pas bouger les dossiers sur le svn !
>

Sauf quand on ne peut pas faire autrement.
Hier je l'ai fait pour un plugin tordu, ça m'a permis de faire le transfert
et ensuite le mergehistory pour récupérer les commits.
Par contre, oui tu as raison, comme je l'ai dit, le transfert de plugins à
squelettes est lui rédhibitoire même pour le mergehistory.



>
> Quand tu importes un projet tu désignes d’un côté le chemin sur le svn et
> de l’autre côté l’organisation, donc oui tu peux importer directement dans
> spip-contrib-squelettes (et au pire on aurait importé dans extensions et
> changé d’organisation ensuite côté git)
>

Oui je m'en doutais mais je préférais une confirmation. Peut etre que le
seul effet de bord sera dans le cas où on crée une branches sous git et
sa synchro avec svn mais je dirais qu'avec le débardeur ce problème n'en
est plus un.
Je vais envoyer ça et on va voir le résultat.
C'est le problème de ma stratégie SPIP 3 basée sur les zips : si non zippé
alors non 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] Fin de migration vers Gitea

2020-04-05 Par sujet Eric Lupinacci
Hello,

Le dim. 5 avr. 2020 à 08:28, Lepaisant Dominique <
dominique.lepais...@ac-normandie.fr> a écrit :

> Est-il possible de migrer aussi spipr-dane-noisettes et spipr-dane-config,
> tous les deux placés dans _plugins_ mais qui auraient sans doute plus leur
> place dans spip-contrib-squelettes ?
> je devais les ajouter à archivelist.txt mais il est sans doute trop tard...
>
>
> https://zone.spip.net/trac/spip-zone/browser/spip-zone/_plugins_/spipr-dane-noisettes
>
> https://zone.spip.net/trac/spip-zone/browser/spip-zone/_plugins_/spipr-dane-config
>
>
Ahhh gr.
On a vraiment tout sur cette zone !
Je vais voir avec Camille si ça ne pose pas de problème de passer de
_plugin_ à spip-contrib-squelettes.
Si c'est bon je le fais.
Si ça pose un souci on peut aussi le faire et alors il faudra le passer
d'abord dans _squelettes_ mais ça veut dire qu'on perdra tout l'historique
car c'est le seul cas où on ne sait pas 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] Fin de migration vers Gitea

2020-04-04 Par sujet Eric Lupinacci
Hello,

Je décrète à 20h30 la migration systématique de la Zone vers Gitea
terminée... ou presque !
Plus précisément, presque tous les plugins, squelettes et thèmes
compatibles avec SPIP 3.2, 3.1 et 3.0 ont été transférés sous git. Il ne
reste que quelques uns qui sont soit obsolètes soit difficilement
transférables sans perte de commits.
La liste de ces plugins est fournie plus loin.

Pour les plugins non transférés car compatibles SPIP 2 ou une autre raison,
il sera toujours possible de le faire à tout moment, mais cela se fera sur
demande.
La phase 2 de la fusée Git peut maintenant débuter avec le Débardeur :
créer les tags nécessaires sous git et supprimer les zips correspondants
dans smart-paquets.

Ceci étant les statistiques de transfert sont donc :

ZONE GITEA ORGA GITEA Commentaires
_plugins_ 1423 734 spip-contrib-extensions moins de 20 plugins SPIP 3 non
migrés.
_squelettes_ 180 148 spip-contrib-squelettes 6 squelettes SPIP 3.0 non
migrés
_themes_ 154 154 spip-contrib-themes Tous les thèmes existants migrés
_core_ (plugins-dist) 30 30 spip Tous les plugins-dist y compris dev et
thèmes
_core_ (securite) 1 1 spip-contrib-outils L'écran de sécurité
_outils_ 22 6 spip-contrib-outils En prenant en compte que les dossiers pas
les fichiers seuls
le reste, à voir plus tard
Total 1810 1073

Les squelettes SPIP 3 non transférés sont :

   - IENSP : Je ne sais pas ce que c'est. Peut être un ensemble de
   squelettes ?
   - galaxie_melusine : 5 dossiers avec des plugins et des trunk/ et
   branches/
   - *mediaspip : 4 dossiers avec des trunk/ et branches/ chacun. c'est
   quoi % galaxie ?*
   - *spip.zone.trac : 3 fichiers css surement pour personnaliser le trac
   => dans galaxie ?*
   - *trac.rezo.net  : un fichier sommaire.html mais
   qui % spip.zone.trac ? => galaxie ?*
   - tutolivre : 9 commits sur 13 avant le trunk/ => quid ?

Les plugins SPIP 3.2 non transférés :

   - apropos : un dossier alpha/xxx qui n'est pas dans les branches
   - eva_freemind : deux sous dossiers de branches sans trunk
   - *maparaan : c'est un squelette ici ou le thème ? Il ne faudrait pas
   juste virer ce dossier ?*
   - rspip_code_mail : deux branches sans trunk

Les plugins SPIP 3.1 non transférés :

   - articles_vers_rubriques : inutile à priori
   - dump_xml : inutile a priori
   - eudock : dépassé à priori
   - forms : remplacé
   - jquery_corner : a priori inutile aujourd'hiu
   - openinviter : plus maintenu
   - orientation : archive sur contrib
   - pages_mobiles : inutile avec le responsive non?
   - panoramas : plus maintenu
   - plan : intégré dans le core
   - portfolio_imageflow : ne semble plus maintenu
   - transaction : plus maintenu et remplacé
   - tweetnspip : semble plus maintenu
   - updateheaders : semble inutile
   - variantes_articles : inutile avec composition

Et merci à Camille et Cédric pour les heures passées à réaliser les
scripts, les tester et maintenir le serveur Gitea.


++
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] Tous en débardeur !

2020-04-03 Par sujet Eric Lupinacci
Non mais en l'occurrence c'est pas pour demain.
Donc pour l'instant il faut bien le maintenir et de toute façon Contrib ne
fera que reproduire ce qu'il y a sur Plugins SPIP.

++
Eric


Le ven. 3 avr. 2020 à 17:26, teamspipfact...@gmail.com <
teamspipfact...@gmail.com> a écrit :

>
>
> Le 03/04/2020 à 15:55, Maïeul Rouquette a écrit :
>
> Le 31/03/2020 à 21:05, Eric Lupinacci a écrit :
>
> Hello,
>
> Avec Cédric nous avons testé hier et aujourd'hui un nouvel outil destiné à
> remplacer smart-paquets et surtout à faciliter la transition douce vers les
> zips de git (moi j'ai juste testé hein).
> Cet outil est nommé débardeur, je vous laisse consulter wikipedia pour
> l'explication.
>
> L'intérêt est que le débardeur est facile d'installation et de
> manipulation et permet de reconstituer les zips, les logos et les
> archives.xml à l'identique de smart-paquets.
> Il est même capable d'agréger dans un même dépôt SVP des zips Zone et des
> zips Gitea.
> De fait, il est possible de basculer petit à petit (mais pas trop quand
> même) des zips SP (qui consomment de la charge serveur) vers les zips Gitea
> qui existent une fois pour toute.
>
> Le débardeur se base sur les tags uniquement !
> Donc pas de tag Git, pas de débardeur.
> Pas de débardeur... pas de débardeur.
>
> Pour basculer les zips d'un plugins zone vers gitea, il faut que le plugin
> soit transféré sur Gitea (c'est aujourd'hui le cas de 90% des plugins
> compatibles SPIP 3.0 à 3.2) et qu'il existe des tags correspondants aux
> zips à fournir. On peut alors supprimer les lignes correspondantes du
> archivelist, le débardeur lit tous les repos des organisations Gitea (et
> même plus si besoin, le détail est dans le readme).
> Simple et de bon goût.
>
> Néanmoins, concernant les tags nous avons du limiter les tags au plus
> récent de chaque branche pour éviter de récupérer par exemple les 600 tags
> des deux plugins Formidable et Saisies. Cet exemple est donc à éviter car
> même en faisant cela il y a déjà 90 tags pour formidable car 90 branches
> x.y ! (faudrait peut être songer à virer des tags si c'est possibles).
> Cela nous a permis de diminuer la taille du archives.xml principal qui
> était passé de 3,5M à 10,5M. On est actuellement à 4,5M (pour info celui du
> core était passé à 33M).
> Pour y arriver on a supprimé aussi des informations inutilisées ou
> redondantes dans le xml comme la liste des autorisations et les traductions
> redondantes des zips d'un même plugin.
>
> Cela aura quand même des effet sur SVP/Plugins SPIP mais qui sont minimes:
> - les traductions ne seront visibles que pour le zip le plus récent
> (Plugins SPIP). C'était d'ailleurs inutile de les répéter à chaque fois, il
> faudra proposer un nouvel affichage des pages plugin.
> - dans l'admin des plugins pour les branches 3.0 et 3.1 on pourra avoir
> une absence des logos. Cela a été patché pour 3.2 et 3.3 uniquement.
>
> Tout nous parait donc prêt pour commencer à basculer.
> Alors on bascule ?
>
> A vous lire
>
> ++
> Eric
>
> Questions betes
> sur
> https://plugins.spip.net/saisies.html?var_mode=calcul
>
> je vois
> 1. Des zip produit par tags
> 2. Des zip produits sur la dernière version du master
>
> On est d'accord qu'àa terme on virera le archivelist.txt et qu'on prendra
> le nouveau? Qui sera posé où ?
>
> *Autre chose, je sais pas si c'est lié, mais sur plugins.spip.net
> <http://plugins.spip.net>, il n'y a plus de lien vers le code... dommage
> c'était parfois utile. *
>
>
> Juste pour ma gouverne, je penser avoir lu qu'avec la refonte de
> spipcontrib , plugin spip devais disparaître.
> j'ai rêver ?
>
>
> -- spipfactory.fr
> 
> Perdu dans la Galaxie SPIP ?https://boussole.spip.net/https://git.spip.net/
>
> Le 1er juillet 2001 : SPIP 1.0   est lancé officiellement.
> Le 1er juillet 2020 : SPIP 3.3.0 "that is the question"
>
> ___
> 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] Tous en débardeur !

2020-04-01 Par sujet Eric Lupinacci
Hello,

Le mer. 1 avr. 2020 à 18:29, Franck  a écrit :

> Hello 
>
>- Juste pour dire que sur la zone, il y a des cas « particulier », il
>s’agit de plugs qui ne sont là que pour fournir une lib (il doit y en avoir
>beaucoup moins de 10 (possible 3 ou 4)).
>
> Exemple : htmlpurifier
> https://plugins.spip.net/htmlpurifier.html?compatible_spip=3.2
>
> C’était l’unique exception au format x.y.z
>
> Bref, c’est juste pour dire que le nouveau système doit en tenir compte,
> j’avais fait un ticket sur ce sujet https://core.spip.net/issues/4322
>

J'ai toujours été contre ce système.
Maintenant je ne sais pas ce que tu veux faire à ce propos.
On voit la version sur Plugins SPIP mais tu veux quoi d'autre ?


>
>
>
>
>- Enfin, une dernière chose, maintenant, sur plugin.spip, il y a des
>plug, ou il n’est plus possible de voir le lien vers le code du plug et en
>plus, maintenant, il y a un nouveau plug du nom de « spip » dans les « 30
>plus utilisé en spip 3.2 » de la page https://plugins.spip.net :D
>
>
Faut nous donner les noms sinon je ne vois pas ce qu'on peut faire.
Pour spip je pense que c'est du au fait que dans l'organisation spip il y a
spip et les plugins-dist.

++
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] Tous en débardeur !

2020-04-01 Par sujet Eric Lupinacci
Yo,

Le mer. 1 avr. 2020 à 14:42, nicod_  a écrit :

> Le 01/04/2020 à 13:25, Eric Lupinacci a écrit :
> > Donc maintenant avec Gitea on a plusieurs possibilités qui sont faciles
> > d'accès :
> > - créer une branche
> > - poser des tags
> > - et définir une version (au sens release).
> > sachant que le paquet.xml contient le numéro de version du plugin.
>
> Les notions de tags et de versions ne sont pas super claires pour moi.
>
> Les tags je vois bien (git tag), mais les versions ce serait un truc
> propre à Gitea ?
>
>
Non c'est propre à toutes les forges : release sur github par exemple.
En fait ça permet de faire ton changelog de tes tags, enfin c'est un peu
comme ça que je le comprends.
Pour l'instant on ne l'utilise pas avec le débardeur.



> > Je rappelle quand même le fil c'est aussi de décider si on bascule sur
> > le débardeur pour commencer à voir ces effets sur notre écosystème ?
>
> Je pensais que le débardeur était un script, et je l'ai d'abord cherché
> dans spip-contrib-outils
>
> En fait, c'est un plugin qui est ici :
> https://git.spip.net/spip-contrib-extensions/debardeur
>
> Du coup, qu'est ce que ça signifie "basculer" ? ajouter le débardeur
> dans les plugins dist pour qu'il fasse partie de le distribution ?
>
> Ou bien ce serait à chacun dans son coin de se l'installer soi même ?
>
>
Non non tu ne fais rien ! ;)

C'est un plugin script qui utilise spip-cli.
Il n'est utile que sur le serveur de zips mais tu peux aussi l'essayer chez
toi.
En fait, ça comble le manque de smart-paquets qui n'était utilisable que
dans un contexte spip défini alors que chacun pouvait se construire un site
comme plugins spip.

Donc pour en revenir à ta question, le débardeur tourne depuis quelques
minutes sur le serveur de zips en cohabitation avec smart-paquets.
Il produit donc les archives.xml et il convient maintenant de tester que
tous nos sites y compris Plugins SPIP se comportent comme avant coté SVP.

++
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] Tous en débardeur !

2020-04-01 Par sujet Eric Lupinacci
Oui, Erational a créé le tag ensuite.
Et donc tu le vois maintenant :p.


++
Eric


Le mer. 1 avr. 2020 à 14:33, nicod_  a écrit :

> Le 01/04/2020 à 09:53, erational a écrit :
> > OK, Je me suis fait avoir comme un bleu :)
> > Je croyais à une mauvaise traduction mais c'est une autre feature.
> >
> > J'ai pigé.
> > Merci pour les précisions
>
> Moi j'ai pas pigé, ou alors le tag a été créé entre temps ?
>
> Parce que je le vois bien là maintenant.
>
> --
> 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] Tous en débardeur !

2020-04-01 Par sujet Eric Lupinacci
Yop,

Le mer. 1 avr. 2020 à 12:03, Charles Razack  a
écrit :

> Après relecture de toutes les réponses sur la partie tag, j'avoue que
> c'est toujours pas très clair pour moi sur ce que ça implique concrètement
> quand on maintient un plugin.
>
> Je crois que la confusion pour ma part vient du fait qu'à la base un tag
> sert juste à signaler une version (le truc de base de git, et c'est normal
> qu'il y en ait moults), mais donc là ça pourrait amener à flooder le
> débardeur, même s'il se retreint au dernier tag d'une branche X.Y, c'est ça
> ?
>
> Dans ce cas quelle est la bonne pratique pour taguer les dépôts ?
>
Je pense que comme le dit Matthieu, ça vient du fait qu'avec la pratique de
la Zone on a souvent confondu je commite avec je publie une nouvelle
version. Erreur qui a surement été amplifiée par les légendes urbaines sur
SVP et ses mises à jour.
Donc maintenant avec Gitea on a plusieurs possibilités qui sont faciles
d'accès :
- créer une branche
- poser des tags
- et définir une version (au sens release).
sachant que le paquet.xml contient le numéro de version du plugin.

Il est donc important de savoir comment on manipule tout ça aujourd'hui
dans l'optique de Gitea et du Débardeur.

Des questions plus précises :
>
> 1) « il faut revoir l’outil pour qu’il [...] ne pose que les tags sur les
> dernières versions » : un truc m'échappe, ça n'est pas toujours aux
> mainteneurs de poser les tags ? Ça veut dire que le débardeur en pose
> lui-même ?
>
Non, c'est la phase 1 dont j'ai parlé plus haut : la migration de la zone
vers le Gitea.
Après normalement on pose les tags au fur et à mesure de de développement
selon une stratégie à expliquer.


> 2) Pour que le débardeur reconnaisse la version x.y.z à partir d'un tag,
> est-ce qu'il faut respecter une certaine nomenclature ? "v1.2.3", ou juste
> "1.2.3", ou autre ?
>
Oui, vx.y.z ou x.y.z.



> 3) Mettons que pour un plugin, je ne veuille proposer qu'un seul zip par
> branche X : je fais comment ?
> Exemple : il y a déjà des tags v1.0.x et j'ajoute un tag v1.1.0 suite à
> une nouvelle fonctionnalité → je supprime tous les anciens tag v1.1.x ?
>
Tu ne peux pas supprimer les tags.
Si on parle du débardeur aujourd'hui il prend uniquement le tag "max" de
chaque branche x.y.
Le problème c'est que l'on utilise souvent le z et le y lors des mises à
jour régulières des plugins, ce qui fait qu'on a pas mal de x.y différents.
Je me demande si il ne faudrait pas utiliser la notion de version (ou
release) pour filtrer un peu les tags ?

Je rappelle quand même le fil c'est aussi de décider si on bascule sur le
débardeur pour commencer à voir ces effets sur notre écosystè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] Tous en débardeur !

2020-04-01 Par sujet Eric Lupinacci
Re,

Le mer. 1 avr. 2020 à 09:42, erational  a écrit :

> Gitea permet aussi de le faire directement en ligne sur la forge.
>
> Sur chaque dépot, il y a un  onglet "version" qui permet de définir ses
> tags.
>
> Je viens de tester:
> https://git.spip.net/spip-contrib-extensions/sociaux/releases
>
>
Euh, alors il faut faire attention qu'une version Gitea (ou release sur
Github) c'est pas un tag. Tu poser une version sans qu'il y ait de tag
attaché.
Et c'est ton cas : si tu vas dans l'onglet code et que tu ouvres la liste
des branches/tags tu vas voir que tu n'as aucun tag.
Pas de tag pas de zip.
Pas de zip... pas de zip.

++
Eric (qui s'est déjà fait avoir)
___
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] Tous en débardeur !

2020-04-01 Par sujet Eric Lupinacci
Hello,

Si je prends l'exemple de formidable, il y avait 300 changement de versions
dans le paquet.xml que ce soit x, y ou z.
Mais il y a aussi 90 changements x.y, ce qui fait que même en prenant le
x.y.zmax on récupère 90 tags.
C'est pour ça que je ne suis pas sur qu'il faille même créer des tags à la
volée sur chaque x.y car la façon dont le y est utilisé est très
personnelle...

C'est pourquoi, je dirais qu'il faut agir en 2 étapes :
1- migrer les archivelist actuels en créant juste les tags nécessaires pour
reproduire les zips de la zone. Les contribs non transférées sur Gitea ne
sont pas concernées.
Si on peut aussi supprimer des zips inutiles allons-y. Je suis toujours
étonné de voir des chevauchements de branches spip entre plusieurs branches
du même plugin.

2- définir une logique de création de tag qui passera surement par une
logique de numérotation x.y.z et de gestion du master vs les branches.

++
Eric


Le mer. 1 avr. 2020 à 09:22, Cerdic  a écrit :

> Un tag c’est juste un pointeur sur une version qui en gros dira « là ça
> marche, on peut l’utiliser ».
> On tag pas forcément chaque version : quand on est sur le dev d’un plugin
> on incrémente les versions plusieurs fois en fonction des changements, on
> test, on debug, on réitère et quand ça semble stabilisé prêt à
> l’utilisation, hop on pose un tag.
>
> La commande c’est juste
> git tag 
>
> et donc la bonne pratique est de taguer simplement avec le numéro de
> version :
> git tag v1.2.3
>
> L’avantage aussi c’est que tant que tu tag pas c’est pas dans un zip.
> Donc tu as moins la pression de diffuser des bugs quand tu interviens sur
> un projet
>
> --
> Cédric
> Le 31 mars 2020 à 22:12 +0200, JLuc , a écrit :
>
> Le 31/03/2020 à 21:39, cam.la...@azerttyu.net a écrit :
>
> gogogogo
>
>
> certes
>
> Et pour celles et ceux qui ont oublié de tagguer correctement leur
> projet. On a un outil qui permet de détecter tous les changements de
> version écrits dans paquet et plugin.xml et d'en faire de beaux tags
> git.
>
>
> Je n'ai jamais tagué les plugins sur lesquels je bosse jusqu'à présent
> et à ma connaissance ça n'était pas incorrect.
>
> Qu'est ce que c'est donc que taguer correctement un projet ?
>
>
> 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
___
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   >