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 — на любителя и не всегда годится, например, когда часть
патчей нужно выбросить по тем или иным причинам.

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

Так себе удобство, честно скажу; я пользуюсь этим когда
приходится, но именно как вынужденной мерой. Хотя бы потому, что
в git крайне не рекомендуется конкурентно коммитить из двух разных
worktree.

>  + перед сборкой необходимо обновить 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

В общем-то, там все наши патчи легко видно по --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 делать, хотя бы по
запросу. Но это уже хотелка вне ядра.

Best regards,
Andrew Savchenko