Re: Вычитка_Bugs_Reporting
Пн 15 окт 2018 @ 13:10 Galina Anikina <merilaga@yandex.ru>:
> Вот где-то здесь, в самом начале этой html страницы, надо сразу
> уведомить читателя о том, что крайне желательно (а практически
> обязательно), чтобы сообщения были написаны на (международном)
> английском языке, поскольку так исторически сложилось, что большинство
> людей взаимодействуют с друг другом на этом языке.
> Это надо написать
> обязательно, вне зависимотси, что где-то на других html-страницах об
> этом было упомянуто. В данном случае "кашу маслом не испортишь". :-))
Написал так:
<p>Сообщения об ошибках следует писать на английском языке, поскольку именно он принят
для общения в Проекте. Если вы затрудняетесь написать сообщение об ошибке на английском языке,
то обратитесь за помощью к команде русскоязычной поддержки, <a href="mailto:debian-russian@lists.debian.org";>\
debian-russian@lists.debian.org</a>, либо к русской команде локализации,
<a href="mailto:debian-l10n-russian@lists.debian.org";>debian-l10n-russian@lists.debian.org</a>.</p>
> было-
> Если у вас есть вопросы,
> на которые в интерактивных запросах вы не получили ответов, вы можете
> воспользоваться документации ниже или задать вопрос в пользовательской
> рассылке Debian.
>
> подправить
> Если у вас есть вопросы, на которые в интерактивных запросах вы не
> получили ответов, вы можете воспользоваться документациЕЙ ниже или
> задать вопрос в пользовательской рассылке Debian.
ОК.
> Вы должны знать пакет, на который должен быть оформлено ваше
> сообщение об ошибке.
>
> надо
> Вы должны знать пакет, на который должнО быть
> оформлено ваше сообщение об ошибке.
ОК.
> Смотрите в этом примере, как найти эту информацию. (Вы будете
> использовать эту информацию, чтобы проверить, не было ли сообщено об
> этой ошибке кем-либо ранее.)
>
> может
> Смотрите в этом примере, как найти эту
> информацию. (Вы будете использовать ЕЁ, чтобы проверить, не посылал ли
> ранее кто-то уже сообщение об этой ошибке.)
ОК.
> На случай, если проблема
> относится не к какому-либо пакету, а к общим услугам Debian, существует
> несколько псевдо-пакетов, или даже списки рассылки, которые можно
> использовать, чтобы довести до нас вашу информацию.
>
> может
> На случай, если
> проблема относится не к какому-либо пакету, а к общим услугам Debian,
> существует несколько псевдо-пакетов, или даже списки рассылки, которые
> можно использовать, чтобы довести до нас ЭТУ информацию.
ОК.
> Вы можете
> увидеть, какие ошибки были отправлены на определённый пакет с помощью
> опции пакета в форме поиска ошибок.
>
> может
> Вы можете просмотреть с
> помощью параметра пакета reportbug в форме поиска ошибок, какие ошибки
> были отправлены ранее на определённый пакет.
Сделал: С помощью <a href="./#pkgreport">опции пакета в форме поиска
ошибок</a> вы можете посмотреть, какие сообщения об ошибках уже были
отправлены для определённого пакета.
> Если сообщение о данной ошибке уже существует с
> #<номером>, то вместо заведения новой ошибки вы должны оставлять
> комментарии, отсылая письма на адрес <номер>@bugs.debian.org.
>
> может
> Если
> сообщение о данной ошибке уже существует, с присвоенным ему #<номером>,
> то вместо составления нового отчёта о той же ошибке надо написать
> комментарий к багу с тем же номером и отправить его в форме письма на
> адрес <номер>@bugs.debian.org.
Сделал: Если сообщение о данной ошибке уже существует с
#<var><номером></var>, то вместо составления нового сообщения об
ошибке вам следует оставлять комментарии в виде писем, отправленных на
адрес <var><номер></var>@bugs.debian.org.</p>
> Посылайте несколько сообщений для нескольких ошибок
>
> может
> На каждую
> ошибку посылайте отдельное сообщение
ОК.
> Не
> посылайте информацию о нескольких несвязанных ошибках в одном
> сообщении, в особенности если они относятся к разным пакетам.
>
> может
> Не
> посылайте информацию о нескольких ошибках в одном сообщении
> (несвязанных между собой), в особенности если они относятся к разным
> пакетам.
Сделал: Не посылайте информацию о нескольких ошибках в одном сообщении,
особенно если они не связаны друг с друго или относятся к разным
пакетам.
> Не посылайте ошибки авторам
> программы
>
> может
> Не посылайте ошибки авторам программ
ОК.
> Если вы отправляете сообщение об ошибке в Debian, не
> посылайте самостоятельно копию авторам программы — возможно, что ошибка
> существует только в Debian.
>
> может
> Если вы отправляете сообщение об
> ошибке в Debian, то не посылайте самостоятельно ещё и копию авторам
> программы — возможно, что ошибка существует только в Debian.
ОК.
> Если будет необходимо, сопровождающий
> пакета сам перешлёт сообщение об ошибке.
>
> может
> Если будет необходимо,
> сопровождающий пакета сам перенаправит сообщение об ошибке авторам.
ОК.
> Вы можете сообщить об ошибке в Debian,
> послав письмо по адресу submit@bugs.debian.org в формате, описанном
> ниже. reportbug (см. выше) должным образом оформит ваше письмо
> (пожалуйста, используйте этот формат!).
>
> может
> Вы можете сообщить об
> ошибке в Debian, послав письмо по адресу submit@bugs.debian.org в
> формате, описанном ниже. Программа reportbug (см. выше) должным образом
> оформит ваше письмо (пожалуйста, используйте этот формат!).
ОК.
> Как и в любом другом письме, вы должны дать
> сообщению ясную, содержательную тему (Subject).
>
> может
> Как и при
> составлении любого другого письма ему надо дать ясную содержательную
> тему (заголовок, Subject).
ОК.
> Указанная тема будет
> использоваться в BTS как первоначальное название ошибки, так что,
> пожалуйста, попытайтесь сделать её информативной!
>
> может
> Поскольку
> указанная тема будет использоваться в BTS как первоначальное название
> ошибки, пожалуйста постарайтесь сделать её информативной!
ОК.
> Если вы хотите послать копию вашего сообщения об
> ошибке дополнительным получателям (например, в список рассылки), вы
> должны для этого использовать не обычные заголовки писем, а другой
> метод, описанный ниже.
>
> может
> Если вы хотите послать копию вашего
> сообщения об ошибке дополнительным получателям (например, в список
> рассылки), то вам необходимо для этого использовать не обычные
> заголовки писем, а другой метод, описанный ниже.
ОК.
> Замените <версия_пакета> версией пакета. Не добавляйте
> сюда ничего кроме версии, так как для работы системы отслеживания
> ошибок это поле более важно, чем выпуски, подверженные данной ошибке.
>
> мо
> жет
> Замените <версия_пакета> версией того пакета, о котором пишите
> сообщение. Не добавляйте сюда ничего кроме версии, так как для работы
> системы отслеживания ошибок это поле более важно, чем выпуски,
> подверженные данной ошибке.
Сделал: версией того пакета, для которого вы пишете сообщение.
> Please don't include any text here other
> than the version itself, as the bug tracking system relies on this
> field to work out which releases are affected by the bug.
>
> Здесь что-то
> подзапуталась - "чем выпуски, подверженные данной ошибке" - это номер
> версии? Но мы же пишем, что здесь надо ввести номер версии, То есть что
> имелось в виду, когда так перевели на русский?
Тут неправильно переведено.
Сделал: Не добавляйте сюда ничего кроме версии, поскольку система
отслеживания ошибок использует это поле для определения того, какие
выпуски, подвержены данной ошибке.
> Вы должны задать правильную строку
> Package псевдо-заголовка для того, чтобы система отслеживания ошибок
> отправила сообщение сопровождающему пакета.
>
> может
> Строку Package (имя
> пакета) псевдо-заголовка вам необходимо заполнять очень внимательно,
> поскольку система отслеживания ошибок отправит это сообщение
> сопровождающему пакета.
Сделал: Вам сделает правильно задать строку <code>Package</code>
псевдозаголовка, чтобы система отслеживания ошибок могла отправила
сообщение сопровождающему пакета.
> См.
> информацию о том, как находить эту информацию, в примере.
>
> может
> Чуть
> ниже, приведён пример, как найти эту информацию.
ОК.
> Другие псевдо-заголовки вы можете найти в
> списке Дополнительных псевдо-заголовков
>
> может
> Информацию о других псевдо-
> заголовках вы можете найти в списке Дополнительных псевдо-заголовков
ОК.
> В точности, что вы вводите или делаете
> для воспроизведения проблемы.
>
> может
> Опишите подробно все ваши действия (с
> момента запуска программы) до возникновения проблемы, чтобы другие люди
> смогли воспроизвести такую же последовательность действий и получить
> тот же результат.
Сделал: Точное и подробное описание всего, что вы вводите или делаете
для воспроизведения проблемы.
Тут и далее указаны элементы списка, который задаётся выше с помощью
фразы "Пожалуйста, включите в ваше сообщение:", поэтому "опишите" и др.
формы тут не подходят.
> Хороший
> способ привести такую информацию — стенограмма демонстрационного сеанса
> работа.
>
> может
> Хорошим решением будет предоставить разработчикам
> стенограмма демонстрационного сеанса работа (видезапись или перечень
> всех действий до появления проблемы).
Сделал: Хорошим способом предоставить такую информацию будет являться
стенограмма демонстрационного сеанса работа.
> Предлагаемое решение, или даже заплата, если оно у вас есть.
>
> может
> Есл
> и у вас есть предложение, как исправить эту проблему, то сообщите о
> нём, или возможно у вас есть решение в виде готорой заплатки, то
> вышлите её вместе с этим письмом.
Заменил только "оно" на "таковое", чтобы лучше согласовать.
> Включите
> полный текст её конфигурационных файлов.
>
> может
> Включите полныЕ текстЫ её
> конфигурационных файлов.
ОК.
> Например, если у вас проблемы со скриптом Perl, вы можете
> пожелать указать версию двоичного файла `perl' (введите perl -v или
> dpkg -s perl | grep ^Version:).
>
> может
> Например, если у вас проблемы со
> скриптом Perl, вы возможно захотите указать версию двоичного файла
> `perl' (введите perl -v или dpkg -s perl | grep ^Version:).
ОК.
> Могущие быть полезными подробности относительно
> аппаратного обеспечения вашей системы.
>
> может
> Подробности относительно
> аппаратного обеспечения вашей системы могут быть очень полезными.
Сделал: Подробности относительно аппаратного обеспечения вашей системы,
которые, как вы считаете, могут оказаться полезными.
> Если вы сообщаете о
> проблеме с драйвером устройства, пожалуйста, приведите список всего
> аппаратного обеспечения вашей системы, поскольку проблемы часто бывают
> вызваны конфликтами номеров IRQ или адресов ввода/вывода.
>
> может
> Если вы
> сообщаете о проблеме с драйвером какого-либо устройства, то пожалуйста
> приведите список всего аппаратного обеспечения вашей системы, поскольку
> часто проблемы бывают вызваны конфликтами номеров IRQ или адресов
> ввода/вывода.
ОК. Ещё убрал "пожалуйста".
> Если у вас установлена
> программа reportbug, вывод команды reportbug -q --template -T none -s
> none -S normal -b --list-cc none -q <пакет> также будет полезным, так
> как содержит вывод специфичных для сопровождающего скриптов и
> информацию о версии.
>
> может
> Если у вас установлена программа reportbug, то
> результат работы команды reportbug -q --template -T none -s none -S
> normal -b --list-cc none -q <пакет> выдаст много полезной информации,
> поскольку в нём будет перечень сценариев, специфичных для
> сопровождающего, и информацию о версии.
"То" добавил, остальное не менял.
> Если
> много подробностей вы привести не можете, пожалуйста, включите в
> сообщение все файлы, которые вы используете при воспроизведении
> проблемы (если они велики, выложите их на публично доступный веб-сайт,
> если это возможно).
>
> может
> Если много подробностей вы привести не сможете,
> то включите пожалуйста в сообщение все файлы, которые вы использовали
> для воспроизведения проблемы (если они велики, то выложите их на
> публично доступный веб-сайт, по возможности).
Убрал "пожалуйста".
> Более подробно о том, как вы можете помочь разработчикам решить
> вашу проблему, вы можете прочитать в статье How to Report Bugs
> Effectively.
>
> может
> Более подробно о том, как вы можете помочь
> разработчикам решить вашу проблему, можно прочитать в статье How to
> Report Bugs Effectively.
ОК. Заменил "прочитать" на "прочесть".
> Иногда необходимо
> отправить копию сообщения об ошибке кому-то ещё, кроме debian-bugs-dist
> и сопровождающего пакета (по этим адресам письмо посылается обычно).
>
> мож
> ет
> Иногда необходимо отправить копию сообщения об ошибке кому-то ещё,
> кроме debian-bugs-dist и сопровождающего пакета (по которым обычно
> данное письмо и направляют).
ОК.
> Вы могли бы сделать, включив другие адреса в поле CC (копия), но в
> этом случае копии не будут содержать номера сообщения об ошибке в полях
> Reply-To и Subject.
>
> может
> Вы могли бы это сделать, включив другие адреса
> в поле CC (копия), но в этом случае копии не будут содержать номера
> регистрации сообщения об ошибке в полях Reply-To и Subject.
ОК.
> Если получатели станут отвечать на это письмо,
> они, вероятно, оставят в заголовке адрес submit@bugs.debian.org и
> создадут своими письмами новые сообщения об ошибках.
>
> может
> Если
> получатели решат ответить на это письмо, то скорее всего оставят в
> заголовке адрес submit@bugs.debian.org. В результате этого их письма
> будут вновь зарегистированы в системе отслуживания ошибок как новые
> ошибки.
ОК, сделал: В результате этого их письма будут заново зарегистрированы в
системе отслеживания ошибок как сообщения о новых ошибках.
> Это приведёт к
> появлению большого количества дублирующихся сообщений.
>
> может
> Это приведёт
> к появлению большого количества дублирующихся сообщений (и создаст
> ситуацию перезагруженностии серверов).
Думаю, это лишее.
> Если ошибка является очень серьёзной или,
> наоборот, лишь желаемой возможностью, вы можете установить при отправке
> сообщения уровень важности ошибки.
>
> может
> В зависимости от того, касается
> ли ваш отчёт очень серьёзной ошибки, или просто включает в себя
> предложения о необходимости включения в программу каких-то характерных
> особенностей, вам необходимо при отправке сообщения указать уровень его
> важности на своё усмотрение.
Сделал: Если ваше сообщение касается очень серьёзной ошибки или,
наоборот, является лишь запросом о желательной функциональности, то вы можете
установить при отправке сообщения соответствующий уровень важности
ошибки.
В ошибках wishlist нет никакой необходимости.
> Тем не
> менее, это не обязательно, и если вы не присвоите ошибке уровень
> важности, сопровождающие пакета сделают это сами (или исправят
> неправильно установленный уровень).
>
> может
> Если вы не выставите уровень
> важности в сообщении (или не смогли его сами определить) это не столь
> принципиально, поскольку сопровождающие пакета сделают это сами (или
> исправят неправильно установленный уровень).
Не вижу смысла менять.
> Замените <важность> одним из возможных значений, как описано в
> расширенной документации.
>
> может
> Замените <важность> одним из возможных
> значений, как описано в дополнительной документации.
ОК.
> Присвоение значений тегам
>
> может
> Присвоение значений меткам
> (контрольные метки для систематизации информации)
Пусть будут "метки".
> Например, если вы включаете
> в сообщение заплату, вы, возможно, захотите установить тег patch.
>
> может
>
> Например, если вы включаете в сообщение заплату, то было бы разумно
> установить метку "patch".
ОК.
> Тем не менее, это не
> обязательно, и разработчики установят все необходимые теги.
>
> может
> Тем не
> менее это не обязательно, и разработчики сами установят все необходимые
> метки.
ОК, только "сами" поставил в конце.
> И далее тоже, где теги упоминаются
> поменять на "метки"
Будет сделано, капитан!
> Замените <теги> одним из возможных значений, как описано в расширенной
> документации.
>
> может
> Замените <теги> одним из возможных значений, как
> описано в дополнительной документации.
>
> Первый раз слышу, чтобы была
> названа "расширенная документация" (вернее в этой html-странице читаю
> уже во второй раз). В русском так не говорят. "Дополнительная,
> уточняющая и какая хочешь ещё, но не расширенная". Даже не могу
> придумать - где употребляется это слово в русском. Расширенная гарантия
> - может так пишут магазины в своей дополнительной гарантии на товар, но
> они так пишут, чтоб заморочить голову покупателям и ни в коем случае не
> произнести "дополнительная", потому что покупатель сразу "навостит уши"
> и не захочет платить за что-то "дополнительное" и вот ему предлагают
> "расширенную" гарантию. То есть это просто игра слов, а в нашей, книго-
> издательской деятельности данное слово не употребляется (применительно
> к нашим задачам). :-)))
Книго-издательской деятельности? Угу, хорошо пусть будет так.
> User:
> <имя_пользователя>
>
> может
> User: <имя_пользователя> латинискими символами
> (пример - как на банковской карточке)
Думаю, это не обязательно.
> Forwarded: foo@example.com
> помечает новую представленную ошибку как
> переправленную на foo@example.com. Смотрите в документации разработчика
> Запись, которую вы отправили в сообщении об ошибке.
>
> может
> пометить, что
> новую представленную ошибку надо переправить на foo@example.com.
> Смотрите в документации разработчика тему Запись, которую вы отправили
> в сообщении об ошибке.
Нет.
> Не поняла в какой документации разработчика - в пакете, где они
> сообщают, куда направлять баг или документация на данном сайте?
> Скопиров
> ала для чтения только текст, а если здесь стоит ссылка на другую
> страницу этого сайта, то она не скопировалась, отсюда и вопрос. Плюс в
> каждом пакете разработчики пишут - куда надо направлять информацию об
> ошибках.
>
> Вот это не поняла "....Запись, которую вы отправили в
> сообщении об ошибке". Запись чего - само описание проблемы, суть
> вопроса, описание внутри сообщения?
Тут опять неправильно.
Сделал: Запись о том, что сообщение об ошибке было перенаправлено
В Bugs/Developer тоже исправлю.
> И ещё - вот такая смесь на одной странице создаёт запутанность-
> Смотрит
> е выше описывался пакет "hello", то есть был конкретный пример. А чуть
> далее отошли в абстракцию... Разумно было бы, чтобы на этой странице,
> от начала и до конца отслеживался один пакет и все описания были к нему
> привязанные.
>
> А иначе вот сейчас читает пользователь эту страницу, дошёл
> до этих примеров и встал в тупике - где брать эти данные?
> foo@example.c
> om
> foopackage
>
> Почему вместо "foopackage" не написать "hello"?
> Понятно, что
> если он остановится, задумается, "почешет репу", то конечно рано или
> поздно сообразит что к чему, но ведь эта страничка создавалась, чтобы
> облегчить эту работу, а в результете, получается головоломка, которую
> не каждый будет разгадывать...
Тут уже другой раздел, это не разбор предыдущего примера. Пусть будет,
как есть.
> Объявление владельца
>
> Owner: foo@example.com
> показывает, что
> foo@example.com теперь ответственный за исправление этой ошибки.
> Смотрите в документации разработчика Смена владельца ошибки.
>
>
> Реплика -то
> есть отправитель бага определяет, кто является теперь ответственным за
> исправление ошибки??
> "Смена владельца ошибки" ещё не читала, подозреваю,
> что страница на английском.
Эти метки используются не только при отправке сообщений об ошибках, но и
вообще при работе с сообщениями об ошибках.
> эквивалентно Package: для ошибок, присутствующих в исходном
> пакете пакета foopackage. Для большинства ошибок в большинстве пакетов
> вам не понадобится эта опция.
>
> может
> эквивалентно Package: для ошибок,
> присутствующих в исходном пакете пакета foopackage. Для большинства
> ошибок в большинстве пакетов вам не понадобится эта опция.
>
> "пакете
> пакета" - это желательно как-то изменить, а то получается "масло-
> масляно".
Сделал: для ошибок, присутствующих в пакете с исходным кодом, из
которого создаётся пакет foopackage
> Команды управления
>
> Control:
> control commands
> Позволяет работать любой команде, которая должна быть
> отправлена на адрес control@bugs.debian.org, если она отправлена на
> адрес submit@bugs.debian.org или nnn@bugs.debian.org. -1 изначально
> указывает на текущую ошибку (то есть, ошибку, созданную письмом на
> submit@, или ошибку, отправленную с nnn@). Пожалуйста, посмотрите
> документацию по серверу управления для получения дополнительной
> информации по применяемым управляющим командам.
>
> Не лучше ли назвать
> "Управляющие команды", ведь далее пишут "для получения дополнительной
> информации по применяемым управляющим командам." - чтобы было
> одинаковое название и там и здесь и в той странице - куда отправляют за
> дополнительной информацией
Хорошо, пусть будут "управляющие команды".
> Например, следующий псевдозаголовок в сообщении, отправленном на
> адрес 12345@bugs.debian.org:
>
> Control: retitle -1 this is the title
> Contro
> l: severity -1 normal
> Control: summary -1 0
> Control: forward -1
> https://bugs.debian.org/nnn
> привел бы к переименованию ошибки 12345,
> изменению её важности, установке резюме и пометке её как пересланной.
>
> мо
> жет - так мысль не разрывается, а после двоеточия поясняется
>
> Например,
> следующий псевдозаголовок в сообщении, отправленном на адрес
> 12345@bugs.debian.org:
> привел бы к переименованию ошибки 12345,
> изменению её важности, установке резюме и пометке её как пересланной:
>
> Co
> ntrol: retitle -1 this is the title
> Control: severity -1 normal
> Control:
> summary -1 0
> Control: forward -1 https://bugs.debian.org/nnn
Нет.
> Наконец, если ваш ПОЧТОВЫЙ
> КЛИЕНТ не позволяет вам редактировать заголовки, вы можете установить
> сколько угодно заголовков X-Debbugs- в псевдо-заголовках.
>
> может
> Наконец в
> случае, если ваш ПОЧТОВЫЙ КЛИЕНТ не позволяет вам редактировать
> заголовки, вы можете установить сколько угодно заголовков X-Debbugs- в
> псевдо-заголовках.
ОК.
> Другие адреса
> отправки сообщений (маловажные или многочисленные ошибки)
>
> может
> Другие
> адреса отправки сообщений (небольшие или многочисленные ошибки)
>
> Смотрела
> minor by grep в
> packaging-tutorial_0.21_from_SID_В 2017 году перевёл
> все Лев Ламберов/ru.po-4312-#. type: itemize
> packaging-
> tutorial_0.21_from_SID_В 2017 году перевёл все Лев Ламберов/ru.po-4313-
> #: packaging-tutorial.tex:1815
> packaging-tutorial_0.21_from_SID_В 2017
> году перевёл все Лев Ламберов/ru.po:4314:msgid "It fixes a few minor
> problems using patches"
> packaging-tutorial_0.21_from_SID_В 2017 году
> перевёл все Лев Ламберов/ru.po-4315-msgstr "Это исправит несколько
> небольших проблем при использовании заплат"
В packaging-tutorial немного о другом.
> Если ошибка маловажная, например, опечатка в документации
> или тривиальная проблема сборки, пожалуйста, задайте уровень важности
> minor и отправьте сообщение по адресу maintonly@bugs.debian.org, а не
> submit@bugs.debian.org. maintonly перешлёт сообщение только
> сопровождающему пакета, не отправляя его в списки рассылки BTS.
>
> может
> Есл
> и ошибка небольшая, к примеру опечатка в документации или
> незначительная проблема сборки, пожалуйста, задайте уровень важности
> minor и отправьте сообщение по адресу maintonly@bugs.debian.org, а не
> submit@bugs.debian.org. Maintonly перешлёт сообщение только
> сопровождающему пакета, не отправляя его в списки рассылки BTS.
>
> Перевод
> слова trivial есть много значений, заимствованное слово "тривиальный"
> практически не применяется в русской литературе (в том числе
> технической). Скорее оно употребляется в сопроводительной документации
> к ящикам с оборудованием, а уж кто и как переведёт эту сопроводительную
> документацию...
> Есть ведь нормальные русские слова - обычный, банальный,
> незначительный и тд
Ладно, пусть будет "незначительный".
> Если вы хотите отправить
> в систему отслеживания ошибок сообщение об ошибке, которое уже
> отправлено сопровождающему, вы можете использовать адрес
> quiet@bugs.debian.org.
>
> может
> Если вы хотите отправить в систему
> отслеживания ошибок сообщение об ошибке, которое ранее уже отправили
> сопровождающему, вы можете использовать адрес quiet@bugs.debian.org.
ОК.
> Если вы используете эти адреса отправки
> сообщений, система отслеживания ошибок установит поле Reply-To всех
> пересылаемых сообщений так, чтобы ответы по умолчанию обрабатывались
> так же, как исходное сообщение.
>
> может
> Если вы используете эти адреса для
> отправки сообщений, система отслеживания ошибок установит поле Reply-To
> для всех пересылаемых сообщений таким образом, что ответы по умолчанию
> будут обрабатываться так же, как исходное сообщение.
ОК.
> Это означает, например, что ответы на сообщение,
> отправленное по адресу maintonly, будут посланы по адресу nnn-
> maintonly@bugs.debian.org, а не nnn@bugs.debian.org, если, конечно,
> отвечающий не поменяет адрес вручную.
>
> может
> Приведём пример: ответы на
> сообщение, отправленное по адресу maintonly, будут посланы по адресу
> nnn-maintonly@bugs.debian.org, а не nnn@bugs.debian.org, конечно если
> отвечающий сам не поменяет адрес вручную.
ОК.
> Если вы отправили сообщение о новой ошибке с таким
> заголовком, вам придётся самостоятельно узнать номер ошибки через веб-
> интерфейс.
>
> может
> Если вы отправили сообщение о новой ошибке с таким
> заголовком, то вам придётся самостоятельно узнать номер ошибки через
> веб-интерфейс.
ОК.
> Имейте в
> виду, что этот заголовок не подавляет отправку подтверждений сервером
> control@bugs.debian.org, поскольку эти подтверждения могут содержать
> сообщений об ошибках, которые следует прочесть и действовать в
> соответствии с ними.
>
> подправить
> Имейте в виду, что этот заголовок не
> подавляет отправку подтверждений сервером control@bugs.debian.org,
> поскольку эти подтверждения могут содержать сообщениЯ об ошибках,
> которые следует прочесть и действовать в соответствии с ними.
ОК.
> В системе отслеживания ошибок реализован весьма
> широкий набор правил предназначенных для того, чтобы спам не
> распространялся через BTS.
>
> поставить запятую
> В системе отслеживания
> ошибок реализован весьма широкий набор правил, предназначенных для
> того, чтобы спам не распространялся через BTS.
ОК.
> Другим распространённым случаем непопадания почты в BTS
> является использование адресов, совпадающих с procmail-овскими
> FROM_DAEMON, которые содержат адреса наподобие mail@foobar.com.
>
> может
> Др
> угим распространённым случаем, почему отправленное письмо не попало в
> BTS, является использование отправителем адресов, совпадающих с
> procmail-овскими FROM_DAEMON, которые содержат адреса похожие на
> mail@foobar.com.
Сделал: Другой распространённой причиной того, почему почта не попадает в BTS является
использование отправителем адресов, совпадающих с procmail-овскими FROM_DAEMON, которые
содержат адреса похожие на...
> Когда используете reportbug для сообщения об ошибке в команде
> введите grep.
>
> может
>
> Когда используете reportbug для сообщения об ошибке,
> то в команде введите grep (если вы пишете сообщение об ошибке,
> касающегося данного пакета).
Тут снова неправильно.
Сделал: Когда используете <code>reportbug</code> для сообщения об
ошибке, например в <code>grep</code>, то следующая команда автоматически
выберет правильный пакет и позволит сразу же начать писать сообщение
> Вызываемая M-x debian-bug, она запросит всю необходимую информацию
> подобным reportbug путём.
>
> может
> Вызываемая M-x debian-bug, она запросит
> всю необходимую информацию таким же образом, как это делает reportbug.
ОК.
Уфффффффф... Всё! Ура!
Reply to: