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

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

[Denis Ovsienko]

Господа!
Любое коллективное начинание не даст никакого эффекта, если от разговоров
не переходить к работе. Есть конкретные планы на текущий год, которые
придётся учесть при новых (пере)сборках?

--
    DO4-UANIC

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

[Stanislav Ievlev]

On Tue, Nov 25, 2003 at 12:17:25AM +0200, Denis Ovsienko wrote:
> 
> Господа!
> Любое коллективное начинание не даст никакого эффекта, если от разговоров
> не переходить к работе. Есть конкретные планы на текущий год, которые
> придётся учесть при новых (пере)сборках?
Если речь идёт о дополнительных репозитариях, то лично я пока так и ничего не понял:
1. зачем ещё один daedalus и что такое "надёжность sisyphus" по-определению.
2. какая будет схема "перетекания" пакетов из одного репозитария в другой, третий и т. п.
3. кто всё это будет поддерживать.
4. ну и много, много других вопросов.
> 
> --
>     DO4-UANIC
> _______________________________________________
> Devel mailing list
> Devel@altlinux.ru
> http://altlinux.ru/mailman/listinfo/devel

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

[Michael Shigorin]

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

On Tue, Nov 25, 2003 at 10:28:30AM +0300, Stanislav Ievlev wrote:
> Если речь идёт о дополнительных репозитариях, то лично я пока
> так и ничего не понял:
> 1. зачем ещё один daedalus

Не совсем.  Скорее "pre-sisyphus" как практически неизбежная
стадия попадания пакета в что-то, входящее в classic.

Т.е. не дополнительная танцплощадка, а звено технологической
цепочки.

> и что такое "надёжность sisyphus" по-определению.

Не знаю; не вводил.

> 2. какая будет схема "перетекания" пакетов из одного
> репозитария в другой, третий и т. п.

[office]incoming->OUT->[ftp].incoming->.contrib

(хм... может, чтоб избежать путаницы между каталогом incoming и
компонентой .incoming -- обозвать компоненту чем-то вроде limbo?
;-)

из .contrib -- в .master, .junior, ... -- как ты в свое время и
рисовал, когда описывал грядущие изменения в репозитории.  Этот
процесс может и не изменяться по ср. с текущим на сейчас.

---

Цель: предоставить разумную грань между
* "sisyphus для разработчиков",
    куда можно положить пакет, в котором
      тут же найдется ляп (не намеренно, но все мы знаем, что так
      бывает), который отловят
        те, кто будет использовать _и_ эту компоненту --
          разработчики
      -- до того, как пакет будет перемещен (точнее,
      пересимлинкован) в одну из имеющихся компонент,
        которые собираются в
* .classic, который и применяется
    _пользователями_ Sisyphus.
      (в т.ч. и разработчиками Sisyphus на хостах, которые можно
      себе позволить / требуется держать на Sisyphus, но которые
      желательно иметь в работоспособном состоянии),
при условии минимальных изменений в текущей схеме.

---

> 3. кто всё это будет поддерживать.

Скрипты.

Из требуемых изменений: делать симлинки из .incoming при
изначальном помещении из OUT в сизиф

Денис говорит, что готов написать скрипт-перетаскиватель из
.incoming в .contrib по достижении понимания того, что будет
критерием.

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

Для того, что хочется в итоге получить -- критерием будет
  совокупность
    важности (и "репутации"?) пакета,
    "репутации" майнтейнера (точнее, последнего собравшего?),
    наличие/критичность открытых багов в BTS,
    время, прошедшее с момента публикации пакета.

Изначально важность пакетов можно инициализировать из данных,
уже сделанных для инсталера плюс принадлежности к компонентам
вроде base; "репутацию" сборщиков я бы инициализировал как
"sec team"/"фултайм"/"волонтер" -> 0.75 / 0.5 / 0.25 из (0..1).

Но лучше пока не трогать, оставив вторым шагом.

> 4. ну и много, много других вопросов.

Ну так сюда их.

Может, через них Большие Грабли или Тривиальная Бессмысленность
обнаружатся.

-- 
 ---- 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

[Stanislav Ievlev]

On Tue, Nov 25, 2003 at 11:48:48AM +0200, Michael Shigorin wrote:
> On Tue, Nov 25, 2003 at 10:28:30AM +0300, Stanislav Ievlev wrote:
> > Если речь идёт о дополнительных репозитариях, то лично я пока
> > так и ничего не понял:
> > 1. зачем ещё один daedalus
> 
> Не совсем.  Скорее "pre-sisyphus" как практически неизбежная
> стадия попадания пакета в что-то, входящее в classic.
> 
> Т.е. не дополнительная танцплощадка, а звено технологической
> цепочки.
> 
> > и что такое "надёжность sisyphus" по-определению.
> 
> Не знаю; не вводил.
нет определения - значит нет правила перекочёвки пакетов из этого "pre-sisyphus" в sisyphus.
> 
> > 2. какая будет схема "перетекания" пакетов из одного
> > репозитария в другой, третий и т. п.
> 
> [office]incoming->OUT->[ftp].incoming->.contrib
> 
> (хм... может, чтоб избежать путаницы между каталогом incoming и
> компонентой .incoming -- обозвать компоненту чем-то вроде limbo?
> ;-)
> 
> из .contrib -- в .master, .junior, ... -- как ты в свое время и
> рисовал, когда описывал грядущие изменения в репозитории.  Этот
> процесс может и не изменяться по ср. с текущим на сейчас.
> 
> ---
> 
> Цель: предоставить разумную грань между
> * "sisyphus для разработчиков",
>     куда можно положить пакет, в котором
>       тут же найдется ляп (не намеренно, но все мы знаем, что так
>       бывает), который отловят
>         те, кто будет использовать _и_ эту компоненту --
>           разработчики
>       -- до того, как пакет будет перемещен (точнее,
>       пересимлинкован) в одну из имеющихся компонент,
>         которые собираются в
> * .classic, который и применяется
>     _пользователями_ Sisyphus.
>       (в т.ч. и разработчиками Sisyphus на хостах, которые можно
>       себе позволить / требуется держать на Sisyphus, но которые
>       желательно иметь в работоспособном состоянии),
> при условии минимальных изменений в текущей схеме.  
До настоящего момента у нас не был "сизифа-дистрибутива", а был только "сизиф для разработчико и желающих". Идеологи должны решить эту проблему до конца, прежде чем начнутся какие-то реальные шаги.

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

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

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


> 
> ---
> 
> > 3. кто всё это будет поддерживать.
> 
> Скрипты.
Не всё можно охватить скриптами.
Даже сейчас при наличии большого количества скриптов приходится иногда
incoming переводить на ручное управление.

Нет никаких гарантий, что нетривиальные замены библиотек,
преименование/образование подпакетов можно будет полностью охватить скриптами.
> 
> Из требуемых изменений: делать симлинки из .incoming при
> изначальном помещении из OUT в сизиф
> 
> Денис говорит, что готов написать скрипт-перетаскиватель из
> .incoming в .contrib по достижении понимания того, что будет
> критерием.
> 
> Для "заглушки" критерием может быть
>   время модификации, от которого прошло N часов (24?);
>     это даст эффект "админ должен быть в меру тормознутым" -- у
>     разработчиков будет фора в эти N часов на dist-upgrade и
>     использование пакета.
Как и кем определяются эти N часов. Если была бага на которую кто-то ещё
не напарывался - то не факт что через N часов она самоликвидируется.
> 
> Для того, что хочется в итоге получить -- критерием будет
>   совокупность
>     важности (и "репутации"?) пакета,
>     "репутации" майнтейнера (точнее, последнего собравшего?),
>     наличие/критичность открытых багов в BTS,
>     время, прошедшее с момента публикации пакета.
Не знаю что такое "репутация".
Почему же вот уже несколько месяцев tetex и python тащат за собой emacs.
> 
> Изначально важность пакетов можно инициализировать из данных,
> уже сделанных для инсталера плюс принадлежности к компонентам
> вроде base; "репутацию" сборщиков я бы инициализировал как
> "sec team"/"фултайм"/"волонтер" -> 0.75 / 0.5 / 0.25 из (0..1).
> 
> Но лучше пока не трогать, оставив вторым шагом.
> 
> > 4. ну и много, много других вопросов.
> 
> Ну так сюда их.
> 
> Может, через них Большие Грабли или Тривиальная Бессмысленность
> обнаружатся.
> 
> -- 
>  ---- WBR, Michael Shigorin <mike@altlinux.ru>
>   ------ Linux.Kiev http://www.linux.kiev.ua/



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

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

[Alexander Bokovoy]

On Tue, Nov 25, 2003 at 03:29:11PM +0300, Stanislav Ievlev wrote:
> >   совокупность
> >     важности (и "репутации"?) пакета,
> >     "репутации" майнтейнера (точнее, последнего собравшего?),
> >     наличие/критичность открытых багов в BTS,
> >     время, прошедшее с момента публикации пакета.
> Не знаю что такое "репутация".
> Почему же вот уже несколько месяцев tetex и python тащат за собой emacs.
Потому что налицо отсутствие времени у maintainer-ов группы пакетов emacs
на исправление тривиальной ошибки в распределении зависимостей в их
пакетах. Это уже обсуждалось и не один раз, tetex, python  и целый ряд
других пакетов совсем не виноваты.
-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

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

[Stanislav Ievlev]

On Tue, Nov 25, 2003 at 02:47:34PM +0200, Alexander Bokovoy wrote:
> On Tue, Nov 25, 2003 at 03:29:11PM +0300, Stanislav Ievlev wrote:
> > >   совокупность
> > >     важности (и "репутации"?) пакета,
> > >     "репутации" майнтейнера (точнее, последнего собравшего?),
> > >     наличие/критичность открытых багов в BTS,
> > >     время, прошедшее с момента публикации пакета.
> > Не знаю что такое "репутация".
> > Почему же вот уже несколько месяцев tetex и python тащат за собой emacs.
> Потому что налицо отсутствие времени у maintainer-ов группы пакетов emacs
> на исправление тривиальной ошибки в распределении зависимостей в их
> пакетах. Это уже обсуждалось и не один раз, tetex, python  и целый ряд
> других пакетов совсем не виноваты.
Вот и я о том.
> -- 
> / Alexander Bokovoy
> Samba Team                      http://www.samba.org/
> ALT Linux Team                  http://www.altlinux.org/
> Midgard Project Ry              http://www.midgard-project.org/
> _______________________________________________
> Devel mailing list
> Devel@altlinux.ru
> http://altlinux.ru/mailman/listinfo/devel

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

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

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

