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

2021-01-19 Par sujet Eric Lupinacci
Hello,

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

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

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


++
Eric


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

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

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

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

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

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

++
Eric


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

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

[spip-dev] Saisies en PHP

2021-01-16 Par sujet Eric Lupinacci
Hello,

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

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

Merci d'avance

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

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

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

++
Eric


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

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

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

2021-01-05 Par sujet Eric Lupinacci
Yop,

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

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



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

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


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

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

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

2021-01-05 Par sujet Eric Lupinacci
Hello,

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

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

Ca peut faire une roadmap sympa il me semble non ?


++
Eric


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

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

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

2021-01-04 Par sujet Eric Lupinacci
Re,

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

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


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



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

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

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

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

2021-01-04 Par sujet Eric Lupinacci
Hello,


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

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

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


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

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


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

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


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


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

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

2021-01-03 Par sujet Eric Lupinacci
Re,

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

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

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


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

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


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



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


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

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

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

2021-01-03 Par sujet Eric Lupinacci
Re,


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

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

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

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

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

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

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

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

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


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

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

2021-01-03 Par sujet Eric Lupinacci
Yop,


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

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

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


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

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

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

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

[spip-dev] Gitea et le débardeur

2021-01-03 Par sujet Eric Lupinacci
Hello,

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

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

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

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

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


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

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

2020-12-31 Par sujet Eric Lupinacci
Hello,


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

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



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

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

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

2020-12-27 Par sujet Eric Lupinacci
Hello,

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

++
Eric


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

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

[spip-dev] Migration Git - Galaxie - Scories

2020-12-27 Par sujet Eric Lupinacci
Hello,

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

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

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

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

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

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


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

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

2020-12-18 Par sujet Eric Lupinacci
Yop,

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

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

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

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

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

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

> Bonjour,
>
> Pour faciliter mes éventuelles futures contributions au projet, j'aurais
> besoin d'un accès à https://git.spip.net/ .
>
> J'ai déjà pris connaissance de la charte qui me convient.
>
> Est-ce qu'il est possible de me créer un accès?
>
> Merci.
>
> --
> Ludo
> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip
>
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

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

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

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

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

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

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

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

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

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

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


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

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

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

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

2020-12-14 Par sujet Eric Lupinacci
Hello,


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

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

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

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


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

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

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

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

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

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

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

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

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

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

++
Eric


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

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

Re: [spip-dev] Plugin Archive

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

++
Eric


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

> Bonjour,
>
> Qu'en est-il du plugin "Archive" qui ajoute un statut aux objets ?
> https://contrib.spip.net/Plugin-Archive
>
> Il est marqué fort en chantier et la doc parle de SPip 1.9.2, mais
> compatible Spip 3.2...
>
> Merci
>
> --
> Stéphane
> 17 Charente-Maritime
> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip
>
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Git et twgit

2020-11-13 Par sujet Eric Lupinacci
Yop,

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

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


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


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

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


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

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

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

Re: [spip-dev] Git et twgit

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

++
Eric


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

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

Re: [spip-dev] Git et twgit

2020-11-13 Par sujet Eric Lupinacci
Yop,



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

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

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

Re: [spip-dev] Git et twgit

2020-11-12 Par sujet Eric Lupinacci
Hello,



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

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


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

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


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

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


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

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

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

[spip-dev] Plugin Licence

2020-11-01 Par sujet Eric Lupinacci
Hello,

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

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

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

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

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

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

Re: [spip-dev] Doc sur contrib

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

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

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

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

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

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

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

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

2020-10-09 Par sujet Eric Lupinacci
Hello,

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





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

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

Re: [spip-dev] Bug avec spip_loader 4.2.0 ???

