Hi Jonathan,
Hi wiresharks,
Context: https://gitlab.com/wireshark/wireshark/-/merge_requests/1313#note_478706594
In Gerrit times, a person could add someone as a reviewer to a change
to request review, the reviewer could remove themselves if they were
unavailable, and so on. What is the equivalent in the GitLab world?
More concretely:
- when a change is ready to review, how do I say so?
All opened threads are resolved and the submitter can add a comment to ping us. A reviewer can be explicitly added in the right column of the Gitlab GUI
Do you mean assignee? I guess so, but I'd like to clear it, since the reviewer and assignee were separate in Gerrit.
No I really meant reviewer as I was considering the assignee as the person that will ultimately schedule the merge. You can have more than one reviewer. But I'm open to any workflow we might define.
- if a review seems to be stalled, what's the best place to poke?
Writing a comment in the MR; we are almost all volunteers doing this on our spare time so sometimes real life collides and a given change can get out of the radar
- if I would like to review a change, how should I signal interest?
Everybody is free to put comments in a MR
- what happens when a change has been approved and it is time to merge
it? Where can I read about the bot that does that?
One of the core developer approves the change and schedules it for merge
The Core devels are able to rebase and merge a MR. However the race for merge with other MRs could make the merge harder. That's why we can assign the MR to the bot that automatically rebases the change until the merge actually happens. But it's not a must.
As only core developers can do this operation, that's what I meant when saying "schedule for merge" but did not enter into the details. Thanks for clarifying it.