On Wed, Nov 26, 2003 at 03:45:05PM +0300, Anton Farygin wrote:
> Собственно а зачем Sisyphus ???  Есть же Master 2.2 - его +
> updates должно хватить.

Знаешь, я не верю, что те, у кого серверы на Sisyphus, сделали
это нечаянно.  Иногда это взвешенный и оцененный риск.

Давайте оставим как дело личное, к ответственности ООО "Альт
Линукс" и разработчиков Sisyphus не имеющее отношения и т.д.

А про ALM2.2+updates -- ну покажи мне его с корнем на soft raid1.

Я последний раз себе такое городил, но чесслово -- до того, чтобы
зарядить туда уже бывшую compact beta и прогнать несколько недель
зафиксированную конфигурацию -- не дошло чуточку, и то потому,
что уже собирался менять место работы.  ALM2.2+извраты+updates --
более штатная все же конфигурация.

> >Это всё потому, что даже Сизиф не является более-менее
> >надёжным дистрибутивом. Daedalus в этом смысле рассматривается
> >как "лучше я сразу сделаю rm -rf /, результат тот же, а работы
> >меньше".
> Sisyphus вообще не дистрибутив.

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

> >Я же предлагаю отслоить от Сизифа надёжную его часть, и
> >позволить людям, которым это необходимо, использовать именно
> >его.
> Зачем ?

(2 DS)
Ммм... это может произойти в качестве следствия (и быть
мотивацией), но вот так в лоб -- невыполнимо.  См. выше.

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

Вот.  А такой Sisyphus.incoming -- это проверка того, что, в
общем, уже известное лекарство не оскорбит тебя, скажем, видом
упаковки. :)

> Не.. не все так просто.... для начала рекомендую попробовать
> вычислить набор provides для бинарных пакетов, которые
> получаются из src.rpm

Ты свои скрипты тоже выложил бы, что ли.

> >За N часов её можно найти и повесить в BTS, и тогда пакет
> >перемещён не будет. Выбирать это самое N пока придётся опытным
> >путём, потом можно анализировать статистику.
> Как показывает практика - большинство ошибок будет выявляться
> уже _после_ перемещения пакета, ибо для того, что бы его
> проверить в нестабильном репозитарии нужно неопределенно
> большое количество пользователей этого пакета, ежедневно
> обновляющихся из _нестабильного_ репозитария. Unreal.

Фигли неопределенно большое.  Есть активные пользователи пакета,
которые читают маны, ченжлоги, исходники (те, кто пишут -- в
отдельной категории, им роль pre-Daedalus сполняет localhost) --
а есть пассивные пользователи пакета, которые получают его, может
статься, и не по dist-upgrade, а как зависимость.

(извиняюсь) Пример -- libgtk+2; оказалось так, что на "первом
фронте" он повел себя хорошо, и даже у некоторых активных
пользователей (avp@ ?) -- вроде тоже, а после попадания в
Sisyphus очень ьыстро вылезли массовые грабли при использовании
_других_ пакетов.

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

Опять же формализация процесса тестирования при таком подходе
имеет шансы улучшиться -- так ты вешаешь багу ..ну чтоб не забыли
починить, а так -- чтоб защитить Зе^Wпользователей до того, как
оно к ним доберется.

Улавливаешь? ;-)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/