Salut,
à la base il avait été décidé que les branches master de l’orga spip serait protégées en écriture.
Sage décision pour les boulets étourdis comme moi.
Mais il semblerait que ça ait été appliqué à tous les dépôts de toutes les orgas.
Quelqu’un peut confirmer ?
Je n’ai pas vu passer d’annonce en ce sens, mais je l’ai peut être ratée.
D’après ce que je lis ici : https://git.spip.net/spip-contrib-outils/ddev/-/settings/repository/branch_rules?branch=master la formulation me ferait penser intuitivement à un réglage global de Gitlab qui aurait été activé, suite à une mise à jour ?
Par contre, ça :
ça pourrait être problématique.
Si je veux push --force pour corriger instantanément une boulette justement en tant que mainteneur, je peux pas ?
Ça semble être ici : Connexion · GitLab
Sauf que ça cause de main et que ça dit que « Allowed to push Developers + Maintainers »
A la base j’avais testé sur mon dépôt ddev, et mon push distant sur master avait été rejeté :
remote: GitLab: You are not allowed to push code to protected branches on this project.
To git.spip.net:spip-contrib-outils/ddev.git
! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'git.spip.net:spip-contrib-outils/ddev.git'
Donc je suis pas sûr 
Pour préciser je trouve très bien que toutes les branches [master|main] soient protégées.
Quand on avait décidé ça pour le core (et plugins), j’avais proposé d’étendre à toute la zone mais on m’avait dit que non, que c’était à chacun de voir sur ses projets.
Moi je suis pour, ça évite les boulettes (
), et de se faire rentrer dans le lard direct sur ses projets, sans même un « Bonjour madame comment allez vous il est beau mon commit hein c’est moi qui l’ai fait ».
C’est bon, on est sortis de SVN là, on n’est plus chez les sauvages 
L’idéal (pour moi), serait :
Et là, je vois un hic : les personnes qui créent un dépôt n’en sont pas déclarées mainteneuses…
En tout cas, j’ai parcouru quelques dépôts créés récemment et ça ne semble pas être le cas.
Ça c’est un problème aussi, pour moi, si on se cale sur les droits que je cite au dessus (basés sur le rôle « Maintainers »)
Actuellement les rôles « maintainer » et « developper » sont attribués de manière horizontale, sur toute la forge.
Pour « developper » partout c’est légitime, pour « maintainer » il est légitime qu’un groupe défini (team) le soit partout, mais il faudrait que les gens qui créent un dépôt le deviennent automatiquement.
Je ne sais pas si c’est possible, je ne vois pas ça dans les options de la GUI.
Probablement possible avec un system hook.
Je me demande si c’est pas simplement le comportement par défaut sur les nouveaux projets, ddev tu l’avais mis assez récemment non ?
Premier commit le 28/09/2022 : Script complémentaire à DDEV pour pouvoir installer et utiliser spip-cli dans... (2d3de587) · Validations · spip-contrib-outils / ddev · GitLab
c’est ce que tu appelles récent ?
Ah ! Bah je comprends mieux pourquoi je n’arrive pas à pusher mon code dans le nouveau projet que j’ai créé dans ma zone perso 
Oui.
Du coup, il serait bon de multiplier les groupes git, de ventiler les projets existants dans ces groupes qui serviraient d’orga où les membres pourraient choisir leurs règles (de coding, de PRs, de membership, etc.); ça apporterait de la cohérence et de la visibilité sur les modes de contributions.
Et pour celleux qui souhaitent développer des projets perso (ou du moins, commencer par ça) d’utiliser les espaces perso (ça se fait déjà, faudrait démocratiser la pratique, je pense)
Je pense à l’inverse qu’on devrait trouver un fonctionnement sécurisant qui convient à l’immense majorité des cas, et qu’il ne faut PAS partir sur des tonnes d’orga avec des fonctionnements différents.
Que de manière hyper ponctuelle pour tel projet précis super sensible (genre plugin Bank) on ait besoin d’un autre fonctionnement encore plus bloquant ok. Mais ça devrait rester des cas super rares.
Dans SPIP on a toujours eu un fonctionnement collégial et communiste, ou le plus possible de gens ont les mêmes droits, et où le fonctionnement global est le même partout. Contrairement à Github où on individualise tout, le libéralisme codal (et la main invisible fera magiquement que l’addition de tous les individualismes augmentera l’innovation et la croissance).
Donc qu’on renforce la sécurité en ajoutant des étapes (PR etc) avant de pouvoir intégrer, ça c’est super, vraiment. Mais de mon avis, pas en poussant volontairement à l’éclatement en plein d’espaces persos séparés avec des règles différentes. On n’est pas chez les libertariens ici.
Je pense aussi, pour les même raisons.
J’ai regardé, tu es bien Maintenair dans le groupe spip-contrib-outils cf Membres du groupe · spip-contrib-outils · GitLab tu peux donc pusher. Mais, comme on peut le voir dans la capture d’écran que tu postes, la case « Autoriser à forcer les poussées » n’est pas cochée, voilà pourquoi ton push force ne passe pas.
Je ne pense pas que ça soit une bonne idée d’autoriser le push force sur les branches protégées de manière globale, mais c’est possible de le faire au cas par cas exemple avec ddev ici https://git.spip.net/spip-contrib-outils/ddev/-/settings/repository
Si je ne me trompe pas, les accès au dépôts sont définis par défaut à partir du groupe de l’organisation dans lequel le dépôt est créé. Exemple avec Membres · spip-contrib-extensions / dumpauto · GitLab où on voit bien les 529 membres du groupe Connexion · GitLab
Or, tous les membres du groupe n’ont pas les même rôles, certaines personnes sont maintenair et d’autres developper (ce qui ne permet donc pas à tout le monde de fusionner).
Non justement, ça peut être appliqué de manière différente dans chaque groupe.
C’est sur quel repo ? (histoire qu’on y jette un œil)
Hello,
Pas vraiment au niveau de compétences de vos échanges mais il se trouve que c’est moi qui ait créé le repo pris en exemple spip-contrib-extensions / dumpauto · GitLab
J’y suis effectivement developper, ce qui ne m’empêche pas (heureusement !) d’y faire mes push. Par contre j’ai constaté que ne n’avais pass accès au Settings anecdotiquement pour y mettre un avatar. Sans être vraiment gênant, c’est un effet de bord de mon rôle developer dans cette organisation ?
Merci de vos avis !
C’est la différence entre créer un projet dans son propre « namespace » (on est owner) et créer un projet dans un groupe pré-existant ou les rôles sont pré-déterminés (et là, c’est variable).
Ok, c’est clair. Il me semblait que j’y avais accès précédemment sous Gitea, mais peut-être les règles était différentes.
Merci pour l’explication. 
J’en doute, mais Gitea, la migration GitLab, le nombre d’admins des plates-formes, ce qu’on pouvait faire, peut faire aujourd’hui et ne pas faire … ça rend les choses très compliquées à expliquer. De plus, bien que technique, c’est sujet à interprétations, pas bien maîtrisé par assez de gens : On finit par en dire n’importe quoi. 
@Loiseau2nuit donc sur tes deux repos persos tu es owner, le rôle le plus haut, tu peux donc « normalement » tout y faire cf Connexion · GitLab & Membres · Loiseau2nuit / zktx-kore · GitLab
Quand tu dis ça, que tentes-tu de faire précisément (quelle commande, dans quel contexte), et quelle est l’erreur renvoyée par la forge ?
Sa branche par défaut (master chez lui) n’autorise pas le force push, c’est tout.
