Re: [devel] [ANNOUNCE] devel-kernel workflow

["Vladimir D. Seleznev" <vseleznv@altlinux.org>]

On Tue, Apr 12, 2022 at 09:54:46PM +0400, Alexey Sheplyakov wrote:
> Здравствуйте!
> 
> 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'ами, где не переписывается история, по крайней мере, между
> > мажорными версиями.
> > В каждый новый бранч (то есть в новую мажорную версию нового ядра)
> > предлагается заново слать свои патчсеты, а затем только обновления
> > (новые коммиты поверх уже принятого патчсета),

Я предлагаю ребейзить уже имеющиеся патчи на новую мажорную версию, и
сообщаться авторам если чистый ребейз не удался (и разрешение конфликтов
не тривиальное), чтобы они исправили проблемы и прислали новые версии
пачтей, а до того выпуск нового мажора приостановить хотя бы на некий
разумный тайм-аут. Возможно, стоит ребейзить ещё на RC мажора.

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

Не понятна ваша мысль. Не все наши патчи попадут в мейнлайн, я согласен
с Виталием, что наши ядра для нас являются апстримом.

> > хорошо относится к нашим ядрам как к стабильным и как к апстримным для
> > нас, а не как к экспериментальным для локальной разработки.
> 
> А чем, собственно, mainline ядро отличается от "экспериментального для
> локальной разработки"? Вопрос со звёздочкой: то же самое для LTS ядер
> (у которых по два и более релиза в неделю случается).
>  
> > Все это упростит поддержку и разработку ядер для всех, так как является
> > общепринятой практикой.
> 
> Хорошо у вас там... Но в этой Вселенной "общепринятая практика" - rebase
> на ветку, которая указана в MAINTAINERS. Нет, мне это не нравится (равно
> как и stable-api-nonsense.rst), но "другого Linux у меня для вас нет".
> 
> Всего доброго,
> 	Алексей

-- 
   WBR,
   Vladimir D. Seleznev