Re: Nombre et noms des organisations Git

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