[tor-project] The Gitlab ticket workflow of the network team

George Kadianakis desnacked at riseup.net
Tue Jun 23 11:14:19 UTC 2020


me and David assigned reviews today and here is the procedure we came up
with. Unfortunately, because we dont use merge requests in gitlab yet,
we cannot use the natural procedure of gitlab when it comes to code
reviews, so we had to hack something up with labels for now.

== Marking something for review ==

When you write code and you want to mark it for review, please add the
"Needs Review" label.

== Assigning reviews ==

When me and David assign reviews, we use the "Reviewer" label and then
assign the ticket to the right reviewer.

== Finding your reviews ==

To find your reviews you use this query:





== Reviewing your reviews (happy path) ==

When you do your reviews, the happy path is that the patch was good and
you merge it and you move forward.

Because ahf can't commit yet, when ahf reviews code, he can add the
label "Merge Ready" and then its our responsibility to merge
it. Hopefully ahf will start committing next week and we won't need to
do that.

== Reviewing your reviews (sad path) ==

If the patch was not good, you need to put it in needs revision. This is
crammy in our workflow (because of lack of MRs) but we suggest the following procedure:
- You add the "Needs Revision" label.
- You don't change any other label.

It's now the responsibility of the code author to notice this label, and
revision the code. It's also the responsibility of the reviewer to poke
the code author if they haven't done this in a reasonable amount of time.

== TODO ==

How to handle backports?
Transition to MR workflow which will greatly improve the sad path above.

More information about the tor-project mailing list