[SPIP Zone] Fusionner les flux de plugins externals et zone

Archives Zone
1

Holla,

comme nous ne sommes toujours pas tombé en consensus sur la manière d'avoir des depot git collectif, de plus en plus de gens dévellope en externe (et j'avoue les comprendre).

Comme je ne sais pas si nous arriverons prochainement à nous mettre d'accord.

ne peut-on pas à minimum fusionner
http://plugins.spip.net/depots/principal.xml
et
https://files.spip.net/externals/archives_externals.xml

histoire que les gens qui veulent installer des plugins n'ai pas à installer ce deuxième flux de plugins, mal documenté et pour ainsi dire inconneu en dehors des expert·e·s ?

Maïeul

2

Le jeu. 7 nov. 2019 à 14:13, Maïeul tapuscrit :

Holla,

comme nous ne sommes toujours pas tombé en consensus sur la manière
d'avoir des depot git collectif, de plus en plus de gens dévellope en
externe (et j'avoue les comprendre).

(moi j'avoue ne pas comprendre)
Juste pour signaler ou rappeler que git.spip.net reprend bien l'esprit
de La Zone...
et en bonus permet d'avoir un projet/plugin aussi bien sous Git que
dans Subversion

Comme je ne sais pas si nous arriverons prochainement à nous mettre
d'accord.

3

Le jeudi 07 novembre 2019 à 19:14 +0100, Gildas Cotomale a écrit :

Le jeu. 7 nov. 2019 à 14:13, Maïeul tapuscrit :
>
> Holla,
>
> comme nous ne sommes toujours pas tombé en consensus sur la manière
> d'avoir des depot git collectif, de plus en plus de gens dévellope
> en
> externe (et j'avoue les comprendre).
>

il était question à une époque de definir des espaces (_plugins_/spip)
je ne sais plus quoi.

surtout c'est pas documenté à ma connaissance, donc cela aide pas.

(moi j'avoue ne pas comprendre)
Juste pour signaler ou rappeler que git.spip.net reprend bien l'esprit
de La Zone...
et en bonus permet d'avoir un projet/plugin aussi bien sous Git que
dans Subversion

ca marche à nouveau la passerelle?

> Comme je ne sais pas si nous arriverons prochainement à nous mettre
> d'accord.
>

4

Le 07/11/2019 à 14:12, Maïeul a écrit :

ne peut-on pas à minimum fusionner
http://plugins.spip.net/depots/principal.xml
et > https://files.spip.net/externals/archives_externals.xml

il risque d'arriver de plus en plus que certains plugins ne s'installent pas
parce que leur dépendance est dans externals

or cette cuisine interne des dépots ici ou là ne devrait pas interférer
sur l'usage de spip par un spipeur Lambda-Michu
qui n'a pas à connaître ces histoires de fourchettes à gauche ou à droite.

ça semble donc nécessaire de fusionner ces 2 repos

(ou au minimum d'enrichir le message d'erreur pour donner des pistes
et d'enrichir les indications données dans ecrire)

JL

histoire que les gens qui veulent installer des plugins n'ai pas à installer ce deuxième flux de plugins, mal documenté et pour ainsi dire inconneu en dehors des expert·e·s ?

5

JLuc a écrit le 08/11/2019 à 09:18 :

Le 07/11/2019 à 14:12, Maïeul a écrit :

ne peut-on pas à minimum fusionner
http://plugins.spip.net/depots/principal.xml
et > https://files.spip.net/externals/archives_externals.xml

il risque d'arriver de plus en plus que certains plugins ne s'installent pas
parce que leur dépendance est dans externals

or cette cuisine interne des dépots ici ou là ne devrait pas interférer
sur l'usage de spip par un spipeur Lambda-Michu
qui n'a pas à connaître ces histoires de fourchettes à gauche ou à droite.

ça semble donc nécessaire de fusionner ces 2 repos

(ou au minimum d'enrichir le message d'erreur pour donner des pistes
et d'enrichir les indications données dans ecrire)

SPIP 3.3 a déjà un lien vers la page qui liste les dépôts.

--
RealET

6

+1

7

Le 08/11/2019 à 09:57, RealET a écrit :

SPIP 3.3 a déjà un lien vers la page qui liste les dépôts.

Justement :
"Lister les dépots" ça ne veut absolument rien dire de concret
pour quelqu'un qui veut juste faire un site internet.

Que ça empêche de découvrir et installer des plugins encore inconnus
(manque de sérendipité) c'est une chose supportable.

Mais que ça empêche d'installer un plugin connu qu'on demande d'installer
parce qu'il a une dépendance inaccessible pour une raison technique impénétrable
ça il faudrait l'éviter.

JL

8

Le jeu. 7 nov. 2019 à 19:27, Maïeul Rouquette a écrit :

Le jeudi 07 novembre 2019 à 19:14 +0100, Gildas Cotomale a écrit :
> Le jeu. 7 nov. 2019 à 14:13, Maïeul tapuscrit :
> >
> > Holla,
> >
> > comme nous ne sommes toujours pas tombé en consensus sur la manière
> > d'avoir des depot git collectif, de plus en plus de gens dévellope
> > en
> > externe (et j'avoue les comprendre).
> >
il était question à une époque de definir des espaces (_plugins_/spip)
je ne sais plus quoi.

un lien avec Connexion · GitLab ?

surtout c'est pas documenté à ma connaissance, donc cela aide pas.
>

Effectivement, la documentation fait défaut. :frowning:
Et ça se comprend vu que beaucoup rechignent à tester-adopter la
solution (ça sent le cercle ...)
On peut initier une page gribouille pour amorcer, s'il y a des partants

> (moi j'avoue ne pas comprendre)
> Juste pour signaler ou rappeler que git.spip.net reprend bien l'esprit
> de La Zone...
> et en bonus permet d'avoir un projet/plugin aussi bien sous Git que
> dans Subversion
>
ca marche à nouveau la passerelle?

Oui :slight_smile: J'ai eu à le constater :wink:

> > Comme je ne sais pas si nous arriverons prochainement à nous mettre
> > d'accord.
> >

9

Le 08/11/2019 à 10:07, JLuc a écrit :

Mais que ça empêche d'installer un plugin connu qu'on demande d'installer
parce qu'il a une dépendance inaccessible pour une raison technique impénétrable

ça il faudrait l'éviter.

Je suis assez d'accord… SAUF QUE au départ externals, c'était pour les
plugins qui ne font PAS PARTIS de la zone démocratique à plusieurs, et
qui donc sont maintenus par une unique personne à part. Et donc qui
peuvent possiblement être considérés comme moins de confiance PAR DÉFAUT
puisque pas maintenable à plusieurs par la communauté (ce n'est pas le
cas si telle personne précise qui s'en occupe est connue et que c'est
justement pour une raison de stabilité, comme Bank par ex mais "par
défaut" quoi).

Et dans ce cas, ça ne me choque pas que les gens doivent faire une étape
en plus pour y accéder, càd que ces plugins ne sont PAS listés par
défaut dans la recherche de plugins si on a pas explicitement demandé à
les y voir.

Je pense toujours qu'il faut absolument une différence entre les plugins
qui sont maintenables par la communauté, et les plugins qui sont d'une
seule personne à part.

Dans tous les cas actuellement les paquets sont fait à partir du SVN sur
des dossiers SVN, le créateur de paquet ne sait même si c'est un dossier
en dur ou venant d'une directive external, juste il prend le dossier
qu'on lui dit.

Donc c'est juste un choix humain, le plugin Bigup par exemple on sait
qu'à terme il doit être maintenu par la communauté, c'est pas juste
marcimat, puisque ça intègre 3.3. Donc on devrait le mettre dans le
fichier de paquet NORMAL, pas celui "externals". (Et en fait il devrait
plus être dans "marcimat" sur Github évidemment.)

Donc tous les plugins qui vont être en synchros ou plus tard même sans
synchros qui seront sur git.spip et mirrorés sur github etc, ça doit pas
être dans les paquets externals (même si pour l'instant on va continuer
de les déclarer en externals du SVN pour pouvoir générer les paquets).

Mais tous les plugins de gens à part doivent continuer à l'être, et je
ne suis PAS pour qu'ils soient visibles par défaut dans les recherches
tant qu'on l'a pas demandé. Je suis pour que les gens comprennent bien
qu'ils doivent installer là des plugins qui ne sont PAS communautaires,
c'est important !

--
RastaPopoulos

10

Le ven. 8 nov. 2019 à 10:07, JLuc a écrit :

Le 08/11/2019 à 09:57, RealET a écrit :
> SPIP 3.3 a déjà un lien vers la page qui liste les dépôts.

Justement :
"Lister les dépots" ça ne veut absolument rien dire de concret
pour quelqu'un qui veut juste faire un site internet.

En fait "Gérer les dépôts" (lister ceux ajoutés... et je crois pouvoir
en supprimer)
Quelqu'un qui veut juste faire un site web et qui veut utiliser des plugins
...comprend qu'il faut déclarer les dépôts à utiliser (ou utilisera
justement celui par défaut)

Que ça empêche de découvrir et installer des plugins encore inconnus
(manque de sérendipité) c'est une chose supportable.

Mais que ça empêche d'installer un plugin connu qu'on demande d'installer
parce qu'il a une dépendance inaccessible pour une raison technique impénétrable
ça il faudrait l'éviter.

Il n'y a pas de vraie solution à ça et c'est un problème que rencontre
tous les gestionnaires de paquets
Il faut justement éviter au maximum ces externals... Et pour les
plugins qui ont dépendance de ce genre, il faut clairement indiquer
dans la document qu'on a besoin de différents dépôts !

JL

11

Le 08/11/2019 à 10:57, RastaPopoulos a écrit :

Le 08/11/2019 à 10:07, JLuc a écrit :

Mais que ça empêche d'installer un plugin connu qu'on demande d'installer
parce qu'il a une dépendance inaccessible pour une raison technique impénétrable

ça il faudrait l'éviter.

Je suis assez d'accord… SAUF QUE au départ externals, c'était pour les
plugins qui ne font PAS PARTIS de la zone démocratique à plusieurs, et
qui donc sont maintenus par une unique personne à part. Et donc qui
peuvent possiblement être considérés comme moins de confiance PAR DÉFAUT
puisque pas maintenable à plusieurs par la communauté (ce n'est pas le
cas si telle personne précise qui s'en occupe est connue et que c'est
justement pour une raison de stabilité, comme Bank par ex mais "par
défaut" quoi).

Et dans ce cas, ça ne me choque pas que les gens doivent faire une étape
en plus pour y accéder, càd que ces plugins ne sont PAS listés par
défaut dans la recherche de plugins si on a pas explicitement demandé à
les y voir.

Je pense toujours qu'il faut absolument une différence entre les plugins
qui sont maintenables par la communauté, et les plugins qui sont d'une
seule personne à part.

Dans tous les cas actuellement les paquets sont fait à partir du SVN sur
des dossiers SVN, le créateur de paquet ne sait même si c'est un dossier
en dur ou venant d'une directive external, juste il prend le dossier
qu'on lui dit.

Donc c'est juste un choix humain, le plugin Bigup par exemple on sait
qu'à terme il doit être maintenu par la communauté, c'est pas juste
marcimat, puisque ça intègre 3.3. Donc on devrait le mettre dans le
fichier de paquet NORMAL, pas celui "externals". (Et en fait il devrait
plus être dans "marcimat" sur Github évidemment.)

Donc tous les plugins qui vont être en synchros ou plus tard même sans
synchros qui seront sur git.spip et mirrorés sur github etc, ça doit pas
être dans les paquets externals (même si pour l'instant on va continuer
de les déclarer en externals du SVN pour pouvoir générer les paquets).

Mais tous les plugins de gens à part doivent continuer à l'être, et je
ne suis PAS pour qu'ils soient visibles par défaut dans les recherches
tant qu'on l'a pas demandé. Je suis pour que les gens comprennent bien
qu'ils doivent installer là des plugins qui ne sont PAS communautaires,
c'est important !

hum, et du coup je comprend pas quel est ta proposition (si tu en a une) pour le dépot "communautaire mais pas svn" ?

12

Le 08/11/2019 à 11:28, Maïeul a écrit :

hum, et du coup je comprend pas quel est ta proposition (si tu en a une)
pour le dépot "communautaire mais pas svn" ?

Je l'ai marqué juste au dessus, le fait de choisir dans quel fichier n'a
rien à voir avec le fait que c'est en externals ou pas, c'est purement
un choix humain, il n'y a aucune obligation technique par rapport au
fait que c'est en svn:externals.

Le fichier externals doit donc être compris comme étant les dépôts
"externes à la communauté".

M'enfin je vois pas trop où est ton problème dans l'état actuel des
choses, puisque les dépôts INTERNES à la communauté, qui sont sur
git.spip, sont censés être sur le svn aussi obligatoirement ! (puisque
de toute façon le gitea n'a pas de lecture svn contrairement à github).

Donc mis à part le cas exceptionnel de Bigup qui est encore sur le dépôt
perso de marcimat, tout ce qui est est en svn:externals sur github c'est
toujours des choses non communautaires.

--
RastaPopoulos

13

Le 08/11/2019 à 10:57, RastaPopoulos a écrit :

Je suis assez d'accord… SAUF QUE au départ externals, c'était pour les
plugins qui ne font PAS PARTIS de la zone démocratique à plusieurs, et
qui donc sont maintenus par une unique personne à part. Et donc qui
peuvent possiblement être considérés comme moins de confiance PAR DÉFAUT
puisque pas maintenable à plusieurs par la communauté (ce n'est pas le
cas si telle personne précise qui s'en occupe est connue et que c'est
justement pour une raison de stabilité, comme Bank par ex mais "par
défaut" quoi).

Je suis absolument d'accord sur cette notion de confiance.

Au delà du débat démocratique / communauté / bande à part, les commits sur les plugins externals ne passent pas sous nos yeux comme ceux de la zone.
Autant on peut réagir collectivement sur un commit sur la zone qui ne respecterait pas la charte ou nos valeurs (et ça arrive de temps en temps), ou introduirait une faille, autant sur les externals on a pas ce regard constant.

Je ne suis donc pas favorable à ce que SPIP fournisse ces plugins par défaut à tout le monde, car ça engagerait notre responsabilité collective sur du code qu'on ne maitrise pas (ou beaucoup moins).

Proposition alternative : avoir deux dépôts externals, un de confiance (bigup, bank etc) fusionné avec le dépôt officiel, et un autre, identifié comme non officiel.

--
nicod_