diff --git a/documentation/content/ru/articles/problem-reports/_index.adoc b/documentation/content/ru/articles/problem-reports/_index.adoc index 9cb82aaa19..7e3414365a 100644 --- a/documentation/content/ru/articles/problem-reports/_index.adoc +++ b/documentation/content/ru/articles/problem-reports/_index.adoc @@ -1,252 +1,265 @@ --- authors: - author: 'Dag-Erling Smørgrav' - author: 'Mark Linimon' description: 'Как лучше сформулировать и отправить отчёт о проблеме в проект FreeBSD' tags: ["formulate", "submit", "FreeBSD", "PR"] title: 'Составление сообщений о проблеме во FreeBSD' trademarks: ["freebsd", "ibm", "intel", "sun", "general"] --- = Составление сообщений о проблеме во FreeBSD :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :images-path: articles/problem-reports/ ifdef::env-beastie[] ifdef::backend-html5[] include::shared/authors.adoc[] include::shared/mirrors.adoc[] include::shared/releases.adoc[] include::shared/attributes/attributes-{{% lang %}}.adoc[] include::shared/{{% lang %}}/teams.adoc[] include::shared/{{% lang %}}/mailing-lists.adoc[] include::shared/{{% lang %}}/urls.adoc[] :imagesdir: ../../../images/{images-path} endif::[] ifdef::backend-pdf,backend-epub3[] include::../../../../shared/asciidoctor.adoc[] endif::[] endif::[] ifndef::env-beastie[] include::../../../../../shared/asciidoctor.adoc[] endif::[] [.abstract-title] Аннотация Эта статья описывает, как наилучшим образом сформулировать и отправить сообщение о проблеме в Проект FreeBSD. ''' toc::[] +[[pr-scope]] +== Область применения данной статьи + +Изначально эта статья была написана для описания отправки отчётов о проблемах через Bugzilla, но некоторые её разделы также применимы при отправке через систему рецензирования Phabricator или через организацию FreeBSD на Github. + [[pr-intro]] == Введение -Одной из самых разочаровывающих практик, которую можно получить в качестве пользователя программного обеспечения, является отправка сообщения о проблеме, которое вскоре закрывается с кратким и ничему не помогающим объяснением типа "это не проблема" или "неправильное PR". Подобным же образом одной из самых разочаровывающих практик, которую можно получить в качестве разработчика программного обеспечения, является получение массы сообщений о проблемах, которые на самом деле не являются сообщениями о проблемах, а запросами на получение поддержки, или которые содержат мало или вообще не содержат никакой информации о сути проблемы или способе ее воспроизведения. +Одной из самых разочаровывающих практик, которую можно получить в качестве пользователя программного обеспечения, является отправка сообщения о проблеме, которое вскоре закрывается с кратким и ничему не помогающим объяснением типа "это не проблема" или "неправильный отчет". Подобным же образом одной из самых разочаровывающих практик, которую можно получить в качестве разработчика программного обеспечения, является получение массы сообщений о проблемах, которые на самом деле не являются сообщениями о проблемах, а запросами на получение поддержки, или которые содержат мало или вообще не содержат никакой информации о сути проблемы или способе её воспроизведения. В этом документе делается попытка описать то, как составлять хорошие сообщения о проблемах. Что же, спросите вы, является хорошим сообщением о проблеме? Ну, если перейти прямо к сути, то хорошим сообщением об проблеме является то, которое может быть быстро проанализировано и отработано, к обоюдному удовлетворению как пользователя, так и разработчика. -Хотя в основном статья фокусируется на сообщениях о проблемах во FreeBSD, большей частью она должна хорошо подходить и другим программным проектам. +Хотя в основном статья фокусируется на отправке сообщений о проблемах во FreeBSD с помощью Bagzilla, большей частью она должна хорошо подходить и другим случаям. Заметьте, что эта статья организована по тематическому принципу, а не хронологически, так что вы должны прочесть документ целиком прежде, чем посылать сообщение о проблеме, и не воспринимать статью как пошаговое руководство. [[pr-when]] == Когда нужно отправлять сообщение о проблеме -Имеется много классов ошибок, и не все они должны приводить к появлению сообщения о проблеме. Конечно же, нет идеальных людей, и будут моменты, когда вы решите, что нашли ошибку в программе, а на самом деле вы неправильно поняли синтаксис команды или сделали опечатку в конфигурационном файле (хотя само по себе это иногда говорит о плохой документации или неправильной обработке ошибок в прикладной программе). Есть еще много случаев, когда посылка сообщения о проблеме явно _не_ является правильным действием, а только приводит к разочарованию вас и разработчиков. И наоборот, есть случаи, когда может быть нужно послать сообщение о чем-то, не являющемся ошибкой - к примеру, запрос на доработку или расширение функциональности. +Имеется много классов ошибок, и не все они должны приводить к появлению сообщения о проблеме. Конечно же, нет идеальных людей, и будут моменты, когда вы решите, что нашли ошибку в программе, а на самом деле вы неправильно поняли синтаксис команды или сделали опечатку в конфигурационном файле (хотя само по себе это иногда говорит о плохой документации или неправильной обработке ошибок в прикладной программе). Есть ещё много случаев, когда посылка сообщения о проблеме явно _не_ является правильным действием, а только приводит к разочарованию вас и разработчиков. И наоборот, есть случаи, когда может быть нужно послать сообщение о чем-то, не являющемся ошибкой - к примеру, запрос на доработку или расширение функциональности. -Но как же определить, что является ошибкой, а что нет? Простым правилом, которому нужно следовать, является следующее - ваша проблема _не_ является ошибкой, если она формулируется как вопрос (обычно в форме "Как сделать X?" или "Где можно найти Y?"). Не всегда это так однозначно, но правило вопроса покрывает большинство случаев. Если Вам нужен ответ, лучше всего задать свой вопрос в {freebsd-questions}. +Но как же определить, что является ошибкой, а что нет? Простым правилом, которому нужно следовать, является следующее - ваша проблема _не_ является ошибкой, если она формулируется как вопрос (обычно в форме "Как сделать X?" или "Где можно найти Y?"). Не всегда это так однозначно, но правило вопроса покрывает большинство случаев. Если Вам нужен ответ, лучше всего сначала проконсультироваться https://forums.freebsd.org[на форумах FreeBSD], в IRC или в {freebsd-questions}. Вот некоторые случаи, в которых может оказаться полезным отправить сообщение о чем-то, что не является ошибкой: * Уведомление об обновлении программного обеспечения, которое поддерживается сторонними разработчиками (в основном порты, но также и компоненты базовой системы, разрабатываемые сторонними организациями, такие, как BIND или различные утилиты GNU). -* Для не поддерживаемых никем портов (переменная `MAINTAINER` содержит `ports@FreeBSD.org`), такие уведомления о обновлении будут замечены заинтересовавшимся коммиттером и вас могут попросить предоставить патч для обновления порта; предоставление патча до того, как вас попросят об этом сильно увеличит шансы того, что порт будет обновлён вовремя. +* Для не поддерживаемых никем портов (переменная `MAINTAINER` содержит `ports@FreeBSD.org`) отчёт о проблеме без приложенного файла с исправлениями едва ли будет замечен коммиттером. Чтобы стать сопровождающим порта, у которого не было сопровождающего, отправьте отчёт с запросом (файл с исправлением желателен, но не обязателен). * В любом случае, следование процессу, описанному в extref:{porters-handbook}upgrading[Руководстве по созданию портов] даст наилучшие результаты. (Также можно ознакомиться с статьей extref:{contributing}[Вклад в коллекцию портов FreeBSD, ports-contributing].) -Ошибка, которую нельзя воспроизвести, вряд ли будет исправлена. Если ошибка возникла только единожды, и вы не можете ее воспроизвести, к тому же никто с ней больше не сталкивался, нет никаких шансов, что разработчики смогут ее воспроизвести или понять, что делается неправильно. Это не значит, что такого не случается, но это значит, что шансов у вашего сообщения дойти когда-либо до стадии исправления ошибки очень малы. Часто эти виды ошибок возникают из-за неудовлетворительной работы жёстких дисков, перегревшихся процессоров. Всегда, когда это возможно вы должны отслеживать такие случаи перед посылкой сообщения об ошибке. +Ошибка, которую нельзя воспроизвести, вряд ли будет исправлена. Если ошибка возникла только единожды, и вы не можете её воспроизвести, к тому же никто с ней больше не сталкивался, нет никаких шансов, что разработчики смогут её воспроизвести или понять, что делается неправильно. Это не значит, что такого не случается, но это значит, что шансов у вашего сообщения дойти когда-либо до стадии исправления ошибки очень малы. Часто эти виды ошибок возникают из-за неудовлетворительной работы жёстких дисков, перегревшихся процессоров. Всегда, когда это возможно вы должны отслеживать такие случаи перед посылкой сообщения об ошибке. Теперь, чтобы определить кому вы должны отправить ваше сообщение об ошибке, вы должны понимать, что программное обеспечение, которое входит во FreeBSD, составляется из нескольких различных частей: * Код в базовой системе, который пишется и поддерживается контрибьюторами FreeBSD. Такой, как ядро, библиотека C, драйвера устройств (входят в категорию `kern`); утилиты (`bin`); страницы справочника и документация (`docs`); веб-страницы (`www`). Все ошибки в этих областях должны быть сообщены разработчикам FreeBSD. * Код в базовой системе, который пишется и поддерживается другим, импортируется во FreeBSD и адаптируется. Примеры включают в себя: bind, man:gcc[1] и man:sendmail[8]. Большинство ошибок, попадающие в данные области должны быть сообщены разработчикам FreeBSD, но в некоторых случаях они должны быть отправлены изначальным разработчикам, если проблемы не являются специфичными для FreeBSD. Обычно ошибки такого рода попадают под категории `bin` или `gnu`. * Отдельные приложения, не входящие в базовую систему, но являющиеся частью Коллекции Портов FreeBSD (категория `ports`). Большинство этих приложений не пишется разработчиками FreeBSD; что предоставляет FreeBSD, так это только лишь инфраструктуру для установки приложения. Следовательно, вы должны отправлять сообщение об ошибке разработчикам FreeBSD только тогда, когда вы уверены в том, что проблема специфична для FreeBSD - иначе отправляйте её авторам программного обеспечения. Затем вы должны убедиться, действительно ли проблема существует. Существует всего несколько вещей, которые раздражают разработчика больше, чем получение сообщения об ошибке, которую он уже исправил. -Если проблема в базовой системе, то вам нужно сначала прочесть раздел extref:{faq}[версии FreeBSD, latest-version] из FAQ, если вы ещё не знакомы с данной темой. Для FreeBSD возможно исправлять проблемы только для некоторых недавних веток базовой системы, поэтому отправка сообщения об ошибке для более старой версии приведёт к тому, что разработчик посоветует вам обновиться до поддерживаемой версии, чтобы посмотреть присутствует ли в ней проблема. Команда офицеров безопасности поддерживает link:https://www.FreeBSD.org/security/[список поддерживаемых версий.]. +Если проблема в базовой системе, то вам нужно сначала прочесть раздел extref:{handbook}cutting-edge[Руководства FreeBSD о версиях], если вы ещё не знакомы с данной темой. Для FreeBSD возможно исправлять проблемы только для некоторых недавних веток базовой системы, поэтому отправка сообщения об ошибке для более старой версии приведёт к тому, что разработчик посоветует вам обновиться до поддерживаемой версии, чтобы посмотреть присутствует ли в ней проблема. Команда офицеров безопасности поддерживает link:https://www.FreeBSD.org/ru/security/#sup[список поддерживаемых версий.]. Если проблема в порте, рассмотрите возможность сообщить об ошибке разработчикам исходного проекта. Проект FreeBSD не может исправлять все ошибки во всём программном обеспечении. [[pr-prep]] == Подготовка Нужно следовать хорошему правилу всегда сначала выполнять дополнительные исследования перед тем, как послать сообщение о проблеме. Может быть, о вашей проблеме уже сообщено; может быть, она недавно обсуждалась или обсуждается в списках рассылки; она может быть уже исправлена в более новой версии, чем та, что вы используете. Поэтому вы должны проверить все обычные места до того, как послать ваше сообщение о проблеме. Для FreeBSD это значит: -* Список extref:{faq}[Часто задаваемых вопросов] (FAQ) по FreeBSD. FAQ содержит ответы на широкий круг вопросов, таких как вопросы, касающиеся extref:{faq}[совместимости оборудования, hardware], extref:{faq}[пользовательских приложений, applications] и extref:{faq}[конфигурации ядра, kernelconfig]. -* extref:{handbook}eresources/[Списки рассылки, eresources-mail] — если Вы не подписаны на них, воспользуйтесь https://www.FreeBSD.org/search/#mailinglists[поиском в архивах] на сайте FreeBSD. Если ваша проблема не обсуждалась в списках рассылки, вы можете попытаться опубликовать сообщение о ней и подождать несколько дней, пока кто-нибудь не сможет увидеть то, что вы не заметили. +* Во-первых, всегда проверяйте, не описан ли этот вопрос в extref:{handbook}[Руководстве]. +* Список extref:{faq}[Часто задаваемых вопросов] (FAQ) по FreeBSD. FAQ содержит ответы на несколько вопросов, таких как вопросы, касающиеся extref:{faq}[совместимости оборудования, hardware]. +* extref:{handbook}eresources/[Списки рассылки, eresources-mail] — если Вы не подписаны на них, воспользуйтесь https://www.FreeBSD.org/search/#mailinglists[поиском в архивах] на сайте FreeBSD. Если ваша проблема не обсуждалась в списках рассылки, вы можете попытаться опубликовать сообщение о ней и подождать несколько дней — возможно, кто-то заметит то, что было упущено. +* Как отмечалось выше, форумы FreeBSD и IRC. * Как вариант, весь веб-используйте вашу любимую поисковую систему для поиска каких-либо ссылок по вашей проблеме. Вы можете даже увидеть ссылки на архивы списков рассылки или телеконференций, о которых вы не знали или не думали там искать. -* Следующим пунктом должна быть https://bugs.freebsd.org/bugzilla/query.cgi[ база данных PR FreeBSD] (Bugzilla). Если только ваша проблема не нова или редка, есть некоторый шанс, что о ней уже сообщено. +* Следующим пунктом должна быть https://bugs.freebsd.org/bugzilla/query.cgi[ база данных FreeBSD Bugzilla]. Если только ваша проблема не нова или редка, есть некоторый шанс, что о ней уже сообщено. * И самое важное, вы должны посмотреть не затрагивает ли документация в базовой системе вашу проблему. + Для основного кода FreeBSD вы должны тщательно изучить содержимое файла [.filename]#/usr/src/UPDATING# или его текущую версию по адресу https://cgit.freebsd.org/src/tree/UPDATING[https://cgit.freebsd.org/src/tree/UPDATING]. (Если вы переходите с одной версии на другую, особенно если вы обновляетесь до FreeBSD-CURRENT, то в этом файле вы можете найти много важной информации). + Если же ваша проблема связана с коллекцией портов FreeBSD, вы должны обратиться к файлу [.filename]#/usr/ports/UPDATING# (изменения, касающиеся индивидуальных портов) или к [.filename]#/usr/ports/CHANGES# (изменения, касающиеся всей коллекции портов). Они также доступны через интерфейс cgit: https://cgit.freebsd.org/ports/tree/UPDATING[https://cgit.freebsd.org/ports/tree/UPDATING] и https://cgit.freebsd.org/ports/tree/CHANGES[https://cgit.freebsd.org/ports/tree/CHANGES] . [[pr-writing]] == Написание сообщения о проблеме -Теперь, после того, как вы решили, что ваш вопрос подпадает под категорию сообщения о проблеме, и это проблема FreeBSD, самое время написать собственно сообщение о проблеме (PR). Прежде чем мы углубимся в частности использования программы для создания и отправки PR, вот несколько советов, которые помогут вам сделать PR более эффективным. +Теперь, после того, как вы решили, что ваш вопрос подпадает под категорию сообщения о проблеме, и это проблема FreeBSD, самое время написать собственно сообщение о проблеме (PR). Прежде чем мы углубимся в частности использования программы для создания и отправки PR в Bugzilla, вот несколько советов, которые помогут вам сделать сообщение более эффективным. [[pr-writing-tips]] -== Как писать хорошие сообщения о проблемах +== Как писать хорошие сообщения о проблемах в Bugzilla -* _Не оставляйте поле "Summary" (краткое описание) пустым._ Сообщения о проблемах попадают как в списки рассылки, которые затем расходятся по всему миру (в них поле "Summary" определяет тему письма), так и в базу данных. Просматривающий эту базу, как правило, пройдет мимо PR с пустым кратким описанием. Не забудьте, что PR остается в базе до тех пор, пока кто-либо не закроет его; сообщение-аноним, скорее всего, просто потеряется на общем фоне. +* _Не оставляйте поле "Summary" (краткое описание) пустым._ Сообщения о проблемах попадают как в списки рассылки, которые затем расходятся по всему миру (в них поле "Summary" определяет тему письма), так и в базу данных. Просматривающий эту базу, как правило, пройдет мимо PR с пустым кратким описанием. Не забудьте, что PR остаётся в базе до тех пор, пока кто-либо не закроет его; сообщение-аноним, скорее всего, просто потеряется на общем фоне. * __Избегайте туманных описаний в поле "Summary"__. Не стоит предполагать, что читающий ваше сообщение владеет контекстом; поэтому, чем подробнее вы опишете ситуацию, тем лучше. В частности, к какой части системы относится ваша проблема? Проявляется ли она на этапе установки или во время нормальной работы? Например, вместо строки `Summary: portupgrade is broken` следовало бы написать что-то вроде `Summary: port ports-mgmt/portupgrade coredumps on -current`. В случае портированных приложений в поле "Summary" полезно указывать не только имя порта, но и категорию. * _Если у вас есть патч, сообщите об этом._ Наличие патча значительно упрощает обработку отчёта. -** Не используйте ключевые слова `patch` или `patch-ready` — они устарели. -* _Если вы сопровождаете код, укажите это._ Если вы сопровождаете часть исходного кода (например, существующий порт), обязательно установите «Class» вашего PR в значение `maintainer-update`. Таким образом, любой коммиттер, обрабатывающий ваш PR, не будет вынужден проверять это. +** Не используйте ключевые слова `patch` или `patch-ready` — они устарели. Вместо этого прикрепите патч как вложение и отметьте флажок `[patch]`. Если флажок не отображается, нажмите `Show Advanced Fields` (Показать расширенные поля) в левом верхнем углу. +** Предпочтительны файлы с исправлениями с MIME-типом `text/plain`. +** Предпочтительны патчи, совместимые с `git`. +* _Если вы сопровождаете порт, укажите это._ Если вы сопровождаете часть исходного кода (например, существующий порт), обязательно установите поле `maintainer-feedback` в вашем сообщении о проблеме в `+`. Таким образом, любой коммиттер, обрабатывающий ваш PR, не будет вынужден проверять это. * _Будьте точны в формулировках._ Чем больше информации вы можете предоставить о проблеме, тем больше у вас шансов получить ответ. ** Включите версию FreeBSD, которую вы используете (для этого есть специальное поле, см. ниже), и архитектуру. Укажите, используете ли вы релиз (например, с CD-ROM или загруженный) или систему, поддерживаемую через Git (и, если да, укажите хэш и ветку). Если вы используете ветку FreeBSD-CURRENT, укажите это в первую очередь, так как исправления (особенно для известных проблем) часто добавляются очень быстро, и пользователи FreeBSD-CURRENT должны следить за обновлениями. ** Включите информацию о том, какие глобальные опции вы указали в [.filename]#make.conf#. На заметку: Объявление опций наподобие `-02` и других, описанных в man:gcc[1] во многих случаях может быть причиной ошибок. Хотя и разработчики FreeBSD будут принимать патчи, у них не будет желания исследовать такие случаи из-за отсутствия времени и добровольцев, и вместо этого они могут ответить, что это не поддерживается. -** Если проблему можно легко повторить, включите необходимую информацию, чтобы разработчик смог воспроизвести ее самостоятельно. Если проблема проявляется при некоторых вводимых данных, то, по возможности, приведите их вместе с получаемым и ожидаемым выводом. Если же вводимых данных много или же их нельзя разглашать, то попробуйте выделить из них лишь небольшой фрагмент, приводящий к возникновению проблемы, и включите его в PR. +** Если проблему можно легко повторить, включите необходимую информацию, чтобы разработчик смог воспроизвести её самостоятельно. Если проблема проявляется при некоторых вводимых данных, то, по возможности, приведите их вместе с получаемым и ожидаемым выводом. Если же вводимых данных много или же их нельзя разглашать, то попробуйте выделить из них лишь небольшой фрагмент, приводящий к возникновению проблемы, и включите его в PR. ** Если ваша проблема связана с ядром, будьте готовы предоставить следующую информацию (вам не обязательно включать её всю, она пойдёт лишь на заполнение базы данных, но вы должны включить информацию, которая по вашему мнению актуальна): *** Вашу конфигурацию ядра, включая то, какие устройства у вас установлены *** Включены ли у вас опции отладки (например, `WITNESS`), и если так, то существует ли проблема после изменения значения этой опции *** Полный вывод обратной трассировки (backtrace), паники или иного консольного вывода, или же записи из [.filename]#/var/log/messages#, если они были сгенерированы *** Вывод команды `pciconf -l`, а также соответствующие части вывода `dmesg`, в случае, если проблема связана с конкретным оборудованием *** Прочли ли вы [.filename]#src/UPDATING#, описана ли там ваша проблема (кто-нибудь спросит обязательно) *** Запускается ли другое ядро (это для тех случаев, когда причиной сбоя стало оборудование, например отказывающие винчестеры или перегревшиеся процессоры, что может маскировать проблемы ядра) ** Если же ваша проблема связана с портами, то предоставьте следующую информацию (вам не обязательно включать её всю, она пойдет лишь на заполнение базы данных, но вы должны включить информацию, которая по вашему мнению актуальна): *** Какие порты вы устанавливали *** Имеются ли какие-либо переменные окружения, которые переписывают первоначально-установленные в [.filename]#bsd.port.mk#, такие как, `PORTSDIR`) *** Прочли ли вы [.filename]#ports/UPDATING#, и описана ли там ваша проблема (кто-нибудь спросит обязательно) -* _Избегайте нечетких запросов о новых возможностях._ Сообщение типа "кто-то обязательно должен сделать так, чтобы такая-то утилита вела себя так-то" имеет куда меньше шансов встретить позитивный отклик, чем более четко сформулированный запрос. Помните, что исходные тексты доступны всем, так что если вам нужна реализация какого-то нового свойства, лучший способ- взяться за работу самому! Не забудьте также, что такие моменты лучше обсуждать в списках рассылки, таких как `freebsd-questions`, чем делать это посредством базы данных PR. -* _Убедитесь, что ваша проблема еще никем не описана._ Мы уже говорили об этом, но стоит повториться. Потратьте пару минут на составление запросов к базе PR: https://bugs.freebsd.org/bugzilla/query.cgi[https://bugs.freebsd.org/bugzilla/query.cgi]. (Несмотря на повторы, об этом постоянно забывают) +* _Избегайте нечетких запросов о новых возможностях._ Сообщение типа "кто-то обязательно должен сделать так, чтобы такая-то утилита вела себя так-то" имеет куда меньше шансов встретить позитивный отклик, чем более четко сформулированный запрос. Помните, что исходные тексты доступны всем, так что если вам нужна реализация какого-то нового свойства, лучший способ — взяться за работу самому! Не забудьте также, что такие моменты лучше обсуждать в списках рассылки, таких как `freebsd-questions`, чем делать это посредством базы данных PR. +* _Убедитесь, что ваша проблема ещё никем не описана._ Мы уже говорили об этом, но стоит повториться. Потратьте пару минут на составление запросов в Bugzilla: https://bugs.freebsd.org/bugzilla/query.cgi[https://bugs.freebsd.org/bugzilla/query.cgi]. (Несмотря на повторы, об этом постоянно забывают) * _Сообщайте об одной проблеме в одном PR._ Избегайте описания двух и более проблем в одном сообщении (исключением являются взаимосвязанные проблемы). Оформляя патчи, не пытайтесь в них добавлять множество функциональных возможностей или исправлять ими несколько ошибок в одном и том же сообщении о проблеме (опять же, за исключением взаимосвязанных проблем) - для таких PR-ов потребуется значительно больше времени на обработку. * _Избегайте полемики._ Если ваше сообщение касается области или способов реализации, которые ранее вызвали разногласия, вам стоит быть готовым предоставить не только патчи, но и внятные аргументы, почему следует поступать именно так (то есть, это "Правильный Путь"). Как отмечалось выше, аккуратный поиск по архиву списков рассылки https://www.FreeBSD.org/search/#mailinglists[https://www.FreeBSD.org/search/#mailinglists] никогда не помешает. -* _Будьте вежливы._ Почти каждый из тех, кто может заниматься вашим сообщением, является добровольцем. Никому не понравятся указания, как и что делать, когда он и так занимается этим, да еще и по каким-либо причинам, отличным от финансовых. Вообще говоря, этого подхода следует придерживаться, имея дело с любым проектом с Открытыми Исходными текстами (Open Source). +* _Будьте вежливы._ Почти каждый из тех, кто может заниматься вашим сообщением, является добровольцем. Никому не понравятся указания, как и что делать, когда он и так занимается этим, да ещё и по каким-либо причинам, отличным от финансовых. Вообще говоря, этого подхода следует придерживаться, имея дело с любым проектом с Открытыми Исходными текстами (Open Source). [[pr-writing-before-beginning]] == Прежде всего -Аналогичные соображения применимы к использованию https://bugs.freebsd.org/bugzilla/enter_bug.cgi[веб-формы для отправки PR]. Будьте осторожны с операциями копирования и вставки, которые могут изменить пробелы или другое форматирование текста. +Следующие соображения применимы к использованию https://bugs.freebsd.org/bugzilla/enter_bug.cgi[веб-формы Bugzilla для отправки PR]. Будьте осторожны с операциями копирования и вставки, которые могут изменить пробелы или другое форматирование текста. И наконец, если ваше сообщение будет объёмным, вы должны приготовить его в offline, чтобы ничего не потерялось в случае, если будет проблема при его отправке. [[pr-writing-attaching-patches]] == Вложение патчей или файлов -В общем, мы рекомендуем использовать `git format-patch` для создания одного или серии унифицированных diff-файлов относительно базовой ветки (например, `origin/main`). Патчи, созданные таким образом, будут содержать хеши Git, а также ваше имя и адрес электронной почты, что упростит применение вашего патча коммиттерами и правильное указание вас как автора (с помощью `git am`). Для небольших изменений, где вы предпочитаете не использовать git, убедитесь, что используете man:diff[1] с опцией `-u` для создания унифицированного diff-файла, так как это даст разработчикам больше контекста и сделает его более читаемым по сравнению с другими форматами diff. +Следующие инструкции применимы не только к отправке отчётов о проблемах через Bugzilla, но также через Phabricator или организацию FreeBSD на Github (в виде пул-реквестов). + +В общем, мы настоятельно рекомендуем использовать `git format-patch` для создания одного или серии унифицированных diff-файлов относительно базовой ветки (например, `origin/main`). Патчи, созданные таким образом, будут содержать хеши Git, а также ваше имя и адрес электронной почты, что упростит применение вашего патча коммиттерами и правильное указание вас как автора (с помощью `git am`). Для небольших изменений, где вы предпочитаете не использовать git, убедитесь, что используете man:diff[1] с опцией `-u` для создания унифицированного diff-файла, так как это даст разработчикам больше контекста и сделает его более читаемым по сравнению с другими форматами diff. Убедитесь, что ваши патчи созданы от корня соответствующего дерева репозитория. Для проблем с ядром или базовыми утилитами предпочтителен патч для FreeBSD-CURRENT (основной ветки Git), поскольку весь новый код должен сначала применяться и тестироваться там. После проведения соответствующих или достаточных тестов код будет объединён/перенесён в ветку FreeBSD-STABLE. -Если вы вставляете патч в тело сообщения, учтите, что некоторые почтовые программы имеют тенденцию заменять табуляции серией пробелов, что полностью разрушит, например, часть файла сборки (Makefile). +Мы предпочитаем, чтобы файлы с исправлениями отправлялись, как вложение к сообщению. Однако, если вы вставляете патч в тело сообщения, учтите, что некоторые почтовые программы имеют тенденцию заменять табуляции серией пробелов, что полностью разрушит, например, часть файла сборки (Makefile). -Не отсылайте патчи в виде вложений, используя `Content-Transfer-Encoding: quoted-printable`. Это выполнит экранирование (escaping) символов и весь патч будет бесполезным. +Не отсылайте патчи в виде вложений, используя `Content-Transfer-Encoding: quoted-printable`. Это выполнит экранирование (escaping) символов и весь патч будет бесполезным. Пожалуйста, просто используйте тип MIME `text/plain'. -Следует также заметить, что включение небольших патчей в сообщение о проблеме является приемлемой практикой, в особенности если они решают проблему, описанную в сообщении, большие же патчи, а в особенности новый код, который может требовать значительного просмотра перед тем, как он будет внесен в дерево исходных текстов, должны быть размещены на web- или ftp-сервере, а в сообщение о проблеме должен быть включён только URL указывающий на этот патч. Очень часто патчи, пересылаемые по электронной почте, а в особенности если задействована GNATS, бывают искажены, и, как следствие, чем больше патч, тем труднее будет для заинтересованных людей привести его к нормальному виду. Также то, что патч будет размещён отдельно от сообщения о проблеме, даёт возможность изменять его не отсылая полный патч в дополнение к изначальному сообщению о проблеме. И наконец, большие патчи просто увеличивают размер базы данных, так как закрытые сообщения об ошибках на самом деле не удаляются, а сохраняются и помечаются, как `closed`. +Следует также заметить, что включение небольших патчей в запросах на изменение (pull request) Github является приемлемой практикой, в особенности если они решают проблему, описанную в запросе на изменение, большие же патчи, а в особенности новый код, который может требовать значительного просмотра перед тем, как он будет внесён в дерево исходных текстов, должны быть размещены на web- или ftp-сервере, а в запрос на изменение должен быть включён только URL указывающий на этот патч. Очень часто патчи, пересылаемые по электронной почте, бывают искажены, и, как следствие, чем больше патч, тем труднее будет для заинтересованных людей привести его к нормальному виду. Также то, что патч будет размещён отдельно от сообщения о проблеме, даёт возможность изменять его не отсылая полный патч в дополнение к изначальному сообщению о проблеме. И наконец, большие патчи просто увеличивают размер базы данных, так как закрытые сообщения об ошибках на самом деле не удаляются, а сохраняются и помечаются, как `closed`. -Вы должны также помнить, что пока вы явно не укажете обратного в вашем сообщении о проблеме или в самих патчах, будет предполагаться, что они подпадают под те же условия лицензирования, что и оригинальный файл, измененный вами. +Вы должны также помнить, что пока вы явно не укажете обратного в вашем запросе или в самих патчах, будет предполагаться, что они подпадают под те же условия лицензирования, что и оригинальный файл, измененный вами. [[pr-writing-filling-template]] -== Заполнение шаблона +== Заполнение формы Bugzilla + +Следующие инструкции применимы только к отправке через Bugzilla. [NOTE] ==== -Используемый вами адрес электронной почты станет общедоступной информацией и может попасть к спамерам. У вас должны быть процедуры обработки спама или следует использовать временный почтовый аккаунт. Однако учтите, что если вы вообще не используете действительный почтовый аккаунт, мы не сможем задать вам вопросы о вашем PR. +Используемый вами адрес электронной почты станет общедоступной информацией и может попасть к спамерам. У вас должны быть процедуры обработки спама или следует использовать временный почтовый аккаунт. Однако учтите, что если вы вообще не используете действительный почтовый аккаунт, мы не сможем задать вам вопросы о вашем сообщении. ==== При подаче сообщения об ошибке вы увидите следующие поля: * _Краткое описание:_ Заполните это кратким и точным описанием проблемы. Краткое описание используется как тема письма с отчётом о проблеме, а также в списках и сводках отчётов; отчёты с неясными описаниями часто остаются без внимания. * _Серьезность:_ Одно из значений: `Затрагивает только меня (Affects only me)`, `Затрагивает некоторых людей (Affects some people)` или `Затрагивает многих людей (Affects many people)`. Не переоценивайте проблему; избегайте отмечать её как `Затрагивает многих людей`, если это не так. Разработчики FreeBSD не обязательно будут работать над вашей проблемой быстрее, если вы преувеличите её важность, поскольку многие другие уже поступали точно так же. * _Категория:_ Выберите подходящую категорию. + Первое, что вам нужно сделать, — это определить, в какой части системы находится ваша проблема. Помните, что FreeBSD — это полноценная операционная система, которая включает в себя ядро, стандартные библиотеки, множество драйверов периферийных устройств и большое количество утилит («базовая система»). Однако в Коллекции портов доступны тысячи дополнительных приложений. Сначала вам нужно выяснить, связана ли проблема с базовой системой или с чем-то, установленным через Коллекцию портов. + Вот описание основных категорий: ** Если проблема в ядре, в библиотеках (таких как стандартная библиотека С `libc`) или в драйвере из базовой системы, то используйте категорию `kern`. (Есть несколько исключений, описанных ниже). В общем, это всё, что описано в разделах 2, 3 или 4 справочника. ** Если проблема с бинарной программой, например с man:sh[1] или man:mount[8], то вам прежде всего необходимо определить принадлежность программы к базовой системе или к установке из коллекции портов. Если вы не уверены, выполните команду `whereis _имя программы_`. В FreeBSD для коллекции портов существует договоренность: установка ведется в [.filename]#/usr/local#, однако это может быть переопределено системным администратором. Для таких программ следует использовать категорию `ports` (даже если категория порта `www`; см. ниже). Если программа располагается в [.filename]#/bin#, [.filename]#/usr/bin#, [.filename]#/sbin# или в [.filename]#/usr/sbin#, то это часть базовой системы, и вам следует использовать категорию `bin`. (Несколько программ, например man:gcc[1], на самом деле используют категорию `gnu`, но не беспокойтесь об этом сейчас.) Программы этой категории описаны в разделах 1 и 8 справочной системы. ** Если вы уверены, что в стартовых скриптах `(rc)` или в каком-то ином неисполняемом конфигурационном файле присутствует ошибка, тогда верной категорией будет `conf` (configuration). Эти сущности описываются в разделе 5 справочной системы. ** Если вы нашли проблему в наборе документации (статьи, книги, страницы справочной системы), правильным выбором будет `docs`. + [NOTE] ==== Если проблема с чем-то из порта, называемого `www/_имяпорта_`, то она все же принадлежит к категории `ports`. ==== + Далее представлены более специализированные категории. ** Если проблема принадлежит к `kern`, но в то же время имеет дело с подсистемой USB, то правильным выбором будет `usb`. ** Если проблема принадлежит к `kern` и найдена в потоковых библиотеках, правильным выбором будет `threads`. ** Если проблема принадлежит к базовой системе и касается соблюдения стандартов, таких как POSIX(R), правильным выбором будет `standards`. -** Если вы уверены, что проблема возникнет только на используемой вами архитектуре процессора, выберите одну из архитектурно-зависимых категорий: обычно `i386` для Intel-совместимых машин в 32-битном режиме; `amd64` для машин AMD, работающих в 64-битном режиме (это также включает Intel-совместимые машины, работающие в режиме EMT64); и реже `arm` или `powerpc`. +** Если вы уверены, что проблема возникнет только на используемой вами архитектуре процессора, выберите одну из архитектурно-зависимых категорий: обычно `i386` для Intel-совместимых машин в 32-битном режиме; `amd64` для машин AMD, работающих в 64-битном режиме (это также включает Intel-совместимые машины, работающие в режиме EMT64); и реже `arm`, `powerpc` или `riscv64`. + [NOTE] ==== Люди часто ошибаются в выборе категории. Если вы не уверены в правильности выбора, то лучше не гадать, а выбрать `misc`. ==== + .Правильное использование архитектурно-зависимых категорий [example] ==== У вас простой ПК, и вы подозреваете, что столкнулись с проблемой, специфичной для конкретного чипсета или материнской платы: верная категория - `i386`. ==== + .Некорректное использование категории, зависящей от архитектуры [example] ==== -Если вы наблюдаете проблему с периферийной картой расширения на распространённой шине или неполадки с конкретного типа жестким диском: в этом случае возможно, что неисправность наблюдается на более чем одной архитектуре, и верным выбором будет `kern`. +Если вы наблюдаете проблему с периферийной картой расширения на распространённой шине или неполадки с конкретного типа жёстким диском: в этом случае возможно, что неисправность наблюдается на более чем одной архитектуре, и верным выбором будет `kern`. ==== -** Если вы не знаете в чем проблема (или вам кажется, что описание не попадает ни под какую из вышеобозначенных), используйте категорию `misc`. Перед тем, как написать PR, можно для начала спросить помощи в {freebsd-questions}. Возможно, там вам подскажут, какую из существующих категорий следует выбрать. +** Если вы не знаете в чем проблема (или вам кажется, что описание не попадает ни под какую из вышеобозначенных), используйте категорию `misc`. Перед тем, как сделать так, можно для начала спросить помощи. Возможно, вам подскажут, какую из существующих категорий следует выбрать. * _Environment:_ Оно должно максимально точно описывать окружение, в котором встречается проблема. Сюда включается версия операционной системы, версия конкретной программы или файла, содержащего проблему, и любая другая информация, такая, как конфигурация системы, другое программное обеспечение, которое влияет на проблему, и так далее-просто все, что разработчик должен знать для создания условий появления проблемы. * _Описание:_ Полное и точное описание проблемы, с которой вы столкнулись. Старайтесь избегать предположений о причинах проблемы, если не уверены в своей правоте, так как это может ввести разработчика в заблуждение и привести к неверным выводам. В описании должны быть указаны действия, необходимые для воспроизведения проблемы. Если вам известен обходной путь, укажите его. Это не только поможет другим людям с той же проблемой временно её решить, но и может помочь разработчику понять причину возникновения проблемы. [[pr-followup]] == Отслеживание -После того, как ваше сообщение будет принято, вы получите по электронной почте уведомление, в котором будет указан номер для отслеживания, который был назначен вашему сообщению о проблеме и URL, который вы можете использовать для проверки его состояния. В случае удачи кто-нибудь проявит интерес к вашей проблеме и попытается ее решить, или, как это бывает, описать, почему это не является проблемой. Вы будете автоматически оповещаться о любом изменении состояния и получать копии всех комментариев или патчей, которые будут присоединяться в процессе отработки вашего сообщения о проблеме. +После того, как ваше сообщение будет принято, вы получите по электронной почте уведомление, в котором будет указан номер для отслеживания, который был назначен вашему сообщению о проблеме и URL, который вы можете использовать для проверки его состояния. В случае удачи кто-нибудь проявит интерес к вашей проблеме и попытается её решить, или, как это бывает, описать, почему это не является проблемой. Вы будете автоматически оповещаться о любом изменении состояния и получать копии всех комментариев или патчей, которые будут присоединяться в процессе отработки вашего сообщения о проблеме. -Если кто-то запросит у вас дополнительную информацию, или вы вспомните или обнаружите что-то, что не упомянули в первоначальном отчёте, пожалуйста, отправьте уточнение. Основная причина, по которой ошибка не исправляется, — это отсутствие связи с автором отчёта. Проще всего воспользоваться опцией комментария на веб-странице конкретного PR, которую можно открыть с https://bugs.freebsd.org/bugzilla/query.cgi[страницы поиска PR]. +Если кто-то запросит у вас дополнительную информацию, или вы вспомните или обнаружите что-то, что не упомянули в первоначальном отчёте, пожалуйста, отправьте уточнение. Основная причина, по которой ошибка не исправляется, — это отсутствие связи с автором отчёта. Проще всего воспользоваться опцией комментария на веб-странице Bugzilla конкретного PR, которую можно открыть с https://bugs.freebsd.org/bugzilla/query.cgi[страницы поиска PR Bugzilla]. Если проблема исчезла, но отчёт о ней остаётся открытым, просто добавьте комментарий с указанием, что отчёт можно закрыть, и, по возможности, объясните, как или когда проблема была устранена. Иногда возникает задержка в одну-две недели, когда отчёт о проблеме остаётся без внимания — никто не назначается на него и не оставляет комментариев. Такое может произойти при увеличении очереди отчётов о проблемах или во время праздничного сезона. Если отчёт о проблеме не получил внимания в течение нескольких недель, стоит найти коммиттера, особенно заинтересованного в работе над ним. Существует несколько способов сделать это, желательно в следующем порядке, с перерывом в несколько дней между попытками использования каждого канала связи: * Отправить письмо по электронной почте в extref:{handbook}eresources/[соответствующий список, eresources-summary] для получения комментариев к отчёту. * Присоединитесь к соответствующим IRC-каналам. Частичный список доступен здесь: https://wiki.freebsd.org/IRC/Channels[]. Сообщите участникам канала о проблеме и запросите помощь. Будьте терпеливы и оставайтесь в канале после отправки сообщения, чтобы у людей из разных часовых поясов была возможность отреагировать. * Найдите коммиттеров, заинтересованных в сообщенной проблеме. Если проблема касается конкретного инструмента, бинарного файла, порта, документа или исходного файла, проверьте https://cgit.FreeBSD.org[Git Repository]. Определите последних коммиттеров, внесших существенные изменения в файл, и попытайтесь связаться с ними через IRC или электронную почту. Список коммиттеров и их адреса электронной почты можно найти в статье extref:{contributors}[Участники проекта FreeBSD]. Помните, что эти люди — добровольцы, как и сопровождающие и пользователи, поэтому они могут быть не сразу доступны для помощи с отчётом о проблеме. Терпение и последовательность в дальнейших действиях крайне рекомендуются и ценятся. При достаточном внимании и усилиях, посвящённых этому процессу, найти коммиттера, который займётся отчётом о проблеме — лишь вопрос времени. [[pr-problems]] == Если возникли проблемы Если вы обнаружили проблему в системе отслеживания ошибок, сообщите об ошибке! Для этого существует специальная категория. Если у вас не получается это сделать, свяжитесь с ответственными за обработку ошибок по адресу mailto:bugmeister@FreeBSD.org[bugmeister@FreeBSD.org]. [[pr-further]] == Для дальнейшего ознакомления Это список информационных ресурсов, относящихся к правильному написанию и обработке сообщений о проблемах. Он, без сомнения, не полон. * https://github.com/smileytechguy/reporting-bugs-effectively/blob/master/ENGLISH.md[How to Report Bugs Effectively]-прекрасное эссе, которое написал Simon G. Tatham о составлении полезных (не специфичных для FreeBSD) сообщений о проблемах. -* extref:{pr-guidelines}[Problem Report Handling Guidelines]-интересный взгляд на обработку сообщений о проблемах самими разработчиками FreeBSD. +* extref:{pr-guidelines}[Руководство по обработке отчётов о проблемах] — интересный взгляд на обработку сообщений о проблемах самими разработчиками FreeBSD. diff --git a/documentation/content/ru/articles/problem-reports/_index.po b/documentation/content/ru/articles/problem-reports/_index.po index a275b35bec..790a57fedf 100644 --- a/documentation/content/ru/articles/problem-reports/_index.po +++ b/documentation/content/ru/articles/problem-reports/_index.po @@ -1,1429 +1,1506 @@ # SOME DESCRIPTIVE TITLE # Copyright (C) YEAR The FreeBSD Project # This file is distributed under the same license as the FreeBSD Documentation package. -# Vladlen Popolitov , 2025. +# Vladlen Popolitov , 2025, 2026. msgid "" msgstr "" "Project-Id-Version: FreeBSD Documentation VERSION\n" -"POT-Creation-Date: 2023-09-09 18:13-0300\n" -"PO-Revision-Date: 2025-11-20 04:45+0000\n" +"POT-Creation-Date: 2026-02-22 15:58+0000\n" +"PO-Revision-Date: 2026-03-08 09:11+0000\n" "Last-Translator: Vladlen Popolitov \n" "Language-Team: Russian \n" "Language: ru\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=3; plural=n%10==1 && n%100!=11 ? 0 : n%10>=2 && " "n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;\n" "X-Generator: Weblate 4.17\n" #. type: YAML Front Matter: description #: documentation/content/en/articles/problem-reports/_index.adoc:1 #, no-wrap msgid "How to best formulate and submit a problem report to the FreeBSD Project" msgstr "Как лучше сформулировать и отправить отчёт о проблеме в проект FreeBSD" #. type: Title = #: documentation/content/en/articles/problem-reports/_index.adoc:1 #: documentation/content/en/articles/problem-reports/_index.adoc:11 #, no-wrap msgid "Writing FreeBSD Problem Reports" msgstr "Составление сообщений о проблеме во FreeBSD" #. type: Plain text #: documentation/content/en/articles/problem-reports/_index.adoc:44 msgid "Abstract" msgstr "Аннотация" #. type: Plain text #: documentation/content/en/articles/problem-reports/_index.adoc:46 msgid "" "This article describes how to best formulate and submit a problem report to " "the FreeBSD Project." msgstr "" "Эта статья описывает, как наилучшим образом сформулировать и отправить " "сообщение о проблеме в Проект FreeBSD." #. type: Plain text #: documentation/content/en/articles/problem-reports/_index.adoc:48 msgid "'''" msgstr "'''" #. type: Title == #: documentation/content/en/articles/problem-reports/_index.adoc:52 #, no-wrap +msgid "Scope of this article" +msgstr "Область применения данной статьи" + +#. type: Plain text +#: documentation/content/en/articles/problem-reports/_index.adoc:55 +msgid "" +"This article was originally written to cover Problem Report submissions via " +"Bugzilla, but parts will also apply to submitting via Phabricator review " +"system or the FreeBSD Github organization." +msgstr "" +"Изначально эта статья была написана для описания отправки отчётов о " +"проблемах через Bugzilla, но некоторые её разделы также применимы при " +"отправке через систему рецензирования Phabricator или через организацию " +"FreeBSD на Github." + +#. type: Title == +#: documentation/content/en/articles/problem-reports/_index.adoc:57 +#, no-wrap msgid "Introduction" msgstr "Введение" #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:56 +#: documentation/content/en/articles/problem-reports/_index.adoc:61 msgid "" "One of the most frustrating experiences one can have as a software user is " "to submit a problem report only to have it summarily closed with a terse and " -"unhelpful explanation like \"not a bug\" or \"bogus PR\". Similarly, one of " -"the most frustrating experiences as a software developer is to be flooded " -"with problem reports that are not really problem reports but requests for " -"support, or that contain little or no information about what the problem is " -"and how to reproduce it." +"unhelpful explanation like \"not a bug\" or \"bogus report\". Similarly, " +"one of the most frustrating experiences as a software developer is to be " +"flooded with problem reports that are not really problem reports but " +"requests for support, or that contain little or no information about what " +"the problem is and how to reproduce it." msgstr "" "Одной из самых разочаровывающих практик, которую можно получить в качестве " "пользователя программного обеспечения, является отправка сообщения о " "проблеме, которое вскоре закрывается с кратким и ничему не помогающим " -"объяснением типа \"это не проблема\" или \"неправильное PR\". Подобным же " +"объяснением типа \"это не проблема\" или \"неправильный отчет\". Подобным же " "образом одной из самых разочаровывающих практик, которую можно получить в " "качестве разработчика программного обеспечения, является получение массы " "сообщений о проблемах, которые на самом деле не являются сообщениями о " "проблемах, а запросами на получение поддержки, или которые содержат мало или " -"вообще не содержат никакой информации о сути проблемы или способе ее " +"вообще не содержат никакой информации о сути проблемы или способе её " "воспроизведения." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:59 +#: documentation/content/en/articles/problem-reports/_index.adoc:64 msgid "" "This document attempts to describe how to write good problem reports. What, " "one asks, is a good problem report? Well, to go straight to the bottom line, " "a good problem report is one that can be analyzed and dealt with swiftly, to " "the mutual satisfaction of both user and developer." msgstr "" "В этом документе делается попытка описать то, как составлять хорошие " "сообщения о проблемах. Что же, спросите вы, является хорошим сообщением о " "проблеме? Ну, если перейти прямо к сути, то хорошим сообщением об проблеме " "является то, которое может быть быстро проанализировано и отработано, к " "обоюдному удовлетворению как пользователя, так и разработчика." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:61 +#: documentation/content/en/articles/problem-reports/_index.adoc:66 msgid "" -"Although the primary focus of this article is on FreeBSD problem reports, " -"most of it should apply quite well to other software projects." +"Although the primary focus of this article is on submitting FreeBSD problem " +"reports via Bugzilla, most of it should apply quite well in other cases." msgstr "" -"Хотя в основном статья фокусируется на сообщениях о проблемах во FreeBSD, " -"большей частью она должна хорошо подходить и другим программным проектам." +"Хотя в основном статья фокусируется на отправке сообщений о проблемах во " +"FreeBSD с помощью Bagzilla, большей частью она должна хорошо подходить и " +"другим случаям." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:64 +#: documentation/content/en/articles/problem-reports/_index.adoc:69 msgid "" "Note that this article is organized thematically, not chronologically. Read " "the entire document before submitting a problem report, rather than treating " "it as a step-by-step tutorial." msgstr "" "Заметьте, что эта статья организована по тематическому принципу, а не " "хронологически, так что вы должны прочесть документ целиком прежде, чем " "посылать сообщение о проблеме, и не воспринимать статью как пошаговое " "руководство." #. type: Title == -#: documentation/content/en/articles/problem-reports/_index.adoc:66 +#: documentation/content/en/articles/problem-reports/_index.adoc:71 #, no-wrap msgid "When to Submit a Problem Report" msgstr "Когда нужно отправлять сообщение о проблеме" #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:72 +#: documentation/content/en/articles/problem-reports/_index.adoc:77 msgid "" "There are many types of problems, and not all of them should engender a " "problem report. Of course, nobody is perfect, and there will be times when " "what seems to be a bug in a program is, in fact, a misunderstanding of the " "syntax for a command or a typographical error in a configuration file " "(though that in itself may sometimes be indicative of poor documentation or " "poor error handling in the application). There are still many cases where " "submitting a problem report is clearly _not_ the right course of action, and " "will only serve to frustrate both the submitter and the developers. " "Conversely, there are cases where it might be appropriate to submit a " "problem report about something else than a bug—an enhancement or a new " "feature, for instance." msgstr "" "Имеется много классов ошибок, и не все они должны приводить к появлению " "сообщения о проблеме. Конечно же, нет идеальных людей, и будут моменты, " "когда вы решите, что нашли ошибку в программе, а на самом деле вы " "неправильно поняли синтаксис команды или сделали опечатку в конфигурационном " "файле (хотя само по себе это иногда говорит о плохой документации или " -"неправильной обработке ошибок в прикладной программе). Есть еще много " +"неправильной обработке ошибок в прикладной программе). Есть ещё много " "случаев, когда посылка сообщения о проблеме явно _не_ является правильным " "действием, а только приводит к разочарованию вас и разработчиков. И " "наоборот, есть случаи, когда может быть нужно послать сообщение о чем-то, не " "являющемся ошибкой - к примеру, запрос на доработку или расширение " "функциональности." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:76 +#: documentation/content/en/articles/problem-reports/_index.adoc:81 msgid "" "So how does one determine what is a bug and what is not? As a simple rule of " "thumb, the problem is _not_ a bug if it can be expressed as a question " "(usually of the form \"How do I do X?\" or \"Where can I find Y?\"). It is " "not always quite so black and white, but the question rule covers a large " -"majority of cases. When looking for an answer, consider posing the question " -"to the {freebsd-questions}." +"majority of cases. When looking for an answer, consider first consulting " +"the https://forums.freebsd.org[FreeBSD Forums], IRC, or the {freebsd-" +"questions}." msgstr "" "Но как же определить, что является ошибкой, а что нет? Простым правилом, " "которому нужно следовать, является следующее - ваша проблема _не_ является " "ошибкой, если она формулируется как вопрос (обычно в форме \"Как сделать X?\"" " или \"Где можно найти Y?\"). Не всегда это так однозначно, но правило " "вопроса покрывает большинство случаев. Если Вам нужен ответ, лучше всего " -"задать свой вопрос в {freebsd-questions}." +"сначала проконсультироваться https://forums.freebsd.org[на форумах FreeBSD], " +"в IRC или в {freebsd-questions}." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:78 +#: documentation/content/en/articles/problem-reports/_index.adoc:83 msgid "" -"Consider these factors when submitting PRs about ports or other software " +"Consider these factors when submitting reports about ports or other software " "that is not part of FreeBSD itself:" msgstr "" "Вот некоторые случаи, в которых может оказаться полезным отправить сообщение " "о чем-то, что не является ошибкой:" #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:80 +#: documentation/content/en/articles/problem-reports/_index.adoc:85 msgid "" "Please do not submit problem reports that simply state that a newer version " "of an application is available. Ports maintainers are automatically notified " "by portscout when a new version of an application becomes available. Actual " "patches to update a port to the latest version are welcome." msgstr "" "Уведомление об обновлении программного обеспечения, которое поддерживается " "сторонними разработчиками (в основном порты, но также и компоненты базовой " "системы, разрабатываемые сторонними организациями, такие, как BIND или " "различные утилиты GNU)." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:81 +#: documentation/content/en/articles/problem-reports/_index.adoc:86 msgid "" -"For unmaintained ports (`MAINTAINER` is `ports@FreeBSD.org`), a PR without " -"an included patch is unlikely to get picked up by a committer. To become the " -"maintainer of an unmaintained port, submit a PR with the request (patch " -"preferred but not required)." +"For unmaintained ports (`MAINTAINER` is `ports@FreeBSD.org`), a report " +"without an included patch is unlikely to get picked up by a committer. To " +"become the maintainer of an unmaintained port, submit a report with the " +"request (patch preferred but not required)." msgstr "" "Для не поддерживаемых никем портов (переменная `MAINTAINER` содержит " -"`ports@FreeBSD.org`), такие уведомления о обновлении будут замечены " -"заинтересовавшимся коммиттером и вас могут попросить предоставить патч для " -"обновления порта; предоставление патча до того, как вас попросят об этом " -"сильно увеличит шансы того, что порт будет обновлён вовремя." +"`ports@FreeBSD.org`) отчёт о проблеме без приложенного файла с исправлениями " +"едва ли будет замечен коммиттером. Чтобы стать сопровождающим порта, у " +"которого не было сопровождающего, отправьте отчёт с запросом (файл с " +"исправлением желателен, но не обязателен)." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:82 +#: documentation/content/en/articles/problem-reports/_index.adoc:87 msgid "" "In either case, following the process described in extref:{porters-handbook}" "upgrading/[Porter's Handbook] will yield the best results. (You might also " "wish to read extref:{contributing}[Contributing to the FreeBSD Ports " "Collection, ports-contributing].)" msgstr "" -"В любом случае, следование процессу, описанному в extref:{porters-" -"handbook}upgrading[Руководстве по созданию портов] даст наилучшие " -"результаты. (Также можно ознакомиться с статьей extref:{contributing}[Вклад " -"в коллекцию портов FreeBSD, ports-contributing].)" +"В любом случае, следование процессу, описанному в extref:{porters-handbook}" +"upgrading[Руководстве по созданию портов] даст наилучшие результаты. (Также " +"можно ознакомиться с статьей extref:{contributing}[Вклад в коллекцию портов " +"FreeBSD, ports-contributing].)" #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:87 +#: documentation/content/en/articles/problem-reports/_index.adoc:92 msgid "" "A bug that cannot be reproduced can rarely be fixed. If the bug only " "occurred once and you cannot reproduce it, and it does not seem to happen to " "anybody else, chances are none of the developers will be able to reproduce " "it or figure out what is wrong. That does not mean it did not happen, but " "it does mean that the chances of your problem report ever leading to a bug " "fix are very slim. To make matters worse, often these kinds of bugs are " "actually caused by failing hard drives or overheating processors—you should " "always try to rule out these causes, whenever possible, before submitting a " -"PR." +"report." msgstr "" "Ошибка, которую нельзя воспроизвести, вряд ли будет исправлена. Если ошибка " -"возникла только единожды, и вы не можете ее воспроизвести, к тому же никто с " -"ней больше не сталкивался, нет никаких шансов, что разработчики смогут ее " +"возникла только единожды, и вы не можете её воспроизвести, к тому же никто с " +"ней больше не сталкивался, нет никаких шансов, что разработчики смогут её " "воспроизвести или понять, что делается неправильно. Это не значит, что " "такого не случается, но это значит, что шансов у вашего сообщения дойти " "когда-либо до стадии исправления ошибки очень малы. Часто эти виды ошибок " "возникают из-за неудовлетворительной работы жёстких дисков, перегревшихся " "процессоров. Всегда, когда это возможно вы должны отслеживать такие случаи " "перед посылкой сообщения об ошибке." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:89 +#: documentation/content/en/articles/problem-reports/_index.adoc:94 msgid "" "Next, to decide to whom you should file your problem report, you need to " "understand that the software that makes up FreeBSD is composed of several " "different elements:" msgstr "" "Теперь, чтобы определить кому вы должны отправить ваше сообщение об ошибке, " "вы должны понимать, что программное обеспечение, которое входит во FreeBSD, " "составляется из нескольких различных частей:" #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:91 +#: documentation/content/en/articles/problem-reports/_index.adoc:96 msgid "" "Code in the base system that is written and maintained by FreeBSD " "contributors, such as the kernel, the C library, and the device drivers " "(categorized as `kern`); the binary utilities (`bin`); the manual pages and " "documentation (`docs`); and the web pages (`www`). All bugs in these areas " "should be reported to the FreeBSD developers." msgstr "" "Код в базовой системе, который пишется и поддерживается контрибьюторами " "FreeBSD. Такой, как ядро, библиотека C, драйвера устройств (входят в " "категорию `kern`); утилиты (`bin`); страницы справочника и документация " "(`docs`); веб-страницы (`www`). Все ошибки в этих областях должны быть " "сообщены разработчикам FreeBSD." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:92 +#: documentation/content/en/articles/problem-reports/_index.adoc:97 msgid "" "Code in the base system that is written and maintained by others, and " "imported into FreeBSD and adapted. Examples include man:clang[1], and man:" "sendmail[8]. Most bugs in these areas should be reported to the FreeBSD " "developers; but in some cases they may need to be reported to the original " "authors instead if the problems are not FreeBSD-specific." msgstr "" "Код в базовой системе, который пишется и поддерживается другим, " -"импортируется во FreeBSD и адаптируется. Примеры включают в себя: bind, " -"man:gcc[1] и man:sendmail[8]. Большинство ошибок, попадающие в данные " -"области должны быть сообщены разработчикам FreeBSD, но в некоторых случаях " -"они должны быть отправлены изначальным разработчикам, если проблемы не " -"являются специфичными для FreeBSD. Обычно ошибки такого рода попадают под " -"категории `bin` или `gnu`." +"импортируется во FreeBSD и адаптируется. Примеры включают в себя: bind, man:" +"gcc[1] и man:sendmail[8]. Большинство ошибок, попадающие в данные области " +"должны быть сообщены разработчикам FreeBSD, но в некоторых случаях они " +"должны быть отправлены изначальным разработчикам, если проблемы не являются " +"специфичными для FreeBSD. Обычно ошибки такого рода попадают под категории " +"`bin` или `gnu`." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:93 +#: documentation/content/en/articles/problem-reports/_index.adoc:98 msgid "" "Individual applications that are not in the base system but are instead part " "of the FreeBSD Ports Collection (category `ports`). Most of these " "applications are not written by FreeBSD developers; what FreeBSD provides is " "merely a framework for installing the application. Therefore, only report a " "problem to the FreeBSD developers when the problem is believed to be FreeBSD-" "specific; otherwise, report it to the authors of the software." msgstr "" "Отдельные приложения, не входящие в базовую систему, но являющиеся частью " "Коллекции Портов FreeBSD (категория `ports`). Большинство этих приложений не " "пишется разработчиками FreeBSD; что предоставляет FreeBSD, так это только " "лишь инфраструктуру для установки приложения. Следовательно, вы должны " "отправлять сообщение об ошибке разработчикам FreeBSD только тогда, когда вы " "уверены в том, что проблема специфична для FreeBSD - иначе отправляйте её " "авторам программного обеспечения." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:96 +#: documentation/content/en/articles/problem-reports/_index.adoc:101 msgid "" "Then, ascertain whether the problem is timely. There are few things that " "will annoy a developer more than receiving a problem report about a bug she " "has already fixed." msgstr "" "Затем вы должны убедиться, действительно ли проблема существует. Существует " "всего несколько вещей, которые раздражают разработчика больше, чем получение " "сообщения об ошибке, которую он уже исправил." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:100 +#: documentation/content/en/articles/problem-reports/_index.adoc:105 msgid "" -"If the problem is in the base system, first read the FAQ section on extref:" -"{faq}[FreeBSD versions, latest-version], if you are not already familiar " +"If the problem is in the base system, first read the extref:{handbook}/" +"cutting-edge/[Handbook section on Versions], if you are not already familiar " "with the topic. It is not possible for FreeBSD to fix problems in anything " "other than certain recent branches of the base system, so filing a bug " "report about an older version will probably only result in a developer " "advising you to upgrade to a supported version to see if the problem still " "recurs. The Security Officer team maintains the link:https://www.FreeBSD." -"org/security/[list of supported versions]." +"org/security/#sup[list of supported versions]." msgstr "" "Если проблема в базовой системе, то вам нужно сначала прочесть раздел " -"extref:{faq}[версии FreeBSD, latest-version] из FAQ, если вы ещё не знакомы " -"с данной темой. Для FreeBSD возможно исправлять проблемы только для " +"extref:{handbook}cutting-edge[Руководства FreeBSD о версиях], если вы ещё не " +"знакомы с данной темой. Для FreeBSD возможно исправлять проблемы только для " "некоторых недавних веток базовой системы, поэтому отправка сообщения об " "ошибке для более старой версии приведёт к тому, что разработчик посоветует " "вам обновиться до поддерживаемой версии, чтобы посмотреть присутствует ли в " "ней проблема. Команда офицеров безопасности поддерживает link:https://www." -"FreeBSD.org/security/[список поддерживаемых версий.]." +"FreeBSD.org/ru/security/#sup[список поддерживаемых версий.]." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:103 +#: documentation/content/en/articles/problem-reports/_index.adoc:108 msgid "" "If the problem is in a port, consider filing a bug with the upstream. The " "FreeBSD Project can not fix all bugs in all software." msgstr "" "Если проблема в порте, рассмотрите возможность сообщить об ошибке " "разработчикам исходного проекта. Проект FreeBSD не может исправлять все " "ошибки во всём программном обеспечении." #. type: Title == -#: documentation/content/en/articles/problem-reports/_index.adoc:105 +#: documentation/content/en/articles/problem-reports/_index.adoc:110 #, no-wrap msgid "Preparations" msgstr "Подготовка" #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:111 +#: documentation/content/en/articles/problem-reports/_index.adoc:116 msgid "" "A good rule to follow is to always do a background search before submitting " "a problem report. Maybe the problem has already been reported; maybe it is " "being discussed on the mailing lists, or recently was; it may even already " "be fixed in a newer version than what you are running. You should therefore " "check all the obvious places before submitting your problem report. For " "FreeBSD, this means:" msgstr "" "Нужно следовать хорошему правилу всегда сначала выполнять дополнительные " "исследования перед тем, как послать сообщение о проблеме. Может быть, о " "вашей проблеме уже сообщено; может быть, она недавно обсуждалась или " "обсуждается в списках рассылки; она может быть уже исправлена в более новой " "версии, чем та, что вы используете. Поэтому вы должны проверить все обычные " "места до того, как послать ваше сообщение о проблеме. Для FreeBSD это значит:" #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:113 +#: documentation/content/en/articles/problem-reports/_index.adoc:118 +msgid "" +"First, always check to see if the problem is covered in extref:{handbook}" +"[Handbook]." +msgstr "" +"Во-первых, всегда проверяйте, не описан ли этот вопрос в " +"extref:{handbook}[Руководстве]." + +#. type: Plain text +#: documentation/content/en/articles/problem-reports/_index.adoc:119 msgid "" "The FreeBSD extref:{faq}[Frequently Asked Questions] (FAQ) list. The FAQ " -"attempts to provide answers for a wide range of questions, such as those " -"concerning extref:{faq}[hardware compatibility, hardware], extref:{faq}[user " -"applications, applications], and extref:{faq}[kernel configuration, " -"kernelconfig]." +"attempts to provide answers for several questions, such as those concerning " +"extref:{faq}[hardware compatibility, hardware]." msgstr "" "Список extref:{faq}[Часто задаваемых вопросов] (FAQ) по FreeBSD. FAQ " -"содержит ответы на широкий круг вопросов, таких как вопросы, касающиеся " -"extref:{faq}[совместимости оборудования, hardware], extref:{faq}[" -"пользовательских приложений, applications] и extref:{faq}[конфигурации ядра, " -"kernelconfig]." +"содержит ответы на несколько вопросов, таких как вопросы, касающиеся " +"extref:{faq}[совместимости оборудования, hardware]." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:114 +#: documentation/content/en/articles/problem-reports/_index.adoc:120 msgid "" "The extref:{handbook}eresources/[mailing lists, eresources-mail]. If you are " "not subscribed, use https://www.FreeBSD.org/search/#mailinglists[the " "searchable archives] on the FreeBSD web site. If the problem has not been " "discussed on the lists, you might try posting a message about it and waiting " "a few days to see if someone can spot something that has been overlooked." msgstr "" "extref:{handbook}eresources/[Списки рассылки, eresources-mail] — если Вы не " "подписаны на них, воспользуйтесь https://www.FreeBSD.org/search/" "#mailinglists[поиском в архивах] на сайте FreeBSD. Если ваша проблема не " "обсуждалась в списках рассылки, вы можете попытаться опубликовать сообщение " -"о ней и подождать несколько дней, пока кто-нибудь не сможет увидеть то, что " -"вы не заметили." +"о ней и подождать несколько дней — возможно, кто-то заметит то, что было " +"упущено." + +#. type: Plain text +#: documentation/content/en/articles/problem-reports/_index.adoc:121 +msgid "As noted above, the FreeBSD Forums and IRC." +msgstr "Как отмечалось выше, форумы FreeBSD и IRC." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:115 +#: documentation/content/en/articles/problem-reports/_index.adoc:122 msgid "" "Optionally, the entire web-use your favorite search engine to locate any " "references to the problem. You may even get hits from archived mailing lists " "or newsgroups you did not know of or had not thought to search through." msgstr "" "Как вариант, весь веб-используйте вашу любимую поисковую систему для поиска " "каких-либо ссылок по вашей проблеме. Вы можете даже увидеть ссылки на архивы " "списков рассылки или телеконференций, о которых вы не знали или не думали " "там искать." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:116 +#: documentation/content/en/articles/problem-reports/_index.adoc:123 msgid "" -"Next, the searchable https://bugs.freebsd.org/bugzilla/query.cgi[FreeBSD PR " -"database] (Bugzilla). Unless the problem is recent or obscure, there is a " -"fair chance it has already been reported." +"Next, the searchable https://bugs.freebsd.org/bugzilla/query.cgi[FreeBSD " +"Bugzilla database]. Unless the problem is recent or obscure, there is a fair " +"chance it has already been reported." msgstr "" "Следующим пунктом должна быть https://bugs.freebsd.org/bugzilla/query.cgi[ " -"база данных PR FreeBSD] (Bugzilla). Если только ваша проблема не нова или " -"редка, есть некоторый шанс, что о ней уже сообщено." +"база данных FreeBSD Bugzilla]. Если только ваша проблема не нова или редка, " +"есть некоторый шанс, что о ней уже сообщено." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:117 +#: documentation/content/en/articles/problem-reports/_index.adoc:124 msgid "" "Most importantly, attempt to see if existing documentation in the source " "base addresses your problem." msgstr "" "И самое важное, вы должны посмотреть не затрагивает ли документация в " "базовой системе вашу проблему." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:120 +#: documentation/content/en/articles/problem-reports/_index.adoc:127 msgid "" "For the base FreeBSD code, you should carefully study the contents of [." "filename]#/usr/src/UPDATING# on your system or the latest version at https://" "cgit.freebsd.org/src/tree/UPDATING[https://cgit.freebsd.org/src/tree/" "UPDATING]. (This is vital information if you are upgrading from one version " "to another, especially if you are upgrading to the FreeBSD-CURRENT branch)." msgstr "" "Для основного кода FreeBSD вы должны тщательно изучить содержимое файла [." "filename]#/usr/src/UPDATING# или его текущую версию по адресу https://cgit." -"freebsd.org/src/tree/UPDATING[https://cgit.freebsd.org/src/tree/UPDATING]. (" -"Если вы переходите с одной версии на другую, особенно если вы обновляетесь " +"freebsd.org/src/tree/UPDATING[https://cgit.freebsd.org/src/tree/UPDATING]. " +"(Если вы переходите с одной версии на другую, особенно если вы обновляетесь " "до FreeBSD-CURRENT, то в этом файле вы можете найти много важной информации)." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:123 +#: documentation/content/en/articles/problem-reports/_index.adoc:130 msgid "" "However, if the problem is in something that was installed as a part of the " "FreeBSD Ports Collection, you should refer to [.filename]#/usr/ports/" "UPDATING# (for individual ports) or [.filename]#/usr/ports/CHANGES# (for " "changes that affect the entire Ports Collection). https://cgit.freebsd.org/" "ports/tree/UPDATING[https://cgit.freebsd.org/ports/tree/UPDATING] and " "https://cgit.freebsd.org/ports/tree/CHANGES[https://cgit.freebsd.org/ports/" "tree/CHANGES] are also available via cgit." msgstr "" "Если же ваша проблема связана с коллекцией портов FreeBSD, вы должны " "обратиться к файлу [.filename]#/usr/ports/UPDATING# (изменения, касающиеся " "индивидуальных портов) или к [.filename]#/usr/ports/CHANGES# (изменения, " "касающиеся всей коллекции портов). Они также доступны через интерфейс cgit: " "https://cgit.freebsd.org/ports/tree/UPDATING[https://cgit.freebsd.org/ports/" "tree/UPDATING] и https://cgit.freebsd.org/ports/tree/CHANGES[https://cgit." "freebsd.org/ports/tree/CHANGES] ." #. type: Title == -#: documentation/content/en/articles/problem-reports/_index.adoc:125 +#: documentation/content/en/articles/problem-reports/_index.adoc:132 #, no-wrap msgid "Writing the Problem Report" msgstr "Написание сообщения о проблеме" #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:129 +#: documentation/content/en/articles/problem-reports/_index.adoc:136 msgid "" "Now that you have decided that your issue merits a problem report, and that " "it is a FreeBSD problem, it is time to write the actual problem report. " "Before we get into the mechanics of the program used to generate and submit " -"PRs, here are some tips and tricks to help make sure that your PR will be " -"most effective." +"Bugzilla PRs, here are some tips and tricks to help make sure that your " +"report will be most effective." msgstr "" "Теперь, после того, как вы решили, что ваш вопрос подпадает под категорию " "сообщения о проблеме, и это проблема FreeBSD, самое время написать " "собственно сообщение о проблеме (PR). Прежде чем мы углубимся в частности " -"использования программы для создания и отправки PR, вот несколько советов, " -"которые помогут вам сделать PR более эффективным." +"использования программы для создания и отправки PR в Bugzilla, вот несколько " +"советов, которые помогут вам сделать сообщение более эффективным." #. type: Title == -#: documentation/content/en/articles/problem-reports/_index.adoc:131 +#: documentation/content/en/articles/problem-reports/_index.adoc:138 #, no-wrap -msgid "Tips and Tricks for Writing a Good Problem Report" -msgstr "Как писать хорошие сообщения о проблемах" +msgid "Tips and Tricks for Writing a Good Problem Report With Bugzilla" +msgstr "Как писать хорошие сообщения о проблемах в Bugzilla" #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:134 +#: documentation/content/en/articles/problem-reports/_index.adoc:141 msgid "" -"_Do not leave the \"Summary\" line empty._ The PRs go both onto a mailing " -"list that goes all over the world (where the \"Summary\" is used for the " -"`Subject:` line), but also into a database. Anyone who comes along later and " -"browses the database by synopsis, and finds a PR with a blank subject line, " -"tends just to skip over it. Remember that PRs stay in this database until " -"they are closed by someone; an anonymous one will usually just disappear in " -"the noise." +"_Do not leave the \"Summary\" line empty._ The reports go both onto a " +"mailing list that goes all over the world (where the \"Summary\" is used for " +"the `Subject:` line), but also into a database. Anyone who comes along later " +"and browses the database by synopsis, and finds a PR with a blank subject " +"line, tends just to skip over it. Remember that PRs stay in this database " +"until they are closed by someone; an anonymous one will usually just " +"disappear in the noise." msgstr "" "_Не оставляйте поле \"Summary\" (краткое описание) пустым._ Сообщения о " "проблемах попадают как в списки рассылки, которые затем расходятся по всему " "миру (в них поле \"Summary\" определяет тему письма), так и в базу данных. " "Просматривающий эту базу, как правило, пройдет мимо PR с пустым кратким " -"описанием. Не забудьте, что PR остается в базе до тех пор, пока кто-либо не " +"описанием. Не забудьте, что PR остаётся в базе до тех пор, пока кто-либо не " "закроет его; сообщение-аноним, скорее всего, просто потеряется на общем фоне." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:135 +#: documentation/content/en/articles/problem-reports/_index.adoc:142 msgid "" "_Avoid using a weak \"Summary\" line._ You should not assume that anyone " "reading your PR has any context for your submission, so the more you " "provide, the better. For instance, what part of the system does the problem " "apply to? Do you only see the problem while installing, or while running? To " "illustrate, instead of `Summary: portupgrade is broken`, see how much more " "informative this seems: `Summary: port ports-mgmt/portupgrade coredumps on -" "current`. (In the case of ports, it is especially helpful to have both the " "category and portname in the \"Summary\" line.)" msgstr "" "__Избегайте туманных описаний в поле \"Summary\"__. Не стоит предполагать, " "что читающий ваше сообщение владеет контекстом; поэтому, чем подробнее вы " "опишете ситуацию, тем лучше. В частности, к какой части системы относится " "ваша проблема? Проявляется ли она на этапе установки или во время нормальной " "работы? Например, вместо строки `Summary: portupgrade is broken` следовало " -"бы написать что-то вроде `Summary: port ports-mgmt/portupgrade coredumps on " -"-current`. В случае портированных приложений в поле \"Summary\" полезно " +"бы написать что-то вроде `Summary: port ports-mgmt/portupgrade coredumps on -" +"current`. В случае портированных приложений в поле \"Summary\" полезно " "указывать не только имя порта, но и категорию." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:137 +#: documentation/content/en/articles/problem-reports/_index.adoc:144 msgid "" "_If you have a patch, say so._ The presence of a patch makes it much easier " "to progress a report." msgstr "" "_Если у вас есть патч, сообщите об этом._ Наличие патча значительно упрощает " "обработку отчёта." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:138 -msgid "Do not use the `patch` or `patch-ready` keywords – they are deprecated." -msgstr "Не используйте ключевые слова `patch` или `patch-ready` — они устарели." +#: documentation/content/en/articles/problem-reports/_index.adoc:145 +msgid "" +"Do not use the `patch` or `patch-ready` keywords – they are deprecated. " +"Instead, include your patch as an Attachment, and click the `[patch]` " +"checkbox. If you do not see the checkbox, click `Show Advanced Fields` in " +"the upper left corner." +msgstr "" +"Не используйте ключевые слова `patch` или `patch-ready` — они устарели. " +"Вместо этого прикрепите патч как вложение и отметьте флажок `[patch]`. Если " +"флажок не отображается, нажмите `Show Advanced Fields` (Показать расширенные " +"поля) в левом верхнем углу." + +#. type: Plain text +#: documentation/content/en/articles/problem-reports/_index.adoc:146 +msgid "Patches with MIME type `text/plain` are preferred." +msgstr "Предпочтительны файлы с исправлениями с MIME-типом `text/plain`." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:139 +#: documentation/content/en/articles/problem-reports/_index.adoc:147 +msgid "Patches compatible with `git` are preferred." +msgstr "Предпочтительны патчи, совместимые с `git`." + +#. type: Plain text +#: documentation/content/en/articles/problem-reports/_index.adoc:148 msgid "" -"_If you are a maintainer, say so._ If you are maintaining a part of the " -"source code (for instance, an existing port), you definitely should set the " -"\"Class\" of your PR to `maintainer-update`. This way any committer that " +"_If you are a ports maintainer, say so._ If you are maintaining a part of " +"the source code (for instance, an existing port), you definitely should set " +"the `maintainer-feedback?` of your PR to `+`. This way any committer that " "handles your PR will not have to check." msgstr "" -"_Если вы сопровождаете код, укажите это._ Если вы сопровождаете часть " -"исходного кода (например, существующий порт), обязательно установите «Class» " -"вашего PR в значение `maintainer-update`. Таким образом, любой коммиттер, " -"обрабатывающий ваш PR, не будет вынужден проверять это." +"_Если вы сопровождаете порт, укажите это._ Если вы сопровождаете часть " +"исходного кода (например, существующий порт), обязательно установите поле " +"`maintainer-feedback` в вашем сообщении о проблеме в `+`. Таким образом, " +"любой коммиттер, обрабатывающий ваш PR, не будет вынужден проверять это." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:140 +#: documentation/content/en/articles/problem-reports/_index.adoc:149 msgid "" "_Be specific._ The more information you supply about what problem you are " "having, the better your chance of getting a response." msgstr "" "_Будьте точны в формулировках._ Чем больше информации вы можете предоставить " "о проблеме, тем больше у вас шансов получить ответ." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:142 +#: documentation/content/en/articles/problem-reports/_index.adoc:151 msgid "" "Include the version of FreeBSD you are running (there is a place to put " "that, see below) and on which architecture. You should include whether you " "are running from a release (e.g., from a CD-ROM or download), or from a " "system maintained by Git (and, if so, what hash and branch you are at). If " "you are tracking the FreeBSD-CURRENT branch, that is the very first thing " "someone will ask, because fixes (especially for high-profile problems) tend " "to get committed very quickly, and FreeBSD-CURRENT users are expected to " "keep up." msgstr "" "Включите версию FreeBSD, которую вы используете (для этого есть специальное " "поле, см. ниже), и архитектуру. Укажите, используете ли вы релиз (например, " "с CD-ROM или загруженный) или систему, поддерживаемую через Git (и, если да, " "укажите хэш и ветку). Если вы используете ветку FreeBSD-CURRENT, укажите это " "в первую очередь, так как исправления (особенно для известных проблем) часто " "добавляются очень быстро, и пользователи FreeBSD-CURRENT должны следить за " "обновлениями." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:143 +#: documentation/content/en/articles/problem-reports/_index.adoc:152 msgid "" "Include which global options you have specified in your [.filename]#make." "conf#, [.filename]#src.conf#, and [.filename]#src-env.conf#. Given the " "infinite number of options, not every combination may be fully supported." msgstr "" "Включите информацию о том, какие глобальные опции вы указали в [." "filename]#make.conf#. На заметку: Объявление опций наподобие `-02` и других, " "описанных в man:gcc[1] во многих случаях может быть причиной ошибок. Хотя и " "разработчики FreeBSD будут принимать патчи, у них не будет желания " "исследовать такие случаи из-за отсутствия времени и добровольцев, и вместо " "этого они могут ответить, что это не поддерживается." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:144 +#: documentation/content/en/articles/problem-reports/_index.adoc:153 msgid "" "If the problem can be reproduced easily, include information that will help " "a developer to reproduce it themselves. If a problem can be demonstrated " "with specific input then include an example of that input if possible, and " "include both the actual and the expected output. If this data is large or " "cannot be made public, then do try to create a minimal file that exhibits " "the same issue and that can be included within the PR." msgstr "" "Если проблему можно легко повторить, включите необходимую информацию, чтобы " -"разработчик смог воспроизвести ее самостоятельно. Если проблема проявляется " +"разработчик смог воспроизвести её самостоятельно. Если проблема проявляется " "при некоторых вводимых данных, то, по возможности, приведите их вместе с " "получаемым и ожидаемым выводом. Если же вводимых данных много или же их " "нельзя разглашать, то попробуйте выделить из них лишь небольшой фрагмент, " "приводящий к возникновению проблемы, и включите его в PR." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:145 +#: documentation/content/en/articles/problem-reports/_index.adoc:154 msgid "" "If this is a kernel problem, then be prepared to supply the following " "information. (You do not have to include these by default, which only tends " "to fill up the database, but you should include excerpts that you think " "might be relevant):" msgstr "" "Если ваша проблема связана с ядром, будьте готовы предоставить следующую " "информацию (вам не обязательно включать её всю, она пойдёт лишь на " "заполнение базы данных, но вы должны включить информацию, которая по вашему " "мнению актуальна):" #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:147 +#: documentation/content/en/articles/problem-reports/_index.adoc:156 msgid "" "your kernel configuration (including which hardware devices you have " "installed)" msgstr "Вашу конфигурацию ядра, включая то, какие устройства у вас установлены" #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:148 +#: documentation/content/en/articles/problem-reports/_index.adoc:157 msgid "" "whether or not you have debugging options enabled (such as `WITNESS`), and " "if so, whether the problem persists when you change the sense of that option" msgstr "" "Включены ли у вас опции отладки (например, `WITNESS`), и если так, то " "существует ли проблема после изменения значения этой опции" #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:149 +#: documentation/content/en/articles/problem-reports/_index.adoc:158 msgid "" "the full text of any backtrace, panic or other console output, or entries in " "[.filename]#/var/log/messages#, if any were generated" msgstr "" "Полный вывод обратной трассировки (backtrace), паники или иного консольного " "вывода, или же записи из [.filename]#/var/log/messages#, если они были " "сгенерированы" #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:150 +#: documentation/content/en/articles/problem-reports/_index.adoc:159 msgid "" "the output of `pciconf -l` and relevant parts of your `dmesg` output if your " "problem relates to a specific piece of hardware" msgstr "" "Вывод команды `pciconf -l`, а также соответствующие части вывода `dmesg`, в " "случае, если проблема связана с конкретным оборудованием" #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:151 +#: documentation/content/en/articles/problem-reports/_index.adoc:160 msgid "" "the fact that you have read [.filename]#src/UPDATING# and that your problem " "is not listed there (someone is guaranteed to ask)" msgstr "" "Прочли ли вы [.filename]#src/UPDATING#, описана ли там ваша проблема (кто-" "нибудь спросит обязательно)" #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:152 +#: documentation/content/en/articles/problem-reports/_index.adoc:161 msgid "" "whether or not you can run any other kernel as a fallback (this is to rule " "out hardware-related issues such as failing disks and overheating CPUs, " "which can masquerade as kernel problems)" msgstr "" "Запускается ли другое ядро (это для тех случаев, когда причиной сбоя стало " "оборудование, например отказывающие винчестеры или перегревшиеся процессоры, " "что может маскировать проблемы ядра)" #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:154 +#: documentation/content/en/articles/problem-reports/_index.adoc:163 msgid "" "If this is a ports problem, then be prepared to supply the following " "information. (You do not have to include these by default, which only tends " "to fill up the database, but you should include excerpts that you think " "might be relevant):" msgstr "" "Если же ваша проблема связана с портами, то предоставьте следующую " "информацию (вам не обязательно включать её всю, она пойдет лишь на " "заполнение базы данных, но вы должны включить информацию, которая по вашему " "мнению актуальна):" #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:156 +#: documentation/content/en/articles/problem-reports/_index.adoc:165 msgid "which ports you have installed" msgstr "Какие порты вы устанавливали" #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:157 +#: documentation/content/en/articles/problem-reports/_index.adoc:166 msgid "" "any environment variables that override the defaults in [.filename]#bsd.port." "mk#, such as `PORTSDIR`" msgstr "" "Имеются ли какие-либо переменные окружения, которые переписывают " "первоначально-установленные в [.filename]#bsd.port.mk#, такие как, " "`PORTSDIR`)" #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:158 +#: documentation/content/en/articles/problem-reports/_index.adoc:167 msgid "" "the fact that you have read [.filename]#ports/UPDATING# and that your " "problem is not listed there (someone is guaranteed to ask)" msgstr "" "Прочли ли вы [.filename]#ports/UPDATING#, и описана ли там ваша проблема " "(кто-нибудь спросит обязательно)" #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:160 +#: documentation/content/en/articles/problem-reports/_index.adoc:169 msgid "" -"_Avoid vague requests for features._ PRs of the form \"someone should really " -"implement something that does so-and-so\" are less likely to get results " -"than very specific requests. Remember, the source is available to everyone, " -"so if you want a feature, the best way to ensure it being included is to get " -"to work! Also consider the fact that many things like this would make a " -"better topic for discussion on `freebsd-questions` than an entry in the PR " -"database, as discussed above." +"_Avoid vague requests for features._ Problem Reports of the form \"someone " +"should really implement something that does so-and-so\" are less likely to " +"get results than very specific requests. Remember, the source is available " +"to everyone, so if you want a feature, the best way to ensure it being " +"included is to get to work! Also consider the fact that many things like " +"this would make a better topic for discussion on `freebsd-questions` than an " +"entry in the PR database, as discussed above." msgstr "" "_Избегайте нечетких запросов о новых возможностях._ Сообщение типа \"кто-то " "обязательно должен сделать так, чтобы такая-то утилита вела себя так-то\" " "имеет куда меньше шансов встретить позитивный отклик, чем более четко " "сформулированный запрос. Помните, что исходные тексты доступны всем, так что " -"если вам нужна реализация какого-то нового свойства, лучший способ- взяться " +"если вам нужна реализация какого-то нового свойства, лучший способ — взяться " "за работу самому! Не забудьте также, что такие моменты лучше обсуждать в " "списках рассылки, таких как `freebsd-questions`, чем делать это посредством " "базы данных PR." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:161 +#: documentation/content/en/articles/problem-reports/_index.adoc:170 msgid "" "_Make sure no one else has already submitted a similar PR._ Although this " "has already been mentioned above, it bears repeating here. It only take a " -"minute or two to use the web-based search engine at https://bugs.freebsd.org/" -"bugzilla/query.cgi[https://bugs.freebsd.org/bugzilla/query.cgi]. (Of course, " -"everyone is guilty of forgetting to do this now and then.)" +"minute or two to use the Bugzilla web-based search engine at https://bugs." +"freebsd.org/bugzilla/query.cgi[https://bugs.freebsd.org/bugzilla/query.cgi]. " +"(Of course, everyone is guilty of forgetting to do this now and then.)" msgstr "" -"_Убедитесь, что ваша проблема еще никем не описана._ Мы уже говорили об " -"этом, но стоит повториться. Потратьте пару минут на составление запросов к " -"базе PR: https://bugs.freebsd.org/bugzilla/query.cgi[https://bugs.freebsd." +"_Убедитесь, что ваша проблема ещё никем не описана._ Мы уже говорили об " +"этом, но стоит повториться. Потратьте пару минут на составление запросов в " +"Bugzilla: https://bugs.freebsd.org/bugzilla/query.cgi[https://bugs.freebsd." "org/bugzilla/query.cgi]. (Несмотря на повторы, об этом постоянно забывают)" #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:162 +#: documentation/content/en/articles/problem-reports/_index.adoc:171 msgid "" "_Report only one issue per Problem Report._ Avoid including two or more " "problems within the same report unless they are related. When submitting " "patches, avoid adding multiple features or fixing multiple bugs in the same " "PR unless they are closely related-such PRs often take longer to resolve." msgstr "" "_Сообщайте об одной проблеме в одном PR._ Избегайте описания двух и более " "проблем в одном сообщении (исключением являются взаимосвязанные проблемы). " "Оформляя патчи, не пытайтесь в них добавлять множество функциональных " "возможностей или исправлять ими несколько ошибок в одном и том же сообщении " "о проблеме (опять же, за исключением взаимосвязанных проблем) - для таких PR-" "ов потребуется значительно больше времени на обработку." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:163 +#: documentation/content/en/articles/problem-reports/_index.adoc:172 msgid "" "_Avoid controversial requests._ If your PR addresses an area that has been " "controversial in the past, you should probably be prepared to not only offer " "patches, but also justification for why the patches are \"The Right Thing To " "Do\". As noted above, a careful search of the mailing lists using the " "archives at https://www.FreeBSD.org/search/#mailinglists[https://www.FreeBSD." "org/search/#mailinglists] is always good preparation." msgstr "" "_Избегайте полемики._ Если ваше сообщение касается области или способов " "реализации, которые ранее вызвали разногласия, вам стоит быть готовым " "предоставить не только патчи, но и внятные аргументы, почему следует " "поступать именно так (то есть, это \"Правильный Путь\"). Как отмечалось " "выше, аккуратный поиск по архиву списков рассылки https://www.FreeBSD.org/" "search/#mailinglists[https://www.FreeBSD.org/search/#mailinglists] никогда " "не помешает." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:164 +#: documentation/content/en/articles/problem-reports/_index.adoc:173 msgid "" "_Be polite._ Almost anyone who would potentially work on your PR is a " "volunteer. No one likes to be told that they have to do something when they " "are already doing it for some motivation other than monetary gain. This is a " "good thing to keep in mind at all times on Open Source projects." msgstr "" "_Будьте вежливы._ Почти каждый из тех, кто может заниматься вашим " "сообщением, является добровольцем. Никому не понравятся указания, как и что " -"делать, когда он и так занимается этим, да еще и по каким-либо причинам, " +"делать, когда он и так занимается этим, да ещё и по каким-либо причинам, " "отличным от финансовых. Вообще говоря, этого подхода следует придерживаться, " "имея дело с любым проектом с Открытыми Исходными текстами (Open Source)." #. type: Title == -#: documentation/content/en/articles/problem-reports/_index.adoc:166 +#: documentation/content/en/articles/problem-reports/_index.adoc:175 #, no-wrap msgid "Before Beginning" msgstr "Прежде всего" #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:170 +#: documentation/content/en/articles/problem-reports/_index.adoc:179 msgid "" -"Similar considerations apply to use of the https://bugs.freebsd.org/bugzilla/" -"enter_bug.cgi[web-based PR submission form]. Be careful of cut-and-paste " -"operations that might change whitespace or other text formatting." +"The following considerations apply to use of the https://bugs.freebsd.org/" +"bugzilla/enter_bug.cgi[Bugzilla web-based PR submission form]. Be careful " +"of cut-and-paste operations that might change whitespace or other text " +"formatting." msgstr "" -"Аналогичные соображения применимы к использованию https://bugs.freebsd.org/" -"bugzilla/enter_bug.cgi[веб-формы для отправки PR]. Будьте осторожны с " -"операциями копирования и вставки, которые могут изменить пробелы или другое " -"форматирование текста." +"Следующие соображения применимы к использованию https://bugs.freebsd.org/" +"bugzilla/enter_bug.cgi[веб-формы Bugzilla для отправки PR]. Будьте осторожны " +"с операциями копирования и вставки, которые могут изменить пробелы или " +"другое форматирование текста." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:172 +#: documentation/content/en/articles/problem-reports/_index.adoc:181 msgid "" "Finally, if the submission is lengthy, prepare the work offline so that " "nothing will be lost if there is a problem submitting it." msgstr "" "И наконец, если ваше сообщение будет объёмным, вы должны приготовить его в " "offline, чтобы ничего не потерялось в случае, если будет проблема при его " "отправке." #. type: Title == -#: documentation/content/en/articles/problem-reports/_index.adoc:174 +#: documentation/content/en/articles/problem-reports/_index.adoc:183 #, no-wrap msgid "Attaching Patches or Files" msgstr "Вложение патчей или файлов" #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:182 +#: documentation/content/en/articles/problem-reports/_index.adoc:187 +msgid "" +"The following instructions apply not only to Problem Report submissions via " +"Bugzilla, but also via Phabricator or the FreeBSD Github instance (as Pull " +"Requests)." +msgstr "" +"Следующие инструкции применимы не только к отправке отчётов о проблемах " +"через Bugzilla, но также через Phabricator или организацию FreeBSD на Github " +"(в виде пул-реквестов)." + +#. type: Plain text +#: documentation/content/en/articles/problem-reports/_index.adoc:195 msgid "" -"In general, we recommend using `git format-patch` to generate one or a " -"series of unified diff against the base branch (e.g. `origin/main`). " +"In general, we strongly prefer using `git format-patch` to generate one or a " +"series of unified diffs against the base branch (e.g. `origin/main`). " "Patches generated this way would include the Git hashes and will include " "your name and email address, making it easier for committers to apply your " "patch and properly credit you as the author (using `git am`). For minor " "changes where you prefer not to use git, please be sure to use man:diff[1] " "with the `-u` option to create a unified diff, as this would give developers " -"more context and are more readable than other diff formats." +"more context and are more readable than other diff formats. Please base " +"your patch(es) at the base of the appropriate tree." msgstr "" -"В общем, мы рекомендуем использовать `git format-patch` для создания одного " -"или серии унифицированных diff-файлов относительно базовой ветки (например, `" -"origin/main`). Патчи, созданные таким образом, будут содержать хеши Git, а " -"также ваше имя и адрес электронной почты, что упростит применение вашего " -"патча коммиттерами и правильное указание вас как автора (с помощью `git am`)" -". Для небольших изменений, где вы предпочитаете не использовать git, " -"убедитесь, что используете man:diff[1] с опцией `-u` для создания " -"унифицированного diff-файла, так как это даст разработчикам больше контекста " -"и сделает его более читаемым по сравнению с другими форматами diff." +"В общем, мы настоятельно рекомендуем использовать `git format-patch` для " +"создания одного или серии унифицированных diff-файлов относительно базовой " +"ветки (например, `origin/main`). Патчи, созданные таким образом, будут " +"содержать хеши Git, а также ваше имя и адрес электронной почты, что упростит " +"применение вашего патча коммиттерами и правильное указание вас как автора (с " +"помощью `git am`). Для небольших изменений, где вы предпочитаете не " +"использовать git, убедитесь, что используете man:diff[1] с опцией `-u` для " +"создания унифицированного diff-файла, так как это даст разработчикам больше " +"контекста и сделает его более читаемым по сравнению с другими форматами " +"diff. Убедитесь, что ваши патчи созданы от корня соответствующего дерева " +"репозитория." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:185 +#: documentation/content/en/articles/problem-reports/_index.adoc:198 msgid "" "For problems with the kernel or the base utilities, a patch against FreeBSD-" "CURRENT (the main Git branch) is preferred since all new code should be " "applied and tested there first. After appropriate or substantial testing " "has been done, the code will be merged/migrated to the FreeBSD-STABLE branch." msgstr "" "Для проблем с ядром или базовыми утилитами предпочтителен патч для FreeBSD-" "CURRENT (основной ветки Git), поскольку весь новый код должен сначала " "применяться и тестироваться там. После проведения соответствующих или " "достаточных тестов код будет объединён/перенесён в ветку FreeBSD-STABLE." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:187 +#: documentation/content/en/articles/problem-reports/_index.adoc:200 msgid "" -"If you attach a patch inline, instead of as an attachment, note that the " -"most common problem by far is the tendency of some email programs to render " -"tabs as spaces, which will completely ruin anything intended to be part of a " -"Makefile." +"We prefer patches as attachments. However, if you attach a patch inline, " +"note that the most common problem by far is the tendency of some email " +"programs to render tabs as spaces, which will completely ruin anything " +"intended to be part of a Makefile." msgstr "" -"Если вы вставляете патч в тело сообщения, учтите, что некоторые почтовые " -"программы имеют тенденцию заменять табуляции серией пробелов, что полностью " -"разрушит, например, часть файла сборки (Makefile)." +"Мы предпочитаем, чтобы файлы с исправлениями отправлялись, как вложение к " +"сообщению. Однако, если вы вставляете патч в тело сообщения, учтите, что " +"некоторые почтовые программы имеют тенденцию заменять табуляции серией " +"пробелов, что полностью разрушит, например, часть файла сборки (Makefile)." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:190 +#: documentation/content/en/articles/problem-reports/_index.adoc:204 msgid "" "Do not send patches as attachments using `Content-Transfer-Encoding: quoted-" "printable`. These will perform character escaping and the entire patch will " -"be useless." +"be useless. Please simply use MIME type `text/plain'." msgstr "" "Не отсылайте патчи в виде вложений, используя `Content-Transfer-Encoding: " "quoted-printable`. Это выполнит экранирование (escaping) символов и весь " -"патч будет бесполезным." +"патч будет бесполезным. Пожалуйста, просто используйте тип MIME `text/plain'." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:195 +#: documentation/content/en/articles/problem-reports/_index.adoc:209 msgid "" -"Also note that while including small patches in a PR is generally all right—" -"particularly when they fix the problem described in the PR-large patches and " -"especially new code which may require substantial review before committing " -"should be placed on a web or ftp server, and the URL should be included in " -"the PR instead of the patch. Patches in email tend to get mangled, and the " -"larger the patch, the harder it will be for interested parties to unmangle " -"it. Also, posting a patch on the web allows you to modify it without having " -"to resubmit the entire patch in a followup to the original PR. Finally, " -"large patches simply increase the size of the database, since closed PRs are " -"not actually deleted but instead kept and simply marked as complete." -msgstr "" -"Следует также заметить, что включение небольших патчей в сообщение о " -"проблеме является приемлемой практикой, в особенности если они решают " -"проблему, описанную в сообщении, большие же патчи, а в особенности новый " -"код, который может требовать значительного просмотра перед тем, как он будет " -"внесен в дерево исходных текстов, должны быть размещены на web- или ftp-" -"сервере, а в сообщение о проблеме должен быть включён только URL указывающий " -"на этот патч. Очень часто патчи, пересылаемые по электронной почте, а в " -"особенности если задействована GNATS, бывают искажены, и, как следствие, чем " -"больше патч, тем труднее будет для заинтересованных людей привести его к " -"нормальному виду. Также то, что патч будет размещён отдельно от сообщения о " -"проблеме, даёт возможность изменять его не отсылая полный патч в дополнение " -"к изначальному сообщению о проблеме. И наконец, большие патчи просто " +"Also note that while including small patches in a Github Pull Request is " +"generally all right—particularly when they fix the problem described in the " +"Pull Request-large patches and especially new code which may require " +"substantial review before committing should be placed on a web or ftp " +"server, and the URL should be included in the Pull Request instead of the " +"patch. Patches in email tend to get mangled, and the larger the patch, the " +"harder it will be for interested parties to unmangle it. Also, posting a " +"patch on the web allows you to modify it without having to resubmit the " +"entire patch in a followup. Finally, large patches simply increase the size " +"of the database, since closed reports are not actually deleted but instead " +"kept and simply marked as complete." +msgstr "" +"Следует также заметить, что включение небольших патчей в запросах на " +"изменение (pull request) Github является приемлемой практикой, в особенности " +"если они решают проблему, описанную в запросе на изменение, большие же " +"патчи, а в особенности новый код, который может требовать значительного " +"просмотра перед тем, как он будет внесён в дерево исходных текстов, должны " +"быть размещены на web- или ftp-сервере, а в запрос на изменение должен быть " +"включён только URL указывающий на этот патч. Очень часто патчи, пересылаемые " +"по электронной почте, бывают искажены, и, как следствие, чем больше патч, " +"тем труднее будет для заинтересованных людей привести его к нормальному " +"виду. Также то, что патч будет размещён отдельно от сообщения о проблеме, " +"даёт возможность изменять его не отсылая полный патч в дополнение к " +"изначальному сообщению о проблеме. И наконец, большие патчи просто " "увеличивают размер базы данных, так как закрытые сообщения об ошибках на " "самом деле не удаляются, а сохраняются и помечаются, как `closed`." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:197 +#: documentation/content/en/articles/problem-reports/_index.adoc:211 msgid "" "You should also take note that unless you explicitly specify otherwise in " -"your PR or in the patch itself, any patches you submit will be assumed to be " -"licensed under the same terms as the original file you modified." +"your request or in the patch itself, any patches you submit will be assumed " +"to be licensed under the same terms as the original file you modified." msgstr "" "Вы должны также помнить, что пока вы явно не укажете обратного в вашем " -"сообщении о проблеме или в самих патчах, будет предполагаться, что они " -"подпадают под те же условия лицензирования, что и оригинальный файл, " -"измененный вами." +"запросе или в самих патчах, будет предполагаться, что они подпадают под те " +"же условия лицензирования, что и оригинальный файл, измененный вами." #. type: Title == -#: documentation/content/en/articles/problem-reports/_index.adoc:199 +#: documentation/content/en/articles/problem-reports/_index.adoc:213 #, no-wrap -msgid "Filling out the Form" -msgstr "Заполнение шаблона" +msgid "Filling out the Bugzilla Form" +msgstr "Заполнение формы Bugzilla" + +#. type: Plain text +#: documentation/content/en/articles/problem-reports/_index.adoc:216 +msgid "The following instructions apply only to submissions via Bugzilla." +msgstr "Следующие инструкции применимы только к отправке через Bugzilla." #. type: delimited block = 4 -#: documentation/content/en/articles/problem-reports/_index.adoc:206 +#: documentation/content/en/articles/problem-reports/_index.adoc:222 msgid "" "The email address you use will become public information and may become " "available to spammers. You should either have spam handling procedures in " "place, or use a temporary email account. However, please note that if you " "do not use a valid email account at all, we will not be able to ask you " -"questions about your PR." +"questions about your submission." msgstr "" "Используемый вами адрес электронной почты станет общедоступной информацией и " "может попасть к спамерам. У вас должны быть процедуры обработки спама или " "следует использовать временный почтовый аккаунт. Однако учтите, что если вы " "вообще не используете действительный почтовый аккаунт, мы не сможем задать " -"вам вопросы о вашем PR." +"вам вопросы о вашем сообщении." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:209 +#: documentation/content/en/articles/problem-reports/_index.adoc:225 msgid "When you file a bug, you will find the following fields:" msgstr "При подаче сообщения об ошибке вы увидите следующие поля:" #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:211 +#: documentation/content/en/articles/problem-reports/_index.adoc:227 msgid "" "_Summary:_ Fill this out with a short and accurate description of the " "problem. The synopsis is used as the subject of the problem report email, " "and is used in problem report listings and summaries; problem reports with " "obscure synopses tend to get ignored." msgstr "" "_Краткое описание:_ Заполните это кратким и точным описанием проблемы. " "Краткое описание используется как тема письма с отчётом о проблеме, а также " "в списках и сводках отчётов; отчёты с неясными описаниями часто остаются без " "внимания." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:212 +#: documentation/content/en/articles/problem-reports/_index.adoc:228 msgid "" "_Severity:_ One of `Affects only me`, `Affects some people` or `Affects many " "people`. Do not overreact; refrain from labeling your problem `Affects many " "people` unless it really does. FreeBSD developers will not necessarily work " "on your problem faster if you inflate its importance since there are so many " "other people who have done exactly that." msgstr "" -"_Серьезность:_ Одно из значений: `Затрагивает только меня (Affects only me)`" -", `Затрагивает некоторых людей (Affects some people)` или `Затрагивает " +"_Серьезность:_ Одно из значений: `Затрагивает только меня (Affects only " +"me)`, `Затрагивает некоторых людей (Affects some people)` или `Затрагивает " "многих людей (Affects many people)`. Не переоценивайте проблему; избегайте " "отмечать её как `Затрагивает многих людей`, если это не так. Разработчики " "FreeBSD не обязательно будут работать над вашей проблемой быстрее, если вы " "преувеличите её важность, поскольку многие другие уже поступали точно так же." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:213 +#: documentation/content/en/articles/problem-reports/_index.adoc:229 msgid "_Category:_ Choose an appropriate category." msgstr "_Категория:_ Выберите подходящую категорию." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:218 +#: documentation/content/en/articles/problem-reports/_index.adoc:234 msgid "" "The first thing you need to do is to decide what part of the system your " "problem lies in. Remember, FreeBSD is a complete operating system, which " "installs both a kernel, the standard libraries, many peripheral drivers, and " "a large number of utilities (the \"base system\"). However, there are " "thousands of additional applications in the Ports Collection. You'll first " "need to decide if the problem is in the base system or something installed " "via the Ports Collection." msgstr "" "Первое, что вам нужно сделать, — это определить, в какой части системы " "находится ваша проблема. Помните, что FreeBSD — это полноценная операционная " "система, которая включает в себя ядро, стандартные библиотеки, множество " "драйверов периферийных устройств и большое количество утилит («базовая " "система»). Однако в Коллекции портов доступны тысячи дополнительных " "приложений. Сначала вам нужно выяснить, связана ли проблема с базовой " "системой или с чем-то, установленным через Коллекцию портов." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:220 +#: documentation/content/en/articles/problem-reports/_index.adoc:236 msgid "Here is a description of the major categories:" msgstr "Вот описание основных категорий:" #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:222 +#: documentation/content/en/articles/problem-reports/_index.adoc:238 msgid "" "If a problem is with the kernel, the libraries (such as standard C library " "`libc`), or a peripheral driver in the base system, in general you will use " "the `kern` category. (There are a few exceptions; see below). In general " "these are things that are described in section 2, 3, or 4 of the manual " "pages." msgstr "" "Если проблема в ядре, в библиотеках (таких как стандартная библиотека С " -"`libc`) или в драйвере из базовой системы, то используйте категорию `kern`. (" -"Есть несколько исключений, описанных ниже). В общем, это всё, что описано в " +"`libc`) или в драйвере из базовой системы, то используйте категорию `kern`. " +"(Есть несколько исключений, описанных ниже). В общем, это всё, что описано в " "разделах 2, 3 или 4 справочника." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:223 +#: documentation/content/en/articles/problem-reports/_index.adoc:239 msgid "" "If a problem is with a binary program such as man:sh[1] or man:mount[8], you " "will first need to determine whether these programs are in the base system " "or were added via the Ports Collection. If you are unsure, you can do " "`whereis _programname_`. FreeBSD's convention for the Ports Collection is to " "install everything underneath [.filename]#/usr/local#, although this can be " "overridden by a system administrator. For these, you will use the `ports` " "category (yes, even if the port's category is `www`; see below). If the " "location is [.filename]#/bin#, [.filename]#/usr/bin#, [.filename]#/sbin#, or " "[.filename]#/usr/sbin#, it is part of the base system, and you should use " "the `bin` category. These are all things that are described in section 1 or " "8 of the manual pages." msgstr "" "Если проблема с бинарной программой, например с man:sh[1] или man:mount[8], " "то вам прежде всего необходимо определить принадлежность программы к базовой " "системе или к установке из коллекции портов. Если вы не уверены, выполните " "команду `whereis _имя программы_`. В FreeBSD для коллекции портов существует " "договоренность: установка ведется в [.filename]#/usr/local#, однако это " "может быть переопределено системным администратором. Для таких программ " "следует использовать категорию `ports` (даже если категория порта `www`; см. " "ниже). Если программа располагается в [.filename]#/bin#, [.filename]#/usr/" "bin#, [.filename]#/sbin# или в [.filename]#/usr/sbin#, то это часть базовой " "системы, и вам следует использовать категорию `bin`. (Несколько программ, " "например man:gcc[1], на самом деле используют категорию `gnu`, но не " "беспокойтесь об этом сейчас.) Программы этой категории описаны в разделах 1 " "и 8 справочной системы." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:224 +#: documentation/content/en/articles/problem-reports/_index.adoc:240 msgid "" "If you believe that the error is in the startup `(rc)` scripts, or in some " "kind of other non-executable configuration file, then the right category is " "`conf` (configuration). These are things that are described in section 5 of " "the manual pages." msgstr "" "Если вы уверены, что в стартовых скриптах `(rc)` или в каком-то ином " "неисполняемом конфигурационном файле присутствует ошибка, тогда верной " "категорией будет `conf` (configuration). Эти сущности описываются в разделе " "5 справочной системы." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:225 +#: documentation/content/en/articles/problem-reports/_index.adoc:241 msgid "" "If you have found a problem in the documentation set (articles, books, man " "pages) or website the correct choice is `docs`." msgstr "" "Если вы нашли проблему в наборе документации (статьи, книги, страницы " "справочной системы), правильным выбором будет `docs`." #. type: delimited block = 4 -#: documentation/content/en/articles/problem-reports/_index.adoc:229 +#: documentation/content/en/articles/problem-reports/_index.adoc:245 msgid "" "if you are having a problem with something from a port named `www/" "_someportname_`, this nevertheless goes in the `ports` category." msgstr "" "Если проблема с чем-то из порта, называемого `www/_имяпорта_`, то она все же " "принадлежит к категории `ports`." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:232 +#: documentation/content/en/articles/problem-reports/_index.adoc:248 msgid "There are a few more specialized categories." msgstr "Далее представлены более специализированные категории." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:234 +#: documentation/content/en/articles/problem-reports/_index.adoc:250 msgid "" "If the problem would otherwise be filed in `kern` but has to do with the USB " "subsystem, the correct choice is `usb`." msgstr "" "Если проблема принадлежит к `kern`, но в то же время имеет дело с " "подсистемой USB, то правильным выбором будет `usb`." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:235 +#: documentation/content/en/articles/problem-reports/_index.adoc:251 msgid "" "If the problem would otherwise be filed in `kern` but has to do with the " "threading libraries, the correct choice is `threads`." msgstr "" "Если проблема принадлежит к `kern` и найдена в потоковых библиотеках, " "правильным выбором будет `threads`." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:236 +#: documentation/content/en/articles/problem-reports/_index.adoc:252 msgid "" "If the problem would otherwise be in the base system, but has to do with our " "adherence to standards such as POSIX(R), the correct choice is `standards`." msgstr "" "Если проблема принадлежит к базовой системе и касается соблюдения " "стандартов, таких как POSIX(R), правильным выбором будет `standards`." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:237 +#: documentation/content/en/articles/problem-reports/_index.adoc:253 msgid "" "If you are convinced that the problem will only occur under the processor " "architecture you are using, select one of the architecture-specific " "categories: commonly `i386` for Intel-compatible machines in 32-bit mode; " "`amd64` for AMD machines running in 64-bit mode (this also includes Intel-" -"compatible machines running in EMT64 mode); and less commonly `arm` or " -"`powerpc`." +"compatible machines running in EMT64 mode); and less commonly `arm`, " +"`powerpc`, or `riscv64`." msgstr "" "Если вы уверены, что проблема возникнет только на используемой вами " "архитектуре процессора, выберите одну из архитектурно-зависимых категорий: " "обычно `i386` для Intel-совместимых машин в 32-битном режиме; `amd64` для " "машин AMD, работающих в 64-битном режиме (это также включает Intel-" -"совместимые машины, работающие в режиме EMT64); и реже `arm` или `powerpc`." +"совместимые машины, работающие в режиме EMT64); и реже `arm`, `powerpc` или " +"`riscv64`." #. type: delimited block = 4 -#: documentation/content/en/articles/problem-reports/_index.adoc:241 +#: documentation/content/en/articles/problem-reports/_index.adoc:257 msgid "" "These categories are quite often misused for \"I do not know\" problems. " "Rather than guessing, please just use `misc`." msgstr "" "Люди часто ошибаются в выборе категории. Если вы не уверены в правильности " "выбора, то лучше не гадать, а выбрать `misc`." #. type: Block title -#: documentation/content/en/articles/problem-reports/_index.adoc:243 +#: documentation/content/en/articles/problem-reports/_index.adoc:259 #, no-wrap msgid "Correct Use of Arch-Specific Category" msgstr "Правильное использование архитектурно-зависимых категорий" #. type: delimited block = 4 -#: documentation/content/en/articles/problem-reports/_index.adoc:247 +#: documentation/content/en/articles/problem-reports/_index.adoc:263 msgid "" "You have a common PC-based machine, and think you have encountered a problem " "specific to a particular chipset or a particular motherboard: `i386` is the " "right category." msgstr "" "У вас простой ПК, и вы подозреваете, что столкнулись с проблемой, " -"специфичной для конкретного чипсета или материнской платы: верная категория -" -" `i386`." +"специфичной для конкретного чипсета или материнской платы: верная категория " +"- `i386`." #. type: Block title -#: documentation/content/en/articles/problem-reports/_index.adoc:249 +#: documentation/content/en/articles/problem-reports/_index.adoc:265 #, no-wrap msgid "Incorrect Use of Arch-Specific Category" msgstr "Некорректное использование категории, зависящей от архитектуры" #. type: delimited block = 4 -#: documentation/content/en/articles/problem-reports/_index.adoc:253 +#: documentation/content/en/articles/problem-reports/_index.adoc:269 msgid "" "You are having a problem with an add-in peripheral card on a commonly seen " "bus, or a problem with a particular type of hard disk drive: in this case, " "it probably applies to more than one architecture, and `kern` is the right " "category." msgstr "" "Если вы наблюдаете проблему с периферийной картой расширения на " -"распространённой шине или неполадки с конкретного типа жестким диском: в " +"распространённой шине или неполадки с конкретного типа жёстким диском: в " "этом случае возможно, что неисправность наблюдается на более чем одной " "архитектуре, и верным выбором будет `kern`." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:255 +#: documentation/content/en/articles/problem-reports/_index.adoc:271 msgid "" "If you really do not know where the problem lies (or the explanation does " "not seem to fit into the ones above), use the `misc` category. Before you do " -"so, you may wish to ask for help on the {freebsd-questions} first. You may " -"be advised that one of the existing categories really is a better choice." +"so, you may wish to ask for help first. You may be advised that one of the " +"existing categories really is a better choice." msgstr "" "Если вы не знаете в чем проблема (или вам кажется, что описание не попадает " "ни под какую из вышеобозначенных), используйте категорию `misc`. Перед тем, " -"как написать PR, можно для начала спросить помощи в {freebsd-questions}. " -"Возможно, там вам подскажут, какую из существующих категорий следует выбрать." +"как сделать так, можно для начала спросить помощи. Возможно, вам подскажут, " +"какую из существующих категорий следует выбрать." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:256 +#: documentation/content/en/articles/problem-reports/_index.adoc:272 msgid "" "_Environment:_ This should describe, as accurately as possible, the " "environment in which the problem has been observed. This includes the " "operating system version, the version of the specific program or file that " "contains the problem, and any other relevant items such as system " "configuration, other installed software that influences the problem, etc.—" "quite simply everything a developer needs to know to reconstruct the " "environment in which the problem occurs." msgstr "" "_Environment:_ Оно должно максимально точно описывать окружение, в котором " "встречается проблема. Сюда включается версия операционной системы, версия " "конкретной программы или файла, содержащего проблему, и любая другая " "информация, такая, как конфигурация системы, другое программное обеспечение, " "которое влияет на проблему, и так далее-просто все, что разработчик должен " "знать для создания условий появления проблемы." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:257 +#: documentation/content/en/articles/problem-reports/_index.adoc:273 msgid "" "_Description:_ A complete and accurate description of the problem you are " "experiencing. Try to avoid speculating about the causes of the problem " "unless you are certain that you are on the right track, as it may mislead a " "developer into making incorrect assumptions about the problem. It should " "include the actions you need to take to reproduce the problem. If you know " "any workaround, include it. It not only helps other people with the same " "problem work around it, but may also help a developer understand the cause " "for the problem." msgstr "" "_Описание:_ Полное и точное описание проблемы, с которой вы столкнулись. " "Старайтесь избегать предположений о причинах проблемы, если не уверены в " "своей правоте, так как это может ввести разработчика в заблуждение и " "привести к неверным выводам. В описании должны быть указаны действия, " "необходимые для воспроизведения проблемы. Если вам известен обходной путь, " "укажите его. Это не только поможет другим людям с той же проблемой временно " "её решить, но и может помочь разработчику понять причину возникновения " "проблемы." #. type: Title == -#: documentation/content/en/articles/problem-reports/_index.adoc:259 +#: documentation/content/en/articles/problem-reports/_index.adoc:275 #, no-wrap msgid "Follow-up" msgstr "Отслеживание" #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:264 +#: documentation/content/en/articles/problem-reports/_index.adoc:280 msgid "" "Once the problem report has been filed, you will receive a confirmation by " "email which will include the tracking number that was assigned to your " "problem report and a URL you can use to check its status. With a little " "luck, someone will take an interest in your problem and try to address it, " "or, as the case may be, explain why it is not a problem. You will be " "automatically notified of any change of status, and you will receive copies " "of any comments or patches someone may attach to your problem report's audit " "trail." msgstr "" "После того, как ваше сообщение будет принято, вы получите по электронной " "почте уведомление, в котором будет указан номер для отслеживания, который " "был назначен вашему сообщению о проблеме и URL, который вы можете " "использовать для проверки его состояния. В случае удачи кто-нибудь проявит " -"интерес к вашей проблеме и попытается ее решить, или, как это бывает, " +"интерес к вашей проблеме и попытается её решить, или, как это бывает, " "описать, почему это не является проблемой. Вы будете автоматически " "оповещаться о любом изменении состояния и получать копии всех комментариев " "или патчей, которые будут присоединяться в процессе отработки вашего " "сообщения о проблеме." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:268 +#: documentation/content/en/articles/problem-reports/_index.adoc:284 msgid "" "If someone requests additional information from you, or you remember or " "discover something you did not mention in the initial report, please submit " "a follow up. The number one reason for a bug not getting fixed is lack of " "communication with the originator. The easiest way is to use the comment " -"option on the individual PR's web page, which you can reach from the https://" -"bugs.freebsd.org/bugzilla/query.cgi[PR search page]." +"option on the individual Bugzilla PR's web page, which you can reach from " +"the https://bugs.freebsd.org/bugzilla/query.cgi[Bugzilla PR search page]." msgstr "" "Если кто-то запросит у вас дополнительную информацию, или вы вспомните или " "обнаружите что-то, что не упомянули в первоначальном отчёте, пожалуйста, " "отправьте уточнение. Основная причина, по которой ошибка не исправляется, — " "это отсутствие связи с автором отчёта. Проще всего воспользоваться опцией " -"комментария на веб-странице конкретного PR, которую можно открыть с " -"https://bugs.freebsd.org/bugzilla/query.cgi[страницы поиска PR]." +"комментария на веб-странице Bugzilla конкретного PR, которую можно открыть с " +"https://bugs.freebsd.org/bugzilla/query.cgi[страницы поиска PR Bugzilla]." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:270 +#: documentation/content/en/articles/problem-reports/_index.adoc:286 msgid "" "If the problem report remains open after the problem has gone away, just add " "a comment saying that the problem report can be closed, and, if possible, " "explaining how or when the problem was fixed." msgstr "" "Если проблема исчезла, но отчёт о ней остаётся открытым, просто добавьте " "комментарий с указанием, что отчёт можно закрыть, и, по возможности, " "объясните, как или когда проблема была устранена." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:274 +#: documentation/content/en/articles/problem-reports/_index.adoc:290 msgid "" "Sometimes there is a delay of a week or two where the problem report remains " "untouched, not assigned or commented on by anyone. This can happen when " "there is an increased problem report backlog or during a holiday season. " "When a problem report has not received attention after several weeks, it is " "worth finding a committer particularly interested in working on it." msgstr "" "Иногда возникает задержка в одну-две недели, когда отчёт о проблеме остаётся " "без внимания — никто не назначается на него и не оставляет комментариев. " "Такое может произойти при увеличении очереди отчётов о проблемах или во " "время праздничного сезона. Если отчёт о проблеме не получил внимания в " "течение нескольких недель, стоит найти коммиттера, особенно " "заинтересованного в работе над ним." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:276 +#: documentation/content/en/articles/problem-reports/_index.adoc:292 msgid "" "There are a few ways to do so, ideally in the following order, with a few " "days between attempting each communication channel:" msgstr "" "Существует несколько способов сделать это, желательно в следующем порядке, с " "перерывом в несколько дней между попытками использования каждого канала " "связи:" #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:278 +#: documentation/content/en/articles/problem-reports/_index.adoc:294 msgid "" "Send an e-mail to extref:{handbook}eresources/[the relevant list, eresources-" "summary] seeking comments on the report." msgstr "" -"Отправить письмо по электронной почте в extref:{handbook}eresources/[" -"соответствующий список, eresources-summary] для получения комментариев к " +"Отправить письмо по электронной почте в extref:{handbook}eresources/" +"[соответствующий список, eresources-summary] для получения комментариев к " "отчёту." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:279 +#: documentation/content/en/articles/problem-reports/_index.adoc:295 msgid "" "Join the relevant IRC channels. A partial listing is here: https://wiki." "freebsd.org/IRC/Channels[]. Inform the people in that channel about the " "problem report and ask for assistance. Be patient and stay in the channel " "after posting, so that the people from different time zones around the world " "have a chance to catch up." msgstr "" "Присоединитесь к соответствующим IRC-каналам. Частичный список доступен " "здесь: https://wiki.freebsd.org/IRC/Channels[]. Сообщите участникам канала о " "проблеме и запросите помощь. Будьте терпеливы и оставайтесь в канале после " "отправки сообщения, чтобы у людей из разных часовых поясов была возможность " "отреагировать." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:280 +#: documentation/content/en/articles/problem-reports/_index.adoc:296 msgid "" "Find committers interested in the problem that was reported. If the problem " "was in a particular tool, binary, port, document, or source file, check the " "https://cgit.FreeBSD.org[Git Repository]. Locate the last few committers who " "made substantive changes to the file, and try to reach them via IRC or " "email. A list of committers and their emails can be found in the extref:" "{contributors}[Contributors to FreeBSD] article." msgstr "" "Найдите коммиттеров, заинтересованных в сообщенной проблеме. Если проблема " "касается конкретного инструмента, бинарного файла, порта, документа или " "исходного файла, проверьте https://cgit.FreeBSD.org[Git Repository]. " "Определите последних коммиттеров, внесших существенные изменения в файл, и " "попытайтесь связаться с ними через IRC или электронную почту. Список " -"коммиттеров и их адреса электронной почты можно найти в статье " -"extref:{contributors}[Участники проекта FreeBSD]." +"коммиттеров и их адреса электронной почты можно найти в статье extref:" +"{contributors}[Участники проекта FreeBSD]." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:284 +#: documentation/content/en/articles/problem-reports/_index.adoc:300 msgid "" "Remember that these people are volunteers, just like maintainers and users, " "so they might not be immediately available to assist with the problem " "report. Patience and consistency in the follow-ups is highly advised and " "appreciated. With enough care and effort dedicated to that follow-up " "process, finding a committer to take care of the problem report is just a " "matter of time." msgstr "" "Помните, что эти люди — добровольцы, как и сопровождающие и пользователи, " "поэтому они могут быть не сразу доступны для помощи с отчётом о проблеме. " "Терпение и последовательность в дальнейших действиях крайне рекомендуются и " "ценятся. При достаточном внимании и усилиях, посвящённых этому процессу, " "найти коммиттера, который займётся отчётом о проблеме — лишь вопрос времени." #. type: Title == -#: documentation/content/en/articles/problem-reports/_index.adoc:286 +#: documentation/content/en/articles/problem-reports/_index.adoc:302 #, no-wrap msgid "If There Are Problems" msgstr "Если возникли проблемы" #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:290 +#: documentation/content/en/articles/problem-reports/_index.adoc:306 msgid "" "If you found an issue with the bug system, file a bug! There is a category " "for exactly this purpose. If you are unable to do so, contact the bug " "wranglers at mailto:bugmeister@FreeBSD.org[bugmeister@FreeBSD.org]." msgstr "" "Если вы обнаружили проблему в системе отслеживания ошибок, сообщите об " "ошибке! Для этого существует специальная категория. Если у вас не получается " -"это сделать, свяжитесь с ответственными за обработку ошибок по адресу " -"mailto:bugmeister@FreeBSD.org[bugmeister@FreeBSD.org]." +"это сделать, свяжитесь с ответственными за обработку ошибок по адресу mailto:" +"bugmeister@FreeBSD.org[bugmeister@FreeBSD.org]." #. type: Title == -#: documentation/content/en/articles/problem-reports/_index.adoc:292 +#: documentation/content/en/articles/problem-reports/_index.adoc:308 #, no-wrap msgid "Further Reading" msgstr "Для дальнейшего ознакомления" #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:296 +#: documentation/content/en/articles/problem-reports/_index.adoc:312 msgid "" "This is a list of resources relevant to the proper writing and processing of " "problem reports. It is by no means complete." msgstr "" "Это список информационных ресурсов, относящихся к правильному написанию и " "обработке сообщений о проблемах. Он, без сомнения, не полон." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:298 +#: documentation/content/en/articles/problem-reports/_index.adoc:314 msgid "" "https://github.com/smileytechguy/reporting-bugs-effectively/blob/master/" "ENGLISH.md[How to Report Bugs Effectively]: An excellent essay by Simon G. " "Tatham on composing useful (non-FreeBSD-specific) problem reports." msgstr "" "https://github.com/smileytechguy/reporting-bugs-effectively/blob/master/" "ENGLISH.md[How to Report Bugs Effectively]-прекрасное эссе, которое написал " "Simon G. Tatham о составлении полезных (не специфичных для FreeBSD) " "сообщений о проблемах." #. type: Plain text -#: documentation/content/en/articles/problem-reports/_index.adoc:298 +#: documentation/content/en/articles/problem-reports/_index.adoc:314 msgid "" "extref:{pr-guidelines}[Problem Report Handling Guidelines]: Valuable insight " "into how problem reports are handled by the FreeBSD developers." msgstr "" -"extref:{pr-guidelines}[Problem Report Handling Guidelines]-интересный взгляд " -"на обработку сообщений о проблемах самими разработчиками FreeBSD." +"extref:{pr-guidelines}[Руководство по обработке отчётов о проблемах] — " +"интересный взгляд на обработку сообщений о проблемах самими разработчиками " +"FreeBSD." + +#~ msgid "" +#~ "Do not use the `patch` or `patch-ready` keywords – they are deprecated." +#~ msgstr "" +#~ "Не используйте ключевые слова `patch` или `patch-ready` — они устарели."