From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 25 Nov 2003 15:29:11 +0300 From: Stanislav Ievlev To: ALT Devel discussion list Subject: Re: [devel] Re: =?koi8-r?B?z8Igz8LT1dbE?= =?koi8-r?B?xc7JySDQz8TIz8TP1yDLIM/Dxc7LxSDOwcSj1s7P09TJ?= Sisyphus Message-ID: <20031125122911.GA9809@basalt.office.altlinux.org> References: <20031125001230.D78905@elefant.dgtu.donetsk.ua> <20031125072830.GE2421@basalt.office.altlinux.org> <20031125094848.GH10424@osdn.org.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20031125094848.GH10424@osdn.org.ua> X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.3 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2003 12:29:12 -0000 Archived-At: List-Archive: List-Post: On Tue, Nov 25, 2003 at 11:48:48AM +0200, Michael Shigorin wrote: > On Tue, Nov 25, 2003 at 10:28:30AM +0300, Stanislav Ievlev wrote: > > Если речь идёт о дополнительных репозитариях, то лично я пока > > так и ничего не понял: > > 1. зачем ещё один daedalus > > Не совсем. Скорее "pre-sisyphus" как практически неизбежная > стадия попадания пакета в что-то, входящее в classic. > > Т.е. не дополнительная танцплощадка, а звено технологической > цепочки. > > > и что такое "надёжность sisyphus" по-определению. > > Не знаю; не вводил. нет определения - значит нет правила перекочёвки пакетов из этого "pre-sisyphus" в sisyphus. > > > 2. какая будет схема "перетекания" пакетов из одного > > репозитария в другой, третий и т. п. > > [office]incoming->OUT->[ftp].incoming->.contrib > > (хм... может, чтоб избежать путаницы между каталогом incoming и > компонентой .incoming -- обозвать компоненту чем-то вроде limbo? > ;-) > > из .contrib -- в .master, .junior, ... -- как ты в свое время и > рисовал, когда описывал грядущие изменения в репозитории. Этот > процесс может и не изменяться по ср. с текущим на сейчас. > > --- > > Цель: предоставить разумную грань между > * "sisyphus для разработчиков", > куда можно положить пакет, в котором > тут же найдется ляп (не намеренно, но все мы знаем, что так > бывает), который отловят > те, кто будет использовать _и_ эту компоненту -- > разработчики > -- до того, как пакет будет перемещен (точнее, > пересимлинкован) в одну из имеющихся компонент, > которые собираются в > * .classic, который и применяется > _пользователями_ Sisyphus. > (в т.ч. и разработчиками Sisyphus на хостах, которые можно > себе позволить / требуется держать на Sisyphus, но которые > желательно иметь в работоспособном состоянии), > при условии минимальных изменений в текущей схеме. До настоящего момента у нас не был "сизифа-дистрибутива", а был только "сизиф для разработчико и желающих". Идеологи должны решить эту проблему до конца, прежде чем начнутся какие-то реальные шаги. Как показывает практика что пакет может лежать в daedalus. Большиство знает что там unstable и не пользуется им. Когда пакет приходит из daedalus в Cизиф там обнаруживаются проблемы. Так в где гарантии что на пакет из incoming хоть кто-нибудь будет смотреть. Для начала надо приучить _разработчиков_ пользоваться deadalus иначе просто будет добавлен новый совершенно неиспользуемый репозитарий. > > --- > > > 3. кто всё это будет поддерживать. > > Скрипты. Не всё можно охватить скриптами. Даже сейчас при наличии большого количества скриптов приходится иногда incoming переводить на ручное управление. Нет никаких гарантий, что нетривиальные замены библиотек, преименование/образование подпакетов можно будет полностью охватить скриптами. > > Из требуемых изменений: делать симлинки из .incoming при > изначальном помещении из OUT в сизиф > > Денис говорит, что готов написать скрипт-перетаскиватель из > .incoming в .contrib по достижении понимания того, что будет > критерием. > > Для "заглушки" критерием может быть > время модификации, от которого прошло N часов (24?); > это даст эффект "админ должен быть в меру тормознутым" -- у > разработчиков будет фора в эти N часов на dist-upgrade и > использование пакета. Как и кем определяются эти N часов. Если была бага на которую кто-то ещё не напарывался - то не факт что через N часов она самоликвидируется. > > Для того, что хочется в итоге получить -- критерием будет > совокупность > важности (и "репутации"?) пакета, > "репутации" майнтейнера (точнее, последнего собравшего?), > наличие/критичность открытых багов в BTS, > время, прошедшее с момента публикации пакета. Не знаю что такое "репутация". Почему же вот уже несколько месяцев tetex и python тащат за собой emacs. > > Изначально важность пакетов можно инициализировать из данных, > уже сделанных для инсталера плюс принадлежности к компонентам > вроде base; "репутацию" сборщиков я бы инициализировал как > "sec team"/"фултайм"/"волонтер" -> 0.75 / 0.5 / 0.25 из (0..1). > > Но лучше пока не трогать, оставив вторым шагом. > > > 4. ну и много, много других вопросов. > > Ну так сюда их. > > Может, через них Большие Грабли или Тривиальная Бессмысленность > обнаружатся. > > -- > ---- WBR, Michael Shigorin > ------ Linux.Kiev http://www.linux.kiev.ua/ > _______________________________________________ > Devel mailing list > Devel@altlinux.ru > http://altlinux.ru/mailman/listinfo/devel