Разные способы code review

https://nasamuffin.github.io/git/open-source/email/code-review/2019/05/22/how-i-learned-to-love-email-patches.html
https://gist.github.com/thoughtpolice/9c45287550a56b2047c6311fbadebed2
https://drewdevault.com/blog/Email-driven-git/
Отрывок от моего сообщения коллегам.
Табличка сравнения подходов. Тильда означает "зависит от".

┌───────────────┬──────┬──────┬───────┬─────────┬─────┬─────┬──────────┬──────┐
│               │GitLab│Gerrit│tracker│schwabrak│Почта│notes│send-email│inband│
├───────────────┼──────┼──────┼───────┼─────────┼─────┼─────┼──────────┼──────┤
│не нужно доп ПО│-     │-     │~      │+        │+    │+    │+         │+     │
├───────────────┼──────┼──────┼───────┼─────────┼─────┼─────┼──────────┼──────┤
│ не нужен доп  │~     │-     │-      │+        │+    │+    │+         │+     │
│    сервер     │      │      │       │         │     │     │          │      │
├───────────────┼──────┼──────┼───────┼─────────┼─────┼─────┼──────────┼──────┤
│локальная копия│-     │-     │-      │+        │+    │+    │+         │+     │
│    review     │      │      │       │         │     │     │          │      │
├───────────────┼──────┼──────┼───────┼─────────┼─────┼─────┼──────────┼──────┤
│    чёткое     │      │      │       │         │     │     │          │      │
│ понимание что │-     │+     │-      │-        │-    │-    │-         │+     │
│   resolved    │      │      │       │         │     │     │          │      │
├───────────────┼──────┼──────┼───────┼─────────┼─────┼─────┼──────────┼──────┤
│архив коммитов │-     │+     │~      │~        │~    │~    │+         │~     │
│    review     │      │      │       │         │     │     │          │      │
├───────────────┼──────┼──────┼───────┼─────────┼─────┼─────┼──────────┼──────┤
│автоматические │+     │+     │-      │-        │-    │-    │+         │-     │
│  оповещения   │      │      │       │         │     │     │          │      │
├───────────────┼──────┼──────┼───────┼─────────┼─────┼─────┼──────────┼──────┤
│   доступная   │      │      │       │         │     │     │          │      │
│  история для  │+     │+     │+      │+        │-    │+    │-         │+     │
│     всех      │      │      │       │         │     │     │          │      │
└───────────────┴──────┴──────┴───────┴─────────┴─────┴─────┴──────────┴──────┘

* не нужно доп ПО -- предполагаем, что у нас у всех имеется Git и почта,
  плюс возможность работать с issue tracker. Наличие только
  web-приложения, как в случае с Gerrit или GitLab -- не считается
  приемлемым удобным вариантом и нужны дополнительные инструменты для
  работы с ними
* не нужен доп сервер -- нужно ли что-то дополнительно поднимать? Gerrit
  у нас нет, который бы кто-то поддерживал. GitLab есть, но... его
  обновление может привести к каким угодно последствиям и потерям (уже
  случалось), которыми мы не управляем
* локальная копия review -- есть ли возможность полностью иметь
  локальную историю проведённых review? Речь про адекватную простую
  возможность получения, типа git fetch/clone. В случае с schwabrak
  issue tracker, мы просто git clone-ом получаем все issues
* чёткое понимание что было resolved -- рецензент пишет с десяток
  замечаний. Во время fixup/whatever коммитов часть из них исправляется.
  Есть ли простой способ чётко понять были все замечания исправлены?
* архив коммитов review -- есть ли архив со всеми версиями коммитов,
  которые были отправлены на review? Если договориться о том, чтобы мы
  делали push в какой-нибудь refs/review/... ветку, в которой не будет
  rebase-ов и которую мы не будем удалять, то тогда можно иметь и архив.
  Gerrit сам по себе хранит все версии и ни о чём договариваться не надо.
  Если всё же надо сделать rebase или что-то подобное, то тогда сделать
  новую review ветку
* автоматические оповещения -- после отправки новых коммитов, нужно ли
  самостоятельно предпринимать какие-то действия для оповещения о push?
* доступная история для всех -- доступна ли история review сообщений для
  всех? Если, например, обсуждение идёт чисто по почте между двумя
  участниками, то другие это никак не могут получить. Если только оно не
  будет отправляться в почтовую рассылку или особый адрес где вся
  корреспонденция будет архивироваться (как это происходит в Linux проекте)

Какие подходы мне приходят в голову?

* Gerrit: многие из нас имели с ним дело. Выступает отдельным сервером,
  в который делается git push, а также предустанавливаются .git/hooks
  для вставки change-id поля в commit message, чтобы была понятна связь
  между новыми версиями патча (коммита). Этого сервера у нас нет, так
  как некому поддерживать. Плюс он на Java, что мало кто из нас умеет.
