From: Aleksey Novodvorsky <aen@basealt.ru> To: ALT Linux Team development discussions <devel@lists.altlinux.org> Subject: Re: [devel] Новая схема ведения исходников ядра Date: Mon, 3 Jan 2022 09:25:01 +0300 Message-ID: <CAGvFrt3ibCfG7yrTawTxVnePpmAJyqB+FxkN5h0nkMftRXwaZQ@mail.gmail.com> (raw) In-Reply-To: <CAK42-GqE3tPEkWzVkyWpcu2pty46cmKhHv6Mbn-Z968M0qYROw@mail.gmail.com> пн, 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
next prev parent reply other threads:[~2022-01-03 6:25 UTC|newest] Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-12-03 19:41 Evgeny Sinelnikov 2021-12-03 23:44 ` Andrey Savchenko 2021-12-05 23:22 ` Evgeny Sinelnikov 2021-12-06 13:36 ` Dmitry V. Levin 2021-12-06 18:28 ` Andrey Savchenko 2021-12-06 23:07 ` Evgeny Sinelnikov 2021-12-07 7:38 ` Anton V. Boyarshinov 2021-12-06 8:29 ` Alexey Sheplyakov 2021-12-06 17:32 ` Andrey Savchenko 2021-12-06 20:08 ` Vladimir D. Seleznev 2021-12-06 7:42 ` Anton V. Boyarshinov 2021-12-06 8:09 ` Alexey Sheplyakov 2021-12-06 10:29 ` Anton V. Boyarshinov 2021-12-06 10:26 ` Alexey Sheplyakov 2021-12-06 10:31 ` Anton V. Boyarshinov 2021-12-06 10:47 ` Evgeny Sinelnikov 2021-12-06 11:03 ` Anton V. Boyarshinov 2021-12-06 10:55 ` Anton V. Boyarshinov 2021-12-06 13:25 ` Dmitry V. Levin 2021-12-06 13:35 ` Evgeny Sinelnikov 2021-12-06 13:41 ` Anton V. Boyarshinov 2021-12-06 13:48 ` Evgeny Sinelnikov 2021-12-06 13:51 ` Anton V. Boyarshinov 2021-12-06 13:57 ` Dmitry V. Levin 2021-12-06 14:04 ` Evgeny Sinelnikov 2021-12-06 14:08 ` Dmitry V. Levin 2021-12-06 14:40 ` Anton V. Boyarshinov 2021-12-06 14:54 ` Anton V. Boyarshinov 2021-12-06 15:02 ` Dmitry V. Levin 2021-12-06 15:26 ` Anton V. Boyarshinov 2021-12-06 15:53 ` Dmitry V. Levin 2021-12-06 22:58 ` Evgeny Sinelnikov 2021-12-07 7:47 ` Anton V. Boyarshinov 2021-12-07 16:54 ` Andrey Savchenko 2021-12-06 13:47 ` Dmitry V. Levin 2021-12-06 13:54 ` Evgeny Sinelnikov 2021-12-06 10:53 ` Anton V. Boyarshinov 2021-12-06 11:27 ` Alexey Sheplyakov 2021-12-06 11:41 ` Anton V. Boyarshinov 2021-12-06 12:12 ` Anton Farygin 2021-12-06 12:30 ` Alexey Sheplyakov 2021-12-06 14:53 ` Anton Farygin 2021-12-23 3:28 ` Mikhail Novosyolov 2021-12-23 6:07 ` Andrey Savchenko 2022-01-03 5:07 ` Evgeny Sinelnikov 2022-01-03 5:33 ` Evgeny Sinelnikov 2022-01-10 8:53 ` Anton V. Boyarshinov 2022-01-11 8:01 ` Anton V. Boyarshinov 2022-01-11 8:12 ` Anton V. Boyarshinov 2022-01-11 8:55 ` Paul Wolneykien 2022-01-11 9:10 ` Sergey V Turchin 2022-01-11 9:33 ` Anton Farygin 2022-01-11 9:37 ` Alexey V. Vissarionov 2022-01-12 0:26 ` [devel] PoC: gear-submodule-update Ex: " Vitaly Chikunov 2022-01-12 0:39 ` Dmitry V. Levin 2022-01-12 12:20 ` Dmitry V. Levin 2022-01-12 12:40 ` Alexey Gladkov 2022-01-12 12:53 ` Alexey Gladkov 2022-01-12 13:10 ` Alexey Gladkov 2022-01-12 13:26 ` Dmitry V. Levin 2022-01-12 16:59 ` [devel] gear-store-submodules Dmitry V. Levin 2022-01-12 19:14 ` Alexey Gladkov 2022-01-12 20:06 ` Dmitry V. Levin 2022-01-12 21:14 ` Alexey Gladkov 2022-01-12 1:04 ` [devel] PoC: gear-submodule-update Ex: Новая схема ведения исходников ядра Vladislav Zavjalov 2022-01-12 6:01 ` Anton Farygin 2022-01-11 10:30 ` [devel] " Vladimir D. Seleznev 2022-01-11 12:18 ` Anton V. Boyarshinov 2022-01-19 9:53 ` Vladimir D. Seleznev 2022-01-19 9:56 ` Anton V. Boyarshinov 2022-01-19 10:15 ` Anton V. Boyarshinov 2022-01-19 10:24 ` Alexey V. Vissarionov 2022-01-19 10:58 ` Anton V. Boyarshinov 2022-01-19 10:31 ` [devel] Автодекларация патчей в спеках (Was: Новая схема ведения исходников ядра) Vladimir D. Seleznev 2022-01-19 10:32 ` Anton Farygin 2022-01-19 10:48 ` Vladimir D. Seleznev 2022-01-19 11:10 ` Anton Farygin 2022-01-19 10:57 ` Anton V. Boyarshinov 2022-01-19 11:09 ` Alexey V. Vissarionov 2022-01-19 10:52 ` [devel] Новая схема ведения исходников ядра Anton V. Boyarshinov 2022-01-03 6:17 ` Evgeny Sinelnikov 2022-01-03 6:25 ` Aleksey Novodvorsky [this message] 2021-12-06 11:54 ` Alexey Sheplyakov 2021-12-06 12:35 ` Dmitry V. Levin 2021-12-06 13:29 ` Evgeny Sinelnikov 2021-12-06 13:48 ` Anton V. Boyarshinov 2021-12-08 8:07 ` [devel] Отделяя котлеты от мух (было Re: Новая схема ведения исходников ядра) Alexey Sheplyakov 2021-12-08 8:54 ` Anton V. Boyarshinov 2021-12-08 10:32 ` Alexey Sheplyakov 2021-12-06 14:31 ` [devel] Новая схема ведения исходников ядра Dmitry V. Levin 2021-12-06 14:55 ` Anton Farygin 2021-12-23 3:14 ` Mikhail Novosyolov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAGvFrt3ibCfG7yrTawTxVnePpmAJyqB+FxkN5h0nkMftRXwaZQ@mail.gmail.com \ --to=aen@basealt.ru \ --cc=devel@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git