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

Пн Янв 3 09:34:14 MSK 2022

пн, 3 янв. 2022 г., 09:25 Aleksey Novodvorsky <aen на basealt.ru>:

> пн, 3 янв. 2022 г. в 09:18, Evgeny Sinelnikov <sin на altlinux.org>:
> >
> > пн, 3 янв. 2022 г. в 09:41, Aleksey Novodvorsky <aen на basealt.ru>:
> > >
> > >
> > >
> > >
> > >
> > > пн, 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, Алексей

>
> Rgrds, Алексей
> >
> > Честно говоря, я не очень понимаю как, и можно ли вообще, добиться
> > второго варианта. Кроме того, разработка для апстрима и партнёров в
> > равной (если не в большей) требует выявления регрессий на всех
> > основных платформах при разработке под какую-то одну.
> >
> >
> >
> > > 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
> > >
> > > _______________________________________________
> > > Devel mailing list
> > > Devel на lists.altlinux.org
> > > https://lists.altlinux.org/mailman/listinfo/devel
> >
> >
> >
> > --
> > 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/71c9e337/attachment-0001.html>