os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Initial import, synchronized with English 1.28

Browse source
This commit is contained in:
Andrey Zakhvatov 2004-01-05 17:00:58 +00:00
parent 27e37eae9d
commit e895d25f78
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=19489
1 changed files with 747 additions and 0 deletions

747
ru_RU.KOI8-R/articles/problem-reports/article.sgml Normal file
View file

@ -0,0 +1,747 @@
<!--
The FreeBSD Russian Documentation Project
$FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/problem-reports/article.sgml,v 1.7 2003/12/31 10:36:04 marck Exp $
Original revision: 1.28
-->
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN">
%man;
<!ENTITY % mailing-lists PUBLIC "-//FreeBSD//ENTITIES DocBook Mailing List Entities//RU">
%mailing-lists;
<!ENTITY % trademarks PUBLIC "-//FreeBSD//ENTITIES DocBook Trademark Entities//EN">
%trademarks;
]>
<article>
<articleinfo>
<title>Составление сообщений о проблеме во FreeBSD</title>
<pubdate>$FreeBSD$</pubdate>
<legalnotice id="trademarks" role="trademarks">
&tm-attrib.freebsd;
&tm-attrib.cvsup;
&tm-attrib.ibm;
&tm-attrib.intel;
&tm-attrib.sparc;
&tm-attrib.sun;
&tm-attrib.general;
</legalnotice>
<abstract>
<para>Эта статья описывает, как наилучшим образом сформулировать и
послать сообщение о проблеме в Проект FreeBSD.</para>
</abstract>
<authorgroup>
<author>
<firstname>Dag-Erling</firstname>
<surname>Sm&oslash;rgrav</surname>
<contrib>Текст предоставил</contrib>
</author>
</authorgroup>
</articleinfo>
<indexterm><primary>сообщения о проблемах</primary></indexterm>
<section id="pr-intro">
<title>Введение</title>
<para>Одной из самых разочаровывающим практик, которую можно получить в
качестве пользователя программного обеспечения, является посылка
сообщения о проблеме, которое вскоре закрывается с кратким и ничему не
помогающим объяснением типа <quote>это не ошибка</quote> или
<quote>неправильное PR</quote>. Подобным же образом одной из самых
разочаровывающим практик, которую можно получить в качестве разработчика
программного обеспечения, является получение массы сообщений о проблемах,
которые на самом деле не являются сообщениями о проблемах, а запросами на
получение поддержки, или которые содержат мало или вообще не содержат
никакой информации о сути проблемы или способе ее воспроизвести.</para>
<para>В этом документе делается попытка описать то, как составлять хорошие
сообщения о проблемах. Что же, спросите вы, является хорошим сообщением
об ошибке? Ну, если перейти прямо к сути, то хорошим сообщением об
ошибке является то, которое может быть быстро проанализировано и
отработано, к обоюдному удовлетворению как пользователя, так и
разработчика.</para>
<para>Хотя в основном статья фокусируется на сообщениях о проблемах во
FreeBSD, большей частью она должна хорошо подходить и другим программным
проектам.</para>
<para>Заметьте, что эта статья организована по тематическому принципу, а
не хронологически, так что вы должны прочесть документ целиком прежде,
чем посылать сообщение об ошибке, и не воспринимать его как пошаговое
руководство.</para>
</section>
<section id="pr-when">
<title>Когда нужно посылать сообщение об ошибке</title>
<para>Имеется много классов ошибок, и не все они должны приводить к
появлению сообщения о проблеме. Конечно же, нет идеальных людей, и
будут моменты, когда вы решите, что нашли ошибку в программе, а на самом
деле вы неправильно поняли синтаксис команды или сделали опечатку в
конфигурационном файле (хотя само по себе это иногда говорит о плохой
документации или неправильной обработке ошибок в прикладной программе).
Есть еще много случаев, когда посылка сообщения об ошибке явно <emphasis>не</emphasis>
является правильным действием, а только приводит к разочарованию вас и
разработчиков. И наоборот, есть случаи, когда может быть нужно послать
сообщение о чем-то, не являющемся ошибкой&mdash;к примеру, запрос на
доработку или расширение функциональности.</para>
<para>Но как же определить, что является ошибкой, а что нет? Простым
правилом, которому нужно следовать, является следующее - ваша проблема
<emphasis>не</emphasis> является ошибкой, если она формулируется как
вопрос (обычно в форме <quote>Как сделать X?</quote> или <quote>Где можно
найти Y?</quote>). Не всегда это так однозначно, но правило вопроса
покрывает большинство случаев. Если Вам нужен ответ, лучше всего задать
свой вопрос в &a.questions;.</para>
<para>Вот некоторые случаи, в которых может оказаться полезным послать
сообщение о чем-то, что не является ошибкой:</para>
<itemizedlist>
<listitem>
<para>Запросы на расширение функций. Обычно хорошей идеей является
озвучивание этого в списках рассылки до того, как посылать сообщение
о проблеме.</para>
</listitem>
<listitem>
<para>Уведомление об обновлении программного обеспечения, которое
поддерживается сторонними разработчиками (в основном порты, но также
и компоненты базовой системы, разрабатываемые сторонними
организациями, такие, как BIND или различные утилиты GNU).</para>
</listitem>
</itemizedlist>
<para>Кроме того, если система, на которой вы столкнулись с ошибкой, давно
не обновлялась, вы должны серьезно подумать об обновлении и попытаться
воспроизвести проблему на обновленной системе прежде, чем посылать
сообщение об ошибке. Есть лишь несколько вещей, которые выводят из
себя разработчика больше, чем получение сообщений об уже исправленных
ею ошибках.</para>
<para>И наконец, ошибка, которую нельзя воспроизвести, вряд ли будет
исправлена. Если ошибка возникла только единожды, и вы не можете ее
воспроизвести, к тому же никто с ней больше не сталкивался, нет никаких
шансов, что разработчики смогут ее воспроизвести или понять, что делается
неправильно. Это не значит, что такого не случается, но это значит, что
шансов у вашего сообщения дойти когда либо до стадии исправления ошибки
очень малы, и вам лучше его не посылать.</para>
</section>
<section id="pr-prep">
<title>Подготовка</title>
<para>Нужно следовать хорошему правилу всегда сначала выполнять
дополнительные исследования перед тем, как послать сообщение о проблеме.
Может быть, о вашей проблеме уже сообщено; может быть, она недавно
обсуждалась или обсуждается в списках рассылки; она может быть уже
исправлена в более новой версии, чем та, что вы используете. Поэтому вы
должны проверить все обычные места до того, как послать ваше сообщение о
проблеме. Для FreeBSD это значит:</para>
<itemizedlist>
<listitem>
<para>FreeBSD
<ulink URL="../../books/faq/index.html">FAQ</ulink>
(Ответы на часто задаваемые вопросы).
FAQ содержит ответы на вопросы из самых разных категорий,
в частности,
<ulink URL="../../books/faq/hardware.html">аппаратной
совместимости</ulink>,
<ulink URL="../../books/faq/applications.html">пользовательских
программ</ulink>
и <ulink URL="../../books/faq/kernelconfig.html">конфигурации
ядра</ulink>.</para>
</listitem>
<listitem>
<para><ulink
URL="../../books/handbook/eresources.html#ERESOURCES-MAIL">Списки
рассылки</ulink>&mdash;если Вы не подписаны на них, воспользуйтесь
<ulink
URL="http://www.FreeBSD.org/search/search.html#mailinglists">поиском
в архивах</ulink> на сайте FreeBSD. Если ваша проблема не
обсуждалась в списках рассылки, вы можете попытаться опубликовать
сообщение о ней и подождать несколько дней, пока кто-нибудь не сможет
увидеть то, что вы не заметили.</para>
</listitem>
<listitem>
<para>Как вариант, весь веб&mdash;используйте вашу любимую поисковую
систему для нахождения каких-либо ссылок на вашу проблему. Вы можете
даже увидеть ссылки на архивы списков рассылки или телеконференций, о
которых вы не знали или не думали там искать.</para>
</listitem>
<listitem>
<para>Следующим пунктом должна быть
<ulink URL="http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query">
база данных PR FreeBSD</ulink> (GNATS). Если только ваша проблема не
нова или редка, есть некоторый шанс, что о ней уже сообщено.</para>
</listitem>
<listitem>
<para>Наконец, если вы обновляли версию системы (в особенности, если
вы обновляете ветку <literal>-current</literal>), вам следует
тщательно изучить содержимое файла
<filename>/usr/src/UPDATING</filename> или его текущую версию по адресу
<ulink URL="http://www.FreeBSD.org/cgi/cvsweb.cgi/src/UPDATING"></ulink>.
Этот файл содержит немало жизненно важной информации.</para>
</listitem>
</itemizedlist>
<para>Теперь вам нужно добиться того, чтобы ваше сообщение о проблеме
попало в нужные руки.</para>
<para>Здесь первым правилом будет то, что если проблема является ошибкой в
программном обеспечении сторонних разработчиков (порт или пакадж, которые
вы установили), то вы должны сообщить об ошибке автору программы, а не в
Проект FreeBSD. Есть два исключения из этого правила: во-первых, если
ошибка не проявляется на других платформах, то в этом случае проблема
может заключаться в том, как программное обеспечение было перенесено на
FreeBSD; во-вторых, если автор уже исправил ошибку и выпустил патч или
новую версию своей программы, а порт FreeBSD еще не был обновлен.</para>
<para>Вторым правилом является то, что система отслеживания ошибок FreeBSD
сортирует сообщения о проблеме в соответствии с категорией, выбранной
тем, кто сообщает о проблеме. Таким образом, если вы выберите
неправильную категорию при посылке сообщения о проблеме, есть большая
вероятность, что оно будет незамеченно до тех пор, пока кто-нибудь не
сменит у него категорию.</para>
</section>
<section id="pr-writing">
<title>Написание сообщения о проблеме</title>
<para>Теперь, после того, как вы решили, что ваш вопрос подпадает под
категорию сообщения о проблеме, и это проблема FreeBSD, самое время
написать собственно сообщение о проблеме (PR). Прежде чем мы углубимся
в частности использования программы для создания и отправки PR, вот
несколько советов, которые помогут вам сделать PR более эффективным.
</para>
<section>
<title>Как писать хорошие сообщения о проблемах</title>
<itemizedlist>
<!-- marck: RU-specific -->
<listitem>
<para>Основным языком общения разработчиков FreeBSD является
английский. База данных по проблемам также ведется на английском.
Если вы испытываете проблемы с формулировкой описания проблемы
по-английски, свяжитесь со своими соотечественниками, которые
помогут вам составить PR.</para> <!-- XXX URLs!!? -->
</listitem>
<listitem>
<para><emphasis>Не оставляйте поле <quote>Synopsis</quote>
(краткое описание) пустым.</emphasis> Сообщения о проблемах
попадают как в списки рассылки, которые затем расходятся по всему
миру (в них поле <quote>Synopsis</quote> определяет тему письма),
так и в базу данных. Просматривающий эту базу, как правило,
пройдет мимо PR с пустым кратким описанием. Не забудьте, что PR
остается в базе до тех пор, пока кто-либо не закроет его;
сообщение-аноним, скорее всего, просто потеряется на общем
фоне.</para>
</listitem>
<listitem>
<para><emphasis>Не оставляйте поле <quote>Synopsis</quote>
(краткое описание) пустым.</emphasis> Сообщения о проблемах
попадают как в списки рассылки, которые затем расходятся по всему
миру (в них поле <quote>Synopsis</quote> определяет тему письма),
так и в базу данных. Просматривающий эту базу, как правило,
пройдет мимо PR с пустым кратким описанием. Не забудьте, что PR
остается в базе до тех пор, пока кто-либо не закроет его;
сообщение-аноним, скорее всего, просто потеряется на общем
фоне.</para>
</listitem>
<listitem>
<para><emphasis>Избегайте туманных описаний в поле
<quote>Synopsis</quote></emphasis>. Не стоит предполагать, что
читающий ваше сообщение владеет контекстом; поэтому, чем подробнее
вы опишете ситуацию, тем лучше. В частности, к какой части системы
относится ваша проблема? Проявляется ли она на этапе установки или
во время нормальной работы? Например, вместо строки
<literal>Synopsis: portupgrade is broken</literal> следовало бы
написать что-то вроде <literal>Synopsis: port sysutils/portupgrade
coredumps on -current</literal>. В случае портированных приложений
в поле <quote>Synopsis</quote> полезно указывать не только имя
порта, но и категорию.</para>
</listitem>
<listitem>
<para><emphasis>Если у вас есть готовый патч, скажите об
этом.</emphasis> PR, содержащий патч, имеет куда больше шансов
быть рассмотренным. В этом случае добавьте строку
<literal>[patch]</literal> в начало поля <quote>Synopsis</quote>
(хотя использование именно этой формы необязательно, она является
стандартом де-факто).</para>
</listitem>
<listitem>
<para><emphasis>Если вы ведете фрагмент кода, сообщите об
этом.</emphasis> Если вы&mdash;ответственная персона, можете
добавить в начало поля <quote>Synopsis</quote> строку
<literal>[maintainer update]</literal>, а также установить класс
вашего сообщения (поле <quote>Class</quote>) в
<literal>maintainer-update</literal>. В этом случае коммиттеру,
обрабатывающему ваш PR, не придется лишний раз сверяться с файлом
<filename>Makefile</filename>.</para>
</listitem>
<listitem>
<para><emphasis>Будьте точны в формулировках.</emphasis>
Чем больше информации вы можете предоставить о проблеме, тем больше
у вас шансов получить ответ. Например, следует предоставить
информацию о версии системы, на которой вы работаете (для этого
предназначено специальное поле, см. ниже), о платформе, работаете ли
вы на версии с CD-ROM или обновлялись посредством &man.cvsup.1;
(если да, то укажите момент обновления). В случае проблем с ядром
укажите, что вы прочли файл <literal>src/UPDATING</literal>, иначе
кто-нибудь обязательно спросит, делали ли вы это. Нет
необходимости сразу предоставлять файл конфигурации ядра, список
установленных портов и/или образ памяти; однако, вы должны быть
готовы выслать или предоставить их по запросу.</para>
</listitem>
<listitem>
<para><emphasis>Избегайте нечетких запросов о новых
возможностях.</emphasis> Сообщение типа <quote>кто-то обязательно
должен сделать так, чтобы такая-то утилита вела себя так-то</quote>
имеет куда меньше шансов встретить позитивный отклик, чем более
четко сформулированный запрос. Помните, что исходные тексты
доступны всем, так что если вам нужна реализация какого-то нового
свойства, лучший способ&mdash; взяться за работу самому! Не
забудьте также, что такие моменты лучше обсуждать в списках
рассылки, таких как <literal>freebsd-questions</literal>, чем
делать это посредством базы данных PR.</para>
</listitem>
<listitem>
<para><emphasis>Убедитесь, что ваша проблема еще никем не описана.
</emphasis> Мы уже говорили об этом, но стоит повториться.
Потратьте пару минут на составление запросов к базе PR:
<ulink URL="http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query"></ulink>.
(Несмотря на повторы, об этом постоянно забывают)</para>
</listitem>
<listitem>
<para><emphasis>Избегайте полемики.</emphasis>
Если ваше сообщение касается области или способов реализации,
которые ранее вызвали разногласия, вам стоит быть готовым
предоставить не только патчи, но и внятные аргументы, почему
следует поступать именно так (то есть, это <quote>Правильный
Путь</quote>). Как отмечалось выше, аккуратный поиск по архиву
списков рассылки
<ulink URL="http://www.FreeBSD.org/search/search.html#mailinglists"></ulink>
никогда не помешает.</para>
</listitem>
<listitem>
<para><emphasis>Будьте вежливы.</emphasis>
Почти каждый из тех, кто может заниматься вашим сообщением,
является добровольцем. Никому не понравятся указания, как и что
делать, когда он и так занимается этим, да еще и по каким-либо
причинам, отличным от денежных. Вообще говоря, этого подхода
следует придерживаться, имея дело с любым проектом с Открытыми
Исходными текстами (Open Source).</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Прежде всего</title>
<para>Перед запуском утилиты &man.send-pr.1; проверьте, что переменная
вашего окружения <envar>VISUAL</envar> (или <envar>EDITOR</envar>, если
<envar>VISUAL</envar> не задана) задана подходящим образом.</para>
<para>Следует также проверить, что от вас нормально ходит электронная
почта. Утилита &man.send-pr.1; генерит ваш PR в виде почтового
сообщения. Если с машины, на которой вы запускаете &man.send-pr.1;,
нельзя отправить почту, ваше сообщение не дойдет до базы данных GNATS.
Об установках электронной почты в FreeBSD можно прочитать в главе
<quote>Электронная почта</quote> в Руководстве по FreeBSD по адресу
<ulink URL="http://www.FreeBSD.org/doc/ru_RU.KOI8-R/books/handbook/mail.html"></ulink>.
</para>
</section>
<section>
<title>Вложение патчей или файлов</title>
<para>Программа &man.send-pr.1; предусматривает присоединение файлов к
сообщению о проблеме. Вы можете вложить сколько угодно файлов, но
каждый с уникальным именем (имеется в виду имя файла без маршрута).
Просто используйте параметр командной строки <option>-a</option> для
задания имен файлов, которые вы хотите присоединить:</para>
<screen>&prompt.user; <userinput>send-pr -a /var/run/dmesg -a /tmp/errors</userinput></screen>
<para>Не беспокойтесь о бинарных файлах, они будут автоматически
перекодированы для того, чтобы не повредить работе вашей почтовой
программы.</para>
<para>Если вы вкладываете патч, обязательно используйте параметр
<option>-c</option> или <option>-u</option> вместе с командой
&man.diff.1; для создания контекстного или унифицированного diff-файла
(унифицированный формат предпочтителен),
и обязательно укажите точные номера версий CVS файлов, которые вы
изменяли, чтобы разработчики, которые будут читать ваше сообщение,
смогли легко его применить. Предпочтительным является патч
относительно ветки CURRENT или HEAD CVS, поскольку весь новый код
должен быть сначала оттестирован в -CURRENT. После завершения
тестирования код будет интегрирован в ветвь STABLE.</para>
<para>Если вы вставляете патч в тело сообщения, учтите, что некоторые
почтовые программы имеют тенденцию заменять табуляции серией пробелов,
что полностью разрушит, например, часть файла сборки (Makefile).</para>
<para>Следует также заметить, что включение небольших патчей в сообщение о
проблеме является приемлемой практикой, в особенности если они решают
проблему, описанную в сообщении, большие же патчи, а в особенности
новый код, который может требовать значительного просмотра перед тем,
как он будет внесен в дерево исходных текстов, должны быть размещены на
web- или ftp-сервере, а в сообщение о проблеме должен быть включён
только URL указывающий на этот патч. Очень часто патчи, пересылаемые по
электронной почте, а в особенности если задействована GNATS, бывают
искажены, и, как следствие, чем больше патч, тем труднее будет для
заинтересованных людей привести его к нормальному виду. Также то, что
патч будет размещён отдельно от сообщения о проблеме, даёт возможность
изменять его не отсылая полный патч в дополнение к изначальному
сообщению об ошибке.</para>
<para>Вы должны также помнить, что пока вы явно не укажете обратного в
вашем сообщении о проблеме или в самих патчах, будет предполагаться,
что они подпадают под те же условия лицензирования, что и оригинальный
файл, измененный вами.</para>
</section>
<section>
<title>Заполнение шаблона</title>
<para>После запуска утилиты &man.send-pr.1; вам будет представлен шаблон
сообщения о проблеме.
Шаблон состоит из списка полей, некоторые из которых уже заполнены,
а некоторые содержат комментарии, объясняющие назначение поля или
перечисляющие подходящие значения. Не беспокойтесь о комментариях; они
будут автоматически удалены, если вы их не изменяли, или удалите их
сами.</para>
<para>Вверху шаблона, ниже строк <literal>SEND-PR:</literal> находятся
заголовки почтового сообщения. Вам обычно не нужно их изменять, если
только вы не посылаете сообщение о проблеме с машины или от учетной
записи, которая может посылать, но не может получать электронную почту,
в случае чего вы можете задать в полях <literal>From:</literal> и
<literal>Reply-To:</literal> ваши реальные адреса электронной почты.
Вы можете также послать самому себе (или кому-то еще) копию сообщения
о проблеме, добавив один или большее количество адресов к заголовку
<literal>Cc:</literal>.</para>
<para>Далее следует последовательности однострочных полей:</para>
<itemizedlist>
<listitem>
<para><emphasis>Submitter-Id:</emphasis> Не меняйте его. Значение
по умолчанию <literal>current-users</literal> правильно, даже если
вы используете FreeBSD-STABLE.</para>
</listitem>
<listitem>
<para><emphasis>Originator:</emphasis> Обычно оно заполнено полем
дополнительной информации учетной записи пользователя. Пожалуйста,
укажите ваше реальное имя, за которым опционально следует адрес
вашей электронной почты в угловых скобках.</para>
</listitem>
<listitem>
<para><emphasis>Organization:</emphasis> Все, что вы захотите здесь
указать. Это поле не используется ни для чего серьезного.</para>
</listitem>
<listitem>
<para><emphasis>Confidential:</emphasis> Предварительно заполнено как
<literal>no</literal>, его изменение не имеет значения, так как нет
такого понятия, как конфиденциальное сообщение о
проблеме&mdash;база данных PR распространяется по всему миру
посредством <application>CVSup</application>.</para>
</listitem>
<listitem>
<para><emphasis>Synopsis:</emphasis> Заполняется кратким и точным
описанием проблемы. Краткое описание используется в качестве темы
сообщения электронной почты о проблеме, и используется при выдаче
списков и выборках сообщений о проблемах; сообщения о проблемах с
непонятными краткими описаниями чаще всего игнорируются.</para>
<para>Повторим: если к вашему сообщению о проблеме приложен патч,
то, пожалуйста, начните краткое описание с
<literal>[PATCH]</literal>; если вы являетесь ответственным за
данную часть кода или порт, можете начать описание с
<literal>[maintainer update]</literal> и/или установить класс
проблемы (поле <quote>Class</quote>) в
<literal>maintainer-update</literal>.</para>
</listitem>
<listitem>
<para><emphasis>Severity:</emphasis> Одно из
<literal>non-critical</literal>,
<literal>serious</literal> или <literal>critical</literal>. Не
переусердствуйте; избегайте пометки вашей проблемы как
<literal>critical</literal>, если только это не действительно
критичная проблема (к примеру, уязвимость пользователя <username>root</username>, легко
воспроизводимый останов системы). Разработчики чаще всего
игнорируют это и следующее поля, и именно потому, что посылающие
слишком часто переоценивают критичность своих проблем.</para>
</listitem>
<listitem>
<para><emphasis>Priority:</emphasis> Одно из
<literal>low</literal>, <literal>medium</literal> или
<literal>high</literal>. Смотрите выше.</para>
</listitem>
<listitem>
<para><emphasis>Category:</emphasis> Выберите одно из
следующего:</para>
<itemizedlist>
<listitem>
<para><literal>advocacy:</literal> проблемы, связанные с
общественным мнением о FreeBSD. Используется редко.</para>
</listitem>
<listitem>
<para><literal>alpha:</literal> проблемы, специфичные для
платформы Alpha.</para>
</listitem>
<listitem>
<para><literal>amd64:</literal> проблемы, специфичные для
платформы AMD64.</para>
</listitem>
<listitem>
<para><literal>bin:</literal> проблемы с пользовательскими
программами из базовой системы.</para>
</listitem>
<listitem>
<para><literal>conf:</literal> проблемы с настроечными файлами,
используемыми по умолчанию значениями и прочее.</para>
</listitem>
<listitem>
<para><literal>docs:</literal> проблемы со страницами справочной
системы или онлайновой документацией.</para>
</listitem>
<listitem>
<para><literal>gnu:</literal> проблемы с программным обеспечением
GNU, таки, как &man.gcc.1; или &man.grep.1;.</para>
</listitem>
<listitem>
<para><literal>i386:</literal> проблемы, специфичные для
платформы &i386;.</para>
</listitem>
<listitem>
<para><literal>ia64:</literal> проблемы, специфичные для
платформы ia64.</para>
</listitem>
<listitem>
<para><literal>java:</literal> проблемы, связанные с &java;.
</para>
</listitem>
<listitem>
<para><literal>kern:</literal> проблемы с ядром.</para>
</listitem>
<listitem>
<para><literal>misc:</literal> все, что не подпадает ни под какую
другую категорию (Надо отметить, что проблемы этой категории
имеют тенденцию теряться легче всего).</para>
</listitem>
<listitem>
<para><literal>ports:</literal> проблемы, связанные с деревом
портов.</para>
</listitem>
<listitem>
<para><literal>powerpc:</literal> проблемы, специфичные для
платформы &powerpc;.</para>
</listitem>
<listitem>
<para><literal>sparc64:</literal> проблемы, специфичные для
платформы &sparc64;.</para>
</listitem>
<listitem>
<para><literal>standards:</literal> проблемы, связанные с
соответствием стандартам.</para>
</listitem>
<listitem>
<para><literal>www:</literal> изменения или улучшения сайта
FreeBSD </para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para><emphasis>Class:</emphasis> Выберите одно из следующего:</para>
<itemizedlist>
<listitem>
<para><literal>sw-bug:</literal> ошибки в программном
обеспечении.</para>
</listitem>
<listitem>
<para><literal>doc-bug:</literal> ошибки в документации.</para>
</listitem>
<listitem>
<para><literal>change-request:</literal> запросы на расширение
функций или изменение в существующих.</para>
</listitem>
<listitem>
<para><literal>update:</literal> обновления портов или другого
программного обеспечения сторонних разработчиков.</para>
</listitem>
<listitem>
<para><literal>maintainer-update:</literal> обновления в портах,
для которых вы являетесь ответственной персоной.</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para><emphasis>Release:</emphasis> Используемая вами версия FreeBSD.
Оно заполняется автоматически программой &man.send-pr.1; и требует
изменения, если только вы отсылаете сообщение о проблеме с системы,
отличающейся от той, где вы столкнулись с проблемой.</para>
</listitem>
</itemizedlist>
<para>И наконец, последовательность многострочных полей:</para>
<itemizedlist>
<listitem>
<para><emphasis>Environment:</emphasis> Оно должно максимально точно
описывать окружение, в котором встречается проблема. Сюда
включается версия операционной системы, версия конкретной программы
или файла, содержащего проблему, и любая другая информация, такая,
как конфигурация системы, другое программное обеспечение, которое
влияет на проблему, и так далее&mdash;просто все, что разработчик
должен знать для создания условий появления проблемы.</para>
</listitem>
<listitem>
<para><emphasis>Description:</emphasis> Полное и точное описание
проблемы, с которой вы столкнулись. Попытайтесь избежать своих
предположений о причинах проблемы, если только вы не
уверены, что правы, так как разработчик может сделать неправильные
предположения о проблеме.</para>
</listitem>
<listitem>
<para><emphasis>How-To-Repeat:</emphasis> Последовательность
действий, которые должны быть выполнены для повторения
проблемы.</para>
</listitem>
<listitem>
<para><emphasis>Fix:</emphasis> Предпочтителен патч, или по крайней
мере обходной путь (который не только поможет другим людям обойти
ту же самую проблему, но также поможет разработчику понять ее
причины), однако если у вас нет никаких здравых идей, то лучше
оставить это поле пустым, чем строит догадки.</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Отсылка сообщения о проблеме</title>
<para>Как только вы заполните шаблон, сохраните его и выйдете из
редактора, &man.send-pr.1; запросит вас
<prompt>s)end, e)dit or a)bort?</prompt>. Вы можете нажать
<userinput>s</userinput> для продолжения и посылки сообщения о
проблеме, <userinput>e</userinput> для повторного запуска редактора и
выполнения дальнейших изменений, или <userinput>a</userinput> для
отказа от вашего сообщения. Если вы выберете последнее, то ваше
сообщение о проблеме останется на диске (&man.send-pr.1; укажет вам
имя файла перед завершением работы), так что вы сможете отредактировать
его на свой вкус или передать в систему с лучшим подключением к сети,
перед тем, как послать его при помощи параметра <option>-f</option>
программы &man.send-pr.1;:</para>
<screen>&prompt.user; <userinput>send-pr -f ~/my-problem-report</userinput></screen>
<para>При этом будет прочитан указанный файл, будет проверено содержимое,
убраны комментарии и сообщение будет отослано.</para>
</section>
</section>
<section id="pr-followup">
<title>Отслеживание</title>
<para>После того, как ваше сообщение будет принято, вы получите по
электронной почте уведомление, в котором будет указан номер для
отслеживания, который был назначен вашему сообщению о проблеме и URL,
который вы можете использовать для проверки его состояния. В случае
удачи кто-нибудь проявит интерес к вашей проблеме и попытается ее
решить, или, как это бывает, описать, почему это не является проблемой.
Вы будет автоматически оповещаться о любом изменении состояния и получать
копии всех комментариев или патчей, которые будут присоединяться в
процессе отработки вашего сообщения о проблеме.</para>
<para>Если кто-то запросит дополнительную информацию от вас, или вы
вспомните или обнаружите нечто, что не указали в начальном сообщении,
просто пошлите письмо на адрес <email>bug-followup@FreeBSD.org</email>,
включив отслеживаемый номер в теме, чтобы система отслеживания сообщений
могла знать, к какому сообщению о проблеме его присоединить.</para>
<para>Если сообщение о проблеме остается открытым после того, как проблема
была решена, просто пошлите сообщение вдогонку (так, как это описано
выше), в котором укажите, что сообщение о проблеме может быть закрыто, и
если это возможно, объясните, как и когда проблема была устранена.</para>
</section>
<section id="pr-further">
<title>Дополнительная литература</title>
<para>Это список информационных ресурсов, относящихся к правильному
написанию и обработке сообщений о проблемах. Он, без сомнения, не
полон.</para>
<itemizedlist>
<listitem>
<para><ulink
url="http://www.chiark.greenend.org.uk/~sgtatham/bugs.html">
How to Report Bugs Effectively</ulink>&mdash;прекрасное эссе, которое
написал Simon G. Tatham о составлении полезных (не специфичных для
FreeBSD) сообщений о проблемах.</para>
</listitem>
<listitem>
<para><ulink url="../../articles/pr-guidelines/article.html">Problem
Report Handling Guidelines</ulink>&mdash;интересный взгляд на
обработку сообщений об ошибках самими разработчиками FreeBSD.</para>
</listitem>
</itemizedlist>
</section>
</article>