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

2021-02-27 Par sujet Gildas Cotomale
Le sam. 27 févr. 2021 à 17:35, Eric Lupinacci a écrit :
>
> Hello,
>
Hello Eric,
Hello all,

> [...] function territoire_peupler($type, $pays, $options = array())
> [...] mais la page part en erreur car on utilise un implode() sur les 
> arguments et cela provoque une erreur sur le troisième qui est un array.
>
> Donc je me demande si c'est un cas non prévu uniquement à l'affichage ou si 
> par définition l'API s'attend toujours à des arguments dont le type n'est 
> jamais tableau ?
>
Je lis que « implode — Rassemble les éléments d'un tableau en une
chaîne » et qu'il prend bien « tableau de chaînes » Donc erreur
normale (mais implode fait sens pour l'affichage …au premier abord.)
Pour l'API même, je ne saurai dire ne connaissant pas les specs et le
traitement fait de $options.
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

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

2021-01-04 Par sujet Gildas Cotomale
Bonsoir la liste,

Le lun. 4 janv. 2021 à 14:02, Eric Lupinacci a écrit :
>
> Re,
>
> Le lun. 4 janv. 2021 à 13:16, nicod_  a écrit :
[…]
>>
>> Sur ta proposition d'utiliser les versions de Gitea, si c'est une
>> fonctionnalité spécifique à Gitea je ne suis pas chaud : on ne pourrait
>> pas la reproduire si on devait changer de forge, ou bien sur un miroir.
>
>
> A priori Github a aussi cette notion de release et Gitlab un notion 
> d'étiquette.
> Je n'ai pas vérifié si cela coïncide exactement.

Attention, il y bien les étiquettes (tags) qui sont une fonctionnalité
de Git qu'on retrouve dans beaucoup de systèmes de gestions de
versions.
Il y a aussi les publications/versions (releases) qui s'appuient sur
les précédents en y ajoutant la génération des artéfacts et une note
de publication… On retrouve cela dans les principales forges basées
sur Git
- https://docs.gitlab.com/ee/user/project/releases/
- 
https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/managing-releases-in-a-repository
- Gitea reprend des fonctionnalité de Github que ne reprend pas Gogs,
et les versions sont maintenant automatiquement générée
https://christine.website/blog/gitea-release-tool-2020-05-31

Pour passer d'une forge à une autre, il y a un travail d'adaptation à prévoir…


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

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

2021-01-04 Par sujet Gildas Cotomale
Bonsoir tout le monde,

Le lun. 4 janv. 2021 à 17:39, Maïeul Rouquette a écrit :
>
> Le 04/01/2021 à 14:02, Eric Lupinacci a écrit :
> > Re,
> >
> > Le lun. 4 janv. 2021 à 13:16, nicod_ a écrit :
>
> > On pourrait utiliser le log de commit du tag et l'afficher dans SVP ?
> >
> >
> > Le log de commit est un pis-aller mais il ne correspond pas pour moi à
> > un changelog compréhensible pour tous.
>
> je pense que nicod parlais du log de commit de TAG différent du log standard
> il est possible en effet d'associer des messages à un tag, même si en
> pratique nous ne le faisons pas souvent (mais on devrait, de même qu'on
> devrait signer nos tags avec PGP).

Ah les étiquettes annotées
https://git-scm.com/book/fr/v2/Les-bases-de-Git-%C3%89tiquetage
Si on veut que ce soit la règle on peut ne prendre en compte que ce
type de tags…

> > Après, il y a une façon simple de faire un changelog c'est un fichier...
> > changelog (d'ailleurs y a une option dans Gitlab pour en ajouter un au
> > repo).
> > Il suffirait qu'il ait une structure standard pour servir partout où on
> > en aurait besoin comme le paquet.xml d'ailleurs.
> > Sans être obligatoire néanmoins.
> >
> peut être une solution plus simple en effet (mais faut voir si il existe
> un standard)

Il n'y a pas de standard établi (genre IETF/W3C/etc.) mais _presque_
un standard de faits (ou bonnes règles) dont on a un bon récapitulatif
sur https://keepachangelog.com/fr/1.0.0/ qui est sourcé ouvertement
sur https://github.com/olivierlacan/keep-a-changelog
Il y a une petite variation sur
https://www.freecodecamp.org/news/a-beginners-guide-to-git-what-is-a-changelog-and-how-to-generate-it/
mais on retrouve bien les mêmes points principaux…

Si l'usage des étiquettes annotées est systématique (pour documenter
chaque nouvelle version livrée) on peut programmaticalement générer le
fichier pour toutes les versions. Voir par exemple le billet suivant
http://lkdjiin.github.io/blog/2013/09/04/generer-un-fichier-changelog-avec-git/
___
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] repo pour gérer plusieurs git

2020-09-21 Par sujet Gildas Cotomale
Le jeu. 23 janv. 2020 à 22:51, j'ai écrit :
>
> Bonsoir la zone,
>
> Dans un autre registre, je viens de tomber sur ceci qui répond à un besoin 
> que j'ai au boulot : https://github.com/gabrie30/ghorg
> Gitea n'est pas (encore) pris en charge. Pour ceux qui ont un compte Github, 
> vous pouvez voter pour le ticket 56...

Je ne l'avais pas fait, merci aux personnes qui ont poucé… ;)
https://github.com/gabrie30/ghorg/issues/56
Y a plus qu'à tester : je me note cela pour la fin de semaine ^^
___
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 3.2->3.3 : codage des caractères dans les tables

2020-04-28 Par sujet Gildas Cotomale
Salut Stephane,

Je vois tardivement tes messages.
Je rajoute quand même quelques adresses pour les personnes qui
chercheront sur la liste
- https://contrib.spip.net/Convertir-un-site-SPIP-3-en-utf-8-avec-le-plugin
- https://contrib.spip.net/Passez-votre-base-SPIP-en-Unicode
- https://contrib.spip.net/Comment-passer-son-site-en-utf-8
- 
https://blog.sodifrance.fr/encodage-et-migration-de-la-base-de-donnees-de-spip-en-utf-8/
- http://zzz.rezo.net/Reparer-le-charset-d-une-base-SPIP.html
- etc.
___
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] SVN => GIT : Core de SPIP & plugins-dist

2020-04-28 Par sujet Gildas Cotomale
Le mar. 28 avr. 2020 à 15:32, teamspipfactory a écrit :
>
> ah ben voilà
> le checkout fonctionne
>
> suffisais que je renomme le .php en .sh
>
Ça n'a pas de sens…
Tu as peut-être des réglages pour pouvoir lancer des .sh ?

> c'est con mais il faut y penser
>
___
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] https://git.spip.net/explore/organizations

2020-04-28 Par sujet Gildas Cotomale
Le lun. 27 avr. 2020 à 19:37, YannX SPIP(hot) a écrit :

>>   - si on utilise une URL en https://git.spip.net, c’est du https. Donc le 
>> clone et le pull peuvent être anonymes si le dépot est public (sinon il faut 
>> s’identifier, via un mot de passe). Pour push il faut forcément s’identifier 
>> via des mots de passe et c’est donc pas très pratique ni sur.
>
> C'est la procédure que j'ai voulu utiliser pour pusher colorscope, avec 
> succès "sauf que"
> les fichiers source téléchargés se sont retrouvés chaque ligne précédée 
> de son numéro

tutut. ce n'est pas possible…
Je pense que vous ne parlez pas des mêmes choses : « git push »
n'ajoute pas de numérotation de ligne !
…ou alors t'as d'autres choses configurées que tu ne dis pas ou
ignore. Raison pour laquelle il faut apprendre Git en ligne de
commande et non avec des interfaces qui font des choses en douces.
___
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] SVN => : Plugin Corbeille + newsletter langue aléatoire

2020-04-28 Par sujet Gildas Cotomale
Le dim. 26 avr. 2020 à 20:42, teamspipfactory a écrit :

> bon le problème se pose sur plusieurs plugins la banche master me délivre
> une langue autre que le français
> que puis je faire ???
>

Je vais peut-être dire une connerie, mais je pense que tu devais déjà avoir
ce souci même avec Svn…
Je dis ça parce-que, si j'ai bien compris, tu récupères directement la
source et non le paquet --via l'interface de SPIP ou le zip sur
plugins.spip.net-- une fois bien emballé et pesé. Du coup tu n'as pas les
fichiers de langues de Salvatore
(pendant que j'écris ça je me fais la remarque que le boulot des
traducteurs était directement « commité » dans Subversion, et donc ce n'est
peut-être pas encore le cas avec le Git ? dans ce cas il faut patienter…)
___
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] https://git.spip.net/explore/organizations

2020-04-25 Par sujet Gildas Cotomale
Bonjour teamspipfactory@
>
> ben en cliquant sur le lien en haut a droite "clone or download'
>
> https://github.com/cariagency/spip-pseudo-hasard/archive/master.zip
>
Donc tu as récupéré le zip généré depuis la dernière version (HEAD) du
tronc (master)

Autrement dit, tu n'as pas fait un clone du dépôt ; donc normal que tu
ne puisses pas faire d'opération git dessus. C'est sur ça que Charles
voulait attirer ton attention.
___
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] Tag sur git mais pas sur gitea

2020-04-09 Par sujet Gildas Cotomale
Le jeu. 9 avr. 2020 à 11:53, nicod_ a écrit :
>
> Le 09/04/2020 à 11:24, Maïeul a écrit :
[...]
> > En tout cas à lire les messages sur ce fil, il semblerait quand même que
> > la logique dans gitea soit un tag = une release
>
J'ai là une instance de Gitea où je constate bien que ce n'est pas le cas.
Peut-être une nouveauté que j'ai loupé et qui s'activerait en config ?
(je vais mettre à jour mon instance, sans rien toucher à sa
configuration et je verrai)

> J'ai créé hier un nouveau dépot sur spip-contrib-extensions :
> https://git.spip.net/spip-contrib-extensions/opquast
>
> Après avoir poussé le code dans le dépôt, j'ai créé un tag localement
> (git tag -a v1.0.0 -m "Version 1.0.0" et git push), et ça a bien créé
> une release côté Gitea, automatiquement.
>
Je pense que ce doit être une nouveauté ou des automatismes (crochets
post poussée) sur le serveur.
Et dans l'un de ces cas, à confirmer si c'est pour tous les tags ou
seulement ceux annotés comme ici…
___
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] Tag sur git mais pas sur gitea

2020-04-09 Par sujet Gildas Cotomale
Le jeu. 9 avr. 2020 à 11:20, Maïeul Rouquette a écrit :
>
> Hum, je peux t'assurer que pour formidable, comme c'est moi qui les
> avais poussé à l'époque, c'était bien du git push --tags. Ca avait même
> fait crier puisque cela avait provoqué plein, plein de commits svn :)

Un point de détail qui n'est pas incompatible avec ce que dit Km
Je pense qu'avec la synchronisation Svn, il y avait des crochets qui,
comme les imports, génèrent des versions dans la foulée ?

> Le jeudi 09 avril 2020 à 11:17 +0200, cam.lafit a écrit :
> > Bonjour
> >
> > Ils ont été importés via l'api de gitea. De ce que je vois ce sont
> > des tags pre-éxistants à l'usage de git.
> >
> > Ils n'ont pas été créés par un git push --tags par exemple.
> >

Toujours est-il que, comme déjà dit, tags et releases sont deux
notions différentes et non synonymes.
___
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] Tag sur git mais pas sur gitea

2020-04-08 Par sujet Gildas Cotomale
> Et comme dit la doc, on peut scripter un automatisme ou utiliser un
> déclencher-pousseur

Exemple d'outil pour Gitea (on se base sur celui de CI-CD)
https://github.com/drone-plugins/drone-gitea-release
Ce genre d'extension utilise bien entendu les API dispos
___
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] Tag sur git mais pas sur gitea

2020-04-08 Par sujet Gildas Cotomale
> > Mais pas Gitea à priori.
>
> Ah si effectivement, dans les autres projets, les simples tags apparaissent 
> aussi dans release…

Je maintiens que ce n'est pas automatique…
…Puisque, par définition, tu choisis quand tu veux faire ta sortie et
sur quel tag avec le reste (le/a texte/description, le nom/titre qui
peut ne pas être celui du tag, les assets complémentaires …que la
forge ne peut pas deviner)
https://help.github.com/en/github/administering-a-repository/managing-releases-in-a-repository
Et j'ai des tags sans releases, les releases que j'ai ont été créés manuellement
Et comme dit la doc, on peut scripter un automatisme ou utiliser un
déclencher-pousseur
https://help.github.com/en/actions/building-actions/publishing-actions-in-github-marketplace
https://github.com/marketplace/actions/automatic-releases
https://github.com/go-gitea/gitea/issues/6875
___
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] Tag sur git mais pas sur gitea

2020-04-08 Par sujet Gildas Cotomale
[...]
>> https://git.spip.net/spip-contrib-extensions/formidable_participation/src/tag/v1.9.0
[...]
> hum, mais il est pas ici
>
> https://git.spip.net/spip-contrib-extensions/formidable_participation/releases
>
ça c'est pas automatix ^^

> on le trouve pas non plus sur
> plugins.spip.net, alors que normalement le débardeur est censé s'appyuer
> sur les tags...
>
> c'est bizarre
>
les tags oui, pas les releases.
mais en effet, étrange qu'il soit pas débardé ; faut patienter un peu
…ou Cerdic peut nous en dire plus ?
___
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] Tag sur git mais pas sur gitea

2020-04-08 Par sujet Gildas Cotomale
Le mer. 8 avr. 2020 à 23:26, Maïeul Rouquette  a écrit :

> j'ai bien un tag v1.9.0
>
> Par contre Gitea ne l'affiche pas (et du coup je pense que le débardeur
> ne le trouve pas).
>

Si, si, il est bien présent
https://git.spip.net/spip-contrib-extensions/formidable_participation/src/tag/v1.9.0

(l'interface est un peu trompeuse… dans le menu déroulant, faut faire un
clic sur "Branches" ou "Tags" selon ce qu'on veut lister, puis faire son
choix)
___
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 Gildas Cotomale
Le mer. 8 avr. 2020 à 09:43, Cerdic a écrit :

> Ah ben oui c’est tout caché !
>
> Je dirai que ce serait bien de le mettre soit une rubrique dédiée sur
> contrib,
> soit carrément dans une rubrique dédiée à git dans « Comment contribuer »
> sur spip.net non https://www.spip.net/fr_rubrique205.html ?
>

Je crois que c'est prévu, enfin fallait décider où mettre la version finale.
En attendant c'était sur la Taverne.

>
> Qu’on ait effectivement un endroit où envoyer les utilisateurs perdus…
>


>
> Le 8 avr. 2020 à 09:38 +0200, Eric Lupinacci a écrit :
>
> Hello,
>
>
> Le mer. 8 avr. 2020 à 09:31, Cerdic a écrit :
>
>
[...]

> 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.
>
>
Ça me rappelle que je m'étais noté de faire de la relecture…
Il te manquait surtout sur Windows et Linux si j'ai bonne mémoire ?
Chez moi je travaille sous Linux. Au boulot, à l'époque j'avais du Windows
(mon actuel est Mac) mais nos serveurs Linux avec du Git sur certaines
machines dont les rebonds.
___
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 Gildas Cotomale
Le jeu. 27 févr. 2020 à 16:29, Jean-Christophe Villeneuve a écrit :

> Bonjour
>
> Bonjour Jean-Christophe,

[...]

