Участие в проекте FreeBSD | FreeBSD Documentation Portal
Description: Как внести вклад в проект FreeBSD
Keywords: Contributing,FreeBSD,Non-Programmer Tasks,Programmer Tasks

# Участие в проекте FreeBSD

Этот перевод может быть устаревшим. Для того, чтобы помочь с переводом, пожалуйста, обратитесь к Сервер переводов FreeBSD.

товарные знаки

FreeBSD является зарегистрированным товарным знаком Фонда FreeBSD.

IEEE, POSIX и 802 являются зарегистрированными товарными знаками Institute of Electrical and Electronics Engineers, Inc. в Соединённых Штатах.

Многие из обозначений, используемые производителями и продавцами для обозначения своих продуктов, заявляются в качестве товарных знаков. Когда такие обозначения появляются в этом документе, и Проекту FreeBSD известно о товарном знаке, к обозначению добавляется знак “™” или “®”.

Аннотация

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

Итак, вы хотите внести свой вклад в FreeBSD? Это замечательно! FreeBSD полагается на вклад своих пользователей для существования. Ваши усилия не только ценятся, они жизненно важны для дальнейшего развития FreeBSD.

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

В качестве волонтёра вы ограничены только тем, чем хотите заниматься. Однако мы просим вас учитывать ожидания других участников сообщества FreeBSD. Возможно, вам стоит принять это во внимание, прежде чем решить стать волонтёром.

Проект FreeBSD отвечает за целостную операционную среду, а не только за ядро или несколько разрозненных утилит. Таким образом, наши списки TODO охватывают очень широкий спектр задач: от документации, бета-тестирования и презентаций до установщика системы и высокоспециализированных видов разработки ядра. Люди с любым уровнем навыков, практически в любой области, почти наверняка могут помочь проекту.

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

## 1. Что необходимо

Следующий список задач и подпроектов представляет собой своего рода объединение различных списков TODO и запросов пользователей.

### 1.1. Текущие задачи для непрограммистов

Многие люди, участвующие в FreeBSD, не являются программистами. Проект включает в себя авторов документации, веб-дизайнеров и специалистов поддержки. Всё, что нужно этим людям для участия, — это вложение времени и готовность учиться.

1. Периодически перечитывайте FAQ и Руководство. Если что-то объяснено недостаточно ясно, неоднозначно, устарело или неверно, дайте нам знать. Ещё лучше — пришлите нам исправление (AsciiDoc несложно изучить, но можно присылать и обычный текст).

2. Помогите перевести документацию FreeBSD на ваш родной язык. Если документация уже существует на вашем языке, вы можете помочь перевести дополнительные документы или проверить, что переводы актуальны и корректны. Сначала ознакомьтесь с FAQ по переводам в Руководстве проекта документации FreeBSD. Вы не обязаны переводить каждый документ FreeBSD — как волонтер, вы можете переводить столько, сколько пожелаете. Как только кто-то начинает переводить, к этому процессу почти всегда присоединяются другие. Если у вас есть время и силы перевести только часть документации, пожалуйста, переведите инструкции по установке.

3. Читайте Список рассылки, посвящённый вопросам и ответам пользователей FreeBSD время от времени (или даже регулярно). Может быть очень приятно делиться своими знаниями и помогать людям решать их проблемы; иногда вы даже можете узнать что-то новое для себя! Эти форумы также могут быть источником идей для улучшений.

### 1.2. Текущие задачи программистов

Большинство перечисленных здесь задач может потребовать значительных временных затрат, глубоких знаний о ядре FreeBSD или того и другого. Однако, есть также множество полезных задач, подходящих для "хакеров выходного дня".

1. Если вы используете FreeBSD-CURRENT и имеете хорошее подключение к интернету, существует машина `current.FreeBSD.org`, которая ежедневно собирает полный релиз — время от времени пробуйте установить последний релиз с неё и сообщайте о любых сбоях в процессе.

2. Разберитесь, какие изменения были предложены или о каких проблемах было сообщено. Возможно, там есть проблема, по которой вы можете конструктивно высказаться, или патчи, которые вы можете протестировать. Или вы даже можете попытаться исправить одну из проблем самостоятельно.

