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_reques...
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.