qa.adoc

---
title: "Задачи контроля качества для Группы управления портами"
sidenav: about
---

= Задачи контроля качества для Группы управления портами

Имеется ряд задач, которые выполняет Группа управления портами в целях улучшения качества Коллекции Портов. Они делятся на две большие категории: <<qa-before-release,мероприятия во время цикла подготовки релиза>> и <<qa-between-releases,мероприятия между циклами подготовки релизов>>.

[[qa-before-release]]
== Мероприятия во время цикла подготовки релиза

* Работа с link:{releng}[Группой подготовки релизов] по координации графика выпуска релиза.
* Работа с группой RE по определению того, какие предварительной построенные пакеты могут быть по умолчанию размещены на установочные ISO-образы.
* Управление коммитами в дерево CVS в целях построения пакетов, что подразумевает выполнение следующих шагов:
. Объявление о приостановке работ и генерации пакетов для всех соответствующих архитектур. Часто этот процесс повторяется, потому что либо в разных портах обнаруживаются ошибки, либо изменения в дереве исходных текстов системы создают определённые риски, которые могут привести к тому, что уже построенные пакеты не будут работать после внесения этих изменений.
+
Для обеспечения целостности и корректности сборки пакетов _все_ коммиты должны быть согласованы с группой управления портами. Обычно разрешаются следующие изменения:
** исправления, влияющие на успешность построения пакета;
** исправления, касающиеся информационной безопасности критических для работы пакетов;
** обнаруженные проблемы с лицензионными соглашениями.
К сожалению, из-за невероятного размера Коллекции Портов и скорости разработки приложений, к моменту выпуска релиза исправить все ошибки невозможно.
. После этого дерево блокируется для любых изменений и помечается CVS-меткой.
. Затем дерево разблокировывается и объявляется о `полировке`. Это состояние нужно для того, чтобы вносить в Коллекцию Портов обычные изменения, но с тем, что они не появятся на ISO с релизом. В коммитах необходимо избегать следующих вещей:
** обновления портов со многими зависимостями, в частности, серверы X11, KDE и GNOME;
** прямые копирования в хранилище многих портов;
** и так далее.
+
Причина, по которой мы хотим избежать таких коммитов, заключается в том, что если будет найдена какая-то настолько серьёзная проблема (связанная с безопасностью или вопросами лицензирования), что нам придётся делать изменения, которую могут быть перенесены на ISO c релизом, то ко всему прочему нам будет нужно проставлять CVS-метку на эти изменённые файлы. Если мы разрешим абсолютно все виды изменений, то высок риск, что любое такое изменение приведёт к необходимости повторного построения пакетов снова и снова, и в результате процесс подготовки релиза будет бесконечным.
+
Как только команда RE и portmgr останутся довольными итоговым состоянием ISO с релизом, дерево портов будет снова полностью доступно для коммитов.

[[qa-between-releases]]
== Мероприятия между циклами подготовки релизов

* Управление машинами http://pointyhat.FreeBSD.org[кластера построения портов]. Они постоянно строят пакеты для всех возможных комбинаций релизов ОС и архитектур ЦП (по нашей терминологии `сред построения`.)
+
В процессе этих построений также генерируются протоколы ошибок для пакетов, которые строятся некорректно (обратитесь по URL-адресу выше). Периодически группа помечает эти порты как нерабочие (BROKEN), чтобы это могли увидеть сопровождающие. (Смотрите далее.)
+
Успешно построенные пакеты (по крайней мере, те, что распространяются свободно) также копируются на главный FTP-сервер и таким образом становятся по умолчанию "самыми последними пакетами" для выполнения установки при помощи пакетов, а не портов.
* Оповещение сообщества FreeBSD о проблемах в Коллекции Портов, чтобы они не были пропущены. Для этого существует некоторое количество отчётов, отправляемых по электронной почте. Те, что отмечены как `общедоступные`, публикуются во freebsd-ports.
** общедоступный перечень портов, удалённых из-за проблем с безопасностью, ошибок построения или общей устарелости, если до этого ситуация не будут исправлена.
** частные письма всем сопровождающим затронутых портов (включая порты, зависящие от указанных выше).
** частные письма всем сопровождающим портов, которые уже помечены как нерабочие (BROKEN) и/или запрещённые (FORBIDDEN).
** частные письма сопровождающим, не являющимся коммиттерами, которые направили PR о собственных портах (для отметки PR, которые могли не направляться им через Cc:).
** сообщение всем о коммитах портов, которые нарушают построение файла INDEX.
** оповещение всех о коммитах портов, в которых мета-данные о версиях меняются в обратную сторону (и таким образом вводят в заблуждение такие инструменты, как portupgrade).
** общедоступный перечень всех портов, которые имеют по крайней мере один файл, который невозможно сгрузить с любого главного сайта, не относящегося к FreeBSD. Полный список результатов проверки доступности всех файлов со всех своих главный сайтов можно найти в http://people.FreeBSD.org/~fenner/portsurvey/[тесте портов Билла Феннера].
** частные письма сопровождающим затронутых портов, если порт будет помечаться как нерабочий (BROKEN), копия через Cc: направляется последнему коммиттеру порта. (Эта почта не автоматизируется, но она должна посылаться как жест вежливости.)
** список портов, которые не устанавливают NO_LATEST_LINK. (Порты, у которых есть и стабильная версия, и версия в процессе разработки, обычно устанавливают номер версии в разработки на большее значение. Если желательно, чтобы из пакетов пользователи устанавливали стабильную версию, а не версию в разработке, то нужно задать этот параметр; в противном случае по умолчанию пользователи получат последнюю версию.)
* Удаление устаревших портов. Порты, которые уже помечены как BROKEN какой-то период времени, помечаются как DEPRECATED (с установкой EXPIRATION_DATE), а затем удаляются, если за истекшее время никто их не исправил. Целью такого порядка является обеспечение того, что если пользователь установил порт, то он должен иметь максимальные шансы на восстановление работоспособность.
+
В других случаях порты помечаются как DEPRECATED, если они заменяются на более современные версии, а старые больше автором не поддерживаются. Обычно при этом должна задаваться EXPIRATION_DATE не менее чем в два будущих месяца, что даёт достаточно времени, чтобы произвести обновление.