2020-10-08 Par sujet eric
Le jeudi 08 octobre 2020 à 19:25 +0200, Philippe Lefèvre a écrit :
> Bonjour,
> 
> à toutes fins utiles je vous signale une étrangeté constatée tout à 
> l'heure en passant de la version SPIP 3.2.5 à la version 3.2.8 via 
> spip_loader.php 4.2.0.
> A la fin du process (?, enfin j'espère) j'ai obtenu un le message
> suivant :
> Fatal error: Uncaught Error: Call to undefined function 
> spip_sanitize_from_request() in 
Bonsoir,

J'ai également eu ce message après un passage de 3.2.5 à 3.2.8,
également avec spip_loader 4.2.0 .

Un redémarrage du service php a réglé le problème : vider le cache des
scripts (si cela est utilisé) .

Depuis samedi dernier, jour de la mise à jour, plus aucune alerte.

Cordialement,

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] Renommages branches & tags SPIP + plugins-dist

2020-09-26 Par sujet Eric Lupinacci
Yes !

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

La bise
Eric


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

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

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

2020-09-26 Par sujet Eric Lupinacci
Hello,

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

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

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

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

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

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

2020-09-14 Par sujet Eric Lupinacci
Yop,

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

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

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

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

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

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

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

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

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

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

Donc on dit début de la semaine prochaine ?

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

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

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

2020-09-03 Par sujet Eric Lupinacci
Hello,

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

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

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

Re: [spip-dev] Bel_env et debug

2020-08-12 Par sujet Eric Lupinacci
Hello,

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

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

Mais oui, très bonne idée.

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

[spip-dev] Bel_env et debug

2020-08-11 Par sujet Eric Lupinacci
Hello,

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

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

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

Vos avis ?

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

Re: [spip-dev] Écriture inclusive

2020-08-05 Par sujet Eric Lupinacci
Hello,

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

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

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

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

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

Re: [spip-dev] Je commence avec GIT

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

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

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

Re: [spip-dev] Compte Gitea

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

++
Eric



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

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

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

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

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

++
Eric


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

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

Re: [spip-dev] UI gitea

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


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

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


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

2020-07-09 Par sujet Eric Lupinacci
Yep,

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

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

++
Eric

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

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

2020-07-09 Par sujet Eric Lupinacci
Re,

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

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

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

++
Eric



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

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

2020-07-09 Par sujet Eric Lupinacci


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

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

++
Eric

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

Re: [spip-dev] Migration sous Git - Bascule finale au 1 juillet 2020 - suite

2020-07-01 Par sujet Eric Lupinacci
Yep,

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

Fait.
A toi de jouer maintenant.

++
Eric


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

Re: [spip-dev] Migration sous Git - Bascule finale au 1 juillet 2020 - suite

2020-06-30 Par sujet Eric Lupinacci
Re,

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

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

++
Eric

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

Re: [spip-dev] Migration sous Git - Bascule finale au 1 juillet 2020 - suite

2020-06-30 Par sujet Eric Lupinacci
Hello,

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

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

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


++
Eric


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

Re: [spip-dev] Migration sous Git - Bascule finale au 1 juillet 2020 - suite

2020-06-30 Par sujet Eric Lupinacci
Re,

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

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


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

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


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

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

++
Eric

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

Re: [spip-dev] Migration sous Git - Bascule finale au 1 juillet 2020 - suite

2020-06-30 Par sujet Eric Lupinacci
Hello,

> champs_extras_import_export

Non, inutile

> cornertease
> horloge_flash

Faits.

> porte_plume_liens_internes

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

> tout_partout

Déjà fait et identifié par Rasta.

++
Eric

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

Re: [spip-dev] Migration sous Git - Bascule finale au 1 juillet 2020 - suite

2020-06-30 Par sujet Eric Lupinacci
Yep,

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

Fait avec tous les commits !

++
Eric

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


Re: [spip-dev] Migration sous Git - Bascule finale au 1 juillet 2020 - suite

2020-06-30 Par sujet Eric Lupinacci
Hello,

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

Fait

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

Sont déjà dans git

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

Fait

++
Eric

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


Re: [spip-dev] Migration sous Git - Bascule finale au 1 juillet 2020 - suite

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

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

Ils sont désormais tous sous git.

++
Eric


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

Re: [spip-dev] Migration sous Git - Bascule finale au 1 juillet 2020 - suite

