Je m’aperçois surement tardivement que la page des groupes dans la forge s’est enrichie de groupes non spip-xxx.
Je ne trouve pas ça heureux car ils sont tous avant les groupes spip et que l’on ne sait pas très bien à quoi ils correspondent.
Je ne sais pas si on peut faire des sous-groupes mais si c’est le cas je trouve qu’il serait plus pratique d’avoir un groupe spip-groupes-speciaux ou un nom quelconque et que les groupes escal, giseh ou autres y soient intégrés.
Car si on continue on aura une tétrachiée de groupes à ce niveau.
Pour ma part je dis pourquoi pas, même si plus largement je pense que nos immenses groupes devraient eux meme etre retravaillé pour mieux s’y retrouver (par exemple en reprenant l’arbo de premier niveau de contrib).
Bref, je pense qu’il faut réflechir à la question de manière plus large.
Euh je ne suis pas sur d’avoir envie de maintenir le rangement de Contrib et un autre sur la forge en les synchronisant. C’est déjà suffisamment pénible sur Contrib.
Par contre, je me demande pourquoi finalement ne pas avoir créé ces groupes comme sous-groupes des groupes spip-xxx ?
Non pour des sous-groupes dans spip-* (et puis ce n’est pas l’objet du fil de discussion).
Oui pour regrouper tous les non spip-* à la racine dans un groupe générique.
Pour le nom de ce groupe, spip-quelquechose, et si ce quelque chose commençait par T, U ou V ce serait top, pour que ça le classe (en ordre alpha) après spip-team.
Oui ça ne marche pas si on veut mettre dans un même groupe un squelette et des plugins fonctionnels. Mais autrement je ne vois pas le problème que ça poserait de mettre n plugins dans un sous-groupe de spip-contrib-extensions.
Exactement.
En plus la proposition de @rastapopoulos me parait totalement appropriée.
Maigre petite pierre à l’édifice : conventionnellement, le « vendor/prefixe » du composer.json suit le « groupe/projet » des forges. Ici par exemple on a « seenthis/squelettes » composer.json · master · seenthis / squelettes · GitLab qui correspond bien au groupe / projet.
Il n’est pas courant d’avoir des sous-groupes (mais Gitlab le permet effectivement).
Moi je me demande : on est sur une forge SPIP. (git.spip.net). Pourquoi on se tape à chaque fois le prefix spip (et j’irais même plus loin : pourquoi le préfixe contrib)
Ben parce qu’un jour on a eu une discussion, longue comme tu peux l’imaginer, qui s’est finie ainsi.
C’est un peu facile ces derniers temps de se demander régulièrement ce qu’on fait les abrutis qui ont pris des décisions il y a plusieurs années.
Moi je suis pas un archiviste mais tu dois pouvoir retrouver les échanges de cette période quand Camille et moi avons basculé projet par projet le svn vers git.
Ca m’étonnerait pas de voir aussi tes posts même si je ne peux pas te dire ce que tu avais argué à l’époque.
Je sais @maieul que tu n’as pas cet esprit mais on peut changer en respectant l’existant surtout quand on y participe.
et on pourrait, si on tient à cette organisation qui ne dit rien de qui s’en occupe (tout le monde, donc personne) et de ce qui s’y trouve vraiment, avoir :
Moi je ne suis pas contre ta proposition, je me suis juste étonné de voir apparaitre des groupes à ce niveau sans concertation sachant que nous avions l’habitude des n groupes spip-xxx.
Si on doit changer de paradigme et que cela a un sens, faisons-le, mais expliquons le svp.
Par contre, je ne suis pas pour une logique « typologique » car il en existe une qui est difficilement maintenable et dont je m’occupe seul. Il faut que l’endroit où on crée un projet soit évident comme pour spip-xxx.
non mais c’ets quoi ce discours à la mord moi le nœud ? d’où tu juges mon esprit ? d’ou tu considère que je voudrais changer sans respecter l’existant sous pretexte que je pose une question ?
Et ce n’est pas parce qu’une discussion a eu lieu à l’époque que les choses sont nécessairement figés. Et à ma connaissance je n’ai jamais traité quiconque d’abrutis. MAis un choix pouvait se justifier à une époque et à un moment on peut se dire que peut être ce n’est plus adapté. Moi ce que je constate empiriquement c’est qu’on se retouve avec des noms à rallonge dont il faut se souvenir à chaquer fois de tous les composant, avec le risque de faire des erreurs. c’est tout.
Par contre, je ne suis pas pour une logique « typologique » car il en existe une qui est difficilement maintenable et dont je m’occupe seul.
bah ca ca tient aussi aussi au fait qu’il n’y a pas actuellement de corrélation directe entre l’arbo contrib et l’arbo typologique. Et c’est pas faut d’avoir dit à l’époque de la refonte de contrib qu’il faudrait idéalement calquer automatiquement l’un sur l’autre. Bref…
Il faut que l’endroit où on crée un projet soit évident comme pour spip-xxx.
c’est effectivement un argumetn qui se tient de dire qu’il faut une logique très simple pour facilement créer. Ok sur ca.
@eric_tonton désolé, mes excuses. Lorsque j’ai lu « tu n’a pas cet esprit » j’ai compris « tu n’a pas un esprit qui veut respecter l’existant » et pas « tu n’a pas un esprit qui ne veut pas respecter l’existant », Bref j’ai compris de travers ce que tu voulais dire.
Dossier clos pour ma part sur cet incident. Avancons donc de l’avant.
@maieul le résumé des choix passé est assez simple :
il y a « spip » parce que justement le but c’est que les groupes Git correspondent aux vendor Composer, que ce n’est pas parce que est sur notre forge perso, que les dépôts (y compris le nom de l’orga parente !) ne se retrouvent pas dans la nature ensuite (packagist ou autre). Et donc c’est très bien qu’il y ait le mot « spip » à chaque fois pour savoir immédiatement que c’est un projet/orga pour SPIP.
il y a « contrib » dès qu’on veut distinguer tout ce qui fait partie de la contribution collective (fonctionnel, squelettes, thèmes), de ce qui est du ressort de l’équipe noyau (même si depuis elle a été sous-découpée en plusieurs équipes, mais ça ne change rien qu’il y a quand même plus de droits et de responsabilités sur les composants noyaux).
@eric_tonton pour ce qui est de justifier (et de savoir si ya eu une décision collective ou pas), perso ya eu quelques échanges mais je n’ai pas du tout eu l’impression qu’il y a eu une décision en commun. Personnellement j’ai toujours été contre que pour la plupart des cas on fasse des organisations séparées autre que la collectivité contrib. Je n’ai jamais été fermé non plus : j’ai toujours dit que ça devrait se faire très ponctuellement et au cas par cas, uniquement si ya une justification forte de sécurité par exemple (exemple typique : plugin Bank à mettre dans une orga dédiée avec moins de personnes qui ont le droit de fusion et commit master). Mais que si ya pas cette justification, alors si on utilise la forge communautaire, bah c’est le jeu d’être dans les orgas communautaire où on a des droits communs (versus « son ptit droit perso dans son coin »).
(Et si on prend Seenthis comme exemple : typiquement 80% des trucs dedans sont des plugins fonctionnels génériques qui n’ont rien à faire dans l’orga Seenthis et qui pourrait être utiles à tout le monde et non pas juste au site de Seenthis : microcache, calcul de date, détecter la langue, etc, etc : ça devrait être dans spip-contrib-extensions et pour moi ya aucune justification à l’avoir là séparé)
Juste pour clarifier le « 80% sorti du chapeau » : seenthis · GitLab contient 12 plugins à ce jour, et la liste que je pointe plus haut 5 plugins, ce qui ne fait pas 80% de 12
Et pour la question de « la généricité » de ces 5 plugins et de leur utilité pour le grand public, j’aimerais bien avoir un chiffre vérifié de leur usage ailleurs que dans seenthis sachant que la plupart n’ont pas de doc (et donc n’existent pas).
Si jamais ces plugins étaient vraiment publics, peut-être que d’autres personnes que celles qui maintiennent seenthis pourraient participer à leur maintenance, mais à ce jour, ça n’est pas le cas.
Donc, pour moi, il y a (pour l’instant) justification à les coller dans une orga seenthis
même si je ne peux pas te dire ce que tu avais argué à l’époque.
avec