Kernel/process

Краткое описание процесса разработки ядра

Разработка ядра Linux происходит публично согласно kernel development process. Полное описание https://docs.kernel.org/process/development-process.html Код (пере)лицензируется под GPL-2.0-only.

Подготовка патчей

1. Индивидуальные разработчики вносят изменения в код ядра на своей копии репозитория mainline (torvalds/linux). Происходит цикл: разработка, локальное тестирование. Git коммиты (будущие патчи) разделяются на смысловые части, для каждого коммита дается описание в commit message. Код оформляется в соответствии со стилем ядра (проверяется скриптом scripts/checkpatch.pl). Каждый добавляемый коммит не должен ломать сборку ядра (чтоб не помешать в будущем git bisect).

1. Перед отправкой формируется patch set (git format-patch), версионируется, добавляется changelog если это не первая версия, добавляется cover letter если патчей больше одного.

1. Патчи публикуют - отсылают по email в списки рассылки затрагиваемых подсистем (git send-email). Актуальные списки рассылок определяются по файлу MAINTAINERS. Если отдельного списка нет или дополнительно к списку нужной подсистемы ставится копия в общий список lkml. Также ставится копия на личные адреса маинтайнеров нужных подсистем и, иногда, на предыдущих разработчиков застрагиваемых файлов или разработчиков чей код меняется. Для удобства определения списка адресатов есть скрипт scripts/get_maintainer.pl.

1. Кроме списков рассылки, опубликованные патчи попадают на сайты patchwork (выделяет только патчи и отслеживает статус review/ack/etc) и lore (сохраняет все письма с поиском м доступом по message-id).

Прием патчей апстримом

1. После публикации патчей дается время, чтоб другие разработчики ядра сделали code review.
2. Разработчики отвечают в список рассылки комментируя код в цитировании (inline replying) если замечаний нет, то указывается тэг reviewed-by.
3. Маинтайнеры затрагиваемых подсистем присылают одобрение в виде тэга acked-by, это значит что они не делали полное review, но разрешают изменение (и прием патчсета затрагивающего их подсистему в чужое дерево).
4. Если кто-то тестировал работоспособность патчей, то он может прислать тэг tested-by.
5. Если были замечания, то разработчик их исправляет повторяя цикл разработки и публикует версию n+1 указывая что это новая версия (PATCH v2) и добавляя changelog.
6. Если замечаний нет маинтайнер основной подсистемы куда прислан полный патчсет принимает его в свое git дерево и пишет об этом в ответ на письмо с отдельным патчем или на cover letter для patch set.

Прохождение патча в аптриме

1. Цикл разработки mainline ядоа длится 7-8 недель, первые 2 из которых называются merge window во время которых Торвальдсом принимаются новые изменения а ядро, а во время остальные фиксы к тому что уже принято - для стабилизации следующего релиза.
2. Маинтайнер принявший патчи, в зависимости от их характера, решает когда их отправить дальше — в этом цикле разработки ядра или в следующем. В зависимости от этого он принимает их в один из своих git репозиториев. Например, если он планирует их послать в merge window следующего цикла, то это может быть не основной репозиторий этой подсистемы.