On Tue, Nov 25, 2003 at 03:29:11PM +0300, Stanislav Ievlev wrote:

 >>> и что такое "надёжность sisyphus" по-определению.
 >> Не знаю; не вводил.
 > нет определения - значит нет правила перекочёвки пакетов из этого "pre-sisyphus" в sisyphus.

У меня есть. Надёжность это величина равная 1-<ненадёжность>, а
ненадёжность, это вероятность поиметь геморрой после dist-upgrade в виде
неработоспособного сервера (т.е. не выполняющего свои функции так же
хорошо, как до апгрейда).

Конечная цель моего предложение -- довести надёжность Сизифа до такой
степени, чтобы можно было себе позволить по крайней мере на своей личной
машине apt-get upgrade -y в cron'е, а при выполнении такого апдейта
ручками на сервере масштаба хотя бы офиса быть увереным, что это не будет
грозить увольнением.
 
 >> * .classic, который и применяется
 >>     _пользователями_ Sisyphus.
 >>       (в т.ч. и разработчиками Sisyphus на хостах, которые можно
 >>       себе позволить / требуется держать на Sisyphus, но которые
 >>       желательно иметь в работоспособном состоянии),
 >> при условии минимальных изменений в текущей схеме.  
 > До настоящего момента у нас не был "сизифа-дистрибутива", а был только "сизиф для разработчико и желающих". Идеологи должны решить эту проблему до конца, прежде чем начнутся какие-то реальные шаги.

de-facto динамичный репозиторий пакетов востребован конечными
пользователями (в первую очередь этими пользователями являются
разработчики и тестеры, но далеко не только они).

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

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

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

Это равносильно попытке приучить людей тестировать на себе новые
лекарства. Daedalus это экспериментальный дистрибутив, а никак не
нестабильный.
 
 > > > 3. кто всё это будет поддерживать.
 > > Скрипты.
 > Не всё можно охватить скриптами.
 > Даже сейчас при наличии большого количества скриптов приходится иногда
 > incoming переводить на ручное управление.

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

Образование подпакетов легко, потому как работать система будет на уровне
src.rpm, и сколько там подпакетов ей будет всё равно. Переименование --
отлично сработает само, так как новый помещаемый в дистрибутив пакет (с
другим именем) должен конфликтовать со старым (насколько я помню), таким
образом, если у этих пакетов один и тот же мантейнер, то он может быть
вынесен скриптом автоматически.
 
 >> Для "заглушки" критерием может быть
 >>   время модификации, от которого прошло N часов (24?);
 >>     это даст эффект "админ должен быть в меру тормознутым" -- у
 >>     разработчиков будет фора в эти N часов на dist-upgrade и
 >>     использование пакета.
 > Как и кем определяются эти N часов. Если была бага на которую кто-то ещё
 > не напарывался - то не факт что через N часов она самоликвидируется.

За N часов её можно найти и повесить в BTS, и тогда пакет перемещён не
будет. Выбирать это самое N пока придётся опытным путём, потом можно
анализировать статистику.
 
-- 
С уважением, Денис

http://freesource.info


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

[devel] Re: Ï ÏÂÓÕÖÄÅÎÉÉ ÐÏÄÈÏÄÏ× Ë ÏÃÅÎËÅ ÎÁÄ£ÖÎÏÓÔÉ Sisyphus

[Andrey Khavryuchenko]

Денис,

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

 ДС> У меня есть. Надёжность это величина равная 1-<ненадёжность>, а
 ДС> ненадёжность, это вероятность поиметь геморрой после dist-upgrade в виде
 ДС> неработоспособного сервера (т.е. не выполняющего свои функции так же
 ДС> хорошо, как до апгрейда).

Ты не зюйд-зюйд-вест, ты операционное определение дай!  Как эту штуку
мерять для сферического пакета в вакууме?

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

Re: [devel] : ?? ?????????? ???????? ? ?????? ?????????? Sisyphus

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

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

On Wed, Nov 26, 2003 at 01:36:16AM +0200, Andrey Khavryuchenko wrote:

 >  ДС> У меня есть. Надёжность это величина равная 1-<ненадёжность>, а
 >  ДС> ненадёжность, это вероятность поиметь геморрой после dist-upgrade в виде
 >  ДС> неработоспособного сервера (т.е. не выполняющего свои функции так же
 >  ДС> хорошо, как до апгрейда).
 > Ты не зюйд-зюйд-вест, ты операционное определение дай!  Как эту штуку
 > мерять для сферического пакета в вакууме?

Как для сферического коня не знаю, а вот как для конкретного репозитория
-- знаю.

Точно измерить сложно, но можно. Количество ошибок, проявившихся при
обновлении * количество обновлений из сизифа. Так как не все люди
немедленно информируют об ошибках, и многие считает нормальным
необходимость поколдовать над apt-get чтобы он не снёс при dist-upgrade
всю систему, то получить это число можно только по весьма ограниченой
выборке.

Именно этот критерий оценки я считаю одним из важнейших в оценке качества.

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

http://dimline.ru/


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

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

[Andrey Orlov]

On Wednesday 26 November 2003 01:59, Денис Смирнов wrote:
> машине apt-get upgrade -y в cron'е, а при выполнении такого апдейта
> ручками на сервере масштаба хотя бы офиса быть увереным, что это не будет
> грозить увольнением.

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

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

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

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

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

On Wed, Nov 26, 2003 at 04:06:04AM +0300, Andrey Orlov wrote:

 >> машине apt-get upgrade -y в cron'е, а при выполнении такого апдейта
 >> ручками на сервере масштаба хотя бы офиса быть увереным, что это не будет
 >> грозить увольнением.
 > К сожалению для этого есть только один способ - нанять тестировщика и
 > платить ему зарплату. Тогда после выполнения апдейта уволят тестировщика,
 > а не вас. Других способов не существует, так как "взрыв всегда возможен".

По крайней мере можно его сделать настолько маловероятным, чтобы об этом
не беспокоиться (в случае сервера масштаба _офиса_, не предприятия или
корпорации).
 
-- 
С уважением, Денис

http://dimline.ru/

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

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

[Alexey Voinov]

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

Денис Смирнов wrote
> Конечная цель моего предложение -- довести надёжность Сизифа до такой
> степени, чтобы можно было себе позволить по крайней мере на своей личной
> машине apt-get upgrade -y в cron'е, а при выполнении такого апдейта
> ручками на сервере масштаба хотя бы офиса быть увереным, что это не будет
> грозить увольнением.
Зачем???? А работать тогда как? Сизиф нестабилен не потому, что его кто-то
таким специально делает, а потому, что там работа идёт непрерывная.
Если Сизиф станет "надёжным", то им перестанут пользоваться разработчики,
потому что им надо что-то делать, т.е. изменять. Если работу перенести в
другой репозитарий, то все те, кто пользуется сейчас Сизифом плавно
перетекут на  новый репозитарий, и начнут "наводить порядок" там.

BTW, Никогда не запускайте dist-upgrade из Сизифа на удалённой машине, особенно
если до неё очень долго ехать. 


-- 
Best Regards!           | "Sometimes you're the windshield
Alexey Voinov           |  Sometimes you're the bug..."
			|
voins@voins.program.ru
voins@altlinux.ru


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

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

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

On Wed, Nov 26, 2003 at 09:51:59AM +0300, Alexey Voinov wrote:

 >> Конечная цель моего предложение -- довести надёжность Сизифа до такой
 >> степени, чтобы можно было себе позволить по крайней мере на своей личной
 >> машине apt-get upgrade -y в cron'е, а при выполнении такого апдейта
 >> ручками на сервере масштаба хотя бы офиса быть увереным, что это не будет
 >> грозить увольнением.
 > Зачем???? А работать тогда как? Сизиф нестабилен не потому, что его кто-то
 > таким специально делает, а потому, что там работа идёт непрерывная.
 > Если Сизиф станет "надёжным", то им перестанут пользоваться разработчики,
 > потому что им надо что-то делать, т.е. изменять. Если работу перенести в
 > другой репозитарий, то все те, кто пользуется сейчас Сизифом плавно
 > перетекут на  новый репозитарий, и начнут "наводить порядок" там.

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

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

http://freesource.info

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

[Andrey Orlov]

On Wednesday 26 November 2003 11:11, Денис Смирнов wrote:
> Ты читал мои предыдущие постинги? Идея предлагаемая мною никак, повторяю
> _никак_ не повлияет на тех разработчиков, которым нравится работать в
> нынешнем стиле. _Вообще никак_. За исключением того, что в репозиторий для
> конечных пользователей их пакеты попадут не в день отправки в incoming, а
> через две недели.

Денис, на самом деле идея правильная. Мы ее даже перетирали на LinuxFest'е и
даже как-то всем вроде бы и понравилось. Так что я думаю, что вам это не доказывать надо,
а наглюкать какойнить скриптик и договорится с LDV & etc чбы его поюзать на реальном 
репозитории. Осмелюсь предположить, что LDV пойдет навстречу. А далее, как грится, 
практика покажет - вышло из этого чего или нет.

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

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

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

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

On Wed, Nov 26, 2003 at 02:02:50PM +0300, Andrey Orlov wrote:

 > Денис, на самом деле идея правильная. Мы ее даже перетирали на LinuxFest'е и
 > даже как-то всем вроде бы и понравилось. Так что я думаю, что вам это не доказывать надо,
 > а наглюкать какойнить скриптик и договорится с LDV & etc чбы его поюзать на реальном 
 > репозитории. Осмелюсь предположить, что LDV пойдет навстречу. А далее, как грится, 
 > практика покажет - вышло из этого чего или нет.

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

http://freesource.info


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

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

[Anton Farygin]

Денис Смирнов wrote:
> On Wed, Nov 26, 2003 at 09:51:59AM +0300, Alexey Voinov wrote:
> 
>  >> Конечная цель моего предложение -- довести надёжность Сизифа до такой
>  >> степени, чтобы можно было себе позволить по крайней мере на своей личной
>  >> машине apt-get upgrade -y в cron'е, а при выполнении такого апдейта
>  >> ручками на сервере масштаба хотя бы офиса быть увереным, что это не будет
>  >> грозить увольнением.
>  > Зачем???? А работать тогда как? Сизиф нестабилен не потому, что его кто-то
>  > таким специально делает, а потому, что там работа идёт непрерывная.
>  > Если Сизиф станет "надёжным", то им перестанут пользоваться разработчики,
>  > потому что им надо что-то делать, т.е. изменять. Если работу перенести в
>  > другой репозитарий, то все те, кто пользуется сейчас Сизифом плавно
>  > перетекут на  новый репозитарий, и начнут "наводить порядок" там.
> 
> Ты читал мои предыдущие постинги? Идея предлагаемая мною никак, повторяю
> _никак_ не повлияет на тех разработчиков, которым нравится работать в
> нынешнем стиле. _Вообще никак_. За исключением того, что в репозиторий для
> конечных пользователей их пакеты попадут не в день отправки в incoming, а
> через две недели.
> 

