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

[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, Алексей
>>
>>
>> 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)