2020-06-30 Par sujet Eric Lupinacci
Yep,

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

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


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

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

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

Ton choix ?

++
Eric


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

Re: [spip-dev] Migration sous Git - Bascule finale au 1 juillet 2020 - suite

2020-06-29 Par sujet Eric Lupinacci
Fait.

++
Eric 

 

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

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

Le 29/06/2020 à 19:25, Eric Lupinacci a écrit :
> Hello,
>
> Avec quelques regex sur _plugins_ j'ai identifié des plugins
> compatibles spip 3 mais non migrés.
> Il y a en environ 150.
> La liste est ici : http://spip.pastebin.fr/63331
>
> J'ai mis un commentaire sur certains qui me paraissent obsolètes.
> Pour le reste il faut décider mais au moins on a une liste.
>
> ++
> Eric
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Migration sous Git - Bascule finale au 1 juillet 2020 - suite

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

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

++
Eric


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

Bonsoir,

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

Merci à vous.

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

Hello,

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

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

++
Eric


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

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

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

Merci d'avance du retour

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

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

Re: [spip-dev] Migration sous Git - Bascule finale au 1 juillet 2020 - suite

2020-06-29 Par sujet Eric Lupinacci
Hello,

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

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

++
Eric


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

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

Re: [spip-dev] Faut pas pusher mémé dans les orties

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


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

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

Re: [spip-dev] SPIP-Bonux

2020-06-21 Par sujet Eric Lupinacci


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

Je viens de réessayer :

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

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

++
Eric

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

Re: [spip-dev] SPIP-Bonux

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

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

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

[spip-dev] SPIP-Bonux

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

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


++
Eric

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

Re: [spip-dev] Migration sous Git - Bascule finale au 1 juillet 2020 - suite

2020-06-16 Par sujet Eric Lupinacci
Hello,


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

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

Et _REGLES_DE_COMMIT et autodoc.txt

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

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

++
Eric




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

Re: [spip-dev] Migration sous Git - Bascule finale au 1 juillet 2020 - suite

2020-06-15 Par sujet Eric Lupinacci
Hello,

Je me reponds déjà pour un point.

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

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

A ne pas oublier donc.

++
Eric

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

[spip-dev] Migration sous Git - Bascule finale au 1 juillet 2020 - suite

2020-06-15 Par sujet Eric Lupinacci
Hello,


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

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

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

A vous lire.

++
Eric

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

Re: [spip-dev] Écriture inclusive

2020-06-15 Par sujet Eric Lupinacci
Hello,

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

Yep.
Et je pense qu’il ne faut pas oublier une des expressions SPIP les plus lues : 
les items de langue.
Une passe sur ces items serait pas forcément une mauvaise idée.

++
Eric


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

Re: [spip-dev] Écriture inclusive

2020-06-07 Par sujet Eric Lupinacci
Yep,

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

Ben justement, dans le texte indiqué par Matthieu 
http://www.haut-conseil-egalite.gouv.fr/IMG/pdf/guide_pour_une_communication_publique_sans_stereotype_de_sexe_vf_2016_11_02.compressed.pdf
 
<http://www.haut-conseil-egalite.gouv.fr/IMG/pdf/guide_pour_une_communication_publique_sans_stereotype_de_sexe_vf_2016_11_02.compressed.pdf>
 on remarque que dans le texte il n’y a que le substantif qui est écrit de 
cette façon et que dès qu’il est suivi d’un adjectif, celui-ci est écrit 
explicitement au féminin et au masculin dans un ordre d’ailleurs quelconque.
Je trouve que c’est une bonne pratique justement qui évite la répétition qui 
peut devenir cette fois pénible.

++
Eric

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

Re: [spip-dev] r125010 - in _core_/plugins/svp

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

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

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

Re: [spip-dev] r125010 - in _core_/plugins/svp

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

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

++
Eric 

 

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

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

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

Et va dire ça donc au plugin 

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

MM.

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

Re: [spip-dev] [Spip-zone-commit] r125010 - in _core_/plugins/svp

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

Donc je ne suis pas trop pour.

++
Eric 

 

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

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

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


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

___
spip-zone-com...@rezo.net - 
https://listes.rezo.net/mailman/listinfo/spip-zone-commit

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

Re: [spip-dev] Écriture inclusive

2020-06-05 Par sujet Eric Lupinacci
Yep,

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

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

++
Eric

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

Re: [spip-dev] Écriture inclusive

2020-06-05 Par sujet Eric Lupinacci
Hello,

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

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


++
Eric


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

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

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

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

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

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

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

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

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

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

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

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

Re: [spip-dev] Nomenclatures et serveur de données

2020-06-01 Par sujet Eric Lupinacci
Yep,


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

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

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

++
Eric

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

[spip-dev] Nomenclatures et serveur de données

2020-06-01 Par sujet Eric Lupinacci
Hello,


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

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

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

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


++
Eric

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

Re: [spip-dev] Gitea - Migration de _dev_

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

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

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

[spip-dev] Gitea - Migration de _dev_

2020-06-01 Par sujet Eric Lupinacci
Hello,

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

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

++
Eric

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

[spip-dev] Spip 3.2 - entites_html coorection double encodage

2020-05-29 Par sujet eric
Bonjour,

Je syndique un flux RSS qui encode deux fois certains caractères :
l'apostrophe est d'abord encodé en   puis en  #039;

Le filtre entites_html ne corrige t-il pas cela ?

Cordialement,

Eric

PS : j'ai prévenu le gestionnaire du flux.


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


Re: [spip-dev] Migration sous Git - Bascule finale au 1 juillet 2020

2020-05-28 Par sujet Eric Lupinacci
Yo,

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

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

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

++
Eric


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

Re: [spip-dev] Migration sous Git - Bascule finale au 1 juillet 2020

2020-05-28 Par sujet Eric Lupinacci
Hello,


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

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

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

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

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


++
Eric, furieux.

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

Re: [spip-dev] Migration sous Git - Bascule finale au 1 juillet 2020

2020-05-27 Par sujet Eric Lupinacci
Yep,

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

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

++
Eric

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

[spip-dev] Migration sous Git - Bascule finale au 1 juillet 2020

2020-05-27 Par sujet Eric Lupinacci
Hello,


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

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

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

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

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

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

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


Vos avis?

++
Eric

PS: on pourrait peut-être aussi sortir la 3.3 en même temps ou c’est trop ?
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip

Re: [spip-dev] Grille boostrap 4 / SpipR

2020-05-25 Par sujet Eric Lupinacci
Hello,

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

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


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

Donc non.

++
Eric

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

Re: [spip-dev] Grille boostrap 4 / SpipR

2020-05-25 Par sujet Eric Lupinacci
Hello,

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

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

++
Eric

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

Re: [spip-dev] Lien entre les articles du Wiki et les articles de doc

2020-05-20 Par sujet Eric Lupinacci
Hello,

Une dernière pour la route.

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

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

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

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


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

Y a un groupe de travail sur l’ergo de Contrib…
Désole il est pas dans le Carnet !
Et cette fois c’est bien fini ;-)

++
Eric

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

Re: [spip-dev] Lien entre les articles du Wiki et les articles de doc

2020-05-20 Par sujet Eric Lupinacci


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

Je ne dénigre pas je constate.


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

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


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

Why not. Mais pareil pourquoi attendre pour organiser ?

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

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

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

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

++
Eric

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

Re: [spip-dev] Lien entre les articles du Wiki et les articles de doc

2020-05-19 Par sujet Eric Lupinacci
Hello,


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

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

Je sais qu’on est pas d’accord.


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

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


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

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

++
Eric

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

Re: [spip-dev] Cloner tout git.spip.net

2020-05-16 Par sujet Eric Lupinacci
Yep,


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

C’est commité, une option —ssh.

++
Eric


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

Re: [spip-dev] Cloner tout git.spip.net

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

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

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

Re: [spip-dev] Meta dans une table spécifique

2020-05-15 Par sujet Eric Lupinacci
Hello,

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

Premiers éléments de réponse :

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

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

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

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

