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

Пн Янв 3 08:07:43 MSK 2022

С новым годом!

чт, 23 дек. 2021 г. в 10:08, Andrey Savchenko <bircoph at altlinux.org>:
>
> On Thu, 23 Dec 2021 06:28:34 +0300 Mikhail Novosyolov wrote:
> >
> > 06.12.2021 15:12, Anton Farygin пишет:
> > > On 06.12.2021 14:41, Anton V. Boyarshinov wrote:
> > >> В Mon, 6 Dec 2021 15:27:11 +0400
> > >> Alexey Sheplyakov <asheplyakov at basealt.ru> пишет:
> > >>
> > >>> 2) Некий логически монолитный кусок кода (например, LSM модуль AltHa, или
> > >>>     драйвер dwmac-baikal) оказывается размазанным тонким слоем по N коммитам.
> > >>>     При переносе на более свежее ядро из этих N коммитов всё равно надо сделать
> > >>>     один патч (а затем доработать его вслед за изменившимися API).
> > >> Да, эти "стабильные" патчи живут в отдельных ветках feat-* и fix-*

Где их искать?
Под какие мажорные релизы они поддерживаются?
Можно ли рассчитывать, что патчи из этих веток лягут без конфликтов на
более старшие минорые версии тех мажорных, под которые они ведутся?

Здесь я их не наблюдаю:
- http://git.altlinux.org/gears/k/kernel-image-std-def.git
- http://git.altlinux.org/gears/k/kernel-image-un-def.git

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

> > >> И, если я правильно понимаю, упоминаемым партнёрам они не очень
> > >> интересны. Зачем их при каждой сборке вытаскивать наверх ценой
> > >> испорченной истории мне не ясно.
> > >
> > > Если мне гит при каждом merge ядра будет ругаться на unrelated history, то я буду громко и сильно ругаться на тех людей, которые так делают.
> > >
> > > Давайте ещё раз подумаем и придумаем удобное решение.
> > >
> > > А как ведёт ядро та же убунта ? Почему у них нет этой проблемы ?
> > > https://git.launchpad.net/~canonical-kernel/ubuntu/+source/linux-oem/+git/focal?h=oem-5.10
> > >
> > По моим наблюдениям примерно годичной давности, убунта регулярно форс-пушит в свой гит, который часто не соответствует ушедшим в репозиторий исходникам. С таким гитом работать невозможно. Точно не пример для подражания.

Ну, наверное, убунта это делает из каких-то соображений. Не из прихоти
же? Субъективные предпочтения тоже бывают, но тут не тот случай, когда
всё к этому сводится.

> Согласен. За push --force в репозитории, которые в разработке
> используются другими людьми, нужно руки отрывать.

Не согласен. Смотря в каком контексте идёт речь о разработке. Пачка
запутанных merge-коммитов - это интересная история для пакета, но не
для разработки того исходного кода, который собирается в этом пакете.

О какой, вообще, разработке идёт речь? Что вы называете разработкой,
если отсутствует плановый сценарий передачи исходников в апстрим и не
заложен подход взаимодействия с другими разработчиками, которые тоже
взаимодействуют с апстримом и этот апстрим не мы?

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

При работе с апстримом и попытках передать астриму исходники
приходится делать регулярный git rebase и git push --force. Это же
очевидно. Вариант - передать патч в электронном сообщении только
скрывает отсутствие этого --force, который, фактически, всё равно,
имеет место быть, поскольку этот патч равносилен цепочке git
cherry-pick && git rebase, после которой неизбежен --force или
параллельная история с кучей merge-коммитов, которая никому не
интересна для разработки, даже нам самим.

Не стоит называть любую сборку пакета в репозиторий участием в
разработке. Это иногда так, но очень и очень редко. Во многих случаях
авторы даже не в курсе, что мы их проект собираем. И разница тут
именно в том, что для передачи исходников и для совместного ведения
исходного кода приходится чем-то платить. В нашем случае, одним из
удачных вариантов является вариант с разделением веток:
- master - апстрим;
- altlinux - наши патчи;
- sisyphus/p10/p9/... - ветки с gear-правилами и нашим spec-файлом.

Если патчи не нужно отдавать и наш сборочный репозиторий никому не
нужен, то, всё равно, такая схема для разработки удобна, поскольку в
историю изменений исходников не входит ещё и история изменений нашего
spec-файла.

Всё это актуально только в том случае, если:
- мы рассматриваем не личный репозиторий, а репозиторий формата
git.altlinux.org/gears/p/package-name.git, как источник для
взаимодействия с другими разработчиками, включая нас самих;
- мы исходим из того, что у нас имеется общий апстрим (ветка master),
который, как первоисточник, используется всеми разработчиками;
- задача, которую мы совместно решаем, состоит в том, чтобы
максимально быстро передавать наши наработки, при необходимости, в
апстрим или друг другу;
- а длительная поддержка наших наработок предполагает, чтобы эта
возможность не утрачивалась в угоду мнимому или объективному, но
весьма условному, удобству.

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

PS: Кстати, у федоры тоже есть git-репы для своих пакетов:
- https://src.fedoraproject.org/rpms/kernel/
Пример, ядра не очень показателен, но даже в нём сразу понятно чем
отличается их ядро от апстримного. А про наше нужно ещё догадаться,
изучив и разобрав gear-правила, которые для каждого пакета свои. Стоит
отметить, что gear на другие дистрибутивы не портирован, хотя у меня
есть свой порт на centos.

PPS: Понятно, что предложенная схема имеет свои издержки. Но "отрывать
руки" - это уже как-то за гранью. Я если отрывать руки за то, что
сборка есть, а патчей нет? Ну, то есть они как бы есть, но передать их
в апстрим требует нетривиальной работы?

-- 
Sin (Sinelnikov Evgeny)