Envisioned Gitlab workflow

[Alexandre Julliard]

Folks,

Here's a description of the envisioned workflow for using Gitlab as the
primary platform for Wine development, should we decide to adopt it.

This will probably evolve as we experiment and find out what
works or doesn't work for us. All feedback/suggestions are welcome.


  1. All patch series are submitted as Merge Requests, so that the
     proper information can be captured. The usual rules apply (small
     patches, small number of patches per MR, sign-off by submitter).

     There are various methods available for creating merge requests:
     - using the web interface
     - directly when pushing: git push -o merge_request.create
       cf. https://docs.gitlab.com/ee/user/project/push_options.html
     - from the command line, eg. 'glab mr create'
       cf. https://glab.readthedocs.io/en/latest/mr/create.html
     - by email
       cf. https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html

  2. The merge request will run through the CI pipeline, ideally
     including a testbot run (not implemented yet).

  3. The patches of the merge request will be forwarded to wine-devel
     by the mail gateway, for people who prefer to use their existing
     email tools to manage patches.

  4. Reviewers will be automatically assigned to the merge request
     based on the MAINTAINERS file (not implemented yet). Reviewers
     can also be assigned manually.  People assigned as reviewers
     should receive a notification from gitlab.

  5. When someone starts reviewing a patch, they can optionally assign
     the patch to themselves, so that the submitter is aware that
     someone is working on their patch.

  6. Feedback on patches can be sent by replying to the wine-devel
     email, or by adding a comment on gitlab. The mail gateway will
     bridge things so that all comments are reflected both on gitlab
     and on wine-devel.

     Note: if you subscribe to gitlab notifications (recommended)
     currently you'll get many duplicate emails. There are mail
     headers that can be used for filtering, but we may want to
     handle this differently, suggestions are welcome.

  7. If there are comments, the submitter can address them and update
     the merge request by pushing to the MR branch. The mail gateway
     will send the new version of the patches to wine-devel (except
     for trivial changes) for further review.

  8. Once a reviewer approves a merge request, they should mark it
     approved in gitlab. The idea is that this will replace the
     existing "send a signoff by email" mechanism. Note that an
     approval applies to the whole merge request, not to individual
     patches. This should be one more reason to keep patch series
     small.

     Approvals can be sent by:
     - using the approve button on the web interface
     - replying to a gitlab notification with "/approve"
       (note: replying to a wine-devel mail won't work, it needs the
       magic gitlab headers)
       cf. https://docs.gitlab.com/ee/user/project/quick_actions.html
     - from the command line, eg. 'glab mr approve'
       cf. https://glab.readthedocs.io/en/latest/mr/approve.html

  9. Once a merge request has been approved by all reviewers, I'll
     merge it into my tree, do a full testbot run to make sure it
     doesn't break anything, then push the results and mark the merge
     request as 'merged'.

 10. If a merge request is no longer relevant, the submitter should
     close it. We may want to add an auto-close process for stale
     merge requests at some point.

-- 
Alexandre Julliard
julliard at winehq.org