2. Как принять участие в работе

2.1. Сообщения об ошибках и отзывы общего характера

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

Если вы нашли ошибку или предлагаете внести какое-то конкретное исправление, пожалуйста, отправьте сообщение при помощи программы send-pr(1) или её Web-эквивалента. Постарайтесь заполнить все поля в сообщении об ошибке. Если его размер оно не превышает 65 Кбайт, включите все патчи непосредственно в сообщение. Если патч предназначен для дерева исходных текстов, поместите [PATCH] в теме сообщения. При включении патчей не используйте технику cut-and-paste, потому что при этом символы табуляции преобразуются в пробелы и патч становится непригодным к использованию. Если объём патчей превышает 20 Кбайт, лучше включать их в сообщение в сжатом виде, для чего упакуйте их (например, при помощи gzip(1) или bzip2(1)) и обработайте архив утилитой uuencode(1).

После отправки сообщения вы должны получить подтверждение и номер для отслеживания. Сохраните этот номер, чтобы использовать его в дальнейшем при направлении подробностей о проблеме по электронной почте на адрес <bug-followup@FreeBSD.org>. Используйте номер в качестве темы письма, например, "Re: kern/3377". Дополнительная информация о любом сообщении об ошибке должна направляться этим способом.

Если вы не получили подтверждения в течение разумного периода времени (от 3 дней до недели, в зависимости от вашего подключения к электронной почты) или по какой-то причине не можете воспользоваться командой send-pr(1), то можете попросить кого-нибудь направить сообщение за вас на адрес Список рассылки FreeBSD, посвящённый сообщениям о проблемах.

Прочтите также эту статью, чтобы узнать, как писать хорошие сообщения о проблемах.

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

Изменения в документации обсуждаются в Список рассылки Проекта Документации FreeBSD. Пожалуйста, посмотрите Учебник Проекта документирования FreeBSD для получения полных инструкций. Посылайте свои пожелания и изменения (принимаются даже самые небольшие!) при помощи send-pr(1), как это описано в разделе о сообщениях об ошибках и общих пожеланиях.

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

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

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

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

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

К примеру:

% diff -c oldfile newfile

или

% diff -c -r olddir newdir

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

Подобным же образом

% diff -u oldfile newfile

или

% diff -u -r olddir newdir

сделают то же самое, но в унифицированном diff-формате.

Дополнительную информацию можно найти на странице справки по команде diff(1).

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

Если вы считаете, что это нужно (к примеру, вы добавляли, удаляли или переименовывали файлы), то объедините ваши изменения в tar-файл и обработайте его программой uuencode(1). Принимаются также и архивы, созданные программой shar(1).

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

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

2.4. Новый код или большие дополнительные пакеты

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

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

1. Лицензионное соглашение BSD. Оно является самым предпочтительным из-за ''отсутствия дополнительных условий'' и общей привлекательности для коммерческих компаний. Проект FreeBSD далёк от того, чтобы выступать против коммерческого использования, но активно популяризирует такое пересечение коммерческих интересов, которое позволит постепенно запустить механизм инвестиций во FreeBSD.

2. GNU General Public License, или ''GPL''. Это лицензионное соглашение не очень популярно у нас из-за объёма требований, которые нужно выполнять всем, кто собирается использовать код в коммерческих целях. Однако, учитывая абсолютное превосходство объёма этого кода (компилятор, ассемблер, инструменты форматирования текста и так далее) было бы глупо отказываться от дополнительных разработок, подпадающих под действие этой лицензии. Код, распространяемый по условиям лицензионного соглашения GPL также размещается в отдельной части дерева исходных текстов, в /sys/gnu или /usr/src/gnu, и поэтому легко идентифицируется всяким, для кого GPL представляет проблему.

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

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

Copyright (c) %%полные_номера_годов%%
	%%ваше_имя%%, %%ваш_штат%%  %%ваш_почтовый_индекс%%.
	All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
   notice, this list of conditions and the following disclaimer as
   the first lines of this file unmodified.
2. Redistributions in binary form must reproduce the above copyright
   notice, this list of conditions and the following disclaimer in the
   documentation and/or other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED BY %%your_name_here%% ``AS IS'' AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL %%your_name_here%% BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

	$Id$

Для вашего удобства копия этого текста размещена в файле /usr/share/examples/etc/bsd-style-copyright.

2.5. Деньги, оборудование или Internet-доступ

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