Problem/Motivation
The core of the GitLab Acceleration initiative is unlocking our self-hosted GitLab’s full feature set on git.drupalcode.org to provide collaboration tools that match the expectations of developers familiar with tools like GitHub.com and GitLab.com. The scope of this issue is to enable GitLab issues, and establish a fork/merge-request workflow for Drupal projects.
However, we also want to preserve Drupal’s culture of collaboration. In the Drupal project we encourage developers to work together on issues, and strive to avoid the proliferation of many forks and work being siloed in different places.
Requirements
- People should be able to begin the collaboration process from any of the places these contribution tools allows:
- Beginning with an issue
- Beginning with GitLab’s WebIDE while browsing a repository
- Beginning with a fork
- Beginning with someone else's issue/fork/merge request
- People should be able to collaborate on a single solution (the same fork/branch/merge request)
- When more than one person wants to collaborate on the same solution, they should not be required to each make separate forks and separate merge requests
- People should not have to wait for a maintainer or collaborator to grant access to update an issue, propose a code change, or to perform other work toward resolving issues
- Maintainers must be able to collaborate on the merge requests to their projects (not just whether or not to merge, but the underlying fork/branch the merge is coming from)
Preferred Solution: Shared Issue Workspace
Resolved blocker: Bug in Gitlab with forking into shared namespaces with the Developer role.
- All users can fork a project into the issue forks group
- GitLab issues will be enabled for the canonical projects. A migration script will be written to migrate existing issues from Drupal.org to GitLab issues #3265096: Move issues from www.drupal.org to git.drupalcode.org. Issues will be disabled for the forks, so issues don't get lost away from the canonical project queue.
- Forking and gaining access to existing forks will work similar to issue forks on Drupal.org issues. A comment will be posted to each issue on GitLab with information on contributing to forks and updating credit/attribution information
Alternate Solution: Personal Namespaces
- All users will have permissions to fork a project into the issue forks their personal namespace on
git.drupalcode.org. GitLab’s UI is designed for using forks - for example, if you do not have access to edit
a file, GitLab prompts to create a fork -
When a fork is created in a personal namespace, an automated process will grant all users on
git.drupalcode.org the GitLab 'Developer' role on that fork, so they can collaborate.- Unlike on GitLab or GitHub, these forks will be collaborative by default
- The fork owner may choose to remove that access
-
GitLab issues will be enabled for the canonical projects
- A migration script will be written to migrate existing issues from Drupal.org to GitLab issues
- Metadata will be migrated into labels in GitLab.
- GitLab issues will be disabled for the personal forks
- This is to encourage users to open issues in the canonical project queue.
-
Project pages and packaging remain on Drupal.org
- This should help prevent a fork from being promoted as the canonical source for a Drupal project
- It also ensures we're only advertising the canonical projects to Packagist/Composer.
Definitions
- Canonical project - a project on Drupal.org that has releases, maintainers, a canonical GitLab project, etc.
- Canonical projects are the only ones that appear on Drupal.org project listings and in the composer endpoints.
- Group - a collection of projects in Gitlab with its own namespace
- Groups can define common labels, permissions and other settings for the projects they contain.
- Canonical projects live in the 'project' namespace: git.drupalcode.org/project.
- Issue forks live in the 'issue' namespace: git.drupalcode.org/issue
These are forks of the canonical projects where contributors collaborate.
- Issue forks - a fork of a project created in the Issue group on
Implementation
#3313979: Give everyone with git.drupalcode.org commit access to all issue forks can be done at any point, sooner is better, to get the current Drupal.org issue workflow closer to the future workflow.
#3317273: Set up a Drupal.org GitLab issues bot to handle comments commanding the bot to create an issue fork, and giving people information about how to contribute to issue forks.
Comments
Comment #2
irinaz commentedComment #3
irinaz commentedComment #4
hestenetComment #5
hestenetComment #6
irinaz commentedComment #7
irinaz commentedComment #8
irinaz commentedComment #9
irinaz commentedComment #10
irinaz commentedComment #11
markdorisonComment #12
drummWith the Drupal.org issue queue comes DrupalCI. DrupalCI won’t be integrated with GitLab, since we will have GitLab CI. To avoid a gap in testing, every project will need to first complete a transition to GitLab CI and have DrupalCI disabled. See #3261803: Using GitLab CI instead of Drupal CI to track progress.
In the meantime, we can start some pre-work on the issue migration, while we ensure GitLab CI and integration via issue forks works well enough.
Comment #13
aaronmchaleQuestion: sometimes issues move between projects, this is a convenient feature of Drupal's issue queue, for example issues might move from the ideas queue into the core queue (I had to do this exact thing a few weeks ago). Would this still work?
Similar question: What happens with issue numbers, are we switching to GitHub/GitLab style per-project numbering, or will we continue with Drupal's issue numbering approach?
Consideration: How do we deal with meeting-type issues, (issues created under the "meetings" component of core), I presume those get migrated over as well; But it feels weird having those in GitLab, a meeting issue is never going to commit any code. For example, the Usability meetings have one issue for each meeting (issue for today's meeting #3261138: Drupal Usability Meeting 2022-02-04 issue from a past meeting #3258637: Drupal Usability Meeting 2022-01-21), the issue is used to collect issues for discussion; then after the meeting, log the issues that were discussed, link to the recording, assign contribution credit to those who attended, and to reference the meeting issue on the issues that were discussed when providing a usability review. The parent/child issue relationship is also used to provide a sort-of canonical navigation between the meeting issues (the parent issue is the previous week's meeting, the child issue is the next future week's meeting). Of course there's nothing there that in theory GitLab issues and the proposed "contribution record" content type couldn't handle, but it would be nice to give meeting issues specific consideration for what the approach should be for those issues that nicely handles all of those considerations.
This was a bit of a ramble/brain bump, but I wanted to get these thoughts down (partcularly about meeting issues).
Comment #14
drummYes, we need to do a complete issue migration to make this worthwhile from a maintenance standpoint. Maintaining GitLab is already more ongoing work than we had put into the previous system. If we don’t complete work to simplify Drupal.org’s codebase, we won't make it back to approximately the same amount of ongoing maintenance work as we had before.
Comment #15
drummhttps://gitlab.com/gitlab-org/gitlab/-/merge_requests/78204 was an issue blocking this.
Comment #16
drummUn-postponing this, since its for planning, and I’ve been working on that planning.
Comment #17
drummBasic issue summary cleanup, linking to issues that we now have.
Comment #18
drummRemoving known issues from issue summary, these are covered elsewhere.
Comment #19
drummComment #20
avpadernoWhat users with only the Maintain issues permission on a project will be able to do, once the issues are moved to Gitlab?
Comment #21
fjgarlin commentedI guess the closest thing would be "Reporter" but not sure if there is a plan to match 1 to 1 existing Drupal "roles" (within a project) to GitLab "roles" (within a project).
Here is a very detailed table of the different roles and permissions: https://docs.gitlab.com/ee/user/permissions.html#project-members-permiss...
Comment #22
avpaderno@fjgarlin Yes, it seems that Reporter allows to do what the Maintain issues permission allows, leaving out the assigning credits part, since Gitlab does not have that feature, yet.
Comment #23
drummUpdating issue summary since #3313979: Give everyone with git.drupalcode.org commit access to all issue forks was not possible
Comment #24
drumm#3262293: Grant GitLab “reporter” access to project maintainers with “edit project” or “maintain issues” is the issue for that
Comment #25
drummI think this has been all done for some time. I’m not seeing any loose ends at the moment.