> Jusque-là, je livre sur le dépôt SVN en utilisant RabbitVCS SVN (sur
> Linux Ubuntu 18.04)
> N'étant pas adepte de la ligne de commande, j'aimerais bien avoir un
> logiciel me permettant de livrer aussi simplement sur GIT
>
> Une recherche rapide me mène vers les pages de listing suivant :
- [anglais] https://git-scm.com/download/gui/linux
- [français]
https://www.supinfo.com/articles/single/2782-onze-meilleurs-clients-graphiques-git-linux
- [anglais]
https://www.tecmint.com/best-gui-git-clients-git-repository-viewers-for-linux/
- [anglais] https://linuxhint.com/best_git_gui_clients_ubuntu/
- [anglais] https://www.ubuntupit.com/top-15-best-git-clients-for-linux/
- [français] https://doc.ubuntu-fr.org/git#interfaces_graphiques
- [anglais]
https://www.slant.co/topics/242/~best-graphical-git-clients-for-linux

Certains noms reviennent souvent ; ils ont donc une certaine notoriété et
il peut valoir le coup de tester.
Sinon, si je comprends bien la page du Wiki francophone Ubuntu, tu peux
continuer à utiliser RabbitVCS …en rajoutant le greffon/extension (plugin)
Git !
D'après la liste de Slant, selon l'éditeur que tu utilises, il a peut être
une extension qui fait l'affaire (ces éditeurs sont assez extensibles pour
permettre de construire un EDI sur mesure et ont une large communauté qui
fourni divers « add-ons »


>
___
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-04 Par sujet Gildas Cotomale
>> 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.

Pas toutes les forges… Je n'ai pas souvenir d'avoir vu ça dans Trac
(et ne pas confondre avec Svn car il peut se brancher sur Git aussi
d'une part, et que Sourceforge qui s'appuie sur Svn a cette notion de
release à travers la page de téléchargement de chaque projet) ni dans
Gogs (le frère aîné de Gitea) Mais cette précision est sans
importance.

> 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.
>
Le mot indique la "livraison/sortie" d'une nouvelle "mouture/version" ;
cf. [en anglais] https://searchsoftwarequality.techtarget.com/definition/release
& [en anglais] https://en.wikipedia.org/wiki/Software_release_life_cycle
(notions de RC et SR, ainsi que GA et EOL)

Les forges, de plus en plus, permettent de faire une release à partir d'un tag.
On va associer en effet un texte de "quoi de neuf" ou une synthèse des
changements significatifs (un vrai fichier d'historique/changelog
pouvant être disponible dans les dépôts) avec les sources [qui souvent
peuvent être téléchargé directement sans passer par ce biais --mais
c'est plus facile pour les usagers finaux] et d'autres fichiers…
En effet, on peut associer aux releases des binaires construits pour
cette sortie (si on a mis en place un mécanisme de CI-CD) et ceux-ci
peuvent être hébergés par la forge [dans ce cas c'est un espace dédié,
comme le files.spip.net, et non dans le dépôt] ou ailleurs. cf [en
anglais] https://stackoverflow.com/a/33587799/1699311
Les "assets" construits/générés, et/ou les parties du dépôt ayant
servi à leur création peuvent être vu comme les "artéfacts"

ailleurs  ;-)

Noter qu'on peut supprimer (et refaire) une "release", mettre à jour
sa note, mais qu'on ne peut supprimer un "tag"
>
>>
>> > 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
>>
Ah merci. Je me demandais où était ce truc que je ne suis pas parvenu
à trouver sur Wikipedia comme annoncé.
Je vais aller jeter un oeil, mais de ce que je lis c'est dommage que
ça s'appuie sur les tags et non les releases.
___
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-04 Par sujet Gildas Cotomale
Le mer. 1 avr. 2020 à 13:25, Eric Lupinacci a écrit :
>
> 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 ?
>>
Tout "commit" Git est référencé par un haché (là où Subversion utilise
un numéro de commit)
Le "tag" Git permet de nommer un haché, i.e. poser une étiquette
synonyme de la longue référence hexadécimale interne. En tout cas
c'est ainsi que je l'utilise.

Ta version peut se composer de plusieurs commits, ce qui est
d'ailleurs mieux en terme de relecture-suivi-maintenance. En tout cas
j'ai toujours trouvé pénible de devoir faire une nouvelle version pour
chaque commit car j'aime avoir de petits commits pour résoudre un
souci ou ajouter une fonctionnalité. (Après, j'imagine que c'est lié
au mode de fonctionnement de Subversion et au nombre de personnes
participant… Avec Git le souci ne se pose plus car on poussera une
version qui pourra avoir plusieurs commits)

>> 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.

Quelles légendes par exemple ?
Il me semble que ce/cette choix/pratique existait bien avant SVP,
d'incrémenter "z" (probablement pour ne pas perdre les personnes qui
rafraichissent leur installation par un "svn co" ?)

> 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 ?
>
Oui, ce débardeur devrait s'appuyer sur les versions publiées et non les tags.
Idéalement, les deux se suivent, mais il peut arriver qu'on ait un tag
qui ne soit pas destinée à la publication du grand public
(contrairement aux releases)

> 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] Poids indiqué par gitea

2020-04-04 Par sujet Gildas Cotomale
Le sam. 4 avr. 2020 à 20:41, nicod_ a écrit :
>
> Par curiosité, quelqu'un sait à quoi correspond le poids d'un dépôt
> indiqué dans Gitea ?
>
Normalement l'occupation disque sur le serveur,
si j'ai bien compris https://github.com/go-gitea/gitea/issues/7796

> Par exemple sur celui là :
> https://git.spip.net/spip-contrib-extensions/fusion_spip
> Gitea indique 106 MB (sur la ligne avec le nombre de révisions et de
> branches)
>
> Alors que localement, le dépôt fait juste 308 Ko...

111 KiO dans le zip du master que je viens de récupérer.
Mais normal, celui-ci n'a pas toute l'historique que tu as en local.
Et j'imagine qu'il y a plus de choses sur le serveur ?
Mais l'écart est tel que je soupçonne un bogue…
___
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] Espace au début d'un code

2020-03-17 Par sujet Gildas Cotomale
Le mar. 17 mars 2020 08:59, Stephane Santon a écrit :

> Bonjour,
>
> Le 17/03/2020 à 08:40, Charles Razack a écrit :
> >> Quand j'écris la balise  suivie d'une espace, je ne pense
> >> pas que celle-ci devrait être supprimée.
> >> Bug ou feature ?
> >
> > Calomnies, SPIP ne supprime aucun espace :p
> > C'est un comportement navigateur.
> > Pour forcer à garder tous les espaces, il faut soit utiliser la balise
> > , soit le faire en CSS avec white-space:pre; par exemple.
>
> Effectivement, le code source a bien conservé l'espace, et il n'est pas
> affiché dans Firefox.
>

Arf, si c'est conservé c'est bon ;
C'était un problème de rendu (mais comportement tout à fait normal comme
l'explique Rasta)

Sinon je préfère en général code dans pre que de styler code comme pre


>
>
___
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] Espace au début d'un code

2020-03-17 Par sujet Gildas Cotomale
Le mar. 17 mars 2020 00:16, Stephane Santon a écrit :

> Le 17/03/2020 à 00:06, Gildas Cotomale a écrit :
> >  >  ?
> > Ben non, je ne veux pas écrire le code html d'une espace insécable...
> >
> > Je désire écrire *le caractère* 'espace', de code %20.
> >
> > 
>
> NAAANN !! Je veux écrire *le caractère*, /PAS son code/ !
>

Je réagissait juste au fait que c'est l'espace normal et non insécable, en
rappelant que tout caractère a une entité numérique correspondante même
s'il n'y a pas d'entité nommée.
En fait c'est même ça *le caractère* ; l'autre forme étant le code, rendu
par ton éditeur, et qu'il faut préciser dans l'entête de la page pour
espérer que tes lecteurs aient le même rendu... :-)


> Quand j'écris la balise  suivie d'une espace, je ne pense pas que
> celle-ci devrait être supprimée.
> Bug ou feature ?
>

Il faudra faire le test... Créer une page web simple, en local, avec ton
cas, pour voir comment se comportent tes navigateurs. J'ai souvenir d'avoir
eu des surprises comme cela (et en vérifiant, la norme est bien entendu
muette sur le détail.)

Si ce premier test n'indique pas de problème, le second test est de
reprendre le même test avec les feuilles de style de ton SPIP.

S'il s'avère malgré tout cela que c'est seulement avec SPIP que ça pose
souci, il faut alors : désactiver tous les plugins et les styles persos,
puis désactiver les compressions... (on a parfois de petites surprises avec
ça)

Si avec tout ça, ça persiste, alors t'auras identifié un bogue (le
traitement de SPIP n'est pas supposé virer les espaces mais juste
transformer les signes supérieur-à et inférieur-à en leur entité)


>
>
___
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] Espace au début d'un code

2020-03-16 Par sujet Gildas Cotomale
> >  ?
>
> Ben non, je ne veux pas écrire le code html d'une espace insécable...
>
> Je désire écrire *le caractère* 'espace', de code %20.
>




>
>
___
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] PostMortem : Incident core/svn/zone.spip.net : 05-07 mars 2020

2020-03-08 Par sujet Gildas Cotomale
Merci beaucoup Camille, pour
- tes actions et le temps offert à la communauté
- ton suivi et ta disponibilité qui sont d'une grande valeur
- ce comote-rendu complet


> Autrement dit il y a plusieurs problèmes suite à l'incident électrique :
> * certains serveurs physiques ont été plus sensibles que d'autres
> * la salve d'alerte (incident et rétablissement) a caché le fait que
> tout n'était pas remonté
> * j'étais sur d'autres actions ce qui a réduit ma disponibilité pour
> traiter sereinement toute les alertes
> * un des serveur était actif mais sans lancer les services spip (faux
> positif)
> * ma messagerie personnelle était tombée en même temps et je n'ai reçu
> des notifications que tardivement (et n'étant pas scotché dessus, 24
> ou 48h sans lire de mail ne m'a pas choqué)
>

Sacré Murphy...


>
>
>
___
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 Alpha et hiérarchie des titres

2020-03-02 Par sujet Gildas Cotomale
>
>
>
> Dernière question (parce que j'ai pas trouvé/réussi), comment on
> supprime une branche ?
>
> J'ai fait la manip sur
> https://git.spip.net/spip-contrib-squelettes/html5up_hyperspace :
> création d'une branche V2, merge du dev (v3) dans master mais je
> n'arrive pas à supprimer cette branche dev maintenant.
>
> Je crois que j'ai réussi en local avec git branch -d dev (alors que
> j'avais error: branch 'dev' not found au début ?!?) mais elle est
> toujours en ligne
> https://git.spip.net/spip-contrib-squelettes/html5up_hyperspace/branches/
> malgré mes push.
>


Alors : git branch -d dev
...va supprimer la branche localement, d'où l'erreur si elle n'existe pas
chez toi.

Ensuite : git branch
...tout court pour lister toutes les branches que tu as localement, avec un
petit signe (astérisque de mémoire) devant la branche courante.

Enfin, quelque chose comme : git push -d dev
...pour supprimer la branche distante si tu es autorisé(e) à le faire (par
exemple si ce n'est pas une branche protégée ni la seule restante et que
t'as le privilège de suppression de branche, ce qui est le cas quand tu es
propriétaire ou mainteneureuse)



> J'ai utilisé ce guide envoyé sur la liste je crois :
> http://rogerdudler.github.io/git-guide/index.fr.html
>
>
___
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] Inscription ouverte des contributeurices (choses à résoudre)

2020-03-02 Par sujet Gildas Cotomale
Le dim. 1 mars 2020 12:05, Km a écrit :

> Ciao
>

Ciao Km e tutti.

>
> Cela est fait.
>

Molte grazie.

C'est un peu un non sens de vouloir fermer aux gens mais la majorité à
> raison :)
>

Ce n'est pas fermé aux vrais gens (les bots oui) ;  c'est juste soumis à
une procédure humaine (je ne vois pas le lien vers la page qui devait être
rajoutée) et chaleureuse :-)

Personne n'est vraiment contre le fait que les gens puissent s'inscrire,
sous réserve qu'ielles acceptent la charte et s'inscrivent à la liste dans
la foulée...


>
___
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] Rien de coordonné dans Coordonnées !

2020-02-26 Par sujet Gildas Cotomale
Le mer. 26 févr. 2020 07:57, Cerdic a écrit :

Par ailleurs je dirai plutot de garder la branche v2 telle quelle au cas où
> elle est encore utilisée, copier le master en branche v2.5, et passer le
> trunk en v3 (ce qui aurait du être fait dès l’origine)
>

+1
___
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] Coordonnées adresses et découpageS administratifS

2020-02-25 Par sujet Gildas Cotomale
Le mar. 25 févr. 2020 10:30, RastaPopoulos a écrit :

> Le 25/02/2020 à 08:40, Gildas Cotomale a écrit :
> > Je ne sais pas ce que tu entends par "n'existe nulle part"
>
> Ce n'est pas un champ existant, dans aucun pays. Quand il y a un service
> de boite postale, c'est à remplir dans le champ d'adresse de base ou dans
> la ligne de complément, avec un mot clé (par ex en France c'est "BP" puis
> un numéro).
> https://fr.wikipedia.org/wiki/Adresse_postale#France
>
> D'où le fait que je propose de déplacer les contenus actuels des gens qui
> auraient utilisé "boite_postale" dans le champ "complement", puis de
> supprimer "boite_postale".
>

Ah... Je comprends mieux et n'ai pas vraiment d'avis du coup.
J'en étais resté à "vCard 3/4" <
https://tools.ietf.org/html/rfc6350#section-6.3.1> et son homologue "xCard"
<https://tools.ietf.org/html/rfc6351>


>
___
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] Coordonnées adresses et découpageS administratifS

2020-02-24 Par sujet Gildas Cotomale
Le mar. 25 févr. 2020 08:40, Gildas Cotomale a écrit :

>
>
> Le mar. 25 févr. 2020 01:33, RastaPopoulos a écrit :
>
> Et il faudra gérer le champ "boite_postale" qui n'existe nulle part, pas
>> même en France, et qui est juste un complément à l'adresse : je propose de
>> le fusionner dans le champ "complement".
>>
>
> Je ne sais pas ce que tu entends par "n'existe nulle part" ...mais c'est
> la seule adresse postale de beaucoup en Afrique de l'Ouest par exemple, où
> le courrier n'est pas distribué à résidence. Cela existe aussi aux
> États-Unis ces "postes restantes".
>

Le service existe encore officiellement en France <
https://www.laposte.fr/produits/article/prenez-de-l-avance-sur-le-facteur>
et en Belgique <
https://www.bpost.be/site/fr/recevoir/lettres-cartes/boites-postales> aussi
!

>

>>
___
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] Coordonnées adresses et découpageS administratifS

2020-02-24 Par sujet Gildas Cotomale
Le mar. 25 févr. 2020 01:33, RastaPopoulos a écrit :

En fait pour les adresses, un seul niveau administratif maxi est demandé
> dans le monde *au dessus* de la ville. En revanche il y en a parfois un *en
> dessous* et qui parfois est obligatoire (l'arrondissement, le quartier,
> etc, notamment dans des pays avec des très grandes communes). Il faudrait
> donc rajouter ce champ ("dependent locality" en anglais, je sais pas trop
> pour nous…).
>

Je crois que c'est l'équivalent de certains lieux-dit ou bourgs. En France
le problème se présente dans l'autre sens : on indique la localité au
niveau habituellement appelé ville, mais il dépend d'un "bureau
distributeur" partagé avec une autre localité (du coup ils ont le même
"code postal" qui n'est pas discriminant)