А работать то как при этом ???

Rgds,
Rider

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

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

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

On Wed, Nov 26, 2003 at 03:47:02PM +0300, Anton Farygin wrote:

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

Как обычно. Единственное изменение -- для тех, кто хочет работать по
старому, придётся пользоваться на classic, а testing репозиторием (который
будет содержать в себе ссылки на всё содержимое incoming + ссылки на
пакеты в classic). Больше никаких изменений с точки зрения разработчиков
не произойдёт.
 
-- 
С уважением, Денис

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:47:02PM +0300, Anton Farygin wrote:
> 
>  >> Ты читал мои предыдущие постинги? Идея предлагаемая мною никак, повторяю
>  >> _никак_ не повлияет на тех разработчиков, которым нравится работать в
>  >> нынешнем стиле. _Вообще никак_. За исключением того, что в репозиторий для
>  >> конечных пользователей их пакеты попадут не в день отправки в incoming, а
>  >> через две недели.
>  > А работать то как при этом ???
> 
> Как обычно. Единственное изменение -- для тех, кто хочет работать по
> старому, придётся пользоваться на classic, а testing репозиторием (который
> будет содержать в себе ссылки на всё содержимое incoming + ссылки на
> пакеты в classic). Больше никаких изменений с точки зрения разработчиков
> не произойдёт.

ссылки на incoming делать нельзя, ибо там как правило - только исходные 
пакеты.

Да и зачем тогда нужен другой репозитарий, если всем придетоя перейти на 
testing для того, что бы работать ???

Rgds,
Rider

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

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

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

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

 > >Как обычно. Единственное изменение -- для тех, кто хочет работать по
 > >старому, придётся пользоваться на classic, а testing репозиторием (который
 > >будет содержать в себе ссылки на всё содержимое incoming + ссылки на
 > >пакеты в classic). Больше никаких изменений с точки зрения разработчиков
 > >не произойдёт.
 > ссылки на incoming делать нельзя, ибо там как правило - только исходные 
 > пакеты.

Как говорят в ru.os.cmp -- отматывание за тебя треда и чтение вслух с
выражением его содержимого будет тебе стоить 50$/h.

Под incoming здесь подразумевается _репозиторий_ incoming (он же
RPMS.incoming).
 
 > Да и зачем тогда нужен другой репозитарий, если всем придетоя перейти на 
 > testing для того, что бы работать ???

Потому как далеко не всем.
 
-- 
С уважением, Денис

http://dimline.ru/

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

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

[Anton V. Boyarshinov]

Добрый день

On Wed, 26 Nov 2003 01:59:16 +0300 Денис Смирнов
 wrote:

> Конечная цель моего предложение -- довести надёжность Сизифа до
> такой степени, чтобы можно было себе позволить по крайней мере
> на своей личной машине apt-get upgrade -y в cron'е, а при
> выполнении такого апдейта ручками на сервере масштаба хотя бы
> офиса быть увереным, что это не будет грозить увольнением.

Насколько я понимаю, такая задача просто не ставится. Более того,
я не знаю ставится ли она, допустим, в Debian отличном от Stable.
Лично я никому не посоветую ставить на сколько-нибудь критичную
машину (тем более, недоступную физически) что либо кроном даже из
updates. Почему -- объяснять надо?

Антон.
-- 
mailto:boyarsh@mail.ru
mailto:boyarsh@ru.echo.fr
 10:04:00  up 3 days, 23:22,  8 users,  load average: 0.88, 0.20,
0.06

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

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

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

On Wed, Nov 26, 2003 at 10:11:35AM +0300, Anton V. Boyarshinov wrote:

 >> Конечная цель моего предложение -- довести надёжность Сизифа до
 >> такой степени, чтобы можно было себе позволить по крайней мере
 >> на своей личной машине apt-get upgrade -y в cron'е, а при
 >> выполнении такого апдейта ручками на сервере масштаба хотя бы
 >> офиса быть увереным, что это не будет грозить увольнением.
 > Насколько я понимаю, такая задача просто не ставится. Более того,
 > я не знаю ставится ли она, допустим, в Debian отличном от Stable.
 > Лично я никому не посоветую ставить на сколько-нибудь критичную
 > машину (тем более, недоступную физически) что либо кроном даже из
 > updates. Почему -- объяснять надо?

Антон, пожалуйста, перечитай четвёртую строчку цитирования. На _сервере_
я не собирался делать обновление по cron'у. Я собирался делать это на
своей личной машине. А на сервере я хочу, чтобы моё личное участие во
время обновления в большинстве случаев было сведено к последовательности:
 - apt-get dist-upgrade
 - посмотреть список пакетов
 - согласиться с ним
 - посмотреть на то, как обновление выполнилось без единой ошибки
 - проверить работоспособность всех сервисов.

То есть всё как обычно: надейся на лучшее, готовься к худшему. 

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

http://freesource.info


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

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

[Anton V. Boyarshinov]

On Wed, 26 Nov 2003 11:24:22 +0300 Денис Смирнов
 wrote:

> Антон, пожалуйста, перечитай четвёртую строчку цитирования. На
> _сервере_ я не собирался делать обновление по cron'у. 

Мои извинения.

-- 
mailto:boyarsh@mail.ru
mailto:boyarsh@ru.echo.fr
 13:56:01  up 4 days,  3:14,  8 users,  load average: 0.00, 0.03,
0.01

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

[Michael Shigorin]

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

On Wed, Nov 26, 2003 at 10:11:35AM +0300, Anton V. Boyarshinov wrote:
> Лично я никому не посоветую ставить на сколько-нибудь критичную
> машину (тем более, недоступную физически) что либо кроном даже
> из updates. Почему -- объяснять надо?

Не надо.  У меня все серверы так живут после дырки в ssh, когда я
был аккурат в поезде и потом без интернета.  Это тоже
сознательный выбор -- правда, и сделан он после ~годового
тестирования на отдельном и _некритичном_ сервере под ALM2.0 еще
(кто помнит -- это был tiny.linux.kiev.ua).

(тут еще один FR вспомнился -- чтоб можно было сказать "ДА,
перестартовывать sshd при обновлении, я подстраховался и у меня
висит волшебный telnetd с волшебного хоста")

(да: если я буду за такое отвечать перед заказчиком, а не
работодателем -- автообновление будет производиться из _моего_
репозитория, дополнительно тестируемого человеком, работающим с
ALT Linux Security Team -- шанс нештатных ситуаций в зависимости
от конфигурации остается все равно, но он и есть всегда)

-- 
 ---- 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

[Stanislav Ievlev]

On Wed, Nov 26, 2003 at 01:59:16AM +0300, Денис Смирнов wrote:
> On Tue, Nov 25, 2003 at 03:29:11PM +0300, Stanislav Ievlev wrote:
> 
>  >>> и что такое "надёжность sisyphus" по-определению.
>  >> Не знаю; не вводил.
>  > нет определения - значит нет правила перекочёвки пакетов из этого "pre-sisyphus" в sisyphus.
> 
> У меня есть. Надёжность это величина равная 1-<ненадёжность>, а
> ненадёжность, это вероятность поиметь геморрой после dist-upgrade в виде
> неработоспособного сервера (т.е. не выполняющего свои функции так же
> хорошо, как до апгрейда).
Ну допустим. Приходит в Сизиф новый bind10. Лежит себе в .incoming -
_небольшое_ количество разработчиков (не админов) тестируют его в своих
конфигурациях. По каким-то, до сих пор не сформулированным критериям,
решают, что он надёжный.
Пакет переезжает в Сизиф. админ X делает dist-upgrade по крону ... и
опаньки. Оказывается в его очень специфической настройке bind, bind10 не
работает. Просто разработчик не админ и не знал, что такие ситуации
существуют. Цель .incoming не выполнена.

Так что вопрос остаётся. Вы знаете критерий оценки надёжности пакета.
Пользуясь которым _разработчики_ могли бы признавать пакет годным для
перемещения. Ибо как понимаете если админ начинает смотреть .incoming, то
зачем он нужен. Проще не проводить синхронизацию рабочих серверов каждый
день. Как правило это и не нужно.
> 
> Конечная цель моего предложение -- довести надёжность Сизифа до такой
> степени, чтобы можно было себе позволить по крайней мере на своей личной
> машине apt-get upgrade -y в cron'е, а при выполнении такого апдейта
> ручками на сервере масштаба хотя бы офиса быть увереным, что это не будет
> грозить увольнением.
>  
>  >> * .classic, который и применяется
>  >>     _пользователями_ Sisyphus.
>  >>       (в т.ч. и разработчиками Sisyphus на хостах, которые можно
>  >>       себе позволить / требуется держать на Sisyphus, но которые
>  >>       желательно иметь в работоспособном состоянии),
>  >> при условии минимальных изменений в текущей схеме.  
>  > До настоящего момента у нас не был "сизифа-дистрибутива", а был только "сизиф для разработчико и желающих". Идеологи должны решить эту проблему до конца, прежде чем начнутся какие-то реальные шаги.
> 
> de-facto динамичный репозиторий пакетов востребован конечными
> пользователями (в первую очередь этими пользователями являются
> разработчики и тестеры, но далеко не только они).
> 
> Поэтому можно либо закрывать глаза на такое его использование, либо
> искать принимать меры, которые позволят убить сразу уйму зайцев без
> негативных последствий для тех, кто привык и кому нравится нынешний
> механизм разработки.
Как бы при таком массовом убийстве зайцев и себя не задеть. Ибо как
известно чтобы убить разбегающихся зайцев одним махом нужна бомба.
>  
>  > Как показывает практика что пакет может лежать в daedalus. Большиство
>  > знает что там unstable и не пользуется им. Когда пакет приходит из
>  > daedalus в Cизиф там обнаруживаются проблемы.
> 
> Это всё потому, что даже Сизиф не является более-менее надёжным
> дистрибутивом. Daedalus в этом смысле рассматривается как "лучше я сразу
> сделаю rm -rf /, результат тот же, а работы меньше".
> 
> Я же предлагаю отслоить от Сизифа надёжную его часть, и позволить людям,
> которым это необходимо, использовать именно его.
Вот тут мы дошли до сути проблемы. Сизиф это _не дистрибутив_, а репозитарий.
Давайте не будем переворачивать всё с ног на голову и переформулируем
проблему так. Нужен способ полуавтоматического выпуска дистрибутивов
скажем раз в месяц. Мы готовы к этому? Я думаю, что при текущем состоянии
инфраструктуры нет. Сначала нужен реальный _репозитарий_ a-la sandman.
Почему sandman-репозитарий не внедрён до сих пор, хотя разговоры между
Сашей и Димой были уже неоднократно, надо ,как я понимаю, спрашивать у
них.
>  
>  > Так в где гарантии что на пакет из incoming хоть кто-нибудь будет смотреть. 
>  > Для начала надо приучить _разработчиков_ пользоваться deadalus иначе
>  > просто будет добавлен новый совершенно неиспользуемый репозитарий.
> 
> Это равносильно попытке приучить людей тестировать на себе новые
> лекарства. Daedalus это экспериментальный дистрибутив, а никак не
> нестабильный.
Опять та же принципиальная ошибка. Daedalus - это не дистрибутив, а
репозитарий.
>  
>  > > > 3. кто всё это будет поддерживать.
>  > > Скрипты.
>  > Не всё можно охватить скриптами.
>  > Даже сейчас при наличии большого количества скриптов приходится иногда
>  > incoming переводить на ручное управление.
> 
> Все те изменения, которые я предложил здесь, отлично скриптуемы.
Только если есть критерий. Его пока нет.
>  
>  > Нет никаких гарантий, что нетривиальные замены библиотек,
>  > преименование/образование подпакетов можно будет полностью охватить скриптами.
> 
> Образование подпакетов легко, потому как работать система будет на уровне
> src.rpm, и сколько там подпакетов ей будет всё равно. Переименование --
> отлично сработает само, так как новый помещаемый в дистрибутив пакет (с
> другим именем) должен конфликтовать со старым (насколько я помню), таким
> образом, если у этих пакетов один и тот же мантейнер, то он может быть
> вынесен скриптом автоматически.
Ну допустим src.rpm. Тогда, проверки придётся делать по 45000 пакетам при
добавлении 10 пакетов. Каждое добавление в Сизиф будет занимать порядка 20
минут. Это не реально.
>  
>  >> Для "заглушки" критерием может быть
>  >>   время модификации, от которого прошло N часов (24?);
>  >>     это даст эффект "админ должен быть в меру тормознутым" -- у
>  >>     разработчиков будет фора в эти N часов на dist-upgrade и
>  >>     использование пакета.
>  > Как и кем определяются эти N часов. Если была бага на которую кто-то ещё
>  > не напарывался - то не факт что через N часов она самоликвидируется.
> 
> За N часов её можно найти и повесить в BTS, и тогда пакет перемещён не
> будет. Выбирать это самое N пока придётся опытным путём, потом можно
> анализировать статистику.
Флаг в руки ;)
Пока ещё никто такого делать не научился  (определять среднестатистическое
обнаружение баги) ;)
Было бы так. Не находили бы баги в 2.2 спустя несколько лет после выхода 2.4?

