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

[Michael Shigorin <mike@osdn.org.ua>]

[-- Attachment #1: Type: text/plain, Size: 2966 bytes --]

On Tue, Nov 25, 2003 at 10:28:30AM +0300, Stanislav Ievlev wrote:
> Если речь идёт о дополнительных репозитариях, то лично я пока
> так и ничего не понял:
> 1. зачем ещё один daedalus

Не совсем.  Скорее "pre-sisyphus" как практически неизбежная
стадия попадания пакета в что-то, входящее в classic.

Т.е. не дополнительная танцплощадка, а звено технологической
цепочки.

> и что такое "надёжность sisyphus" по-определению.

Не знаю; не вводил.

> 2. какая будет схема "перетекания" пакетов из одного
> репозитария в другой, третий и т. п.

[office]incoming->OUT->[ftp].incoming->.contrib

(хм... может, чтоб избежать путаницы между каталогом incoming и
компонентой .incoming -- обозвать компоненту чем-то вроде limbo?
;-)

из .contrib -- в .master, .junior, ... -- как ты в свое время и
рисовал, когда описывал грядущие изменения в репозитории.  Этот
процесс может и не изменяться по ср. с текущим на сейчас.

---

Цель: предоставить разумную грань между
* "sisyphus для разработчиков",
    куда можно положить пакет, в котором
      тут же найдется ляп (не намеренно, но все мы знаем, что так
      бывает), который отловят
        те, кто будет использовать _и_ эту компоненту --
          разработчики
      -- до того, как пакет будет перемещен (точнее,
      пересимлинкован) в одну из имеющихся компонент,
        которые собираются в
* .classic, который и применяется
    _пользователями_ Sisyphus.
      (в т.ч. и разработчиками Sisyphus на хостах, которые можно
      себе позволить / требуется держать на Sisyphus, но которые
      желательно иметь в работоспособном состоянии),
при условии минимальных изменений в текущей схеме.

---

> 3. кто всё это будет поддерживать.

Скрипты.

Из требуемых изменений: делать симлинки из .incoming при
изначальном помещении из OUT в сизиф

Денис говорит, что готов написать скрипт-перетаскиватель из
.incoming в .contrib по достижении понимания того, что будет
критерием.

Для "заглушки" критерием может быть
  время модификации, от которого прошло N часов (24?);
    это даст эффект "админ должен быть в меру тормознутым" -- у
    разработчиков будет фора в эти N часов на dist-upgrade и
    использование пакета.

Для того, что хочется в итоге получить -- критерием будет
  совокупность
    важности (и "репутации"?) пакета,
    "репутации" майнтейнера (точнее, последнего собравшего?),
    наличие/критичность открытых багов в BTS,
    время, прошедшее с момента публикации пакета.

Изначально важность пакетов можно инициализировать из данных,
уже сделанных для инсталера плюс принадлежности к компонентам
вроде 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/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]