Версия для печати

Архив документации на OpenNet.ru / Раздел "Руководства по FreeBSD на русском" (Многостраничная версия)

Составление сообщений о проблеме во FreeBSD

Dag-Erling SmЬrgrav

$FreeBSD$

Legal Notice

Эта статья описывает, как наилучшим образом сформулировать и отправить сообщение о проблеме в Проект FreeBSD.

[ Split HTML / Single HTML ]

Table of Contents
1. Введение
2. Когда нужно отправлять сообщение о проблеме
3. Подготовка
4. Написание сообщения о проблеме
5. Отслеживание
6. Дополнительная литература

1. Введение

Одной из самых разочаровывающих практик, которую можно получить в качестве пользователя программного обеспечения, является отправка сообщения о проблеме, которое вскоре закрывается с кратким и ничему не помогающим объяснением типа ``это не проблема'' или ``неправильное PR''. Подобным же образом одной из самых разочаровывающих практик, которую можно получить в качестве разработчика программного обеспечения, является получение массы сообщений о проблемах, которые на самом деле не являются сообщениями о проблемах, а запросами на получение поддержки, или которые содержат мало или вообще не содержат никакой информации о сути проблемы или способе ее воспроизведения.

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

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

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

Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

По вопросам связанными с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам связанным с русским переводом документации, пишите <frdp@FreeBSD.org.ua>.


Составление сообщений о проблеме во FreeBSD

Dag-Erling SmЬrgrav

$FreeBSD$

FreeBSD is a registered trademark of Wind River Systems, Inc. This is expected to change soon.

CVSup is a registered trademark of John D. Polstra.

IBM, AIX, EtherJet, Netfinity, OS/2, PowerPC, PS/2, S/390, and ThinkPad are trademarks of International Business Machines Corporation in the United States, other countries, or both.

Intel, Celeron, EtherExpress, i386, i486, Itanium, Pentium, and Xeon are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.

Sparc, Sparc64, SPARCEngine, and UltraSPARC are trademarks of SPARC International, Inc in the United States and other countries. Products bearing SPARC trademarks are based upon architecture developed by Sun Microsystems, Inc.

Sun, Sun Microsystems, Java, Java Virtual Machine, JavaServer Pages, JDK, JSP, JVM, Netra, Solaris, StarOffice, Sun Blade, Sun Enterprise, Sun Fire, SunOS, and Ultra are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the ``™'' or the ``®'' symbol.

Эта статья описывает, как наилучшим образом сформулировать и отправить сообщение о проблеме в Проект FreeBSD.

[ Split HTML / Single HTML ]

Table of Contents
1. Введение
2. Когда нужно отправлять сообщение о проблеме
3. Подготовка
4. Написание сообщения о проблеме
5. Отслеживание
6. Дополнительная литература

1. Введение

Одной из самых разочаровывающих практик, которую можно получить в качестве пользователя программного обеспечения, является отправка сообщения о проблеме, которое вскоре закрывается с кратким и ничему не помогающим объяснением типа ``это не проблема'' или ``неправильное PR''. Подобным же образом одной из самых разочаровывающих практик, которую можно получить в качестве разработчика программного обеспечения, является получение массы сообщений о проблемах, которые на самом деле не являются сообщениями о проблемах, а запросами на получение поддержки, или которые содержат мало или вообще не содержат никакой информации о сути проблемы или способе ее воспроизведения.

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

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

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


2. Когда нужно отправлять сообщение о проблеме

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

Но как же определить, что является ошибкой, а что нет? Простым правилом, которому нужно следовать, является следующее - ваша проблема не является ошибкой, если она формулируется как вопрос (обычно в форме ``Как сделать X?'' или ``Где можно найти Y?''). Не всегда это так однозначно, но правило вопроса покрывает большинство случаев. Если Вам нужен ответ, лучше всего задать свой вопрос в Список рассылки, посвящённый вопросам и ответам пользователей FreeBSD.

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

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

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


3. Подготовка

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

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

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

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


4. Написание сообщения о проблеме

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


4.1. Как писать хорошие сообщения о проблемах


4.2. Прежде всего

Перед запуском утилиты send-pr(1) проверьте, что переменная вашего окружения VISUAL (или EDITOR, если VISUAL не задана) задана подходящим образом.