Если за N принимать среднее - то будет срабатывать пример с bind10.
>  
> -- 
> С уважением, Денис
> 
> http://freesource.info
> 



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

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

[Anton V. Boyarshinov]

On Wed, 26 Nov 2003 11:27:52 +0300 Stanislav Ievlev
 wrote:

> > У меня есть. Надёжность это величина равная 1-<ненадёжность>,
> > а ненадёжность, это вероятность поиметь геморрой после
> > dist-upgrade в виде неработоспособного сервера (т.е. не
> > выполняющего свои функции так же хорошо, как до апгрейда).

> Ну допустим. Приходит в Сизиф новый bind10. Лежит себе в
> .incoming -_небольшое_ количество разработчиков (не админов)
> тестируют его в своих конфигурациях. По каким-то, до сих пор не
> сформулированным критериям, решают, что он надёжный.
> Пакет переезжает в Сизиф. админ X делает dist-upgrade по крону
> ... и опаньки. Оказывается в его очень специфической настройке
> bind, bind10 не работает. 

И тут начинается самое интересное. Особенно если он не совсем не
работает, а работает не совсем так, как надо. Поскольку
обновление было сделано кроном, админ о нём узнает только от
разъярённых пользователей, причём не факт, что в тот же день. И
когда выяснится, что в результате всего этого безобразия фирма
потеряла X или даже Y денег, вылетит такой админ с неофициальной
формулировкой: "за абсолютную безответственность".

Антон
-- 
mailto:boyarsh@mail.ru
mailto:boyarsh@ru.echo.fr
 11:40:00  up 4 days, 58 min,  8 users,  load average: 0.01,
0.02, 0.00

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

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

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

On Wed, Nov 26, 2003 at 11:46:27AM +0300, Anton V. Boyarshinov wrote:

 > И тут начинается самое интересное. Особенно если он не совсем не
 > работает, а работает не совсем так, как надо. Поскольку
 > обновление было сделано кроном, админ о нём узнает только от
 > разъярённых пользователей, причём не факт, что в тот же день. И
 > когда выяснится, что в результате всего этого безобразия фирма
 > потеряла X или даже Y денег, вылетит такой админ с неофициальной
 > формулировкой: "за абсолютную безответственность".

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

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

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

http://freesource.info


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

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

[Anton Farygin]

Денис Смирнов wrote:
> On Wed, Nov 26, 2003 at 11:46:27AM +0300, Anton V. Boyarshinov wrote:
> 
>  > И тут начинается самое интересное. Особенно если он не совсем не
>  > работает, а работает не совсем так, как надо. Поскольку
>  > обновление было сделано кроном, админ о нём узнает только от
>  > разъярённых пользователей, причём не факт, что в тот же день. И
>  > когда выяснится, что в результате всего этого безобразия фирма
>  > потеряла X или даже Y денег, вылетит такой админ с неофициальной
>  > формулировкой: "за абсолютную безответственность".
> 
> Абсолютно согласен, ибо обновление на автомате сервера, который
> используется в обслуживании клиентов это действительно "абсолютная
> безответственность". Такое обновление на сервере, который является чем-то
> вроде внутриофисного файл-сервера, если это компания "рога и копыта" и
> денег на своего админа нет, и они предпочитают приглашать удалённого
> вполне разумно (правда не из Сизифа, а именно из updates).
> 
> А вот на персональной машине разработчика, который как всякий умный
> разработчик не держит на своей машине никаких данных, которые не лежали бы
> на соседнем сервере в CVS, который ежедневно архивируется (а в идеале и
> кассеты с этого CVS периодически уносятся кем-нибудь к себе домой, как это
> делается в одной из фирм, где я настраивал файл-сервер), если это
> разработчик активно участвует в разработке дистрибутива -- можно и нужно
> так обновляться. И на тестовых машинах (на которых программисты результаты
> своего труда гоняют) такое обновление делать весьма полезно.

Ну и обновляемся мы автоматом.. из Sisyphus.. ну и что ?

Тестим, рапортуем...

А при этом сервера работают на Master 2.2 - и без проблем.

да, вот еще одна не совсем тривиальная задачка для скриптов:

допустим в тестовом репозитарии есть пакет A, который нужен для сборки и 
функционирования пакетов B, C

А пакет C - нужен для сборки пакета G, но может быть собран только с 
пакетом A.

А пакет G - для функционирования пакета E, но может быть собран только с 
пакетом G.

Ну и пакет F - для него нужно иметь собранный пакет C, но он может быть 
собран только с пакетом A.

И вот допустим что все они вместе выложены (c интервалом в один день).

Получаем, что:
пакеты должны быть перемещены при отстуствии ошибок :
dateA=A+14
dateB=B+14 (или A+15)
и т.д.

Но тут возникает маленькая неприятность. В день C+11 нашли ошибку в 
пакете C.


Вопрос: какие пакеты и когда нужно выкладывать.

Ответ желательно в виде скрипта.

Rgds,
Rider

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

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

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

On Wed, Nov 26, 2003 at 03:57:02PM +0300, Anton Farygin wrote:

 > да, вот еще одна не совсем тривиальная задачка для скриптов:
 > допустим в тестовом репозитарии есть пакет A, который нужен для сборки и 
 > функционирования пакетов B, C
 > А пакет C - нужен для сборки пакета G, но может быть собран только с 
 > пакетом A.
 > А пакет G - для функционирования пакета E, но может быть собран только с 
 > пакетом G.
 > Ну и пакет F - для него нужно иметь собранный пакет C, но он может быть 
 > собран только с пакетом A.
 > И вот допустим что все они вместе выложены (c интервалом в один день).
 > Получаем, что:
 > пакеты должны быть перемещены при отстуствии ошибок :
 > dateA=A+14
 > dateB=B+14 (или A+15)
 > и т.д.
 > Но тут возникает маленькая неприятность. В день C+11 нашли ошибку в 
 > пакете C.
 > Вопрос: какие пакеты и когда нужно выкладывать.
 > Ответ желательно в виде скрипта.

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

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

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:57:02PM +0300, Anton Farygin wrote:
> 
>  > да, вот еще одна не совсем тривиальная задачка для скриптов:
>  > допустим в тестовом репозитарии есть пакет A, который нужен для сборки и 
>  > функционирования пакетов B, C
>  > А пакет C - нужен для сборки пакета G, но может быть собран только с 
>  > пакетом A.
>  > А пакет G - для функционирования пакета E, но может быть собран только с 
>  > пакетом G.
>  > Ну и пакет F - для него нужно иметь собранный пакет C, но он может быть 
>  > собран только с пакетом A.
>  > И вот допустим что все они вместе выложены (c интервалом в один день).
>  > Получаем, что:
>  > пакеты должны быть перемещены при отстуствии ошибок :
>  > dateA=A+14
>  > dateB=B+14 (или A+15)
>  > и т.д.
>  > Но тут возникает маленькая неприятность. В день C+11 нашли ошибку в 
>  > пакете C.
>  > Вопрос: какие пакеты и когда нужно выкладывать.
>  > Ответ желательно в виде скрипта.
> 
> Скрипт я напишу позже, когда всё обдумаю. Если кратко -- для каждого
> пакета определяется дата, когда его теоретически можно переносить в
> стабильный репозиторий. Реально перенос делается тогда, и только тогда,
> когда это возможно без нарушения зависимостей.

Вот.. опять пришли к зависимостям.

А как вы собираетесь высчитывать зависимости пакетов ???

Rgds,
Rider

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

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

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

On Wed, Nov 26, 2003 at 05:41:54PM +0300, Anton Farygin wrote:

 > Вот.. опять пришли к зависимостям.
 > А как вы собираетесь высчитывать зависимости пакетов ???

У меня это в голове _почти_ сложилось. Как сложится совсем, оформлю в виде
кода.
 
-- 
С уважением, Денис

http://dimline.ru/


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

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

[Anton Farygin]

Денис Смирнов wrote:
> On Wed, Nov 26, 2003 at 05:41:54PM +0300, Anton Farygin wrote:
> 
>  > Вот.. опять пришли к зависимостям.
>  > А как вы собираетесь высчитывать зависимости пакетов ???
> 
> У меня это в голове _почти_ сложилось. Как сложится совсем, оформлю в виде
> кода.

