ALT Linux Team development discussions
 help / color / mirror / Atom feed
From: Evgeny Sinelnikov <sin@altlinux.org>
To: ALT Linux Team development discussions <devel@lists.altlinux.org>
Subject: Re: [devel] Новая схема ведения исходников ядра
Date: Mon, 3 Jan 2022 09:07:43 +0400
Message-ID: <CAK42-Goz1kTeMEyj4zGUFLD4KTas-QU=G_ZtDpUrfyYAKgkYFg@mail.gmail.com> (raw)
In-Reply-To: <20211223090747.928b5667b416a58c2c55eeb6@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-репах, то неплохо бы его и использовать (ну,
хотелось бы). В том виде, в котором мы ведём сборку сейчас, во многих
случаях, нашими наработками воспользоваться, мягко говоря, довольно
затруднительно. Если мы не ставим себе такой задачи, то у меня нет
больше никаких вопросов.

PS: Кстати, у федоры тоже есть git-репы для своих пакетов:
- https://src.fedoraproject.org/rpms/kernel/
Пример, ядра не очень показателен, но даже в нём сразу понятно чем
отличается их ядро от апстримного. А про наше нужно ещё догадаться,
изучив и разобрав gear-правила, которые для каждого пакета свои. Стоит
отметить, что gear на другие дистрибутивы не портирован, хотя у меня
есть свой порт на centos.

PPS: Понятно, что предложенная схема имеет свои издержки. Но "отрывать
руки" - это уже как-то за гранью. Я если отрывать руки за то, что
сборка есть, а патчей нет? Ну, то есть они как бы есть, но передать их
в апстрим требует нетривиальной работы?


-- 
Sin (Sinelnikov Evgeny)

  reply	other threads:[~2022-01-03  5:07 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 [this message]
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
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='CAK42-Goz1kTeMEyj4zGUFLD4KTas-QU=G_ZtDpUrfyYAKgkYFg@mail.gmail.com' \
    --to=sin@altlinux.org \
    --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