3. Один из способов — прочитать Список рассылки FreeBSD, посвящённый сообщениям о проблемах (для проблем, отправленных с помощью Bugzilla).

4. Если вам известны исправления ошибок, которые были успешно применены в -CURRENT, но не были перенесены в -STABLE в течение разумного срока (обычно пары недель), отправьте коммиттеру вежливое напоминание.

5. Переместите стороннее программное обеспечение в src/contrib в дереве исходных кодов.

6. Убедитесь, что код в src/contrib актуален.

7. Соберите дерево исходников (или только его часть) с включенными дополнительными предупреждениями и устраните эти предупреждения. Список предупреждений при сборке также можно найти в нашем CI, выбрав сборку и отметив "LLVM/Clang Warnings".

8. Исправление предупреждений для портов, которые используют устаревшие функции, такие как `gets()` или включают malloc.h.

9. Если вы внесли свой вклад в какие-либо порты и вам пришлось внести изменения, специфичные для FreeBSD, отправьте свои исправления оригинальным авторам (это облегчит вашу жизнь, когда они выпустят следующую версию).

10. Получите копии официальных стандартов, таких как POSIX®. Сравните поведение FreeBSD с требованиями стандарта. Если поведение отличается, особенно в сложных или малоизученных аспектах спецификации, отправьте PR об этом. Если вы можете, предложите исправление и включите патч в PR. Если вы считаете, что стандарт ошибочен, обратитесь в орган по стандартизации с просьбой рассмотреть этот вопрос.

11. Предложите дополнительные задачи для этого списка!

### 1.3. Пройдитесь по базе данных отчётов о проблемах Bugzilla

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

Начните с PR, которые никому не назначены. Если PR назначен кому-то другому, но вам кажется, что вы можете с ним справиться, напишите этому человеку на почту и спросите, можно ли вам над ним поработать — возможно, у него уже есть готовый патч для тестирования или дополнительные идеи, которые можно обсудить.

### 1.4. Текущие задачи портов

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

Вовлечься может любой, и способов для этого множество. Участие в разработке портов — отличный способ "отдать долг" проекту. Будь то поиск постоянной роли или интересный вызов на дождливый день — мы будем рады вашей помощи!

Есть несколько простых способов помочь поддерживать дерево портов в актуальном состоянии и в хорошем рабочем порядке:

- Найдите интересное или полезное программное обеспечение и создайте порт для него.

- Существует множество портов, у которых нет сопровождающего. Станьте сопровождающим и Возьмите на сопровождение неподдерживаемый порт.

- Если вы создали или адаптировали порт, обратите внимание на раздел Задача для сопровождающих портов.

- Если вы ищете быстрый вызов, вы можете Найти и исправить сломанный порт.

### 1.5. Выберите один из пунктов со страницы Идеи

Список проектов и идей FreeBSD для волонтёров также доступен для тех, кто хочет внести свой вклад в проект FreeBSD. Список регулярно обновляется и содержит пункты как для программистов, так и для не-программистов, с информацией о каждом проекте.

## 2. Как внести свой вклад

Вклады в систему обычно относятся к одной или нескольким из следующих 5 категорий:

### 2.1. Отчёты об ошибках и общие комментарии

Идея или предложение, представляющие общий технический интерес, должны быть отправлены на Список рассылки FreeBSD, посвящённый техническим обсуждениям. Аналогично, люди, заинтересованные в подобных вещах (и готовые терпеть большой объём почты!), могут подписаться на Список рассылки FreeBSD, посвящённый техническим обсуждениям. Дополнительную информацию об этом и других списках рассылки см. в The FreeBSD Handbook.

Если вы отправляете простой патч в репозиторий src, рассмотрите возможность отправить его в зеркало проекта на GitHub как запрос на включение. Подходящие отправки должны:

- Готово или почти готово для включения. Коммиттер должен быть в состоянии применить этот патч с менее чем 10 минутами дополнительной работы.

- Он проходит все задания GitHub CI.

- Вы можете быстро реагировать на обратную связь.

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

