В Fri, 16 Feb 2024 19:59:17 +0300 Dmitrii Kashin <free...@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 <vi...@wagner.pp.ru>
