[devel] [ANNOUNCE] devel-kernel workflow

[Alexey Sheplyakov]

Здравствуйте!

On Tue, Apr 12, 2022 at 01:20:01PM +0300, Vitaly Chikunov wrote:
> Так как Антон Бояршинов больше не сопровождает ядра (спасибо ему за
> проделанную работу), мы реформируем наш kernel workflow. Теперь патчи[1]
> и пулл реквесты[2] предлагается слать так же как они идут (и
> принимаются) в апстримные ядра - через список рассылки devel-kernel[3].
> Просьба использовать тот же инструментарий как для отсылки в апстрим -
> format-patch, request-pull, send-email с правильно окормленными From,
> descriptions, tags и т.д.
> 
> Дополнительно, просьба указывать в какое ядро предназначен патч (версия и
> бранч). Так же в случае заимствования патчей "из интернета" просьба
> ставить ссылку на источник в тег Link: перед своим Signed-off-by:.

До этого места предложения вполне разумные...
 
> Сейчас деревья каждого ядра ведутся в равном стиле, но они будут со
> временем преобразованы -- каждое ядро будет иметь свой единый бранч с
> merge commit'ами, где не переписывается история, по крайней мере, между
> мажорными версиями.
> В каждый новый бранч (то есть в новую мажорную версию нового ядра)
> предлагается заново слать свои патчсеты, а затем только обновления
> (новые коммиты поверх уже принятого патчсета),

А вот тут -- уже нет. Это гарантировано не работает. Поддерживать
несколько веток (mainline и пару LTS) * несколько плат * несколько
версий прошивок возможно только при явном разделении "здесь моё,
а здесь -- не моё", т.е. при rebase на свежий mainline, и перенос
получившихся патчей на LTS ветки.

К тому же цикл разработки (поддержки SoC/плат) зависит не только
(и не столько) с циклом разработки ядра (mainline, LTS, "нашего").
А прежде всего от
1) Появления новых процессоров/плат
2) Появлением новых драйверов/фич (и их переносом из заведомо
   устаревшего ядра от производителя процессора/платы).
3) Обновлением прошивки (которые как правило ломают совместимость
   и требуют адаптации ядра).

> а не пере-посылать новые версии своих патчсетов как промежуточные
> версии при разработке.

Это и есть "промежуточные версии при разработке". Которые пока не попали
в mainline (а может и никогда не попадут).

> хорошо относится к нашим ядрам как к стабильным и как к апстримным для
> нас, а не как к экспериментальным для локальной разработки.

А чем, собственно, mainline ядро отличается от "экспериментального для
локальной разработки"? Вопрос со звёздочкой: то же самое для LTS ядер
(у которых по два и более релиза в неделю случается).
 
> Все это упростит поддержку и разработку ядер для всех, так как является
> общепринятой практикой.

Хорошо у вас там... Но в этой Вселенной "общепринятая практика" - rebase
на ветку, которая указана в MAINTAINERS. Нет, мне это не нравится (равно
как и stable-api-nonsense.rst), но "другого Linux у меня для вас нет".

Всего доброго,
	Алексей