[devel] Re: [sisyphus] Надёжность Sisyphus

[devel] Re: [sisyphus] Надёжность Sisyphus

[Alex Murygin]

On Thu, 13 Nov 2003 21:00:22 +0300
"Денис Смирнов" wrote:

> On Thu, Nov 13, 2003 at 04:58:57PM +0200, Michael Shigorin wrote:
> 
>  >>>> невозможно, то установки по-умолчанию должны быть
>  >>>> максимально близки к тому, что было до обновления, а
>  >>>> информацию об изменениях кроме как на stderr админ должен
>  >>>> получить на root@.
>  >>> Это подразумевает рабочий почтовик.  Т.е. уже серьезно.
>  >> Есть другие предложения? Я ничего кроме stderr с дублированием
>  >> на почтовик не вижу.
>  > Я только за (при условии почты _только_ с проблемами... но это
>  > личное, а по-хорошему -- должно регулерироваться).
>  > Сделаете?
> 
> Хм. Кажется я нечётно сформулировал свою мысль. Попробую сначала.
> 
> Проблема: периодически попытки обновиться из сизифа приводят к
> неработоспособности системы.
> 
> Задача: техническими и/или административными методами уменьшить
> вероятность получения системным администратором по голове от руководства
> и клиентов при попытке пбновиться.
> 
...
>       как реализовать: разделить сизиф на два уровня, новые пакеты всегда
>       добавляются в один из уровней, если за неделю никаких изменений в
>       нём не было (или на него не висит в BTS block-bug'ов), то
>       автоматически переносить его в основной репозитарий. Вся эта работа
>       должна выполняться автоматически, без участия человека (что снизит
>       нагрузку на incominger'ов заодно).

<5 копеек>
Хочу Хочу Хочу :)
</5 копеек>

<ищо 5 копеек>
И рассылку о новых/измененых пакетах хочу :) типа а ля news://fm.announce
</ищо 5 копеек>

P.S. но не могу :)
P.S.2. но ведь вторые 5 копеек наверное и не такая фантастика? :)

-- 
-----------------------
- Alex Murygin, AITOC -
-----------------------

Re: [devel] Re: [sisyphus] Надёжность Sisyphus

[Marat Khairullin]

> > Задача: техническими и/или административными методами уменьшить
> > вероятность получения системным администратором по голове от руководства
> > и клиентов при попытке пбновиться.

Я давно пришел к выводу, что в серьезных проектах надо иметь тестовый сервер.

> >       как реализовать: разделить сизиф на два уровня, новые пакеты всегда
> >       добавляются в один из уровней, если за неделю никаких изменений в
> >       нём не было (или на него не висит в BTS block-bug'ов), то
> >       автоматически переносить его в основной репозитарий. Вся эта работа
> >       должна выполняться автоматически, без участия человека (что снизит
> >       нагрузку на incominger'ов заодно).

И все будут ждать - когда же кто-нибудь по юзает/проверит новый пакет.
А он так и не юзаный никем кроме мантенера через неделю переползет в Сизиф...

Re: [devel] Re: [sisyphus] Надёжность Sisyphus

[Denis Klykvin]

On Thu, 13 Nov 2003 23:30:31 +0300
Marat Khairullin <xmm@altlinux.ru> wrote:

> > >       как реализовать: разделить сизиф на два уровня, новые пакеты
> > >       всегда добавляются в один из уровней, если за неделю никаких
> > >       изменений в нём не было (или на него не висит в BTS
> > >       block-bug'ов), то автоматически переносить его в основной
> > >       репозитарий. Вся эта работа должна выполняться
> > >       автоматически, без участия человека (что снизит нагрузку на
> > >       incominger'ов заодно).
> 
> И все будут ждать - когда же кто-нибудь по юзает/проверит новый пакет.
> А он так и не юзаный никем кроме мантенера через неделю переползет в
> Сизиф...
Сделать по 3-5 ответственных бета-тестера на каждый пакет и ждать от
них письмо с подтверждением, что они протестили этот пакет.


-- 
Software is like SEX: it's better, when it's FREE.
Registered Linux User #315350

Re: [devel] Надёжность Sisyphus

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

On Thu, Nov 13, 2003 at 11:42:48PM +0300, Denis Klykvin wrote:

 >> И все будут ждать - когда же кто-нибудь по юзает/проверит новый пакет.
 >> А он так и не юзаный никем кроме мантенера через неделю переползет в
 >> Сизиф...
 > Сделать по 3-5 ответственных бета-тестера на каждый пакет и ждать от
 > них письмо с подтверждением, что они протестили этот пакет.

Всё даже проще -- gpg подписи пакета. У разных пакетов может быть разный
уровень "важности" и срок который пакет должен вылежаться. Перемещение
пакета производится либо при _одновременно_ прошествии нужного количества
дней и код подписан N1 подписями, либо если код подписан N2 подписями.

При этом хорошо обращать отдельное внимание на подписи мантейнеров
пакетов, у которых в зависимость на установку или сборку указан этот
пакет.

-- 
С уважением, Денис

http://freesource.info

[devel] Re: Надёжность Sisyphus

[Michael Shigorin]

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

On Fri, Nov 14, 2003 at 01:44:56AM +0300, Денис Смирнов wrote:
>  >> И все будут ждать - когда же кто-нибудь по юзает/проверит
>  >> новый пакет.  А он так и не юзаный никем кроме мантенера
>  >> через неделю переползет в Сизиф...

Вот.  Т.е. проблема скорее в связности, в непоступлении
востребованной информации (новый пакет [в группе] / новая версия
или сборка) тем, кто может и хочет проверять.

Что, похоже, может быть уперто в тот же робот-нотификатор и
решено "своими силами". :-)

>  > Сделать по 3-5 ответственных бета-тестера на каждый пакет и
>  > ждать от них письмо с подтверждением, что они протестили
>  > этот пакет.

Это как это "сделать"?  CREATE TESTER? ;]

> Всё даже проще -- gpg подписи пакета. У разных пакетов может
> быть разный уровень "важности" и срок который пакет должен
> вылежаться. Перемещение пакета производится либо при
> _одновременно_ прошествии нужного количества дней и код
> подписан N1 подписями, либо если код подписан N2 подписями.

Не прокатит.  Это ж какая волокита -- (пере)подписывать: при этом
релиз менять надо (файл изменился).  А потом по кругу рекурсивно?
Так это только два процесса популярны и останутся -- rsync и gpg.

:-(

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

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

Re: [devel] Re: Надёжность Sisyphus

[Denis Klykvin]

On Fri, 14 Nov 2003 14:47:50 +0200
Michael Shigorin <mike@osdn.org.ua> wrote:

> >  > Сделать по 3-5 ответственных бета-тестера на каждый пакет и
> >  > ждать от них письмо с подтверждением, что они протестили
> >  > этот пакет.
> 
> Это как это "сделать"?  CREATE TESTER? ;]
Нет ) Можно ./configure --with-testers , можно еще как-нить... А
можно просто спросить кому какой пакет жизненно необходим в рабочем
состоянии. Т.е. каждый maintainer отвечает за свой пакет, чтобы он был в
рабочем состоянии, а можно сделать еще и группу testers, которым будут
приходить уведомления о новом релизе пакета, и которые должны ответить в
течении какого-то срока, что они протестили этот пакет и нашли\не нашли
в нем баги.

P.S. Сори за несвязанный ход мыслей - /me только что проснулся.

-- 
Software is like SEX: it's better, when it's FREE.
Registered Linux User #315350

Re: [devel] Надёжность Sisyphus

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

On Fri, Nov 14, 2003 at 02:47:50PM +0200, Michael Shigorin wrote:

 >>>> И все будут ждать - когда же кто-нибудь по юзает/проверит
 >>>> новый пакет.  А он так и не юзаный никем кроме мантенера
 >>>> через неделю переползет в Сизиф...
 > Вот.  Т.е. проблема скорее в связности, в непоступлении
 > востребованной информации (новый пакет [в группе] / новая версия
 > или сборка) тем, кто может и хочет проверять.

Да, в этом основная проблема. Но и поступление неоттестированого пакета
тем, кто его тестировать не хочет -- тоже проблема.
 
 > Что, похоже, может быть уперто в тот же робот-нотификатор и
 > решено "своими силами". :-)

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

Тогда легко будет сделать фильтры.

 > > Всё даже проще -- gpg подписи пакета. У разных пакетов может
 > > быть разный уровень "важности" и срок который пакет должен
 > > вылежаться. Перемещение пакета производится либо при
 > > _одновременно_ прошествии нужного количества дней и код
 > > подписан N1 подписями, либо если код подписан N2 подписями.
 > Не прокатит.  Это ж какая волокита -- (пере)подписывать: при этом
 > релиз менять надо (файл изменился).  А потом по кругу рекурсивно?
 > Так это только два процесса популярны и останутся -- rsync и gpg.
 > :-(

Зачем менять файл? Можно присылать detached подпись после тестирования
пакета. Подписывает пакет пусть как сейчас -- только мантейнер, ничего
усложнять не стоит.

-- 
С уважением, Денис

http://freesource.info

[devel] Re: Надёжность Sisyphus

[Michael Shigorin]

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

On Fri, Nov 14, 2003 at 06:21:46PM +0300, Денис Смирнов wrote:
> Теоретически -- да. Практически была бы полезна рассылка, в

А я о чем?

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

Ммм... возможно.

>  - мантейнер пакета

Ессно.

>  - changelog

lastchange, я бы сказал.

> Тогда легко будет сделать фильтры.

Именно.

> Зачем менять файл? Можно присылать detached подпись после
> тестирования пакета.

Разве что так.  Но смысл в этом видится только при опять же
увеличении команды настолько, что простых анонсов / переписки не
хватает и требуется некий формализованный (и автоматизированный)
процесс вывода пакета в репозиторий.

Опять же не уверен, стоит ли геморрой свеч для не-фултаймеров, от
которых по определению нельзя требовать ВОТ ТАКОЙ
ответственности.  И интерес которых в качестве пакета от подписи
зависит весьма слабо.

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

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

Re: [devel] Надёжность Sisyphus

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

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

On Mon, Nov 17, 2003 at 10:35:02AM +0200, Michael Shigorin wrote:

 >> Теоретически -- да. Практически была бы полезна рассылка, в
 > А я о чем?

Я тебя не совсем хорошо понял.
 
 >>  - changelog
 > lastchange, я бы сказал.

Да.
 
 >> Зачем менять файл? Можно присылать detached подпись после
 >> тестирования пакета.
 > Разве что так.  Но смысл в этом видится только при опять же
 > увеличении команды настолько, что простых анонсов / переписки не
 > хватает и требуется некий формализованный (и автоматизированный)
 > процесс вывода пакета в репозиторий.

Как ты себе сейчас представляешь процесс переноса из "совсем
нестабильного" репозитария в "чуть-чуть стабильный"?
 
 > Опять же не уверен, стоит ли геморрой свеч для не-фултаймеров, от
 > которых по определению нельзя требовать ВОТ ТАКОЙ
 > ответственности.  И интерес которых в качестве пакета от подписи
 > зависит весьма слабо.

Как раз при работе над проектом не только фултаймеров и есть смысл
использовать такой метод. Барьер в N дней и K подписей (числа зависят от
важности пакета) позволит даже если мантейнер не может уделить достаточное
время для тестирования защитить пользователей от проблем.

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

-- 
С уважением, Денис

http://freesource.info


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

[devel] Re: Надёжность Sisyphus

[Michael Shigorin]

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

On Tue, Nov 18, 2003 at 12:29:59AM +0300, Денис Смирнов wrote:
>  >> Зачем менять файл? Можно присылать detached подпись после
>  >> тестирования пакета.
>  > Разве что так.  Но смысл в этом видится только при опять же
>  > увеличении команды настолько, что простых анонсов / переписки не
>  > хватает и требуется некий формализованный (и автоматизированный)
>  > процесс вывода пакета в репозиторий.
> Как ты себе сейчас представляешь процесс переноса из "совсем
> нестабильного" репозитария в "чуть-чуть стабильный"?

Формализованно _и_ удобно -- пока никак.

>  > Опять же не уверен, стоит ли геморрой свеч для не-фултаймеров, от
>  > которых по определению нельзя требовать ВОТ ТАКОЙ
>  > ответственности.  И интерес которых в качестве пакета от подписи
>  > зависит весьма слабо.
> Как раз при работе над проектом не только фултаймеров и есть
> смысл использовать такой метод. Барьер в N дней и K подписей
> (числа зависят от важности пакета) позволит даже если мантейнер
> не может уделить достаточное время для тестирования защитить
> пользователей от проблем.

Не уверен.  Это срабатывает после того, как мотивация заниматься
своими пакетами переваливает за некий предел, причем увеличение
формального барьера на нем сильно отражается.  [...]

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

Нет.  В таких местах такой базар не работает ни разу.

Работает -- команда с ответственным во главе.  Чье решение
действительно является определяющим.

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

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

Re: [devel] Надёжность Sisyphus

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

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

On Thu, Nov 20, 2003 at 04:51:03PM +0200, Michael Shigorin wrote:

 > > Как раз при работе над проектом не только фултаймеров и есть
 > > смысл использовать такой метод. Барьер в N дней и K подписей
 > > (числа зависят от важности пакета) позволит даже если мантейнер
 > > не может уделить достаточное время для тестирования защитить
 > > пользователей от проблем.
 > Не уверен.  Это срабатывает после того, как мотивация заниматься
 > своими пакетами переваливает за некий предел, причем увеличение
 > формального барьера на нем сильно отражается.  [...]

Зачем барьер? Есть Сизиф, который изначально динамичен (политкорректное
название нестабильности). Возможно есть смысл создать ещё один
репозиторий, в которые и переносить автоматом пакеты. Соответственно
дистрибутвы формировать уже не на основе Сизифа, а на основе этого
оттестированого репозитария, в который в принципе не может попасть
непровереный пакет.
 
 >> Кроме того если пакет является более-менее критичным для
 >> системы, то у мантейнеров пакетов, которые зависят от этого
 >> пакета, должно быть время проверить совместимость этих пакетов
 >> друг с другом.
 > Нет.  В таких местах такой базар не работает ни разу.
 > Работает -- команда с ответственным во главе.  Чье решение
 > действительно является определяющим.

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

Как ты себе представляешь структуру такой команды? Один ответственный
перепроверяет _все_ пакеты идущие в incoming.

-- 
С уважением, Денис

http://dimline.ru/


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

[devel] надёжность разработчиков Sisyphus

[Denis Ovsienko]

> Зачем барьер? Есть Сизиф, который изначально динамичен (политкорректное
> название нестабильности). Возможно есть смысл создать ещё один
> репозиторий, в которые и переносить автоматом пакеты. Соответственно
А потом ещё один, и туда --- ещё более надёжные... :) Уже есть Daedalus,
только мы им по назначению почему-то не пользуемся.

