Re: Nombre et noms des organisations Git

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 :)
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

Le lun. 12 août 2019 à 17:54, Eric Lupinacci <[email protected]> a écrit :
>
> Yop,
>
> Le lun. 12 août 2019 à 17:20, Cerdic <[email protected]> a écrit :
>>
>> 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é.
>
> ++
> Eric
>
> _______________________________________________
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: http://www.spip.net/
> dev: http://trac.rezo.net/trac/spip/
> irc://irc.freenode.net/spip
_______________________________________________
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip