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

Пн Янв 3 09:25:01 MSK 2022

пн, 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, Алексей
> >>
> >>
> >> 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