> дистрибутвы формировать уже не на основе Сизифа, а на основе этого
> оттестированого репозитария, в который в принципе не может попасть
> непровереный пакет.
В любой дистрибутив в принципе может попасть непроверенный пакет
независимо ни от чего.
Самоконтроль м самодисциплину никакой командой проверяющих не заменишь, на
собственном опыте убеждался не раз.
А всякие рассылки типа sisyphus-daily & cvsdiff-daily не нужны. Нужны
комментарии своих действий devel@ при заливке очередной сборки.

--
    DO4-UANIC

[devel] Re: Надёжность Sisyphus

[Michael Shigorin]

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

On Thu, Nov 20, 2003 at 08:33:26PM +0300, Денис Смирнов wrote:
>  > > Как раз при работе над проектом не только фултаймеров и есть
>  > > смысл использовать такой метод. Барьер в N дней и K подписей
                                       ^^^^^^
>  > причем увеличение формального барьера на нем сильно
> Зачем барьер?

Гм.

> Есть Сизиф, который изначально динамичен (политкорректное
> название нестабильности). Возможно есть смысл создать ещё один
> репозиторий, в которые и переносить автоматом пакеты.

testing? ;-)

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

Насколько я понимаю, в него превращают Сизифа перед выпусками.
Этакий себе Big Sisyphus Lock, который становится все
неприемлемей при увеличении кол-ва майнтейнеров, выпускателей
дистрибутивов и этих самых дистрибутивов в единицу времени.

Форканье всего -- осмысленно разве что перед "большим релизом"...
и вообще слишком сильно завязано на внутренние процессы
подготовки релиза в конкретно взятой фирме.

(почему об этом говорю? -- да потому, что это единственная
реальная на сейчас мотивация дополнительного репо)

>  >> Кроме того если пакет является более-менее критичным для
>  >> системы, то у мантейнеров пакетов, которые зависят от этого
>  >> пакета, должно быть время проверить совместимость этих
>  >> пакетов друг с другом.
>  > Нет.  В таких местах такой базар не работает ни разу.
>  > Работает -- команда с ответственным во главе.  Чье решение
>  > действительно является определяющим.
> Ты действительно не согласен с тем, что у мантейнеров пакетов,
> которые зависят от обновляемых должно быть время проверки на
> совместимость, перед тем как этот пакет отправится в
> репозиторий, используемый на реальных рабочих машинах (пусть и
> не серверах)?

Это было бы слишком хорошо.  Я не вижу, как это *реально*
сделать :(

> Как ты себе представляешь структуру такой команды? Один
> ответственный перепроверяет _все_ пакеты идущие в incoming.

Или не проверяет...

On Fri, Nov 21, 2003 at 07:42:59AM +0200, Denis Ovsienko wrote:
> > Зачем барьер? Есть Сизиф, который изначально динамичен
> > (политкорректное название нестабильности). Возможно есть
> > смысл создать ещё один репозиторий, в которые и переносить
> > автоматом пакеты. Соответственно
> А потом ещё один, и туда --- ещё более надёжные... :) Уже есть
> Daedalus, только мы им по назначению почему-то не пользуемся.

На самом деле да.

Поддерживаемые пакеты обладают некоторым "кредитом доверия" на
предмет проверки.  Те, на которых не хочется его подрывать --
идут в Daedalus.

Например, в xmms-1.2.8 вылез какой-то странный ляп, 

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

Именно.

> А всякие рассылки типа sisyphus-daily & cvsdiff-daily не нужны.

Видишь ли... --changes-since предыдущий_в_сизифе плюс spec.diff в
аттаче -- то, чего хочется довольно давно.  Собирался себе
сделать было.

> Нужны комментарии своих действий devel@ при заливке очередной
> сборки.

Только нетривиальных, потому как иначе -- дублирование ченжлога и
ухудшение SNR.  Рассылки появляются по мере роста специфичных тем
узкого профиля и выделенной направленности, понимаешь ли :)

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

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

Re: [devel] Надёжность Sisyphus

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

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

On Fri, Nov 21, 2003 at 06:00:09PM +0200, Michael Shigorin wrote:

 >>>> Как раз при работе над проектом не только фултаймеров и есть
 >>>> смысл использовать такой метод. Барьер в N дней и K подписей
 >                                        ^^^^^^
 >>> причем увеличение формального барьера на нем сильно
 >> Зачем барьер?
 > Гм.

Упс. Мы имеем в виду разные барьеры -- одно дело барьер, ограничивающий
попадение пакета вообще в сизиф (а чем sisyphus_check не такой барьер?),
другое дело барьер, предназначеный для того, чтобы на машины конечных
пользователей данного пакета попадал только оттестированый пакет.
 
 >> Есть Сизиф, который изначально динамичен (политкорректное
 >> название нестабильности). Возможно есть смысл создать ещё один
 >> репозиторий, в которые и переносить автоматом пакеты.
 > testing? ;-)

Да. За исключением идеи с тем, что у разных пакетов могут быть разные
периоды тестирования, и тем, что этот период будет зависеть от того,
сколько человек (и какого ранга) подписали пакет. Скажем подпись человека
из security team должна означать то, что пакет лучше всего перенести
немедленно.
 
 >> Соответственно дистрибутвы формировать уже не на основе Сизифа,
 >> а на основе этого оттестированого репозитария, в который в
 >> принципе не может попасть непровереный пакет.
 > Насколько я понимаю, в него превращают Сизифа перед выпусками.
 > Этакий себе Big Sisyphus Lock, который становится все
 > неприемлемей при увеличении кол-ва майнтейнеров, выпускателей
 > дистрибутивов и этих самых дистрибутивов в единицу времени.

 > Форканье всего -- осмысленно разве что перед "большим релизом"...
 > и вообще слишком сильно завязано на внутренние процессы
 > подготовки релиза в конкретно взятой фирме.

Почему, если для предлагаемой мною модели форка практически не требуется
человеческих ресурсов?

 > (почему об этом говорю? -- да потому, что это единственная
 > реальная на сейчас мотивация дополнительного репо)

С моей точки зрения есть смысл в существовании постоянно развивающегося
дистрибутива средней надёжности (средней, в смысле на ядерный реактор
ставить не стоит). Линукс слишком быстро развивается, чтобы выход нового
дистрибутива раз в год мог устроить. Поэтому постоянно изменяющийся
репозиторий, генерирующийся _автоматически_ на базе Сизифа, IMHO, вполне
имеет право на жизнь и свою, отнюдь не маленькую, аудиторию.
 
 > >  >> Кроме того если пакет является более-менее критичным для
 > >  >> системы, то у мантейнеров пакетов, которые зависят от этого
 > >  >> пакета, должно быть время проверить совместимость этих
 > >  >> пакетов друг с другом.
 > >  > Нет.  В таких местах такой базар не работает ни разу.
 > >  > Работает -- команда с ответственным во главе.  Чье решение
 > >  > действительно является определяющим.
 > > Ты действительно не согласен с тем, что у мантейнеров пакетов,
 > > которые зависят от обновляемых должно быть время проверки на
 > > совместимость, перед тем как этот пакет отправится в
 > > репозиторий, используемый на реальных рабочих машинах (пусть и
 > > не серверах)?
 > Это было бы слишком хорошо.  Я не вижу, как это *реально*
 > сделать :(

Реально сделать так, чтобы у них _было время_. Воспользуются они этим или
нет -- другой вопрос.
 
 >> Как ты себе представляешь структуру такой команды? Один
 >> ответственный перепроверяет _все_ пакеты идущие в incoming.
 > Или не проверяет...

Так может лучше модель, когда любой человек может проверить пакет, и если
некоторое количество людей утверждают что пакет стабильный, то считать его
стабильным? Модель очень напоминающая модель проверки достоверности
PGP-ключа.

-- 
С уважением, Денис

http://dimline.ru/

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

[devel] Re: Надёжность Sisyphus

[Michael Shigorin]

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

On Sat, Nov 22, 2003 at 12:55:54AM +0300, Денис Смирнов wrote:
>  >>>> Как раз при работе над проектом не только фултаймеров и есть
>  >>>> смысл использовать такой метод. Барьер в N дней и K подписей
>  >                                        ^^^^^^
>  >>> причем увеличение формального барьера на нем сильно
>  >> Зачем барьер?
>  > Гм.
> Упс. Мы имеем в виду разные барьеры

Да нет.

> -- одно дело барьер, ограничивающий попадение пакета вообще в
> сизиф (а чем sisyphus_check не такой барьер?), другое дело
> барьер, предназначеный для того, чтобы на машины конечных
> пользователей данного пакета попадал только оттестированый
> пакет.

Понимаю.  Но сказанное относилось к ним обоим.

>  >> Есть Сизиф, который изначально динамичен (политкорректное
>  >> название нестабильности). Возможно есть смысл создать ещё один
>  >> репозиторий, в которые и переносить автоматом пакеты.
>  > testing? ;-)
> Да. За исключением идеи с тем, что у разных пакетов могут быть
> разные периоды тестирования, и тем, что этот период будет
> зависеть от того, сколько человек (и какого ранга) подписали
> пакет. Скажем подпись человека из security team должна означать
> то, что пакет лучше всего перенести немедленно.

