Регламент обновления пакетов в основных репозиториях ROSA Linux

Материал из Rosalab Wiki
Версия от 07:43, 2 мая 2018; Vladimir.potapov (обсуждение | вклад) (Общий порядок обновления)

Перейти к: навигация, поиск

Применимость

Настоящий регламент описывает порядок добавления и исправления пакетов в дистрибутивах ROSA Linux Fresh при взаимодействии пяти команд:

  1. Команды репортеров, сообщающих об ошибках и уязвимостях в пакетной базе и выступающих с предложениями обновления пакетов
  2. Команды сборщиков, собирающих пакеты с новыми версиями программ и исправлениями ошибок и уязвимостей
  3. Команды контроля качества (QA), контролирующих работоспособность исправленных пакетов и всей системы в целом после обновления
  4. Команда контроля уязвимостей (SecTeam), отслеживающих текущие уязвимости дистрибутива и корректность исправления этих уязвимостей сборщиками
  5. Публикатора, задача которого - доступность исправленных пакетов на зеркалах дистрибутива

Данный порядок относится к работе с основными репозиториями ROSA Linux, за исключением репозитория сообщества (contrib) где контроль качества не производится.

Общий порядок обновления

  1. Общий порядок адресации каждого запроса на обновление - Репортеры -> Cборщики -> QA & Secteam -> Публикатор
  2. Допустимо совмещение ролей "репортер", "сборщик" и "публикатор", но недопустима ситуация, когда человек проверяет результаты своей сборки и публикует их.
  3. Репортер-сборщик, отслеживающий обновления необходимого ему пакета и самостоятельно собирающий его, называется сопровождающим (мейнтейнером) и прописывается на abf.
  4. Вся работа по обновлению пакетов происходит с помощью специально созданных в багзилле ROSA Linux багов - запросов на обновление

Репортеры

  1. Репортеры заводят в багзилле баги, обосновывающие необходимость исправления или добавления, с описанием ошибки, кодом уязвимости или необходимым им новым функционалом.
  2. Альтернативным путем создания запроса на изменение пакетов в репозиториях для репортеров является пул-реквест в системе сборки ABF.
  3. Репортеры являются заказчиками исправления, т.е. контролируют весь его процесс до попадания в репозитории.

Сборщики

  1. Сборщики получают информацию о багах от репортеров через рассылку багзиллы
  2. Пакеты обновляются на основании заведенного в багзилле бага с заголовком [UPDATE REQUEST <платформа>] называемого запросом на обновление
  3. В комментариях к запросу на обновления указываются ссылки на контейнеры с собранным для указанной платформы обновлением пакета и advisory - написанное по-английски обоснование обновления (например выход новой версии, исправление уязвимости)
  4. После того, как закончено формирование запроса на обновление, он отправляется на контроль качества команде QA установкой флажка qa_verified в знак вопроса "?"

Команда контроля качества (QA)

  1. Команда QA получается запросы с установленным сборщиками флажком qa_verified
  2. Если обновление содержит исправления уязвимостей, устанавливается флажок sectime_verified в "?" для параллельной проверки корректности исправления уязвимостей командой SecTeam
  3. После проверки отсутствия регрессий функциональности у собранного пакета команда QA ставит флаг QA_verified "+" при успешной проверке и "-" при неуспешной.
  4. При отсутствии регрессий и, при необходимости, после получения одобрения запроса от команды SecTeam (флажок sectime_verified меняется на "+") запрос отправляется на публикацию установкой флажка publishied в "?"
  5. Команда QA проводит тестирование пакетов, используя Регламент тестирования

Команда контроля уязвимостей (SecTeam)

  1. Список уязвимостей ведется на странице вики Список уязвимостей командой SecTeam.
  2. Для каждой уязвимости из списка команда SecTeam выступает репортером и заводит баг или пул-реквест
  3. Дополнительно могут проверяться и запросы с исправлениями уязвимостей, сделанные и не участниками команды SecTeam

Публикатор

  1. Публикатор получает запрос на обновление после его одобрения командами QA и (если он содержит исправления уязвимостей) SecTeam
  2. Публикатор обеспечивает появление пакетов обновлений в репозиториях и непротиворечивость репозиториев после публикации.
  3. После успешной публикации флажок "publishied" устанавливается в "+" и запрос на обновление считается полностью закрытым.