From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,FUZZY_XPILL autolearn=no version=3.2.5 Date: Sat, 30 May 2009 17:04:52 +0300 From: Michael Shigorin To: ALT Linux Team development discussions Message-ID: <20090530140451.GJ12156@osdn.org.ua> Mail-Followup-To: ALT Linux Team development discussions References: <20090424174358.GN9391@altlinux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20090424174358.GN9391@altlinux.org> User-Agent: Mutt/1.4.2.1i Subject: [devel] =?koi8-r?b?c2lzeXBodXMtdW5tZXRzOiAi083Rx97J1NgiINLBws/U?= =?koi8-r?b?1SDOwcQgc2hhcmVkIHRhc2tzICh3YXM6IGNvbGxhYm9yYXRpb24g?= =?koi8-r?b?cGF0dGVybnMp?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2009 14:05:06 -0000 Archived-At: List-Archive: List-Post: On Fri, Apr 24, 2009 at 09:43:58PM +0400, Alexey Tourbin wrote: > > > Yes, you have to add that another package to your fpc task. > > > If you have ACL permissions to build that another package, > > > this is remarkably simple. :) And if you don't, this is > > > still possible. > > Да, наверно сейчас, когда такой пакет всего один, это будет > > просто. А если завтра их будет больше одного? А каждый > > мантейнер личность и к каждому найти подход... > Okay, let's discuss again what I call "collaboration patterns". [...] > Are there any better possibilities? I believe we need to make > rebuilding packages for new dependencies easily possible. And > otherwise we face major problems. Yup. Вот что ещё подумалось: а можно ли обломавшиеся по причине создания новых анметов задания сваливать в некую общую кучу sisyphus-unmets или там sisyphus-next, в рамках которой не требовалось бы отдельных действий по координации для исправления? Это бы могло снизить потери времени на это самое взаимодействие (что бывает особенно важно тогда, когда у разных людей сильно разъезжаются окна времени для работы над сизифом) и вместе с тем быть семантически ближе к тому, как публиковал сизиф ldv@, что бывало менее категоричным, нежели текущая схема. Возможность реализации IMHO зависит от того, насколько получается предположить возможность исправления целостности получаемого репозитория новоприбывшими пакетами -- примерно так: - залил новые A и B; - A собрался/проверился нормально и пошёл в Sisyphus; - B сломал по установочным зависимостям пакеты C и D и потому был отправлен в sisyphus-unmets; - майнтейнер C забросил новую сборку в git.alt или incoming; - её пересборка в окружении sisyphus-unmets показала уменьшение количества анметов при транзакции => пакет определён в sisyphus-unmets; - майнтейнер D тоже забросил сборку, но она не уменьшила количества анметов в рамках sisyphus-unmets, при этом пересборка на sisyphus показала неувеличение анметов => пакет определён в sisyphus; - когда все порождённые B анметы "погашены" определёнными в sisyphus-unmets пакетами, B и пакеты, скомпенсировавшие именно им созданные анметами, отправляются на пересборку в Sisyphus (и при прохождении перекладываются туда). Налицо существенные сомнения в "сходимости ряда" анметов таким образом в разумное время, чтобы полученную "кучу" можно было целиком перемещать в Sisyphus: скорее всего, куча будет распухать со временем и блокировать возможность перекладывания в сизиф статистически постоянным наличием/созданием анметов. _Возможно_, от этого бы помогло установление некоего таймаута (скажем, в неделю) и напускание stmpclean. А ещё судьба пакета C может быть неожиданной для майнтейнера, который и не собирался как-то особенно исправлять судьбу пакета B (даже быть не в курсе), а просто намеревался увидеть новую сборку пакета C в сизифе. --- Предложение не претендует на реализуемость, но если вдруг получится сделать так, чтобы простые вещи (вроде исправления строго прибитых по V/VR зависимых пакетов пересборкой) делались если не сами, то хотя бы просто и без отдельной синхронизации людей -- то это бы здорово сэкономило времени и нервов на полезную, а не формальную деятельность. Получилось же сделать task add srpm, за что отдельное спасибо. -- ---- WBR, Michael Shigorin ------ Linux.Kiev http://www.linux.kiev.ua/