Re: Nombre et noms des organisations Git

Salut

Premier point, je suis d'accord pour que la situation soit figée d'une
façon ou d'une autre.
Au final peut m'importe la façon dont c'est structuré du moment qu'on
a une cohérence explicable.

La suite de la réaction est non bloquante mais il me semble important
de faire les remarques.

> [...] 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. [...]

Tu mélange organisation et équipe, ce sont 2 concepts différents.
Même en ayant cette approche là, tu tomberas toujours sur au moins 2
équipes, les personnes administrant (autrement dit
responsables/propriétaires/...) les projets de l'organisation et les
contributeurs. Ce qui ne correspond donc pas à "QUI est responsable".
Au mieux ce qui serait à "qui participe"

> [...] Elles doivent donc absolument avoir "spip" chacune dans leur nom, pour être sûr de pouvoir les dupliquer ailleurs. [...]

Si un projet déménage de forge, tous les clones devront mettre à jour
le chemin du remote. Modifier ou non le préfixe de l'organisation ne
complexifiera pas la procédure de renommage. Donc non il ne faut
"absolument" pas avoir un préfixe.

> (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.)

Cela se défend dans l'idée d'avoir une cohérence de nommage. Ce point
de cohérence me semble un point important mais cela n'a rien d'absolu.


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

Cela fera un pot pourri et qui va à l'encontre du point composer
précédent vu qu'on mélangera plein de truc différents.
spip est une distribution avec des un core, des plugins, squelettes
(ce qu'on retrouverait dans composer) et tout le reste comme des
outils tiers comme *_loader ou spip-cli.

Autre remarque, est défendu la cohérence de nommage dans le temps
(anticiper les migrations de forge, composer, ...) et en même est
considéré normal le déplacement des projets entre organisation.

> - 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.

Pour l'aspect nommage à proprement parler contrib me semble mieux que
zone, toujours dans cette logique de cohérence.
Pour ce qu'on y met dedans, je ne suis toujours convaincu que ce soit
bien d'en faire un gros fourre tout.
D'autant plus qu'on retrouve déjà sur la zone cette logique de sous
organisation avec les préfixes d'ensemble de projet (acces_restreint,
galaxie, ....)


> 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.

cela reprénd le point distribution/composer discuté plus haut.

> 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".

Les PR sont possibles dans les 2 cas. Ce n'est pas parce que c'est
open bar que les PR sont à imposer ou à proscrire. C'est une
méthodologie de travail.

> 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.

Je ne trouve toujours pas cette proposition simple.
Et comme proposé l'orga pour composer sera un gros fourre tout de truc
qui ne le concernera pas.

> (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.)

Sur ce point je trouve qu'on est à la limite (voire au delà) d'une
forge communautaire. Vu tout ce qui précède, c'est un point qu'on peut
mettre en sommeil le temps de stabiliser/valider le reste.

Pour conclure, comme dit au tout début, un solution même imparfaite
sera mieux qu'une non décision qui s'enlise.

Km
_______________________________________________
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