Вот и появилось слово "ранг".  Чем же он определяется?

(собственно, нечто вроде freshmeat/slashdot-like системы давно
напрашивается применительно к _пакетам_)

>  > Форканье всего -- осмысленно разве что перед "большим релизом"...
>  > и вообще слишком сильно завязано на внутренние процессы
>  > подготовки релиза в конкретно взятой фирме.
> Почему, если для предлагаемой мною модели форка практически не
> требуется человеческих ресурсов?

Sure? (я могу чего-то не понимать, но и setup time (написание
кода для переноса, инициализация этих самых рангов, ...), и
runtime (подписи, проверка, перекладывание?) -- в т.ч. и
человекоемкие вещи.

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

Почему?  Вон корпоративным пользователям (заметь: деньги они
платят, а не пользователи unstable) более удобен цикл порядка
трех лет.  С поддержкой продукта в течении.

> Поэтому постоянно изменяющийся репозиторий, генерирующийся
> _автоматически_ на базе Сизифа, IMHO, вполне имеет право на
> жизнь и свою, отнюдь не маленькую, аудиторию.

Да кристально понятно.  Я бы на таком и серверы некоторые держал
:-)

Только это фактически постоянно выпускаемый дистрибутив (навроде
Compact, только объемами побольше) -- соответственно ему нужен
QA.

Понятно, что некоторые вещи вроде "чистой BTS" могут быть
формальными критериями для скрипта -- только ситуации вроде
критических багов, правящихся наживую и попросту не попадающих в
BTS -- не отработаются.  Лекарство от этого -- обязать проводить
их _через_ багтрекер, но тут мне не нравится слово "обязать".
Потому что смотря кого.

>  > > Ты действительно не согласен с тем, что у мантейнеров пакетов,
>  > > которые зависят от обновляемых должно быть время проверки на
>  > > совместимость, перед тем как этот пакет отправится в
>  > > репозиторий, используемый на реальных рабочих машинах (пусть и
>  > > не серверах)?
>  > Это было бы слишком хорошо.  Я не вижу, как это *реально*
>  > сделать :(
> Реально сделать так, чтобы у них _было время_.

В такой формулировке это фултайм, period.

Личное время -- как домашний каталог: можешь попробовать
ненавязчиво помочь человеку, сделав что-то за него (~/tmp и
TMPDIR), а можешь и возмутить его (~/Desktop и ~/Documents,
которые вечно сносятся и порой пытаются появиться).

> Воспользуются они этим или нет -- другой вопрос.

За то, что автоматизация -- друг ленивого человека -- не спорю
:-)

>  >> Как ты себе представляешь структуру такой команды? Один
>  >> ответственный перепроверяет _все_ пакеты идущие в incoming.
>  > Или не проверяет...
> Так может лучше модель, когда любой человек может проверить
> пакет, и если некоторое количество людей утверждают что пакет
> стабильный, то считать его стабильным? Модель очень
> напоминающая модель проверки достоверности PGP-ключа.

Здесь ключ -- "может проверить".

1) это QA => ответственность
2) это тоже риск
3) где грань, когда человек _может_ сказать, что "пакет
   стабилен"? (применительно как к пакету, так и к человеку)

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

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

Re: [devel] Надёжность Sisyphus

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

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

On Sat, Nov 22, 2003 at 08:47:40AM +0200, Michael Shigorin wrote:

 >> -- одно дело барьер, ограничивающий попадение пакета вообще в
 >> сизиф (а чем sisyphus_check не такой барьер?), другое дело
 >> барьер, предназначеный для того, чтобы на машины конечных
 >> пользователей данного пакета попадал только оттестированый
 >> пакет.
 > Понимаю.  Но сказанное относилось к ним обоим.

Мне кажется, что огранчения первого типа могут вызывать какие-то
неприятности (если они неразумные), а второго типа -- вряд ли. 
 
 > >  >> Есть Сизиф, который изначально динамичен (политкорректное
 > >  >> название нестабильности). Возможно есть смысл создать ещё один
 > >  >> репозиторий, в которые и переносить автоматом пакеты.
 > >  > testing? ;-)
 > > Да. За исключением идеи с тем, что у разных пакетов могут быть
 > > разные периоды тестирования, и тем, что этот период будет
 > > зависеть от того, сколько человек (и какого ранга) подписали
 > > пакет. Скажем подпись человека из security team должна означать
 > > то, что пакет лучше всего перенести немедленно.
 > Вот и появилось слово "ранг".  Чем же он определяется?

Для некоторых пакетов (openssh, pam, tcb, glibc, login) он искуственный,
и задаётся ручками, скорее всего security командой. Для всех остальных его
можно рассчитывать. По поводу того какая формула даст пригодный
практически результат ещё стоит подумать, но базироваться рассчёт должен
на:
 - количестве прямо зависимых пакетов (и их ранге?)
 - количестве косвенно зависимых пакетов (и их ранге?)
 - группе, к которой относится пакет (скажем если он из группы Games, то
   требовать для него месяц тестирования или десяток подписей по меньшей
   времени неразумно).
 
 > (собственно, нечто вроде freshmeat/slashdot-like системы давно
 > напрашивается применительно к _пакетам_)

Я не знаком с этой системой.
 
 >>> Форканье всего -- осмысленно разве что перед "большим релизом"...
 >>> и вообще слишком сильно завязано на внутренние процессы
 >>> подготовки релиза в конкретно взятой фирме.
 >> Почему, если для предлагаемой мною модели форка практически не
 >> требуется человеческих ресурсов?
 > Sure? (я могу чего-то не понимать, но и setup time (написание
 > кода для переноса, инициализация этих самых рангов, ...), и
 > runtime (подписи, проверка, перекладывание?) -- в т.ч. и
 > человекоемкие вещи.

1. написание кода -- да, это некие ресурсы, если в ходе обсуждения мы
сможем чётко сформулировать ТЗ, то, _возможно_, я это напишу
(руководствуясь основным принципом Open Source -- тебе нужно, ты и пиши).

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

3. подписи -- один скриптик, и для человека сделать и отправить подпись
будет задачей на несколько секунд.

4. проверка -- дык если мне пакет _нужен_, то я с удовольствием его
проверю (особенно если у меня из репозитария какая-нибудь машина автоматом
апгрейдится :) А смысл этой проверки -- просто сказать "да, _меня_ этот
пакет устраивает".

5. перекладывание -- машина железная, пусть она и перекладывает,
единственная сложность при этом это поддержка целостности дистрибутива,
только по этому скрипт перекладывания будет требовать подумать, прежде чем
его написать.

Вывод: человекоёмким будет только создание этой системы, с учётом пользы,
которую это принесёт, такие затраты вполне оправданы.

 >>> (почему об этом говорю? -- да потому, что это единственная
 >>> реальная на сейчас мотивация дополнительного репо)
 >> С моей точки зрения есть смысл в существовании постоянно
 >> развивающегося дистрибутива средней надёжности (средней, в
 >> смысле на ядерный реактор ставить не стоит). Линукс слишком
 >> быстро развивается, чтобы выход нового дистрибутива раз в год
 >> мог устроить.
 > Почему?  Вон корпоративным пользователям (заметь: деньги они
 > платят, а не пользователи unstable) более удобен цикл порядка
 > трех лет.  С поддержкой продукта в течении.

Добавлю к своей реплике -- "... чтобы мог устроить _всех_".

 >> Поэтому постоянно изменяющийся репозиторий, генерирующийся
 >> _автоматически_ на базе Сизифа, IMHO, вполне имеет право на
 >> жизнь и свою, отнюдь не маленькую, аудиторию.
 > Да кристально понятно.  Я бы на таком и серверы некоторые держал
 > :-)

:)

 > Только это фактически постоянно выпускаемый дистрибутив (навроде
 > Compact, только объемами побольше) -- соответственно ему нужен
 > QA.

Позиционироваться он должен точно так же как и Сизиф -- репозиторий для
разработчика. Некоторый QA и будет выполняться теми, кто тестирует
интересные ему пакеты, с помощью пары скриптов (один отсылает подпись,
другой смотря на подписи и на даты выполняет перемещение).
 
 > Понятно, что некоторые вещи вроде "чистой BTS" могут быть
 > формальными критериями для скрипта -- только ситуации вроде
 > критических багов, правящихся наживую и попросту не попадающих в
 > BTS -- не отработаются.  Лекарство от этого -- обязать проводить
 > их _через_ багтрекер, но тут мне не нравится слово "обязать".
 > Потому что смотря кого.

Я не пытаюсь изобрести серебрянную пулю, которая позволит попрыгав с
бубном и написав скрипт автоматически получить дистрибутив, пригодный к
использованию в управлении ядерными реакторами. Боже упаси. У излагаю своё
предложение, которое может помочь _заметно улучшить_ качество
_общедоступного постоянно изменяющегося репозитария_.

Что-то не пройдёт через BTS, может быть какая-то ошибка не будет
исправлена, и с какой-то вероятностью таки попадёт кривующий пакет в этот
дистрибутив. В текущей схеме он попадёт туда 100%, в предлагаемой мною у
него будет масса заслонов.

 > >  > > Ты действительно не согласен с тем, что у мантейнеров пакетов,
 > >  > > которые зависят от обновляемых должно быть время проверки на
 > >  > > совместимость, перед тем как этот пакет отправится в
 > >  > > репозиторий, используемый на реальных рабочих машинах (пусть и
 > >  > > не серверах)?
 > >  > Это было бы слишком хорошо.  Я не вижу, как это *реально*
 > >  > сделать :(
 > > Реально сделать так, чтобы у них _было время_.
 > В такой формулировке это фултайм, period.

Причём тут фуллтайм? Лично я (по крайней мере в ближайшее время) не
собираюсь заниматься уделять времени работе в команде хотя бы сравнимое с
фуллтайм. При этом я очень хочу, чтобы критичные для меня пакеты попадали
ко мне на тестирование _до_ того, как они попадут в репозиторий, с
которого мне, возможно, в какой-то момент придётся обновиться. И время на
тестировании пары нужных мне пакетиков я найду.
 
 > Личное время -- как домашний каталог: можешь попробовать
 > ненавязчиво помочь человеку, сделав что-то за него (~/tmp и
 > TMPDIR), а можешь и возмутить его (~/Desktop и ~/Documents,
 > которые вечно сносятся и порой пытаются появиться).

Дык о чём и речь -- должна быть _возможность_ (например сделать mkdir
~/Desktop).

Я не слишком чётко, видимо, сформулировал идею -- речь шла _и_ о временном
барьере, _и_ о барьере с подписями. При этом временной барьер должен
уменьшаться в зависимости от числа подписей. И, возможно, отдельно должны
обрабатываться такие случаи как подписи security team (это повод для
немедленного переноса).
 
 > >  >> Как ты себе представляешь структуру такой команды? Один
 > >  >> ответственный перепроверяет _все_ пакеты идущие в incoming.
 > >  > Или не проверяет...
 > > Так может лучше модель, когда любой человек может проверить
 > > пакет, и если некоторое количество людей утверждают что пакет
 > > стабильный, то считать его стабильным? Модель очень
 > > напоминающая модель проверки достоверности PGP-ключа.
 > Здесь ключ -- "может проверить".
 > 1) это QA => ответственность
 > 2) это тоже риск
 > 3) где грань, когда человек _может_ сказать, что "пакет
 >    стабилен"? (применительно как к пакету, так и к человеку)

Абсолютно никакой ответственности. Человек просто говорит что "лично для
меня этот пакет пригоден к использованию и лично я считаю этот пакет
пригодным для установки на свои машины". Говорит он это с чисто
эгоистической позиции.

Фишка в том, что если посмотрит несколько человек, то заметно больше
шансов что block bug будет найден до переноса в другой репозитарий.
Собственно и городится всё это исключительно для этой цели.

Риск -- да, конечно. На текущий момент использование большинства программ,
входящих в состав дистрибутива (начиная с ядра) является риском. И будет
являться до тех пор, пока не будут использоваться более другие языки
программирования чем C/C++, и не начнут использоваться механизмы доказания
программ. Однако мой идеализм не заходит настолько далеко, чтобы из-за
этого не пользоваться линуксом :)

Для меня на домашней машине после реализации такого механизма будет вполне
разумным ставить a[t-get upgrade -y в cron'e. Ты даже на некоторые сервера
уже готов такую систему поставить. А кто-то принципиально не станет
ставить нечто, неоттестированое лет эдак много. У каждого своя оценка
риска.

Дело всё в том, что Сизиф очень немногих устраивает как рабочий
дистрибутив. А даже для выплнения функций мантейнера периодический upgrade
очень даже желателен. Но геморроя лишний раз ой как не хочется. А риск от
предлагаемого мною репозитария будет во много раз меньше чем от
использования Сизифа, и это уже устроит как минимум многих домашних
пользователей.

-- 
С уважением, Денис

http://freesource.info


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

[devel] Re: Надёжность Sisyphus

[Michael Shigorin]

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

On Sun, Nov 23, 2003 at 09:44:27AM +0300, Денис Смирнов wrote:
>  >> сизиф (а чем sisyphus_check не такой барьер?), другое дело
>  >> барьер, предназначеный для того, чтобы на машины конечных
>  >> пользователей данного пакета попадал только оттестированый
>  >> пакет.
>  > Понимаю.  Но сказанное относилось к ним обоим.
> Мне кажется, что огранчения первого типа могут вызывать какие-то
> неприятности (если они неразумные), а второго типа -- вряд ли. 

Да; проблема в том, что (на сейчас) первое автоматизируется,
второе -- непонятно как (с тем чтоб реально, а не схема, которая
будет великолепна и никем не используема).

>  > > разные периоды тестирования, и тем, что этот период будет
>  > > зависеть от того, сколько человек (и какого ранга) подписали
>  > Вот и появилось слово "ранг".  Чем же он определяется?
> Для некоторых пакетов (openssh, pam, tcb, glibc, login) он
> искуственный, и задаётся ручками, скорее всего security
> командой. Для всех остальных его можно рассчитывать. По поводу
> того какая формула даст пригодный практически результат ещё
> стоит подумать, но базироваться рассчёт должен на:
>  - количестве прямо зависимых пакетов (и их ранге?)
>  - количестве косвенно зависимых пакетов (и их ранге?)
>  - группе, к которой относится пакет (скажем если он из группы
>    Games, то требовать для него месяц тестирования или десяток
>    подписей по меньшей времени неразумно).

Вот.  Мне в голову что-то подобное тоже приходило, но у Вас
получилось сформулировать.

(на самом деле это добавляет в разработку sisyphus еще один
спортивно-соревновательный момент :))

>  > (собственно, нечто вроде freshmeat/slashdot-like системы
>  > давно напрашивается применительно к _пакетам_)
> Я не знаком с этой системой.

Схожая шкала с влиянием оценки на ранг, зависящей от ранга
оценивающего (в т.ч.), если правильно понял (в случае /.).

Мы тут подумывали сделать нечто вроде community site с
возможностью публикации резюмов и проделанных работ _и_ вот такой
вот оценки, чтобы профессиональный журнал человека мог быть
оценен и сравнен при принятии решения о взятии его на работу.

>  >> Почему, если для предлагаемой мною модели форка практически
>  >> не требуется человеческих ресурсов?
>  > Sure? (я могу чего-то не понимать, но и setup time
>  > (написание кода для переноса, инициализация этих самых
>  > рангов, ...), и runtime (подписи, проверка, перекладывание?)
>  > -- в т.ч. и человекоемкие вещи.
> 1. написание кода -- да, это некие ресурсы, если в ходе
> обсуждения мы сможем чётко сформулировать ТЗ, то, _возможно_, я
> это напишу (руководствуясь основным принципом Open Source --
> тебе нужно, ты и пиши).

Эт хорошо.

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

Скорее соглашусь.

> 3. подписи -- один скриптик, и для человека сделать и отправить
> подпись будет задачей на несколько секунд.
> 4. проверка -- дык если мне пакет _нужен_, то я с удовольствием
> его проверю (особенно если у меня из репозитария какая-нибудь
> машина автоматом апгрейдится :) А смысл этой проверки -- просто
> сказать "да, _меня_ этот пакет устраивает".

Ну положим.

> 5. перекладывание -- машина железная, пусть она и
> перекладывает, единственная сложность при этом это поддержка
> целостности дистрибутива, только по этому скрипт перекладывания
> будет требовать подумать, прежде чем его написать.
> 
> Вывод: человекоёмким будет только создание этой системы, с
> учётом пользы, которую это принесёт, такие затраты вполне
> оправданы.

Это понятно.  Тут просто наблюдается хроническая нехватка
ресурсов на автоматизацию из-за недостатка этой самой
автоматизации...

>  >> С моей точки зрения есть смысл в существовании постоянно
>  >> развивающегося дистрибутива средней надёжности (средней, в
>  >> смысле на ядерный реактор ставить не стоит). Линукс слишком
>  >> быстро развивается, чтобы выход нового дистрибутива раз в год
>  >> мог устроить.
>  > Почему?  Вон корпоративным пользователям (заметь: деньги они
>  > платят, а не пользователи unstable) более удобен цикл порядка
>  > трех лет.  С поддержкой продукта в течении.
> Добавлю к своей реплике -- "... чтобы мог устроить _всех_".

Так не бывает.  См. в т.ч. RH -- это _очень_ хороший пример.
Их Федоре вон теперь расти до Sisyphus :)

>  > Понятно, что некоторые вещи вроде "чистой BTS" могут быть
>  > формальными критериями для скрипта -- только ситуации вроде
>  > критических багов, правящихся наживую и попросту не попадающих в
>  > BTS -- не отработаются.  Лекарство от этого -- обязать проводить
>  > их _через_ багтрекер, но тут мне не нравится слово "обязать".
>  > Потому что смотря кого.
> Я не пытаюсь изобрести серебрянную пулю, которая позволит
> попрыгав с бубном и написав скрипт автоматически получить
> дистрибутив, пригодный к использованию в управлении ядерными
> реакторами. Боже упаси. У излагаю своё предложение, которое
> может помочь _заметно улучшить_ качество _общедоступного
> постоянно изменяющегося репозитария_.

Да прекрасно понятно :-)  И мне оно нравится, почему же и
докапываюсь везде, где могу. (где могут вылезти бяки, которые
лучше продумать до -- в разумных пределах)

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

Что-то не слышно мнения QA, кстати.  Удивительно.

>  > > Реально сделать так, чтобы у них _было время_.
>  > В такой формулировке это фултайм, period.
> Причём тут фуллтайм?

Ну, "_было_" == гарантия.  Другое дело, что время, выделяемое
человеком, но сэкономленное от всякой ерунды (вроде выделения
мышом в xterm пачки пакетов, порожденных hasher, и переноса в
подписное отделение и отправки) -- может действительно
применяться на более полезные дела.

>  > Личное время -- как домашний каталог: можешь попробовать
>  > ненавязчиво помочь человеку, сделав что-то за него
> Дык о чём и речь -- должна быть _возможность_

ACK

> Я не слишком чётко, видимо, сформулировал идею -- речь шла _и_
> о временном барьере, _и_ о барьере с подписями. При этом
> временной барьер должен уменьшаться в зависимости от числа
> подписей. И, возможно, отдельно должны обрабатываться такие
> случаи как подписи security team (это повод для немедленного
> переноса).

Есть подозрение, что security team все равно переносит чуть ли не
руками... но ладно.

>  > Здесь ключ -- "может проверить".
>  > 1) это QA => ответственность
>  > 2) это тоже риск
>  > 3) где грань, когда человек _может_ сказать, что "пакет
>  >    стабилен"? (применительно как к пакету, так и к человеку)
> Абсолютно никакой ответственности. Человек просто говорит что
> "лично для меня этот пакет пригоден к использованию и лично я
> считаю этот пакет пригодным для установки на свои машины".

Если формулировку закрепить для несоздания иллюзий -- согласен.

> Фишка в том, что если посмотрит несколько человек, то заметно
> больше шансов что block bug будет найден до переноса в другой
> репозитарий.  Собственно и городится всё это исключительно для
> этой цели.

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

> Однако мой идеализм не заходит настолько далеко, чтобы из-за
> этого не пользоваться линуксом :)

:)

> Дело всё в том, что Сизиф очень немногих устраивает как рабочий
> дистрибутив. А даже для выплнения функций мантейнера
> периодический upgrade очень даже желателен. Но геморроя лишний
> раз ой как не хочется. А риск от предлагаемого мною репозитария
> будет во много раз меньше чем от использования Сизифа, и это
> уже устроит как минимум многих домашних пользователей.

IMCO главное тут -- не домашние пользователи, не в обиду им будь
сказано.  А именно разработчики, которые путем расширения ареала
таких систем могут, с одной стороны, обеспечить себе большее
удобство (стал бы я портировать пакеты назад на Мастер), а с
другой стороны -- обеспечивать все то же дополнительное
тестирование уже на уровне перехода testing-->stable.

Домашним пользователям же, как правило, достаточно stable (плохо
разве то, что у нас два года нет stable без выдающихся мелких
ляпов, но это вроде как исправляется -- compact-20031026_mike
меня в своем роде устраивает); те же, кому недостаточно -- или
уже разработчики, или очень быстро ими становятся по вполне
понятным причинам.

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

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

Re: [devel] Надёжность Sisyphus

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

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

On Mon, Nov 24, 2003 at 09:27:44AM +0200, Michael Shigorin wrote:

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

Разумеется. Поэтому я и предлагаю схему, которая будет _работать_ (пусть и
не с лучшей эффективностью) даже если на неё все забьют, и при этом будет
работать весьма эффективно, если ей начнут пользоваться (т.е. отсылать
репорты о тестировании).
 
 > >  > > разные периоды тестирования, и тем, что этот период будет
 > >  > > зависеть от того, сколько человек (и какого ранга) подписали
 > >  > Вот и появилось слово "ранг".  Чем же он определяется?
 > > Для некоторых пакетов (openssh, pam, tcb, glibc, login) он
 > > искуственный, и задаётся ручками, скорее всего security
 > > командой. Для всех остальных его можно рассчитывать. По поводу
 > > того какая формула даст пригодный практически результат ещё
 > > стоит подумать, но базироваться рассчёт должен на:
 > >  - количестве прямо зависимых пакетов (и их ранге?)
 > >  - количестве косвенно зависимых пакетов (и их ранге?)
 > >  - группе, к которой относится пакет (скажем если он из группы
 > >    Games, то требовать для него месяц тестирования или десяток
 > >    подписей по меньшей времени неразумно).
 > Вот.  Мне в голову что-то подобное тоже приходило, но у Вас
 > получилось сформулировать.
 > (на самом деле это добавляет в разработку sisyphus еще один
 > спортивно-соревновательный момент :))

Об этом я не подумал. Интересная мысль. Тогда эту статистику в каком-то
виде надо публиковать.

 >>> (собственно, нечто вроде freshmeat/slashdot-like системы
 >>> давно напрашивается применительно к _пакетам_)
 >> Я не знаком с этой системой.
 > Схожая шкала с влиянием оценки на ранг, зависящей от ранга
 > оценивающего (в т.ч.), если правильно понял (в случае /.).

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

 > Мы тут подумывали сделать нечто вроде community site с
 > возможностью публикации резюмов и проделанных работ _и_ вот такой
 > вот оценки, чтобы профессиональный журнал человека мог быть
 > оценен и сравнен при принятии решения о взятии его на работу.