Et il faudra gérer le champ "boite_postale" qui n'existe nulle part, pas
> même en France, et qui est juste un complément à l'adresse : je propose de
> le fusionner dans le champ "complement".
>

Je ne sais pas ce que tu entends par "n'existe nulle part" ...mais c'est la
seule adresse postale de beaucoup en Afrique de l'Ouest par exemple, où le
courrier n'est pas distribué à résidence. Cela existe aussi aux États-Unis
ces "postes restantes".


>
___
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] Mise à jour git.spip.net

2020-02-24 Par sujet Gildas Cotomale
> > Une mise à jour mineure a eu lieu. On passe à la version 1.11.1.
>
> Attention, ça ne marche plus du tout depuis cette annonce, ni git ni
> interface web. :(
>

De mon smartphone il affiche l'erreur d'adresse introuvable...
Pour en avoir le coeur net, j'ai demandé un test externe qui dit qu'il y a
non réponse (timeout)
https://www.webpagetest.org/result/200224_PP_1d524549a2100dc2bf67f9fba04b448f/
Donc pas de problème DNS mais le serveur (service gitea) à relancer ...ou
le parfeu à reconfigurer ?

>
>
___
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] Mise à jour git.spip.net

2020-02-24 Par sujet Gildas Cotomale
Le lun. 24 févr. 2020 14:02, Km a écrit :

>
> Le détail se passe sur :
> https://blog.gitea.io/2020/02/gitea-1.11.1-is-released/


De ce que je lis, vivement la 1.11.2 qui ne saurait tarder :-)
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] [hs] sans facteur

2020-02-11 Par sujet Gildas Cotomale
Le mar. 11 févr. 2020 12:13, Maïeul Rouquette a écrit :

> a mon sens facteur en core aurait du sens, mais il faudrait offrir la
> possibilité de faire des mails en text brut (ecologie, tout ca)
>

Ah mais carrément (le texte pur, préférablement Unicode-encodé, est la vie)


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

Re: [spip-dev] [hs] sans facteur

2020-02-11 Par sujet Gildas Cotomale
Le mar. 11 févr. 2020 12:07, Cerdic a demandé :

> Il y a une raison particulière ?
>

Réponse courte : non...

Quelque chose qu’on manquerait en intégrant le plugin facteur dans la
> distrib de base ?
>

Je ne sais pas du tout ; jamais regardé ce que fait la facteurice 

Ou juste un choix philosophique ?
>

Un peu philosophique, surtout de principe :  minimum de plugin, surtout si
je peux faire sans... (et pour l'instant, je n'ai pas été obligé d'utiliser
facteur donc pas de facteur pour le confort)

Si c'est dans la distribution de base, bah il y a de fortes chances qu'on
l'utilise sans s'en rendre compte...


> L’envoi d’emails devient de plus en plus compliqué et ça commence à
> devenir anachronique de continuer à considérer que c’est la fonction mail()
> de PHP qui doit faire le job sans offrir d’alternative par défaut...
>

Je ne suis point contre les alternatives ; ma réponse initiale était juste
pour dire qu'il en existe qui peuvent se permettre le bon vieux sendmail
direct et donc ne se rendent peut être pas compte de ce qu'illles loupent
  (irréductibles c'est pour la boutade)


> --
> Cédric
> Le 10 févr. 2020 à 21:39 +0100, Gildas Cotomale a écrit :
>
> Le lun. 10 févr. 2020 20:14, B B a demandé :
>
>>  mais bon, qui envoie encore des mails sans facteur ?
>>
>
> ✋ (y a des irréductibles)
>
>>
___
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] [hs] sans facteur

2020-02-10 Par sujet Gildas Cotomale
Le lun. 10 févr. 2020 20:14, B B a demandé :

>  mais bon, qui envoie encore des mails sans facteur ?
>

✋ (y a des irréductibles)

>
___
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] r122358 - in _plugins_/agenda/trunk

2020-02-10 Par sujet Gildas Cotomale
Le lun. 10 févr. 2020 19:40, dut a écrit :

> Je réagis sans doute un peu hors sujet, mais dans le cas d'un agenda
> culturel souvent les evenement commencent en soirée et se termine au delà
> de minuit sans que personne ne les envisage sur deux dates différentes.
> Idéalement, avoir un paramètre qui permettrait de fixer l'heure de
> changement de date à un autre horaire que minuit (dans le cas du site qui
> m'intéresse à 6h du matin), serait un plus qui clarifierait les choses.
> Mais j'entends que ça compilquerait l'usage courant.
>
> Votre avis sur cela ?
>


Je pense que c'est plutôt un problème d'affichage (donc un/une
squelette/noisette adapté/e) qu'autre chose...

Un événement commence à un moment (un jour donné à une heure dite) et se
termine à un moment ultérieur (qui peut être le jour suivant) Ça ne pose de
problème à personne, à ma connaissance, et les usagers de smarthphones y
sont même habitués [pour ceux qui récupèrent le fichier .ics de
l'événement] Après c'est de l'affichage [et tous les programmes d'agenda
--sur PDA, ordi, tél-- ne se valent pas pour les trucs à cheval sur deux
jours ou plus, mais on comprend fort bien]

>
> Le 10/02/2020 à 18:16, Cerdic a écrit :
>
> Salut Jean-Marie,
>
> j’ai éventuellement un patch pour changer ça en base, mais je ne suis pas
> certain que ce soit la bonne méthode.
> Notamment avec l’introduction des fuseaux horaires on se retrouve avec
> potentiellement des événements (faussement) à cheval sur 2 jours selon le
> fuseau considéré, et j’ai peur que çà complique des choses.
>
> Actuellement les critères {evenement_a_venir} {evenement_en_cours} {
> evenement_passe} prennent bien en compte le champ horaire et ne se
> trompent pas : un evenement sans horaire n’est passé que le jour suivant,
> et pas dès que 0h00 est passé.
>
>
C'est l'essentiel, pas besoin de complexifier plus que ça.


> Donc dans quels autre cas cela te semble gênant ?
>
> --
> Cédric
> Le 10 févr. 2020 à 17:38 +0100, Jean Marie Grall a écrit :
>
> Salut,
>
> je profite des ces commits et du travail en cours sur la V4 pour
> remonter un échange d'il y a qqs temps au sujet des événements sur la
> journée dont la date de fin est -MM-DD 00:00:00 et qui sont donc
> considérés comme terminé à 00h le matin au lieu de 23h59:59 le soir.
> https://www.mail-archive.com/spip-zone@rezo.net/msg47390.html
>
> A voir si ça peut s'insérer dans la fournée des évolutions en cours :)
>
> jean marie
>
>
> Le 10/02/2020 à 17:17, spip-zone-com...@rezo.net a écrit :
>
> Author: Cerdic
> Date: 2020-02-10 16:07:48 + (Mon, 10 Feb 2020)
> New Revision: 122358
>
> Modified:
> _plugins_/agenda/trunk/
> _plugins_/agenda/trunk/formulaires/configurer_agenda.html
> _plugins_/agenda/trunk/lang/configureragenda_fr.php
> Log:
> On ajoute une configuration pour la prise en charge des fuseaux horaires
> sur les evenements (todo)
>
>
> Details: https://zone.spip.org/trac/spip-zone/changeset/122358
>
> ___
> 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
>
>
> ___
> 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] Inscription ouverte des contributeurices (choses à résoudre)

2020-02-07 Par sujet Gildas Cotomale
Le ven. 7 févr. 2020 21:07, Gildas Cotomale a écrit :

> Le ven. 7 févr. 2020 13:27, Eric Lupinacci a écrit :
>

Mais si on veut proposer une PR faut-il absolument être inscrit ?
>>
>
> Oui... (en fait, il y a d'autres possibilités que d'être sur notre forge,
> mais dans tous les cas il faut avoir l'autorisation de pousser vers le
> dépôt... et comme en pratique personne ne maintient plusieurs ACL bah faut
> être sur github pour faire une PR sur github et pareil pour les autres
> forges)
>

Bon, je vérifie quand même (et constante que je ne suis pas à jour) : la
chose devrait être possible moyennant l'utilisation d'une étiquette signée
(usage avancé et très motivé donc)
https://stackoverflow.com/questions/9630774/how-to-make-pull-requests-without-a-github-account/9630828#9630828
=>
https://git-blame.blogspot.com/2012/01/using-signed-tag-in-pull-requests.html


> Si non, alors le fonctionnement "zone" est toujours acceptable.
>> Si oui, alors là c'est plus problématique mais on pourrait imaginer
>> d'inscrire toute personne avec des droits de lecture uniquement et de ne
>> réserver les droits d'écriture,
>>
>
> N'importe qui a déjà le droit de lecture (tant que le/la
> dépôt/organisation est marqué/e comme public/que ...et dans ce cas, même
> pas besoin d'un compte pour consulter en ligne --comme c'était/est avec le
> Trac-- ni pour cloner localement le dépôt)
>
> Sauf si tu voulais dire pouvoir s'inscrire sur le gitea sans être
> automatiquement rattaché à l'équipe contrib (et donc avoir les droits sur
> ses organisations...) C'est faisable mais sans intérêt (si ce n'est
> d'offrir à tous ceux qui passent un espace pour des dépôts perso)
>
> donc de contribution à SPIP que sur demande et acceptation de la charte
>> comme sur le zone.
>>
>
> Voilà. Des changements oui, tant qu'on ne change pas ces deux points :
> - accepter la charte (il faut être d'accord avec les idéaux défendus et
> les règles de fonctionnent de la communauté à laquelle on veut participer)
> - s'inscrire (ou être inscrit automatiquement si on accepte que les gens
> s'inscrivent d'eulles même sur le gitea) à la liste (cf. point précédent,
> puisque cela fait encore partir des règles de fonctionnement)
>
___
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] Inscription ouverte des contributeurices (choses à résoudre)

2020-02-07 Par sujet Gildas Cotomale
Le ven. 7 févr. 2020 13:27, Eric Lupinacci a écrit :

> Yop,
>
> Le ven. 7 févr. 2020 à 09:54, JLuc a écrit :
>
>> Le 07/02/2020 à 09:10, Eric Lupinacci a écrit :
>> > je ne vois pas pour quelle raison le changement d'outil devrait
>> impliquer un changement de procédure :
>>
>> Tout à fait, mais il n'y a pas non plus de raison de garder le
>> fonctionnement tout comme avant,
>> car il y a tout de même eu des envies de changer certains fonctionnements.
>>
>> Parmi ces envies de changement, il y avait, pour Composer mais aussi pour
>> git,
>> l'envie de plus s'ouvrir au plus large réseau de dev php notamment
>> en facilitant leur participation et l'intégration de leurs librairies et
>> patches.
>>
>
> Absolument.
> Mais si on veut proposer une PR faut-il absolument être inscrit ?
>

Oui... (en fait, il y a d'autres possibilités que d'être sur notre forge,
mais dans tous les cas il faut avoir l'autorisation de pousser vers le
dépôt... et comme en pratique personne ne maintient plusieurs ACL bah faut
être sur github pour faire une PR sur github et pareil pour les autres
forges)

Si non, alors le fonctionnement "zone" est toujours acceptable.
> Si oui, alors là c'est plus problématique mais on pourrait imaginer
> d'inscrire toute personne avec des droits de lecture uniquement et de ne
> réserver les droits d'écriture,
>

N'importe qui a déjà le droit de lecture (tant que le/la dépôt/organisation
est marqué/e comme public/que ...et dans ce cas, même pas besoin d'un
compte pour consulter en ligne --comme c'était/est avec le Trac-- ni pour
cloner localement le dépôt)

Sauf si tu voulais dire pouvoir s'inscrire sur le gitea sans être
automatiquement rattaché à l'équipe contrib (et donc avoir les droits sur
ses organisations...) C'est faisable mais sans intérêt (si ce n'est
d'offrir à tous ceux qui passent un espace pour des dépôts perso)

donc de contribution à SPIP que sur demande et acceptation de la charte
> comme sur le zone.
>

Voilà. Des changements oui, tant qu'on ne change pas ces deux points :
- accepter la charte (il faut être d'accord avec les idéaux défendus et les
règles de fonctionnent de la communauté à laquelle on veut participer)
- s'inscrire (ou être inscrit automatiquement si on accepte que les gens
s'inscrivent d'eulles même sur le gitea) à la liste (cf. point précédent,
puisque cela fait encore partir des règles de fonctionnement)

Après je dis ça mais il faudrait que Camille nous dise si c'est possible
> voire utile.
>
>
>>
>> Je sais pas si ça doit spécifiquement se manifester pour l'inscription
>> sur la zone,
>> mais en tout cas il faut pas se crisper sur les fonctionnements
>> antérieurs,
>> car c'est le moment de les interroger
>> et pas oublier de faire les bons choix, y compris de changements,
>> lorsque c'est le bon moment pour changer qqchose.
>>
>>
> Non je ne suis pas crispé, sur ce sujet du moins.
> Mais vu le nombre de personnes qui actionnent les manettes je pense qu'il
> est utile de prendre des précautions au début pour éviter de nettoyer
> ensuite quitte à ouvrir ensuite plus largement une fois qu'on est assuré du
> fonctionnement.
>
___
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] Inscription ouverte des contributeurices (choses à résoudre)

2020-02-07 Par sujet Gildas Cotomale
Le ven. 7 févr. 2020 09:31, chankalan a écrit :

>
>
> Le 07/02/2020 à 09:10, Eric Lupinacci a écrit :
> > Je suis d'avis de ne pas laisser les inscriptions ouvertes et de
> > rester dans le fonctionnement actuel de la zone car je ne vois pas
> > pour quelle raison le changement d'outil devrait impliquer un
> > changement de procédure :
> > - on demande une inscription en acceptant la charte qui doit être
> > accessible facilement à partir du site ou mieux comme on l'avait dit
> > il y a pas mal de temps via la barre SPIP.
> > - on obtient l'autorisation et on est inscrit à la liste spip-dev.
>

oui, +1
>

+1

>
>
___
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 SVN->GIT et historiques

2020-02-06 Par sujet Gildas Cotomale
Le jeu. 30 janv. 2020 10:33, Cerdic a écrit :

> Bonjour,
>
> suite à la campagne de migration des plugins et squelettes de spip-zone en
> SVN vers des projets git indépendants sur git.spip.net est apparu un
> soucis sur la reprise de l’historique :
>  * chaque fois que dans l’historique SVN on a déplacé un dossier xx
> vers un sous-dossier xx/trunk ou xx/branches/ cela casse
> l’historique dans la migration.
>

L'import porte bien sur toute l'arborescence xx ou ses sous-dossiers ?
Ou le script n'a pas autorisé le suivi des déplacements  ? (remarque, il
faut bien des limites et on paie la dette du mono-dépôt)


> On a donc de manière générale, des historiques partiels uniquement sur les
> projets git de https://git.spip.net/spip-contrib-squelettes et
> https://git.spip.net/spip-contrib-extensions
>
> On a donc fait une évaluation des dégats, et pour un certain nombre de
> projets on a repris l’historique sur SVN en remontant au moment du
> déplacement et en rejouant par dessus les commits qui avaient été fait par
> la suite.
>
> En gros on est repassé de xx/trunk vers xx quand il y avait moins
> d’une vingtaine de commits à reprendre.
>

Bien.

>
> Dans certains cas spéciaux pour lesquels les plugins avaient changé de
> répertoire au cours de leur vie on a fait une migration avec des réglages
> personalisés.
>

Bien.

>
> Cela concerne au total une 100aine de plugins et squelettes pour lesquels
> on a récupéré tout ou partie de l’historique.
>
>
> ## En l’état actuel :
>
> Pour les squelettes la situation est à peu près saine, car on a eu
> beaucoup moins de mouvement et les historiques sont plus simples
>

Bonne nouvelle !

>
> Pour les plugins :
>   - il n’y a a priori plus de plugins avec un historique court pour
> lesquels on peut reprendre facilement l’historique sur SVN pour migrer
>   - mais de manière générale on perd des queues d’historiques lointains
>

Loin jusqu'à ?

>
> ## Proposition de rustine
>
> Comme on a semble-t-il pas de solution simple pour récupérer ces
> historiques en git, et que perdre de l’histoire c’est toujours embêtant -
> sans parler du problème que cela peut poser dans la recherche de bugs, j’ai
> fait le test d’importer en git-svn les répertoires complets _squelettes_ et
> _plugins_ :
>
> https://github.com/Cerdic/spip-zone-squelettes
> https://github.com/Cerdic/spip-zone-plugins
>
> Je les ai mis sur mon compte le temps de tester mais on peut les migrer
> dans l’orga SPIP ensuite.
>

OK

>
> L’idée est de stocker ces 2 gros repos git qui font ~3Go au total sur
> github pour pouvoir aller y piocher dedans l’historique en cas de besoin.
> Cela nous permettra de fermer définitivement le SVN et le trac quand on le
> décidera (et d’ici là on peut resynchroniser de temps en temps ces 2
> projets archives)
>
> ## Ce qu’il faut faire pour valider la migration vers git
>
> Il faut maintenant que chacun aille voir les repositories avec lesquels il
> est habitué à travailler et qui comptent pour lui, et regarde si
> l’historique est satisfaisant ou non, et si les morceaux plus anciens
> manquants sont bien retrouvable via les 2 projets archives sur github
>
> Peut-être que malgré notre attention il reste des cas avec un historique
> tronqué qu’on peut réparer, je vous invite donc à nous faire remonter les
> cas les plus gênants pour vous qu’on regarde ça pour dire si oui ou non on
> peut faire mieux.
>

Je vais m'y mettre ce week-end (en croisant les doigts)

>
> Et une fois que tout le monde est OK et que personne ne crie plus au
> scandale, on peut décider que la nouvelle référence des projets est
> git.spip.net, le svn n’étant plus qu’un miroir temporaire le temps que
> tout le monde migre.
>
> C’est important de le noter car pour tous les plugins migrés dans trunk,
> les branches créées dans git ne seront pas créeés dans SVN, qui va donc
> petit à petit être de moins en moins complet.
>

Ouch...

>
> A vos remarques et retours,
>
>
>
___
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] Retours utilisation forge git

2020-02-06 Par sujet Gildas Cotomale
Le mar. 21 janv. 2020 15:00, cam.lafit a écrit :

> Yop
>
>
> >> Je sais pas si il faut faire un svn merge ou un svn copy depuis une
> ancienne revision ?
> >> Ce qui est quand même bizarre qu’il perde tout l’historique sur la
> copie, on a pas ce soucis avec un git svn clone par exemple, qui suit bien
> l’historique.
> >>
>

Je n'ai pas tout suivi ; j'espère que les choses se sont arrangées
finalement et que ce n'est pas un point bloquant à la migration vers un/une
autre vcs/forge.

Pour info le script n'utilise pas git-svn il n'y a rien de commun avec
> subgit si ce n'est l'objectif de traduire svn en git.
>

Intéressant, faudrait que je jette un oeil curieux...
Au début des échanges j'essayais de retrouver dans mes favoris ce que ça me
rappelait. Presqu'en vain (en plus le site
http://progetti.arstecnica.it/tailor/ n'existe plus... mais j'ai fini par
retrouver sa trace sur une forge de μ$) https://github.com/lelit/tailor !
C'est ça que me rappelait la discussion. Je n'ai toujours pas eu l'occasion
de le tester


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

Re: [spip-dev] Doc Git pour SPIP

2020-02-06 Par sujet Gildas Cotomale
Le ven. 24 janv. 2020 10:46, JLuc a écrit :

> Le 21/01/2020 à 09:40, Gildas Cotomale a écrit :
> > Les forges ont une fonctionnalité de recherche...
>
> Recherche d'une organisation, d'un utilisateur ou d'un dépot selon
> l'onglet où on se trouve,
> mais pas de recherche du source.
>

Si si (je réponds en retard, et j'ai vu que quelqu'un d'autre a mentionné
le fait que Gitea n'active pas cette fonctionnalité par défaut car
l'indexation a son coût)
Après, pour les autres forges, la recherche dans le code est limité au
dépôt (utile pour retrouver une fonction/variable/constante dans plusieurs
fichiers en mode Internet et non local) ce qui ne correspond pas à ton
besoin (si j'ai bien compris)
Il y a aussi, dans d'autres forges, la recherche par nom de fichier sur
l'ensemble d'une organisation (ou d'un auteur) je crois.


> > Sinon ça milite pour généraliser l'autodoc...
>
> C'est bien utile en effet,
> mais ça peut juste remplacer quelques cas d'usage d'une recherche locale
> sur la zone.
>

Ça donne les fichiers qui utilisent la référence si on a configuré cela
pour... (et il faut que tout soit vu comme un seul ensemble)
À minima on a juste les signatures (i.e. classses/méthodes/paramètres) par
projet, sans devoir aller fouiller le code. C'est utile si c'est juste pour
savoir rapidement comment utiliser  un bout de tuyauterie


> JL
>
> >
> > Le mar. 21 janv. 2020 09:31, JLuc a écrit :
> >
> > Le 20/01/2020 à 16:36, cam.lafit  a écrit :
> >  > Je réagis sur un point :
> > merci
> >  >> - Est-ce une bonne pratique de récupérer le code de tous les
> plugins de la zone comme avec svn ?
> >  >
> >  > Cela n'a JAMAIS été une bonne pratique avec svn. On a toujours
> dit :
> >  > "Merci de faire des checkout sur uniquement les plugins qui vous
> >  > intéressent et non sur la racine de la zone."
> >
> > Pas conseillé mais assez souvent utile :
> > Pour comprendre l'usage d'un pipeline ou d'une fonction, rien de tel
> qu'une recherche globale sur la zone pour étudier
> > le code qui l'utilise.
> >
> > Et parfois nécessaire :
> > des fonctions de nospam ont récemment été préfixées par nospam_
> > Pas plus tard qu'hier, la recherche sur le source de toute la zone
> m'a permis de trouver
> > les ocurences de ces fonctions et de corriger le plugin qui restait
> à corriger.
> > Quelle alternative sans tout avoir sur place ?
> >
> > 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

Re: [spip-dev] nomagic / no automagismes

2020-02-06 Par sujet Gildas Cotomale
Le mer. 5 févr. 2020 09:12, JLuc a écrit :

> Le 04/02/2020 à 06:38, JLuc a écrit :
> > Le 03/02/2020 à 21:40, JLuc a écrit :
> >> Parfois tout de même, le codeur innocent se prend les pieds dans les
> ficelles
> > ... des automagismes.
>
> Je remarque que dans tous les cas évoqués : environnement de rechargement
> ajax
> et autres exemples cités, le contexte d'environnement est automagiquement
> augmenté
> par des variables de l'url.
>


Vécu :-) Chaque fois je revois la copie et tente de simplifier (et
spécifier quand il y a risque de télescopage)


> Dans certains cas, ces variables introduites par effet de bord
> peuvent ne pas du tout concerner  la sémantique de cette noisette.
> - Cela multiplie inutilement les caches.
> Par exemple la noisette reloadée par ajax génère un cache qui ne servira
> plus jamais
> car les appels suivants de la page ne lui fourniront pas ces variables
> superfétatoires.
>

Très bon point.

- En cas d'interférence avec les arguments désirés, cela peut perturber le
> fonctionnement.
>
> Un de mes sites utilisant cachelab est peut être plus sensible à ces
> particularités
> puisque les caches ne sont pas recalculés à toute modification de la BDD.
>
> L'idée d'un plugin nomagic n'st pas de supprimer toute magie
> (puisque celle ci est le plus souvent bienvenue)
> mais de fournir des fonctions sans magie, préfixées par nomagic_ ,
> utilisables au besoin par les pipelines, codes de traitements de
> formulaires
> et autres devs maisons pour les besoins d'un plugin.
>

Ce serait bienvenue


> Indépendamment, je trouverais salutaire de documenter cela dans le code
> par exemple par un simple commentaire // Automagisme
> et mieux, permettre de débrayer localement débrayable.
> Par exemple avec une variable globale qui évite de devoir changer les
> signatures des fonctions.
> if ($GLOBALS['spip_automagisme']) {
> // ici le truc de magie
> }
> À la fois ça permet de débrayer (dans le code d'appel) et ça signale ces
> tricks.
>
> > Les autres exemples donnés ne concernent pas l'exemple ajax à l'origine
> de ce fil.
> >
> > Je me demande si d'autres personnes sont confrontées occasionnellement à
> ces difficultés,
> > auquel cas ça serait pas inutile de créer un plugin "nomagic" qui
> proposerait une copie des fonctions
> > et balises qui générent cette magie, préfixées par nomagic_ et SANS leur
> ajouts automagiques,
> > que le dev aurait loisir d'employer lorsque son plugin ou squelette ne
> supporte pas les automagismes de spip.
> >
> >> Par exemple je me retrouvais avec un id_document parasite au sortir
> d'une popin d'édition d'un document
> >> appelé dans la page d'un autre objet.
> >> La raison : $res['redirect'] = parametre_url($retour, $id_table_objet,
> $id);
> >> à la fin de formulaires_editer_objet_traiter
> >>
> >> Un autre jour, c'était #SELF qui ajoute les _POST aux arguments de
> l'url "réelle".
> >> J'avais du créer une balise doublon mais sans cet ajout qui gênait à un
> endroit.
> >>
> >> Et bien avant, je me heurtais à ce fonctionnement particulier de
> form_hidden
> >> https://core.spip.net/issues/3769 que je ne saurais plus décrire
> aujourd'hui
> >> mais mon code garde un doublon dépouillé de ce comportement parfois
> dérangeant.
> >>
> >> À chaque fois c'est très déconcertant.
> >> Et ça semble toujours en relation avec des globales.
> >>
> >> 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

Re: [spip-dev] Inscription ouverte des contributeurices (choses à résoudre)

2020-02-06 Par sujet Gildas Cotomale
(holà, beaucoup de retard dans ma pile à lire)

Le jeu. 23 janv. 2020 11:25, nicod_ a écrit :

> Le 23/01/2020 à 10:00, Charles Razack a écrit :
> > Il faudrait également un message d'accueil sur gitea ou un lien vers une
> > page expliquant ce fonctionnement. J'ai vu que nicod_ a déjà commencé à
> > personnaliser les templates, donc ça doit être possible.
>
> Ça l'est, il pourrait y avoir un message et des liens sur la page
> "Inscription" à la place du formulaire.
>

Pour moi, on change d'outil mais pas de mode de fonctionnement global. Du
coup, je serai plutôt d'avis que les comptes Git soient gérés comme les
comptes Svn : on s'inscrit d'abord sur la liste, on demande ensuite
l'accès... Bref, plus d'auto-inscription...


>
___
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] Coordonnées adresses et découpageS administratifS

2020-02-06 Par sujet Gildas Cotomale
Je prends le train en retard, et pas mal de messages à lire


> Hello,
> on a un problème avec la généricité de la table spip_adresses pour
> permettre à des gens de remplir des adresses correctes dans plusieurs pays
> (Chili, Japon…).
>
> ## Problème
>
> En effet, à la base il y avait juste un champ "region", mais c'était
> vraiment conçu de manière quasi franco-française. Ensuite, Touti a eu
> besoin d'un autre découpage pour un pays (le Canada) qui n'a pas de
> "régions". Après discussion, un terme *semi* générique a été proposé
> (etat_federe) pour les pays qui n'ont pas des régions mais vraiment des
> états.


Avant de voir apparaître cette version, j'avais l'habitude de surcharger
l'intitulé français en "Canton/Département/État" ...puis j'ai du
systématiquement cacher le nouveau champ tant que la migration n'était pas
faite (la région désignant alors un territoire autrement)

Sauf que ce n'est pas générique non plus, ça ne concerne que les pays
> fédéraux. Le Japon a juste des "préfectures" par exemple.
> https://www.mail-archive.com/spip-zone@rezo.net/msg40953.html
>
> Or un même site peut permettre aux gens *de plusieurs pays* de remplir
> leurs adresses (exemple concret : un site japonais où des gens peuvent
> s'inscrire qu'ils soient au Japon, aux États-Unis, etc). Il n'est donc pas
> possible de juste surcharger le label, puisque ça ne va marcher que pour un
> pays précis, alors que le site n'est pas mono-pays.
>

Il me semble que nombre de grands/gros groupes/sites fonctionnent ainsi...
Quand je passe l'interface de Google Contacts en français, il indique par
exemple "Code postal" & "Département" là où j'avais "Zip code" & "State" en
anglais, et je suis prêt à parier que si je bascule en japonais ça me dira
"Préfecture" et en Mandarin "Canton"... Et les différents locuteurs, à
l'heure d'Internet, savent faire la correspondance par rapport à leur
résidence : pour avoir travaillé avec d'autres pays francophones, j'ai bien
vu que les gens remplissaient les champs qui les concernent et qui ne porte
pas forcément le même nom chez eux... Je doute qu'il y ait une solution
ultime mais je peux me tromper.


> ## Solution dans la base
>
> Tout d'abord il faut savoir comment arriver à enregistrer les infos en
> base pour n'importe quel pays.
>
> On aimerait faire les moins de modifications possibles, en restant simple,
> le moins de champs.
>
> Il ne semble pas pertinent d'ajouter à chaque fois un champ différent pour
> chaque nouveau cas qu'on va rencontrer suivant tous les pays du monde,
> c'est infini et in-maintenable. Dans Google et OSM, il y a plutôt des
> champs génériques du type : "admin_area_1", "admin_area_2", ce qui
> signifique "découpage administratif de niveau X". Pour les adresses
> postales, à priori il n'y a jamais plus de 2 niveaux maximum en dehors de
> la voie/numéro et de la commune, et encore, même je crois qu'un seul suffit…
>
> L'idée serait donc peut-être d'avoir uniquement un champ "admin_1" et
> possiblement "admin_2" (à vérifier si utile), et de ne plus avoir ni
> "region" ni "etat_federe", qui de fait sont tous les deux le premier niveau
> administratif de plusieurs pays, donc devrait être dans "admin_1".
>

Nous sommes d'accord, il y a les champs qu'il faut. Juste un souci de
nommage (ou pas.)
Par contre, comme cité, "admin_area_1" se traduit par
"zone_administrative_niveau1" et la zone/aire en question est appelée
"subdivision" (ou "division" si on ne veut pas paraître trop
France-cemtrée) En tout cas, juste "admin" peut laisser croire qu'on veut
unne administrateurice pour quelque raison, ou certaines pourraient penser
qu'on demande de quelle administration (préfecture ou sous-préfecture)
illes dépendent.

Ce serait une nouvelle version majeure, donc pouvant casser des choses.
> Dans ce cas, des alias seraient codés quand même, pour que #REGION et
> #ETAT_FEDERE sortent la valeur de #ADMIN_1, afin de ne pas casser les
> squelettes.
>

Dans ce cas, go...


> À priori il n'y a pas de cas où les gens auraient à la fois "etat_federe"
> ET "region" remplis. Est-ce que vous pensez qu'on peut déplacer les valeurs
> dans un nouveau champ "admin_1" en mise à jour ? (si jamais les deux sont
> remplis ont fait quoi, on pourrait les fusionner avec une virgule entre eux
> ?)
>

Normalement ce sont deux concepts différents... Si les 2 sont remplis, ils
vont dans les niveaux 1 & 2, et c'est tout.


> ## Ergonomie
>
> Ensuite il faut résoudre le problème de l'interface de remplissage : le
> label doit être un truc humain.
>
> Pour les cas où le site est mono-pays, la config du plugin pourrait
> 1) avoir une valeur vraiment défaut en dur, dans tous les cas ("Région"
> car le plus courant pour celleux qui mettent à jour ? Car le plus
> d'utilisation en France pour l'instant ?)
>

Ça c'est parce-que historiquement là depuis plus longtemps non ? Et en
général, chez moi, les gens y foutaient leur département (sousdivision 1)
et non leur région (sousdivision 2)

2) permettre de configurer le 