++
Eric




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

[spip-dev] Meta dans une table spécifique

2020-05-15 Par sujet Eric Lupinacci
Hello,

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

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

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

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

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

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

++
Eric

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

Re: [spip-dev] Cloner tout git.spip.net

2020-05-15 Par sujet Eric Lupinacci
Hello,

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

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

++
Eric


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

[spip-dev] Config et meta

2020-05-13 Par sujet Eric Lupinacci
Hello,


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

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

Vu qu’on a la version 3.3 en vue :

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

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

Voilà voilà pour la route.

++
Eric

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

Re: [spip-dev] problème de tag

2020-05-13 Par sujet Eric Lupinacci
Hello,

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

Sur Plugins SPIP le CRON passe toutes les 6 heures.

++
Eric


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

Re: [spip-dev] git.spip.net et reboot hardu

2020-05-06 Par sujet eric
Pas prioritaire ni urgent, éviter la 500 :
supprimer :  https://git.spip.net/eldk/test_bootstrap_5

Merci

PS : dans ce cas impossible de le faire soi même ?
___
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: https://www.spip.net/
dev: https://core.spip.net/
irc://irc.freenode.net/spip


Re: [spip-dev] html5up_spectral : comment faire pour changer le dépôt

2020-04-29 Par sujet Eric Lupinacci
Hello,



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

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


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

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

++
Eric

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

Re: [spip-dev] Problème enregistrement clé SSH sur git.spip

2020-04-25 Par sujet eric


> Peux tu détailler comment tu utilises tes pseudo  et mdp ?

$git push origin branche

- prompt de demande du login (pseudo ou mail fonctionnent)
- prompt de demande du mot de passe



> C'est un repo perso, alors son accés est il protégé de la même
> manière que les répos communautaires ?

Je ne sais pas, je suppose que la limitation est faite sur les accès à
une organisation. 

Voir le fichier .git/config du dossier clôné/bifurqué ?

```
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = https://git.spip.net/eldk/test.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
```



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


Re: [spip-dev] Problème enregistrement clé SSH sur git.spip

2020-04-25 Par sujet Eric Lupinacci
Hello,

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

++
Eric


> Le 25 avr. 2020 à 09:07, JLuc  a écrit :
> 
> Pour commiter sur git.spip depuis la ligne de commande
> pouvez vous me confirmer qu'il faut avoir enregistré une clé SSH dans les 
> paramètres perso de gitea ?
> 
> Actuellement, je n'ai aucune clé enregistrée et je n'arrive pas à commiter.
> Mais quand j'ajoute ma clé publique, gitea indique
> "Cette clef SSH a déjà été ajoutée au serveur."
> ce qui n'est pas faux puisque je l'avais ajoutée il y a longtemps,
> mais elle a été supprimée depuis et n'est plus enregistrée actuellement.
> 
> C'est un problème gitea et camille peut régler ça ?
> Il faut que je signale un bug sur le bugtracker de gitea ?
> Il faut que je crée une nouvelle clé pour contourner ce bug ?
> Ou il y a qqchose de préférable, qui m'échappe ?
> 
> JL
> 
> 
> ___
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip

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

Re: [spip-dev] Problème enregistrement clé SSH sur git.spip

2020-04-25 Par sujet eric
Le samedi 25 avril 2020 à 09:07 +0200, JLuc a écrit :
> Pour commiter sur git.spip depuis la ligne de commande
> pouvez vous me confirmer qu'il faut avoir enregistré une clé SSH dans
> les paramètres perso de gitea ?


Bonjour,

Je viens de tester avec pseudo/mdp et mail.mdp : pas de soucis pour le
push/poussé.

https://git.spip.net/eldk/test

Je n'ai fait aucune modification de mon profil du côté de git.spip.net
: valeurs de profil par défaut : pas de clef ssh, ni authentification 2
facteurs.

Cordialement,

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


Re: [spip-dev] html5up_spectral : comment faire pour changer le dépôt

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

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

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

  1   2   3   4   5   6   7   8   9   10   >