On Thu, Nov 13, 2003 at 09:00:22PM +0300, Денис Смирнов wrote:
> Обоснование: обновление из сизифа часто является вынужденым,
> даже если человек и не хочет принимать активного участия в
> разработке, по таким причинам, как отсутствие багфиксов к
> Мастеру, за исключением security.

Ммм... в таком случае может быть более осмысленно поддерживать
локальный репозиторий бэкпортов.  У меня в некоей форме такое
водится, по крайней мере leafnode и apache на alm2.2-системы
попадают именно так.

Если критичность * общесть проблемы превышает некий субъективный
порог -- может быть оправданно рекомендовать (org@?) включение
таких пакетов в updates после проверки.

> Причины:
>  - ошибки в upstream

Есть updates, которые errata.  Для критичных ошибок они могут
выпускаться.

>    С этим борется каждый мантейнер как может, гарантированых
>    решений быть не может. Улучшить ситуацию можно:
>    1. автоматическими тестированиями;
>       как реализовать это на практике в общем виде я себе
>       представляю слабо, однако для таких продуктов как PHP
>       вполне можно реализовать набор тестов (хотя бы анализ
>       того, что возвращает phpinfo() ).

Анализ по каким критериям?

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

Так без него критичность не определяется в любом случае.

>       при этом иметь список людей (привязаный к каждому пакету)
>       заинтересованых в том, чтобы отслеживать развитие данного
>       конкретного пакета, речь идёт о людях _не обязательно_
>       являющихся членами Team.

Ну так это участники BTS.  Это уже имеем.

>  - ошибки в пакетах
>    1. тестирование вроде приведённого выше;
>    2. продуманое полиси, в котором будут перечислены вещи, на
>       которые важно обращать внимание.

Ммм... боюсь, обобщить тестирование -- проблема еще та, судя по
количеству живой силы на этой задаче у поставщиков коммерческого
ПО.

>       собственно мои мысли на тему "при обновлении не должна
>       меняться конфигурация",

Зависит.  Иногда известно, что с имеющейся конфигурацией новый
код попросту не взлетит.

Т.к. в sisyphus изменения между большими ветками _могут_ быть и
бывают, то приходим к необходимости их отслеживать.  Т.к. это
трудно, то выход для тех, кому приходится пользовать sisyphus
вместо master видится таким:

- реализация механизма нотификации при поступлении новых пакетов,
  который позволил бы разделять изменения по степени масштабности
  (критичности, опасности).
  
  Примерно так уже сделано в Debian; у нас хотелось бы вырулить
  на то, информацию о чем можно получить той же почтой и
  отфильтровать по порогу, причем в идеале -- иметь возможность
  подвесить туда же робота (доступного в дистрибутиве), который
  может, глядя на подпись и некоторые иные критерии (тот же порог
  важности) -- дернуть rsync и/или apt и/или /bin/mail.

>       "если при обновлении меняется конфигурация, это повод
>       срочно проинформировать админа, да ещё и так, чтобы он
>       эту информацию потерять лишь с большим трудом мог"

Ммм... *.rpmsave?

>       "при обновлении нельзя вносить изменения, которые могут
>       блокировать удалённый доступ администратора к серверу"
>       (это я всё pam вспоминаю)

Полностью согласен.

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

Проблема в том, что люди, которые отвечают за базовые средства
удаленного доступа и контроля/смены привилегий -- a priori
полагаются более чем сведущими в вопросе.

Соответственно что делать с этим вопрсом -- непонятно.

>  >> К тому же ситуация, при которой обновление может блокировать
>  >> работу почтовика, является одной из той, опасность которых
>  > Вот.  А тут добавляется еще одно требование его живости.
> Сейчас эта информация просто теряется.

Лог?

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