[sisyphus] [POLICY] Sisyphus альфа , бета , гамма

[info]

Написал довольно длинное письмо - как положено, с целеполаганием 
и пр... - но оно куда-то по дороге съелось.

Посему - вкратце повторяю.

Итак, целеполагание.

Цель существования Сизифа и всех работ над ним - т.е. тот 
конечный результат, который должен быть достигнут - это 
подготовка некоего набора пакетов (дистрибутива), который в 
любой момент, определенный руководством ALT, может быть выпущен 
в свет в качестве очередной версии Master.   

Данная цель достигается, в общем виде, путем решения следующих 
задач ("задача" - в понимании программно-целевого планирования, 
а не программирования).
1. Получение новых версий программных продуктов в исходниках
2. Сборка пакетов.
3. Помещение собранных пакетов в Сизиф
4. Тестирование пакетов
5. Исправление ошибок в случае их нахождения
6. Повторная сборка пакетов с исправленными ошибками.
7. Повторное помещение собранных и исправленных пакетов в Сизиф.

Задачи 1 и 5 решаются упаковщиком, задачи 2 и 6, как я понял - 
как упаковщиком на своей машине, так и в недрах incoming@,  
задачи 3 и 7 решает incoming на .

А вот задача 4 "Тестирование" разделяется на две подзадачи:
4.1 - системное тестирование, производящееся с целью добиться 
устанавливаемости и запускаемости приложения в системе
4.2 - пользовательское тестирование, производящееся с целью 
добиться соответствия реальной функциональности приложения 
заявленному.

Соответственно, подзадача 4.1 "Системное тестирование" решается 
как упаковщиком, так и некими автоматизированными  средствами, 
а вот подзадача 4.2 "Пользовательское тестирование" - она 
решается вручную пользователем, реально применяющим пакет на 
практике по его предназначению.

Кстати необходимо отметить, что соотношение между 
динамичностью/стабильностью для пользовательского и системного 
тестирования должно быть различным. Упаковщикам важна динамика; 
пользователи же вряд ли будут обновляться чаще раза в неделю, и 
вплоть до раза в месяц.

Также стоит отметить целесообразность деления багов минимум на 
две категории - "системные" и "пользовательские"

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

1.
Альфа-сизиф.

Предназначение: инструмент для решения подзадачи 4.1 "Системное 
тестирование"

Кто пользуется: упаковщики и разработчики.

Способ формирования: фактически нынешний Сизиф, но с четким 
делением на фазы существования по времени (как в любом 
проекте). 

Фазы предлагаются следующие:

* incoming&testing (~ 5 дней) - принимаются любые новые версии 
пакетов, производится системное тестирование, на каждую 
замеченную ошибку вешается "системный баг" 
* fixing (~ 1 день) - принимаются только пакеты с исправлением 
"системных багов", замеченных на фазе incoming&testing.
* frozing (~ 1 день)  - не принимается никаких новых пакетов. 

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

Особое требование: к началу фазы frozing все замеченные при 
системном тестировании ошибки должны быть либо устранены, либо 
произведен откат на предыдущие версии.

Таким образом, альфа-сизиф в фазе frozing - это дистрибутив со 
100%-й устанавливаемостью и запускаемостью приложений. 

2.
Бета-сизиф

Предназначение: инструмент для решения подзадачи 4.2 
"Пользовательское тестирование"

Кто пользуется: "продвинутые пользователи"

Способ формирования: копия последнего альфа-сизифа в фазе 
frozen.

Оcобое требование: удобный и быстрый в использовании 
web-интерфейс оповещения о "пользовательских" багах (кстати, 
обращаю внимание на существование такого интерфейса в KDE - 
меню "Помощь -> Сообщить об ошибке")

3. 
Гамма-сизиф, он же - pre-Master

Предназначение:
* основа для формирования очередной версии дистрибутива
* обновления для предыдущих версий

Способ формирования: перенос из бета-сизифа тех пакетов, которые 
пролежали в бета-сизифе время не менее N, и на которые либо не 
поступило "пользовательских" багов, либо  с момента закрытия 
последнего "пользовательского" бага прошло не менее M дней.

Ну вот примерно так. Комментарии?