[devel] Новая схема ведения исходников ядра

[Evgeny Sinelnikov]

пн, 6 дек. 2021 г. в 16:35, Dmitry V. Levin <ldv at altlinux.org>:
>
> On Fri, Dec 03, 2021 at 11:41:56PM +0400, Evgeny Sinelnikov wrote:
> > Доброй ночи,
> >
> > хочу сообщить, что asheplyakov@ по мотивам наших с ним обсуждений о
> > разработке ядра подготовил новую сборку на основе текущей в сизифе.
> > http://git.altlinux.org/gears/k/kernel-image-un-def.git
> >
> > Суть: для того, чтобы вести не только поддержку сборки, но разработку
> > ядра, нацеленную на продвижение наших патчей в апстрим, предлагается
> > рассмотреть новую схему ведения исходников.
> >
> > - все наши патчи складываются "ребейзом" или "черипиком" поверх
> > последнего релиза, который заявлен в версии пакета
> > kernel-image-FLAVOUR:
> >  + https://github.com/altlinux/linux-arm/commits/altlinux-5.15.y
> >
> > - схема сборки остаётся прежней за следующими дополнениями:
> >  + ветка sisyphus содержит только gear-rules и spec (ну, пока и не
> > надо больше - вряд ли потребуется, хотя я бы предложил ещё README по
> > сборке);
> >  + исходники включают в себя только продуктивные патчи и ветка с ними
> > перед сборкой "мёрджится" с git merge -s ours;
> >  + для удобной работы над исходниками можно воспользоваться командой
> > git worktree, позволяющей получить отдельную ветку в соседнем каталоге
> > на одном и том же git-репозитории;
> >  + перед сборкой необходимо обновить commitid в .gear/tags/list
> > https://github.com/altlinux/linux-arm/commits/sisyphus-un-def
> >
> > В целом, этот подход ничего не ломает, но очень много позволяет:
> > - чётко отслеживать пачти;
> > - всегда знать чем наше ядро отличается от апстримного не на уровне
> > одного большого "дифа", доступного только git в консоли, но и на
> > уровне полного списка патчей, доступного также через web-интерфейс в
> > соответствующей ветке;
> > - всегда иметь подготовленный набор патчей для текущего ядра.
> >
> > Я бы ещё предложил делать два патча:
> > - linux-x.y.0-x.y.z.patch
> > - linux- x.y.z-alt.patch
> > тогда патч в нашем SRCRPM-пакете ядра будет не столь бесполезен, чем сейчас.
> >
> > Такой подход позволит всегда знать какие патчи есть в нашем ядре, а
> > также даст возможность передать наши ядра для совместной разработки
> > коллегам из компаний, занимающихся разработкой аппаратных средств -
> > процессоров и новых устройств.
> >
> > Тестовая сборка упала из-за ограничений на подпись.
> > #291228 FAILED #2 [test-only] sisyphus
> > linux.git=kernel-image-un-def-5.15.6-alt2 [...]
> > http://git.altlinux.org/tasks/291228/logs/events.2.1.log
> > ...
> >  - Verifying /boot/vmlinuz-5.15.6-un-def-alt2
> >  Signature verification failed
> >  = PESIGN verification failures 1, successes 0.
> >  /usr/lib/rpm/check-pesign.filetrigger failed
> >  error: posttrans filetriggers scriptlet failed, exit status 1
> > ...
> > То есть её можно пробовать.
> > Это, по сути, та же сборка, что и alt1, но по новой схеме.
>
> Я не понял, вы что, предлагаете внутри одной ветки ядра 5.15 делать rebase
> для каждого обновления из апстримного 5.15?

В целом, да. Так и есть.

Даже если они разбросаны по отдельным веткам -fix и -feat, их всё
равно время от времени нужно ребейзить. Если код сильно не менялся, то
он и ребейзится просто и мерджится просто. Если менялся сильнее, чем
этого хочется, то мы получаем от "мерджа" немного больше удобства,
которое картины, по сути не меняет.

Если делать не "ребейз", а "мердж", то хотелось бы понять:
- как с этим работать сторонним разработчикам, от какого ядра отталкиваться?
- какой подход к разработке ядра мы предлагаем другим участникам процесса?
- где и как можно найти исходники нашего ядра только с продуктивными патчами?
- готовы ли вы выковыривать патчи размазанные мердж-коммитами в ветках
других участников разработки?

В последнем я уверен, что ответ - нет.

Сценарий "внутри одной ветки ядра 5.15 делать rebase для каждого
обновления из апстримного 5.15" - это понятный вариант. Другие требуют
пояснений относительно текущего подхода.



-- 
Sin (Sinelnikov Evgeny)