* GitLab: делается merge request (MR), добавляется assignee,
  комментариями обсуждается сам review и код. Обновлённые версии
  push --force-атся в ту же ветку MR. В самом web-приложении GitLab
  показывает прежде загруженные версии коммитов, но через git ls-remote
  я не увидел веток с которых можно бы было достать их. Есть штатная
  утилита glab, на Go, в которой можно смотреть/писать эти комментарии.
  Через glab mr note list можно увидеть упоминание хэшей этих коммитов,
  но попытка сделать fetch мне выдаёт, что нет таких объектов
* tracker -- под этим я подразумеваю некий general purpose issue tracker
  в котором в виде комментариев к задаче пишутся сами review и идёт
  обсуждение. Несколько лет на моём прошлом месте работы десятки людей в
  команде так работали вполне себе успешно. Статус задачи переводится в
  review, назначается assignee, в комментарии указывается ветка которую
  надо отрецензировать
* schwabrak -- аналогично tracker, но гарантированно имеется полная
  копия всего tracker, так как это очередной git-репозиторий. Так как
  наш текущий schwabrak для pkit и okz2 проектов расположен не на
  "обычном" git-репозитории, а на GitLab, то туда мы не можем добавить
  просто так свои .git/hooks, где можно бы было отсылать оповещения об
  изменениях только участвующим в задаче людям. Сейчас у нас
  широковещательная рассылка всех действий над tracker отправляемая
  всем. Поэтому если review бы проходило через правку issue/commit файл,
  то об этом оповещения бы шли всем, что наверное может надоесть
* почта -- под этим подразумеваю то, что происходило сейчас. Просто
  отправляем почтовое сообщение о том, что надо сделать review. И само
  review просто является ответом. И дальше перебрасывание сообщениями в
  пределах этого thread-а. Для этого кстати удобно бы было использовать
  git-request-pull команду
* notes -- никогда не пробовал такого на практике (не сами git notes, а
  именно review делать), но идея в том, чтобы почтовые сообщения (review
  и обсуждение) писать в виде notes к коммитам которые надо рецензировать.
  Прямо вместе с кодом будет параллельно существовать и текстовые review
* send-email -- под этим подразумевается самый классический способ
  использования git-а, применяемых во многих крупных (крупнейших!)
  проектах, типа того же Linux. git-format-patch, git-send-email, git-am
  команды для работы со всем этим. Исправленные (amended) коммиты
  отправляются всем скопом, под увеличивающейся версией (format-patch -v),
  не забывая указывать --in-reply-to, для соединения новой пачки с
  оригинальным сообщением о review в thread. Обсуждение/review прямо
  внутри thread-а происходит, над прямо конкретным патчем. Крайне
  полезен функционал --interdiff, который может показать разницу в новых
  версиях относительно прошлых
* inband -- под этим подразумеваю то, на чём вчера и остановились. По
  почте/whatever отправляется оповещение о ветке где надо сделать
  review (наверное имеет смысл в schwabrak commit message писать, при
  переводе состояния задачи в review). В той же ветке рецензент
  добавляет коммит поверх всех остальных, где прямо внутри кода
  оставляет комментарии. Далее, оповещает о том, что закончил (в
  schwabrak, переводя статус задачи в wip). Исправления в ветке делаются
  поверх этого коммита, удаляя "# REVIEW" (whatever) комментарии
  рецензента, показывая что замечание исправлено. И под конец diff между
  первым и последним коммитом ветки не должен будет содержать REVIEW
  комментарии, означая что всё исправлено

По идее, штатный способ работы через send-email -- наиболее удобный и
гибкий в общем случае. Судя по всему, это единственный разумный способ
работы на огромных проектах, где большая нагрузка на рецензента (как в
Linux).

Но вместо привычного нам git push, нужно подготавливать патчи для
отправки. Делать format-patch, возможно редактировать их немного, не
забывать связывать в thread-ы. На приёмной стороне, видимо, плодить
ветки для новой версии патчей, чтобы review-ить не просто патч в
почтовом клиенте, а видеть весь код. Немного побольше телодвижений.

Плюс это требует полноценную Unix-like рабочую экосистему: работающую
почту. То есть локальный MTA и адекватный MUA. У кого-то это всё есть, у
кого-то нет. Применять штатный Git подход не получится без полноценного
настроенного Unix окружения (именно поэтому из коробки во всех
нормальных дистрибутивах/ОС и устанавливается MTA). Хотя это совсем не
сложно настроить.

Но вот "inband" подход, не требует ничего сложнее привычных fetch/push.
Вести обсуждение в нём: ну так себе наверное по удобству, но не
невозможно. Плюс всё равно надо как-то оповещать о том, что был
произведён push с ответом. Но учитывая, сколько нас тут человек, как не
много review в принципе производится, то не вижу тут большой проблемы.