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

Пн Янв 3 08:41:18 MSK 2022

пн, 3 янв. 2022 г., 08:08 Evgeny Sinelnikov <sin на altlinux.org>:

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

И вас!

>
> чт, 23 дек. 2021 г. в 10:08, Andrey Savchenko <bircoph на 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 на 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-репах, то неплохо бы его и использовать (ну,
> хотелось бы). В том виде, в котором мы ведём сборку сейчас, во многих
> случаях, нашими наработками воспользоваться, мягко говоря, довольно
> затруднительно. Если мы не ставим себе такой задачи, то у меня нет
> больше никаких вопросов.
>

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

Rgrds, Алексей

>
> PS: Кстати, у федоры тоже есть git-репы для своих пакетов:
> - https://src.fedoraproject.org/rpms/kernel/
> Пример, ядра не очень показателен, но даже в нём сразу понятно чем
> отличается их ядро от апстримного. А про наше нужно ещё догадаться,
> изучив и разобрав gear-правила, которые для каждого пакета свои. Стоит
> отметить, что gear на другие дистрибутивы не портирован, хотя у меня
> есть свой порт на centos.
>
> PPS: Понятно, что предложенная схема имеет свои издержки. Но "отрывать
> руки" - это уже как-то за гранью. Я если отрывать руки за то, что
> сборка есть, а патчей нет? Ну, то есть они как бы есть, но передать их
> в апстрим требует нетривиальной работы?
>
>
> --
> Sin (Sinelnikov Evgeny)
> _______________________________________________
> Devel mailing list
> Devel на lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
----------- следующая часть -----------
Вложение в формате HTML было удалено...
URL: <http://lists.altlinux.org/pipermail/devel/attachments/20220103/6e8dbb59/attachment-0001.html>