[spip-dev] Nombre et noms des organisations Git

Dev
1

Un fil spécifique pour ça uniquement. Le but étant que ça ne bouge plus
pendant bien longtemps.

Il y a deux grandes questions :
- combien d'organisations (2 ou 3)
- le nom de chacune

Pour rappel le nom des orgas Git est par défaut (ya aucune raison de
changer pour pas être confus) utilisé pour le nom des vendors
(fournisseurs) Composer, au moins utilisé dans l'identifiant (première
partie) de tout projet Composer : spip/spip, spipdist/mots, etc

## Combien

Dans tous les cas, il y aura au moins
- une organisation pour l'équipe du core, avec les dépôts spécifiques au
noyau
- une organisation pour les projets maintenus en commun par la
communauté, notre spip-zone actuelle, avec les mêmes droits pour
chacun⋅e sur tous les dépôts

Mais il reste ensuite à savoir pour les plugins-dist (et peut-être les
sites officiels de la galaxie ?) : on a dit plusieurs fois que c'était
des plugins mais avec une attention plus poussé, que ce soit pour la
sécu ou les bugs, etc. Il y a essentiellement deux options :
- considérer que c'est exactement l'équipe du noyau qui gère ça, et
alors les modifications extérieures ne pourront venir que de PR
- avoir une troisième organisation, qui comprend l'équipe du noyau *plus
d'autres*, ajoutés par cooptation pareil, et qui peuvent maintenir ces
choses officielles mais qui ne sont pas le noyau (et dans toute forge
correcte on peut déplacer un projet d'une orga à une autre donc aucun
problème à ajouter un nouveau plugins-dist ou à en virer un jour comme
les brèves)

## Noms

Le nom de l'organisation du noyau, le cœur du projet, à mon avis ça doit
rester "spip".

Si jamais il y a une troisième orga, ça peut être "spipdist" ou ce genre
(sinon quoi ?).

Ensuite il y a la question de l'orga communautaire :
- soit on garde "spip-zone", c'est historique, mais ça ne parle qu'aux
quelques connaisseurs, ce n'est pas très parlant en soit
- dans plusieurs communautés, c'est du genre "friendsofXXX" donc ici
"friendsofspip"
- je ne sais pas si c'est mieux de trouver un terme en un seul bloc sans
tiret… peut-être ? (et du coup même si on garde "zone", ce serait
"spipzone" ?)
- je suis d'avis que ça ne doit pas être une private joke, ni un jeu de
mot français, etc : ça doit reste simple, et compréhensible par le plus
de monde immédiatement

On résout tout ça et on n'en parle plus pour ce petit point qui vaudra
quelque soit l'infrastructure.

2

Hello,

Un fil spécifique pour ça uniquement. Le but étant que ça ne bouge plus
pendant bien longtemps.

Cool.

Il y a deux grandes questions :

  • combien d’organisations (2 ou 3)
  • le nom de chacune

En fait le nombre est fonction de quoi exactement ?
D’une stratégie Composer ou d’une stratégie d’autorisation de modification ou les deux ou autres ?

Dans tous les cas, il y aura au moins

  • une organisation pour l’équipe du core, avec les dépôts spécifiques au
    noyau
  • une organisation pour les projets maintenus en commun par la
    communauté, notre spip-zone actuelle, avec les mêmes droits pour
    chacun⋅e sur tous les dépôts

Je proposerais bien (à voir pour le tiret ou pas) :

  • spip pour le Core (équipe core uniquement)
  • spip-dist pour les plugins de la distribution officielle de spip (équipe core + invités si nécessaire)
  • spip-zone ou spip-plugins pour les plugins, les squelettes et les thèmes (tout le monde comme la zone actuelle)
  • spip-galaxie pour les squelettes des sites de SPIP (le core + invités).

De cette façon on garde de la souplesse pour adapter les droits sur ces différents ensembles qui ont quand même des finalités assez distinctes.
Mais pour les outils qui sont dans outils, dev, acotes… ont fait quoi ? On laisse ça dans spip-zone ?

Une autre question que fait-on de grenier ?

3

En fait le nombre est fonction de quoi exactement ?
D'une stratégie Composer ou d'une stratégie d'autorisation de
modification ou les deux ou autres ?

Uniquement de qui s'en occupe. Donc le nom ne doit pas avoir trop de
rapport avec qu'est-ce qu'on met dedans, c'est vraiment qui s'en occupe.

Je proposerais bien (à voir pour le tiret ou pas) :

Peut-être qu'il en faut un différent pour la galaxie, mais je sais pas
si faut morceler à ce point. Si déjà on en a trois, ça fait déjà trois
grands types d'autorisations, et sûrement que la galaxie peut rentrer
dans l'orga pour "les trucs officiels mais pas noyau" si elle existe.
Cela dit, les sites de la galaxie, ya juste une seule instance à chaque
fois, et donc l'update est unique et contrôlé, du coup c'est moins
problématique, ça pourrait tout aussi bien rester dans l'orga communauté.

Tiens d'ailleurs pour l'orga communauté, je proposerais bien
"spip-contrib" aussi : pourquoi avoir autant de noms différents ? Le mot
"contrib" marche aussi en anglais et français (et même d'autres
langues), donc très compréhensible par tout le monde, et comme ça c'est
le même que le site central qui regroupe… les contributions
communautaires (quel heureux hasard !).

spip/…
spip-contrib/… ou spipcontrib/…
et éventuellement si pas dans l'orga core
spip-dist/… ou spipdist/…

