---
title: "Политики работы Группы управления портами"
sidenav: about
---

include::shared/ru/urls.adoc[]

= Политики работы Группы управления портами

В соответствии со своим link:../charter[Уставом], Команда управления портами применяет определённые политики для достижения каждой из стоящих перед ней целей.

== Обеспечение целостности Коллекции Портов

Для того, чтобы добиться целостности Коллекции Портов, portmgr выступает в роли единственного коммиттера для определённых файлов, которые связывают всё воедино, в частности, `bsd.port.mk`. Так как дерево портов не делится на ветки (в отличие от других проектов BSD), любая фатальная ошибка в этих файлах быстро отразится на многих пользователях, выполняющих автоматическое обновление своих портов.

portmgr также выполняет периодическое построение больших изменений в Коллекции Портов в отдельной области автоматизированного http://pointyhat.FreeBSD.org[кластера построения портов]. В качестве примеров изменений, которые должны тестироваться до их вступления в силу, можно привести следующие:

* изменения в `bsd.port.mk`
* изменения в пакетах со многими зависимостями, в том числе серверы X11, GNOME, KDE, пакеты из серии autotools и так далее
* исправления, которые изменяют "рекомендуемый порядок" для make-файлов портов, в частности, определения или использование распространённых make-переменных (`Makevar`). (к примеру, объединение различных реализаций USE_*, WITH_* и так далее)
* большие объёмы прямых изменений в хранилище (например, при разделении существующей категории портов)

И снова, из-за отсутствия веток в дереве CVS, любые крупные сбои, которые могут быть вызваны любым из вышеописанных действий, должны быть выявлены до того, как они смогут затронуть большое количество пользователей.

portmgr оставляет за собой право выступать в качестве последнего арбитра для коммитов других разработчиков в отдельных нестандартных ситуациях, в частности: коммиты, которые, по их мнению, дестабилизируют Коллекцию Портов; нарушения POLA (принципа наименьшего изменения) для пользователей FreeBSD, а также случаи разногласий между коммиттерами, которые не могут быть решены ими самостоятельно.

== Поддержка автоматизированного http://pointyhat.FreeBSD.org[кластера построения портов]

portmgr поддерживает набор машин, которые автоматически строят пакеты для разных комбинаций деревьев исходных текстов FreeBSD и архитектур центральных процессоров (в нашей терминологии, `сред построения` или `buildenv`). Если позволяют лицензионные соглашения, то получающиеся пакеты регулярно записываются на главное зеркало FTP в качестве "новых последних пакетов", так что они становятся доступными для сгрузки пользователями FreeBSD. Ошибки при построении портов направляются ответственным сопровождающими и/или коммиттерам для принятия мер по исправлению ситуации.

В некоторых случаях порты могут перестать работать из-за изменений в базовой системе FreeBSD (дерево src/). В таком случае Группа управления портами полагает, что ответственный системный коммиттер разработает исправления для затронутых портов вместе с соответствующими сопровождающими портов.

== Работа с Группой информационной безопасности FreeBSD

== Работа с коммиттерами портов и документации FreeBSD

portmgr будет помогать в поддержании link:{porters-handbook}[Руководства по созданию портов FreeBSD] в актуальном состоянии в том духе, который, по их мнению, являются "наилучшей практикой" для отдельных портов.

(Целью является не только определение 'правил', но и объяснение того, 'почему в make-файлах сделаны определённые вещи, которые мы считаем правильными'. В частности, существует ряд "частных случаев", для работы с которыми в файлах `bsd.*.mk` присутствует хитроумный код -- например, для обеспечения установки портов с CDROM, по NFS и так далее -- и непонимание этих вопросов может привести к тому, что используемые сопровождающими упрощённые подходы не будут работать в этих крайних случаях.)

portmgr не является единственным хозяином Руководства по созданию портов, так как оно размещено в дереве `doc/`. Мы рады присылаемым сообщениям об ошибках и приветствуем работу коммиттеров `doc` над добавлением документации, которая помогает описать существующую практику. Однако мы хотели бы запросить, в качестве жеста вежливости, право на пересмотр любых изменений, которые могли бы отразиться на существующих рекомендациях.

Кроме того, недавно возникла идея создания документа "Права и ответственности сопровождающих портов FreeBSD и коммиттеров". portmgr поддерживает эти усилия и рассмотрит любые предварительные версии документа.

portmgr также отвечает за некоторую другую документацию, в частности, разделы Руководства коммиттера, касающиеся портов.

== Уважение юридических прав авторов, чьи работы устанавливаются через Коллекцию Портов

