Je ne propose rien 
J’'expose des cas de figure.
Pour que la communauté, et les admins git ;), puisse se positionner et qu’on trouve un consensus. Ou que rien ne se dise ni ne se passe, on verra 
Mais c’est un bon résumé @cy_altern, merci
La situation actuelle pose t’elle un problème ?
(arf bizarre en envoi email j’ai ce fil SAUF le tout premier message… du coup je ne comprenais que dalle 
)
J’ai pas franchement d’opinion. Aller vers des plus petits groupes thématiques pourrait me plaire, si on arrivait à avoir une idée de comment découper. Mais bon cela ne me parait pas non plus indispensable à ce stade, sauf si cela permettrait de valoriser des gens / empowerer ces gens en leur affecttant des missions précises pour elleux.
Il y a déjà des groupes thématiques, qui ne déplacent pas les foules.
Pour ce qui est de balkaniser la zone, je suis contre, comme déjà dit.
Il y a un fonctionnement historique et horizontal (tout le monde peut dev dessus) auquel moi je tiens encore.
C’est une pratique politique spécifique à SPIP, ne perdons pas notre identité en faisant tout comme les autres…
Ça vient de là je crois : Plugins incompatibles avec SPIP4.1 ou plus - #16 par JamesRezo
Le split en question n’a pas généré de notif, je n’avais pas compris non plus comme je suis tout ça par mail.
Je me positionne
Passer les developpers du groupe spip-contrib-extensions en maintenair, non, ça ne serait pas tenable/sérieux. Pour rappel, une personne maintenair à accès beaucoup de choses cf Permissions and roles | GitLab
Oui, tout le monde peut dev partout, mais depuis le passage à git on s’est discipliné⋅es, on passe par de PRs et on n’envoie plus dans le lard en mode yolo svn
Donc, si on créait des groupes plus spécifiques, rien n’empêcherait de « dev partout » puisqu’on pourrait toujours proposer des PRs partout.
On sait bien que SPIP est politique, mais est-ce que c’est perdre notre identité que de nous organiser « un peu » ?
2 « J'aime »
On sait bien que SPIP est politique, mais est-ce que c’est perdre notre identité que de nous organiser « un peu » ?
Oui si ça veut dire que de manière plus que ponctuel (le core et quelques rares plugins particuliers comme Banque) on se retrouve avec beaucoup de différences entre les droits des gens.
On peut parfaitement être organisés (faire des PR etc) tout en ayant au plus possible les mêmes droits. Séparer de plus en plus, avec seulement certaines personnes qui peuvent fusionner ou faire ceci cela en plus, c’est infantiliser l’ensemble des gens, et retirer encore plus l’horizontalité.
j’ai un peu du mal à suivre, je dois me referais à chaque à la doc pas tjr évident.
Actuellement si j’ai bien compris les « ancienn·es » peuvent tout faire ou presque. Les « nouveaux/nouvelles » ne peuvent pas :
- pusher sur les branches protégées, mais pour l’instant sur spip-contrib-extensions j’au pas l’impression qu’on s’en serve (bien que je serai assez favorable, ne serait-ce que pour éviter les erreurs, sur main/master)
- archiver / supprimer / etc
bon, le cas 2 ca arrive, c’est pas hyper fréquent, mais si on peut bipper facilement l’équipe de maintenance et que c’est documenté, ca ééviterait que cela porte sur « le plus rapide à lire le message »
Pour moi il faut distinguer deux choses
- Le fait de créer des sous groupes thématiques : tant que personne n’en éprouve le besoin, je ne vois pas pourquoi faire
- Les droits/la methode sur les groupes générique : j’ai vraiment l’impression qu’on arrive à se discipliner, donc le statut quo m’irait bien en fait.
Ah j’ai oublié un truc aussi : de mémoire à aucun moment les anciens importés et les nouveaux ne devaient être différents. En effet, sur Gitea il y avait censément un script lancé sur le serveur (par @azerttyu ou en cron je ne sais plus) et qui assignait automatiquement en masse les bonnes équipes, droits, etc aux nouveaux comptes. Et donc à la fin tout le monde avait bien sensiblement les mêmes droits. Sauf que ça n’a pas été reporté pour Gitlab non ?
Tout le monde était developper ou tout le monde était maintainer ?
Ça je ne sais pas/plus, ni si le découpage des droits étaient le même sur gitea et sur gitlab. À priori assez fort pour pouvoir modifier les dépôts déjà existants, créer des branches et faire des fusions : pas seulement pouvoir faire des PR uniquement (encore moins que depuis des dépôts privés, pas directement dans le plugin lui-même). Pour ce qui est des plugins fonctionnels, squelettes, et thèmes.
On peut effectivement élargir ce débat aux autres groupes historiques spip-contrib-themes et spip-contrib-squelettes … c’est le même constat, les mêmes pratiques et j’imagine, le même argument « politique » …
Avec, ceci-dit, moins de projets git et pas exactement le même nombre de personnes historiquement membres. Allez savoir pourquoi.
Hello
Comme l’indique @rastapopoulos, en effet avec gitea on affectait systématiquement les nouvelles personnes au groupe « spip-contrib » qui avait des droits d’éditions élargis sans être pour autant de type propriétaire. Ainsi les droits étaient identiques car on travaillait au niveau du groupe et non du compte.
Et on a fait évoluer les droits du groupe en fonction des contraintes identifiées au fil de l’eau.
L’approche horizontale était acceptée/voulue à l’époque de SVN, puis défendue lors de la bascule à Git/gitea. Cette horizontalité est un choix assumé lors de la bascule vers git et faisait partie du cahier des charges lors de la migration. (ce pourquoi certaines forges git ont été exclues)
Sur l’organisation actuelle avec gitlab , il semble que l’approche est autre et ce qui a été décidé en petit comité est une approche verticale. Et cela inclus, à mon sens le concept de groupe tel que mis en place.
@JamesRezo git ne coince pas en l’état. C’est un choix « politique » lors de la migration à Gitlab de passer sur ce mode de fonctionnement.
Ce qui est au passage était une des alertes remontée lors du gros coup de balai de début d’année.
Donc exposer ceci maintenant de cette façon me semble assez étrange.
Est-ce qu’un⋅e maintenaire peut faire des trucs irrécupérablement irréversibles ?
Je disais plus haut :
Plus précisément pour les repos Permissions and roles | GitLab
On peut y lire pour qu’une personne maintainer peut « Delete protected branches ».
Je vous laisse lire tout ça en détail, j’arrête là mon TLDR
Hello
Les profils de type mainteneur, propriétaire ont des droits assez (trop ?) élargis. Il est préférable d’éviter de les attribuer sans garde fou.
L’avantage de git c’est qu’on peut (quasi) toujours reprendre/restaurer/réparer un dépôt mais pas forcément sur les parties MR/PR/tickets qui sont propres au fonctionnement même de chaque forge et donc de leur système de sauvegarde et maintenance.
Du coup un ‹ administrateur › peut faire des actions irrévocables ce qui peut être problématique selon les cas.
Je vois qu’il y a déjà des groupes qui ont été créés.
Quand on demande à temporiser cette façon de faire parce que, pour certains, ça ne va pas, autant pisser dans un violon.
Et donc, le plugin centre_image a été déplacé dans le groupe 23Forward https://git.spip.net/23forward et on ne le trouve plus par une recherche.
Déjà, pour chercher (en théorie) dans tous les groupes, il faut penser à aller, à gauche, sur projets, et pas dans spip-contrib-extensions.
Mais de toute façon, cette recherche globale ne remonte rien :
https://git.spip.net/dashboard/projects?name=centre
Il faut donc savoir dans quel groupe le plugin est rangé.
Ce qui n’est pas non plus évident parce que la page principale des groupes (https://git.spip.net/dashboard/groups) ne les montre pas.
Là encore, il faut aller à droite cette fois sur « Explorer les groupes ».
Alors c’est peut être (j’espère) juste un problème de config / visibilité du groupe, mais ça confirme ce que je pense (du mal) de cette balkanisation, où chacun fait son truc dans son coin avec sa visibilité et ses règles.
Franchement, autant se le faire sur github son groupe hein, pour bénéficier de l’effet réseau social…
Et pourtant, le groupe 23forward est bien public :
Et même punition pour le groupe Seenthis aucun résultat lors d’une recherche globale sur un de ses plugins, microcache :
https://git.spip.net/dashboard/projects?name=microcache
Au temps pour moi, je ne suis pas sûr que ce groupe ait été créé récemment (?) mais je n’arrive pas à voir la date.
J’ai souvent peiné à trouver ce que je voulais sur git.spip.net, indépendamment des nouveaux rangements.
Par exemple, en partant de la page d’accueil https://git.spip.net, la grande zone de saisie de la recherche n’est pas la bonne (elle ne cherche que dans mes espaces), il faut utiliser la petite zone de recherche dans la colonne gauche.
- si je cherche
spip_loaderil trouve tout de suite - mais « forum » ne ramène rien de pertinent. Faut il approfondir avec l’effrayant « Chercher dans tout gitlab » ? Oui, et encore, le désiré
spip/forumapparaît en dernière position. - idem pour
statistique,centre_imageau passage et pour plein de noms de repo de la dist.
Ce serait bien de booster le référencement de la dist.
Et dans quoi cherche t il donc spontanément, si ce n’est dans « tout gitlab » ?