В Fri, 16 Feb 2024 19:59:17 +0300
Dmitrii Kashin <
freehck@gmail.com> пишет:
Что бы сказал Фредерик Брукс на такое расточительство? =)
Фредерик Брукс нам еще ответит за украденный 32-бит из архитектуры s390;-)
(почему-то и спарк и power и arm 32-битные, а IBM-овские мейнфреймы -
31 битные)
А если серьёзно, Вы почему-то делаете предположение, что у нас нет
нормальных тест-сьютов. Но это ошибочно. Если мы будем полный
тест-сьют на каждую сборку запускать, то вы же, разработчики, первые
прибежите с претензиями "а что так долго сборку ждать, я никак таску
не могу закрыть, а с меня уже требуют". В общем, обычно в фичбранче
прогоняются только юнит-тесты, а полный тест-сьют запускает уже QA
перед мерджем.
Мы тут не про разработчиков, мы тут про мейнтейнеров пакетов.
Это разные роли, и их должны исполнять разные люди. Во всяком случае в
отношении одного и того же пакета.
Поэтому я, кстати, никогда не пытался стать мейнтейнером своих
программ, которые попали в Debian. Потому что им я разработчик, а не
мейнтейнер.
Как сказал Эрик Раймонд, "Given enough eyeballs all bugs are shallow".
Вот одна пара - это точно не enough. Поэтому вторая пара глаз -
мейнтейнера, который смотрит на код с другой точки зрения, чем
разработчик, необходима.
У разработчика на машине, и даже на общем для команды разработчиков VCS
хосте где запускаются тесты на коммиты во фича-ветки, совершенно не
обязательно иметь чистую среду. Там все -dev пакеты могут быть заранее
поставлены. Но у них там будет от силы пяток разных сред. Именно в силу
необходимости балансирования скорости прогона и широты покрытия.
А вот на этапе пакетирования, где контролируется правильность написания
spec или debian/control - там нужны воспроизводимые билды в
воспроизводимой среде.
И тестовые среды тоже должны быть воспроизводимыми. Раскатываться из
архива образов перед каждым запуском.
И здесь уже будет 30 дистрибутивов для 5 аппаратных архитектур.
Впрочем у нас еще есть между этими двумя стадиями промежуточная, где
максимальная широта охвата, то есть тестируются даже системы которые мы
не поддерживаем и поддерживать не собираемся. Просто потому что баги
которые вылезут на Solaris/Sparc сразу на x86_64 могут не замечаться
годами а просто сажать производительность.
И работает, кстати, я подтверждаю. Но со стороны эксплуатации к
Вашему, Виктор, продукту -- на самом деле есть вопросы.
Например, почему нет официального решения для построения HA-кластера?
Или почему есть официальная тулза для promote, а для demote -- нету?
В нашем продукте - PostgresPro Enterprise и то, и другое уже есть.
https://postgrespro.ru/docs/enterprise/16/biha
А в апстримовском опенсурсном постгресе есть только то, с
необходимость чего согласны все разработчики участвующие в сообществе.
А тут у нас, EnterpriseDB и 2nd Quadrant есть разные мнения. И
проталкивание какой-нибудь разработанной нами фичи иногда занимает годы.
Так было например с covering indexes, которые у нас были еще в 9.5, а в
апстрим были вмержены по-моему в 10. И не потому что мы их зажимали -
на коммитфесте они висели.
В конкретном случае HA-кластера у разных пользователей очень разные
требования и одним "официальным" решением всех не удовлетворишь.
Поэтому и расцветают все цветы.
--
Victor Wagner <
vitus@wagner.pp.ru>
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)