[sisyphus] Re: [POLICY] Sisyphus-current; альфа, бета, гамма -- это уже Master

[Michael Shigorin]

On Wed, Jan 28, 2004 at 01:45:19PM +0300, info wrote:
> Родилась очередная схемка, которую и выношу на обсуждение.

Эээ... ну кое-что уже существенно нуждается в правке.

> В чем цель Сизифа и смысл его существования?

В http://wiki.atmsk.ru/index.html/AltPolicy сформулировал так:

---
* Sisyphus:

репозиторий пакетов, являющийся основой всех остальных продуктов;
может быть характеризован как "current" / "unstable".

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

Интересен:

  - технологическим партнерам как адекватная база для создания и
    развития своих продуктов;

  - индивидуальным разработчикам как удобный пул ПО,
    используемого ими;

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

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

Не только.

Попросту говоря, Sisyphus на сейчас -- это не просто "вечная
бета" или движущийся ландшафт, а /платформа/.  Движущаяся. :-)

> Или - иными словами - работа над Сизифом - это работа по
> подготовке очередной версии Мастера.

Не только.

На основе Sisyphus выпускается не только (и не столько, рискну
добавить) Master, сколько более специфические и нацеленные
дистрибутивы.  Не обязательно фирмой Альт Линукс.

Собственно, http://altlinux.ru/?module=sisyphus

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

Не только. :)

---
Участники

...принимают участие в проекте (обычно Sisyphus) по таким причинам:

* контроль качества критичных для своего продукта компонентов:

      это - случай разработчиков, занятых в фирмах, которые
      участвуют в проекте ALT Linux Sisyphus.

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

* контроль качества критичных для своей производственной среды
  компонент:

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

      Обеспечение аналогично предыдущему случаю. 

* контроль качества продукта или компонентов продукта в силу
  своей заинтересованности в оном:

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

      Качество продукта/компонента обеспечивается квалификацией
      участника, затраченного времени и мерой личной
      ответственности участника. 
---

> Итак, повторяю: конечный результат работы над Сизифом  - скажем
> так,  pre-Master. Который может быть оформлен в очередной
> Master x.x тогда, когда это сочтет руководство ALT.
> Вот это и есть целеполагание: цель Сизифа -> pre-Master.

Нет, это конечный вариант работы над частным случаем --
замораживаемым срезом Sisyphus, предназначенным стать Master.

> Цель определена.

Да, но эта цель ближе к задачам QA & ALM release mgmt.

Применительно к Sisyphus, например, квантовать время настолько
детерминированно -- все равно что плывущую реку рывками двигать.

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

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

А еще реже приходит (приходила?) зима и если течение и
продолжается -- то сверху его не видно.  Потом Весна приходит
Хозяином, ну и вскоре лед шумно трескается, все ломается нафиг и,
слегка успокоившись, течет дальше :-)

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

Еще как имеет.  Пакет -- это value added source, что уже
предопределяет то, что:

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

- скрипты в пакетах могут настраивать устанавливаемое ПО разумно
  предполагаемым образом (если после установки lyx надо запустить
  его конфигурилку -- зачем это делать _каждый_ раз
  администратору? ...etc);

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

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

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

Местами автоматизируется (или уже автоматизировано).

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

Вот Вы и сформулировали, зачем "буфер" (как реализуемая часть
вместо удвоения Sisyphus как репозитория, что нереально).

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

> Отсюда получаем следующее - предлагаю использовать общепринятую
> терминологию при тестировании (альфа, бета и т.д.)

Здесь придется сдвинуть и чуточку дополнить.

Есть "пре-альфа-сизиф", каковой в миру известен как Daedalus. :)
Некоторое время он не был даже репозиторием -- скорее местом
расположения пакетов.

Даже безусловно стабильные пакеты, которые в нем могут
оказываться, предлагаются с биркой "НЕ КАНТОВАТЬ, ВЗРЫВООПАСНО!".

Закладываться на пакеты/версии из дедала при сборке пакета в
сизиф нельзя.

> 1.  Альфа-сизиф. 
> Предназначение: системное тестирование. 
> Кто пользуется: паковщики и разработчики.

...или "classic+incoming".

> Фактически нынешний сизиф, но с четким разделением на "периоды
> жизни", или фазы:
>  - incoming (~ 2 дня) - принимаются любые свежие пакеты
>  - systesting (~ 3 дня) - упаковщики обновляют cвои машины до
>  состояния на конец фазы incoming, проверяют устанавливаемость,
>  запускаемость и пр., если надо - списываются друг с другом,
>  фиксят ошибки и пр.
>  - fixing (~ 1 день) - принимаются только пофиксенные пакеты,
>  исправляющие ошибки, замеченные на фазе systesting.
>  - frozen (~ 1 день) - не принимается вообще ничего; фаза
>  предназначена для того, чтобы упаковщики могли обновить свои
>  машины и далее собирать пакеты в гарантированно одинаковом
>  окружении.

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

Повторюсь: река он, река :)

> 2.  Бета-сизиф.
> Предназначение: пользовательское тестирование.
> Кто пользуется: "продвинутые пользователи" и "пионэры", 
> проверяющие приложения в работе.
> Обновление - раз в неделю.  Метод заполнение: бета-сизиф - это
> копия альфа-сизифа в фазе frozen.

Возможно, с развитием QA доберется и до такого.  Здесь сразу
видится как минимум одна проблема: чрезмерная неравномерность
нагрузки и привязка к TIME2 (неделе), которая вовсе необязательно
совпадает с ритмом "жизни" систем целевой аудитории.
Навязываться же нельзя... полагаю.

> 3.  Гамма-сизиф, он же - pre-Master
> Предназначение: основа для очередных версий дистрибутивов, а 
> также обновления предыдущих их версий.
> Кто пользуется: те пользователи, которым нужны свежие, но
> проверенные и стабильные версии пакетов.
> Заполнение: те самые алгоритмы, о которых здесь много
> говорилось (пакет n-ное время находится в бета-сизифе, на него
> нет незакрытых багов, с момента закрытия последнего бага
> опять-таки прошло nn-ное время и т.д.) 

Это обычно называется "Master beta".  Пока ни разу не было так,
чтобы это была действительно параллельно разрабатываемая ветка --
по банальной причине нехватки ресурсов.  Посему объявлялась
заморозка Sisyphus различной степени глубины с последующим
бранчем и требованием дополнительно анонсировать пакеты,
содержащие критичные фиксы, для их отбора туда.

С другой стороны, что происходит, когда горячие пакаджерские
/usr/bin/rsync начинают "по привычке" заливать что-нить
"свеженькое" в замораживаемый сизиф?  Понятно -- подтаивает.
Вылазят новые баги, которые вносить было просто незачем.

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

> Вот такая очередная схемка на обсуждение. Комментарии???

Это гораздо более редкий (не повседневный) фрагмент времени.
Т.е. схемка, но не развития _Sisyphus_.  Скорее упорядоченного
замораживания и тестирования перед выпуском дистрибутива.

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

PS: 2 all: сорри, немного понесло на лирику, но эту сторону
сейчас лучше не развивать, наверное.  К фесту лучше.

-- 
 ---- WBR, Michael Shigorin <mike на altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/
----------- следущая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : отсутствует
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: отсутствует
Url     : /pipermail/sisyphus/attachments/20040128/6d8c4878/attachment.bin