[devel] Re: об обсуждении подходов к оценке надёжности Sisyphus

[Stanislav Ievlev]

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 <mike на altlinux.ru>
>   ------ Linux.Kiev http://www.linux.kiev.ua/



> _______________________________________________
> Devel mailing list
> Devel на altlinux.ru
> http://altlinux.ru/mailman/listinfo/devel