Отлично. Договорились.

Rgds,
Rider

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

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

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

On Wed, Nov 26, 2003 at 11:27:52AM +0300, Stanislav Ievlev wrote:

 > Ну допустим. Приходит в Сизиф новый bind10. Лежит себе в .incoming -
 > _небольшое_ количество разработчиков (не админов) тестируют его в своих
 > конфигурациях. По каким-то, до сих пор не сформулированным критериям,
 > решают, что он надёжный.
 > Пакет переезжает в Сизиф. админ X делает dist-upgrade по крону ... и
 > опаньки. Оказывается в его очень специфической настройке bind, bind10 не
 > работает. Просто разработчик не админ и не знал, что такие ситуации
 > существуют. Цель .incoming не выполнена.

Цель -- _увеличить надёжность_. То есть _уменьшить вероятность сбоя_, а не
свести её к нулю (что, как я уже говорил, принципиально невозможно при
нынешней практике писать софт на си).
 
 > Так что вопрос остаётся. Вы знаете критерий оценки надёжности пакета.
 > Пользуясь которым _разработчики_ могли бы признавать пакет годным для
 > перемещения. Ибо как понимаете если админ начинает смотреть .incoming, то
 > зачем он нужен. Проще не проводить синхронизацию рабочих серверов каждый
 > день. Как правило это и не нужно.

Предположим в данный конкретный день мне надо сделать обновление. А там
как раз сейчас валяется какой-нибудь пакет, которому 2 дня назад уже
выставили в BTS block-bug сборки. И что тогда делать? Ждать пока баг
закроют?

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

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

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

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

Критерий -- время. Речь идёт о том, чтобы разделить Сизиф на две части --
одна содержит уже протестированые пакеты (временем и людьми), другая
пакеты только что помещённые. Кто-то прописывает в apt только первый
репозиторий, кто-то оба.
 
 > >  > Нет никаких гарантий, что нетривиальные замены библиотек,
 > >  > преименование/образование подпакетов можно будет полностью охватить скриптами.
 > > Образование подпакетов легко, потому как работать система будет на уровне
 > > src.rpm, и сколько там подпакетов ей будет всё равно. Переименование --
 > > отлично сработает само, так как новый помещаемый в дистрибутив пакет (с
 > > другим именем) должен конфликтовать со старым (насколько я помню), таким
 > > образом, если у этих пакетов один и тот же мантейнер, то он может быть
 > > вынесен скриптом автоматически.
 > Ну допустим src.rpm. Тогда, проверки придётся делать по 45000 пакетам при
 > добавлении 10 пакетов. Каждое добавление в Сизиф будет занимать порядка 20
 > минут. Это не реально.

Я не понял, какие проверки нужно делать по 45000 пакетам.
 
 > >  >> Для "заглушки" критерием может быть
 > >  >>   время модификации, от которого прошло N часов (24?);
 > >  >>     это даст эффект "админ должен быть в меру тормознутым" -- у
 > >  >>     разработчиков будет фора в эти N часов на dist-upgrade и
 > >  >>     использование пакета.
 > >  > Как и кем определяются эти N часов. Если была бага на которую кто-то ещё
 > >  > не напарывался - то не факт что через N часов она самоликвидируется.
 > > За N часов её можно найти и повесить в BTS, и тогда пакет перемещён не
 > > будет. Выбирать это самое N пока придётся опытным путём, потом можно
 > > анализировать статистику.
 > Флаг в руки ;)
 > Пока ещё никто такого делать не научился  (определять среднестатистическое
 > обнаружение баги) ;)
 > Было бы так. Не находили бы баги в 2.2 спустя несколько лет после выхода 2.4?
 > Если за N принимать среднее - то будет срабатывать пример с bind10.

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

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

http://freesource.info


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

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

[Stanislav Ievlev]

On Wed, Nov 26, 2003 at 02:15:14PM +0300, Денис Смирнов wrote:
>  > решают, что он надёжный.
>  > Пакет переезжает в Сизиф. админ X делает dist-upgrade по крону ... и
>  > опаньки. Оказывается в его очень специфической настройке bind, bind10 не
>  > работает. Просто разработчик не админ и не знал, что такие ситуации
>  > существуют. Цель .incoming не выполнена.
> 
> Цель -- _увеличить надёжность_. То есть _уменьшить вероятность сбоя_, а не
> свести её к нулю (что, как я уже говорил, принципиально невозможно при
> нынешней практике писать софт на си).
ради любопытства: причём здесь си.

Дабы минимизировать объём теста, пропущу то что далее.
Итак, мне понятна мысль  - сделать два Сизифа с "запаздыванием по времени".
Но до сих пор не понятно почему для этого нельзя использовать связку
Сизиф-Дедал. По моему разумению результат от введения ещё одного Сизифа
сопоставим (при значительно меньших затратах) от более эффективного
использования Дедала.
Ключевой момент в моей	позиции - мы получим ещё один Дедал ибо люди (будь
то пользователи или разработчики) будут сознательно или несознательно
избегать использования пакетов, объявленных как нестабильные. Зачем нам
ещё одна прослойка которая будет использоваться на 30%.

Если уж нужен какой "отстойник" пакетов - то для этих целей можно
использовать уже существующий incoming: он доступен на чтение всем
разработчикам, а забирать в Сизиф можно только пакеты которые отлежались
там например 3 дня. Результат будет одинаковый.

Много пакетов придётся проверять в скрипте: например может появиться
принципиально новый пакет который просто обсолетит другой пакет в Сизифе.

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

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

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

On Wed, Nov 26, 2003 at 03:15:42PM +0300, Stanislav Ievlev wrote:

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

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

Эти два факта (отсутствие строк и присутствие адресной арифметики)
превращают этот язык в диверсию отраслевого масштаба.

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

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

Дальнейшие разговоры на эту тему предлагаю провести в talk-room, так как
тема слишком провокативная.

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

Дело в том, что в Дедал идут пакеты, которые изначально подразумевается
что недостаточно готовы, чтобы отправиться конечному пользователю. В Сизиф
идут пакеты, о которых мантейнер по крайней мере надеется, что
пользователь может их использовать.
 
 > Ключевой момент в моей позиции - мы получим ещё один Дедал ибо люди (будь
 > то пользователи или разработчики) будут сознательно или несознательно
 > избегать использования пакетов, объявленных как нестабильные. Зачем нам
 > ещё одна прослойка которая будет использоваться на 30%.

Я предлагаю создать не ещё одну тестовую прослойку, а наоборот, отслоить
более надёжную версию Сизифа. 
 
 > Если уж нужен какой "отстойник" пакетов - то для этих целей можно
 > использовать уже существующий incoming: он доступен на чтение всем
 > разработчикам, а забирать в Сизиф можно только пакеты которые отлежались
 > там например 3 дня. Результат будет одинаковый.

Это преувеличение.

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

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

Кстати, как сейчас это решается технически? incominger делает это ручками?

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

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:15:42PM +0300, Stanislav Ievlev wrote:
> 
>  >> Цель -- _увеличить надёжность_. То есть _уменьшить вероятность сбоя_, а не
>  >> свести её к нулю (что, как я уже говорил, принципиально невозможно при
>  >> нынешней практике писать софт на си).
>  > ради любопытства: причём здесь си.
> 

<skip>

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

Да, и больше эту тему не стоит здесь поднимать.

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

ну почему-же ???
Я вот собираюсь в ближайшее время выложить несколько пакетов, которые я 
точно знаю, что пользователь использовать не может...

Зато может использовать разработчик. ;-)

Речь идет про библиотеки и ASL компилятор iasl.

>  
>  > Ключевой момент в моей позиции - мы получим ещё один Дедал ибо люди (будь
>  > то пользователи или разработчики) будут сознательно или несознательно
>  > избегать использования пакетов, объявленных как нестабильные. Зачем нам
>  > ещё одна прослойка которая будет использоваться на 30%.
> 
> Я предлагаю создать не ещё одну тестовую прослойку, а наоборот, отслоить
> более надёжную версию Сизифа. 

А что считать надежной частью Sisyphus ???

Вот еще один пример:

есть некий очень надежный пакет (к примеру) libqt, который собирается с 
совсем ненадежной библиотекой от MySQL.

Как будет выглядеть отслаиваение MySQL от QT ?

Или еще: вчера был супер-надежный пакет mysql-3.x, а сегодня собрали 
некий понетциально надежный, но безусловно глючный пакет mysql-4.x ...

И что делать ?


>  
>  > Если уж нужен какой "отстойник" пакетов - то для этих целей можно
>  > использовать уже существующий incoming: он доступен на чтение всем
>  > разработчикам, а забирать в Сизиф можно только пакеты которые отлежались
>  > там например 3 дня. Результат будет одинаковый.
> 
> Это преувеличение.
> 
>  > Много пакетов придётся проверять в скрипте: например может появиться
>  > принципиально новый пакет который просто обсолетит другой пакет в Сизифе.
> 
> Ну и что? Если мантейнер один и тот же, то как только принимается решение
> о том, что пакет может быть перемещён в Сизиф, то пакет из Сизифа
> удаляется.
> 
> Кстати, как сейчас это решается технически? incominger делает это ручками?

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

Rgds,
Rider

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

[Alexey I. Froloff]

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

* Anton Farygin <rider@altlinux.com> [031126 17:28]:
> есть некий очень надежный пакет (к примеру) libqt, который собирается с 
> совсем ненадежной библиотекой от MySQL.
Надёжность пакета не может быть больше надёжности самого
ненадёжного из требуемых им пакетов.  Так мне кажется...

-- 
Regards, Sir Raorn.
-------------------
Ждать можно бесконечно долго: похоже, что вы единственный, у кого
наблюдаются проблемы такого рода.
		-- ldv in sisyphus@

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

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

[Anton Farygin]

Alexey I. Froloff wrote:
> * Anton Farygin <rider@altlinux.com> [031126 17:28]:
> 
>>есть некий очень надежный пакет (к примеру) libqt, который собирается с 
>>совсем ненадежной библиотекой от MySQL.
> 
> Надёжность пакета не может быть больше надёжности самого
> ненадёжного из требуемых им пакетов.  Так мне кажется...

Да, но при этом libMySQL реализует примерно 0.5% функциональности libqt ;-)

Т.е. - получается что 0.5% libQT потенциально ненадежен на основании 
каких-то сторонних выводов...

при этом цифру в 0.5% я вывел на основании сам и естественно ошибся.. в 
какую сторону - неизвестно ;-)


Rgds,
Rider

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

[Andrey Orlov]

