Gitlab Has come to Drupal.org
mlhess
Come learn about the 3 phases we will be using to deploying gitlab on Drupal.org
PHASE 1: REPLACING DRUPAL.ORG'S GIT BACKEND
The first phase of the Drupal.org migration
Transparently replace Drupal’s current underlying Git infrastructure (for repository hosting, maintainer permissions, code viewing) with GitLab repositories, GitLab roles and permissions for maintainers, and the GitLab code viewing UI.
Enable inline code editing (only for maintainers for this phase).
During this phase, Drupal.org will remain the primary source of information. SSH keys, new projects, etc. will be created on Drupal.org.
This first phase, while modest, will bring some concrete benefits to the project:
Maintainers will be able to begin familiarizing themselves with GitLab's code collaboration tools.
Code viewing will receive a significant upgrade from CGIT to GitLab's built-in code viewer.
And Drupal.org's old Git server will be phased out.
Phase 2: Enabling Merge Requests, Inline Code Editing, and Web-based Code Review
The timeline for Phase 2 is dependent on GitLab’s resolution of a diskspace deduplication issue, which they have committed to on our behalf: https://gitlab.com/gitlab-org/gitlab-ce/issues/23029
Enable GitLab Merge Requests, GitLab inline code editing in the web UI, and GitLab web-based code review.
During this phase, Drupal.org will handle any 'create branch/merge request' integrations from the Drupal.org Issue queues, and related call-backs from GitLab into the Drupal.org issue comment stream.
Phase 2 is where we realize some tremendous benefits to developer velocity and collaboration:
By adding merge requests, contributing to Drupal will become much more familiar to the broad audience of open source contributors who learned their skills in the post-patch era.
By adding inline editing and web-based code review, it will be much easier to make quick contributions. This not only lowers the barrier to contribution for people new to our community, it also saves significant effort for our existing community members, as they'll no longer need to clone work locally and generate patches.
Finally, by creating a tight integration between the Drupal.org issue queues and GitLab's development tools, we'll be able to transition to this new toolset without disrupting the community's existing way of collaborating.
Particpants will have input and be able to ask questions about how this flow will affect their workflow.
https://2018.badcamp.org/session/gitlab-has-come-drupalorg
Come learn about the 3 phases we will be using to deploying gitlab on Drupal.org
PHASE 1: REPLACING DRUPAL.ORG'S GIT BACKEND
The first phase of the Drupal.org migration
Transparently replace Drupal’s current underlying Git infrastructure (for repository hosting, maintainer permissions, code viewing) with GitLab repositories, GitLab roles and permissions for maintainers, and the GitLab code viewing UI.
Enable inline code editing (only for maintainers for this phase).
During this phase, Drupal.org will remain the primary source of information. SSH keys, new projects, etc. will be created on Drupal.org.
This first phase, while modest, will bring some concrete benefits to the project:
Maintainers will be able to begin familiarizing themselves with GitLab's code collaboration tools.
Code viewing will receive a significant upgrade from CGIT to GitLab's built-in code viewer.
And Drupal.org's old Git server will be phased out.
Phase 2: Enabling Merge Requests, Inline Code Editing, and Web-based Code Review
The timeline for Phase 2 is dependent on GitLab’s resolution of a diskspace deduplication issue, which they have committed to on our behalf: https://gitlab.com/gitlab-org/gitlab-ce/issues/23029
Enable GitLab Merge Requests, GitLab inline code editing in the web UI, and GitLab web-based code review.
During this phase, Drupal.org will handle any 'create branch/merge request' integrations from the Drupal.org Issue queues, and related call-backs from GitLab into the Drupal.org issue comment stream.
Phase 2 is where we realize some tremendous benefits to developer velocity and collaboration:
By adding merge requests, contributing to Drupal will become much more familiar to the broad audience of open source contributors who learned their skills in the post-patch era.
By adding inline editing and web-based code review, it will be much easier to make quick contributions. This not only lowers the barrier to contribution for people new to our community, it also saves significant effort for our existing community members, as they'll no longer need to clone work locally and generate patches.
Finally, by creating a tight integration between the Drupal.org issue queues and GitLab's development tools, we'll be able to transition to this new toolset without disrupting the community's existing way of collaborating.
Particpants will have input and be able to ask questions about how this flow will affect their workflow.
https://2018.badcamp.org/session/gitlab-has-come-drupalorg