- Каждое логическое изменение — это отдельный коммит в рамках pull request. Сообщения коммитов для каждого изменения должны соответствовать руководству по оформлению логов коммитов.

- Все коммиты содержат ваше имя и действительный адрес электронной почты, которые вы хотите видеть в репозитории FreeBSD в качестве автора. Поддельные адреса github.com использовать нельзя.

- Объём pull request не должен меняться в процессе проверки. Если в ходе проверки предложены изменения, расширяющие объём, создайте отдельный pull request.

- Исправляющие коммиты должны быть объединены (squash) с коммитом, который они исправляют. Каждый коммит в вашей ветке должен быть пригоден для репозитория FreeBSD.

- Коммиты должны включать одну или несколько строк `Signed-off-by:` с полным именем и адресом электронной почты, подтверждающими Сертификат происхождения разработчика.

При обновлении запроса на включение изменений, пожалуйста, выполняйте перебазирование с принудительной отправкой (forced push), а не слиянием через коммит (merge commit). Более сложные изменения могут быть отправлены как запросы на включение (pull request), но они могут быть отклонены и закрыты, если они слишком большие, слишком громоздкие, становятся неактивными, требуют дополнительного обсуждения в сообществе или нуждаются в значительной доработке. Пожалуйста, избегайте создания больших, широкомасштабных патчей для очистки: они слишком велики и не обладают необходимой фокусировкой для качественного рецензирования. Патчи, отправленные не по адресу, могут быть перенаправлены в более подходящий форум для их доработки.

Запросы на включение изменений, отправленные в репозиторий портов, могут быть обработаны или проигнорированы, в зависимости от настроения разработчиков. На данный момент, вам будет проще, если вы будете следовать процессу отправки портов Вклад в порты.

Команда документации также принимает pull requests через GitHub, но пока не установила для них никакой политики.

Если вы обнаружили ошибку или хотите отправить конкретное изменение, пожалуйста, сообщите об этом, используя форму Bugzilla отправки отчёта об ошибках. Постарайтесь заполнить каждое поле отчёта. Если патчи не превышают 65 КБ, включите их непосредственно в отчёт. Если патч подходит для применения к исходному дереву, укажите `[PATCH]` в кратком описании отчёта. При включении патчей не используйте копирование и вставку, так как это превращает табуляции в пробелы и делает их непригодными. Если патчи значительно превышают 20 КБ, рассмотрите возможность их сжатия (например, с помощью gzip(1) или bzip2(1)) перед загрузкой.

После подачи отчёта вы должны получить подтверждение вместе с номером для отслеживания. Сохраните этот номер, чтобы вы могли сообщить нам дополнительные сведения о проблеме.

См. также эту статью о том, как писать хорошие отчёты о проблемах.

### 2.2. Изменения в документации

Изменения в документации контролируются Список рассылки Проекта Документации FreeBSD. Пожалуйста, ознакомьтесь с руководством Проект документации FreeBSD: введение для новых участников для получения полных инструкций. Отправляйте исправления и изменения (даже небольшие правки приветствуются!) тем же способом, что и другие отчёты об ошибках.

### 2.3. Изменения в существующем исходном коде

Добавление или изменение существующего исходного кода — это несколько более сложная задача, которая во многом зависит от того, насколько сильно вы отстали от текущего состояния разработки FreeBSD. Существует специальная постоянно обновляемая версия FreeBSD, известная как "FreeBSD-CURRENT", которая доступна различными способами для удобства разработчиков, активно работающих над системой. Подробнее о получении и использовании FreeBSD-CURRENT можно узнать в Руководстве FreeBSD.

Работа с устаревшими исходниками, к сожалению, означает, что ваши изменения иногда могут быть слишком устаревшими или слишком расходящимися для лёгкого повторного включения в FreeBSD. Шансы на это можно несколько уменьшить, подписавшись на списки рассылки Список рассылки анонсов FreeBSD и Список рассылки, посвящённый обсуждению FreeBSD-CURRENT, где обсуждается текущее состояние системы.

Предполагая, что вам удалось получить достаточно актуальные исходные коды для внесения изменений, следующий шаг — создать набор различий (diff) для отправки сопровождающим FreeBSD. Это делается с помощью команды diff(1).

