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

[Michael Shigorin]

On Tue, Nov 25, 2003 at 03:29:11PM +0300, Stanislav Ievlev wrote:
> До настоящего момента у нас не был "сизифа-дистрибутива", а был
> только "сизиф для разработчико и желающих". Идеологи должны
> решить эту проблему до конца, прежде чем начнутся какие-то
> реальные шаги.

(соображения по поводу партнеров, синхронизации, коммуникации etc skipped)

> Как показывает практика что пакет может лежать в daedalus.
> Большиство знает что там unstable и не пользуется им. Когда
> пакет приходит из daedalus в Cизиф там обнаруживаются проблемы.

Вот.  При этом я не раз подумывал добавить Daedalus в
sources.list с тех пор как это стало вообще возможно (спасибо
sass!) -- и только сейчас понял, почему этого не сделал.

Daedalus -- это место, где может (имеет полное право) взорваться
_каждый_ кусочек.

Если я добавлю его ради, например, xmms -- и в итоге взорвется
synaptic -- а потом еще что-нибудь -- мое время, которое
предполагалось выделить на разработку, пойдет на бултыхание в
проблемах.

> Так в где гарантии что на пакет из incoming хоть кто-нибудь
> будет смотреть. 

А туда должно попадать то, что и так попадает в _Sisyphus_.
Просто разработчики, как правило (к этому надо привести ситуацию)
-- будут с этими версиями несколько раньше, чем растущая (?) доля
пользователей Sisyphus, которая заглядывает в рассылку
повнимательнее только _после_ проблем -- потому что _обычно_ после
dist-upgrade все работает.

> Для начала надо приучить _разработчиков_ пользоваться deadalus
> иначе просто будет добавлен новый совершенно неиспользуемый
> репозитарий.

См. выше.  Я пользуюсь Daedalus (и на запись, и на чтение).  Но
это полигон, а не "предбанник", где можно проверить, что не забыл
веник :)

> > > 3. кто всё это будет поддерживать.
> > Скрипты.
> Не всё можно охватить скриптами.

Да.

> Даже сейчас при наличии большого количества скриптов приходится
> иногда incoming переводить на ручное управление.

Понимаю.  Но с этой стороны ничто и не меняется.

> Нет никаких гарантий, что нетривиальные замены библиотек,
> преименование/образование подпакетов можно будет полностью
> охватить скриптами.

Да не о них речь на данный момент.  То, что можно (реально и
осмысленно, при этом уже будет приносить пользу, если верить нам
с Денисом) сделать -- касается не автоматизации разгребания
incoming (кстати -- с дебиановцами не совещались?  у них-то
автомат).  Касается QA пакета уже фактически по пути внутри
Sisyphus.

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

"24" предложено как интервал между синхронизациями.  Минимальная
фора, сутки.

> Если была бага на которую кто-то ещё не напарывался - то не
> факт что через N часов она самоликвидируется.

Ессно.

> >     важности (и "репутации"?) пакета,
> >     "репутации" майнтейнера (точнее, последнего собравшего?),
> Не знаю что такое "репутация".

Может, это не лучший термин -- слишком пересекается с жизнью...
но в идеале этот показатель должен коррелировать с
(важность*срок_жизни_багов), например.

Инициализировать можно как

security@ -> 0.75
fulltime  -> 0.50
volunteer -> 0.25

(сейчас меня кунут, но что делать)

> Почему же вот уже несколько месяцев tetex и python тащат за
> собой emacs.

Я могу привести еще много "почему", но здесь это иррелевантно.

-- 
 ---- WBR, Michael Shigorin <mike на altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20031127/544df72b/attachment-0001.bin>