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

[Evgeny Sinelnikov <sin@altlinux.org>]

сб, 4 дек. 2021 г. в 03:45, Andrey Savchenko <bircoph@altlinux.org>:
>
> On Fri, 3 Dec 2021 23:41:56 +0400 Evgeny Sinelnikov wrote:
> > Суть: для того, чтобы вести не только поддержку сборки, но разработку
> > ядра, нацеленную на продвижение наших патчей в апстрим, предлагается
> > рассмотреть новую схему ведения исходников.
> >
> > - все наши патчи складываются "ребейзом" или "черипиком" поверх
> > последнего релиза, который заявлен в версии пакета
> > kernel-image-FLAVOUR:
> >  + https://github.com/altlinux/linux-arm/commits/altlinux-5.15.y
>
> cherry-pick не осилит merge коммиты (максимум, что можно от него
> получить, это всю ветку одним коммитом, с потерей истории). Ну
> а rebase — на любителя и не всегда годится, например, когда часть
> патчей нужно выбросить по тем или иным причинам.

Вопрос в том, что у нас нет сейчас возможности вести разработку ядра
на тех же исходниках, что и для сборки. Разработчикам же, так или
иначе, приходится проводить rebase или cherry-pick. Это не вопрос
предпочтений - это вопрос возможности вести разработку со сторонними
разработчиками, которым нужны наши исходники без множества
merge-коммитов. Взаимодействуя с ними, мы сами просим от них того же,
чтобы не искать по их исходникам нужные нам патчи, чтобы забрать себе.

>
> > - схема сборки остаётся прежней за следующими дополнениями:
> >  + ветка sisyphus содержит только gear-rules и spec (ну, пока и не
> > надо больше - вряд ли потребуется, хотя я бы предложил ещё README по
> > сборке);
> >  + исходники включают в себя только продуктивные патчи и ветка с ними
> > перед сборкой "мёрджится" с git merge -s ours;
> >  + для удобной работы над исходниками можно воспользоваться командой
> > git worktree, позволяющей получить отдельную ветку в соседнем каталоге
> > на одном и том же git-репозитории;
>
> Так себе удобство, честно скажу; я пользуюсь этим когда
> приходится, но именно как вынужденной мерой. Хотя бы потому, что
> в git крайне не рекомендуется конкурентно коммитить из двух разных
> worktree.

Опять. Это не вопрос удобства. Кому-то так даже удобнее, может быть.
Но тут важнее другое возможность увидеть исходники с теми патчами,
которые у нас есть, а не искать их кусками размазанными по истории
после очередного merge-коммита.

> >  + перед сборкой необходимо обновить commitid в .gear/tags/list
> > https://github.com/altlinux/linux-arm/commits/sisyphus-un-def
>
> Вот эта головная боль тоже нежелательна. Потому что при отладке
> где-нибудь на другой железке или в инсталляторе пакет приходится
> часто пересобирать. Да, скриптуется, но сборка и так сложна из-за
> specsubst и разных kflavour.

А разработка, в ином случае, вообще невозможна. Как взаимодействовать
с апстримом? Как взаимодействовать с теми, кто берёт апстримные
исходники? Ответ: "Пока никак". Вести две параллельных истории. Не
хотелось бы.

> > В целом, этот подход ничего не ломает, но очень много позволяет:
> > - чётко отслеживать пачти;
> > - всегда знать чем наше ядро отличается от апстримного не на уровне
> > одного большого "дифа", доступного только git в консоли, но и на
> > уровне полного списка патчей, доступного также через web-интерфейс в
> > соответствующей ветке;
>
> А вы точно работали с нашим ядром? Я регулярно переношу все наши
> патчи на e2k ядро (кроме патчей для других архитектур). Для этого
> используются ветка нужной версии из
> git.alt:/people/kernelbot/packages/kernel-image.git

Конечно, работали. Давайте посмотрим на ветку ядра, которую удалось получить:
https://github.com/altlinux/linux-arm/commits/altlinux-5.15.y

Где иначе и как ещё можно найти и увидеть полный список наших патчей
по-отдельности по сравнению с апстримом?

> В общем-то, там все наши патчи легко видно по --first-parent;

Давайте посмотрим как. Вот есть коллеги из компании разработчика
железа. Они хотя собрать ядро, как у нас, но они планируют апстримить
свои патчи. Куда из прикладывать с нашим ядром? В ветку, где куча
наших релизных коммитов? Зачем им это?

> cherry-pick работает, но не с merge коммитами, которых там хватает
> из всяких небольших тематических веток вроде kernelbot/fix-strlcpy.
> Вот с ними засада, приходится повторять merge коммиты, git rerere
> облегчает работу, но его кеш локален нельзя запушить в то же
> дерево, чтоб поделиться с другими или просто перетащить на другую
> машину.

Это ещё одна потенциальная проблема. Но и без этого хватает проблем.

В итоге, текущая схема не удовлетворяет возможности вести совместную
разработку с теми, кто берёт апстримное ядро и добавляет свои патчи.
Тут либо мы поддерживаем переход к нашему ядру. Например, так как
предложено. Либо у нас два набора исходников - удобная для сборки и
удобная для разработки. Я предлагаю вести одну - удобную для
разработки. Для сборки она не становится неудобнее, скорее меняет
предпочтения.

> > - всегда иметь подготовленный набор патчей для текущего ядра.
> >
> > Я бы ещё предложил делать два патча:
> > - linux-x.y.0-x.y.z.patch
> > - linux- x.y.z-alt.patch
> > тогда патч в нашем SRCRPM-пакете ядра будет не столь бесполезен, чем сейчас.
>
> Я бы вообще от них отказался (в общем, у меня так и сделано).
> В гите же вся работа, вот из него и нужно собирать. Просто git
> тяжёлый и хорошо бы сборочнице shallow clone делать, хотя бы по
> запросу. Но это уже хотелка вне ядра.

Ну, может быть.


-- 
Sin (Sinelnikov Evgeny)