Mais pour les outils qui sont dans outils, dev, acotes... ont fait quoi
? On laisse ça dans spip-zone ?
Une autre question que fait-on de grenier ?

Qui s'en occupe ? Si c'est la communauté, alors c'est dans l'orga
spip-zone, tout simplement.

Si tel outil devient finalement un outil officiel, par exemple imaginons
qu'un jour spip-cli soit fourni avec SPIP, bah ça sera déplacé dans
l'orga "spip". Mais sinon c'est la communauté.

4

Hello,

En fait le nombre est fonction de quoi exactement ?
D’une stratégie Composer ou d’une stratégie d’autorisation de
modification ou les deux ou autres ?

Uniquement de qui s’en occupe. Donc le nom ne doit pas avoir trop de
rapport avec qu’est-ce qu’on met dedans, c’est vraiment qui s’en occupe.

Ok claro.

Je proposerais bien (à voir pour le tiret ou pas) :

Peut-être qu’il en faut un différent pour la galaxie, mais je sais pas
si faut morceler à ce point. Si déjà on en a trois, ça fait déjà trois
grands types d’autorisations, et sûrement que la galaxie peut rentrer
dans l’orga pour « les trucs officiels mais pas noyau » si elle existe.
Cela dit, les sites de la galaxie, ya juste une seule instance à chaque
fois, et donc l’update est unique et contrôlé, du coup c’est moins
problématique, ça pourrait tout aussi bien rester dans l’orga communauté.

Bah, je pense pas que ce soit un gros souci d’en avoir 3 ou 4.
On ne va pas changer les autorisations tous les jours non plus.
Je serais plus pour garder de la flexibilité don d’avoir les 4 proposées.

5

Salut

# État actuel

Les organisations présentes sur git.spip.net sont inspirées du
découpage existant sur zone.spip.org. Il n'y a pas eu de logique
particulière sur le nommage en soit. On peut noter une seule
contrainte principale. Il y avait besoin d'isoler le code de SPIP des
autres code (plugins, dist, squelettes, outils, ....)

# Évolution et contraintes.

Il est tout à fait possible de faire évoluer les organisations
existantes, ce n'est pas figé du fait que leurs diffusions restent
encore assez marginale.
Je noterais que 2 mots clefs sont réservés "git" et "composer", je
préfères les bloquer par anticipation.

# Nommage et Composer