On Wednesday 26 November 2003 17:34, Alexey I. Froloff wrote:
> Надёжность пакета не может быть больше надёжности самого
> ненадёжного из требуемых им пакетов.  Так мне кажется...

Неправильно кажется. Попробуйте вероятность падения посчитать ;),
если программный комплекс состоит из N программ, каждая из которых
падает с в вероятностью p[n] на потоке событий, причем событие обрабатывается
данным пакетом с вероятностью pe[n]  и т.д. и т.п. 

Ну или если считать влом, то обратите внимание
pe[c] = 0, p[c] = 1, когда вроде бы самая ненадежная часть "ваще не надежна"
а комплекс, как ни бывало шуршит. 

Кстати, реальная модель существенно более сложная.

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

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

[Anton Farygin]

Andrey Orlov wrote:
> On Wednesday 26 November 2003 17:34, Alexey I. Froloff wrote:
> 
>>Надёжность пакета не может быть больше надёжности самого
>>ненадёжного из требуемых им пакетов.  Так мне кажется...
> 
> 
> Неправильно кажется. Попробуйте вероятность падения посчитать ;),
> если программный комплекс состоит из N программ, каждая из которых
> падает с в вероятностью p[n] на потоке событий, причем событие обрабатывается
> данным пакетом с вероятностью pe[n]  и т.д. и т.п. 
> 
> Ну или если считать влом, то обратите внимание
> pe[c] = 0, p[c] = 1, когда вроде бы самая ненадежная часть "ваще не надежна"
> а комплекс, как ни бывало шуршит. 
> 
> Кстати, реальная модель существенно более сложная.
> 

Примерно к тому я и веду - без математической модели получить 
стабильность путем простого увеличения количества репозитариев - 
невозможно. Здесь очень много влияющих факторов и пока лучше работать по 
уже отработанной схеме.

Rgds,
Rider

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

[Andrey Orlov]

On Wednesday 26 November 2003 19:24, Anton Farygin wrote:
> Примерно к тому я и веду - без математической модели получить
> стабильность путем простого увеличения количества репозитариев -
> невозможно. Здесь очень много влияющих факторов и пока лучше работать по

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

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

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

[Anton Farygin]

Andrey Orlov wrote:
> On Wednesday 26 November 2003 19:24, Anton Farygin wrote:
> 
>>Примерно к тому я и веду - без математической модели получить
>>стабильность путем простого увеличения количества репозитариев -
>>невозможно. Здесь очень много влияющих факторов и пока лучше работать по
> 
> 
> Я веду к тому, что парень имеет право попробовать. Все эти теории без практики
> ничего не стоят. Так как на самом деле речь идет не о надежности, а об удобстве
> некоторых конкретных людей. Т.о. вопрос сводится только к тому, что нужно чбы 
> попробовать & протестировать.
> 

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

Протестировать - это если только Стас лично захочет прогнать скрипты 
через стандартный incoming. Тут я уж ничем помочь не смогу. ;-(

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

Rgds,
Rider

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

[Sergey V Turchin]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 373 bytes --]

В сообщении от 26 Ноябрь 2003 19:42 Anton Farygin написал(a):

<skip/>

> дополнительных репозитариев, а самое главное - не учитывает
> наличие ошибок в bugzilla.
Стабильного репозитория не будет ;-)
http://bugzilla.altlinux.ru/show_bug.cgi?id=3272

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

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

[devel] bugzilla.altlinux.ru was: об обсужденииподходов к оценке надёжности Sisyphus

[Denis Ovsienko]

>> дополнительных репозитариев, а самое главное - не учитывает
>> наличие ошибок в bugzilla.
>Стабильного репозитория не будет ;-)
>http://bugzilla.altlinux.ru/show_bug.cgi?id=3272

Господа! Раньше мы плакали, что мантис не даёт нормально работать. Из этих
block-bug'ов около трети (минимум) просто не обновлены. А сколько таких
багов не-block? Пожалуйста посмотрите на свои баги и хотя бы позакрывайте
разрешённые, тогда мы сможем более предметно говорить о чём бы то ни было,
касающегося "стабильности". Количество _открытых_ корректных записей ---
вот вам критерий оценки. Это же ненамного сложнее, чем лить воду в devel@!

--
    DO4-UANIC

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

[Michael Shigorin]

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

On Wed, Nov 26, 2003 at 07:42:22PM +0300, Anton Farygin wrote:
> Протестировать - это если только Стас лично захочет прогнать
> скрипты через стандартный incoming. Тут я уж ничем помочь не
> смогу. ;-(

Давайте так...  Есть люди, имеющие доступ на ftp.  Можно провести
эксперимент с ними, создав компоненту .incoming и декларировав,
что в e.g. 3 часа ночи по Москве она индексируется (хэши apt).

Наверное, grace time можно выставить в пару недель -- если что-то
долежит от начала до конца, будет интересно на него посмотреть.
Перекладывать -- ну пусть руками, как из incoming/.

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

Вот.  Но "мамонта надо есть постепенно" (c) один знакомый,
некогда работавщий в mylinux ;-)

-- 
 ---- 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

[Stanislav Ievlev]

On Thu, Nov 27, 2003 at 04:34:00PM +0200, Michael Shigorin wrote:
> On Wed, Nov 26, 2003 at 07:42:22PM +0300, Anton Farygin wrote:
> > Протестировать - это если только Стас лично захочет прогнать
> > скрипты через стандартный incoming. Тут я уж ничем помочь не
> > смогу. ;-(
> 
> Давайте так...  Есть люди, имеющие доступ на ftp.  Можно провести
> эксперимент с ними, создав компоненту .incoming и декларировав,
> что в e.g. 3 часа ночи по Москве она индексируется (хэши apt).
> 
> Наверное, grace time можно выставить в пару недель -- если что-то
> долежит от начала до конца, будет интересно на него посмотреть.
> Перекладывать -- ну пусть руками, как из incoming/.
Пусть пока проводится эксперимент где угодно. Потом посмотрим.
> 
> > Хотя - я могу заюзать скрипты для сборки тестовых
> > дистрибутивов, ибо по функциональности они все равно близки к
> > тому, что есть сейчас. Но то, что есть сейчас - не учитывает
> > наличия дополнительных репозитариев, а самое главное - не
> > учитывает наличие ошибок в bugzilla.
> 
> Вот.  Но "мамонта надо есть постепенно" (c) один знакомый,
> некогда работавщий в mylinux ;-)
> 
> -- 
>  ---- WBR, Michael Shigorin <mike@altlinux.ru>
>   ------ Linux.Kiev http://www.linux.kiev.ua/



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

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

[Michael Shigorin]

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

On Fri, Nov 28, 2003 at 02:48:36PM +0300, Stanislav Ievlev wrote:
> > Давайте так...  Есть люди, имеющие доступ на ftp.  Можно провести
> > эксперимент с ними, создав компоненту .incoming и декларировав,
> > что в e.g. 3 часа ночи по Москве она индексируется (хэши apt).
> Пусть пока проводится эксперимент где угодно. Потом посмотрим.

"Где угодно" в другом месте?  Так на сейчас это бессмысленно
делать где-то кроме ftp.altlinux.org.

Или не понял реплики.

-- 
 ---- 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

[Stanislav Ievlev]

On Fri, Nov 28, 2003 at 11:09:58PM +0200, Michael Shigorin wrote:
> On Fri, Nov 28, 2003 at 02:48:36PM +0300, Stanislav Ievlev wrote:
> > > Давайте так...  Есть люди, имеющие доступ на ftp.  Можно провести
> > > эксперимент с ними, создав компоненту .incoming и декларировав,
> > > что в e.g. 3 часа ночи по Москве она индексируется (хэши apt).
> > Пусть пока проводится эксперимент где угодно. Потом посмотрим.
> 
> "Где угодно" в другом месте?  Так на сейчас это бессмысленно
> делать где-то кроме ftp.altlinux.org.
> 
> Или не понял реплики.
Теперь я не понял ;)
В другом значит в любом другом. Можно и на people, но не внутри репозитария.
> 
> -- 
>  ---- WBR, Michael Shigorin <mike@altlinux.ru>
>   ------ Linux.Kiev http://www.linux.kiev.ua/



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

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

[Michael Shigorin]

On Mon, Dec 01, 2003 at 12:29:49PM +0300, Stanislav Ievlev wrote:
> > > > Давайте так...  Есть люди, имеющие доступ на ftp.  Можно
> > > > провести эксперимент с ними, создав компоненту .incoming
> > > > и декларировав, что в e.g. 3 часа ночи по Москве она
> > > > индексируется (хэши apt).
> > > Пусть пока проводится эксперимент где угодно. Потом посмотрим.
> > "Где угодно" в другом месте?  Так на сейчас это бессмысленно
> > делать где-то кроме ftp.altlinux.org.
> > Или не понял реплики.
> Теперь я не понял ;)
> В другом значит в любом другом. Можно и на people, но не внутри
> репозитария.

Это бессмысленно.  Почему -- см. описание предложения.

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

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

[Stanislav Ievlev]

On Wed, Nov 26, 2003 at 03:48:14PM +0300, Денис Смирнов wrote:
> тема слишком провокативная.
> 
>  > Итак, мне понятна мысль  - сделать два Сизифа с "запаздыванием по времени".
>  > Но до сих пор не понятно почему для этого нельзя использовать связку
>  > Сизиф-Дедал. По моему разумению результат от введения ещё одного Сизифа
>  > сопоставим (при значительно меньших затратах) от более эффективного
>  > использования Дедала.
> 
> Дело в том, что в Дедал идут пакеты, которые изначально подразумевается
> что недостаточно готовы, чтобы отправиться конечному пользователю. В Сизиф
> идут пакеты, о которых мантейнер по крайней мере надеется, что
> пользователь может их использовать.
Правильно. В новый репозитарий будут посылаться пакеты стабильность
которых мантейнер также не может гарантировать. Так какая разница?
Как пользователю мне не хочется пользоваться как "совсем" так и "полу"
стабильными пакетами. Я имею право хотеть не ставить на своей машине
нестабильные binutils => они не будут оттестированы.

Попробуйте убедить меня что хотя бы половина devel@+sisyphus@ "пересядет" на unstable.
Если этого не произойдёт, то нет смысла тратить дисковое пространство на серверах. Ибо всё-равно реальное тестирование, а именно это прежде всего необходимо для стабильности, будет мизерным.
Любое решение должно быть обосновано не только идеологически (теоретически мысль-то
хорошая не спорю), но и экономически.

