[devel] [ANNOUNCE] devel-kernel workflow

[devel] [ANNOUNCE] devel-kernel workflow

[Vitaly Chikunov]

Hi,

Так как Антон Бояршинов больше не сопровождает ядра (спасибо ему за
проделанную работу), мы реформируем наш kernel workflow. Теперь патчи[1]
и пулл реквесты[2] предлагается слать так же как они идут (и
принимаются) в апстримные ядра - через список рассылки devel-kernel[3].
Просьба использовать тот же инструментарий как для отсылки в апстрим -
format-patch, request-pull, send-email с правильно окормленными From,
descriptions, tags и т.д.

Дополнительно, просьба указывать в какое ядро предназначен патч (версия и
бранч). Так же в случае заимствования патчей "из интернета" просьба
ставить ссылку на источник в тег Link: перед своим Signed-off-by:.

Сейчас деревья каждого ядра ведутся в равном стиле, но они будут со
временем преобразованы -- каждое ядро будет иметь свой единый бранч с
merge commit'ами, где не переписывается история, по крайней мере, между
мажорными версиями.

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

Все это упростит поддержку и разработку ядер для всех, так как является
общепринятой практикой.

Это предложение не окончательный вариант и, возможно, что-то ещё будет меняться.

[1] https://www.kernel.org/doc/html/latest/process/submitting-patches.html
[2] https://www.kernel.org/doc/html/latest/maintainer/pull-requests.html
[3] https://lists.altlinux.org/mailman/listinfo/devel-kernel
    https://lore.altlinux.org/devel-kernel/