Il n'y pas d'obligation d'avoir des nommages communs. Les vendors
composer sont là pour éviter toute collision avec des projets qui
auraient le même nom (
https://getcomposer.org/doc/01-basic-usage.md#package-names ). On a un
exemple concret avec la maquette spipremix dont l'organisation github
est spipremix et le vendor composer est spip.
Sur ce point on peut donc définir n'importe quel vendor dans n'importe
quel plugin de n'importe quelle organisation.
Je me mets toutefois un bémol, il serait pratique (mais pas
obligatoire) de considérer que pour une organisation on ait un seul
vendor (c'est plus pour des pratiques d'automatisation et de logique
que de contraintes techniques de base)

# Nommage et github

Je ne me bloquerai pas dessus dans le sens que si on a besoin
d'exporter vers github, je prendrais simplement les noms des
organisations définies sur git.spip.net et j'ajouterai le préfixe
"spip-". Avec une seule exception pour l'organisation "spip", pour
éviter la redondance "spip-spip"

# Droit et usage Git

Il est possible de dissocier les organisations des droits associés.
Pour exemple (encore incomplet) avec l'équipe SPIP de l'organisation
SPIP ( https://git.spip.net/org/SPIP/teams/spip ) ou l'équipe contrib
de l'organisation _plugins_ (
https://git.spip.net/org/plugins/teams/contrib )
Sur ce point je suis donc assez en désaccord avec Rasta qui fusionne
ces 2 logiques. Pour ma part on devrait plutôt considérer les
organisations comme des entités répondant à un type de besoin ou ayant
une certaine cohérence dans leur contenu.
D'autant plus qu'il est possible d'affecter par défaut un compte à
l'ensemble des équipes "contrib" des différentes organisations (cf
plus bas).

# Rangement des projets actuels

Pour SVN nous avons :
2 dépôts distincts (zone et spip) avec :
* Coté serveur spip l'équivalent d'une seule "organisation" : spip ;
* Coté serveur zone, au moins 16 organisations ( _acotes_ , _composer_
, _contribs_, _core_ , _dev_ , _doc_ , _externals_ , _galaxie_ ,
_graphismes_ , _grenier_ , _libs_ , _modeles_ , _outils_ , _plugins_ ,
_squelettes_ , _themes_/ )

Sur la zone je ne suis incapable de dire à quelle logique cela répond(ait).

# Les propositions d'organisations soumises

* Vincent : spip , spipdist , spipzone ou spipcontrib ou friendsofspip
* Eric : spip, spip-dist, spip-zone ou spip-plugins , spip-galaxie

# Proposition complémentaire

Pour ma part je me rapproche beaucoup d'Eric avec :
* spip ou core (pour le core de SPIP comme déjà proposé car il y a des
logiques de droit et diffusion spécifique dont composer)
* plugins (pour tout ce qui est plugins et qu'on pourrait diffuser via composer)
* outils ou divers (pour tout ce qui est autre comme spip_loader,
gitloader, importgitea, satis, hook, smart paquet ...)
* presentation (cf plus bas)
* galaxie (pour tout ce qui concerne l'écosystème de la communauté
sans être dans les points précédents)

Et en complément je vois 3 équipes :
* owner pour administrer la forge
* spip pour gérer le code de l'orga SPIP
* zone pour le mode open bar sur l'ensemble des autres organisations

Je coince sur 2 points
* les plugins-dist, je ne pense pas que ce soit pertinent d'avoir une
organisation dédiée, cela ne répond ni à des problématiques d'usage
(ce sont des plugins) ni à des problématiques de droit (sur la zone
c'est openbar). Ces plugins devraient être soit dans plugins soit dans
spip.
Pour une histoire de visibilité j'aurais une petite préférence pour
mettre ceci dans SPIP et gérer les contributions via PR. On perd en
liberté par rapport à la zone. Si on met dans plugins on gagne en
liberté , on perd en visibilité car rien ne les distinguerait dans le
listing global.

* les présentations (squelettes, thèmes, modèles, ....) là honnêtement
j'en perd mon latin. Je n'ai aucune idée de où les mettre car c'est un
peut tout sans être rien. plugins ne me semble pas adapté car tous ne
sont pas des plugins, squelettes a le même problème tous ne sont pas
des squelettes. L'approche composer n'aide pas non plus car il ne
traite pas ces cas de figure, soit ça va dans squelttes, soi dans
plugins, soit dans theme, ....
Soit on renomme "plugins" en truc plus large mais il est compliqué de
rendre ceci explicite (si on met "zone" il n'y pas de sens en soit,
"contribution" trop laxiste car on pourrait tout mettre dedans alors).
A la rigueur je verrais bien une organisation "presentation" par
élimination des autres options.

Mes 2 sous .

Km

6

Hello,

Salut

Nommage et github

Je ne me bloquerai pas dessus dans le sens que si on a besoin
d’exporter vers github, je prendrais simplement les noms des
organisations définies sur git.spip.net et j’ajouterai le préfixe
« spip- ». Avec une seule exception pour l’organisation « spip », pour
éviter la redondance « spip-spip »

Sauf que je pense qu’il faudrait en profiter pour « nettoyer » les répertoires comme dev, outils, doc, graphismes, contribs…

Droit et usage Git

Il est possible de dissocier les organisations des droits associés.
Pour exemple (encore incomplet) avec l’équipe SPIP de l’organisation
SPIP ( https://git.spip.net/org/SPIP/teams/spip ) ou l’équipe contrib
de l’organisation plugins (
https://git.spip.net/org/plugins/teams/contrib )
Sur ce point je suis donc assez en désaccord avec Rasta qui fusionne
ces 2 logiques. Pour ma part on devrait plutôt considérer les
organisations comme des entités répondant à un type de besoin ou ayant
une certaine cohérence dans leur contenu.
D’autant plus qu’il est possible d’affecter par défaut un compte à
l’ensemble des équipes « contrib » des différentes organisations (cf
plus bas).

Ah ça ça change par rapport à ma compréhension initiale.
Pour moi la liste que j’ai donnée correspond aussi à une liste d’autorisations différentes : core de spip, plugins de spip, la zone et galaxie de spip sont a priori pas gérées par les mêms groupes de personnes.

Proposition complémentaire

Pour ma part je me rapproche beaucoup d’Eric avec :

  • spip ou core (pour le core de SPIP comme déjà proposé car il y a des

On pourrait aussi utiliser le terme spip-core

Et en complément je vois 3 équipes :

  • owner pour administrer la forge
  • spip pour gérer le code de l’orga SPIP
  • zone pour le mode open bar sur l’ensemble des autres organisations

Oui c’est là où je dis qu’il a peut-être aussi les plugins-dist et la galxie qui sont à ajouter.

Je coince sur 2 points

  • les plugins-dist, je ne pense pas que ce soit pertinent d’avoir une
    organisation dédiée, cela ne répond ni à des problématiques d’usage
    (ce sont des plugins) ni à des problématiques de droit (sur la zone
    c’est openbar). Ces plugins devraient être soit dans plugins soit dans
    spip.

Quand on regarde l’organisation spip actuelle sur Gitea on a trois repos :

  • spip
  • ecrire
  • prive
    Ca correspond à quoi exactement ?
    Après c’est vrai que si on considère que l’équipe gérant les plugins-dist est celle du core on peut très bien les avoir dans l’organisation spip ou spip-core.
    Mais alors pourquoi ne pas y mettre aussi tous les outils attachés à spip (loader, générateurs divers…)
  • les présentations (squelettes, thèmes, modèles, …) là honnêtement
    j’en perd mon latin. Je n’ai aucune idée de où les mettre car c’est un
    peut tout sans être rien. plugins ne me semble pas adapté car tous ne
    sont pas des plugins, squelettes a le même problème tous ne sont pas
    des squelettes. L’approche composer n’aide pas non plus car il ne
    traite pas ces cas de figure, soit ça va dans squelttes, soi dans
    plugins, soit dans theme, …

Là on revient toujours à la confusion du plugin comme fonctionnalité ou mécanisme de distribution.
En l’occurrence sur la zone plugins désigne un module fonctionnel qui peut être distribué en plugin ou pas. Je pense d’ailleurs que c’est toujours un plugin au sens distribution pour ce répertoire.
Par contre, squelettes et thèmes sont pour la plupart des plugins au sens distribution mais pas que.
Donc c’est pour ça que spip-zone est mieux que spip-plugins sauf si on considérerait que l’on y met que des plugins au sens distribution (ie, modules fonctionnels, squelettes et thèmes).
Après, on peut se demander si aujourd’hui on partage autre chose que des plugins au sens distribution en tant que contribution finie ?

Soit on renomme « plugins » en truc plus large mais il est compliqué de
rendre ceci explicite (si on met « zone » il n’y pas de sens en soit,
« contribution » trop laxiste car on pourrait tout mettre dedans alors).
A la rigueur je verrais bien une organisation « presentation » par
élimination des autres options.

Non pas top.
Plugins, Squelettes et thèmes doivent faire partie de la même organisation.
Par contre, il faut savoir si on y met encore des contributions non distribuées en tant que plugin.

7

Oui, l’organisation, ça correspond en gros à «qui» a en charge les choses qui sont dedans», pas forcément donc à quoi est dedans.

Idéalement, et par convention, l’organisation est la même que le "vendor" utilisé dans composer (comme l’a déjà indiqué azertyu, ça n’a rien d’obligatoire, c’est juste plus pratique pour tout le monde, et c’est ce qui est fait à peu près partout). Donc si "spip/spip" => organisation "spip".

Et je rejoindrais Rasta (je crois du moins) sur le fait que l’organisation c’est "qui" détiens le droit. Si y a plusieurs noms d’organisations, mais avec le même ensemble de personnes qui ont les droits, il me semble qu’il vaut mieux 1 seule organisation pour ça.

Ceci étant dit, il faut quand même dire aussi que suivre l’ensemble des modifications sur les projets GIT d’une organisation (disons spip-zone où il risque d’y avoir le plus d’activité) sera plus difficile qu’actuellement en SVN.

Je ne trouvais pas notamment comment voir l’activité des commits de l’organisation _plugins_ entière (https://git.spip.net/plugins) [ aparté : gitlab le permet depuis un bouton "Activité" bien visible. Finalement c’est faisable avec Gitea aussi (si on fait partie de l’organisation) https://git.spip.net/org/plugins/dashboard en cliquant (comme sur github d’ailleurs) le logo en haut à gauche (sous Tableau de bord).

J’appréhende quand même un poil l’ouverture en 'push' de tous les plugins à tout le monde, vu déjà les erreurs sous SVN, me disant que c’est peut être pas la meilleure idée dans le monde GIT (on peut forker si on veut améliorer un plugin, ou éditer en ligne et proposer des PR).

Ça tendrait plus à avoir des rôles plus fins au niveau de chaque ou certains projets / plugin, ou les autrices et auteurs mainteneurs pourraient décider ou non d’ouvrir l’accès en écriture à tous les membres, ou seulement à certaines personnes. Mais je conçois que c’est pas très cool de brider comme ça.

Mais dans ma caboche, j’imagine plus facilement une organisation "SarkaSpip" avec son squelette, ses thèmes, ses mainteneurs, qu’une orga "spip-zone" qui les contiendrait, par exemple.

Bon, après il suffit de dire que celleux qui veulent ça ont qu’à aller ailleurs que sur la zone...

MM.

8

Pour rebondir sur la dernière remarque de Matthieu, on peut sans doute considérer que la règle par défaut sera l’ouverture à tous, mais qu’il serait acceptable que certains plugins soient fermés par leurs auteurs aux commits directs, en obligeant à passer par des PR relues.

Je fais ça pour le plugin bank, et plus généralement sur ce qui est ecommerce je pense que ça serait très souhaitable car les impacts en cas de bugs sont grands.
Je serai donc bien content de pouvoir ramener le plugin bank sur l’espace communautaire du moment qu’il est possible d’avoir un fonctionnement de ce type.
A défaut en effet on est obligé de développer autre part, mais c’est un peu dommage non ?

9

cette règle me paraît bonne.

10

Yop,

Pour rebondir sur la dernière remarque de Matthieu, on peut sans doute
considérer que la règle par défaut sera l’ouverture à tous, mais qu’il
serait acceptable que certains plugins soient fermés par leurs auteurs aux
commits directs, en obligeant à passer par des PR relues.

Je fais ça pour le plugin bank, et plus généralement sur ce qui est
ecommerce je pense que ça serait très souhaitable car les impacts en cas de
bugs sont grands.
Je serai donc bien content de pouvoir ramener le plugin bank sur l’espace
communautaire du moment qu’il est possible d’avoir un fonctionnement de ce
type.
A défaut en effet on est obligé de développer autre part, mais c’est un
peu dommage non

Oui, le fait de pouvoir le faire me parait pertinent du moment que la
valeur par défaut est bien "ouvert à tous".
Après je reviens sur les droits :
Je pense qu'il faut considérer la flexibilité aussi.
Si on met les plugins-dist dans l'organisation spip parce que ce sont les
mêmes qui aujourd'hui les maintiennent ça veut dire qu'on ne pourra pas
ouvrir les plugins-dist à d'autres sans ouvrir SPIP ce qui peut être
problématique.
Et je pense que c'est pareil pour Galaxie.
C'est pourquoi ça me choque pas qu'on ait ces 4 organisations pour avoir la
possibilité de faire varier la liste des personnes sans être bridé.

11

Salut

Je reprends dans le désordre certains points soulevés dans les
précédents courriels. Désolé d'en faire une drôle de mixture.

Quand on regarde l'organisation spip actuelle sur Gitea on a trois repos :
- spip
- ecrire
- prive
Ca correspond à quoi exactement ?

C'est la même chose :slight_smile:
Le premier dépôt est la traduction en l'état du projet svn. (privé des
svn:externals)
Tandis que ecrire et prive sont les filtrages demandés par la maquette
composer. Ce sont les sous répertoire de spip. On pourra noter qu'ils
sont synchrones au même titre que SPIP avec un ajustement au niveau de
versions afin de respecter composer.
Ces 2 dépôts sont encore expérimentaux.

En toute logique le dépôt spip devrait donc disparaître à leur profit
à terme. Et on devrait voir apparaitre le metapackage spip-classic qui
piloterai ces 2 dépôts, spip-installer ainsi que les plugins-dist.

Après c'est vrai que si on considère que l'équipe gérant les plugins-dist est celle du core on peut très bien les avoir dans l'organisation spip ou spip-core.
Mais alors pourquoi ne pas y mettre aussi tous les outils attachés à spip (loader, générateurs divers...)

C'est aussi une histoire de lisibilité. On a trop de projets pour tout
mettre dans une même organisation. Il me semble pertinent de pouvoir
faire des groupements au delà de la simple logique d'autorisation.

[...]
D'autant plus qu'il est possible d'affecter par défaut un compte à
l'ensemble des équipes "contrib" des différentes organisations (cf
plus bas).

[...]
Ah ça ça change par rapport à ma compréhension initiale.
Pour moi la liste que j'ai donnée correspond aussi à une liste d'autorisations différentes : core de spip, plugins de spip, la zone et galaxie de spip sont a priori pas gérées par les mêms groupes de personnes.

Concernant l'aspect des "teams", j'ai été un peu rapide et surtout
vous ne pouviez pas bien voir la situation, donc pas très pratique.
Note : les noms des teams n'est pas figé (ce sont celles actives
maintenant mais on peut les renommer/créer/supprimer/....)

Pour une "organisation" on peut créer des "équipes(team)" avec des
droits spécifiques. Ces teams font la jonction entre les "dépôts
(repository)" de l'organisation et l'ensemble des membres inscrits.
Par défaut cette team n'a aucun membre et aucun dépôt, uniquement des
droits type :
* lecture/ecrite/administration
* accès à des sections (code, ticket, PR, accès aux versions, wiki)
Ces droits sont alors activés pour les membres de la team sur les
dépôts associés à celle ci.

Dans le cas de l'organisation _plugins_ j'ai créé la team "contrib"
qui a des droits d'écriture générique (sauf wiki et ticket interne).
J'ai un traitement automatisé qui fait que :
* chaque nouveau dépôt de _plugins_ est associé à la team "contrib".
* chaque membre validé est affecté à la team "contrib" de
l'organisation "_plugins_"

Ainsi on a un comportement similaire à ce que propose la zone. C'est
traité via cron et api interne de gitea.

Je fais ça pour le plugin bank, et plus généralement sur ce qui est ecommerce je pense que ça serait très souhaitable car les impacts en cas de bugs sont grands.
Je serai donc bien content de pouvoir ramener le plugin bank sur l’espace communautaire du moment qu’il est possible d’avoir un fonctionnement de ce type.
A défaut en effet on est obligé de développer autre part, mais c’est un peu dommage non ?

Comme une team est vide par défaut, on peut surcharger le comportement
précédent en ayant par exemple une team "bank" qui aurait des droits
élargis aux plugins "bank_*" . Ces plugins seraient à supprimer de
contrib pour restreindre les droits générique. Cela demande une
gestion manuelle (à tester si on veut).

En complément de ceci on peut, dépôts par dépôt, affecter des
"collaborateurs". On peut considérer ceci comme une team restreinte à
un seul et unique dépôt.

Après je reviens sur les droits :
Je pense qu'il faut considérer la flexibilité aussi.
Si on met les plugins-dist dans l'organisation spip parce que ce sont les mêmes qui aujourd'hui les maintiennent ça veut dire qu'on ne pourra pas ouvrir les plugins-dist à d'autres sans ouvrir SPIP ce qui peut
être problématique.

On peut envisager de les mettre dans l'organisation SPIP (on a une
organisation cohérente pour avoir un SPIP classic) avec une team
contrib qui aurait des droits d'écriture restreints à ces plugins.
(avec affectation automatique à la création d'un compte sur la forge).

J’appréhende quand même un poil l’ouverture en 'push' de tous les
plugins à tout le monde, vu déjà les erreurs sous SVN, me disant que
c’est peut être pas la meilleure idée dans le monde GIT (on peut forker
si on veut améliorer un plugin, ou éditer en ligne et proposer des PR).

En effet mais faut avoir en tête une logique de PR qui n'est pas
nécessairement évidente dans le cas des contributions de la zone.
C'est une habitude de travail. Les 2 sont possibles.

Ça tendrait plus à avoir des rôles plus fins au niveau de chaque ou
certains projets / plugin, ou les autrices et auteurs mainteneurs
pourraient décider ou non d’ouvrir l’accès en écriture à tous les
membres, ou seulement à certaines personnes. Mais je conçois que c’est
pas très cool de brider comme ça.
Mais dans ma caboche, j’imagine plus facilement une organisation
"SarkaSpip" avec son squelette, ses thèmes, ses mainteneurs, qu’une orga
"spip-zone" qui les contiendrait, par exemple.
Bon, après il suffit de dire que celleux qui veulent ça ont qu’à aller
ailleurs que sur la zone...

On pourrait à terme faire évoluer vers des organisations séparées,
j'ai en effet imposé une logique plate de ce point de vue (car je suis
parti du modèle zone)
On peut envisager que les organisations soient libres et avoir (ou
non) une team "contrib" par défaut tout le temps. Cette team serait
active par défaut et restreinte sur demande.
On a plusieurs modèles de fonctionnement possible.

Je n'ai pas trop poussé cet aspect mais il me semble qu'on peut aller
plus loin que le comportement proposé actuellement la forge actuelle.

Km

12

M'est-avis qu'on est en train de se diriger vers une usine à gaz encore,
chiante à comprendre, avec des scripts pour synchroniser des choses et
je ne sais quelle merdouille.

Les "équipes", c'est un concept supplémentaire, qui vaut pour la plupart
des forges certes, mais qui n'est pas forcément pile pareil partout, et
qui dans tous les cas ajoutent un concept, et une strate supplémentaire.

Les équipes sont propres à chaque organisation, donc si plusieurs
organisations différentes doivent avoir les mêmes personnes, faut
dupliquer les listes, faut synchroniser… Et si un jour où doit passer à
une autre forge (quelque soit le sens) faut s'assurer de tout retrouver,
bref un bordel sans nom. Mais même sans transfert, je trouve ça relou perso.

KISS franchement, des bisous et de la simplicité.

Qu'on ajoute *très légèrement* un découpage en plus pou affiner, avec
une orga autre pour les plugins-dist ou la galaxie, ou ce genre, ok.

Mais sinon : une orga = un groupe de personnes précis, et ce sont les
gens de l'orga directement, pas des sous-groupes encore à l'intérieur.
Et basta. C'est facile à maintenir, c'est surtout facile à comprendre.
Tu fais partie de l'orga "spipcontrib", tu peux modifier tous les
projets dedans. Fin.

Pour les *quelques rares projets* qui ont besoin de surveillance
particulière, je le conçois totalement. Mais dans ce cas, ce n'est plus
une modification ouverte, et donc ça n'a pas à être dans le dépôt/orga
coopératif. C'est forcément ailleurs, et c'est très bien que ce soit
ailleurs, clairement séparé du reste, bien identifiable.

Après, à partir du moment où un projet (Bank par exemple) n'est pas dans
la partie coopérative : qu'il soit sur une autre orga git.spip.net, ou
sur Github, ou sur un Gitlab perso : ça ne change pas des masses pour
moi, dans tous les cas il doit être ailleurs que la partie ouverte. Mais
tant mieux si c'est dans git.spip.net (mais ailleurs, dans
git.spip.net/nursit/bank, ou git.spip.net/cerdic/bank), ça permet de le
voir au même endroit que le reste, et puis ça permet surtout aux
mainteneurs de profiter sûrement plus facilement des outils de diffusion
qu'on mettra en place.

Donc j'insiste et je ne change pas d'avis sur mon premier mail :
- du simple, juste quelques orgas (2, 3, 4, maxi)
- aucun sous-droits compliqués !
- et les quelques rares projets qui doivent avoir des droits
particuliers, peuvent bien être sur la même forge mais chez des
utilisateurs particuliers ou dans d'autres orgas que celles collectives

13

Hop,

KISS franchement, des bisous et de la simplicité.

Pas mieux, restons simples "sur le papier", on aura tout le temps et le loisir de complexifier par la suite, je sais qu'on est doué⋅e⋅s pour ça :stuck_out_tongue:

Qu'on ajoute *très légèrement* un découpage en plus pou affiner, avec
une orga autre pour les plugins-dist ou la galaxie, ou ce genre, ok.

Si on met les plugins-dist dans l'organisation spip parce que ce sont les
mêmes qui aujourd'hui les maintiennent ça veut dire qu'on ne pourra pas
ouvrir les plugins-dist à d'autres sans ouvrir SPIP ce qui peut être
problématique.

Non pas du tout, les personnes externes à l'orga spip(-core) pourront très bien proposer des pull/merge request et c'est bien vers ça qu'on veut aller :slight_smile:

14

Salut

Pour le coup je commence une première évolution :
* _outils_ disparaît et son contenu migre dans l'orga contrib
* dist disparaît et son contenu migre dans l'orga spip (ce qui fait
qu'on a une seule organisation pour la distribution de base SPIP)
* _plugins_ est renommé plugin (plugins est un mot réservé, je me
renseigne sur le pourquoi)

Km

15

Il faudrait vraiment clôturer ce choix.

TL;DR : 1) Les orgas doivent correspondre à qui participe dedans. 2) la communauté est divisée en seulement deux sous-groupes avec chacun ses droits. Donc il n'y a pas besoin de plus que deux orgas.
- spip
- spip-contrib
Basta.

Donc j'insiste et je ne change pas d'avis sur mon premier mail :
- du simple, juste quelques orgas (2, 3, 4, maxi)
- aucun sous-droits compliqués !
- et les quelques rares projets qui doivent avoir des droits particuliers, peuvent bien être sur la même forge mais chez des utilisateurs particuliers ou dans d'autres orgas que celles collectives

Et je réitère sur un autre point : je suis toujours persuadé que les orgas doivent absolument être nommées et utilisées suivant QUI en est responsable, qui contribue dedans. À aucun moment on ne doit séparer suivant le type de contribution à l'intérieur, car les mêmes personnes peuvent aussi bien maintenir un plugin, ou un outil important qui n'est pas un plugin (spip-cli), ou un squelette qui n'est pas sous forme de plugin…Il n'y a aucun rapport avec le type.

Le découpage ne doit pas non plus se baser sur le fait qu'on est sur telle ou telle forge, là on est sur la notre, mais si on décide de tout déplacer ailleurs (ou même juste dupliquer, synchroniser, par ex avec Github), il faut pouvoir juste tout copier tel quel, donc sans rien avoir à renommer, en premier lieu les orgas. Elles doivent donc absolument avoir "spip" chacune dans leur nom, pour être sûr de pouvoir les dupliquer ailleurs. (Et aussi parce que c'est plus simple si l'orga est pareille à l'orga Composer quand on s'y mettra, donc même rien que pour ça, il faut avoir "spip" dans tous les noms.)

Pas de mélange de majuscules et minuscules non plus. Le nom principal technique qui identifie chaque orga devrait être prédictible, donc tout en minuscule à priori.

- spip : pour l'équipe du noyau, donc le core de spip, les plugins dist (les gens feront des PR pour participer, et on peut déplacer les dépôts d'une orga à une autre si tel plugin devient dist, ou inversement s'il est viré et repart en contrib), les outils officiels (écran de sécurité et spip-loader devraient y être ! et pourquoi pas spip-cli un jour)

- spip-contrib : pour TOUT ce qui concerne les contributions collectives où la communauté a les mêmes droits, plugins, squelettes y compris pas en plugins, thèmes, outils (spip-cli actuellement)… Ce nom est le mieux, on abandonne "zone" qui restera en mémoire pour le svn, "contrib" marche dans plusieurs langues, et il correspond au site du même nom qui regroupent toutes les contributions, donc c'est parfait, on ne multiplie plus les termes, les nouveaux arrivants comprendront immédiatement.

Et vu qu'on a décidé que les plugins-dist seraient gérés par l'équipe noyau (puisque critiques et officiels), il n'y a même plus besoin d'une troisième orga.

Pour les sites officiels de la galaxie, je ne vois aucune raison d'avoir une orga dédiée :
- soit on dit que c'est super officiel et qu'on veut du contrôle, et alors on décide que c'est dans l'orga "spip" du noyau (contributions par PR comme pour les plugins-dist pour les autres)
- soit on dit qu'on veut que n'importe qui puissent les modifier, et alors on laisse dans l'orga "spip-contrib".
Et c'est tout.

La simplicité. Deux orgas, suivant qui participent dedans. Facile à comprendre pour nous et pour les arrivant⋅es, duplicables telles quelles sur d'autres forges et utilisables telles quelles pour Composer.

(Pour les plugins critiques ayant besoin de contrôle comme Bank, c'est HS et ya rien à choisir. Si les mainteneurs veulent profiter de l'hébergement et des automatismes qui seront possibles, ils peuvent créer leur orga et maintenir leur truc par PR sur la forge choisie par la communauté, donc par ex ici git.spip.net/nursit/bank.)

16

Il faudrait vraiment clôturer ce choix.
TL;DR : 1) Les orgas doivent correspondre à qui participe dedans. 2) la communauté est divisée en seulement deux sous-groupes avec chacun ses droits. Donc il n'y a pas besoin de plus que deux orgas.
- spip
- spip-contrib
Basta.

D'accord mais je me demande si cette définition est suffisante.

(Ces organisations "divisent" elles les spipeurs ou leurs contributions ??)

Car si on veut garder la notion centrale de "catalogue SPIP",
alors les clones des repos de 'spip' ou de 'spip-contrib' ne doivent pas encombrer ces organisations.
Faut il donc pas une autre organisation pour les clones et autres repos qui ne doivent pas figurer au "catalogue spip" ?

