Задачи контроля качества для Группы управления портами
Имеется ряд задач, которые выполняет Группа управления портами в целях улучшения качества Коллекции Портов. Они делятся на две большие категории: мероприятия во время цикла подготовки релиза и мероприятия между циклами подготовки релизов.
Мероприятия во время цикла подготовки релиза
Работа с Группой подготовки релизов по координации графика выпуска релиза.
Работа с группой RE по определению того, какие предварительной построенные пакеты могут быть по умолчанию размещены на установочные ISO-образы.
-
Управление коммитами в дерево CVS в целях построения пакетов, что подразумевает выполнение следующих шагов:
-
Объявление о приостановке работ и генерации пакетов для всех соответствующих архитектур. Часто этот процесс повторяется, потому что либо в разных портах обнаруживаются ошибки, либо изменения в дереве исходных текстов системы создают определённые риски, которые могут привести к тому, что уже построенные пакеты не будут работать после внесения этих изменений.
Для обеспечения целостности и корректности сборки пакетов все коммиты должны быть согласованы с группой управления портами. Обычно разрешаются следующие изменения:
исправления, влияющие на успешность построения пакета;
исправления, касающиеся информационной безопасности критических для работы пакетов;
обнаруженные проблемы с лицензионными соглашениями.
К сожалению, из-за невероятного размера Коллекции Портов и скорости разработки приложений, к моменту выпуска релиза исправить все ошибки невозможно.
-
После этого дерево блокируется для любых изменений и помечается CVS-меткой.
-
Затем дерево разблокировывается и объявляется о полировке. Это состояние нужно для того, чтобы вносить в Коллекцию Портов обычные изменения, но с тем, что они не появятся на ISO с релизом. В коммитах необходимо избегать следующих вещей:
обновления портов со многими зависимостями, в частности, серверы X11, KDE и GNOME;
прямые копирования в хранилище многих портов;
и так далее.
Причина, по которой мы хотим избежать таких коммитов, заключается в том, что если будет найдена какая-то настолько серьёзная проблема (связанная с безопасностью или вопросами лицензирования), что нам придётся делать изменения, которую могут быть перенесены на ISO c релизом, то ко всему прочему нам будет нужно проставлять CVS-метку на эти изменённые файлы. Если мы разрешим абсолютно все виды изменений, то высок риск, что любое такое изменение приведёт к необходимости повторного построения пакетов снова и снова, и в результате процесс подготовки релиза будет бесконечным.
Как только команда RE и portmgr останутся довольными итоговым состоянием ISO с релизом, дерево портов будет снова полностью доступно для коммитов.
-
Мероприятия между циклами подготовки релизов
-
Управление машинами кластера построения портов. Они постоянно строят пакеты для всех возможных комбинаций релизов ОС и архитектур ЦП (по нашей терминологии сред построения.)
В процессе этих построений также генерируются протоколы ошибок для пакетов, которые строятся некорректно (обратитесь по URL-адресу выше). Периодически группа помечает эти порты как нерабочие (BROKEN), чтобы это могли увидеть мэйнтейнеры. (Смотрите далее.)
Успешно построенные пакеты (по крайней мере, те, что распространяются свободно) также копируются на главный FTP-сервер и таким образом становятся по умолчанию "самыми последними пакетами" для выполнения установки при помощи пакетов, а не портов.
-
Оповещение сообщества FreeBSD о проблемах в Коллекции Портов, чтобы они не были пропущены. Для этого существует некоторое количество отчётов, отправляемых по электронной почте. Те, что отмечены как общедоступные, публикуются во freebsd-ports.
общедоступный перечень портов, удалённых из-за проблем с безопасностью, ошибок построения или общей устарелости, если до этого ситуация не будут исправлена.
частные письма всем мэйнтейнерам затронутых портов (включая порты, зависящие от указанных выше).
частные письма всем мэйнтейнерам портов, которые уже помечены как нерабочие (BROKEN) и/или запрещённые (FORBIDDEN).
частные письма мэйнтейнерам, не являющимся коммиттерами, которые направили PR о собственных портах (для отметки PR, которые могли не направляться им через Cc:).
сообщение всем о коммитах портов, которые нарушают построение файла INDEX.
оповещение всех о коммитах портов, в которых мета-данные о версиях меняются в обратную сторону (и таким образом вводят в заблуждение такие инструменты, как portupgrade).
общедоступный перечень всех портов, которые имеют по крайней мере один файл, который невозможно сгрузить с любого главного сайта, не относящегося к FreeBSD. Полный список результатов проверки доступности всех файлов со всех своих главный сайтов можно найти в тесте портов Билла Феннера.
частные письма мэйнтейнерам затронутых портов, если порт будет помечаться как нерабочий (BROKEN), копия через Cc: направляется последнему коммиттеру порта. (Эта почта не автоматизируется, но она должна посылаться как жест вежливости.)
список портов, которые не устанавливают NO_LATEST_LINK. (Порты, у которых есть и стабильная версия, и версия в процессе разработки, обычно устанавливают номер версии в разработки на большее значение. Если желательно, чтобы из пакетов пользователи устанавливали стабильную версию, а не версию в разработке, то нужно задать этот параметр; в противном случае по умолчанию пользователи получат последнюю версию.)
-
Удаление устаревших портов. Порты, которые уже помечены как BROKEN какой-то период времени, помечаются как DEPRECATED (с установкой EXPIRATION_DATE), а затем удаляются, если за истекшее время никто их не исправил. Целью такого порядка является обеспечение того, что если пользователь установил порт, то он должен иметь максимальные шансы на восстановление работоспособность.
В других случаях порты помечаются как DEPRECATED, если они заменяются на более современные версии, а старые больше автором не поддерживаются. Обычно при этом должна задаваться EXPIRATION_DATE не менее чем в два будущих месяца, что даёт достаточно времени, чтобы произвести обновление.