Интересная мысль.
 
 >>>> Почему, если для предлагаемой мною модели форка практически
 >>>> не требуется человеческих ресурсов?
 >>> Sure? (я могу чего-то не понимать, но и setup time
 >>> (написание кода для переноса, инициализация этих самых
 >>> рангов, ...), и runtime (подписи, проверка, перекладывание?)
 >>> -- в т.ч. и человекоемкие вещи.
 >> 1. написание кода -- да, это некие ресурсы, если в ходе
 >> обсуждения мы сможем чётко сформулировать ТЗ, то, _возможно_, я
 >> это напишу (руководствуясь основным принципом Open Source --
 >> тебе нужно, ты и пиши).
 > Эт хорошо.

 >> 3. подписи -- один скриптик, и для человека сделать и отправить
 >> подпись будет задачей на несколько секунд.
 >> 4. проверка -- дык если мне пакет _нужен_, то я с удовольствием
 >> его проверю (особенно если у меня из репозитария какая-нибудь
 >> машина автоматом апгрейдится :) А смысл этой проверки -- просто
 >> сказать "да, _меня_ этот пакет устраивает".
 > Ну положим.

Этот пункт критичен, и для реальной работоспособности необходимо именно
его донести до остальных. Человек подписывает пакет не тогда, когда он с
его точки зрения идеален, а тогда, когда лично он готов его использовать
у себя.
 
 >> Вывод: человекоёмким будет только создание этой системы, с
 >> учётом пользы, которую это принесёт, такие затраты вполне
 >> оправданы.
 > Это понятно.  Тут просто наблюдается хроническая нехватка
 > ресурсов на автоматизацию из-за недостатка этой самой
 > автоматизации...

Змкнутый круг. IMHO такой круг рвётся только тем, что задачи по
автоматизации на некоторое время выносятся на самый верх по приоритетам.

 > >  >> С моей точки зрения есть смысл в существовании постоянно
 > >  >> развивающегося дистрибутива средней надёжности (средней, в
 > >  >> смысле на ядерный реактор ставить не стоит). Линукс слишком
 > >  >> быстро развивается, чтобы выход нового дистрибутива раз в год
 > >  >> мог устроить.
 > >  > Почему?  Вон корпоративным пользователям (заметь: деньги они
 > >  > платят, а не пользователи unstable) более удобен цикл порядка
 > >  > трех лет.  С поддержкой продукта в течении.
 > > Добавлю к своей реплике -- "... чтобы мог устроить _всех_".
 > Так не бывает.  См. в т.ч. RH -- это _очень_ хороший пример.
 > Их Федоре вон теперь расти до Sisyphus :)

Дык и я о том же, что сделать пригодное для всех не получится :) Есть
люди, которым нужен 0day софт (разработчики, которым важно видеть заранее
что будет стоять на машинах у пользователей через несколько месяцев), а
есть те, кому и 5-и лет тестирования мало.
 
 > >  > Понятно, что некоторые вещи вроде "чистой BTS" могут быть
 > >  > формальными критериями для скрипта -- только ситуации вроде
 > >  > критических багов, правящихся наживую и попросту не попадающих в
 > >  > BTS -- не отработаются.  Лекарство от этого -- обязать проводить
 > >  > их _через_ багтрекер, но тут мне не нравится слово "обязать".
 > >  > Потому что смотря кого.
 > > Я не пытаюсь изобрести серебрянную пулю, которая позволит
 > > попрыгав с бубном и написав скрипт автоматически получить
 > > дистрибутив, пригодный к использованию в управлении ядерными
 > > реакторами. Боже упаси. У излагаю своё предложение, которое
 > > может помочь _заметно улучшить_ качество _общедоступного
 > > постоянно изменяющегося репозитария_.
 > Да прекрасно понятно :-)  И мне оно нравится, почему же и
 > докапываюсь везде, где могу. (где могут вылезти бяки, которые
 > лучше продумать до -- в разумных пределах)

Ясно, тогда большое спасибо :)
 
 >> Что-то не пройдёт через BTS, может быть какая-то ошибка не
 >> будет исправлена, и с какой-то вероятностью таки попадёт
 >> кривующий пакет в этот дистрибутив. В текущей схеме он попадёт
 >> туда 100%, в предлагаемой мною у него будет масса заслонов.
 > Что-то не слышно мнения QA, кстати.  Удивительно.


 >>>> Реально сделать так, чтобы у них _было время_.
 >>> В такой формулировке это фултайм, period.
 >> Причём тут фуллтайм?
 > Ну, "_было_" == гарантия.  Другое дело, что время, выделяемое
 > человеком, но сэкономленное от всякой ерунды (вроде выделения
 > мышом в xterm пачки пакетов, порожденных hasher, и переноса в
 > подписное отделение и отправки) -- может действительно
 > применяться на более полезные дела.

Я имел в виду под этой фразой другое. Скажем ты делаешь новый апач и
кладёшь его в сизиф. Предположим ты где-то ошибся. Есть ли время у кого-то
кроме тебя протестировать этот апач _до того_, как он попадёт в
репозиторий де-факт использующийся конечными пользователями? Нет, ни
минуты. При введении предложеной мной схемы любой желающий сможет взять
протестировать этот апач _до того_, как он попадёт к _пользователям_.

Можно, конечно, прятать голову в песок и говорить что сизиф только для
разработчиков, но де-факто это не так, и мы все это прекрасно знаем :)

 >> Я не слишком чётко, видимо, сформулировал идею -- речь шла _и_
 >> о временном барьере, _и_ о барьере с подписями. При этом
 >> временной барьер должен уменьшаться в зависимости от числа
 >> подписей. И, возможно, отдельно должны обрабатываться такие
 >> случаи как подписи security team (это повод для немедленного
 >> переноса).
 > Есть подозрение, что security team все равно переносит чуть ли не
 > руками... но ладно.

Насколько я понимаю security team не занимается сизифом, или я ошибаюсь?
 
 >>> Здесь ключ -- "может проверить".
 >>> 1) это QA => ответственность
 >>> 2) это тоже риск
 >>> 3) где грань, когда человек _может_ сказать, что "пакет
 >>>    стабилен"? (применительно как к пакету, так и к человеку)
 >> Абсолютно никакой ответственности. Человек просто говорит что
 >> "лично для меня этот пакет пригоден к использованию и лично я
 >> считаю этот пакет пригодным для установки на свои машины".
 > Если формулировку закрепить для несоздания иллюзий -- согласен.

Именно, только при такой формулировке люди будут реально подписывать
пакеты. Иначе безответственные будут подписывать хаотичным образом, а
ответственные не будут подписывать вообще, прок будет минимальный (хотя
всё равно будет, то что block bug в BTS поставленый вовремя гарантирует
непрохождение пакета уже само по себе полезно).

Ещё мысль -- если висит block или critical bug на пакет, который уже в
протестированом репозитории, то прохождение новой версии этого пакета
должно ускоряться (вопрос только насколько).

 >> Фишка в том, что если посмотрит несколько человек, то заметно
 >> больше шансов что block bug будет найден до переноса в другой
 >> репозитарий.  Собственно и городится всё это исключительно для
 >> этой цели.
 > Это понятно.  Я беспокоюсь о том, чтобы этих несколько человек
 > *нашлось*... впрочем, может, вижу проблемы там, где их нет.

Думаю что в начале их не найдётся, и работать будет в первую очередь
механизм блокирования через BTS и выжидания некоторого время. 
 
 >> Дело всё в том, что Сизиф очень немногих устраивает как рабочий
 >> дистрибутив. А даже для выплнения функций мантейнера
 >> периодический upgrade очень даже желателен. Но геморроя лишний
 >> раз ой как не хочется. А риск от предлагаемого мною репозитария
 >> будет во много раз меньше чем от использования Сизифа, и это
 >> уже устроит как минимум многих домашних пользователей.
 > IMCO главное тут -- не домашние пользователи, не в обиду им будь
 > сказано.  А именно разработчики, которые путем расширения ареала
 > таких систем могут, с одной стороны, обеспечить себе большее
 > удобство (стал бы я портировать пакеты назад на Мастер), а с
 > другой стороны -- обеспечивать все то же дополнительное
 > тестирование уже на уровне перехода testing-->stable.

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

 > Домашним пользователям же, как правило, достаточно stable 

Ага, только почему-то именно они любят распосление версии софта. И как раз
их отучать от этого смысла нет (хочется дома человеку помаяться с глюками,
пусть мается, лишь бы разработчикам о них сообщал).
 
 > (плохо разве то, что у нас два года нет stable без выдающихся мелких
 > ляпов, но это вроде как исправляется -- compact-20031026_mike
 > меня в своем роде устраивает); те же, кому недостаточно -- или
 > уже разработчики, или очень быстро ими становятся по вполне
 > понятным причинам.

Или не утруждают себя таким геморроем как использование Линукса. У меня в
одной комнате со мной есть отличным пример -- братец, у которого тоже
Мастер (я ему коробочку подарил). Так вот ему действительно оказалось
вполне комфортно в нём работать. Только вот неработа kppp из коробки (без
правки под рутом), то что apt в некоторых случаях при установке не
ставится (а rpm'ом он пользоваться не умеет), и мерзкий глюк с поддержкой
звука (то, что надо во-первых использовать OSS-драйвера, редактируя для
этого modules.conf, а во-вторых то, что надо убирать сортировку из
/etc/init.d/sound, ибо иначе первым оказывается тюнер) привели его к тому,
что он пользуется виндой даже тогда, когда ему удобнее линукс. Кстати он
весьма странный в этом смысле человек -- хоть и воспитывался уже на
Win'98, но тексты ему набивать нравится больше в Far'е на полный экран,
чем в ворде :)

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

Чайник с кувалдой тоже может быть хорошо как бетатестер :) Официальные
бета-версии пользователи не так часто себе ставят, а если это непрервыно
меняющийся репозиторий, то он точно так же непрерывно тестируется.

-- 
С уважением, Денис

http://freesource.info


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

[devel] Re: Надёжность Sisyphus

[Michael Shigorin]

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

On Mon, Nov 24, 2003 at 02:21:17PM +0300, Денис Смирнов wrote:
> Человек подписывает пакет не тогда, когда он с его точки зрения
> идеален, а тогда, когда лично он готов его использовать у себя.

ACK

>  >> Вывод: человекоёмким будет только создание этой системы, с
>  >> учётом пользы, которую это принесёт, такие затраты вполне
>  >> оправданы.
>  > Это понятно.  Тут просто наблюдается хроническая нехватка
>  > ресурсов на автоматизацию из-за недостатка этой самой
>  > автоматизации...
> Змкнутый круг. IMHO такой круг рвётся только тем, что задачи по
> автоматизации на некоторое время выносятся на самый верх по
> приоритетам.

Или приходит кто-то и их делает.

> Я имел в виду под этой фразой другое. Скажем ты делаешь новый
> апач и кладёшь его в сизиф. Предположим ты где-то ошибся. Есть
> ли время у кого-то кроме тебя протестировать этот апач _до
> того_, как он попадёт в репозиторий де-факт использующийся
> конечными пользователями? Нет, ни минуты. При введении
> предложеной мной схемы любой желающий сможет взять
> протестировать этот апач _до того_, как он попадёт к
> _пользователям_.

Эээ... придумал, как это сделать тупо и угрюмо: *RPMS.incoming,
не входящий в .classic -- под отдельную прописку в sources.list.

Из Sisyphus/incoming пакет (после incoming@/qa@?) попадает именно
туда, если нет подтвержденной майнтейнером (с учетом пресловутого
ранга, когда он вводится?) необходимости в другом;

в .incoming он может лежать до достижения некоего списка
критериев, в которые входят время; подписи; записи в BTS;