Un spip-pas-spip

JL

17

Hello,

Il faudrait vraiment clôturer ce choix.

OUI !!!

TL;DR : 1) Les orgas doivent correspondre à qui participe dedans. 2) la communauté est divisée en seulement deux sous-groupes avec chacun ses droits. Donc il n’y a pas besoin de plus que deux orgas.

  • spip
  • spip-contrib
    Basta.

Bof…

Et je réitère sur un autre point : je suis toujours persuadé que les orgas doivent absolument être nommées et utilisées suivant QUI en est responsable, qui contribue dedans. À aucun moment on ne doit séparer suivant le type de contribution à l’intérieur, car les mêmes personnes peuvent aussi bien maintenir un plugin, ou un outil important qui n’est pas un plugin (spip-cli), ou un squelette qui n’est pas sous forme de plugin…Il n’y a aucun rapport avec le type.

Ca ne me parait pas une évidence.
En fait, il faut peut-être distinguer l’aspect organisationnel et accès de l’aspect utilisabilité de la forge et son ergonomie.
Moi ce qui me gêne le plus c’est d’afficher un fourre-tout dans lequel j’ai des sites de la galaxie, des outils plus ou moins officiels, plus ou moins utilisables, des plugins, des forks de lambda…
Alors si la seule façon d’afficher cela plus proprement comme c’est déjà le cas sur la zone alors non je ne suis pas d’accord avec cette approche.
Si il y a une façon de séparer la problématique et de le faire dans le même temps (pas deux ans plus tard) alors oui je souscris à ta proposition.

18

Je n'ai absolument rien compris à de quoi tu parles. :frowning:

19

Moi ce qui me gêne le plus c'est d'afficher un fourre-tout dans lequel j'ai des sites de la galaxie, des outils plus ou moins officiels, plus ou moins utilisables, des plugins, des forks de lambda...

Stop de reparler 12 fois du même bug. Les forks ne sont PAS visibles dans les orgas, là c'est un BUG d'affichage uniquement de l'installation Gitea de azerttyu. On n'argumente pas sur des bugs, mais sur l'affichage réel normal qui est :
- tu vas sur l'orga "spip-contrib" alors tu vois les dépôts communs uniquement (pas officiel)
- tu vas sur l'orga "spip" tu vois les trucs officiels uniquement (core, dist, outils officiels)
- les forks on les verra que sur la page de chaque utilisateur perso

