Quand on est coincé pour faire un truc sur git, on fait quoi ?

Général
#1

Ok, donc :

  • Le groupe git spip-contrib-extensions est historique. Les dépôts qu’il contient proviennent de l’ancien dépôt subverson(svn) « spip-zone » qu’on a utilisé jusque y a pas si longtemps
  • Il a été décidé qu’il fallait qu’on passe à git MAIS qu’on reste à un fonctionnement dit « horizontal » où tout le monde peut commiter partout
  • En conséquence de quoi, tout le monde (les users subversion importés dans git et les nouveaux) est « dev » de tous les dépôt de ce groupe
  • En passant à GitLab, on a importés tous les users et les dépôts et la distribution des rôles est restée la même en gros
  • Les nouveaux inscrits post-migration, eux, ne sont dans aucun groupe (et ne s’en plaignent pas a priori, vu que ça n’empêche pas de créer des issues, des commentaires, de forker des dépôts, de faire des PRs)

Mais :

  • les users importés ont des rôles standards GitLab : developper, maintainer (et pourraient en avoir d’autres : reporter, guest, owner mais on s’en fout)
  • un·e developper peut déjà faire beaucoup : créer des projets, créer des branches, pousser des commits dedans, créer des tags, …
  • un·e maintainer peut aller plus loin : transférer des dépôts entre groupes, et, en fonction des paramètres du groupe ET de la personnalisation des paramètres de chacun des projets qui sont dedans, iel peut merger, poussesr dans une branche protégée, accéder aux paramètres (comme le logo du dépôt) et des opérations avancées (comme archiver unn dépôts)
  • être admin gitlab apportent d’autres possibilités, notament sur les users qui s’incrivent…

Et sur notre plate-forme, on a, à peu de choses près, 14 personnes qui sont admins ET maintainer du groupe spip-contrib-extensions. Tous les autres membres de ce groupe sont developper.

Très peu de monde demande à accéder à un groupe (depuis février, je n’ai vu que 2 demandes (pour spip/*). Comme dit plus haut, c’est pas une grosse nécessité.

Il n’y a pas de concertation entre admins, chacun·e fait ce qu’iel veut et n’a pas de compte à rendre ni de communication à faire a priori.

Les opérations impossibles pour les developpers doivent donc être effectuées par un·e maintainer/admin et y a pas une grosse comm’ sur qui sont ces 14 personnes. (vous savez au moins, compte tenu des échanges de ce sujet qu’il y a @b_b et moi)

Pour que les developpers actuels du groupe spip-contrib-extensions soient un peu plus autonomes pour les plugins qu’iels maintiennent concrètement, serait qu’iels soient promu·e·s maintainers du groupe … Et donc de TOUS les dépôts git du groupe (940 à l’heure actuelle, dont 724 actifs (i.e. non-archivés), 549 membres, dont 79 actifs)

Tout ça afin qu’iels soient autonomes sur un ou quelques plugins, en général, pas la totalité…

L’alternative serait de leur donner des droits au cas par cas, dépôt par dépôt, user par user … Vous, je ne sais pas, mais moi, les comptes d’apothicaires, ça me file des boutons …

Sinon, au risque de passer pour de vils libertariens, confier des groupes de plus petites tailles à un plus petit nombre de personnes afin qu’iels s’y auto-organisent … (assistance gratuite de ma part aux demandeurs)

Plugins incompatibles avec SPIP4.1 ou plus
#2

je n’ai pas bien saisi la proposition… ton idée c’est de passer tous les developper du groupe spip-contrib-extensions en maintener ?
ou alors que, au coup par coup lorsqu’un developper exprime qu’il a besoin de gérer des plugins dont il s’occupe de le passer en maintener ?

1 « J'aime »
#3

Je ne propose rien :slight_smile:

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 :wink:

Mais c’est un bon résumé @cy_altern, merci :slight_smile:

#4

La situation actuelle pose t’elle un problème ?

#5

(arf bizarre en envoi email j’ai ce fil SAUF le tout premier message… du coup je ne comprenais que dalle :stuck_out_tongue: )

#6

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.

#7

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…

#8

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

#9

Je me positionne :stuck_out_tongue:

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 :stuck_out_tongue:

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 » ? :slight_smile:

2 « J'aime »
#10

On sait bien que SPIP est politique, mais est-ce que c’est perdre notre identité que de nous organiser « un peu » ? :slight_smile:

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

#11

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

  1. Le fait de créer des sous groupes thématiques : tant que personne n’en éprouve le besoin, je ne vois pas pourquoi faire
  2. 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.
#12

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 ?

#13

Tout le monde était developper ou tout le monde était maintainer ?

#14

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

#15

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.

#16

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.

#17

Est-ce qu’un⋅e maintenaire peut faire des trucs irrécupérablement irréversibles ?

#18

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 :stuck_out_tongue:

#19

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.

#20

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…