Я понимаю Ваше желание получить "дистрибутив". Но, это не даёт той
отдачи, из-за которой можно было бы согласиться потратить ещё место на серверах.
>  
>  > Ключевой момент в моей позиции - мы получим ещё один Дедал ибо люди (будь
>  > то пользователи или разработчики) будут сознательно или несознательно
>  > избегать использования пакетов, объявленных как нестабильные. Зачем нам
>  > ещё одна прослойка которая будет использоваться на 30%.
> 
> Я предлагаю создать не ещё одну тестовую прослойку, а наоборот, отслоить
> более надёжную версию Сизифа. 
Дык чем она надёжней-то будет??
>  
>  > Если уж нужен какой "отстойник" пакетов - то для этих целей можно
>  > использовать уже существующий incoming: он доступен на чтение всем
>  > разработчикам, а забирать в Сизиф можно только пакеты которые отлежались
>  > там например 3 дня. Результат будет одинаковый.
> 
> Это преувеличение.
> 
>  > Много пакетов придётся проверять в скрипте: например может появиться
>  > принципиально новый пакет который просто обсолетит другой пакет в Сизифе.
> 
> Ну и что? Если мантейнер один и тот же, то как только принимается решение
> о том, что пакет может быть перемещён в Сизиф, то пакет из Сизифа
> удаляется.
Да, так сейчас и делается, но это _ручная_ работа.
> 
> Кстати, как сейчас это решается технически? incominger делает это ручками?
Поскольку поток пакетов достаточно большой, а изменения подчас очень
непростые, то в большинстве случаев гораздо проще удалить пакет вручную.
> 
> -- 
> С уважением, Денис
> 
> http://freesource.info
> 



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

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

[Michael Shigorin]

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

On Wed, Nov 26, 2003 at 03:48:14PM +0300, Денис Смирнов wrote:
> Я предлагаю создать не ещё одну тестовую прослойку, а наоборот,
> отслоить более надёжную версию Сизифа. 

Т.к. выше ты фактически математически показал, что это одно и то
же ;-) -- и т.к. как отслоить _слишком_ свежую версию сизифа,
понятно -- давай не будем говорить о надежности и сосредоточимся
на _не_надежности.  Бишь .incoming.

-- 
 ---- 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: 522 bytes --]

On Thu, Nov 27, 2003 at 04:25:37PM +0200, Michael Shigorin wrote:

 >> Я предлагаю создать не ещё одну тестовую прослойку, а наоборот,
 >> отслоить более надёжную версию Сизифа. 
 > Т.к. выше ты фактически математически показал, что это одно и то
 > же ;-) -- и т.к. как отслоить _слишком_ свежую версию сизифа,
 > понятно -- давай не будем говорить о надежности и сосредоточимся
 > на _не_надежности.  Бишь .incoming.

Согласен, Ok. По сути процесса это будет правильнее.

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

http://freesource.info


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

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

[Andrey Orlov]

On Wednesday 26 November 2003 15:15, Stanislav Ievlev wrote:

> Но до сих пор не понятно почему для этого нельзя использовать связку
> Сизиф-Дедал. По моему разумению результат от введения ещё одного Сизифа

По историческим причинам, некая практика работы Сизиф-Дедал уже сложилась,
изменить существующую практику значительно сложнее чем создать новую. Чисто
психологический фактор. Кроме того, в отличие от связки Сизиф-Дедал в данном
случае имеет место некий сорт автоматического тестирования + автоматического переноса
из одного репозитория в другой. О качестве этого тестирования я, лучше, промолчу, но
почему бы и не попробовать?

> Ключевой момент в моей	позиции - мы получим ещё один Дедал ибо люди (будь
> то пользователи или разработчики) будут сознательно или несознательно
> избегать использования пакетов, объявленных как нестабильные. Зачем нам
> ещё одна прослойка которая будет использоваться на 30%.

"Онм не смогут". Есть только один полноценный репозиторий - Сизиф. Второй репозиторий
неполноценен в принципе: в зависимости от принятой стратегии тестирования (чгря, не
дал себе труда прочитать весь тред, и говорю потому "в общем"), второй репозиторий будет:

 1. Содержать не все пакеты (по среднепотолочным данным, можно оценить как 
     60-70%, если контроллируется целостность и непротиворичивость репозитория);

 2. Содержать не самые последние версии пакетов (по тем же самым данным ;), можно
   оценить как 1месяц "в среднем", с хвостов порядка трех месяцев для худшего случая);

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

> там например 3 дня. Результат будет одинаковый.

 Не одинакоывый. Если мы делаем второй репозиторий под управлением apt, то
 можно контролировать зависимости, гарантировать (например) отсутствие конфликтов
 и многое другое. Иными словами, отстой содержит последнюю внутренне-непротиворечивую
 подборку пакетов, такую что для каждого пакета выполнены некие 
 "признаки оттестированности". 

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

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

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

ЗЫ: Чбы никто ничего зря не подумал - я в этом не участвую. Занят.

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

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

[Michael Shigorin]

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

On Wed, Nov 26, 2003 at 03:15:42PM +0300, Stanislav Ievlev wrote:
> Итак, мне понятна мысль  - сделать два Сизифа с "запаздыванием
> по времени".

Скорее возможность "видеть" сизифа в двух временнЫх сдвигах,
обеспеченная буфером -- .incoming.

> Но до сих пор не понятно почему для этого нельзя использовать
> связку Сизиф-Дедал.

См. мое письмо выше -- Дедал -- для точечных взрывов.

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

Нет.

Мы получим компоненту Сизифа, что куда как менее ресурсоемко
(files/ плюс симлинки), помимо всего прочего.  Бишь переложить
пакет из Sisyphus.incoming в Sisyphus.contrib, например -- вопрос
удаления предыдущей версии и перекидывания одного симлинка.

Трафик, опять же.  Для девелоперов и тестеров это тоже важно:
если пакет взят из Daedalus, никто не поручится, что при залитии
в Sisyphus в нем не сменится еще пара байт (пересборка ->
timestamp, например) и не придется качать все снова.

> Зачем нам ещё одна прослойка которая будет использоваться на
> 30%.

Это как раз неплохая цифра была бы -- те самые девелоперы
(которым настойчиво рекомендуется) и активно участвующие в
тестировании админы (+.incoming на тест-системе) и пользователи.

> Если уж нужен какой "отстойник" пакетов - то для этих целей
> можно использовать уже существующий incoming: он доступен на
> чтение всем разработчикам, а забирать в Сизиф можно только
> пакеты которые отлежались там например 3 дня. Результат будет
> одинаковый.

...и тут родился дурацкий вопрос: Стас, а что происходит с
пакетами между incoming:/incoming/Sisyphus/BTE/ и сизифом?  Они
пересобираются в обязательном порядке или BuildHost предписанного
вида (вместе с подписью, разумеется) достаточно для заливания?

Может быть, этот .incoming и будет действительно Sisyphus
Incoming для пакетов, собранных в BTE?

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

Можно.  Но это отдельный (ортогональный) вопрос, который все
равно надо решать или все равно надо отрабатывать руками.

-- 
 ---- 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

[Anton Farygin]

Денис Смирнов wrote:
> On Tue, Nov 25, 2003 at 03:29:11PM +0300, Stanislav Ievlev wrote:
> 
>  >>> и что такое "надёжность sisyphus" по-определению.
>  >> Не знаю; не вводил.
>  > нет определения - значит нет правила перекочёвки пакетов из этого "pre-sisyphus" в sisyphus.
> 
> У меня есть. Надёжность это величина равная 1-<ненадёжность>, а
> ненадёжность, это вероятность поиметь геморрой после dist-upgrade в виде
> неработоспособного сервера (т.е. не выполняющего свои функции так же
> хорошо, как до апгрейда).

Ой ой ой... господа, я _не рекоменду_ использовать Sisyphus на серверах 
любого маштаба.

> 
> Конечная цель моего предложение -- довести надёжность Сизифа до такой
> степени, чтобы можно было себе позволить по крайней мере на своей личной
> машине apt-get upgrade -y в cron'е, а при выполнении такого апдейта
> ручками на сервере масштаба хотя бы офиса быть увереным, что это не будет
> грозить увольнением.

Собственно а зачем Sisyphus ???

Есть же Master 2.2 - его + updates должно хватить.

>  
>  >> * .classic, который и применяется
>  >>     _пользователями_ Sisyphus.
>  >>       (в т.ч. и разработчиками Sisyphus на хостах, которые можно
>  >>       себе позволить / требуется держать на Sisyphus, но которые
>  >>       желательно иметь в работоспособном состоянии),
>  >> при условии минимальных изменений в текущей схеме.  
>  > До настоящего момента у нас не был "сизифа-дистрибутива", а был только "сизиф для разработчико и желающих". Идеологи должны решить эту проблему до конца, прежде чем начнутся какие-то реальные шаги.
> 
> de-facto динамичный репозиторий пакетов востребован конечными
> пользователями (в первую очередь этими пользователями являются
> разработчики и тестеры, но далеко не только они).
> 
> Поэтому можно либо закрывать глаза на такое его использование, либо
> искать принимать меры, которые позволят убить сразу уйму зайцев без
> негативных последствий для тех, кто привык и кому нравится нынешний
> механизм разработки.
>  
>  > Как показывает практика что пакет может лежать в daedalus. Большиство
>  > знает что там unstable и не пользуется им. Когда пакет приходит из
>  > daedalus в Cизиф там обнаруживаются проблемы.
> 
> Это всё потому, что даже Сизиф не является более-менее надёжным
> дистрибутивом. Daedalus в этом смысле рассматривается как "лучше я сразу
> сделаю rm -rf /, результат тот же, а работы меньше".

Sisyphus вообще не дистрибутив.

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

Зачем ?

>  
>  > Так в где гарантии что на пакет из incoming хоть кто-нибудь будет смотреть. 
>  > Для начала надо приучить _разработчиков_ пользоваться deadalus иначе
>  > просто будет добавлен новый совершенно неиспользуемый репозитарий.
> 
> Это равносильно попытке приучить людей тестировать на себе новые
> лекарства. Daedalus это экспериментальный дистрибутив, а никак не
> нестабильный.

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

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

Нет. Не скриптуемы до тех пор, пока в Sisyphus не появятся кем-то 
(неважно кем) разработанный набор скриптов.
И пока этот набор скриптов не решит использовать наш incoming@

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

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

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

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

Rgds,
Rider

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

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

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

On Wed, Nov 26, 2003 at 03:45:05PM +0300, Anton Farygin wrote:

 >> Конечная цель моего предложение -- довести надёжность Сизифа до такой
 >> степени, чтобы можно было себе позволить по крайней мере на своей личной
 >> машине apt-get upgrade -y в cron'е, а при выполнении такого апдейта
 >> ручками на сервере масштаба хотя бы офиса быть увереным, что это не будет
 >> грозить увольнением.
 > Собственно а зачем Sisyphus ???
 > Есть же Master 2.2 - его + updates должно хватить.

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

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