Предпочтительным форматом diff(1) для отправки исправлений является унифицированный формат вывода, создаваемый командой `diff -u`.

    % diff -u oldfile newfile

или

    % diff -u -r -N olddir newdir

сгенерирует набор унифицированных diff-файлов для указанного исходного файла или иерархии каталогов.

См. diff(1) для получения дополнительной информации.

После того как у вас есть набор изменений (которые вы можете проверить с помощью команды patch(1)), вы можете отправить их для включения в FreeBSD в виде отчёта об ошибке в Bugzilla. Не отправляйте изменения просто на Список рассылки FreeBSD, посвящённый техническим обсуждениям, иначе они могут потеряться! Мы очень ценим ваши предложения (это добровольный проект!); поскольку мы заняты, мы не всегда можем обработать их сразу, но они останутся в базе данных PR, пока мы не дойдем до них. Укажите, что это предложение изменений, добавив `[PATCH]` в заголовок отчёта.

Если вы считаете это уместным (например, вы добавили, удалили или переименовали файлы), упакуйте свои изменения в файл `tar`.

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

Пожалуйста, обратитесь к intro(9) и style(9) для получения информации о стиле написания кода. Мы будем признательны, если вы хотя бы ознакомитесь с этой информацией перед отправкой кода.

### 2.4. Новый код или основные пакеты с добавленной стоимостью

В случае значительного вклада в виде большого объёма работы или добавления важной новой функции в FreeBSD, почти всегда необходимо либо отправить изменения в виде tar-файлов, либо загрузить их на веб- или FTP-сайт для доступа других людей. Если у вас нет доступа к веб- или FTP-сайту, запросите на соответствующем списке рассылки FreeBSD, чтобы кто-то разместил изменения для вас.

При работе с большими объёмами кода неизбежно возникает деликатная тема авторских прав. FreeBSD предпочитает свободные лицензии, такие как BSD или ISC. Копилефтные лицензии (copyleft — требование той же лицензии для производных продуктов), например GPLv2, иногда допускаются. Полный список можно найти на странице политики лицензирования основной команды.

### 2.5. Деньги или оборудование

Мы всегда рады пожертвованиям для поддержки проекта FreeBSD, и в добровольческих усилиях, подобных нашим, даже небольшая помощь может иметь большое значение! Пожертвования оборудования также очень важны для расширения списка поддерживаемых периферийных устройств, поскольку у нас обычно нет средств на их приобретение.

#### 2.5.1. Пожертвование средств

Фонд FreeBSD (FreeBSD Foundation) — это некоммерческий, освобожденный от налогов фонд, созданный для поддержки целей проекта FreeBSD. Как организация 501(c)3, Фонд, как правило, освобожден от федерального подоходного налога США, а также от подоходного налога штата Колорадо. Пожертвования освобожденным от налогов организациям часто вычитаются из налогооблагаемого федерального дохода.

Пожертвования можно отправить в виде чека по адресу:

The FreeBSD Foundation
3980 Broadway Street
STE #103-107
Boulder CO 80304
USA

Фонд FreeBSD также принимает онлайн-пожертвования через различные варианты оплаты.

Дополнительная информация о Фонде FreeBSD доступна по ссылке Фонд FreeBSD — введение. Чтобы связаться с Фондом по электронной почте, напишите на info@FreeBSDFoundation.org.

#### 2.5.2. Пожертвование оборудования

Проект FreeBSD с благодарностью принимает пожертвования в виде оборудования, которое может быть полезно для проекта. Если вы хотите пожертвовать оборудование, пожалуйста, свяжитесь с Офисом по связям с пожертвованиями.

## 3. Вклад в порты

### 3.1. Принятие сопровождения неподдерживаемого порта

#### 3.1.1. Выбор неподдерживаемого порта

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

Неподдерживаемые порты имеют параметр `MAINTAINER`, установленный в `ports@FreeBSD.org`. Многие неподдерживаемые порты могут иметь ожидающие обновления, это можно увидеть на сканере дистрибутивных файлов портов FreeBSD.