по достижении такового робот перетаскивает в другую (хорошо бы
автоматом определять, какую) компоненту.

  здесь еще один момент: насколько я помню задумку новой
  структуры репозитория, подразумевалось, что есть несколько
  "базовых" репо (kernel, base, master, junior), "ниже" которых
  сообразно своей нестабильности пакет опуститься не может -- это
  категоризация по роду применения; вот здесь было бы уместно
  детерминировать, какой репозиторий является "целевым" для
  пакета по мере увеличения его известной стабильности.

>  > Есть подозрение, что security team все равно переносит чуть ли не
>  > руками... но ладно.
> Насколько я понимаю security team не занимается сизифом, или я
> ошибаюсь?

Хех.  Интересно -- кто из разработчиков вообще им _не_
занимается...

>  >>> 3) где грань, когда человек _может_ сказать, что "пакет
>  >>> стабилен"? (применительно как к пакету, так и к человеку)
>  >> Абсолютно никакой ответственности. Человек просто говорит
>  >> что "лично для меня этот пакет пригоден к использованию и
>  >> лично я считаю этот пакет пригодным для установки на свои
>  >> машины".
>  > Если формулировку закрепить для несоздания иллюзий --
>  > согласен.
> Именно, только при такой формулировке люди будут реально
> подписывать пакеты.  Ещё мысль -- если висит block или critical
> bug на пакет, который уже в протестированом репозитории, то
> прохождение новой версии этого пакета должно ускоряться (вопрос
> только насколько).

Ммм... разумно.  Может эмулироваться на заинтересованных людях и
их голосах, но лучше автоматизировать.

>  > Домашним пользователям же, как правило, достаточно stable 
> Ага, только почему-то именно они любят распосление версии
> софта. И как раз их отучать от этого смысла нет (хочется дома
> человеку помаяться с глюками, пусть мается, лишь бы
> разработчикам о них сообщал).

Еще как имеет.  На самом деле это такая же часть отучения от
болячек халявного проприетарного софта ("цифромания"), как и
отучение от синдрома "из пушки по воробьям", "дайте мне побольше
таблеток от жадности" и других схожих.  Впрочем, это отдельная
тема.

> Домашних пользователей я очень люблю и ценю, и считаю их крайне
> полезным для комьюнити, если они могут хотя бы более-менее
> грамотно отрапортовать об ошибке.

Да я тоже, но это просто другой вопрос.  Он позже.

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

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

Re: [devel] Надёжность Sisyphus

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

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

On Mon, Nov 24, 2003 at 03:05:39PM +0200, Michael Shigorin wrote:

 > >  > Это понятно.  Тут просто наблюдается хроническая нехватка
 > >  > ресурсов на автоматизацию из-за недостатка этой самой
 > >  > автоматизации...
 > > Змкнутый круг. IMHO такой круг рвётся только тем, что задачи по
 > > автоматизации на некоторое время выносятся на самый верх по
 > > приоритетам.
 > Или приходит кто-то и их делает.

Да.
 
 > > Я имел в виду под этой фразой другое. Скажем ты делаешь новый
 > > апач и кладёшь его в сизиф. Предположим ты где-то ошибся. Есть
 > > ли время у кого-то кроме тебя протестировать этот апач _до
 > > того_, как он попадёт в репозиторий де-факт использующийся
 > > конечными пользователями? Нет, ни минуты. При введении
 > > предложеной мной схемы любой желающий сможет взять
 > > протестировать этот апач _до того_, как он попадёт к
 > > _пользователям_.
 > Эээ... придумал, как это сделать тупо и угрюмо: *RPMS.incoming,
 > не входящий в .classic -- под отдельную прописку в sources.list.

Отличный вариант.
 
 > Из Sisyphus/incoming пакет (после incoming@/qa@?) попадает именно
 > туда, если нет подтвержденной майнтейнером (с учетом пресловутого
 > ранга, когда он вводится?) необходимости в другом;

Думаю что в любом случае именно туда. Перенос из incoming куда бы то ни
было ещё должен быть исключительно автоматическим. Например по подписи от
security@ что необходимо немедленно перенести пакет.

 > в .incoming он может лежать до достижения некоего списка
 > критериев, в которые входят время; подписи; записи в BTS;
 > по достижении такового робот перетаскивает в другую (хорошо бы
 > автоматом определять, какую) компоненту.

Как сейчас это определяется?
 
 >   здесь еще один момент: насколько я помню задумку новой
 >   структуры репозитория, подразумевалось, что есть несколько
 >   "базовых" репо (kernel, base, master, junior), "ниже" которых
 >   сообразно своей нестабильности пакет опуститься не может -- это
 >   категоризация по роду применения; вот здесь было бы уместно
 >   детерминировать, какой репозиторий является "целевым" для
 >   пакета по мере увеличения его известной стабильности.

Как измерять его известную стабильность? Количеством и типом багов в
каждом из релизов и временем обнаружения багов разных типов после выхода
релиза?
 
 >>> Есть подозрение, что security team все равно переносит чуть ли не
 >>> руками... но ладно.
 >> Насколько я понимаю security team не занимается сизифом, или я
 >> ошибаюсь?
 > Хех.  Интересно -- кто из разработчиков вообще им _не_
 > занимается...

Я не то имел в виду :) Насколько я понимаю понятия "security update" для
Сизифа просто не существует.
 
 > >  >>> 3) где грань, когда человек _может_ сказать, что "пакет
 > >  >>> стабилен"? (применительно как к пакету, так и к человеку)
 > >  >> Абсолютно никакой ответственности. Человек просто говорит
 > >  >> что "лично для меня этот пакет пригоден к использованию и
 > >  >> лично я считаю этот пакет пригодным для установки на свои
 > >  >> машины".
 > >  > Если формулировку закрепить для несоздания иллюзий --
 > >  > согласен.
 > > Именно, только при такой формулировке люди будут реально
 > > подписывать пакеты.  Ещё мысль -- если висит block или critical
 > > bug на пакет, который уже в протестированом репозитории, то
 > > прохождение новой версии этого пакета должно ускоряться (вопрос
 > > только насколько).
 > Ммм... разумно.  Может эмулироваться на заинтересованных людях и
 > их голосах, но лучше автоматизировать.

Угу. Тем более что block bug может быть повешен человеком, который вообще
не является мантейнером, и даже не имеет своей цифровой подписи. Если
мантейнер этот баг обработал и закрыл, то это повод.
 
 >>> Домашним пользователям же, как правило, достаточно stable 
 >> Ага, только почему-то именно они любят распосление версии
 >> софта. И как раз их отучать от этого смысла нет (хочется дома
 >> человеку помаяться с глюками, пусть мается, лишь бы
 >> разработчикам о них сообщал).
 > Еще как имеет.  На самом деле это такая же часть отучения от
 > болячек халявного проприетарного софта ("цифромания"), как и
 > отучение от синдрома "из пушки по воробьям", "дайте мне побольше
 > таблеток от жадности" и других схожих.  Впрочем, это отдельная
 > тема.

По крайней мере лично моя позиция такая -- если компьютер, на котором этот
пользователь так развлекается, не является офисным, то мне однозначно всё
равно чем он там занимается (у каждого свои развлекухи). Если же он так
играется с софтом, в стабильности которого я заинтересован (в том числе
написаным мною), то я его за такую манию ещё и пивом поить буду :)
 
 >> Домашних пользователей я очень люблю и ценю, и считаю их крайне
 >> полезным для комьюнити, если они могут хотя бы более-менее
 >> грамотно отрапортовать об ошибке.
 > Да я тоже, но это просто другой вопрос.  Он позже.

Увеличение количества домашних пользователей -- полезный побочный эффект
предлагаемой мною идеи.

-- 
С уважением, Денис

http://freesource.info


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

[devel] Re: Надёжность Sisyphus

[Michael Shigorin]

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

On Mon, Nov 24, 2003 at 05:07:26PM +0300, Денис Смирнов wrote:
>  > Эээ... придумал, как это сделать тупо и угрюмо: *RPMS.incoming,
>  > не входящий в .classic -- под отдельную прописку в sources.list.
> Отличный вариант.

Вот и мне так кажется.

Будет интересно выслушать мнение ldv@ как ftpmaster@ и inger@ как
incoming@.  По мере наличия у них возможности обдумать и
ответить, разумеется.

>  > в .incoming он может лежать до достижения некоего списка
>  > критериев, в которые входят время; подписи; записи в BTS;
>  > по достижении такового робот перетаскивает в другую (хорошо бы
>  > автоматом определять, какую) компоненту.
> Как сейчас это определяется?

Не знаю.  Думаю, головой/глазами/руками.

>  >   "базовых" репо (kernel, base, master, junior) [...]
>  >   детерминировать, какой репозиторий является "целевым" для
>  >   пакета по мере увеличения его известной стабильности.
> Как измерять его известную стабильность? Количеством и типом
> багов в каждом из релизов и временем обнаружения багов разных
> типов после выхода релиза?

Не знаю.  Впрочем, эта задача равносильна уже поставленной, для
которой предложено решение -- по собственно переносу из .incoming
в .contrib.

>  >> Насколько я понимаю security team не занимается сизифом,
>  >> или я ошибаюсь?
> Я не то имел в виду :) Насколько я понимаю понятия "security
> update" для Сизифа просто не существует.

Тем не менее готовить обновления для Sisyphus (которые его же
частью и становятся) -- приходится; на базе их (обычно?) и
создаются updates.

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

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

Re: [devel] Надёжность Sisyphus

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

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

On Mon, Nov 24, 2003 at 10:23:33PM +0200, Michael Shigorin wrote:

 >>> в .incoming он может лежать до достижения некоего списка
 >>> критериев, в которые входят время; подписи; записи в BTS;
 >>> по достижении такового робот перетаскивает в другую (хорошо бы
 >>> автоматом определять, какую) компоненту.
 >> Как сейчас это определяется?
 > Не знаю.  Думаю, головой/глазами/руками.

Спрошу по-другому -- руководствуясь какими критериями?
 
 >>>   "базовых" репо (kernel, base, master, junior) [...]
 >>>   детерминировать, какой репозиторий является "целевым" для
 >>>   пакета по мере увеличения его известной стабильности.
 >> Как измерять его известную стабильность? Количеством и типом
 >> багов в каждом из релизов и временем обнаружения багов разных
 >> типов после выхода релиза?
 > Не знаю.  Впрочем, эта задача равносильна уже поставленной, для
 > которой предложено решение -- по собственно переносу из .incoming
 > в .contrib.

В смысле если подписей больше некоего другого порога, и/или пакет пролежал
в репозитории больше некоего количества дней, то его допустимо переносить
в дистрибутив? Хм. В этом случае появляется одна проблема -- не всё, что
надо переносить в Master можно переносить в Junior, как это обрабатывать?
 
 >>>> Насколько я понимаю security team не занимается сизифом,
 >>>> или я ошибаюсь?
 >> Я не то имел в виду :) Насколько я понимаю понятия "security
 >> update" для Сизифа просто не существует.
 > Тем не менее готовить обновления для Sisyphus (которые его же
 > частью и становятся) -- приходится; на базе их (обычно?) и
 > создаются updates.

Ясно.

-- 
С уважением, Денис

http://freesource.info


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

[devel] Re: Надёжность Sisyphus

[Michael Shigorin]

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

On Tue, Nov 25, 2003 at 02:28:46AM +0300, Денис Смирнов wrote:
>  >>>   "базовых" репо (kernel, base, master, junior) [...]
>  >>>   детерминировать, какой репозиторий является "целевым" для
>  >>>   пакета по мере увеличения его известной стабильности.
>  >> Как измерять его известную стабильность? Количеством и типом
>  >> багов в каждом из релизов и временем обнаружения багов разных
>  >> типов после выхода релиза?
>  > Не знаю.  Впрочем, эта задача равносильна уже поставленной, для
>  > которой предложено решение -- по собственно переносу из .incoming
>  > в .contrib.
> В смысле если подписей больше некоего другого порога, и/или
> пакет пролежал в репозитории больше некоего количества дней, то
> его допустимо переносить в дистрибутив? Хм. В этом случае
> появляется одна проблема -- не всё, что надо переносить в
> Master можно переносить в Junior, как это обрабатывать?