В той мере, что возможна в рамках добровольного проекта, portmgr будет работать над соблюдением прав тех авторов, чьи работы устанавливаются через Коллекцию Портов. Сюда включается добавление соответствующих записей в файл `ports/LEGAL` и изменение `make-переменных`, управляющих построением пакетов и, вследствие этого, автоматизированным распространением бинарных файлов.

В редких случаях по требованию автора при этом также может потребоваться удалить порт и все дистрибутивные и двоичные файлы.

portmgr просит наших добровольных коммиттеров тщательно соблюдать лицензионные ограничения, накладываемые авторами, при добавлении новых портов, так как для членов portmgr самим сделать это невозможно из-за огромного количества портов.

== Выполнение роли первого лица при решении споров между такими участниками сообщества FreeBSD, как сопровождающие и коммиттеры

portmgr призывает участников сообщества FreeBSD работать вместе в согласии в соответствии с принципами, описанными в Руководстве коммиттера. В случае разногласий мы оставляем за собой роль арбитра, что может быть пересмотрено Правлением.

== Управление доступом с CVS для выполнения коммитов в дерево портов

Управляющий совет FreeBSD делегировал portmgr ответственность за управление доступом к CVS для выполнения изменений в дереве `ports/`. Правление рассматривает выдачу и лишение прав на выполнение изменений и является последней инстанцией в вопросам, касающихся CVS-хранилища FreeBSD.

Новые коммиттеры портов выдвигаются действующим коммиттером портов, который хочет выступать в роли наставника. Представление должно включать краткое описание вклада, который внёс представляемый новый коммиттер, в частности, количество присланных сообщений об ошибках, количество портов, поддерживаемых им на данный момент, а также наличие прав на выполнение коммитов в других деревьях, если они есть.

При голосовании группа будет рассматривать эту историю наравне со всеми прочими имеющими отношение к делу факторами. Результаты голосования доводятся до сведения сообщества разработчиков FreeBSD.

В соответствии с практикой, применяемой в проекте в целом, неактивные коммиттеры портов периодически опрашиваются на предмет выяснения их состояния и интереса к продолжению работы над деревом портов. Коммиттеры, которые не отвечают на подобные электронные послания, или отвечают негативно, теряют свои права на выполнение коммитов. В настоящее время этот период равен одному году.

В исключительных случаях может появиться необходимость в удалении коммиттеров портов и по другим причинам. Это будет выполняться после серьёзного обдумывания и является предметом рассмотрения Правлением.

== Разработка руководств и политик, описывающих права и обязанности коммиттеров и сопровождающих портов

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

Для обеспечения своевременной обработки сообщений об ошибках, касающихся портов, portmgr разработал руководство о том, как долго PR, назначенная коммиттеру, может оставаться открытой до момента, когда её сможет решить другой коммиттер через "тайм-аут от сопровождающего". На данный момент этот срок установлен в две недели (не считая заморозок портов и общепринятые праздничные дни.)

Кроме того, чтобы обеспечить своевременную поддержку портов, portmgr разработал руководство относительно того, как долго сопровождающий порта может быть неактивным без лишения его прав на статус сопровождающего. "Неактивность" понимается здесь не в буквальном смысле, однако предназначена для контроля таких вещей, как нерешённые открытые PR, выполнение коммитов другими людьми при молчании сопровождающего, а также нерешённые проблемы построения. на данный момент этот период определён в три месяца.

Целью таких правил не является определение наказания или вины, но они должны отражать тот факт, что программное обеспечение, установленное через Коллекцию Портов, быстро развивается без контроля FreeBSD. Частью забот, которую несёт сопровождающий порта, является поддержание порта в работоспособном и обновлённом состоянии, насколько это возможно. Было бы несправедливо по отношению к нашим пользователям относиться к решению проблем с прохладцей и позволять использовать старые версии. Однако мы также понимаем, что все наши сопровождающие и коммиттеры являются такими же добровольцами, как и мы, поэтому, как и в любом добровольном проекте, легко перегрузить себя работой или потерять интерес к некоторому порту.

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

== Определение приоритетов будущих направлений развития Коллекции Портов в целом

portmgr осознаёт, что разработка и развитие Коллекции Портов в первую очередь ведётся руками участников сообщества. Однако, из-за отсутствия веток в Коллекции Портов, иногда необходимо координировать и даже делать выбор между предлагаемыми изменениями.

В некотором смысле это подразумевается выбор того, какие именно патчи будут приняты для тестирования в кластере построения, а также выработка консенсуса между разными архитектурными подходами, создание списка "интересных проектов" и так далее.
