Re: Nombre et noms des organisations Git

Le ven. 13 déc. 2019 14:51, cam.lafit a écrit :

> Salut
>
> Premier point, je suis d'accord pour que la situation soit figée
> d'une façon ou d'une autre.
>
+1

> Au final peut m'importe la façon dont c'est structuré du moment qu'on a
> une cohérence explicable.
>

Et Eric propose de garder plus ou moins la même cohérence, puisqu'il s'agit
de migrer et non recréer.

Suivant https://zone.spip.net/trac/spip-zone/browser/spip-zone?order=name
donc, on pourrait avoir :
- spip_core_
- spip_contribs_ (avec les sous-orga : plugins, squelettes, themes)
- spip_galaxie_
- spip_outils_

Après tout, cela a fait ses preuves...


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

Tout à fait. Et ça c'est probablement une autre discussion à avoir.


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

James, si tu nous lis, quel est ton avis ?
Je n'ai pas non plus l'impression qu'il faille avoir un gros fourre-tout
pour Composer mais bien des espaces de nommage cohérents préfixés de
"spip-" pour bien faire.


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