Фишка в том, что у нас есть только Мастер (в который попадают пакеты в том
числе после freeze, и который тажже далёк от идеала в плане надёжности), и
Сизиф, использование которого сами разработчики считают склонностью к
суициду. Я же предлагаю ввести дополнительную прослойку между Сизифом и
Мастером.

 >>>>> 3. кто всё это будет поддерживать.
 >>>> Скрипты.
 >>> Не всё можно охватить скриптами.
 >>> Даже сейчас при наличии большого количества скриптов приходится иногда
 >>> incoming переводить на ручное управление.
 >> Все те изменения, которые я предложил здесь, отлично скриптуемы.
 > Нет. Не скриптуемы до тех пор, пока в Sisyphus не появятся кем-то 
 > (неважно кем) разработанный набор скриптов.
 > И пока этот набор скриптов не решит использовать наш incoming@

Я думал что это не требует уточнение, ибо абсолютно ясно всем.
 
 > > > Нет никаких гарантий, что нетривиальные замены библиотек,
 > > > преименование/образование подпакетов можно будет полностью охватить 
 > > скриптами.
 >> Образование подпакетов легко, потому как работать система будет на уровне
 >> src.rpm, и сколько там подпакетов ей будет всё равно. Переименование --
 >> отлично сработает само, так как новый помещаемый в дистрибутив пакет (с
 >> другим именем) должен конфликтовать со старым (насколько я помню), таким
 >> образом, если у этих пакетов один и тот же мантейнер, то он может быть
 >> вынесен скриптом автоматически.
 > Не.. не все так просто.... для начала рекомендую попробовать вычислить 
 > набор provides для бинарных пакетов, которые получаются из src.rpm

provides-то зачем?
 
 >>>> Для "заглушки" критерием может быть
 >>>>   время модификации, от которого прошло N часов (24?);
 >>>>     это даст эффект "админ должен быть в меру тормознутым" -- у
 >>>>     разработчиков будет фора в эти N часов на dist-upgrade и
 >>>>     использование пакета.
 >>> Как и кем определяются эти N часов. Если была бага на которую кто-то ещё
 >>> не напарывался - то не факт что через N часов она самоликвидируется.
 >> За N часов её можно найти и повесить в BTS, и тогда пакет перемещён не
 >> будет. Выбирать это самое N пока придётся опытным путём, потом можно
 >> анализировать статистику.
 > Как показывает практика - большинство ошибок будет выявляться уже 
 > _после_ перемещения пакета, ибо для того, что бы его проверить в 
 > нестабильном репозитарии нужно неопределенно большое количество 
 > пользователей этого пакета, ежедневно обновляющихся из _нестабильного_ 
 > репозитария. Unreal.

Тут есть один нюанс, с которым я пока не знаю как бороться. Дело в том,
что, например, basesystem я тестировать на себе не хочу. А вот тот же php
и apache -- хочу. Потому как лучше я их сам оттестирую, чем буду иметь
проблемы при обновлении.

Собственно моя первая цель -- убиение большинства критических ошибок
и явных ляпов (которые выявляются минимальным тестированием даже 2-3
человек), и эту цель моя идея позволит выполнить.
 
-- 
С уважением, Денис

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:45:05PM +0300, Anton Farygin wrote:
> 
>  >> Конечная цель моего предложение -- довести надёжность Сизифа до такой
>  >> степени, чтобы можно было себе позволить по крайней мере на своей личной
>  >> машине apt-get upgrade -y в cron'е, а при выполнении такого апдейта
>  >> ручками на сервере масштаба хотя бы офиса быть увереным, что это не будет
>  >> грозить увольнением.
>  > Собственно а зачем Sisyphus ???
>  > Есть же Master 2.2 - его + updates должно хватить.
> 
> На сервере, в большинстве случаев, да. Однако во многих оказывается
> необходимость пол-сизифа бэкпортить.

ну так это лучше чем держать кучу непонятных репозитариев.

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


Самоубийцы должны быть на самообслуживании... все остальные - Welcom 2 
Sisyphus, постоянно нестабильную среду разработки.


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

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

> 
>  >>>>> 3. кто всё это будет поддерживать.
>  >>>> Скрипты.
>  >>> Не всё можно охватить скриптами.
>  >>> Даже сейчас при наличии большого количества скриптов приходится иногда
>  >>> incoming переводить на ручное управление.
>  >> Все те изменения, которые я предложил здесь, отлично скриптуемы.
>  > Нет. Не скриптуемы до тех пор, пока в Sisyphus не появятся кем-то 
>  > (неважно кем) разработанный набор скриптов.
>  > И пока этот набор скриптов не решит использовать наш incoming@
> 
> Я думал что это не требует уточнение, ибо абсолютно ясно всем.

Ясно что? Что не будет использовать или что будет использовать?


>  
>  > > > Нет никаких гарантий, что нетривиальные замены библиотек,
>  > > > преименование/образование подпакетов можно будет полностью охватить 
>  > > скриптами.
>  >> Образование подпакетов легко, потому как работать система будет на уровне
>  >> src.rpm, и сколько там подпакетов ей будет всё равно. Переименование --
>  >> отлично сработает само, так как новый помещаемый в дистрибутив пакет (с
>  >> другим именем) должен конфликтовать со старым (насколько я помню), таким
>  >> образом, если у этих пакетов один и тот же мантейнер, то он может быть
>  >> вынесен скриптом автоматически.
>  > Не.. не все так просто.... для начала рекомендую попробовать вычислить 
>  > набор provides для бинарных пакетов, которые получаются из src.rpm
> 
> provides-то зачем?

А как иначе узнать реальный список пакетов, которые получаются из этого 
src.rpm ?

Да, еще нужно вычислить Obsoletes...

>  
>  >>>> Для "заглушки" критерием может быть
>  >>>>   время модификации, от которого прошло N часов (24?);
>  >>>>     это даст эффект "админ должен быть в меру тормознутым" -- у
>  >>>>     разработчиков будет фора в эти N часов на dist-upgrade и
>  >>>>     использование пакета.
>  >>> Как и кем определяются эти N часов. Если была бага на которую кто-то ещё
>  >>> не напарывался - то не факт что через N часов она самоликвидируется.
>  >> За N часов её можно найти и повесить в BTS, и тогда пакет перемещён не
>  >> будет. Выбирать это самое N пока придётся опытным путём, потом можно
>  >> анализировать статистику.
>  > Как показывает практика - большинство ошибок будет выявляться уже 
>  > _после_ перемещения пакета, ибо для того, что бы его проверить в 
>  > нестабильном репозитарии нужно неопределенно большое количество 
>  > пользователей этого пакета, ежедневно обновляющихся из _нестабильного_ 
>  > репозитария. Unreal.
> 
> Тут есть один нюанс, с которым я пока не знаю как бороться. Дело в том,
> что, например, basesystem я тестировать на себе не хочу. А вот тот же php
> и apache -- хочу. Потому как лучше я их сам оттестирую, чем буду иметь
> проблемы при обновлении.

Ну так тестируйте из Sisyphus, вешайте баги, убивайте ошибки, 
пересобирайте для Master 2.2 - и вперед !!!


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


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

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

Rgds,
Rider

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

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

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

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

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

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

Такой репозиторий является меньшим самоубийством, чем использование
Сизифа.
 
 > > >> Это равносильно попытке приучить людей тестировать на себе новые
 > > >> лекарства. Daedalus это экспериментальный дистрибутив, а никак не
 > > >> нестабильный.
 > > > Это не дистрибутив, а репозитарий.. и именно экспериментальный... есть 
 > > > много людей, которые хотят тестировать новые лекарства, если этим самые 
 > > > лекарства могут спасти их от неминуемой смерти или ятжелоизлечимой 
 > > болезни.
 > >Фишка в том, что у нас есть только Мастер (в который попадают пакеты в том
 > >числе после freeze, и который тажже далёк от идеала в плане надёжности), и
 > >Сизиф, использование которого сами разработчики считают склонностью к
 > >суициду. Я же предлагаю ввести дополнительную прослойку между Сизифом и
 > >Мастером.
 > Ага... называется профессиональный суицид чужими руками...  нет. Как-то 
 > это выглядит намного хуже, чем введение новых правил в sisyphus_check.

Пока я не вижу здесь никакой конкретики. 
 
 >>> Нет. Не скриптуемы до тех пор, пока в Sisyphus не появятся кем-то 
 >>> (неважно кем) разработанный набор скриптов.
 >>> И пока этот набор скриптов не решит использовать наш incoming@
 >> Я думал что это не требует уточнение, ибо абсолютно ясно всем.
 > Ясно что? Что не будет использовать или что будет использовать?

Что будем использовать в случае согласия тех, кто отвечает за сервер, и
если, например, я напишу скрипт.
 
 >>> Не.. не все так просто.... для начала рекомендую попробовать вычислить 
 >>> набор provides для бинарных пакетов, которые получаются из src.rpm
 >> provides-то зачем?
 > А как иначе узнать реальный список пакетов, которые получаются из этого 
 > src.rpm ?

_пакетов_ или _provides_? Это сильно разные вещи.

 > Да, еще нужно вычислить Obsoletes...

Что его вычислять? Для этого spec есть.
 
 >> Тут есть один нюанс, с которым я пока не знаю как бороться. Дело в том,
 >> что, например, basesystem я тестировать на себе не хочу. А вот тот же php
 >> и apache -- хочу. Потому как лучше я их сам оттестирую, чем буду иметь
 >> проблемы при обновлении.
 > Ну так тестируйте из Sisyphus, вешайте баги, убивайте ошибки, 
 > пересобирайте для Master 2.2 - и вперед !!!

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

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

Безапелляционное и ничем не обоснованое заявление.
 
-- 
С уважением, Денис

http://dimline.ru/


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

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

[Michael Shigorin]

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

On Wed, Nov 26, 2003 at 05:41:05PM +0300, Anton Farygin wrote:
> >На сервере, в большинстве случаев, да. Однако во многих
> >оказывается необходимость пол-сизифа бэкпортить.
> ну так это лучше чем держать кучу непонятных репозитариев.

Каких-таких репозитОриев?!

Предлагается КОМПОНЕНТА в Sisyphus.  Их там и так куча --
{ base castle contrib junior kernel master } == classic; non-free
-- и никто вроде не страдает?

[long skip: договоритесь о терминах в привате, что ли?]

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

Это ортогонально.  Т.е. тоже нужно, но совсем другое.

-- 
 ---- 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

[Michael Shigorin]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Michael Shigorin]

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

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

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

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

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

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

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

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

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

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

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

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

Да.

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

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

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

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

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

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

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

Ессно.

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

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

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

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

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

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

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

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

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