На PortsFallout можно увидеть список неподдерживаемых портов с ошибками.

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

Вы можете узнать, есть ли у порта зависимости или вторичные порты, посмотрев в основной индекс портов под названием INDEX. (Имя файла может различаться в зависимости от версии FreeBSD; например, INDEX-13.) Некоторые порты имеют условные зависимости, которые не включены в стандартную сборку INDEX. Мы ожидаем, что вы сможете распознать такие порты, просмотрев Makefile других портов.

#### 3.1.2. Как принять сопровождение порта

Убедитесь, что вы понимаете раздел Задача для сопровождающих портов. Также прочитайте Руководство FreeBSD по созданию портов. Пожалуйста, не берите на себя больше, чем вам комфортно выполнять.

Вы можете запросить статус сопровождающего для любого неподдерживаемого порта, как только пожелаете. Просто установите `MAINTAINER` на ваш собственный адрес электронной почты и отправьте PR (отчёт о проблеме) с этим изменением. Если порт имеет ошибки сборки или нуждается в обновлении, вы можете включить другие изменения в тот же PR. Это поможет, поскольку многие коммиттеры менее склонны назначать сопровождающего тому, у кого нет известной истории работы с FreeBSD. Отправка PR, исправляющих ошибки сборки или обновляющих порты, — лучший способ её установить.

Подайте ваш PR в категорию `Порты и пакеты`. Коммиттер проверит ваш PR, закоммитит изменения и в конце закрыт PR. Иногда этот процесс может занять некоторое время (коммиттеры тоже волонтеры :).

### 3.2. Задача для сопровождающих портов

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

#### 3.2.1. Почему порты требуют обслуживания

Создание порта — это разовая задача. Обеспечение актуальности порта, его сборки и работы требует постоянных усилий по поддержке. Поддерживающие (maintainers) — это люди, которые посвящают часть своего времени достижению этих целей.

Основная причина, по которой порты требуют обслуживания, — это предоставление новейших и лучших сторонних программных решений сообществу FreeBSD. Дополнительная задача — обеспечение работоспособности отдельных портов в рамках коллекции Ports по мере её развития.

Как сопровождающему, вам потребуется управлять следующими задачами:

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

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

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

- Взаимодействие с другими пользователями, сопровождающими и разработчиками. Часть обязанностей сопровождающего включает в себя поддержку. От вас не ожидают предоставления общей поддержки (но мы приветствуем это, если вы решите её оказывать). Ваша задача — быть точкой координации по вопросам, связанным с вашими портами, специфичным для FreeBSD.

- Поиск ошибок. Порт может быть подвержен ошибкам, специфичным для FreeBSD. Вам потребуется исследовать, находить и исправлять эти ошибки при их поступлении. Ещё лучше тщательно тестировать порт для выявления проблем до их попадания в Коллекцию портов.

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

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

#### 3.2.2. Обязанности сопровождающего

##### Поддерживайте свои порты в актуальном состоянии

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

Это общий обзор. Дополнительная информация об обновлении порта доступна в Руководстве FreeBSD по созданию портов.

1. Следите за обновлениями

   Отслеживайте у вышестоящего поставщика появление новых версий, обновлений и исправлений безопасности для программного обеспечения. Для этого полезны списки рассылки объявлений или новостные веб-страницы. Иногда пользователи могут связаться с вами и спросить, когда ваш порт будет обновлен. Если вы заняты другими делами или по какой-либо причине просто не можете обновить его в данный момент, спросите, могут ли они помочь вам, предоставив обновление.

   Вы также можете получать автоматические письма от `FreeBSD Ports Version Check`, уведомляющие о доступности новой версии дистрибутивного файла вашего порта. В сообщении будет предоставлена дополнительная информация об этой системе (включая инструкции по остановке будущих писем).

2. Вносите изменения

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

