<div dir="auto"><div><br><div data-smartmail="gmail_signature"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">пн, 3 янв. 2022 г., 09:25 Aleksey Novodvorsky <<a href="mailto:aen@basealt.ru">aen@basealt.ru</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">пн, 3 янв. 2022 г. в 09:18, Evgeny Sinelnikov <<a href="mailto:sin@altlinux.org" target="_blank" rel="noreferrer">sin@altlinux.org</a>>:<br>
><br>
> пн, 3 янв. 2022 г. в 09:41, Aleksey Novodvorsky <<a href="mailto:aen@basealt.ru" target="_blank" rel="noreferrer">aen@basealt.ru</a>>:<br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > пн, 3 янв. 2022 г., 08:08 Evgeny Sinelnikov <<a href="mailto:sin@altlinux.org" target="_blank" rel="noreferrer">sin@altlinux.org</a>>:<br>
> >><br>
> >> С новым годом!<br>
> ><br>
> ><br>
> > И вас!<br>
> >><br>
> >><br>
> >> чт, 23 дек. 2021 г. в 10:08, Andrey Savchenko <<a href="mailto:bircoph@altlinux.org" target="_blank" rel="noreferrer">bircoph@altlinux.org</a>>:<br>
> >> ><br>
> >> > On Thu, 23 Dec 2021 06:28:34 +0300 Mikhail Novosyolov wrote:<br>
> >> > ><br>
> >> > > 06.12.2021 15:12, Anton Farygin пишет:<br>
> >> > > > On 06.12.2021 14:41, Anton V. Boyarshinov wrote:<br>
> >> > > >> В Mon, 6 Dec 2021 15:27:11 +0400<br>
> >> > > >> Alexey Sheplyakov <<a href="mailto:asheplyakov@basealt.ru" target="_blank" rel="noreferrer">asheplyakov@basealt.ru</a>> пишет:<br>
> >> > > >><br>
> >> > > >>> 2) Некий логически монолитный кусок кода (например, LSM модуль AltHa, или<br>
> >> > > >>> драйвер dwmac-baikal) оказывается размазанным тонким слоем по N коммитам.<br>
> >> > > >>> При переносе на более свежее ядро из этих N коммитов всё равно надо сделать<br>
> >> > > >>> один патч (а затем доработать его вслед за изменившимися API).<br>
> >> > > >> Да, эти "стабильные" патчи живут в отдельных ветках feat-* и fix-*<br>
> >><br>
> >> Где их искать?<br>
> >> Под какие мажорные релизы они поддерживаются?<br>
> >> Можно ли рассчитывать, что патчи из этих веток лягут без конфликтов на<br>
> >> более старшие минорые версии тех мажорных, под которые они ведутся?<br>
> >><br>
> >> Здесь я их не наблюдаю:<br>
> >> - <a href="http://git.altlinux.org/gears/k/kernel-image-std-def.git" rel="noreferrer noreferrer" target="_blank">http://git.altlinux.org/gears/k/kernel-image-std-def.git</a><br>
> >> - <a href="http://git.altlinux.org/gears/k/kernel-image-un-def.git" rel="noreferrer noreferrer" target="_blank">http://git.altlinux.org/gears/k/kernel-image-un-def.git</a><br>
> >><br>
> >> Наверное, это вычисляется. Но для этого потребуется:<br>
> >> - вытянуть гигабайт исходников;<br>
> >> - выяснить какой командой это вычисляется;<br>
> >> - то есть потратить кучу времени без гарантии, что не ошибся и всё<br>
> >> правильно сделал;<br>
> >> - без возможности быстро посмотреть через веб-интерфейс ту часть<br>
> >> истории, которая (казалось бы) должна быть доступна.<br>
> >><br>
> >><br>
> >> > > >> И, если я правильно понимаю, упоминаемым партнёрам они не очень<br>
> >> > > >> интересны. Зачем их при каждой сборке вытаскивать наверх ценой<br>
> >> > > >> испорченной истории мне не ясно.<br>
> >> > > ><br>
> >> > > > Если мне гит при каждом merge ядра будет ругаться на unrelated history, то я буду громко и сильно ругаться на тех людей, которые так делают.<br>
> >> > > ><br>
> >> > > > Давайте ещё раз подумаем и придумаем удобное решение.<br>
> >> > > ><br>
> >> > > > А как ведёт ядро та же убунта ? Почему у них нет этой проблемы ?<br>
> >> > > > <a href="https://git.launchpad.net/~canonical-kernel/ubuntu/+source/linux-oem/+git/focal?h=oem-5.10" rel="noreferrer noreferrer" target="_blank">https://git.launchpad.net/~canonical-kernel/ubuntu/+source/linux-oem/+git/focal?h=oem-5.10</a><br>
> >> > > ><br>
> >> > > По моим наблюдениям примерно годичной давности, убунта регулярно форс-пушит в свой гит, который часто не соответствует ушедшим в репозиторий исходникам. С таким гитом работать невозможно. Точно не пример для подражания.<br>
> >><br>
> >> Ну, наверное, убунта это делает из каких-то соображений. Не из прихоти<br>
> >> же? Субъективные предпочтения тоже бывают, но тут не тот случай, когда<br>
> >> всё к этому сводится.<br>
> >><br>
> >><br>
> >> > Согласен. За push --force в репозитории, которые в разработке<br>
> >> > используются другими людьми, нужно руки отрывать.<br>
> >><br>
> >> Не согласен. Смотря в каком контексте идёт речь о разработке. Пачка<br>
> >> запутанных merge-коммитов - это интересная история для пакета, но не<br>
> >> для разработки того исходного кода, который собирается в этом пакете.<br>
> >><br>
> >> О какой, вообще, разработке идёт речь? Что вы называете разработкой,<br>
> >> если отсутствует плановый сценарий передачи исходников в апстрим и не<br>
> >> заложен подход взаимодействия с другими разработчиками, которые тоже<br>
> >> взаимодействуют с апстримом и этот апстрим не мы?<br>
> >><br>
> >> "Плановый сценарий передачи исходников в апстрим" отсутствует, в<br>
> >> данном случае, потому, что "выковыривать" размазанные по истории патчи<br>
> >> - это антипродуктивный, нерабочий сценарий для любого разработчика,<br>
> >> кроме автора пакета, да и для него тоже неудобная;<br>
> >> "Подход взаимодействия с другими разработчиками, которые тоже<br>
> >> взаимодействуют с апстримом" не заложен, в данном случае, потому, что<br>
> >> сторонним разработчикам не менее нужны наши патчи в доступном виде,<br>
> >> чем апстриму, если мы хотим этой самой совместной разработки.<br>
> >><br>
> >> При работе с апстримом и попытках передать астриму исходники<br>
> >> приходится делать регулярный git rebase и git push --force. Это же<br>
> >> очевидно. Вариант - передать патч в электронном сообщении только<br>
> >> скрывает отсутствие этого --force, который, фактически, всё равно,<br>
> >> имеет место быть, поскольку этот патч равносилен цепочке git<br>
> >> cherry-pick && git rebase, после которой неизбежен --force или<br>
> >> параллельная история с кучей merge-коммитов, которая никому не<br>
> >> интересна для разработки, даже нам самим.<br>
> >><br>
> >> Не стоит называть любую сборку пакета в репозиторий участием в<br>
> >> разработке. Это иногда так, но очень и очень редко. Во многих случаях<br>
> >> авторы даже не в курсе, что мы их проект собираем. И разница тут<br>
> >> именно в том, что для передачи исходников и для совместного ведения<br>
> >> исходного кода приходится чем-то платить. В нашем случае, одним из<br>
> >> удачных вариантов является вариант с разделением веток:<br>
> >> - master - апстрим;<br>
> >> - altlinux - наши патчи;<br>
> >> - sisyphus/p10/p9/... - ветки с gear-правилами и нашим spec-файлом.<br>
> >><br>
> >> Если патчи не нужно отдавать и наш сборочный репозиторий никому не<br>
> >> нужен, то, всё равно, такая схема для разработки удобна, поскольку в<br>
> >> историю изменений исходников не входит ещё и история изменений нашего<br>
> >> spec-файла.<br>
> >><br>
> >> Всё это актуально только в том случае, если:<br>
> >> - мы рассматриваем не личный репозиторий, а репозиторий формата<br>
> >> <a href="http://git.altlinux.org/gears/p/package-name.git" rel="noreferrer noreferrer" target="_blank">git.altlinux.org/gears/p/package-name.git</a>, как источник для<br>
> >> взаимодействия с другими разработчиками, включая нас самих;<br>
> >> - мы исходим из того, что у нас имеется общий апстрим (ветка master),<br>
> >> который, как первоисточник, используется всеми разработчиками;<br>
> >> - задача, которую мы совместно решаем, состоит в том, чтобы<br>
> >> максимально быстро передавать наши наработки, при необходимости, в<br>
> >> апстрим или друг другу;<br>
> >> - а длительная поддержка наших наработок предполагает, чтобы эта<br>
> >> возможность не утрачивалась в угоду мнимому или объективному, но<br>
> >> весьма условному, удобству.<br>
> >><br>
> >> Длительная поддержка наших изменений в апстримных проектах тоже, в<br>
> >> каком-то смысле - разработка. Но совершенно другая задача, если<br>
> >> взаимодействие планируется налаживать на регулярной основе. Если мы<br>
> >> ведём все исходники в git-репах, то неплохо бы его и использовать (ну,<br>
> >> хотелось бы). В том виде, в котором мы ведём сборку сейчас, во многих<br>
> >> случаях, нашими наработками воспользоваться, мягко говоря, довольно<br>
> >> затруднительно. Если мы не ставим себе такой задачи, то у меня нет<br>
> >> больше никаких вопросов.<br>
> ><br>
> ><br>
> > У нас есть по крайней мере две разные задачи: регулярная сборка ядра из единых исходников для основных платформ и разработка для апстрима и партнёров. И это две разные сферы ответственности.<br>
> > То есть задача не только техническая, но управленческая и кадровая. Тянуть одеяло на себя -- самое плохое дело в этой ситуации. Решение нужно комплексное и согласованное, простым оно не будет. Но сейчас есть время и, возможно, ресурсы, подумать над ней.<br>
><br>
> Именно с целью подумать и что-то придумать я и начал эту переписку.<br>
><br>
> Поскольку уже прошло некоторое время и были высказаны различные точки<br>
> зрения, хочу обобщить некоторые тезисы:<br>
> - в идеале нужен общий подход, подходящий для регулярной сборки ядра<br>
> из единых исходников для основных платформ и для разработки для<br>
> апстрима и партнёров;<br>
> - если это по каким-то причинам невозможно, то требуется<br>
> автоматизируемый сценарий получения исходников для разработки в<br>
> точности совпадающий с исходниками для регулярной сборки.<br>
<br>
Да. И что дальше?<br>
Какой следующий шаг, пусть небольшой, но согласованный?<br>
Доверенного эксперта мы пока не нашли.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Вопрос. </div><div dir="auto">В каких репозиториях есть синхронные сборки ядер из единых исходников для разных архитектур, и для каких архитектур? </div><div dir="auto"><br></div><div dir="auto">Rgrds, Алексей</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Rgrds, Алексей<br>
><br>
> Честно говоря, я не очень понимаю как, и можно ли вообще, добиться<br>
> второго варианта. Кроме того, разработка для апстрима и партнёров в<br>
> равной (если не в большей) требует выявления регрессий на всех<br>
> основных платформах при разработке под какую-то одну.<br>
><br>
><br>
><br>
> > Rgrds, Алексей<br>
> >><br>
> >><br>
> >> PS: Кстати, у федоры тоже есть git-репы для своих пакетов:<br>
> >> - <a href="https://src.fedoraproject.org/rpms/kernel/" rel="noreferrer noreferrer" target="_blank">https://src.fedoraproject.org/rpms/kernel/</a><br>
> >> Пример, ядра не очень показателен, но даже в нём сразу понятно чем<br>
> >> отличается их ядро от апстримного. А про наше нужно ещё догадаться,<br>
> >> изучив и разобрав gear-правила, которые для каждого пакета свои. Стоит<br>
> >> отметить, что gear на другие дистрибутивы не портирован, хотя у меня<br>
> >> есть свой порт на centos.<br>
> >><br>
> >> PPS: Понятно, что предложенная схема имеет свои издержки. Но "отрывать<br>
> >> руки" - это уже как-то за гранью. Я если отрывать руки за то, что<br>
> >> сборка есть, а патчей нет? Ну, то есть они как бы есть, но передать их<br>
> >> в апстрим требует нетривиальной работы?<br>
> >><br>
> >><br>
> >> --<br>
> >> Sin (Sinelnikov Evgeny)<br>
> >> _______________________________________________<br>
> >> Devel mailing list<br>
> >> <a href="mailto:Devel@lists.altlinux.org" target="_blank" rel="noreferrer">Devel@lists.altlinux.org</a><br>
> >> <a href="https://lists.altlinux.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">https://lists.altlinux.org/mailman/listinfo/devel</a><br>
> ><br>
> > _______________________________________________<br>
> > Devel mailing list<br>
> > <a href="mailto:Devel@lists.altlinux.org" target="_blank" rel="noreferrer">Devel@lists.altlinux.org</a><br>
> > <a href="https://lists.altlinux.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">https://lists.altlinux.org/mailman/listinfo/devel</a><br>
><br>
><br>
><br>
> --<br>
> Sin (Sinelnikov Evgeny)<br>
> _______________________________________________<br>
> Devel mailing list<br>
> <a href="mailto:Devel@lists.altlinux.org" target="_blank" rel="noreferrer">Devel@lists.altlinux.org</a><br>
> <a href="https://lists.altlinux.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">https://lists.altlinux.org/mailman/listinfo/devel</a><br>
</blockquote></div></div></div>