Денис, там _еще_ более по-другому -- .master и .junior -- это
_разные_ _конечные_ точки маршрута стабилизации серверных /
общего_назначения и "настольных пакетов, соответственно.

По крайней мере я так понял.

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

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

Re: [devel] Надёжность Sisyphus

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

On Tue, Nov 25, 2003 at 09:06:16AM +0200, Michael Shigorin wrote:

 >> В смысле если подписей больше некоего другого порога, и/или
 >> пакет пролежал в репозитории больше некоего количества дней, то
 >> его допустимо переносить в дистрибутив? Хм. В этом случае
 >> появляется одна проблема -- не всё, что надо переносить в
 >> Master можно переносить в Junior, как это обрабатывать?
 > Денис, там _еще_ более по-другому -- .master и .junior -- это
 > _разные_ _конечные_ точки маршрута стабилизации серверных /
 > общего_назначения и "настольных пакетов, соответственно.
 > По крайней мере я так понял.

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

-- 
С уважением, Денис

http://freesource.info

[devel] Re: Надёжность Sisyphus

[Alexey Tourbin]

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

On Mon, Nov 24, 2003 at 09:27:44AM +0200, Michael Shigorin wrote:
> > Что-то не пройдёт через BTS, может быть какая-то ошибка не
> > будет исправлена, и с какой-то вероятностью таки попадёт
> > кривующий пакет в этот дистрибутив. В текущей схеме он попадёт
> > туда 100%, в предлагаемой мною у него будет масса заслонов.
> 
> Что-то не слышно мнения QA, кстати.  Удивительно.

Робот мнений не имеет. :)
Сизиф достаточно стабилен, чтобы использовать его по назначению.
Все программы, которыми я пользуюсь, работают хорошо.
Программами, которые работают плохо, я не пользуюсь.
Это грустно, но это выход.

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

Re: [devel] Re: Надёжность Sisyphus

[Alexey I. Froloff]

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

* Alexey Tourbin <at@altlinux.ru> [031124 16:54]:
> > Что-то не слышно мнения QA, кстати.  Удивительно.
> Робот мнений не имеет. :)
> Сизиф достаточно стабилен, чтобы использовать его по назначению.
> Все программы, которыми я пользуюсь, работают хорошо.
> Программами, которые работают плохо, я не пользуюсь.
> Это грустно, но это выход.
Такими темпами по количеству цитат в fortunes-ALT на душу
населения ты скоро догонишь ldv ;-)

-- 
Regards, Sir Raorn.
-------------------
Ну если хочется - кто же запретит? ;-)
		-- rider in devel@

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

Re: [devel] Надёжность Sisyphus

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

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

On Mon, Nov 24, 2003 at 04:43:00PM +0300, Алексей Турбин wrote:

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

Подскажи, пожалуйста, где ты ясновидению учился? Я тоже хочу! :)

От случайных ошибок мантейнеров спастись, кроме как принципом "хороший
пакет должен вылежаться", весьма сложно без обладания способностей к
ясновидению. Я искренне надеюсь, что людям не обладающим столь редкими
способностями тоже можно будет пользоваться репозиторием :)

-- 
С уважением, Денис

http://freesource.info


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

[devel] Re: îÁÄ£ÖÎÏÓÔØ Sisyphus

[Andrey Khavryuchenko]

Денис,

"ДС" == Денис Смирнов wrote:

 ДС> От случайных ошибок мантейнеров спастись, кроме как принципом "хороший
 ДС> пакет должен вылежаться", весьма сложно без обладания способностей к
 ДС> ясновидению.

Уже давно твердилось миру,
Что должен быть regression testing.
А воз, увы и ныне там.

-- 
Andrey V Khavryuchenko            http://www.kds.com.ua/
Silver Bullet Software Solutions  http://www.kds.com.ua/training/

[devel] Re: Надёжность Sisyphus

[Alexey Tourbin]

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

On Mon, Nov 24, 2003 at 10:45:55PM +0300, Денис Смирнов wrote:
>  > Все программы, которыми я пользуюсь, работают хорошо.
>  > Программами, которые работают плохо, я не пользуюсь.
>  > Это грустно, но это выход.
> 
> Подскажи, пожалуйста, где ты ясновидению учился? Я тоже хочу! :)

Я не пользуюсь иксами.  Вообще.  Последним аргументом стало то, что на
i845 они безбожно глючат, отваливается клавиатура, помогает только
перезагрузка по ssh.  Из консольных программ есть дюжина приличных,
некоторые из них я поддерживаю.

> От случайных ошибок мантейнеров спастись, кроме как принципом "хороший
> пакет должен вылежаться", весьма сложно без обладания способностей к
> ясновидению. Я искренне надеюсь, что людям не обладающим столь редкими
> способностями тоже можно будет пользоваться репозиторием :)

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

Re: [devel] Надёжность Sisyphus

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

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

On Tue, Nov 25, 2003 at 03:58:56PM +0300, Алексей Турбин wrote:

 > >  > Все программы, которыми я пользуюсь, работают хорошо.
 > >  > Программами, которые работают плохо, я не пользуюсь.
 > >  > Это грустно, но это выход.
 > > Подскажи, пожалуйста, где ты ясновидению учился? Я тоже хочу! :)
 > Я не пользуюсь иксами.  Вообще.  Последним аргументом стало то, что на
 > i845 они безбожно глючат, отваливается клавиатура, помогает только
 > перезагрузка по ssh.  Из консольных программ есть дюжина приличных,
 > некоторые из них я поддерживаю.

К сожалению проблемы могут быть где угодно. И ошибиться может, например,
мантейнер openssh. И если машина доступна только по сети (ибо в другом
городе, и нет serial console, про которую ни слова я нигде в документации
к Мастеру не нашёл, и многие администраторы о ней не знают), да ещё и
находится в другом городе, то ты имеешь шансы после обновления получить
массу удовольствия.

-- 
С уважением, Денис

http://freesource.info


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

Re: [devel] Надёжность Sisyphus

[Anton Farygin]

Денис Смирнов wrote:
> On Tue, Nov 25, 2003 at 03:58:56PM +0300, Алексей Турбин wrote:
> 
>  > >  > Все программы, которыми я пользуюсь, работают хорошо.
>  > >  > Программами, которые работают плохо, я не пользуюсь.
>  > >  > Это грустно, но это выход.
>  > > Подскажи, пожалуйста, где ты ясновидению учился? Я тоже хочу! :)
>  > Я не пользуюсь иксами.  Вообще.  Последним аргументом стало то, что на
>  > i845 они безбожно глючат, отваливается клавиатура, помогает только
>  > перезагрузка по ssh.  Из консольных программ есть дюжина приличных,
>  > некоторые из них я поддерживаю.
> 
> К сожалению проблемы могут быть где угодно. И ошибиться может, например,
> мантейнер openssh. И если машина доступна только по сети (ибо в другом
> городе, и нет serial console, про которую ни слова я нигде в документации
> к Мастеру не нашёл, и многие администраторы о ней не знают), да ещё и
> находится в другом городе, то ты имеешь шансы после обновления получить
> массу удовольствия.

На то он и Sisyphus, что бы после обновления получать массу удовольствия 
!!!!

Rgds,
Rider

Re: [devel] Надёжность Sisyphus

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

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

On Wed, Nov 26, 2003 at 03:33:29PM +0300, Anton Farygin wrote:

 >> К сожалению проблемы могут быть где угодно. И ошибиться может, например,
 >> мантейнер openssh. И если машина доступна только по сети (ибо в другом
 >> городе, и нет serial console, про которую ни слова я нигде в документации
 >> к Мастеру не нашёл, и многие администраторы о ней не знают), да ещё и
 >> находится в другом городе, то ты имеешь шансы после обновления получить
 >> массу удовольствия.
 > На то он и Sisyphus, что бы после обновления получать массу удовольствия 
 > !!!!

А я думал что он для разработки нужен...
 
-- 
С уважением, Денис

http://freesource.info


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

Re: [devel] Надёжность Sisyphus

[Anton Farygin]

Денис Смирнов wrote:
> On Wed, Nov 26, 2003 at 03:33:29PM +0300, Anton Farygin wrote:
> 
>  >> К сожалению проблемы могут быть где угодно. И ошибиться может, например,
>  >> мантейнер openssh. И если машина доступна только по сети (ибо в другом
>  >> городе, и нет serial console, про которую ни слова я нигде в документации
>  >> к Мастеру не нашёл, и многие администраторы о ней не знают), да ещё и
>  >> находится в другом городе, то ты имеешь шансы после обновления получить
>  >> массу удовольствия.
>  > На то он и Sisyphus, что бы после обновления получать массу удовольствия 
>  > !!!!
> 
> А я думал что он для разработки нужен...

А кто сказал, что от разработки нельзя получать массу удовольствия ??? ;-)

Rgds,
Rider

Re: [devel] Надёжность Sisyphus

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

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

On Wed, Nov 26, 2003 at 05:24:51PM +0300, Anton Farygin wrote:

 >>>> к Мастеру не нашёл, и многие администраторы о ней не знают), да ещё и
 >>>> находится в другом городе, то ты имеешь шансы после обновления получить
 >>>> массу удовольствия.
 >>> На то он и Sisyphus, что бы после обновления получать массу 
 >> удовольствия > !!!!
 >> А я думал что он для разработки нужен...
 > А кто сказал, что от разработки нельзя получать массу удовольствия ??? ;-)

Можно. Только вот dist-upgrade частенько вынуждает получить не то
удовольствие, которое хотелось бы :)
 
-- 
С уважением, Денис

http://dimline.ru/

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

Re: [devel] Надёжность Sisyphus

[Stanislav Ievlev]

On Thu, Nov 27, 2003 at 05:45:12AM +0300, Денис Смирнов wrote:
> On Wed, Nov 26, 2003 at 05:24:51PM +0300, Anton Farygin wrote:
> 
>  >>>> к Мастеру не нашёл, и многие администраторы о ней не знают), да ещё и
>  >>>> находится в другом городе, то ты имеешь шансы после обновления получить
>  >>>> массу удовольствия.
>  >>> На то он и Sisyphus, что бы после обновления получать массу 
>  >> удовольствия > !!!!
>  >> А я думал что он для разработки нужен...
>  > А кто сказал, что от разработки нельзя получать массу удовольствия ??? ;-)
> 
> Можно. Только вот dist-upgrade частенько вынуждает получить не то
> удовольствие, которое хотелось бы :)
На то она и _разработка_ и тем репозитарий и отличается от дистрибутива.
>  
> -- 
> С уважением, Денис
> 
> http://dimline.ru/



> _______________________________________________
> Devel mailing list
> Devel@altlinux.ru
> http://altlinux.ru/mailman/listinfo/devel

Re: [devel] Надёжность Sisyphus

[Canis Cerberus]

В сообщении от 27 Ноябрь 2003 05:45 Денис Смирнов написал(a):
> On Wed, Nov 26, 2003 at 05:24:51PM +0300, Anton Farygin wrote:
>  >>>> к Мастеру не нашёл, и многие администраторы о ней не знают), да ещё и
>  >>>> находится в другом городе, то ты имеешь шансы после обновления
>  >>>> получить массу удовольствия.
>  >>>
>  >>> На то он и Sisyphus, что бы после обновления получать массу
>  >>
>  >> удовольствия > !!!!
>  >> А я думал что он для разработки нужен...
>  >
>  > А кто сказал, что от разработки нельзя получать массу удовольствия ???
>  > ;-)
>
> Можно. Только вот dist-upgrade частенько вынуждает получить не то
> удовольствие, которое хотелось бы :)
бэкапы нужно делать перед дист-апгрейдом :-)
-- 
Canis Cerberus
Magna est veritas et praevalebit !
Санкт-Петербург

Re: [devel] Надёжность Sisyphus

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

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

On Wed, Dec 03, 2003 at 09:03:30AM +0300, Canis Cerberus wrote:

 >> Можно. Только вот dist-upgrade частенько вынуждает получить не то
 >> удовольствие, которое хотелось бы :)
 > бэкапы нужно делать перед дист-апгрейдом :-)

Да, конечно. А также искать новую работу :-)
 
-- 
С уважением, Денис

http://freesource.info


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

Re: [devel] Re: Надёжность Sisyphus

[Anton Farygin]

Alexey Tourbin wrote:
> On Mon, Nov 24, 2003 at 10:45:55PM +0300, Денис Смирнов wrote:
> 
>> > Все программы, которыми я пользуюсь, работают хорошо.
>> > Программами, которые работают плохо, я не пользуюсь.
>> > Это грустно, но это выход.
>>
>>Подскажи, пожалуйста, где ты ясновидению учился? Я тоже хочу! :)
> 
> 
> Я не пользуюсь иксами.  Вообще.  Последним аргументом стало то, что на
> i845 они безбожно глючат, отваливается клавиатура, помогает только
> перезагрузка по ssh.  Из консольных программ есть дюжина приличных,
> некоторые из них я поддерживаю.

Леш, на i845 XFree уже давно починили - спроси у Voins'а - у него все 
работает как часы.

Rgds,
Rider

Re: [devel] Надёжность Sisyphus

[Alexey I. Froloff]

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

* Денис Смирнов <mithraen@altlinux.ru> [031124 00:07]:
> Для некоторых пакетов (openssh, pam, tcb, glibc, login) он искуственный,
> и задаётся ручками, скорее всего security командой. Для всех остальных его
> можно рассчитывать. По поводу того какая формула даст пригодный
> практически результат ещё стоит подумать, но базироваться рассчёт должен
> на:
>  - количестве прямо зависимых пакетов (и их ранге?)
>  - количестве косвенно зависимых пакетов (и их ранге?)
>  - группе, к которой относится пакет (скажем если он из группы Games, то
>    требовать для него месяц тестирования или десяток подписей по меньшей
>    времени неразумно).
А если посмотреть на Debian'овскую схему с его stable, unstable,
testing и b0rken? testing (промежуточный между unstable и stable)
наверно будет лишним, и останутся Sisyphus, Icarus и Daedalus ;-)

-- 
Regards, Sir Raorn.
-------------------
Одно их правил хорошего тона говорит, что
+ если программа использует некую библиотеку, то она должна быть с ней
  слинкована;
+ если библиотека использует некую библиотеку, то она должна быть с ней
  слинкована.
		-- ldv in devel@

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

[devel] Re: Надёжность Sisyphus

[Michael Shigorin]

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

On Mon, Nov 24, 2003 at 12:05:32PM +0300, Alexey I. Froloff wrote:
> А если посмотреть на Debian'овскую схему с его stable, unstable,
> testing и b0rken? testing (промежуточный между unstable и stable)
> наверно будет лишним, и останутся Sisyphus, Icarus и Daedalus ;-)

Тю.  Так спич как раз о том, что нужен именно testing --
посредник между Sisyphus и $STABLE.

PS: а Icarus -- это "ну что, смертнички, полетаем?" ;-)

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

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

[devel] Re: Надёжность Sisyphus

[Anton V. Boyarshinov]

On Mon, 24 Nov 2003 11:27:06 +0200 Michael Shigorin
 wrote:

> > наверно будет лишним, и останутся Sisyphus, Icarus и Daedalus
> > ;-)
> 
> PS: а Icarus -- это "ну что, смертнички, полетаем?" ;-)

Примерно. Немного поработает -- и падет.

-- 
mailto:boyarsh@mail.ru
mailto:boyarsh@ru.echo.fr
 12:36:00  up 2 days,  1:54,  8 users,  load average: 0.00, 0.07,
0.11

Re: [devel] Re: Надёжность Sisyphus

[Alexey I. Froloff]

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

* Michael Shigorin <mike@osdn.org.ua> [031124 12:28]:
> > А если посмотреть на Debian'овскую схему с его stable, unstable,
> > testing и b0rken? testing (промежуточный между unstable и stable)
> > наверно будет лишним, и останутся Sisyphus, Icarus и Daedalus ;-)
> Тю.  Так спич как раз о том, что нужен именно testing --
> посредник между Sisyphus и $STABLE.
unstable == Icarus, b0rken == Daedalus, stable == Sisyphus.

Миграция пакетов: Daedalus -> Icarus -> Sisyphus

> PS: а Icarus -- это "ну что, смертнички, полетаем?" ;-)
Угу. Icarus летает на том, что сконстролил Daedalus, что
от этого отстанется Sisyphus потом катает ;-)

При такой схеме фриз сизифа не будет влиять на разработку в
Daedalus'е...

-- 
Regards, Sir Raorn.
-------------------
Хотел предложить воспользоваться bushbug, но он оказался сломанным.
		-- ldv in sisyphus@

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

Re: [devel] Re: Надёжность Sisyphus

[Alexander Bokovoy]

On Mon, Nov 24, 2003 at 11:27:06AM +0200, Michael Shigorin wrote:
> On Mon, Nov 24, 2003 at 12:05:32PM +0300, Alexey I. Froloff wrote:
> > А если посмотреть на Debian'овскую схему с его stable, unstable,
> > testing и b0rken? testing (промежуточный между unstable и stable)
> > наверно будет лишним, и останутся Sisyphus, Icarus и Daedalus ;-)
> 
> Тю.  Так спич как раз о том, что нужен именно testing --
> посредник между Sisyphus и $STABLE.
> 
> PS: а Icarus -- это "ну что, смертнички, полетаем?" ;-)
В новейшей истории Икарус -- это нечто иное. Резиновое и набиваемое по
самое "не хочу" на каждой остановке.

Сидящий рядом DD утверждает, что Testing, к сожалению, покрывает
достаточно узкий спектр задач и, в частности, наши проблемы не решит.
В то же время, идея кластеризации пакетной базы и контроль
развития/движения кластеров, который мы с тобой еще полтора года назад
обсуждали, является важным моментом при поддержке крупных репозитариев.
Тот же DD обещает заняться этим вопросом в прикладном плане, с учетом
возможности использования единых механизмов как на APT, так и на APT-RPM.
-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

[devel] Re: Надёжность Sisyphus

[Michael Shigorin]

On Mon, Nov 24, 2003 at 11:42:53AM +0200, Alexander Bokovoy wrote:
> Сидящий рядом DD утверждает, что Testing, к сожалению, покрывает
> достаточно узкий спектр задач и, в частности, наши проблемы не решит.

*sigh*

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

Естественно.

> Тот же DD обещает заняться этим вопросом в прикладном плане, с
> учетом возможности использования единых механизмов как на APT,
> так и на APT-RPM.

Вообще хорошо -- у них этот вопрос вроде как тоже стоит?

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

Re: [devel] Re: Надёжность Sisyphus

[Anton Farygin]

Michael Shigorin wrote:
> On Mon, Nov 24, 2003 at 12:05:32PM +0300, Alexey I. Froloff wrote:
> 
>>А если посмотреть на Debian'овскую схему с его stable, unstable,
>>testing и b0rken? testing (промежуточный между unstable и stable)
>>наверно будет лишним, и останутся Sisyphus, Icarus и Daedalus ;-)
> 
> 
> Тю.  Так спич как раз о том, что нужен именно testing --
> посредник между Sisyphus и $STABLE.

Зачем нужен Testing, когда есть Daedalus и Sisyphus ???

Rgds,
Rider

[devel] Re: Надёжность Sisyphus

[Michael Shigorin]

On Wed, Nov 26, 2003 at 03:34:13PM +0300, Anton Farygin wrote:
> >Тю.  Так спич как раз о том, что нужен именно testing --
> >посредник между Sisyphus и $STABLE.
> Зачем нужен Testing, когда есть Daedalus и Sisyphus ???

См. выше.  В Daedalus имеет право быть сломанным _слишком_ много,
а там бывают и критичные компоненты.

Это получается _не_ аналог Debian/testing, кстати -- а
действительно наоборот.  pre-Sisyphus.

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

Re: [devel] надёжность разработчиков Sisyphus

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

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

On Fri, Nov 21, 2003 at 07:42:59AM +0200, Denis Ovsienko wrote:

 >> Зачем барьер? Есть Сизиф, который изначально динамичен (политкорректное
 >> название нестабильности). Возможно есть смысл создать ещё один
 >> репозиторий, в которые и переносить автоматом пакеты. Соответственно
 > А потом ещё один, и туда --- ещё более надёжные... :) Уже есть Daedalus,
 > только мы им по назначению почему-то не пользуемся.

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

Да, конечнл.
 
 > Самоконтроль м самодисциплину никакой командой проверяющих не заменишь, на
 > собственном опыте убеждался не раз.

Разумеется. Однако, как уже говорилось в этом треде, даже самые
профессиональные специалисты иногда ошибаются. И цена их ошибки обычно
пропорциональна их профессиональности.

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

 > А всякие рассылки типа sisyphus-daily & cvsdiff-daily не нужны. Нужны
 > комментарии своих действий devel@ при заливке очередной сборки.

Ага. При этом "случайно" в инсталляционном скрипте оказалась строчка вида
"rm -rf <>". И чем эти комментарии помогут?
 
-- 
С уважением, Денис

http://dimline.ru/


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

[devel] Re: надёжность разработчиков Sisyphus

[Michael Shigorin]

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

On Fri, Nov 21, 2003 at 10:16:53PM +0300, Денис Смирнов wrote:
>  > есть Daedalus, только мы им по назначению почему-то не
> Пользуемся -- для заведомо потенциально опасных пакетов.

Нет -- для них localhost. :)

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

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

Re: [devel] Надёжность Sisyphus

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

On Thu, Nov 13, 2003 at 11:30:31PM +0300, Marat Khairullin wrote:

 >>> Задача: техническими и/или административными методами уменьшить
 >>> вероятность получения системным администратором по голове от руководства
 >>> и клиентов при попытке пбновиться.
 > Я давно пришел к выводу, что в серьезных проектах надо иметь тестовый сервер.

Разумеется. И этих серверов должно быть много (с разными конфигурациями,
причём хорошо бы и разными админами). Что и получается при разработке
продукта большой community.
 
 >>>       как реализовать: разделить сизиф на два уровня, новые пакеты всегда
 >>>       добавляются в один из уровней, если за неделю никаких изменений в
 >>>       нём не было (или на него не висит в BTS block-bug'ов), то
 >>>       автоматически переносить его в основной репозитарий. Вся эта работа
 >>>       должна выполняться автоматически, без участия человека (что снизит
 >>>       нагрузку на incominger'ов заодно).
 > И все будут ждать - когда же кто-нибудь по юзает/проверит новый пакет.
 > А он так и не юзаный никем кроме мантенера через неделю переползет в Сизиф...

...и тогда все огребут себе проблем. Людям, которым реально пакет _нужен_,
будет смысл отслеживать обновления и тестировать на подручных тестмашинах.
 
-- 
С уважением, Денис

http://freesource.info

[devel] Re: [sisyphus] Надёжность Sisyphus

[Michael Shigorin]

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

On Thu, Nov 13, 2003 at 09:54:04PM +0200, Alex Murygin wrote:
> И рассылку о новых/измененых пакетах хочу :) типа а ля news://fm.announce
> P.S. но не могу :)
> P.S.2. но ведь вторые 5 копеек наверное и не такая фантастика? :)

Именно.  Я вот все думаю прикрутить к украинскому зеркалу такой
нотификатор заради себя любимого, но все руки не доходят сесть на
полчаса и написать.

Ау, есть у кого? ;-)  Или хотя бы время -- чего от него хочу,
расскажу? ;-)

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

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