Re: Nombre et noms des organisations Git

Hello,

Vu qu'on est toujours bloqué dans l'utilisation de Git, j'en profite pour
continuer à creuser le sujet de la typologie des repos et pour parler de
l'API Gitea.
J'ai essayé cette API REST est c'est quand même très intéressant.
Il existe d'ailleurs une commande assez sympa : /orgs/{org}/repos qui
renvoie la liste des repos d'une organisation.
Aujourd'hui avec l'organisation "plugin" (sans S d'ailleurs ce qui est pas
très intuitif) je peux récupérer tous les plugins en repo Git.
Je trouve cela très pratique et d'ailleurs je veins de m'en servir pour
construire un petit outil pour générer un bash d'installation (un peu comme
git_loader).

Supposons que l'on regroupe dans l'organisation Contributions les plugins,
les sites de la galaxie, etc, la même requête va me fournir d'autres repo
que je ne saurais pas qualifier : plugin ? site galaxie ? autre ?
C'est franchement dommage.
Y aurait-il quand même un moyen d'isoler les plugins ?

Je pense toujours que de pouvoir déterminer la nature du repo est et
restera toujours intéressant.
Maintenant je ne sais pas si il faut absolument passer par l'organisation
ou si on pourrait faire autrement.
A vous lire.

++
Eric



++
Eric


Le sam. 14 déc. 2019 à 09:08, Gildas Cotomale <[email protected]> a
écrit :

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