Re: [spip-dev] repo pour gérer plusieurs git

2020-01-23 Par sujet Gildas Cotomale
Bonsoir la zone,

Dans un autre registre, je viens de tomber sur ceci qui répond à un besoin
que j'ai au boulot : https://github.com/gabrie30/ghorg
Gitea n'est pas (encore) pris en charge. Pour ceux qui ont un compte
Github, vous pouvez voter pour le ticket 56...
___
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] repo pour gérer plusieurs git

2020-01-22 Par sujet Gildas Cotomale
Le mar. 21 janv. 2020 00:00, chanka...@choc0.net  a
écrit :

> hello,
> je découvre repo comme expliqué ici :
> http://www.yoannsculo.fr/git-repo-outil-gestion-multiples-repositories-arracher-cheveux/
> on peut gérer plusieurs git,
>

C'est une bonne présentation (en français pour ne rien gâcher.) Certaines
remarques s'entendent mais le mode de fonctionnement se justifient... par
l'origine et le besoin (Google & Android) alors que la plupart des besoins
sont fort éloignés de là (on ne gère pas autant de dépôts et ils ne sont
surtout pas alignés en versions et branches etc. de plus, c'est fortement
lié à leurs outils/écosystèmes et flux de travail)
Dans la même ligne, https://github.com/TankerHQ/tsrc (évoqué par Km dans un
autre fil), peut être considéré comme son évolution (et se présente comme
tel dans la faq) https://github.com/TankerHQ/tsrc/blob/master/docs/faq.md
Ça correspond avant tout à leur organisation (mode de fonctionnement),
tous/toutes les outils/solutions ne pouvant s'appliquer à toutes les
organisations :-) Ceci dit, il m'a l'air très bien (je ne l'ai pas encore
testé)


par exemple spip + les plugins-dist + squelettes + ce qu'on veut
> comme on peut choisir les dossiers de destination on peut aussi sortir des
> plugins du dossier plugins-dist et les mettre dans plugins si on veut les
> utiliser sans obligation
> avec ce manifest j'ai mis 4 plugins-dist dans plugins/dist et ça m'a l'air
> de fonctionner
> https://framagit.org/chankalan/spip-repo/blob/master/default.xml
>
> le site public devrait bien afficher de grosses erreurs à certains
> endroits, pour prouver que ça marche...
>
> dans l'idée, la commande pour mettre à jour tout d'un coup :
> repo sync
>
> Je sais pas encore si c'est bien au final, et si on peut gérer une
> distribution personnalisée, mais je me suis bien amusé avec repo ;o)
>

Ça me semble bien à première vue :-)
___
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] repo pour gérer plusieurs git

2020-01-22 Par sujet Gildas Cotomale
Le mer. 22 janv. 2020 09:51, chankalan a écrit :

> hello
>
> Le 21/01/2020 à 08:58, Gildas Cotomale a écrit :
>
> :-) Oui, c'est dans la même veine que "mr" <https://linux.die.net/man/1/mr>
> Je l'ai (repo) découvert il y a moins d'un semestre. Mon besoin est pour de
> la conf versionnnée qui est maintenant éclaté dans différents dépôts <
> https://myrepos.branchable.com> :-)
>
> a oui, je trouve que c'est même beaucoup mieux, merci !
>

Je ne l'ai pas précisé, mais ce sont deux outils (scripts) différents qui
utilisent la même commande "mr" et le même mode de fonctionnement. Le
premier, en PERL, a un miroir (officieux je crois) sur
https://github.com/matthewmccullough/mr

Dans le même esprit, ont fleuri (dans d'autres langages, et on peut s'en
inspirer pour faire avec PHP si le coeur vous en dit) :
- http://mixu.net/gr/ (en NodeJS)
- http://fabioz.github.io/mu-repo (en Python)
- http://gitslave.sf.net/
- https://github.com/reednj/git-status-all (en Ruby)
- https://github.com/nosarthur/gita )en Python 3)
- https://streakycobra.github.io/gws/ (en BASH)
- etc ?

Je les ai pas tous testé.

>
>
___
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] « https://****.**/ » dangereux ou pas?

2020-01-22 Par sujet Gildas Cotomale
Attention aux liens qu'on partage publiquement (l'alphabet cyrillique,
c'est pas sympa pour nous autres utilisateurs d'alphabet latin où du
contenu non francophone est déjà limite) :-)
Je suis tombé sur https://www.woorank.com/en/www/7ooo.ru et
https://7siters.com/domen/7ooo.ru/ d'où je déduis que c'est un site/réseau
d'échanges axé photos (le bon coin ou insta le sont, tandis que redit ou
seenthis le sont pas) Je ne devine pas le public ni la thématique, mais ça
brasse beaucoup de liens et de visiteurs (dont certains atterrissent sur
ton site)
Je te conseille de rentrer le lien dans un moteur de traduction de pages
comme http://itools.com/tool/google-translate-web-page-translator entre
autres https://www.lexicool.com/translate-web-page.asp
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Doc Git pour SPIP

2020-01-21 Par sujet Gildas Cotomale
Les forges ont une fonctionnalité de recherche... Par contre, il faut être
connecté et je n'ai pas eu l'occasion de tester ton cas (sur
Gitea/Github/Gitlab/Framagit/etc, je n'ai essayé que la recherche dans un
dépôt, et ça peut être sur les noms de fichiers comme sur leur contenu)
Sinon ça milite pour généraliser l'autodoc...

Le mar. 21 janv. 2020 09:31, JLuc  a écrit :

> Le 20/01/2020 à 16:36, cam.la...@azerttyu.net a écrit :
> > Je réagis sur un point :
> merci
> >> - Est-ce une bonne pratique de récupérer le code de tous les plugins de
> la zone comme avec svn ?
> >
> > Cela n'a JAMAIS été une bonne pratique avec svn. On a toujours dit :
> > "Merci de faire des checkout sur uniquement les plugins qui vous
> > intéressent et non sur la racine de la zone."
>
> Pas conseillé mais assez souvent utile :
> Pour comprendre l'usage d'un pipeline ou d'une fonction, rien de tel
> qu'une recherche globale sur la zone pour étudier
> le code qui l'utilise.
>
> Et parfois nécessaire :
> des fonctions de nospam ont récemment été préfixées par nospam_
> Pas plus tard qu'hier, la recherche sur le source de toute la zone m'a
> permis de trouver
> les ocurences de ces fonctions et de corriger le plugin qui restait à
> corriger.
> Quelle alternative sans tout avoir sur place ?
>
> 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] repo pour gérer plusieurs git

2020-01-21 Par sujet Gildas Cotomale
Le mar. 21 janv. 2020 00:00, chankalan a demandé :

>
> Certains connaissent déjà ?
>

:-) Oui, c'est dans la même veine que "mr" 
Je l'ai (repo) découvert il y a moins d'un semestre. Mon besoin est pour de
la conf versionnnée qui est maintenant éclaté dans différents dépôts <
https://myrepos.branchable.com> :-)



>
>
___
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] Organisation de la forge Git de SPIP

2020-01-19 Par sujet Gildas Cotomale
Le dim. 19 janv. 2020 21:50, Eric Lupinacci a écrit :

> Yop,
>
> Le dim. 19 janv. 2020 à 21:44, Gildas Cotomale a écrit :
>
>>
>>> Juste un petit détail, galaxie ne serait pas mieux nommée en
>>> spip-galaxie, pour être cohérents ?
>>>
>>
>> Moi c'est plutôt "spip" tout court qui m'intrigue et que je verrai bien
>> en "spip-core" par exemple.
>>
>>
> spip contient à la fois le noyau (donc le core) et les plugins-dist. C'est
> pourquoi on a préféré le nommer spip tout court.
>

Ou "spip-dist" ? Mais bon, dans un peu temps ça choquera plus (ou moins par
habitude)

J'ai proposé galaxie pour que justement ça se distingue de spip et
> spip-contrib-.
> En fait, si vous lisez le mail on a trois grandes familles d'organisation
> qui correspondent à trois types d'accès différents :
> - spip : la team SPIP uniquement
> - galaxie : la team SPIP + quelques contributeurs
> - spip-contrib- : l'ensemble des contributeurs de la zone regroupés
> dans la team contrib.
>
> Donc j'ai évité spip-galaxie pour ne pas confondre avec spip-contrib-xxx.
>

Ça fait sens. En y repensant, je me demande si à l'inverse les
"spip-contrib-xxx" n'auraient pas du être tout juste "contrib-xxx" :-)


> ++
> 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] Organisation de la forge Git de SPIP

2020-01-19 Par sujet Gildas Cotomale
Le dim. 19 janv. 2020 19:29, Eric Lupinacci a écrit :

> Hello,
>
> C'est un jour important pour le développement de SPIP car la migration de
> la forge SPIP de SVN (autrement dit la Zone) vers Git (forge Gitea ou notre
> nouvelle Zone) a clairement débutée.
> Une première étape est finalisée (où se termine au moment où j'écris ce
> mail, le script n'étant pas totalement fini), je vais expliquer en quoi
> elle consiste.
>
> *Etape 1 : organisations et plugins 3.2*
> Cette première étape nous a donné l'occasion d'échanges multiples quant
> aux nombres et aux noms des organisations que nous espérons compréhensibles
> . Il a été décidé que la nouvelle forge rappellerait l'organisation de la
> Zone SVN pour faciliter l'apprentissage.
>

Merci, Merci, Merci.
Je sais qu'il y avait quelques réticences (ou plutôt un désire d'en
profiter pour améliorer ? mais il se trouve que l'organisation actuelle est
le résultat de réorganisations successives et donne satisfaction à la
majorité) mais cela va aider/accélérer la transition, je pense.

De fait nous avons choisi de créer les organisations dont la liste est
> consultable à l'adresse https://git.spip.net/explore/organizations, à
> savoir :
> - spip
> - spip-contrib-extensions
> - spip-contrib-squelettes
> - spip-contrib-themes
> - spip-contrib-outils
> - galaxie
>
> L'organisation "spip" contient le noyau de spip et l'ensemble des
> plugins-dist. Elle est publique (donc accessible en lecture pour tout le
> monde) mais accessible en écriture uniquement par une *équipe nommée
> "SPIP"* qui correspond exactement à l'équipe noyau actuelle.
> Il sera possible pour des développeurs externes à la team SPIP de proposer
> des modifications en utilisant le processus de Push Request (PR) qui
> remplace avantageusement le patch de SVN.
>
> L'organisation "galaxie" contient l'ensemble des sites de la galaxie. Elle
> est publique mais accessible en écriture uniquement par une *équipe
> nommée "galaxie"* qui correspond à l'équipe noyau de SPIP et de quelques
> contributeurs additionnels assurant le développement de certains sites.
>
> Enfin, les organisations spip-contrib- contiennent les contributions
> accessibles en écriture à tous les inscrits sur la forge qui ont été
> regroupés dans une *équipe nommée "contrib"* (a priori la même liste que
> sur la Zone aux erreurs près). On distingue donc :
> - spip-contrib-extensions : qui contient l'ensemble des contributions
> fonctionnelles (sou forme de plugin ou autre) et qui proviennent des
> répertoires _plugins_ (principalement) et _grenier_ (à voir).
> - spip-contrib-squelettes : qui contient l'ensemble des contributions de
> squelettes (sou forme de plugin ou autre) qui proviennent de _squelettes_
> - spip-contrib-themes : qui contient l'ensemble des contributions de
> thèmes au sens de SPIP qui proviennent de _themes_
> - spip-contrib-outils : qui contient les outils connexes à SPIP qui
> proviennent de _outils_ et _dev_
> Pour l'instant toute la zone n'a pas encore été transférée, le choix s'est
> portée en premier lieu sur les plugins compatibles SPIP 3.2. Certains
> (liste à disposition) n'ont pas été importés car leur organisation sur le
> Zone nécessite quelques adaptations ou discussions. Par exemples, il reste
> à discuter comment on aplatit la structure actuelle de _themes_
> (nomenclature à décider).
> spip-contrib-extensions et spip-contrib-squelettes sont quand à elles bien
> peuplées.
>

Avec tout ça on garde le principe du "qui" donc double bénef :-)


> Pour le moment, la Zone continue d'être accessible en écriture (commit) de
> la même façon que la forge Git.
> Un outil de synchronisation assure la cohérence bidirectionnelle.
> Cette synchronisation va être assurée encore jusqu'à fin mars pour les
> organisations spip-contrib-.
> A partir d'avril seule la forge Git permettra de contribuer aux
> organisations spip-contrib-, il faudra donc d'ici là switcher les
> environnements de développement sous Git.
>

C'est un peu dommage d'arrêter la synchronisation quand on peut avoir le
meilleur des deux mondes. Espérons que tout le monde aura eu le temps de
migrer son "toolchain" (je pense aux non developpeurs avec l'infra qui
récupère du Subversion)

J'aurais vu plutôt l'arrêt de l'accès en écriture svn et la synchro
(unidirectionnelle) qui se fait en prenant git comme référence. Mais bon.

Pour cela, une documentation sera proposée pour expliquer à tous comment
> effectuer la migration des environnements de développement.
>
___
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] Organisation de la forge Git de SPIP

2020-01-19 Par sujet Gildas Cotomale
Le dim. 19 janv. 2020 21:03, nicod_  a écrit :

> Merci à ceux qui ont travaillé sur cette grosse migration, je crois
> qu'on a franchi une étape cette fois \o/
>

Je plussois.
Un dimanche qui fera date dans l'année 2020 !


> Juste un petit détail, galaxie ne serait pas mieux nommée en
> spip-galaxie, pour être cohérents ?
>

Moi c'est plutôt "spip" tout court qui m'intrigue et que je verrai bien en
"spip-core" par exemple.
___
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] Nombre et noms des organisations Git

2020-01-18 Par sujet Gildas Cotomale
Le sam. 18 janv. 2020 17:34, cam.lafit a écrit :

> Bonjour
>

Ciao la zona

>
> Une maintenance de la forge git va démarrer. Elle va mettre en place
> une nouvelle structure des organisations.
> A tester sous peu.
>

Merci pour le travail précieux Camille. Hâte de voir le résultat. :-)

>
> En attendant il ne sera plus possible de comitter via git.
>
> Km
>
___
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] installation plugin mes_favoris (3.0.2) échoue

2020-01-02 Par sujet Gildas Cotomale
Le jeu. 2 janv. 2020 09:35, Jacques B a écrit :

> OK
> J'ai appliqué la modif de
> https://zone.spip.net/trac/spip-zone/changeset/119584/spip-zone
> localement, désactivé-réactivé et installation OK
>

Est-ce fourbe ? :-)

(j'aurais presque pu le voir moi même ^^)
>
> Merci !
> Jacques
>
> Le 02/01/2020 à 09:18, Cerdic a écrit :
>
> Je regarde et corrigé, sorry !
>
> De rien, et merci surtout pour la grande réactivité :-)
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip

Re: [spip-dev] installation plugin mes_favoris (3.0.2) échoue

2020-01-02 Par sujet Gildas Cotomale
Le jeu. 2 janv. 2020 09:05, Jacque B a écrit :

> Bonjour,
> J'ai l'erreur en local mais j'ai également fait l'essai en ligne avec les
> mêmes erreurs.
>
> J'utilise mysql 5-7 et php 7.2 (en local avec Laragon)
> En local je viens de supprimer le plugin et de réinstaller via svp,
> l'erreur se reproduit.
> J'avais vidé le fichier mysql.log et aucune erreur ne s'y est ajoutée, par
> contre dans spip.log j'ai cette erreur :
> 2020-01-02 07:52:09 ::1 (pid 8300) :Pri:ERREUR: Erreur mysql 1146
> 2020-01-02 07:52:09 ::1 (pid 8300) :Pri:!INFO: trouver_table: table
> inconnue '' 'spip_plugins_liens'
> 2020-01-02 07:52:25 ::1 (pid 8300) :Pri:cf maj.log
> et dans maj.log j'ai
> 2020-01-02 07:52:21 ::1 (pid 8300) :Pri:ERREUR: maj 0 fonction maj_table
> non definie
> 2020-01-02 07:52:25 ::1 (pid 8300) :Pri:ERREUR: maj 0 fonction maj_table
> non definie
>

