ALT Linux Team development discussions
 help / color / mirror / Atom feed
From: Vitaly Lipatov <lav@altlinux.ru>
To: ALT Linux Team development discussions <devel@lists.altlinux.org>
Subject: Re: [devel] Устаревшая концепция бранчей или стабильный бранч как основа разработки
Date: Tue, 20 Oct 2020 23:58:25 +0300
Message-ID: <5d511fdd0fde16467115b59402726446@etersoft.ru> (raw)
In-Reply-To: <20201020202115.bf2b3d8959e55aa39caa8e25@altlinux.org>

Andrey Savchenko писал 20.10.20 20:21:
...
>> Первый момент. Концепция вечно нестабильного репозитория, которым 
>> нельзя
>> пользоваться, не очень популярна среди пользователей.
> 
> Не говорите за всех, пожалуйста.
Вы хотите сказать, что у кого-то популярна концепция репозитория, 
которым нельзя пользоваться? :) Мне кажется, причина другая.
Я на всякий случай ещё раз повторюсь, что я излагал своё мнение, и 
полагал, что при этом не требуется оговаривать всё время, что я говорю 
не за всех :)

> Как пользователь, я не вижу смысла использовать бранчи с устаревшим
> софтом. В первую очередь потому, что, как говорит Брюс Шнайер,
Понятно, что стабильный репозиторий со свежим софтом — это то, чего всем 
не хватает.
Но всё же вы не пользователь. Пользователю в силу ограниченности 
возможностей взаимодействия с репозиторием приходится идти на 
компромиссы (читай — использование бранча с устаревшим софтом).

...> ещё менее прозрачна. А эксплойты нередко начинают использовать
> в течении суток после публикации информации, поэтому хуже старого
> софта сложно что-то придумать.
Очень поддерживаю этот подход. Вовремя не обновился — уже проиграл. 
Собственно поэтому я и говорил о том, что надо сделать Сизиф более 
пригодным для пользователя. Просто при этом я его назвал стабильным 
бранчем.

> Во вторых, как пользователю, мне нужны новые плюшки. Не во всём
> софте и не всегда, но редко да метко. И ждать месяцами не горю
> желанием.
Редко да метко софт может обновляться и в p9. Особенно если кроме вас, 
никто им не пользуется.

> В общем, для меня, как для пользователя Альта, всё, кроме Сизифа —
> бесполезно.
Возможно, я был не прав, и пользователи Альта это такие особенные 
пользователи, которые могут и пакет откатить, и initrd отладить.

> Поэтому я считаю замечательным, что наш дистрибутив удовлетворяет
> потребности широких категорий пользователей: как тех, кто хочет
> быть на передовой прогресса, так и тех, кому нужны стабильные,
> тихие, долгоиграющие решения. И поэтому я крайне негативно отношусь
> к попытке задавить одно из направлений в угоду другому.
Есть небольшой нюанс, что Сизиф это не дистрибутив. Я не предлагал 
ничего задавить. Возможно, мысль моя осталась не ясна.

>> Также и несколько
>> теряется смысл для мантейнеров — зачастую они собирают пакеты в этот
>> репозиторий, а сами пользуются другим, более стабильным.
> 
> Опять же, не говорите за всех. Как мейнтейнер я сам пользуюсь
> Сизифом.
Я тоже как мантейнер пользуюсь Сизифом. Собираю в нём пакеты. Но кроме 
него у меня ещё сотня систем на стабильном бранче. При такой статистике 
я не могу говорить, что пользуюсь Сизифом.

> Мало того, я стараюсь не связываться с бранчами, потому
> что там долгая волокита и лишняя головная боль. Зачем мне, как
> разработчику, это всё нужно? Дополнительная трата времени.
Это смотря, что вы разрабатываете. Я отлично понимаю менталитет 
разработчика Сизифа — ничего не нужно, обновляй знай пакеты, кати камень 
на гору, да скатывай. Но всё же надеюсь, что Сизиф это не самоцель, а 
инструмент, пакетная база, инфраструктура взаимодействия разработчиков.

...
> Апстримы апстримам рознь. Где-то CI, а где-то сотни сломанных
> тестов, которые корректно работают только в очень специфических
> условиях. Где-то сементическое версионирование в библиотеках,
> а где-то забандленые статикой на уровне языка библиотеки и модули
> (привет golang).
> 
> Количество систем сборок кода возрастает, многие крупные проекты
> считают своим священным долгом изобрести собственную. Их безумие
> тоже возрастает, чего стоят забитые в meson на уровне конфигов
> апстрима свойства компилятора вместо проверки на реальном
> компиляторе того, что он умеет. Ну а про всякие waf, dmake, gyp
> и т.п. мерзость я вообще промолчу. Python даже в сборочную систему
> glibc запихнули; ждём в ядре, run-time, systemd-kerneld-pythond.
> 
> Мораль простая: есть как тенденция по улучшению качества кода
> и наведению порядка, так и тенденция по усложнению сборочных
> систем, увеличению числа фич, зависимостей, общему увеличению
> количества пакетов и росту как их собственной сложности, так и
> сложности взаимосвязей между ними.
> 
> Сложно сказать, какая из этих тенденций преобладает: сильно от
> конкретного софта зависит, но в целом на уровне совокупности всего
> ПО в дистрибутиве, по моему мнению, нагрузка на мейнтенеров
> возрастает.
Спасибо за картину, тенденции действительно разные.