Следует также проверить работоспособность системы электронной почты. Утилита send-pr(1) использует почтовую систему для отправки и отслеживания сообщения о проблеме. Если с машины, на которой вы запускаете send-pr(1), нельзя отправить почту, сообщение не попадёт в базу данных GNATS. О настройке электронной почты во FreeBSD можно прочитать в главе ``Электронная почта'' Руководства по FreeBSD по адресу http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/mail.html.


4.3. Вложение патчей или файлов

Программа send-pr(1) предусматривает присоединение файлов к сообщению о проблеме. Вы можете вложить сколько угодно файлов, но каждый с уникальным именем (имеется в виду имя файла без маршрута). Просто используйте параметр командной строки -a для задания имен файлов, которые вы хотите присоединить:

% send-pr -a /var/run/dmesg -a /tmp/errors

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

Если вы вкладываете патч, обязательно используйте параметр -c или -u вместе с командой diff(1) для создания контекстного или унифицированного diff-файла (унифицированный формат предпочтителен), и обязательно укажите точные номера версий CVS файлов, которые вы изменяли, чтобы разработчики, которые будут читать ваше сообщение, смогли легко его применить. Предпочтительным является патч относительно ветки CURRENT или HEAD CVS, поскольку весь новый код должен быть сначала оттестирован в -CURRENT. После завершения тестирования код будет интегрирован в ветвь STABLE.

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

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

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


4.4. Заполнение шаблона

После запуска утилиты send-pr(1) вам будет представлен шаблон сообщения о проблеме. Шаблон состоит из списка полей, некоторые из которых уже заполнены, а некоторые содержат комментарии, объясняющие назначение поля или перечисляющие подходящие значения. Не беспокойтесь о комментариях; они будут автоматически удалены, если вы их не изменяли (или удалите их сами).

Вверху шаблона, ниже строк SEND-PR: находятся заголовки почтового сообщения. Вам обычно не нужно их изменять, если только вы не посылаете сообщение о проблеме с машины или от учетной записи, которая может посылать, но не может получать электронную почту, в случае чего вы можете задать в полях From: и Reply-To: ваши реальные адреса электронной почты. Вы можете также послать самому себе (или кому-то еще) копию сообщения о проблеме, добавив один или большее количество адресов к заголовку Cc:.

Далее следует последовательности однострочных полей:

И наконец, последовательность многострочных полей:


4.5. Отправка сообщения о проблеме

Как только вы заполните шаблон, сохраните его и выйдете из редактора, send-pr(1) запросит вас s)end, e)dit or a)bort?. Вы можете нажать s для продолжения и отправки сообщения о проблеме, e для повторного запуска редактора и выполнения дальнейших изменений, или a для отказа от вашего сообщения. Если вы выберете последнее, то ваше сообщение о проблеме останется на диске (send-pr(1) укажет вам имя файла перед завершением работы), так что вы сможете отредактировать его на свой вкус или передать в систему с лучшим подключением к сети, перед тем, как послать его при помощи параметра -f программы send-pr(1):

% send-pr -f ~/my-problem-report

При этом будет прочитан указанный файл, будет проверено содержимое, убраны комментарии и сообщение будет отослано.


5. Отслеживание

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

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

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


6. Дополнительная литература

Это список информационных ресурсов, относящихся к правильному написанию и обработке сообщений о проблемах. Он, без сомнения, не полон.


Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

По вопросам связанными с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам связанным с русским переводом документации, пишите <frdp@FreeBSD.org.ua>.


Prev Next

5. Отслеживание

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

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

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

Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

По вопросам связанными с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам связанным с русским переводом документации, пишите <frdp@FreeBSD.org.ua>.


Prev  

6. Дополнительная литература

Это список информационных ресурсов, относящихся к правильному написанию и обработке сообщений о проблемах. Он, без сомнения, не полон.

Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

По вопросам связанными с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам связанным с русским переводом документации, пишите <frdp@FreeBSD.org.ua>.


Prev Next

3. Подготовка

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

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

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

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

Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

По вопросам связанными с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам связанным с русским переводом документации, пишите <frdp@FreeBSD.org.ua>.


Prev Next

2. Когда нужно отправлять сообщение о проблеме

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

