[sisyphus] Re: [POLICY] Sisyphus

[Денис Смирнов]

On Mon, Jan 26, 2004 at 06:13:35PM +0200, Michael Shigorin wrote:

 >> В юзабельный сизиф пакет попадает тогда, и только тогда, когда:
 >> а) собирается на последнем юзабельном сизифе;
 > Для этого нужен API к BTE какой-то.  Хотя бы в виде логов/флажков
 > сборки.

Да. 
 
 >> б) проходит набор встроеных тестов (если они были) на последнем
 >> юзабельном сизифе;
 > --""--
 >> в) прошло не менее N времени после помещения в сизиф;
 > по mtime?

Например. Или начиная с того момента, когда скрипт его "увидел" (и сказал
об этом собственной БД). Это даже надёжнее.
 
 >> г) нет ни одного незакрытого block-bug на этот пакет;
 > Для этого нужен API к bugzilla.  В принципе, можно и на HTTP
 > сэмулировать :)

:-)

Думаю специальное API (пусть и по HTTP) будет лучше.
 
 >> + некая логика, меняющая N в зависимости от условий (например
 >> если новая версия исправляет критическую ошибку в уже имеющемся
 >> в юзабельном репозитории пакете, то N стремится к нулю).
 > Да пусть хоть без нее для начала и без BTE API.  Возьметесь
 > смакетировать?

Хм. А что тогда вообще этому несчастному скриптику делать? Просто
переносить пакеты из дистрибутива в дистрибутив, если они не портят
зависимости, после ожидания в N дней?

То есть как только пакет проходит период в N дней, то он является
_предлагаемым_ для переноса, когда будет возможен перенос пакета без
изничтожения всех зависимостей -- переносить в юзабельный Сизиф.

Потом уже добавить проверку на его собираемость в юзабельном Сизифе.
Только вот от ломания собираемости Сизифа это не спасёт, для гарантии
нужно после попытки переноса каждого пакета пересобирать всё, что от него
зависит при сборке. Это вообще реально?
 
 >>>> Третий день - тестирование собранного, и слив собранных
 >>>> пакетов. Получаем minimum minimorum для кванта времени -
 >>>> трое суток. 
 >>> На самом деле и между ними могут быть задержки.  Но в общем
 >>> -- неделя :)
 >> Неделя очень хорошо для стабильности, но очень плохо для
 >> динамики. К тому же не факт что вновь добавленые через неделю
 >> пакеты не будут друг с другом конфликтовать.
 > Знаю.  Но если эта компонента получает incoming/BTE ASAP -- то
 > динамика для разработчиков не то что бы улучшится (из incoming
 > таскать каштаны можно тоже), но цивилизуется.  А для остальных
 > будет в достаточной мере меньше, чтобы предупредительные выстрелы
 > "сломали!" можно было услышать заранее.
 > Это просто ступенька управляемости, которая делается явно --
 > сейчас такой возможности просто нет, а жаль.

Если честно я не совсем понимаю что имеется в виду под недельной
заморозкой. Если речь идёт о создании буфера между играми разработчиков и
реально используемым дистрибутивом, то я, разумеется, за. Если речь идёт о
каких-либо помехах разработчикам, то я против.
 
 >>>> Прежде всего, необходимо ранжирование пакетов по категориям
 >>>> важности.
 >>> Кстати, по крайней мере какая-то информация по этой части для mdk
 >>> installer есть ("важно/неважно/прикольно").
 >> Я предлагал пытаться вычислять важность пакета на основе количества прямых
 >> и косвенных зависимостей на него.
 > Угу. ("сумму зависимостей")

ага.
 
 >>> 2 mithraen: руки до этих самых скриптов не дошли?
 >> Увы, нет, я этот месяц вообще был перегружен до уровня
 >> малосовместимого с жизнью. Только-только выплыл из перегруза,
 >> попробую помедитировать.  Меня смущает то, что этому скрипту
 >> нужно:
 >>  - уметь получать информацию из BTS
 >>  - знать _собирается_ ли пакет на юзабельном сизифе.
 > См. выше.
 > Если задаться incoming/BTE в качестве входа -- предполагается,
 > что собирается, если не старше $TIME2 ::= одна_неделя.  Как
 > нулевое приближение.

Э, вопрос собираемости на incoming-сизифе и сизифе после этого "шлюза" это
совсем разные вопросы. Собственно пока твой вариант лучше чем ничего, но
думать над проверкой сборки придётся.
 
-- 
С уважением, Денис

http://freesource.info