Kernel/process

Материал из ALT Linux Wiki

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

Разработка ядра 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).
  2. Перед отправкой формируется patch set (git format-patch), версионируется и добавляется changelog если это не первая версия, добавляется cover letter [PATCH 0/N] если патчей больше одного.
  3. Затем патчи публикуют — отсылают по email в списки рассылки затрагиваемых подсистем (git send-email). Актуальные списки рассылок указаны в файле MAINTAINERS. Если отдельного списка нет или дополнительно к списку нужной подсистемы ставится копия в общий список lkml. Также ставится копия на личные адреса мейнтейнеров нужных подсистем и, иногда, на предыдущих разработчиков застрагиваемых файлов или разработчиков чей код меняется, ревьюверов. Для определения списка адресатов есть скрипт scripts/get_maintainer.pl.
  4. Опубликованные в списках рассылки патчи попадают на сайты patchwork (выделяет только патчи и отслеживает статус reviewed/acked/tested) и lore (сохраняет все письма с доступом по message-id).

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

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

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

Попадание в mainline

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

Мейнтейнер, принявший патчи, в зависимости от их характера, решает, когда отправить их дальше — в текущем цикле разработки ядра или в следующем. Например, если это новый функционал, а 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, ставится релиз тег и делается анонс.