...
> Автоматизируются легко только весьма специфические классы пакетов,
> как, например, массовые несложные модули языков (perl, ruby, python
> и т.п.), где, по сути, есть своя система управления модулями
> и нужно транслировать её в spec. Но и там возникают сложности, когда
> пакеты становятся большими и нетривиальными, ну тот же numpy,
> например.
Всё так, но система сборки (например, autotools, которую пишут 20 лет), 
предназначена именно для того, чтобы без проблем собрать проект в любом 
окружении.

> Сложные пакеты неавтоматизируемы, за исключением некоторых рутинных
> операций: glibc, binutils, gdb, kernel, libreoffice, qt и т.п.
> 
> Просто посмотрите на количество патчей в любых дистрибутивах,
> особенно на тулчейн. И после этого не говорите ерунды про то, что
> апстримы делают пакеты, которые можно прямо из коробки в
> дистрибутиве использовать.
Тулчейн это антипример, который как раз подтверждает правило. К тому же 
просто тулчейны никому не нужны, поэтому они в таком состоянии. 
Тулчейном пользуются те, кто его не разрабатывает. И разрабатывают те, 
кто в общем-то его не использует. А если и использует, то на разработку 
внимания остаётся мало времени.
На количество патчей я смотрю, и их количество это плохой признак. И 
тулчейны я собираю, тут чем меня удивлять.

> Для сложных пакетов нагрузка на мейнтенера наоборот возрастает,
> т.к. растёт сложность самих пакетов.
Рост сложности может и должен происходить внутри, с внешним упрощением.
Чтобы за пределы configure && make ничего не выходило.

>> На самом деле предложение в том, чтобы основной веткой разработки стал
>> репозиторий, который бранчуется при крупных несовместимых изменениях
>> (например, критичных обновлениях тулчейна, glibc или KDE :)).
>> Репозитории Компании (p9 и т.д.) при этом забирают изменения из такого
>> репозитория согласно своим регламентам.
> 
> Очень надеюсь, что такого никогда не будет, потому что разработка
> здорового дистрибутива всегда идёт сверху вниз: new -> stable
> с градациями зависящими от дистрибутива.
Это вы рассказываете стереотип. Он не обязательно транслирует лучший 
подход.
Но я не предлагал ничего переворачивать.

Я всего лишь о том, что стоит перестать говорить о том, что Сизиф это 
нестабильный репозиторий, а нужно, уважая его пользователей, стараться 
его не разваливать.
Почему эта идея вызвала столько критики, я не понял.

>> Отличия от нынешней схемы (они же — преимущества) я вижу такие:
>> * бранчевание репозитория происходит в момент технологической
>> необходимости (когда весь мир переходит,
> 
> Нет такого, что «весь мир» переходит. Все решают для себя, многие
> параллельно альтернативы поддерживают.
Есть такое, определённая синхронизация есть.

>> Кстати, разработчикам не хватает доступного инструмента по проверке
>> пересобираемости (её умеют делать при тестировании для прохождения
...
> http://git.altlinux.org/people/ldv/packages/beehive.git
Поиск по вики слова beehive даёт «я рылся grep'ом в логах beehive»
Возможно, именно beehive я имел в виду, когда писал «не хватает 
доступного инструмента».
Пока что мне кажется, что beehive это не инструмент, это программная 
часть ldv@.

Тут интересно, чем пользуются тестировщики при проверки собираемости в 
p9. У меня есть подозрение, что чем-то другим. А если beehive, тогда 
где-то есть и описание.




-- 
С уважением,
Виталий Липатов,
ALT Linux Team


  parent reply	other threads:[~2020-10-20 20:58 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-13 19:47 Vitaly Lipatov
2020-10-13 20:23 ` Aleksey Novodvorsky
2020-10-13 22:39     ` Aleksey Novodvorsky
2020-10-14 12:02   ` Vitaly Lipatov
2020-10-14 12:17     ` Anton Farygin
2020-10-14  7:06 ` Sergey V Turchin
2020-10-14 10:39   ` Vitaly Lipatov
2020-10-14 10:55     ` Sergey V Turchin
2020-10-14 14:22   ` Arseny Maslennikov
2020-10-14 14:46     ` Sergey V Turchin
2020-10-14 15:28       ` Arseny Maslennikov
2020-10-15  6:48         ` Sergey V Turchin
2020-10-15  6:50         ` Sergey V Turchin
2020-10-20 17:21 ` Andrey Savchenko
2020-10-20 18:28   ` Alexey Gladkov
2020-10-21  5:52     ` Anton Farygin
2020-10-21  6:59       ` Alexey Gladkov
2020-10-21  7:58         ` [devel] Ресурсы для CI в Sisyphus или про review кода su из coreutuls Anton Farygin
2020-10-21 10:01           ` [devel] " Dmitry V. Levin
2020-10-21 10:18             ` [devel] про review кода su из util-linux Anton Farygin
2020-11-10 22:45     ` [devel] Устаревшая концепция бранчей или стабильный бранч как основа разработки mikhailnov
2020-10-20 20:58   ` Vitaly Lipatov [this message]
2020-10-21  5:54     ` Anton Farygin
2020-10-21  1:46   ` Антон Мидюков
2020-10-21  7:29     ` Andrey Savchenko
2020-10-21  7:34       ` Антон Мидюков
2020-10-21  9:56   ` [devel] CI для Сизифа Dmitry V. Levin

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=5d511fdd0fde16467115b59402726446@etersoft.ru \
    --to=lav@altlinux.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