GitLab Workflows

This is a review of the expected workflows when using GitLab. It is intended as a validation exercise to ensure that the solution would work for different members of the GNOME community.

Maintainers & developers

Push your own commit

1. git push as usual. [CLI]

You can also put a comment in the commit message to automatically close an issue at the same time. Example: "Closes: #234".

Post a commit for review

Using GitLab UI and branching:

1. Go to the issue and press create a branch [UI]
2. Locally check out the branch [CLI]
3. Locally create commit with comment "Closes: ISSUE_LINK" [CLI]
4. Push branch [CLI]

5. In GitLab, create merge request [UI]

6. Code review:

   1. Another developer then does code review in GitLab (GitLab shows diffs between branches as well as branch history) [UI]

   2. Developer makes changes based on review, force pushes them to the branch [CLI]

   3. When the branch is ready, accpet the merge request in GitLab [UI]

Using master locally only (branching is done on the remote):

1. Create a commit locally on master; put in commits "Closes: ISSUE_LINK". [CLI]

2. Create a new branch and push  git push origin HEAD:newBranch  [CLI]

3. In GitLab, a button to create a merge request for the branch appears - click it [UI]

4. Code review in GitLab, as above [UI]

5. Push local master branch; the issue will be automatically closed [CLI]

CLI based contribution

You can use https://github.com/seveas/git-spindle, docs at http://seveas.github.io/git-spindle/gitlab.html

Apply, test and review changes locally

GitLab UI using a branch:

1. Contributor creates a merge request
2. Maintainer checks out the remote branch
3. Then standard review/merge process

Using master locally only (branching is done on the remote) (CLI only):

1. Contributor creates a merge request

2. Maintainer rebases master against the remote branch, like  git rebase origin theRemoteBranch 

3. Then standard review/merge process

Managing issues

Things you can easily do with the GitLab UI:

• Create issues
• Use labels to organize issues according to importance
• Assign milestones to issues

• Do task/project management using the Issue Board

• Track dependencies between issues - add a comment with a list of the blocker issues (comments can be edited/updated); links will indicate when they are closed (see example issue)

• Mark an issue as a duplicate - on the bug that you are going to close, add the "duplicate" label and close the issue, then mention the issue that is being kept (example issue, how it looks in the lists of issues)

• Move issues between modules
• Keep an issue as private - use the "This issue is confidential" checkbox

Managing issues using the command line

You can use https://github.com/seveas/git-spindle [CLI]

Create a branch

Standard process using the command line or through the GitLab UI.

Releases

Initially this will be the same as it is now, using ftpadmin stuff. However, we could use GitLab to host releases in the future (GitLab documentation):

1. In GitLab, click any tag [UI]

2. Add a "note" to it for release notes [UI]
3. Optionally, attach a tarball [UI]

Translators

Translation team answer to what their needs are

Workflow will continue the same as it is now. Dammed Lies will have commit rights to every project, as will translator coordinators.

Release Team

Track release milestones

1. There will be a group for all release modules; it will be possible for the Release Team to create milestones for the group
2. To view the issues for a particular milestone:
   1. Browse to the group to see its issues
   2. Select the milestone to filter issues

Newcomers

Explore and choose projects

1. Browse the project list and filter by programming language

2. View the readme for each module
3. Use the URL to clone

Search for tasks

1. From the landing page, select issues
2. Select labels and choose "newcomers", or search for "newcomers"

Contribute their first patch

In the UI:

1. Create an account or use OpenID to log in

2. In an issue, click create branch & copy the URL

3. Clone the repo and checkout the branch
4. Create a fix and push it to the branch

5. In GitLab, create a merge request

6. Code review
   1. Contributor uses force push to update the branch

   2. In GitLab, maintainer clicks "accept merge request" when the branch is ready

CLI based contribution

You can use https://github.com/seveas/git-spindle, docs at http://seveas.github.io/git-spindle/gitlab.html

Bug Squad

BugsQuad answer to what their needs are

Find Bugs

• New
• Needinfo and old
• Without a response
• Oldest bugs
• Statistics and reports - new/closed bugs by module/user per month/year

Monitor new squad members