Problem/Motivation

Based off a discussion on slack: https://drupal.slack.com/archives/C1BMUQ9U6/p1699955494119689

Currently you are only granted the Gitlab-maintainer role when you have both the write to vcs and administer maintainers. The Gitlab-maintainer is required to be able to change project configurations like the default branch on GitLab.

I think the requirement to have "administer maintainers" is a bit excessive. I've recently become co-maintainer of a bunch of different modules where the original maintainer no longer is active. But having to request now to become full maintainer just to change the default branch is a bit too much for me.

Steps to reproduce

- Be a co-maintainer without the administer maintainers permission
- Go to GitLab --> You don't have the cogwheel to change the project settings
- Grant administer maintainers permission
- Go to GitLab --> You have the cogwheel to change the project settings

Proposed resolution

Open to discussion, but I think it would be better to use the administer releases permission in combination with the write to vcs. Given you can administer releases, and thus create new branches/dev releases/... you should in my eyes also be able to change the default branch.

@drumm explained the reasoning behind this:

Maintainer access in GitLab’s grants you access to add more maintainers in GitLab

Hence why the administer maintainers is used to grant you Maintainer access in GitLab. Because of the limitations of the roles and permissions in GitLab (which can't be changed) I think the real end solution here would be to bring back the "default branch tab" on Drupal.org which could make a GET and POST/PUT request to GitLab to get the current value and post the changed value.

Form logic suggestion:
GET request to fetch all branches -> Rendered as radio button list, default branch selected -> PUT request when saving.

Remaining tasks

Create pull request/patch

Comments

BramDriesen created an issue. See original summary.

bramdriesen’s picture

bramdriesen
he/him
Primary language Dutch
Location Belgium 🇧🇪🇪🇺
commented
Issue summary: View changes
bramdriesen’s picture

bramdriesen
he/him
Primary language Dutch
Location Belgium 🇧🇪🇪🇺
commented
Related issues: +#3196581: Give project maintainers GitLab maintainer access

Linking the ticket that added the logic for granting people Maintainer role on GitLab after the migration.

bramdriesen’s picture

bramdriesen
he/him
Primary language Dutch
Location Belgium 🇧🇪🇪🇺
commented

So the reasoning behind this:

Maintainer access in GitLab’s grants you access to add more maintainers in GitLab

Hence why the administer maintainers is used to grant you Maintainer access in GitLab.

Because of the limitations of the roles and permissions in GitLab (which can't be changed) I think the real end solution here would be to bring back the "default branch tab" on Drupal.org which could make a GET and POST/PUT request to GitLab to get the current value and post the changed value.

bramdriesen’s picture

bramdriesen
he/him
Primary language Dutch
Location Belgium 🇧🇪🇪🇺
commented
Title: Change logic to grant maintainers the permission to change the default branch of a project » Bring back the "default branch" tab under project settings on Drupal.org
Issue summary: View changes
cmlara’s picture

cmlara
he/him
commented

I'm going to suggest that this isn't a good idea to implement.

I've recently become co-maintainer of a bunch of different modules where the original maintainer no longer is active. But having to request now to become full maintainer just to change the default branch is a bit too much for me.

I think this is actually our messaging regarding adopting projects that is at fault. I have been suggesting those who are trying to make a module D10 ready that they don't become a co-maintainer apply instead they apply to become the project owner from the start (this also reduces the number of people to contact).

If a project is abandoned it doesn't need another co-maintainer it needs someone who will stand up, who can direct without any fear of reprisal from another maintainer and with the ability to take action to promote new maintainers to help them. Traditionally in the open source world we do this as forks, on D.O. we do this as supply chain attacks(adoptions).

Many other features are tied to the GItLab Maintainer role, these are features that an active managing maintainer should have. They, like the "default branch" setting control the strategic direction of a project (even if most users don't use these features.)

While I would prefer GitLab had flexible permissions it seems reasonable these are linked, when you look around the UI the 'default branch' setting plays into so many more options, such as controlling push access to protected branches . Adding a D.O. backdoor would make it harder to apply permissions inside GitLab and know they are enforced and pose a risk at code bypassing advanced maintainer controls.

drumm’s picture

drumm
he/him
Location NY, US
commented
Status: Active » Closed (won't fix)

While GitLab overall does not make a significant difference in how much we have to maintain on Drupal.org, we do want to keep integrations minimal whenever possible.

#3328663: Remove versioncontrol_project_git & versioncontrol_project_issue submodules is where this was removed, for some idea of how much code this was.

bramdriesen’s picture

bramdriesen
he/him
Primary language Dutch
Location Belgium 🇧🇪🇪🇺
commented

I think this is actually our messaging regarding adopting projects that is at fault. I have been suggesting those who are trying to make a module D10 ready that they don't become a co-maintainer apply instead they apply to become the project owner from the start (this also reduces the number of people to contact).

Yeah, I guess this is the real "problem". I'll have to endure the pain and go through the process again to become a full maintainer then.

Good points, the more I think about it the more it makes sense to close this as won't fix 😁