--- title: "Задачи контроля качества для Группы управления портами" sidenav: about --- = Задачи контроля качества для Группы управления портами Имеется ряд задач, которые выполняет Группа управления портами в целях улучшения качества Коллекции Портов. Они делятся на две большие категории: <> и <>. [[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 не менее чем в два будущих месяца, что даёт достаточно времени, чтобы произвести обновление.