From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_20 autolearn=unavailable version=3.2.4 Message-ID: <4871CB05.1000608@rattler.kiev.ua> Date: Mon, 07 Jul 2008 10:51:33 +0300 From: Michael Bochkaryov User-Agent: Thunderbird 2.0.0.14 (X11/20080513) MIME-Version: 1.0 To: Pavlov Konstantin References: <487130B3.3070904@rattler.kiev.ua> <20080706210256.GH18715@cryo.net.ru> <20080706210719.GW31923@osdn.org.ua> <20080706211920.GI18715@cryo.net.ru> In-Reply-To: <20080706211920.GI18715@cryo.net.ru> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit Cc: sysadmins@lists.altlinux.org Subject: Re: [Sysadmins] =?windows-1251?b?UG9zdGdyZVNRTCDiINHo5+j05Q==?= X-BeenThere: sysadmins@lists.altlinux.org X-Mailman-Version: 2.1.10b3 Precedence: list Reply-To: ALT Linux sysadmin discuss List-Id: ALT Linux sysadmin discuss List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2008 07:45:48 -0000 Archived-At: List-Archive: Pavlov Konstantin пишет: >>>> 1. Политика по одновременной поддержке различных веток. >>> Думается, в Сизифе не нужно ничего, кроме последней ветки. >> Ммм... наверное, это решать тем, кто его применяет и готов >> обеспечивать поддержку более ранних веток в отпочковывающихся >> бранчах. В силу того, что слишком частая миграция между ними >> может быть дороже. > > Ну и мигрируй себе с бранча на бранч или с сервера 4.х на сервер 4.y; > Сизиф тут ни при чем, как и в поддержке обновлений для бранчей. В общем, все сводится к паттернам использования постгреса. > Мы и применяем, я не просто так написал. Кстати, а чуть подробнее можешь отписать, в каких позах у вас постгресы гоняются и какие требования к ним предъявляются ? Можешь в личку, если информация не для распространения. >>>> 2. Поддержка chroot и доступная при этом функциональность. >>> Как я уже озвучивал раньше, chroot несколько излишен для PGSQL, >>> когда используется виртуализация. В связи с этим вопрос, >>> кто-то еще использует PGSQL не внутри контейнера? >> Не-а. Ну, этого и логично было ожидать :) >>>> 3. Политика по добавлению сторонних функций и патчей. >>>> А то у нас уже 4 ветки разной степени >>>> разломанности/протухшести (или 5, если отдельно считать >>>> 8.2_1C) и стопка граблей по ним, которые то ли решать надо, >>>> то ли объявлять особенностями сборки и документировать. >>> Выкидывать их надо. С 1C другой вопрос -- но я так понял его >>> собирают несколько иначе, чем основной PG? >> PS: перевожу в sysadmins@, поскольку и сам пишу с точки зрения >> потребителя, а не комайнтянина. > > Я заинтересован быть комантяином (баги висят, впрочем). Может, тогда присоединишься к pgsql@packages? Все же на нормальное распиливание постгреса лучше командой бросаться, внятно расписав перед этим, куда двигаем и кто что может сделать. P.S. Только сразу предупреждаю, что на майнтейнеров постгреса в обязательном порядке сваливается стопка дедлайнов, с постгресом слабо связанных. Научного обоснования нет, но есть статистика :) -- Michael Bochkaryov