Kernel/process

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

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

Код для ядра должен быть совместим с лицензией GPL-2.0 (например, совместим код под лицензией BSD-3-Clause, см. список совместимых лицензий в каталоге LICENSES). По лицензионным причинам код от анонимов/псевдонимов не принимается. Весь код подписывается (тегом signed-off-by) что означает заявление о соответствии кода свободной лицензии.

Все комментарии, описания пишутся и обсуждения ведутся только на английском языке.

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

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.

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

Попадание в mainline

Цикл разработки одного релиза mainline ядра длится около 2-х месяцев, первые 2 недели из которых называются merge window во время которых Торвальдсом принимаются новые features в ядро, а в остальное время fixes к тому что уже принято - для стабилизации следующего релиза. После окончания merge window каждую неделю выпускается релиз кандидат (в основном репозитории Торвальдса).

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

Попадание в stable

После релиза mainline ядра stable team (во главе с Грегом КХ) выбирает коммиты из mainline с фиксами багов и backport'ит их в stable/longterm ядра. Важно, что выбираемые коммиты, за редким исключением, должны уже быть приняты в mainline — а значит они уже прошли процессы review и тестирования для mainline. Основной способ выбора коммитов — это AUTOSEL process.

Релизы стабильных ядер происходят примерно каждую неделю. Патчи для новых stable релизов пушатся в репозиторий stable-rc и постятся в список рассылки stable с анонсом где сообществу дается время на их review и тестирование. Протестировавшие отвечают на анонс с описанием проведенного ими тестирования и тегом tested-by.

Если не выявлено проблем коммиты пушатся в репозиторий stable, ставится релиз тег и делается анонс.