3. Проверяйте и тестируйте

   Тщательно проверьте и протестируйте свои изменения:

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

   - Убедитесь, что зависимости вашего порта полные. Рекомендуемый способ сделать это — установить собственный tinderbox для портов. Дополнительную информацию см. в Ресурсы для сопровождающих и участников разработки портов.

   - Проверьте, что список упаковки актуален. Это включает добавление новых файлов и каталогов и удаление неиспользуемых записей.

   - Проверьте ваш порт, используя portlint(1) в качестве помощника. См. Ресурсы для сопровождающих и участников портов для важной информации об использовании portlint.

   - Подумайте, могут ли изменения в вашем порту привести к проблемам в других портах. Если это так, согласуйте изменения с их сопровождающими. Это особенно важно, если ваше обновление изменяет версию разделяемой библиотеки; в этом случае, как минимум, зависимые порты должны получить увеличение `PORTREVISION`, чтобы автоматизированные инструменты, такие как ports-mgmt/poudriere, могли их обновить.

4. Представляйте изменения

   Отправьте ваше обновление, создав отчет о проблеме с описанием изменений и патчем, содержащим различия между исходным портом и обновлённым. Обратитесь к статье Составление сообщений о проблеме во FreeBSD для получения информации о том, как правильно оформить PR.

   | Пожалуйста, не отправляйте архив shar(1) всего порта; вместо этого используйте git-format-patch(1) или diff(1) `-ruN`. Таким образом, коммиттеры смогут гораздо проще увидеть, какие именно изменения были внесены. Раздел Обновление в Руководстве FreeBSD по созданию портов содержит дополнительную информацию.

5. Ждите

   На каком-то этапе коммиттер рассмотрит ваш PR. Это может занять минуты, а может и одну-две недели — так что проявите терпение. Если это займёт больше времени, обратитесь за помощью в почтовые рассылки (Список рассылки, посвящённый Портам FreeBSD), IRC: #bsdports на EFNet или #freebsd-ports на Libera, например.

6. Предоставляйте обратную связь

   Если участник проекта обнаружит проблему в ваших изменениях, он, скорее всего, вернёт их вам на доработку. Быстрый ответ поможет ускорить принятие вашего PR, а также упростит поддержание последовательности обсуждения при попытке разрешить возникшие проблемы.

7. И наконец

   Ваши изменения будут зафиксированы, и ваш порт будет обновлен. Затем PR будет закрыт коммиттером. Вот и все!

##### Убедитесь, что ваши порты продолжают собираться корректно

Этот раздел посвящён обнаружению и исправлению проблем, которые мешают правильной сборке портов.

FreeBSD гарантирует работоспособность Коллекции портов только в ветках `-STABLE`. Теоретически можно обойтись использованием последних выпусков каждой стабильной ветки (поскольку ABI не должны меняться), но если есть возможность использовать саму ветку, это ещё лучше.

Поскольку большинство установок FreeBSD работают на PC-совместимых машинах (так называемая архитектура `i386`), мы ожидаем, что порт будет работать на этой архитектуре. Мы предпочитаем, чтобы порты также работали на архитектуре `amd64` в нативном режиме. Совершенно допустимо попросить о помощи, если у вас нет одной из таких машин.

| Обычные режимы сбоя для машин не на архитектуре `x86` связаны с предположениями оригинальных программистов, например, что указатели являются `int`-ами, или что используется относительно старый и менее строгий компилятор gcc. Все чаще авторы приложений перерабатывают свой код, чтобы устранить эти предположения — но если автор не занимается активной поддержкой своего кода, вам, возможно, придется сделать это самостоятельно.

Вот задачи, которые необходимо выполнить, чтобы убедиться, что ваш порт может быть собран:

1. Следите за ошибками сборки

   Проверьте свою почту на наличие писем от `pkg-fallout@FreeBSD.org` и сканера distfiles, чтобы узнать, не устарели ли какие-либо порты, которые не собираются.

2. Собрать информацию

   Как только вы обнаружили проблему, соберите информацию, которая поможет её исправить. Ошибки сборки, о которых сообщает `pkg-fallout`, сопровождаются журналами, показывающими, где произошёл сбой. Если о проблеме сообщил пользователь, попросите его предоставить данные, которые могут помочь в диагностике, например:

   - Логи сборки

   - Команды и параметры, используемые для сборки порта (включая параметры, установленные в /etc/make.conf)

   - Список пакетов, установленных в системе, как показано в pkg-info(8)

   - Версия FreeBSD, которую они используют, как показано в uname(1) `-a`

   - Когда их коллекция портов была последний раз обновлена

   - Когда их дерево портов и файл INDEX были последний раз обновлены

