[devel] [ANNOUNCE] devel-kernel workflow

[Alexey Sheplyakov]

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

On Tue, Apr 12, 2022 at 09:30:26PM +0300, Vladimir D. Seleznev wrote:
> > До этого места предложения вполне разумные...
> >  
> > > Сейчас деревья каждого ядра ведутся в равном стиле, но они будут со
> > > временем преобразованы -- каждое ядро будет иметь свой единый бранч с
> > > merge commit'ами, где не переписывается история, по крайней мере, между
> > > мажорными версиями.
> > > В каждый новый бранч (то есть в новую мажорную версию нового ядра)
> > > предлагается заново слать свои патчсеты, а затем только обновления
> > > (новые коммиты поверх уже принятого патчсета),
> 
> Я предлагаю ребейзить уже имеющиеся патчи на новую мажорную версию, и
> сообщаться авторам если чистый ребейз не удался (и разрешение конфликтов
> не тривиальное), чтобы они исправили проблемы и прислали новые версии
> пачтей, а до того выпуск нового мажора приостановить хотя бы на некий
> разумный тайм-аут. Возможно, стоит ребейзить ещё на RC мажора.
> 
> > А вот тут -- уже нет. Это гарантировано не работает. Поддерживать
> > несколько веток (mainline и пару LTS) * несколько плат * несколько
> > версий прошивок возможно только при явном разделении "здесь моё,
> > а здесь -- не моё", т.е. при rebase на свежий mainline, и перенос
> > получившихся патчей на LTS ветки.
> > 
> > К тому же цикл разработки (поддержки SoC/плат) зависит не только
> > (и не столько) с циклом разработки ядра (mainline, LTS, "нашего").
> > А прежде всего от
> > 1) Появления новых процессоров/плат
> > 2) Появлением новых драйверов/фич (и их переносом из заведомо
> >    устаревшего ядра от производителя процессора/платы).
> > 3) Обновлением прошивки (которые как правило ломают совместимость
> >    и требуют адаптации ядра).
> > 
> > > а не пере-посылать новые версии своих патчсетов как промежуточные
> > > версии при разработке.
> > 
> > Это и есть "промежуточные версии при разработке". Которые пока не попали
> > в mainline (а может и никогда не попадут).
 
> Не понятна ваша мысль.

Их, мыслей, несколько.

1. mainline ядро само по себе - "промежуточная версия при разработке".
2. Поддержка нового процессора, новой платы, новой версии прошивки - это
   неизбежно "промежуточная версия при разработке".

> Не все наши патчи попадут в мейнлайн,

3. Жизненный цикл устройств (процессоров/плат/периферии) никак не связан
   и не совпадает с циклом разработки ядер (mainline, lts). К моменту,
   когда наконец upstream согласится (или нет?) принять патчи, изделие
   уже снимут с производства (см. поддержка Mali T628 в ядре и Mesa).

> я согласен с Виталием, что наши ядра для нас являются апстримом.

А тут уже я не понимаю. Что значит "наши ядра для нас являются апстримом".
Кто и что разрабатывает на основе наших ядер, и как им мешает rebase патчей
для поддержки $YET_ANOTHER_ARM_SOC, $YET_ANOTHER_ARM_BOARD ?