736 lines
31 KiB
Text
736 lines
31 KiB
Text
<!--
|
||
The FreeBSD Russian Documentation Project
|
||
|
||
$FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/problem-reports/article.sgml,v 1.14 2004/04/08 06:14:19 den 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ø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>
|
||
является правильным действием, а только приводит к разочарованию вас и
|
||
разработчиков. И наоборот, есть случаи, когда может быть нужно послать
|
||
сообщение о чем-то, не являющемся ошибкой—к примеру, запрос на
|
||
доработку или расширение функциональности.</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>—если Вы не подписаны на них, воспользуйтесь
|
||
<ulink
|
||
URL="http://www.FreeBSD.org/search/search.html#mailinglists">поиском
|
||
в архивах</ulink> на сайте FreeBSD. Если ваша проблема не
|
||
обсуждалась в списках рассылки, вы можете попытаться опубликовать
|
||
сообщение о ней и подождать несколько дней, пока кто-нибудь не сможет
|
||
увидеть то, что вы не заметили.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Как вариант, весь веб—используйте вашу любимую поисковую
|
||
систему для поиска каких-либо ссылок по вашей проблеме. Вы можете
|
||
даже увидеть ссылки на архивы списков рассылки или телеконференций, о
|
||
которых вы не знали или не думали там искать.</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>. Не стоит предполагать, что
|
||
читающий ваше сообщение владеет контекстом; поэтому, чем подробнее
|
||
вы опишете ситуацию, тем лучше. В частности, к какой части системы
|
||
относится ваша проблема? Проявляется ли она на этапе установки или
|
||
во время нормальной работы? Например, вместо строки
|
||
<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> Если вы отвечаете за часть исходных текстов
|
||
(например, порт) можете
|
||
добавить в начало поля <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>
|
||
имеет куда меньше шансов встретить позитивный отклик, чем более
|
||
четко сформулированный запрос. Помните, что исходные тексты
|
||
доступны всем, так что если вам нужна реализация какого-то нового
|
||
свойства, лучший способ— взяться за работу самому! Не
|
||
забудьте также, что такие моменты лучше обсуждать в списках
|
||
рассылки, таких как <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; использует почтовую систему для
|
||
отправки и отслеживания сообщения о проблеме. Если с машины, на
|
||
которой вы запускаете &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>, его изменение не имеет значения, так как нет
|
||
такого понятия, как конфиденциальное сообщение о
|
||
проблеме—база данных 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> Оно должно максимально точно
|
||
описывать окружение, в котором встречается проблема. Сюда
|
||
включается версия операционной системы, версия конкретной программы
|
||
или файла, содержащего проблему, и любая другая информация, такая,
|
||
как конфигурация системы, другое программное обеспечение, которое
|
||
влияет на проблему, и так далее—просто все, что разработчик
|
||
должен знать для создания условий появления проблемы.</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>—прекрасное эссе, которое
|
||
написал Simon G. Tatham о составлении полезных (не специфичных для
|
||
FreeBSD) сообщений о проблемах.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para><ulink url="../../articles/pr-guidelines/article.html">Problem
|
||
Report Handling Guidelines</ulink>—интересный взгляд на
|
||
обработку сообщений о проблемах самими разработчиками FreeBSD.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
</section>
|
||
</article>
|