Une fois dit ça, il n'y a rien de fourre-tout à voir "spip/spip", "spip/medias", "spip/squelettes-dist", et "spip/loader", qui sont 4 choses de type différents (le noyau, un plugin, un squelette qui ne sera pas utilisé en plugin, un outil divers) dans la même organisation "spip". C'est au contraire très bien, ça correspond à qui les maintient. Tout pareil pour "spip-contrib", sauf qu'il y en aura plus en nombre forcément.

Alors si la seule façon d'afficher cela plus proprement comme c'est déjà le cas sur la zone alors non je ne suis pas d'accord avec cette approche.
Si il y a une façon de séparer la problématique et de le faire dans le même temps (pas deux ans plus tard) alors oui je souscris à ta proposition.

Je ne comprends pas vraiment de quoi tu parles.

Si on parle d'affichage, de tri, etc, c'est pas une problématique de devs qui sait à quoi ille veut contribuer à un instant T. Dans ce cas tu vas sur le SITE internet contrib.spip.net et tu cherches ce que tu veux. Et une fois que t'as trouvé, tu sais où c'est développé et tu y contribues.

À aucun moment une forge ne sert à trier *finement* des choses, on a un site internet pour ça, on va pas faire plusieurs fois les mêmes choses.

La forge, sans plugin compliqué sans rien, c'est des dépôts, appartenant à des groupes de gens (orgas, spip-contrib/noizetier) ou à des individus (utilisateurs, eric/montruc ou eric/monforkduntruccommun).

- Si tu participes à Formidable, à spip-cli ou à SpipR, ton utilisateur fait partie de l'orga "spip-contrib", tu vas sur la page de l'orga, t'as un énorme champ de recherche en tout premier, tu tapes "formidable" dedans, et paf, tu visionnes le projet auquel tu voulais participer aujourd'hui.
- Si tu veux découvrir les trucs récents, tu vas sur l'orga "spip-contrib", et déjà de base c'est trié par dernière mise à jour, donc tu vois les dépôts qui bougent récemment.

Ya aucune raison particulière de faire de différence entre les types de projet, ça ça se voit soit en ouvrant le projet, en lisant sa description, son readme.md ou sa doc complète.
Tout dépôt bien configuré doit avoir un nom explicite et une petite phrase de description, et c'est affiché sur toutes les listes (actuellement on ne voit que le nom et quasi aucun n'a de description). Donc par ex pour le site de Programmer dans les listes ça serait affiché

programmer.spip.net
Les squelettes du site de documentation pour devs blablabla.

Qu'on décide de le mettre dans l'orga "spip" ou l'orga "spip-contrib", ya aucun soucis de recherche ni de compréhension. L'orga sert à définir qui maintient le projet, pas à ranger.

20

Re,

Moi ce qui me gêne le plus c’est d’afficher un fourre-tout dans lequel j’ai des sites de la galaxie, des outils plus ou moins officiels, plus ou moins utilisables, des plugins, des forks de lambda…

Stop de reparler 12 fois du même bug. Les forks ne sont PAS visibles dans les orgas, là c’est un BUG d’affichage uniquement de l’installation Gitea de azerttyu.

Inutile d’écrire en majuscules surtout quand tu réponds à coté du sujet.
J’ai cité les forks, oui, mais j’ai cité surtout les plugins, la galaxie, les outils et je trouve que tout mélanger n’apporte pas de clarté.

On n’argumente pas sur des bugs, mais sur l’affichage réel normal qui est :

  • tu vas sur l’orga « spip-contrib » alors tu vois les dépôts communs uniquement (pas officiel)
  • tu vas sur l’orga « spip » tu vois les trucs officiels uniquement (core, dist, outils officiels)
  • les forks on les verra que sur la page de chaque utilisateur perso

Une fois dit ça, il n’y a rien de fourre-tout à voir « spip/spip », « spip/medias », « spip/squelettes-dist », et « spip/loader », qui sont 4 choses de type différents (le noyau, un plugin, un squelette qui ne sera pas utilisé en plugin, un outil divers) dans la même organisation « spip ». C’est au contraire très bien, ça correspond à qui les maintient. Tout pareil pour « spip-contrib », sauf qu’il y en aura plus en nombre forcément.

C’est ton point de vue.

Ya aucune raison particulière de faire de différence entre les types de projet, ça ça se voit soit en ouvrant le projet, en lisant sa description, son readme.md ou sa doc complète.
Tout dépôt bien configuré doit avoir un nom explicite et une petite phrase de description, et c’est affiché sur toutes les listes (actuellement on ne voit que le nom et quasi aucun n’a de description). Donc par ex pour le site de Programmer dans les listes ça serait affiché

programmer.spip.net
Les squelettes du site de documentation pour devs blablabla.
Qu’on décide de le mettre dans l’orga « spip » ou l’orga « spip-contrib », ya aucun soucis de recherche ni de compréhension. L’orga sert à définir qui maintient le projet, pas à ranger.

C’est aussi ton point de vue.
Peux-tu m’expliquer pourquoi la zone est rangée en dossiers sous le root ?
Ce que je dis c’est juste ça, peut-on retrouver ce type de présentation car je suis désolé la première impression de la forge est un peu abrupte sans.
Toi tu t’en débrouilles, d’autres peut-être moins.

En tout cas c’est mon avis, il diffère du tien sur ce point (le reste on est d’accord).
J’ai juste peur que ça rebute et que ce soit encore un frein au passage sur git et cette forge.