Но как же определить, что является ошибкой, а что нет? Простым правилом, которому нужно следовать, является следующее - ваша проблема не является ошибкой, если она формулируется как вопрос (обычно в форме ``Как сделать X?'' или ``Где можно найти Y?''). Не всегда это так однозначно, но правило вопроса покрывает большинство случаев. Если Вам нужен ответ, лучше всего задать свой вопрос в Список рассылки, посвящённый вопросам и ответам пользователей FreeBSD.

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

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

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

Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

По вопросам связанными с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам связанным с русским переводом документации, пишите <frdp@FreeBSD.org.ua>.


Prev Next

4. Написание сообщения о проблеме

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

4.1. Как писать хорошие сообщения о проблемах

4.2. Прежде всего

Перед запуском утилиты send-pr(1) проверьте, что переменная вашего окружения VISUAL (или EDITOR, если VISUAL не задана) задана подходящим образом.

Следует также проверить работоспособность системы электронной почты. Утилита send-pr(1) использует почтовую систему для отправки и отслеживания сообщения о проблеме. Если с машины, на которой вы запускаете send-pr(1), нельзя отправить почту, сообщение не попадёт в базу данных GNATS. О настройке электронной почты во FreeBSD можно прочитать в главе ``Электронная почта'' Руководства по FreeBSD по адресу http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/mail.html.

4.3. Вложение патчей или файлов

Программа send-pr(1) предусматривает присоединение файлов к сообщению о проблеме. Вы можете вложить сколько угодно файлов, но каждый с уникальным именем (имеется в виду имя файла без маршрута). Просто используйте параметр командной строки -a для задания имен файлов, которые вы хотите присоединить:

% send-pr -a /var/run/dmesg -a /tmp/errors

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

Если вы вкладываете патч, обязательно используйте параметр -c или -u вместе с командой diff(1) для создания контекстного или унифицированного diff-файла (унифицированный формат предпочтителен), и обязательно укажите точные номера версий CVS файлов, которые вы изменяли, чтобы разработчики, которые будут читать ваше сообщение, смогли легко его применить. Предпочтительным является патч относительно ветки CURRENT или HEAD CVS, поскольку весь новый код должен быть сначала оттестирован в -CURRENT. После завершения тестирования код будет интегрирован в ветвь STABLE.

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

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

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

4.4. Заполнение шаблона

После запуска утилиты send-pr(1) вам будет представлен шаблон сообщения о проблеме. Шаблон состоит из списка полей, некоторые из которых уже заполнены, а некоторые содержат комментарии, объясняющие назначение поля или перечисляющие подходящие значения. Не беспокойтесь о комментариях; они будут автоматически удалены, если вы их не изменяли (или удалите их сами).

Вверху шаблона, ниже строк SEND-PR: находятся заголовки почтового сообщения. Вам обычно не нужно их изменять, если только вы не посылаете сообщение о проблеме с машины или от учетной записи, которая может посылать, но не может получать электронную почту, в случае чего вы можете задать в полях From: и Reply-To: ваши реальные адреса электронной почты. Вы можете также послать самому себе (или кому-то еще) копию сообщения о проблеме, добавив один или большее количество адресов к заголовку Cc:.

Далее следует последовательности однострочных полей:

И наконец, последовательность многострочных полей:

4.5. Отправка сообщения о проблеме

Как только вы заполните шаблон, сохраните его и выйдете из редактора, send-pr(1) запросит вас s)end, e)dit or a)bort?. Вы можете нажать s для продолжения и отправки сообщения о проблеме, e для повторного запуска редактора и выполнения дальнейших изменений, или a для отказа от вашего сообщения. Если вы выберете последнее, то ваше сообщение о проблеме останется на диске (send-pr(1) укажет вам имя файла перед завершением работы), так что вы сможете отредактировать его на свой вкус или передать в систему с лучшим подключением к сети, перед тем, как послать его при помощи параметра -f программы send-pr(1):

% send-pr -f ~/my-problem-report

При этом будет прочитан указанный файл, будет проверено содержимое, убраны комментарии и сообщение будет отослано.

Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

По вопросам связанными с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам связанным с русским переводом документации, пишите <frdp@FreeBSD.org.ua>.