[devel] [ANNOUNCE] devel-kernel workflow
Alexey Sheplyakov
asheplyakov на basealt.ru
Ср Апр 13 13:37:36 MSK 2022
Здравствуйте!
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 ?
Подробная информация о списке рассылки Devel