OK un souci dans le fichier de déclaration qui fait que la base n'est même
pas appelée pour créer les tables. (d'où rien dans sql.log)


> Jacques
>
> Le 02/01/2020 à 08:23, Gildas Cotomale a écrit :
>
> Le jeu. 2 janv. 2020 07:57, Jacques B a écrit :
>
>> Oups, j'ai oublié un message d'erreur :
>> "L’installation du plugin « Mes Favoris » (version : 3.0.2) a échoué
>> MAJ init
>> L’opération a échoué. init 1"
>>
>
>
> Bonjours Jacques,
>
> Il se peut que ce soit une erreur temporaire sur ton serveur au mauvais
> moment (du coup ça échoue à ce moment là, mais passe mieux le moment
> d'après.)
> À la vue de l'erreur, je soupçonne une erreur au niveau de la base de
> données lors de la création des tables. Peux tu voir ce que tu as dans les
> logs sql à l'heure de l'erreur ? Et aussi quel sgbd utilises tu ?
> Ceci dit, je n'ai pas souvenir que la structure ait changée entre ces deux
> versions
>
> Jacques
>>
>> Le 02/01/2020 à 07:55, Jacques B a écrit :
>> > Bonjour,
>> > J'ai voulu essayer le plugin mes favoris en local sur un SPIP 3.2.7 :
>> > l'installation ne se fait pas.
>> > Messages  :
>> > "Actions réalisées
>> > Le téléchargement et l’activation du plugin « Mes Favoris »
>> > (version : 3.0.2) se sont correctement déroulés
>> > L’installation du plugin « Mes Favoris » (version : 3.0.2) a échoué"
>> > J'ai essayé avec une version plus ancienne (2.5.6) et l'installation a
>> > fonctionné puis mise à jour OK en 3.0.2.
>> >
>> > Merci,
>> > Jacques
>> > ___
>> > liste: https://listes.rezo.net/mailman/listinfo/spip-dev
>> > doc: http://www.spip.net/
>> > dev: http://trac.rezo.net/trac/spip/
>> > irc://irc.freenode.net/spip
>>
>> ___
>> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
>> doc: http://www.spip.net/
>> dev: http://trac.rezo.net/trac/spip/
>> irc://irc.freenode.net/spip
>
>
>
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip

Re: [spip-dev] installation plugin mes_favoris (3.0.2) échoue

2020-01-01 Par sujet Gildas Cotomale
Le jeu. 2 janv. 2020 07:57, Jacques B a écrit :

> Oups, j'ai oublié un message d'erreur :
> "L’installation du plugin « Mes Favoris » (version : 3.0.2) a échoué
> MAJ init
> L’opération a échoué. init 1"
>


Bonjours Jacques,

Il se peut que ce soit une erreur temporaire sur ton serveur au mauvais
moment (du coup ça échoue à ce moment là, mais passe mieux le moment
d'après.)
À la vue de l'erreur, je soupçonne une erreur au niveau de la base de
données lors de la création des tables. Peux tu voir ce que tu as dans les
logs sql à l'heure de l'erreur ? Et aussi quel sgbd utilises tu ?
Ceci dit, je n'ai pas souvenir que la structure ait changée entre ces deux
versions

Jacques
>
> Le 02/01/2020 à 07:55, Jacques B a écrit :
> > Bonjour,
> > J'ai voulu essayer le plugin mes favoris en local sur un SPIP 3.2.7 :
> > l'installation ne se fait pas.
> > Messages  :
> > "Actions réalisées
> > Le téléchargement et l’activation du plugin « Mes Favoris »
> > (version : 3.0.2) se sont correctement déroulés
> > L’installation du plugin « Mes Favoris » (version : 3.0.2) a échoué"
> > J'ai essayé avec une version plus ancienne (2.5.6) et l'installation a
> > fonctionné puis mise à jour OK en 3.0.2.
> >
> > Merci,
> > Jacques
> > ___
> > liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> > doc: http://www.spip.net/
> > dev: http://trac.rezo.net/trac/spip/
> > irc://irc.freenode.net/spip
>
> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: http://www.spip.net/
> dev: http://trac.rezo.net/trac/spip/
> irc://irc.freenode.net/spip
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip

Re: [spip-dev] [SPIP Zone] Fusionner les flux de plugins externals et zone

2020-01-01 Par sujet Gildas Cotomale
Le jeu. 2 janv. 2020 07:26, teamspipfactory@ a écrit :

> Hu a vous lire  me viens des questions
>
> Comment en tant qu'utilisateur de spip, savoir ou trouver les plugins et
>

Depuis un bon bout de temps, une référence : https://plugins.spip.net

si ils sont en dehors de l'officiel, comment les mettre en œuvre sur un
> site et ou trouver la Doc
>


Sur chaque plugin on a un bloc d'informations qui donne : un résumé de ce
que fait le plugin, le lien vers la page de documentation (si celle ci
existe), la ligne "hébergée par" qui indique le dépôt, la possibilité de
voir tout le paquet.xml (pour les autres informations non mises en forme
dans ce bloc)


>
> mes deux sous en lisant vos réflexions ...
>
>
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip

Re: [spip-dev] [SPIP Zone] Fusionner les flux de plugins externals et zone

2020-01-01 Par sujet Gildas Cotomale
En effet, avec tout le contexte tu ne n'extrapole pas les mots de Rasta (et
je m'excuse de n'avoir pas relu tout le fil avant de répondre.) Ceci dit,
je crois bien (à la relecture) que c'est bien l'aspect communauté SPIP qui
se porterait garant versus maintenus par une personne ou un groupe isolé
(confiance ou pas, ce point étant un des nombreux aspects que peut soulever
la question de rouler solo)

Pour en revenir à la question, je fais justement le parallèle parce-que je
trouve la gestion de SPIP avec SVP tout aussi avancé que la gestion de
paquets sous Linux (les dernières fois que j'ai regardé les autres CMS/SGC
ils faisaient pas aussi bien) d'une part et qu'ils ont cette problématique
d'autre part.
Il se trouve que techniquement on a déjà tout ce qu'il faut et que le débat
est vraiment idéologique (les dépôts étant logiques et non physiques, rien
n'empêche certains paquets hors zone de ne pas être déclaré en dépôt
externe mais plutôt le contraire) Et là dessus, je pense qu'il n'y a rien à
changer (ce qui n'engage que moi bien entendu) Ceci ne remet pas du tout en
cause le principe de plugins (je ne militais pas pour avoir des couteux
suisses mais juste pour ne pas mélanger ce qui est sous le regard de la
zone avec ce qui passe sous son radar.)

Bonne année à tous au fait (j'avais envoyé mon précédent message avant de
pouvoir rajouter ne serait-ce que les salutations) Et désolé de répondre un
peu n'importe comment (client gmail sur le phone pas terrible)




Le mer. 1 janv. 2020 21:49, Bruno Bergot  a écrit :

> Hop,
>
> Le 01/01/2020 à 21:05, Gildas Cotomale a écrit :
> >>
> >> Quid des plugins de tetue qui sont maintenant sur github ? On ne peut
> plus
> >> leur faire confiance ? Il ne faut plus les référencer en nécessite ? Et
> il
> >> n'y a pas que les plugins de tetue, on prive aussi les users de plugins
> >> sympas comme mastodon, markdown & tri_par_rubrique cf :
> >>
> >> https://plugins.spip.net/spip.php?page=plugins_depot=18
> >
> >
> > Il ne faut pas faire dire ce qui n'est pas dit... Ce n'est pas maintenu
> et
> > garanti par la communauté. Point. Cela ne remet pas en question la
> qualité
> > de des plugins et ne dit rien de la confiance ou pas en leurs auteures.
> >
>
> J'avais volontairement éludé une partie de citation, mais puisqu'elle
> semble nécessaire :
>
> Le 08/11/2019 à 10:57, RastaPopoulos a écrit :
> >
> > Je suis assez d'accord… SAUF QUE au départ externals, c'était pour les
> > plugins qui ne font PAS PARTIS de la zone démocratique à plusieurs, et
> > qui donc sont maintenus par une unique personne à part. Et donc qui
> > peuvent possiblement être considérés comme moins de confiance PAR DÉFAUT
> ...
>
> > Utiliser le moins possible des dépendances externes.
>
> Non, c'est clairement l'inverse de ce qu'on souhaite depuis des années :
> on fait tout pour avoir un plugin unique par fonctionnalité, et non des
> plugins fourre-tout, ce qui mène forcément vers l'interdépendance d'un
> plugin envers les autres.
>
> > Quand on se sent obligé de le faire, clairement mentionner dans la doc
> > qu'il faut ajouter un dépôt et lequel et comment.
> >
>
> Le point est bien là, mais si on peut éviter un "RTFM" (qu'on n'utilise
> jamais chez SPIP) et privilégier une solution simple et directe pour
> l'utilisateur, je pense que c'est "mieux".
>
> > Quand j'ai besoin d'un paquet qui n'est pas dans les dépôts officiels
> d'une
> > distribution Linux, j'ajoute le dit dépôt. Il m'est déjà arrivé d'avoir
> des
> > dépendances de paquets dans les dépôts officiels qui n'y soient pas
> > (normalement tout est fait pour que cela ne se produise pas, mais
> quelques
> > rares fois ça arrive avec un backport) et on fait la manip nécessaire.
> >
>
> Notre gestion des dépendances n'est pas encore assez aboutie pour la
> comparer à celle des paquets d'une distrib linux...
>
> PS : merci de ne plus écrire à spip-zone, cette liste est fermée,
> préfère spip-dev.
>
> ++
> b_b
>
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip

Re: [spip-dev] [SPIP Zone] Fusionner les flux de plugins externals et zone

2020-01-01 Par sujet Gildas Cotomale
> >
> > Je ne suis donc pas favorable à ce que SPIP fournisse ces plugins par
> > défaut à tout le monde, car ça engagerait notre responsabilité
> > collective sur du code qu'on ne maitrise pas (ou beaucoup moins).
> >
>
> Quid des plugins de tetue qui sont maintenant sur github ? On ne peut plus
> leur faire confiance ? Il ne faut plus les référencer en nécessite ? Et il
> n'y a pas que les plugins de tetue, on prive aussi les users de plugins
> sympas comme mastodon, markdown & tri_par_rubrique cf :
>
> https://plugins.spip.net/spip.php?page=plugins_depot=18


Il ne faut pas faire dire ce qui n'est pas dit... Ce n'est pas maintenu et
garanti par la communauté. Point. Cela ne remet pas en question la qualité
de des plugins et ne dit rien de la confiance ou pas en leurs auteures.


>
> En attendant qu'une super solution technique (ou non) voit le jour, quelle
> solution simple peut-on envisager afin de faciliter la vie des users ?
>

Utiliser le moins possible des dépendances externes.
Quand on se sent obligé de le faire, clairement mentionner dans la doc
qu'il faut ajouter un dépôt et lequel et comment.

Quand j'ai besoin d'un paquet qui n'est pas dans les dépôts officiels d'une
distribution Linux, j'ajoute le dit dépôt. Il m'est déjà arrivé d'avoir des
dépendances de paquets dans les dépôts officiels qui n'y soient pas
(normalement tout est fait pour que cela ne se produise pas, mais quelques
rares fois ça arrive avec un backport) et on fait la manip nécessaire.


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

Re: [spip-dev] Nombre et noms des organisations Git

2019-12-22 Par sujet Gildas Cotomale
Le sam. 21 déc. 2019 17:03, Eric Lupinacci a écrit :

> Yop,
>
>
> Le sam. 21 déc. 2019 à 16:35, RastaPopoulos a écrit :
>
>> Je ne sais pas pour quelle utilisation précise, mais si c'est pour des
>> automatismes je pense que c'est une mauvaise idée de se baser sur l'API
>> d'une forge précise pour construire des outils pérennes.
>>
>
+1


>> L'API peut servir bien sûr pour récupérer des choses en terme de Git,
>> mais ensuite en terme de typologie et de quoi faire avec quel dépôt, on
>> doit se baser sur leur contenu réel et de toute façon la majorité du temps
>> sur de l'explicite. Les projets à empaqueter par ex, je pense que ça doit
>> rester une déclaration voulue, donc savoir faire un listing automatique
>> n'avance pas à grand chose.
>>
>
> Déjà je ne vois pas pourquoi sous une forge Git il faudrait conserver un
> empaqueteur.
> Le zip est déjà dispo.
>

Il me semble y avoir une petite confusion. Quasiment toutes les forges
offrent la possibilité de générer une archive d'une version donnée (on a
cette possibilité aussi avec Trac et ça n'a rien à voir avec le fait d'être
Git ou pas)

Certaines ont en effet un système de distribution avancé : Sourceforge
offre une zone de téléchargement pour chaque projet ; Github génère une
page listant toutes les "release"s publiées avec leurs archives ; etc.
Les mécanismes diffèrent d'une forge à une autre.

Ce qu'il faudrait toujours c'est un référentiel des plugins (ie le XML de
> SVP) pour construire le site associé.
>
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip

Re: [spip-dev] Nombre et noms des organisations Git

2019-12-22 Par sujet Gildas Cotomale
Le sam. 21 déc. 2019 16:35, RastaPopoulos a écrit :

Sinon, sans hacker le principe des orgas qui est de dire "qui participe"


Attention que le terme "organization" a été retenu par Github et d'autres
parce-que assez courant et générique pour désigner des groupements de
personnes (entreprises ou associations ou parfois
équipe/département/service) et que leur modèle économique économique se
base sur le fait d'avoir/distinguer des comptes/espaces individuels ou de
groupes/communautés (offre gratuit contre offres payants) Dans le principe
c'est juste un regroupement de dépôts comme dans un dossier. Cela n'a pas
de lien direct avec le "qui contribue", et tu pourras remarquer que sur tes
dépôts perso github tu peux associer des contribuables... Et les membres
des orga peuvent avoir des accès complètement différents (y compris ne pas
être mis à contribution sur un dépôt)


, il y a dans toutes les forges (j'ai vérifié) le système de tags/topics
> pour chaque description de dépôt. Qui est multiple donc, en plus. Dans la
> même orga "spip-contrib", tu peux très bien dire que tel dépôt est
> #squelette ET #plugin (= un jeu de squelette distribué sous forme technique
> de plugin). Ce qui permet alors pour tout besoin d'automatisme de récupérer
> "tous les squelettes, "tous les thèmes", "tous les projets en plugins",
> etc. Tout cela en ne maintenant qu'une seule liste de contributeurices de
> la même orga.
>
>
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip

Re: [spip-dev] Saisies input type=number

2019-12-22 Par sujet Gildas Cotomale
Le sam. 21 déc. 2019 17:28, pierre laszczak a écrit :

> Oui et non, le soucis c est qu en CSS le type number et trop pénible a
> décorer suivant le navigateur. Parfois j utilise un input text pour la
> saisie d un  nombre a cause des petits boutons d
> incrémentation/decrementation qui sont vraiment pénible à décorer. Ex: les
> même version de Firefox sous Linux et Windows ne réagissent pas de la même
> façon.
>

Salut la liste

Je suis plutôt favorable à l'usage des types plus précis et sémantiques
pour ma part ; et donc suis d'accord avec la proposition initiale de Maïeul.

Je n'ai pas de soucis avec la stylisation des champs, et je n'ai jamais
besoin de retoucher aux boutons de ..crémentation fort utiles et qui
semblent en effet casse gueule à cibler (C'est dommage de s'acharner à les
virer alors que ça apporte plus d'aide aux usagers...)
- https://stackoverflow.com/questions/26024771/styling-a-input-type-number
- https://css-tricks.com/numeric-inputs-a-comparison-of-browser-defaults/
- https://www.ctrl.blog/entry/html5-input-number-localization.html

Que Firefox présente des différences d'un système d'exploitation à un autre
est normal et a toujours été assumé : ça s'intègre au maximum à la
plateforme, et je parie qu'il y a de subtiles différences d'un bureau à un
autre.



> Le sam. 21 déc. 2019 à 16:51, Maïeul Rouquette a écrit :
>
>> oui, oui, ma question était plutot sur l'application automatique de ces
>> paramètres coté client en html5 a partir de quelque chose censé être au
>> départ une vérif coté serveur
>>
>> Le samedi 21 décembre 2019 à 16:41 +0100, Gildas Cotomale a écrit :
>> > Il n'est pas du tout déconnant d'avoir ces paramètres ...pour peu
>> > qu'on soit en HTML5 (dans les autres cas de doctype on devrait avoir
>> > type="text" pour ne pas avoir de page non valide)
>> >
>> > Maintenant, ceci n'empêche et ne se substitue pas à la vérification
>> > côté serveur...
>> > Il faut voir ce qui est fait côté client comme un plus pouvant ne pas
>> > être disponible (tout comme un navigateur peut ne pas supporter JS, il
>> > peut ne pas connaître cette DTD)
>> >
>> >
>>
> <http://irc.freenode.net/spip>
>>
>
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip

Re: [spip-dev] Saisies input type=number

2019-12-21 Par sujet Gildas Cotomale
Il n'est pas du tout déconnant d'avoir ces paramètres ...pour peu qu'on
soit en HTML5 (dans les autres cas de doctype on devrait avoir type="text"
pour ne pas avoir de page non valide)

Maintenant, ceci n'empêche et ne se substitue pas à la vérification côté
serveur...
Il faut voir ce qui est fait côté client comme un plus pouvant ne pas être
disponible (tout comme un navigateur peut ne pas supporter JS, il peut ne
pas connaître cette DTD)


Le sam. 21 déc. 2019 16:21, Maïeul  a écrit :

> Holla,
>
> le html5 permet une saisie de type number en précisant les nombre max et
> min.
>
> Cela correspond peu ou prou à ce qu'on propose en PHP en terme de
> vérificaiton d'une saisies de type input.
>
> Du coup je me dis que si une personne demande cela lorsqu'on construit
> une saisie dans Formidable (ou tout autre constructeur de formulaire),
> ce serait cohérent de modifier automatiquement le html5 pour appliquer
> type="number" "max" et "min".
>
> En meme temps je trouverais bizarre de faire dépendre cela d'une
> vérification qu'on configure en yaml/php mais pas forcéement en
> squelette brut
>
> Qu'en pensez vous ?
>
> Maïeul
>
>
>
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip

Re: [spip-dev] Gitea : pouvoir commenter un commit

2019-12-21 Par sujet Gildas Cotomale
Le jeu. 19 déc. 2019 13:54, Bruno Bergot a écrit :

> Hop,
>
> Le 19/12/2019 à 13:32, Maïeul a écrit :
> > Holla,
> >
> > sur gitlab/github, il est possible de commenter un commit.
> > Sur git.spip.net, je n'ai pas pu commenter ce commit
> >
>
[...]

>
> > 1. Est-ce une limite de gitea, ou une configuration?
> > 2. Si configuration, pourrait-on la changer ?
>
> Option 1, on peut commenter les parties d'une PR, mais pas un commit cf :
>
> https://github.com/go-gitea/gitea/issues/4898
>
>
 Pas génial dans le principe de base (et devrait être indiqué dans leur
page de comparaison de fonctionnalités)
Pour nous c'est sans impact ; les commits devant être annoncés et discutés
sur une liste...
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip

Re: [spip-dev] Outil checkout

2019-12-18 Par sujet Gildas Cotomale
Le mer. 18 déc. 2019 12:33, cam.la...@azerttyu.net 
a écrit :

> Bonjour
>
> Il n'y a pas d'équivalent des svn:externals dans git. Pour palier à ce
> comportement subgit (qui fait la traduction snv<>git) gère un fichier
> de correspondance.
> Coté git ce fichier n'a pas de signification en soit. Toutefois cela
> permet de commiter depuis git des mises à jour pour applicables pour
> les svn:external.
>

Bonsoir et merci...

Intéressant...
http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html Je ne
connaissais pas [n'ayant jamais été confronté au besoin et n'ayant jamais
lu l'entièreté du manuel --quoique, pas sûr que je m'en serait souvenu...]
Je découvre au passage que Tortoise le gère [je travaille sous Linux et
uniquement en console, mais c'est intéressant de savoir comment une
interface graphique peut ajouter des options en extra sans devenir usine à
gaz)
https://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-externals.html
; https://jmfeurprier.com/2009/12/10/simple-introduction-to-svn-externals/
Du coup, je pensais plutôt que c'est un truc que sait faire Git mais pas
Subversion, sauf que de l'autre côté la fonctionnalité s'appelle
sous-module et non externe https://git-scm.com/docs/git-submodule Et c'est
également connu de Tortoise
https://tortoisegit.org/docs/tortoisegit/tgit-dug-submodules.html Il y a
aussi une fonctionnalité de sous-arborescence [que je n'ai pas encore eu
l'occasion de pratiquer]
https://help.github.com/en/github/using-git/about-git-subtree-merges
Bien entendu, le mode de fonctionnement des deux systèmes influence la
fonctionnalité
http://alexking.org/blog/2012/03/05/git-submodules-vs-svn-externals ;
https://blog.jonathanoliver.com/git-submodules-like-svnexternals/ ;
https://delicious-insights.com/fr/articles/git-submodules/ ;
https://delicious-insights.com/fr/articles/git-subtrees/

Du coup, je me suis demandé s'il n'est pas possible de simplement convertir
l'un en l'autre... Une petite recherche sur la fabuleuse place qu'est le
web m'a fait découvrir
-* une extension Ruby [cela ne répond pas directement à la question et doit
dater d'avant l'introduction de la fonctionnalité]
http://danielcestari.com/git-external/
-* une extension Python [similaire au précédent mais utilise du JSON aussi
et est pensé dans une optique d'importation/migration comme nous]
https://github.com/develersrl/git-externals
-* un script shell d'importation à plat [on est plus dans un esprit
chargeur ici] avec une arborescence cachée [à la .git/submodules-- et des
liens symboliques] https://github.com/andrep/git-svn-clone-externals
-* une autre solution d'importation en lecture [pareillement chargeur donc]
https://www.yergler.net/2009/07/21/git-svn-and-svnexternals/
-* un article intéressant [qui ne donne pas de solution mais confirme
l'approche et est en faveur d'une certaine forge]
https://www.leewillis.co.uk/including-git-repo-svn-external/



> La notion de distribution SPIP est actuellement géré par
> svn:externals. Dans le cas du script de Cédric, il s'appuie donc sur
> l'information traduit en git , dans le cas de mon script on s'appuie
> sur l'organisation SPIP pour retrouver cette notion.
>
> Km
>
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip

Re: [spip-dev] Nombre et noms des organisations Git

2019-12-14 Par sujet Gildas Cotomale
Le ven. 13 déc. 2019 14:51, cam.lafit a écrit :

> Salut
>
> Premier point, je suis d'accord pour que la situation soit figée
> d'une façon ou d'une autre.
>
+1

> Au final peut m'importe la façon dont c'est structuré du moment qu'on a
> une cohérence explicable.
>

Et Eric propose de garder plus ou moins la même cohérence, puisqu'il s'agit
de migrer et non recréer.

Suivant https://zone.spip.net/trac/spip-zone/browser/spip-zone?order=name
donc, on pourrait avoir :
- spip_core_
- spip_contribs_ (avec les sous-orga : plugins, squelettes, themes)
- spip_galaxie_
- spip_outils_

Après tout, cela a fait ses preuves...


> La suite de la réaction est non bloquante mais il me semble important de
> faire les remarques.
>
> > [...] Et je réitère sur un autre point : je suis toujours persuadé que
> les orgas doivent absolument être nommées et utilisées suivant QUI en est
> responsable, qui contribue dedans. [...]
>
> Tu mélange organisation et équipe, ce sont 2 concepts différents.
> Même en ayant cette approche là, tu tomberas toujours sur au moins
> 2 équipes, les personnes administrant (autrement dit
> responsables/propriétaires/...) les projets de l'organisation et
> les contributeurs. Ce qui ne correspond donc pas à "QUI est responsable".
> Au mieux ce qui serait à "qui participe"
>
> > [...] Elles doivent donc absolument avoir "spip" chacune dans leur nom,
> pour être sûr de pouvoir les dupliquer ailleurs. [...]
>
> Si un projet déménage de forge, tous les clones devront mettre à jour le
> chemin du remote. Modifier ou non le préfixe de l'organisation
> ne complexifiera pas la procédure de renommage. Donc non il ne faut
> "absolument" pas avoir un préfixe.
>
> > (Et aussi parce que c'est plus simple si l'orga est pareille à l'orga
> Composer quand on s'y mettra, donc même rien que pour ça, il faut avoir
> "spip" dans tous les noms.)
>
> Cela se défend dans l'idée d'avoir une cohérence de nommage. Ce point
> de cohérence me semble un point important mais cela n'a rien d'absolu.
>
>
> > - spip : pour l'équipe du noyau, donc le core de spip, les plugins dist
> (les gens feront des PR pour participer, et on peut déplacer les dépôts
> d'une orga à une autre si tel plugin devient dist, ou inversement s'il est
> viré et repart en contrib), les outils officiels (écran de sécurité et
> spip-loader devraient y être ! et pourquoi pas spip-cli un jour)
>
> Cela fera un pot pourri et qui va à l'encontre du point composer
> précédent vu qu'on mélangera plein de truc différents.
> spip est une distribution avec des un core, des plugins, squelettes (ce
> qu'on retrouverait dans composer) et tout le reste comme des outils tiers
> comme *_loader ou spip-cli.
>
> Autre remarque, est défendu la cohérence de nommage dans le
> temps (anticiper les migrations de forge, composer, ...) et en même
> est considéré normal le déplacement des projets entre organisation.
>
> > - spip-contrib : pour TOUT ce qui concerne les contributions collectives
> où la communauté a les mêmes droits, plugins, squelettes y compris pas en
> plugins, thèmes, outils (spip-cli actuellement)… Ce nom est le mieux, on
> abandonne "zone" qui restera en mémoire pour le svn, "contrib" marche dans
> plusieurs langues, et il correspond au site du même nom qui regroupent
> toutes les contributions, donc c'est parfait, on ne multiplie plus les
> termes, les nouveaux arrivants comprendront immédiatement.
>
> Pour l'aspect nommage à proprement parler contrib me semble mieux
> que zone, toujours dans cette logique de cohérence.
> Pour ce qu'on y met dedans, je ne suis toujours convaincu que ce soit bien
> d'en faire un gros fourre tout.
> D'autant plus qu'on retrouve déjà sur la zone cette logique de sous
> organisation avec les préfixes d'ensemble de projet (acces_restreint,
> galaxie, )
>
>
> > Et vu qu'on a décidé que les plugins-dist seraient gérés par l'équipe
> noyau (puisque critiques et officiels), il n'y a même plus besoin d'une
> troisième orga.
>
> cela reprénd le point distribution/composer discuté plus haut.
>
> > Pour les sites officiels de la galaxie, je ne vois aucune raison d'avoir
> une orga dédiée :
> > - soit on dit que c'est super officiel et qu'on veut du contrôle, et
> alors on décide que c'est dans l'orga "spip" du noyau (contributions par PR
> comme pour les plugins-dist pour les autres)
> > - soit on dit qu'on veut que n'importe qui puissent les modifier, et
> alors on laisse dans l'orga "spip-contrib".
>
> Les PR sont possibles dans les 2 cas. Ce n'est pas parce que c'est
> open bar que les PR sont à imposer ou à proscrire. C'est une
> méthodologie de travail.
>

Tout à fait. Et ça c'est probablement une autre discussion à avoir.


> > Et c'est tout.
> > La simplicité. Deux orgas, suivant qui participent dedans. Facile à
> comprendre pour nous et pour les arrivant⋅es, duplicables telles quelles
> sur d'autres forges et utilisables telles quelles pour Composer.
>
> Je ne trouve toujours pas cette proposition simple.
> Et comme proposé 

Re: [spip-dev] spam git.spip.net

2019-12-11 Par sujet Gildas Cotomale
Salut la liste

Le mer. 11 déc. 2019 18:51, Eric Lupinacci a écrit :

> Hello,
>
> On a la main sur le gitea, il est peut-être possible de corriger certaines
> choses.
> Ensuite les organisations aussi sont à revoir et finaliser.
> Contrib pour les outils c'est pas clair, on fait le rapport avec
> SPIP-Contrib.
>

D'accord avec toi sur ce point ; ça m'a perturbé quelques secondes.

À la lecture de la description, je suggère de renommer l'espace (nom
interne de l'organisation) en "vrac" (en vrac, juste par opposition à, en
paquet) ...et de mettre comme titre (nom humain/amical affiché)
"contributions/projets sans paquet.xml" (ou autre chose en 2 ou 3 mots
disant que ce n'est pas des plugins)


Après il faut distinguer les outils "officiels" de SPIP et du bac à sable.
>

Ah... pourquoi pas une organisation "test" faisant office de bac à sable
...comme pour le svn ?


> Galaxie il faudrait y etre toute la galaxie.
> Dans spip, voir tous les plugins est perturbant.
>

J'ai vu tout à l'heure que c'est renommé "plugins" ...ou je confonds ?

>
> Voilà y a des trucs comme ça qui sont perturbants et à mon avis rebutants.
> Si on peut corriger ça et transférer la zone rapidement (ou une partie
> utilisée) ça me parait une bonne étape.
>

Et une bonne base pour travailler aux autres outils (comme la
fabrication/génération de zip pour SVP)

D'ailleurs à ce propos, et j'ai pensé aussi à ça pendant mon nettoyage de
> Contrib, il va falloir qu'on décide de ce qu'on fait des plugins obsolètes,
> grenier qui ne sont d'ailleurs pas gérés de la même façon suivant qu'on est
> sur Contrib ou sur la Zone.
> Ca pourrait aussi nous guider pour le git des plugins.
>
>
>
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip

Re: [spip-dev] spam git.spip.net

2019-12-11 Par sujet Gildas Cotomale
Ciao tute

Le mer. 11 déc. 2019 14:39, Eric Lupinacci  a écrit :

>
>
> Le mer. 11 déc. 2019 à 13:48, nicod_ a écrit :
>
>> Le 11/12/2019 à 10:42, RastaPopoulos a écrit :
>> > Le 11/12/2019 à 10:22, Bruno Bergot a écrit :
>> >> Je pense que oui on peut supprimer ce miroir, mais ça pose surtout la
>> question suivante : n'importe qui peut s'inscrire sur git.spip.net et y
>> créer un dépôt ?
>> >
>> > Oui je ne comprends pas trop. Ça devrait être inchangé sur la procédure
>> normalement. Les inscriptions ne devraient pas être ouvertes, et on devrait
>> avoir l'obligation de demander à des humains pour s'assurer que les gens
>> ont lu et accepté la charte de la communauté.
>> >
>>
>> +1
>>
>
> +1
>
+1

Il n'est pas trop tard pour rattraper le coup :
-* fermer les inscriptions publiques
-* désactiver les comptes avec des emails qui ne sont recensé ni sur la
liste ni dans les accès Subversion


> Mais c'est sur que tant qu'on sera dans l'indécision ou la non décision ça
> ne pousse pas à nettoyer tout ça pour a minima retrouver quelque chose qui
> soit identique à la zone.
> Est-ce que ce n'est pas justement le moment de faire un vrai pas en avant
> et d'au moins ranger le git comme on voudrait qu'il le soit même si on
> conserve encore la zone ?
>

Oui, oui, oui !
Il faudrait dès à présent que lorsqu'on accorde l'accès à la Zone,  que ce
soit aussi bien au svn et au git avec le même courriel et mot de passe.

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

Re: [spip-dev] spam git.spip.net

2019-12-11 Par sujet Gildas Cotomale
Ciao tute

Le mer. 11 déc. 2019 19:00, RastaPopoulos a écrit :

>
> Sinon quand t'es dans une orga précise (SPIP par ex) t'es censé voir que
> les dépôts de CETTE orga. Donc ya aucun problème de confusion. Quand tu
> veux voir les projets officiels, bah tu vas sur la bonne orga officielle,
> comme dans Github quoi.
>
> Ça a déjà été dit trois fois au moins. Camille quel est le problème ?
> Gitea par défaut n'est pas bugué là dessus à priori, pourquoi nous on a ce
> bug ? Il faudrait vraiment corriger cet affichage.
>

Je retenterai demain, mais à l'instant, je ne constate pas (en étant
connecté avec le client gitnex) Peut être est-ce déjà corrigé ?

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

Re: [spip-dev] [SPIP Zone] Maintenance de la zone : trac

2019-10-22 Par sujet Gildas Cotomale
Le mar. 8 oct. 2019 14:52, nicod_  a écrit :

> Le 07/10/2019 à 10:07, cam.lafit@  a écrit :
> > Bonjour
> >
> > Une nouvelle opération de maintenance a été faite ce matin. Comme le
> > trac est sensé fournir 90% de données statiques, une cache devrait lui
> > faire du bien.
> >
> > C'est ce que je viens de faire. Il y a donc maintenant un cache apache
> > au dessus du trac. Cela devrait augmenter une peu la charge du serveur
> > frontal et baisser celle du trac.
>
> En attendant que trac se stabilise, une instance de websvn a été mise en
> place temporairement pour pouvoir suivre les derniers commits :
> https://websvn.spip.net/
>
> C'est assez rustique, mais ça permet au moins de suivre les développements.
>

Je trouve que ça fait franchement l'affaire quand on veut voir les
"changeset"s, malgré l'absence de coloration syntaxique (que parfois
j'aimerais désactiver sur trac et qui parfois est top aussi) Il est assez
complet pour tout ce qui tourne autour des "revision"s, du moins pour ce
que j'ai vu jusqu'à présent.
Par contre, juste pour naviguer dans l'arborescence, le côté relatif de
Trac me manque : ici on a toute l'arborescence avec le morceau demandé qui
est déplié (ce qui est bien sur des dépôts un peu plus classiques mais pas
top avec l'organisation de la zone où tous les projets sont dans le même
dépôt)

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

Re: [spip-dev] [SPIP Zone] Mise à jour git.spip.net

2019-10-02 Par sujet Gildas Cotomale
Le mer. 2 oct. 2019 18:18, cam.lafit@ a écrit :

> Bonjour
>

Ciao tuti

>
> Pour information :
> phabricator a été testé. Il ne correspond pas à nos usages entre autre
> en obligeant à nommer les projets avec des trigrammes. Ce qui est
> compliqué et inadapté à notre volumétrie. [...]


Wahooo ! Je me rends compte qu'on ne se rend pas compte du taf que t'as
abattu.
On devrait franchement basculer pour de bon ; je ne vois plus ce qu'on
attend (sauf la forge maison ou messie)

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

Re: [spip-dev] [SPIP Zone] Mise à jour git.spip.net

2019-10-02 Par sujet Gildas Cotomale
Hello,

J'avais pas suivi les échanges entre temps, mais je voter pour gitea : ça
fait largement le boulot par rapport à nos besoins et n'a rien à envier aux
mastodontes (...hub/lab même si je ne juge pas que Go soit meilleur que
Ruby haha) ; et attention, je parle des besoins-et-usages
identifiés-décrits pas juste de l'admin (jamais eu de souci avec mes
instances gitlab, mais le contexte --nombre de
projets/groupes/utilisateurs-- et les ressources  allouées ne sont
certainement pas pareils)

--

J'en profite pour quelque petit rappel/remarque après avoir vu que certains
entendent les chants de la mauvaise sirène :o

En utilisant Svn, on a évité d'aller chez : "CloudForge" <
http://www.cloudforge.com/> ; "GForge" 
; "SourceForge"  ; "RhodeCode" <
https://rhodecode.com/> ; "CodeBase"  ;
"Assembla"  ; "Helix TeamHub" <
http://www.perforce.com/> ;
En passant à Git, il faut éviter ces mêmes services (ceux qui supportent
aussi du Git) et similaires : "Github"  ; "Bitbucket" <
https://bitbucket.org/> ; "YouTrack" ; "Codeplex" ; etc.

Pour une forge auto-gérée, le constat est que Trac ne fait pas l'affaire
(sinon il existe aussi pour du Git...) et que GitLab CE (ou une solution
basée sur Ruby comme Github justement) est trop lourd. Du coup, il ne reste
que Gitea (écrit en Go et ayant interface/fonctionnalités proches de
Github) ou peut-être : "Phabricator" 
(c'est écrit en PHP héhé) ; "gogs"  (mais bon, gitea est
sa fourche avec plus de fonctionnalités <
https://docs.gitea.io/en-us/comparison/>) "Gitblit" 
(côté légèreté j'ai des aprioris vu que c'est en Java, mais bon

Si c'est pour des soucis de maintenance et qu'il y a vraiment le besoin de
faire héberger la forge, il y a des offres plus en accord avec les valeurs
défendues (comme "OurProject"  ou "Savannah" <
https://savannah.gnu.org/> ou encore "gitorious" 
autrefois) : "OpenHub"  ; "OSDN" <
https://osdn.net/> ; "Gitlab.com"  ou
"Framagit" 
On peut également considérer d'être porté par : "SEUL" <
https://www.seul.org/> ; "OW2"  ; "TuxFamily" <
http://projects.tuxfamily.org/?do=allgroups> ; etc.

C'est tout. Et désolé pour l'inventert à la Prévaire.
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip

Re: [spip-dev] [SPIP Zone] questions sur svn

2019-09-27 Par sujet Gildas Cotomale
Bonjour la liste,

Merci beaucoup Camille, pour les réponses précieuses.

Le jeu. 26 sept. 2019 à 10:44, cam.la...@azerttyu.net <
cam.la...@azerttyu.net> a écrit :


> [...] Oui c'est du pareil au même.[...]


Le message de bienvenue que j'avais reçu (et retrouvé ce matin), avec mes
identifiants, en demandant l'accès à la zone, m'invitait à consulter
https://zone.spip.org/trac/spip-zone/wiki/CommentUtiliserSvn
Je propose de l'ajouter, dans le champ "URL d'article", pour les contrib
relatifs aux questions d'usage de Subversion/Spip-Zone. Ça va améliorer son
référencement dans G.. et d'autres ; et on s'assure de retomber sur la
référence quand on vient d'ailleurs.


> > Autre question que je me pose : quand j'ai un lien de source (depuis
> Contri.spip.net ou Plugins.spip.net par exemple) du genre :
> >
> https://zone.spip.net/trac/spip-zone/browser/spip-zone/_plugins_/81dule/
> > comment je déduis l'adresse à récupérer pour mon client Subversion ?
> Quelque chose comme
> >  svn://zone.spip.net/spip-zone/spip-zone/_plugins_/81dule/ ?
>
> https://zone.spip.net/trac/spip-zone/browser/spip-zone/_plugins_/81dule/
> se décompose ainsi :
> * https://zone.spip.net/trac/spip-zone/browser/ : chemin spécifique à Trac
> * spip-zone/_plugins_/81dule/ : chemin dans le serveur svn
>
> Donc cela se traduit par :
> svn://zone.spip.net/spip-zone/_plugins_/81dule
>
> Super, je me note ça. :P
À voir s'il ne faut pas rajouter cet exemple dans le wiki sur Trac (ou
alors ça y est et je ne l'ai pas vu ?)

Pour la petite histoire, je ne sais plus mais je crois que j'avais suivi le
tuto pour déposer mon premier plugin ; puis j'ai du me servir de ce lien
(soit via l'historique de mes commandes, soit en reprenant à partir de
l'adresse d'un dépôt que j'avais en local) puis ai varié la fin selon les
répertoires où je voulais contribuer. Et là, je voulais m'y remettre, mais
je n'ai pas ressorti mon disque dur de l'époque et me suis heurté à
question (j'ai bêtement essayé l'adresse copié du navigateur en remplaçant
"https" par "svn" puis voyant que ça ne marchait pas, ai viré tantôt
"/trac/" tantôt "/browser/" ou les deux sans succès. effectivement j'avais
pas le bon schéma...)

> Accessoirement, quels sont les protocoles/ports supportés par le serveur
> Subversion des zones ?
> > - https/443
> > - svn+ssh/22
> > Je pose la question pour les situations où svn/3690 ne serait pas
> autorisé...
>
> (pas autorisé selon l'endroit où je suis : j'ai actuellement mis des
modifs sur une clef USB avec un Svn portable à tester)

Il est possible d’accéder au svn en écriture/lecture uniquement via
> svn://zone.spip.net/spip-zone
> Il est possible d'accéder en lecture seule depuis
> https://svn.spip.net/spip-zone/
> Et pas de ssh
>
> Merci encore. Déjà avec la bonne adresse je serai donc fixé ; et si ce
port est fermé je ne chercherai de-midi-à-quatorze-heure :)
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip

[spip-dev] questions sur svn

2019-09-25 Par sujet Gildas Cotomale
 Je profite de l'annonce de Km pour faire un petit hors sujet

Les services suivants sont en cours de migration dans leur nouveau DC :
> zone.spip.net / svn.spip.net
> core.spip.net
> latex.spip.net
> git.spip.net
>
> [...]

En début de semaine, "svn spip zone" dans un certain moteur de recherche,
me présente les pages suivantes dans l'ordre :
- https://contrib.spip.net/Publier-son-projet-via-SVN (pub. du 24 sep. 2009)
- https://contrib.spip.net/Commandes-svn-de-base-pour-la-zone (m-à-j du 3
fév. 2018)
- https://contrib.spip.net/La-Zone-Facile (m-à-j du 4 mar. 2019)

(N.B. J'ai omis https://zone.spip.net/trac/spip-zone qui apparaissait en 2è
position)
Or je remarque que :
- la première contribution mentionne trac.rezo.net
- les deux contributions suivantes mentionnent zone.spip.org

...comme les deux sous-domaines existent, je me demande si c'est du même au
pareil.

Autre question que je me pose : quand j'ai un lien de source (depuis
Contri.spip.net ou Plugins.spip.net par exemple) du genre :
 https://zone.spip.net/trac/spip-zone/browser/spip-zone/_plugins_/81dule/
