landau-linux: maintenance: Add maintainers repos and 2MR description

The LANDAU-linux maintenance document doesn't provide an important
information regarding the way the sub-LANDAU-Linux repositories are
supposed to be maintained. Moreover it is uncertain of how these changes
are supposed to be collected into a single LANDAU-Linux release. Let's fix
that by adding the detailed description of both of these processes into
the chapter 6 concerning the maintainers responsibilities. The text is
equipped with a mermaid gitGraph diagram visualising the GIT-flow in that
regard.

Signed-off-by: Serge Semin <svsemin@unistemlab.com>

1 files changed, 42 insertions, 0 deletions

diff --git a/landau-linux/maintenance.md b/landau-linux/maintenance.md
index 838a74b..2b5a000 100644
--- a/landau-linux/maintenance.md
+++ b/landau-linux/maintenance.md
@@ -268,6 +268,48 @@ flowchart TD
 | 🔒 Безопасность | Мониторинг и применение исправлений безопасности |
 | 📝 Документирование | Ведение changelog для каждого LANDAU-релиза |
 
+### Личные репозитории ментейнеров
+
+В личных репозиториях ментейнеры хранят и развивают собственные форки ядра Linux с подведомственным им набором изменений. В целом, способ организации персональных репозиториев ментейнеры могут выбирать самостоятельное. Например, можно разделить независимые изменения на GIT-ветки по подсистемам и отправлять MR с каждым из них, либо предварительно объединить их в единую GIT-ветку и отправить один целостный MR. Как бы то ни было, при этом необходимо придерживаться правила **преемственности предыдущих изменений и минимизации merge-конфликтов**. То есть GIT-ветка, отправляемая в MR главному ментейнеру, должна сохранять историю предыдущих изменений LANDAU-Linux и их исправлений, а также содержать последнюю версию оригинальной версии ядра Linux, для которого готовится релиз LANDAU-Linux. Для реализации такого требования удобно использовать подход **двойного слияния**, суть которого в том, чтобы сначала ментейнеры sub-LANDAU-Linux репозиториев выполнили слияние своих GIT-веток с `landau-next`, разрешили все конфликты и лишь потом отправляли MR в рамках этапа RMW:
+
+```mermaid
+---
+config:
+    gitGraph:
+        parallelCommits: true
+        mainBranchName: 'linux-V.P.y'
+---
+gitGraph
+    branch baikal-next order: 2
+    branch amlogic-next order: 3
+    commit
+    commit
+    commit
+    commit
+    checkout baikal-next
+    commit
+    commit
+    commit
+    checkout linux-V.P.y
+    commit
+    commit
+    commit id: "Linux V.P" tag: "vV.P"
+    branch landau-next order: 1
+    commit id: " " type: HIGHLIGHT
+    checkout amlogic-next
+    merge landau-next
+    checkout baikal-next
+    merge landau-next
+    checkout landau-next
+    merge amlogic-next
+    merge baikal-next
+    commit id: "LANDAU-Linux V.P.l-rc1" tag: "vV.P.l-rc1"
+```
+
+Таким образом, основная нагрузка по исправлению конфликтов ложится на нижестоящих ментейнеров. Главному ментейнуру остаётся лишь собрать все MR в `linux-next`. Если и в этом случае возникают сложные конфликты, то главный ментейнер вправе попросить выполнить повторный цикл **двойного слияния**, чтобы кросс sub-LANDAU-Linux конфликты были разешены на стороне нижестоящих ментейнеров.
+
+К тому же опционально ментейнеры могут выполнять поддержку GIT-веток с патч-сетами для последующей отправки изменений в оригинальный репозиторий ядра Linux. До момента интеграции патч-сеты могут "поглощать" исправления и стилистические изменения в процессе перебазирования на новую версию ядра Linux. Это упрощает сопровождение таких GIT-веток, минимизируя лог изменений, который к тому же является лишним при интеграции в ядро Linux.
+
 ---
 
 ## 📖 7. Пример полного цикла релиза