3. Изучить и найти решение

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

4. Представляйте изменения

   Как и при обновлении порта, теперь вам следует внести изменения, проверить и протестировать их, отправить изменения в PR и, если требуется, предоставить обратную связь.

5. Отправляйте исправления авторам вышестоящих проектов

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

##### Изучать отчёты об ошибках и отчеты о проблемах Bugzilla, связанные с вашим портом

Этот раздел посвящён поиску и исправлению ошибок.

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

Вот задачи, которые необходимо выполнить, чтобы ваш порт продолжал работать должным образом:

1. Отвечать на отчёты об ошибках

   Ошибки могут быть сообщены вам по электронной почте через базу данных отчётов о проблемах Bugzilla. Также пользователи могут сообщать об ошибках напрямую вам.

   Вы должны отвечать на PR и другие сообщения в течение 14 дней, но постарайтесь не затягивать так долго. Старайтесь отвечать как можно скорее, даже если это просто сообщение о том, что вам нужно ещё немного времени, прежде чем вы сможете заняться PR.

   Если вы не ответили в течение 14 дней, любой коммиттер может выполнить коммит из PR, на который вы не ответили, используя `maintainer-timeout`.

2. Собрать информацию

   Если человек, сообщивший об ошибке, также не предоставил исправление, вам необходимо собрать информацию, которая позволит вам создать исправление.

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

   - Подробное описание их действий, ожидаемого поведения программы и фактического поведения

   - Копии входных данных, использованных для выявления ошибки

   - Информация о среде сборки и выполнения — например, список установленных пакетов и вывод команды env(1)

   - Файлы дампов ядра

   - Стеки вызовов функций

3. Устраните некорректные отчёты

   Некоторые отчёты об ошибках могут быть некорректными. Например, пользователь мог просто неправильно использовать программу; или установленные пакеты могут быть устаревшими и требовать обновления. Иногда сообщаемая ошибка не специфична для FreeBSD. В этом случае следует сообщить об ошибке разработчикам вышестоящего проекта. Если ошибка находится в пределах ваших возможностей для исправления, вы также можете исправить порт, чтобы исправление было применено до следующего релиза вышестоящего проекта.

4. Найдите решение

   Как и с ошибками сборки, вам потребуется найти решение проблемы. И снова, не забывайте спросить, если застряли!

5. Представить или утвердить изменения

   Как и при обновлении порта, теперь вам следует внести изменения, проверить и протестировать их, а затем отправить изменения в PR в Bugzilla (или отправить дополнение, если PR для данной проблемы уже существует). Если другой пользователь отправил изменения в PR, вы также можете отправить дополнение, указав, одобряете ли вы эти изменения или нет.

##### Предоставление поддержки

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

Время от времени вам может понадобиться проявить дипломатические навыки и вежливо направить пользователей, ищущих общую поддержку, к соответствующим ресурсам. Реже вы столкнётесь с людьми, спрашивающими, почему `RPMS` не обновлены или как запустить программное обеспечение под Foo Linux. Воспользуйтесь возможностью сообщить им, что ваш порт актуален (если это так, конечно!), и предложите попробовать FreeBSD.

Иногда пользователи и разработчики решают, что вы занятой человек, чьё время ценно, и выполняют часть работы за вас. Например, они могут:

- отправить PR в Bugzilla или прислать свои патчи для обновления вашего порта,

- исследовать и, возможно, предоставить исправление для PR, или

- иначе отправить изменения в ваш порт.

В этих случаях ваша основная обязанность — своевременно отвечать. Напоминаем, что срок ожидания ответа от сопровождающего составляет 14 дней. По истечении этого периода изменения могут быть зафиксированы без одобрения. Они потрудились сделать это за вас; пожалуйста, постарайтесь хотя бы оперативно ответить. Затем как можно скорее проверьте, одобрите, измените или обсудите их изменения с ними.