Re: [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 у меня для вас нет".

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

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

[Vladimir D. Seleznev]

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

Re: [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 ?
 

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

[Dmitry V. Levin]

Hi,

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'ами, где не переписывается история, по крайней мере, между
> > мажорными версиями.
> > В каждый новый бранч (то есть в новую мажорную версию нового ядра)
> > предлагается заново слать свои патчсеты, а затем только обновления
> > (новые коммиты поверх уже принятого патчсета),
> 
> А вот тут -- уже нет. Это гарантировано не работает. Поддерживать
> несколько веток (mainline и пару LTS) * несколько плат * несколько
> версий прошивок возможно только при явном разделении "здесь моё,
> а здесь -- не моё", т.е. при rebase на свежий mainline, и перенос
> получившихся патчей на LTS ветки.

Посмотрите уже, наконец, опыт linux-rt:
https://lpc.events/event/4/contributions/293/attachments/237/416/maintaining-out-of-tree-patches-over-the-long-term.pdf

Это работает, и это, похоже, единственный выход.


-- 
ldv

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

[Alexey Sheplyakov]

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

On Wed, Apr 13, 2022 at 01:01:15PM +0300, Dmitry V. Levin wrote:

> > > Сейчас деревья каждого ядра ведутся в равном стиле, но они будут со
> > > временем преобразованы -- каждое ядро будет иметь свой единый бранч с
> > > merge commit'ами, где не переписывается история, по крайней мере, между
> > > мажорными версиями.
> > > В каждый новый бранч (то есть в новую мажорную версию нового ядра)
> > > предлагается заново слать свои патчсеты, а затем только обновления
> > > (новые коммиты поверх уже принятого патчсета),
> > 
> > А вот тут -- уже нет. Это гарантировано не работает. Поддерживать
> > несколько веток (mainline и пару LTS) * несколько плат * несколько
> > версий прошивок возможно только при явном разделении "здесь моё,
> > а здесь -- не моё", т.е. при rebase на свежий mainline, и перенос
> > получившихся патчей на LTS ветки.
> 
> Посмотрите уже, наконец, опыт linux-rt:

Какое отношение он имеет к рассматриваемой проблеме (поддержка новых
процессоров, плат в нескольких ветках ядер)? Ещё раз:

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

> https://lpc.events/event/4/contributions/293/attachments/237/416/maintaining-out-of-tree-patches-over-the-long-term.pdf

Боль и страдания, но чуть полегче - без * "n плат" * "m версий прошивок"

> Это работает, и это, похоже, единственный выход.

У Вас получилось - я рад (кстати, где можно поглядеть на результат?).
А я проверил - не работает, и только усложняет жизнь.
Есть кактус только потому, что Вам он нравится - нет уж, увольте.

P.S. 

Патчи для поддержки СнК Байкал-М (и плат на его основе) можно взять отсюда:

git://git.altlinux.org/people/asheplyakov/linux.git

- baikalm - для mainline ядра [1] (ветка master)
- baikalm-5.15.y - для LTS ядра [2] 5.15 (ветка linux-5.15.y)
- baikalm-5.10.y - для LTS ядра [2] 5.10 (ветка linux-5.10.y)
- rpi-baikalm-5.15.y - для ядра rpi-5.15.y (https://github.com/raspberrypi/linux.git)
  поддерживаются raspberry pi, Байкал-М, и rock pi 4 (rk3399)
- baikalm-5.17.y - для "стабильного" ядра [2] 5.17.y (ветка linux-5.17.y)

(остальные ветки - для внутреннего пользования).

[1] git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
[2] git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git


Ещё раз подчёркиваю - *можно* взять. А можно и не брать - я никого не заставляю.

Всем добра,
	Алексей.

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

[Aleksey Novodvorsky]

ср, 13 апр. 2022 г. в 14:17, Alexey Sheplyakov <asheplyakov@basealt.ru>:
>
> Здравствуйте!
>
> On Wed, Apr 13, 2022 at 01:01:15PM +0300, Dmitry V. Levin wrote:
>
> > > > Сейчас деревья каждого ядра ведутся в равном стиле, но они будут со
> > > > временем преобразованы -- каждое ядро будет иметь свой единый бранч с
> > > > merge commit'ами, где не переписывается история, по крайней мере, между
> > > > мажорными версиями.
> > > > В каждый новый бранч (то есть в новую мажорную версию нового ядра)
> > > > предлагается заново слать свои патчсеты, а затем только обновления
> > > > (новые коммиты поверх уже принятого патчсета),
> > >
> > > А вот тут -- уже нет. Это гарантировано не работает. Поддерживать
> > > несколько веток (mainline и пару LTS) * несколько плат * несколько
> > > версий прошивок возможно только при явном разделении "здесь моё,
> > > а здесь -- не моё", т.е. при rebase на свежий mainline, и перенос
> > > получившихся патчей на LTS ветки.
> >
> > Посмотрите уже, наконец, опыт linux-rt:
>
> Какое отношение он имеет к рассматриваемой проблеме (поддержка новых
> процессоров, плат в нескольких ветках ядер)? Ещё раз:
>
> > К тому же цикл разработки (поддержки SoC/плат) зависит не только
> > (и не столько) с циклом разработки ядра (mainline, LTS, "нашего").
> > А прежде всего от
> > 1) Появления новых процессоров/плат
> > 2) Появлением новых драйверов/фич (и их переносом из заведомо
> >    устаревшего ядра от производителя процессора/платы).
> > 3) Обновлением прошивки (которые как правило ломают совместимость
> >    и требуют адаптации ядра).
>
>
> > https://lpc.events/event/4/contributions/293/attachments/237/416/maintaining-out-of-tree-patches-over-the-long-term.pdf
>
> Боль и страдания, но чуть полегче - без * "n плат" * "m версий прошивок"
>
> > Это работает, и это, похоже, единственный выход.
>
> У Вас получилось - я рад (кстати, где можно поглядеть на результат?).
> А я проверил - не работает, и только усложняет жизнь.
> Есть кактус только потому, что Вам он нравится - нет уж, увольте.
>
> P.S.
>
> Патчи для поддержки СнК Байкал-М (и плат на его основе) можно взять отсюда:
>
> git://git.altlinux.org/people/asheplyakov/linux.git
>
> - baikalm - для mainline ядра [1] (ветка master)
> - baikalm-5.15.y - для LTS ядра [2] 5.15 (ветка linux-5.15.y)
> - baikalm-5.10.y - для LTS ядра [2] 5.10 (ветка linux-5.10.y)
> - rpi-baikalm-5.15.y - для ядра rpi-5.15.y (https://github.com/raspberrypi/linux.git)
>   поддерживаются raspberry pi, Байкал-М, и rock pi 4 (rk3399)


Замечу только, что поддержка этих устройств и преемственнность такой
подержки в production ядрах критически важна.
Надо бы искать компромисс.
Rgrds, Алексей
> - baikalm-5.17.y - для "стабильного" ядра [2] 5.17.y (ветка linux-5.17.y)
>
> (остальные ветки - для внутреннего пользования).
>
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> [2] git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
>
>
> Ещё раз подчёркиваю - *можно* взять. А можно и не брать - я никого не заставляю.
>
> Всем добра,
>         Алексей.
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel