<div dir="auto"><div><br><br><div data-smartmail="gmail_signature"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">пн, 3 янв. 2022 г., 08:08 Evgeny Sinelnikov <<a href="mailto:sin@altlinux.org">sin@altlinux.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">С новым годом!<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">И вас! </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>
чт, 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></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>
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></blockquote></div></div></div>