Если вы сможете дать им почувствовать, что их вклад ценится (а так и должно быть), у вас будет больше шансов убедить их сделать для вас больше в будущем :-).

### 3.3. Поиск и исправление сломанного порта

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

Вы можете использовать веб-интерфейс базы данных отчётов о проблемах для поиска и просмотра нерешенных PR в Bugzilla. Большинство PR для портов — это обновления, но с небольшим поиском и беглым просмотром описаний вы сможете найти что-то интересное для работы.

PortsFallout отображает проблемы с портами, собранные при сборке пакетов FreeBSD.

Допустимо отправлять изменения и для поддерживаемого порта, но не забудьте уточнить у сопровождающего, не работает ли он уже над этой проблемой.

Как только вы обнаружили ошибку или проблему, соберите информацию, изучите её и исправьте! Если уже существует PR, продолжите работу с ним. В противном случае создайте новый PR. Ваши изменения будут проверены и, если всё в порядке, приняты.

### 3.4. Как прекратить сопровождение

По мере изменения ваших интересов и обязательств вы можете обнаружить, что у вас больше нет времени продолжать некоторые (или все) ваши вклады в порты. Это нормально! Пожалуйста, сообщите нам, если вы больше не используете порт или у вас нет времени или интереса продолжать быть его сопровождающим. Таким образом, мы сможем позволить другим людям попытаться решить существующие проблемы с портом, не дожидаясь вашего ответа. Помните, FreeBSD — это добровольный проект, поэтому если сопровождение порта больше не приносит удовольствия, вероятно, пришло время позволить кому-то другому заняться этим!

В любом случае, команда управления портами (`portmgr`) оставляет за собой право сбросить ваше право сопровождения, если вы не поддерживали свой порт в течение некоторого времени. (В настоящее время этот срок установлен в 3 месяца.) Под этим подразумевается, что есть нерешенные проблемы или ожидающие обновления, над которыми не велась работа в течение этого времени.

### 3.5. Ресурсы для сопровождающих и участников портов

Руководство FreeBSD по созданию портов — это ваш путеводитель по системе портов. Держите его под рукой!

Статья Составление сообщений о проблеме во FreeBSD описывает, как лучше всего сформулировать и отправить PR. Следование этой статье значительно поможет нам сократить время, необходимое для обработки ваших PR.

База данных отчётов о проблемах Bugzilla.

Сканер дистрибутивных файлов портов FreeBSD (portscout) FreeBSD Ports distfile scanner (portscout) может показать вам порты, для которых дистрибутивные файлы недоступны для загрузки. Вы можете проверить свои собственные порты или использовать его для поиска портов, которым требуется обновление `MASTER_SITES`.

ports-mgmt/poudriere — это наиболее тщательный способ проверить порт на протяжении всего цикла установки, упаковки и удаления. Документация находится в репозитории poudriere на GitHub

portlint(1) — это приложение, которое можно использовать для проверки соответствия вашего порта многим важным стилистическим и функциональным рекомендациям. portlint — это простое эвристическое приложение, поэтому его следует использовать только в качестве ориентира. Если portlint предлагает изменения, которые кажутся необоснованными, обратитесь к Руководству портировщика или попросите совета.

Список рассылки, посвящённый Портам FreeBSD предназначен для общих обсуждений, связанных с портами. Это хорошее место для поиска помощи. Вы можете subscribe, читать и искать в архивах списка. Также может быть полезно ознакомиться с архивами Список рассылки, посвящённый ошибкам в портах FreeBSD и SVN commit messages for the ports tree for head/.

PortsFallout — это место для помощи в поиске по архиву FreeBSD package-fallout.

## 4. Начало работы в других областях

Ищете что-то интересное для начала работы, что не упоминается в этой статье? Проект FreeBSD имеет несколько страниц на Wiki, содержащих области, в которых новые участники могут найти идеи о том, как начать.

Страница Junior Jobs содержит список проектов, которые могут быть интересны тем, кто только начинает работать с FreeBSD и хочет попробовать свои силы в интересных задачах.

Страница идей содержит различные «приятные» или «интересные» вещи для работы в Проекте.

Изменено: 18 июня 2026 г. by Alexander Ziaee