diff --git a/ru_RU.KOI8-R/articles/problem-reports/article.sgml b/ru_RU.KOI8-R/articles/problem-reports/article.sgml index 4c35a67955..7ee5ad2d4c 100644 --- a/ru_RU.KOI8-R/articles/problem-reports/article.sgml +++ b/ru_RU.KOI8-R/articles/problem-reports/article.sgml @@ -1,736 +1,878 @@ -%man; - -%mailing-lists; - -%trademarks; + +%articles.ent; ]>
- Составление сообщений о проблеме во FreeBSD + Составление сообщений о проблеме во &os; $FreeBSD$ &tm-attrib.freebsd; &tm-attrib.cvsup; &tm-attrib.ibm; &tm-attrib.intel; &tm-attrib.sparc; &tm-attrib.sun; &tm-attrib.general; Эта статья описывает, как наилучшим образом сформулировать и - отправить сообщение о проблеме в Проект FreeBSD. + отправить сообщение о проблеме в Проект &os;. Dag-Erling Smørgrav Текст предоставил сообщения о проблемах
Введение Одной из самых разочаровывающих практик, которую можно получить в качестве пользователя программного обеспечения, является отправка сообщения о проблеме, которое вскоре закрывается с кратким и ничему не помогающим объяснением типа это не проблема или неправильное PR. Подобным же образом одной из самых разочаровывающих практик, которую можно получить в качестве разработчика программного обеспечения, является получение массы сообщений о проблемах, которые на самом деле не являются сообщениями о проблемах, а запросами на получение поддержки, или которые содержат мало или вообще не содержат никакой информации о сути проблемы или способе ее воспроизведения. В этом документе делается попытка описать то, как составлять хорошие сообщения о проблемах. Что же, спросите вы, является хорошим сообщением о проблеме? Ну, если перейти прямо к сути, то хорошим сообщением об проблеме является то, которое может быть быстро проанализировано и отработано, к обоюдному удовлетворению как пользователя, так и разработчика. Хотя в основном статья фокусируется на сообщениях о проблемах во - FreeBSD, большей частью она должна хорошо подходить и другим программным + &os;, большей частью она должна хорошо подходить и другим программным проектам. Заметьте, что эта статья организована по тематическому принципу, а не хронологически, так что вы должны прочесть документ целиком прежде, чем посылать сообщение о проблеме, и не воспринимать статью как пошаговое руководство.
Когда нужно отправлять сообщение о проблеме Имеется много классов ошибок, и не все они должны приводить к появлению сообщения о проблеме. Конечно же, нет идеальных людей, и будут моменты, когда вы решите, что нашли ошибку в программе, а на самом деле вы неправильно поняли синтаксис команды или сделали опечатку в конфигурационном файле (хотя само по себе это иногда говорит о плохой документации или неправильной обработке ошибок в прикладной программе). Есть еще много случаев, когда посылка сообщения о проблеме явно не является правильным действием, а только приводит к разочарованию вас и разработчиков. И наоборот, есть случаи, когда может быть нужно послать сообщение о чем-то, не являющемся ошибкой—к примеру, запрос на доработку или расширение функциональности. Но как же определить, что является ошибкой, а что нет? Простым правилом, которому нужно следовать, является следующее – ваша проблема не является ошибкой, если она формулируется как вопрос (обычно в форме Как сделать X? или Где можно найти Y?). Не всегда это так однозначно, но правило вопроса покрывает большинство случаев. Если Вам нужен ответ, лучше всего задать свой вопрос в &a.questions;. Вот некоторые случаи, в которых может оказаться полезным отправить сообщение о чем-то, что не является ошибкой: Запросы на расширение функциональности. Обычно хорошей идеей является озвучивание этого в списках рассылки до того, как посылать сообщение о проблеме. Уведомление об обновлении программного обеспечения, которое поддерживается сторонними разработчиками (в основном порты, но также и компоненты базовой системы, разрабатываемые сторонними организациями, такие, как BIND или различные утилиты GNU). Кроме того, если система, на которой вы столкнулись с ошибкой, давно не обновлялась, вы должны серьезно подумать об обновлении и попытаться воспроизвести проблему на обновленной системе прежде, чем посылать сообщение о проблеме. Есть лишь несколько вещей, которые выводят из себя разработчика больше, чем получение сообщений об уже исправленных ошибках. И наконец, ошибка, которую нельзя воспроизвести, вряд ли будет исправлена. Если ошибка возникла только единожды, и вы не можете ее воспроизвести, к тому же никто с ней больше не сталкивался, нет никаких шансов, что разработчики смогут ее воспроизвести или понять, что делается неправильно. Это не значит, что такого не случается, но это значит, что шансов у вашего сообщения дойти когда-либо до стадии исправления ошибки - очень малы, и вам лучше его не посылать. + очень малы. Часто эти виды ошибок возникают из-за неудовлетворительной + работы жёстких дисков, перегревшихся процессоров. Всегда, когда это + возможно вы должны отслеживать такие случаи перед посылкой сообщения об + ошибке.
Подготовка Нужно следовать хорошему правилу всегда сначала выполнять дополнительные исследования перед тем, как послать сообщение о проблеме. Может быть, о вашей проблеме уже сообщено; может быть, она недавно обсуждалась или обсуждается в списках рассылки; она может быть уже исправлена в более новой версии, чем та, что вы используете. Поэтому вы должны проверить все обычные места до того, как послать ваше сообщение о - проблеме. Для FreeBSD это значит: + проблеме. Для &os; это значит: - FreeBSD - FAQ + &os; + FAQ (Ответы на часто задаваемые вопросы). FAQ содержит ответы на вопросы из самых разных категорий, в частности, - аппаратной + аппаратной совместимости, - пользовательских + пользовательских программ - и конфигурации + и конфигурации ядра. Списки + url="&url.books.handbook;/handbook/eresources.html#ERESOURCES-MAIL">Списки рассылки—если Вы не подписаны на них, воспользуйтесь поиском - в архивах на сайте FreeBSD. Если ваша проблема не + url="http://www.FreeBSD.org/search/search.html#mailinglists">поиском + в архивах на сайте &os;. Если ваша проблема не обсуждалась в списках рассылки, вы можете попытаться опубликовать сообщение о ней и подождать несколько дней, пока кто-нибудь не сможет увидеть то, что вы не заметили. Как вариант, весь веб—используйте вашу любимую поисковую систему для поиска каких-либо ссылок по вашей проблеме. Вы можете даже увидеть ссылки на архивы списков рассылки или телеконференций, о которых вы не знали или не думали там искать. Следующим пунктом должна быть - - база данных PR FreeBSD (GNATS). Если только ваша проблема не + + база данных PR &os; (GNATS). Если только ваша проблема не нова или редка, есть некоторый шанс, что о ней уже сообщено. - Наконец, если вы обновляли версию системы (в особенности, если - вы обновляете ветку -current), вам следует - тщательно изучить содержимое файла - /usr/src/UPDATING или его текущую версию по адресу - . - Этот файл содержит немало жизненно важной информации. + И самое важное, вы должны посмотреть не затрагивает ли + документация в базовой системе вашу проблему. + + Для основного кода &os; вы должны тщательно изучить содержимое + файла /usr/src/UPDATING или его текущую версию + по адресу + . + (Если вы переходите с одной версии на другую, особенно если вы + обновляетесь до &os.current;, то в этом файле вы можете найти много + важной информации). + + Если же ваша проблема связана с коллекцией портов &os;, вы должны + обратиться к файлу /usr/ports/UPDATING + (изменения, касающиеся индивидуальных портов) или к + /usr/ports/CHANGES (изменения, касающиеся всей + коллекции портов). Они также доступны через интерфейс CVSweb: и + . + + Теперь вам нужно добиться того, чтобы сообщение о проблеме попало в нужные руки. Здесь первым правилом будет то, что если проблема является ошибкой в программном обеспечении сторонних разработчиков (порт или пакет, которые вы установили), то вы должны сообщить об ошибке автору программы, а не в - Проект FreeBSD. Есть два исключения из этого правила: во-первых, если + Проект &os;. Есть два исключения из этого правила: во-первых, если ошибка не проявляется на других платформах, то в этом случае проблема может заключаться в том, как программное обеспечение было перенесено на - FreeBSD; во-вторых, если автор уже исправил ошибку и выпустил патч или - новую версию своей программы, а порт FreeBSD еще не был обновлен. + &os;; во-вторых, если автор уже исправил ошибку и выпустил патч или + новую версию своей программы, а порт &os; еще не был обновлен. - Вторым правилом является то, что система отслеживания ошибок FreeBSD + Вторым правилом является то, что система отслеживания ошибок &os; сортирует сообщения о проблеме в соответствии с категорией, выбранной тем, кто сообщает о проблеме. Таким образом, если вы выберете неправильную категорию при отправке сообщения о проблеме, есть большая вероятность того, что его не заметят до тех пор, пока кто-нибудь не сменит его категорию.
Написание сообщения о проблеме Теперь, после того, как вы решили, что ваш вопрос подпадает под - категорию сообщения о проблеме, и это проблема FreeBSD, самое время + категорию сообщения о проблеме, и это проблема &os;, самое время написать собственно сообщение о проблеме (PR). Прежде чем мы углубимся в частности использования программы для создания и отправки PR, вот несколько советов, которые помогут вам сделать PR более эффективным.
Как писать хорошие сообщения о проблемах Основным языком общения разработчиков FreeBSD является английский. База данных по проблемам также ведется на английском. Если вы испытываете проблемы с формулировкой описания проблемы по-английски, свяжитесь со своими соотечественниками, которые помогут вам составить PR. Не оставляйте поле Synopsis (краткое описание) пустым. Сообщения о проблемах попадают как в списки рассылки, которые затем расходятся по всему миру (в них поле Synopsis определяет тему письма), так и в базу данных. Просматривающий эту базу, как правило, пройдет мимо PR с пустым кратким описанием. Не забудьте, что PR остается в базе до тех пор, пока кто-либо не закроет его; сообщение-аноним, скорее всего, просто потеряется на общем фоне. Избегайте туманных описаний в поле Synopsis. Не стоит предполагать, что читающий ваше сообщение владеет контекстом; поэтому, чем подробнее вы опишете ситуацию, тем лучше. В частности, к какой части системы относится ваша проблема? Проявляется ли она на этапе установки или во время нормальной работы? Например, вместо строки Synopsis: portupgrade is broken следовало бы написать что-то вроде Synopsis: port sysutils/portupgrade coredumps on -current. В случае портированных приложений в поле Synopsis полезно указывать не только имя порта, но и категорию. Если у вас есть готовый патч, скажите об этом. PR, содержащий патч, имеет куда больше шансов быть рассмотренным. В этом случае добавьте строку [patch] в начало поля Synopsis (хотя использование именно этой формы необязательно, она является стандартом де-факто). Если вы отвечаете за исходные тексты, сообщите об этом. Если вы отвечаете за часть исходных текстов - (например, порт) можете - добавить в начало поля Synopsis строку + (например, порт), вы можете добавить в начало поля + Synopsis строку [maintainer update], а также установить класс - вашего сообщения (поле Class) в + вашего PR (поле Class) в maintainer-update. В этом случае коммиттеру, - обрабатывающему ваш PR, не придется лишний раз сверяться с файлом - Makefile. + обрабатывающему ваш PR, не придётся лишний раз проверять. Будьте точны в формулировках. Чем больше информации вы можете предоставить о проблеме, тем больше - у вас шансов получить ответ. Например, следует предоставить - информацию о версии системы, на которой вы работаете (для этого - предназначено специальное поле, см. ниже), о платформе, работаете ли - вы на версии с CD-ROM или обновлялись посредством &man.cvsup.1; - (если да, то укажите момент обновления). В случае проблем с ядром - укажите, что вы прочли файл src/UPDATING, иначе - кто-нибудь обязательно спросит, делали ли вы это. Нет - необходимости сразу предоставлять файл конфигурации ядра, список - установленных портов и/или образ памяти; однако, вы должны быть - готовы выслать или предоставить их по запросу. - + у вас шансов получить ответ. + + + + Включите информацию о версии &os;, которую вы используйте + (существует специальное поле для его включения, смотрите ниже) + и на какой архитектуре. Сообщите, используете ли вы release + версию (установили с компакт-диска либо загрузили) или скачали + её с помощью &man.cvsup.1; (если так, то как давно вы + обновлялись). Если вы используйте &os.current;, то первый вопрос, + который вам могут задать, будет про дату последнего обновления, + так как исправления для этой ветки имеют + тенденцию (особенно для серьёзных проблем) появляться слишком + быстро. + + + + Включите информацию о том, какие глобальные опции вы указали + в make.conf. На заметку: Объявление + опций наподобие -02 и других, описанных в + &man.gcc.1; во многих случаях может быть причиной ошибок. Хотя + и разработчики &os; будут принимать патчи, у них не будет + желания исследовать такие случаи из-за отсутствия времени и + добровольцев, и вместо этого они могут ответить, что это не + поддерживается. + + + + Если ваша проблема связана с ядром, будьте готовы предоставить + следующую информацию (вам не обязательно включать её всю, она пойдёт лишь + на заполнение базы данных, но вы должны включить информацию, + которая по вашему мнению актуальна): + + + + Вашу конфигурацию ядра, включая то, какие устройства у вас + установлены + + + Включены ли у вас опции отладки (например, + WITNESS), и если так, то существует ли + проблема после изменения значения этой опции + + + дамп, если был сгенерирован + + + Прочли ли вы src/UPDATING, описана ли + там ваша проблема (кто-нибудь спросит обязательно) + + + + Запускается ли другое ядро (это для тех случаев, + когда причиной сбоя стало оборудование, например + отказывающие винчестеры или перегревшиеся процессоры, + что может маскировать проблемы ядра) + + + + + + Если же ваша проблема связана с портами, то предоставьте + следующую информацию (вам не обязательно включать её всю, + она пойдет лишь на заполнение базы данных, но вы должны + включить информацию, которая по вашему мнению актуальна): + + + + Какие порты вы устанавливали + + + Имеются ли какие-либо переменные окружения, + которые переписывают первоначально-установленные + в bsd.port.mk, такие как, + PORTSDIR) + + + Прочли ли вы ports/UPDATING, и + описана ли там ваша проблема (кто-нибудь спросит + обязательно) + + + + + + + Избегайте нечетких запросов о новых возможностях. Сообщение типа кто-то обязательно должен сделать так, чтобы такая-то утилита вела себя так-то имеет куда меньше шансов встретить позитивный отклик, чем более четко сформулированный запрос. Помните, что исходные тексты доступны всем, так что если вам нужна реализация какого-то нового свойства, лучший способ— взяться за работу самому! Не забудьте также, что такие моменты лучше обсуждать в списках рассылки, таких как freebsd-questions, чем делать это посредством базы данных PR. Убедитесь, что ваша проблема еще никем не описана. Мы уже говорили об этом, но стоит повториться. Потратьте пару минут на составление запросов к базе PR: - . + . (Несмотря на повторы, об этом постоянно забывают) Избегайте полемики. Если ваше сообщение касается области или способов реализации, которые ранее вызвали разногласия, вам стоит быть готовым предоставить не только патчи, но и внятные аргументы, почему следует поступать именно так (то есть, это Правильный Путь). Как отмечалось выше, аккуратный поиск по архиву списков рассылки - + никогда не помешает. Будьте вежливы. Почти каждый из тех, кто может заниматься вашим сообщением, является добровольцем. Никому не понравятся указания, как и что делать, когда он и так занимается этим, да еще и по каким-либо причинам, отличным от финансовых. Вообще говоря, этого подхода следует придерживаться, имея дело с любым проектом с Открытыми Исходными текстами (Open Source).
Прежде всего Перед запуском утилиты &man.send-pr.1; проверьте, что переменная вашего окружения VISUAL (или EDITOR, если VISUAL не задана) задана подходящим образом. Следует также проверить работоспособность системы электронной почты. Утилита &man.send-pr.1; использует почтовую систему для отправки и отслеживания сообщения о проблеме. Если с машины, на которой вы запускаете &man.send-pr.1;, нельзя отправить почту, сообщение не попадёт в базу данных GNATS. О настройке электронной - почты во FreeBSD можно прочитать в главе Электронная - почта Руководства по FreeBSD по адресу Электронная + почта Руководства по &os; по адресу .
Вложение патчей или файлов Программа &man.send-pr.1; предусматривает присоединение файлов к сообщению о проблеме. Вы можете вложить сколько угодно файлов, но каждый с уникальным именем (имеется в виду имя файла без маршрута). Просто используйте параметр командной строки для задания имен файлов, которые вы хотите присоединить: &prompt.user; send-pr -a /var/run/dmesg -a /tmp/errors Не беспокойтесь о бинарных файлах, они будут автоматически перекодированы для того, чтобы не повредить работе вашей почтовой программы. Если вы вкладываете патч, обязательно используйте параметр или вместе с командой &man.diff.1; для создания контекстного или унифицированного diff-файла (унифицированный формат предпочтителен), и обязательно укажите точные номера версий CVS файлов, которые вы изменяли, чтобы разработчики, которые будут читать ваше сообщение, - смогли легко его применить. Предпочтительным является патч - относительно ветки CURRENT или HEAD CVS, поскольку весь новый код - должен быть сначала оттестирован в -CURRENT. После завершения - тестирования код будет интегрирован в ветвь STABLE. + смогли легко его применить. Для проблем, связанных с ядром или с + базовыми утилитами предпочтительнее будет патч относительно ветки + &os.current; (или HEAD CVS), т.к. весь новый код должен быть сначала + протестирован в ней. После завершения тестирования код будет + интегрирован в ветвь &os.stable;. Если вы вставляете патч в тело сообщения, учтите, что некоторые почтовые программы имеют тенденцию заменять табуляции серией пробелов, что полностью разрушит, например, часть файла сборки (Makefile). Следует также заметить, что включение небольших патчей в сообщение о проблеме является приемлемой практикой, в особенности если они решают проблему, описанную в сообщении, большие же патчи, а в особенности новый код, который может требовать значительного просмотра перед тем, как он будет внесен в дерево исходных текстов, должны быть размещены на web- или ftp-сервере, а в сообщение о проблеме должен быть включён только URL указывающий на этот патч. Очень часто патчи, пересылаемые по электронной почте, а в особенности если задействована GNATS, бывают искажены, и, как следствие, чем больше патч, тем труднее будет для заинтересованных людей привести его к нормальному виду. Также то, что патч будет размещён отдельно от сообщения о проблеме, даёт возможность изменять его не отсылая полный патч в дополнение к изначальному сообщению о проблеме. Вы должны также помнить, что пока вы явно не укажете обратного в вашем сообщении о проблеме или в самих патчах, будет предполагаться, что они подпадают под те же условия лицензирования, что и оригинальный файл, измененный вами.
Заполнение шаблона После запуска утилиты &man.send-pr.1; вам будет представлен шаблон сообщения о проблеме. Шаблон состоит из списка полей, некоторые из которых уже заполнены, а некоторые содержат комментарии, объясняющие назначение поля или перечисляющие подходящие значения. Не беспокойтесь о комментариях; они будут автоматически удалены, если вы их не изменяли (или удалите их сами). Вверху шаблона, ниже строк SEND-PR: находятся заголовки почтового сообщения. Вам обычно не нужно их изменять, если только вы не посылаете сообщение о проблеме с машины или от учетной записи, которая может посылать, но не может получать электронную почту, в случае чего вы можете задать в полях From: и Reply-To: ваши реальные адреса электронной почты. Вы можете также послать самому себе (или кому-то еще) копию сообщения о проблеме, добавив один или большее количество адресов к заголовку Cc:. Далее следует последовательности однострочных полей: Submitter-Id: Не меняйте его. Значение по умолчанию current-users правильно, даже если - вы используете FreeBSD-STABLE. + вы используете &os.stable;. Originator: Обычно оно заполнено полем дополнительной информации учетной записи пользователя. Пожалуйста, укажите ваше реальное имя, за которым опционально следует адрес вашей электронной почты в угловых скобках. Organization: Все, что вы захотите здесь указать. Это поле не содержит значительной информации. Confidential: Предварительно заполнено как no, его изменение не имеет значения, так как нет такого понятия, как конфиденциальное сообщение о проблеме—база данных PR распространяется по всему миру посредством CVSup. Synopsis: Заполняется кратким и точным описанием проблемы. Краткое описание используется в качестве темы сообщения электронной почты о проблеме, и используется при выдаче списков и выборках сообщений о проблемах; сообщения о проблемах с непонятными краткими описаниями чаще всего игнорируются. Повторим: если к вашему сообщению о проблеме приложен патч, то, пожалуйста, начните краткое описание с [patch]; если вы являетесь ответственным за данную часть кода или порт, можете начать описание с - [maintainer update] и/или установить класс - проблемы (поле Class) в + [maintainer update] и установить класс проблемы + (поле Class) в maintainer-update. Severity: Одно из non-critical, serious или critical. Не переусердствуйте; избегайте пометки вашей проблемы как critical, если только это не действительно - критичная проблема (к примеру, уязвимость пользователя root, легко - воспроизводимый останов системы). Разработчики чаще всего - игнорируют это и следующее поля, и именно потому, что посылающие - слишком часто переоценивают критичность своих проблем. + критичная проблема (к примеру, уязвимость пользователя + root, легко воспроизводимый останов системы), + или serious, если только это не касается многих + пользователей (проблемы с конкретными драйверами устройств или с + системными утилитами). Разработчики &os; не обязательно будут + работать над вашей проблемой быстрее, если вы установите слишком + высокий уровень важности, т.к. существует много других людей, + которые сделали тоже самое — некоторые разработчики всё же + уделят этому полю немного внимания и перейдут к следующему + сообщению именно из-за этого поля. Priority: Одно из low, medium или - high. Смотрите выше. + high. high должен + использоваться для проблем, которые затронут конкретно + каждого пользователя &os;, а medium для чего-то, + что затронет многих пользователей. - Category: Выберите одно из - следующего: + Category: Выберите одну из + следующих (взято из + ): advocacy: проблемы, связанные с - общественным мнением о FreeBSD. Используется редко. + общественным мнением о &os;. Используется редко. alpha: проблемы, специфичные для платформы Alpha. amd64: проблемы, специфичные для платформы AMD64. bin: проблемы с пользовательскими программами из базовой системы. conf: проблемы с файлами настройки, используемыми по умолчанию значениями и прочее. docs: проблемы со страницами справочной системы или онлайновой документацией. gnu: проблемы с программным обеспечением GNU, таким как &man.gcc.1; или &man.grep.1;. i386: проблемы, специфичные для платформы &i386;. ia64: проблемы, специфичные для платформы ia64. - java: проблемы, связанные с &java;. + java: проблемы, связанные с виртуальной + машиной &java;. (Портированные приложения, требующие + для своей работы &java; должны находиться в коллекции портов.) - kern: проблемы с ядром. + kern: проблемы с ядром или с не + связанными с какой-либо платформой драйверами устройств. misc: все, что не подпадает ни под какую другую категорию (Надо отметить, что проблемы этой категории имеют тенденцию теряться легче всего). ports: проблемы, связанные с деревом портов. powerpc: проблемы, специфичные для платформы &powerpc;. sparc64: проблемы, специфичные для платформы &sparc64;. standards: проблемы, связанные с соответствием стандартам. + + threads: проблемы, касающиеся + реализации тредов во &os; (особенно во &os.current;). + + + + usb: проблемы, относящиеся к реализации + USB во &os;. + + www: изменения или улучшения сайта - FreeBSD + &os; Class: Выберите одно из следующего: sw-bug: ошибки в программном обеспечении. doc-bug: ошибки в документации. change-request: запросы на расширение функций или изменение в существующих. update: обновления портов или другого программного обеспечения сторонних разработчиков. maintainer-update: обновления в портах, для которых вы являетесь ответственной персоной. - Release: Используемая вами версия FreeBSD. + Release: Используемая вами версия &os;. Оно заполняется автоматически программой &man.send-pr.1; и требует изменения, если только вы отсылаете сообщение о проблеме с системы, отличающейся от той, где вы столкнулись с проблемой. И наконец, последовательность многострочных полей: Environment: Оно должно максимально точно описывать окружение, в котором встречается проблема. Сюда включается версия операционной системы, версия конкретной программы или файла, содержащего проблему, и любая другая информация, такая, как конфигурация системы, другое программное обеспечение, которое влияет на проблему, и так далее—просто все, что разработчик должен знать для создания условий появления проблемы. Description: Полное и точное описание проблемы, с которой вы столкнулись. Попытайтесь избежать своих предположений о причинах проблемы, если только вы не уверены, что правы, так как вы можете привести разработчика к неправильным предположениям о проблеме. How-To-Repeat: Последовательность действий, которые должны быть выполнены для повторения проблемы. Fix: Предпочтителен патч, или по крайней мере обходной путь (который не только поможет другим людям обойти ту же самую проблему, но также поможет разработчику понять ее причины), однако если у вас нет никаких здравых идей, то лучше оставить это поле пустым, чем строит догадки.
Отправка сообщения о проблеме Как только вы заполните шаблон, сохраните его и выйдете из редактора, &man.send-pr.1; запросит вас s)end, e)dit or a)bort?. Вы можете нажать s для продолжения и отправки сообщения о проблеме, e для повторного запуска редактора и выполнения дальнейших изменений, или a для отказа от вашего сообщения. Если вы выберете последнее, то ваше сообщение о проблеме останется на диске (&man.send-pr.1; укажет вам имя файла перед завершением работы), так что вы сможете отредактировать его на свой вкус или передать в систему с лучшим подключением к сети, перед тем, как послать его при помощи параметра программы &man.send-pr.1;: &prompt.user; send-pr -f ~/my-problem-report При этом будет прочитан указанный файл, будет проверено содержимое, убраны комментарии и сообщение будет отослано.
Отслеживание После того, как ваше сообщение будет принято, вы получите по электронной почте уведомление, в котором будет указан номер для отслеживания, который был назначен вашему сообщению о проблеме и URL, который вы можете использовать для проверки его состояния. В случае удачи кто-нибудь проявит интерес к вашей проблеме и попытается ее решить, или, как это бывает, описать, почему это не является проблемой. Вы будете автоматически оповещаться о любом изменении состояния и получать копии всех комментариев или патчей, которые будут присоединяться в процессе отработки вашего сообщения о проблеме. Если кто-то запросит дополнительную информацию от вас, или вы вспомните или обнаружите нечто, что не указали в начальном сообщении, - просто пошлите письмо на адрес bug-followup@FreeBSD.org, - включив отслеживаемый номер в теме, чтобы система отслеживания сообщений - могла знать, к какому сообщению о проблеме его присоединить. - - Если сообщение о проблеме остается открытым после того, как проблема - была решена, просто отправьте сообщение (так, как это описано - выше), с указанием, что сообщение о проблеме может быть закрыто, и - если это возможно, объясните, как и когда проблема была устранена. + пожалуйста пошлите ваше дополнение (отклик) с помощью одного из этих + способов: + + + + Самый простой путь это использовать соответствующую ссылку + (followup) на индивидуальной веб страничке сообщения об ошибки, к + которой можно перейти, используя страничку + поиска PR. Кликнув на этой ссылке откроется окно для отправки + email с уже корректно заполненными полями To: и Subject: (если ваш + браузер сконфигурирован для этого). + + + + Или просто просто пошлите письмо на адрес + bug-followup@FreeBSD.org, включив отслеживаемый номер + в теме письма, чтобы система отслеживания сообщений могла знать, к + какому сообщению о проблеме его присоединить. + + + Если вы не включите отслеживаемый номер, + GNATS растеряется и создаст совершенно новое PR, которое будет + закреплено за администратором GNATS. В результате ваш отклик + затеряется до тех пор пока кто-нибудь не начнёт разгребать + скопившийся мусор, что может произойти спустя дни или даже + недели. + + Неправильно: Subject: that PR I sent + Правильно: Subject: Re: ports/12345: compilation problem with foo/bar + + + + + Если сообщение о проблеме остается открытым после того, как проблема + была решена, просто отправьте сообщение (так, как это описано + выше), с указанием, что сообщение о проблеме может быть закрыто, и + если это возможно, объясните, как и когда проблема была устранена.
Дополнительная литература Это список информационных ресурсов, относящихся к правильному написанию и обработке сообщений о проблемах. Он, без сомнения, не полон. How to Report Bugs Effectively—прекрасное эссе, которое написал Simon G. Tatham о составлении полезных (не специфичных для - FreeBSD) сообщений о проблемах. + &os;) сообщений о проблемах. - Problem + Problem Report Handling Guidelines—интересный взгляд на - обработку сообщений о проблемах самими разработчиками FreeBSD. + обработку сообщений о проблемах самими разработчиками &os;.