comment je déduis l'adresse à récupérer pour mon client Subversion ?
Quelque chose comme
 svn://zone.spip.net/spip-zone/spip-zone/_plugins_/81dule/ ?

Accessoirement, quels sont les protocoles/ports supportés par le serveur
Subversion des zones ?
- https/443
- svn+ssh/22
Je pose la question pour les situations où svn/3690 ne serait pas
autorisé...

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

Re: [spip-dev] [SPIP Zone] Évolution du trac : son remplacement

2019-09-05 Par sujet Gildas Cotomale
Hello,


> Salut
> >
> >> et pourquoi ne pas en profiter pour switcher sur une forge git la
> >> totalité de la zone.
> > Pour la réponse courte : cela n'a rien à voir, mais vraiment rien.
> >
> > Pour plus de détail, le fonctionnement de la zone en svn n'est pas
> > convertible en l'état en git. Il y a un travail en cours/à faire qui
> > n'a rien à voir avec le remplacement ou non du trac.
>
> Si je ne me trompe, une forge Git (gitea, gitlab, ...) gère les dépôts
> sous GIT mais également les tickets, ...
>
> Comme il dit, il y a un travail en cours :-)
Et pour la forge actuelle (trac) on n'utilise pas la plupart des
fonctionnalités (les tickets sont faits via les commentaires sous les
articles liés sur contrib, et le côté wiki-et-co est géré par contrib
aussi)


> je ne vois pas de fonctionnalités qui sont exclusivement sur trac, mais
> je ne maitrise pas tous les tenants et aboutissants de trac et SPIP.
>
> Je me risque (je n'ai pas toutes les infos et ce n'est que ma vision des
choses) à dire que la migration en elle-même est déjà pas un point évident
car il ne faut pas perdre l'historique (plus c'est gros plus on a des
problèmes de conversion), sachant que la zone n'a pas toujours été
organisée ainsi (par exemple les répertoires trunk et branches, ou même les
arborescences _squeleettes_ et _plugins_ etc.) Ensuite (outre la migration)
il y a tous les workflows autour de svn en lui-même dont génération des
archives par exemple.


>
> > Pour la partie git, je t'invite à te reporter sur git.spip.net/plugin
> > pour ce point et les échanges sur les listes dev. (problèmatique de la
> > nomemclature des orgas, démultiplication des autorisations, temps de
> > réalisation,  )
>
> Effectivement, donc pourquoi mettre de l'énergie à configurer et
> maintenir 2 plateformes ?
>
> Je crois qu'il pointe une urgence liée aux problèmes que pose actuellement
Trac (faut croire que SPIP a réussi à atteindre les limites de l'outil) et
que la solution proposée semble plus simple et facile ; tandis que
précipiter la migration vers git sans avoir pu résoudre tous les soucis
identifiés est la catastrophe assurée. Bref, la solution de moindre énergie
et de maximum de sécurité.


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