developers-reference - en to ru translation catalogue (68 entries)

en: Beyond Packaging
ru: Помимо создания пакетов

en: Debian is about a lot more than just packaging software and maintaining those packages. This chapter contains information about ways, often really critical ways, to contribute to Debian beyond simply creating and maintaining packages.
ru: Debian предполагает гораздо больше, чем простое создание пакетов ПО и сопровождение этих пакетов. Данная глава содержит информацию о способах, часто действительно критичных способах, участия в Debian помимо создания и сопровождения пакетов.

en: As a volunteer organization, Debian relies on the discretion of its members in choosing what they want to work on and in choosing the most critical thing to spend their time on.
ru: Будучи добровольной организацией, Debian полагается на благоразумие своих членов в их выборе того, над чем они хотят работать, а также в выборе наиболее критических задач, исходя из своего собственного времени.

en: Bug reporting
ru: Отправка отчётов об ошибках

en: We encourage you to file bugs as you find them in Debian packages. In fact, Debian developers are often the first line testers. Finding and reporting bugs in other developers' packages improves the quality of Debian.
ru: Мы призываем вас сообщать об ошибках в пакетах Debian как только вы найдёте их. Фактически, разработчики Debian зачастую являются тестировщиками первой волны. Обнаружение ошибки и сообщение о ней другим разработчикам пакетов повышает качество Debian.

en: Read the `instructions for reporting bugs <https://www.debian.org/Bugs/Reporting>`__ in the Debian `bug tracking system <https://www.debian.org/Bugs/>`__.
ru: Прочтите `инструкции по отправке отчётов об ошибках <https://www.debian.org/Bugs/Reporting>`__ в `систему отслеживания ошибок <https://www.debian.org/Bugs/>`__ Debian.

en: Try to submit the bug from a normal user account at which you are likely to receive mail, so that people can reach you if they need further information about the bug. Do not submit bugs as root.
ru: Попытайтесь отправить сообщение об ошибке от учётной записи обычного пользователя, на которую вы получаете почту, чтобы люди могли с вами связаться, если им потребуется дополнительная информация об ошибке. Не отправляйте отчёты от учётной записи суперпользователя.

en: You can use a tool like reportbug 1 to submit bugs. It can automate and generally ease the process.
ru: Вы можете использовать инструмент на подобие reportbug 1 для отправки сообщений об ошибках. Это может автоматизировать и в целом упростить процесс.

en: Make sure the bug is not already filed against a package. Each package has a bug list easily reachable at ``https://bugs.debian.org/``\ *packagename*. Utilities like querybts 1 can also provide you with this information (and ``reportbug`` will usually invoke ``querybts`` before sending, too).
ru: Убедитесь, что о данной ошибке в данном пакете ещё не сообщали. Всякий пакет имеет свой список ошибок, доступ к которому можно легко получить, по адресу ``https://bugs.debian.org/``\ *имя-пакета*. Такие утилиты как querybts 1 также могут предоставить вам информацию (``reportbug`` обычно вызывает команду ``querybts`` до отправки отчёта).

en: Try to direct your bugs to the proper location. When for example your bug is about a package which overwrites files from another package, check the bug lists for *both* of those packages in order to avoid filing duplicate bug reports.
ru: Попытайтесь направить ваше сообщение об ошибках туда, где они нужны. Когда, например, ваша ошибка касается пакета, который перезаписывает файлы из другого пакета, проверьте список ошибок, *оба* этих пакета нужны для того, чтобы избежать заполнения дублирующих отчётов об ошибках.

en: For extra credit, you can go through other packages, merging bugs which are reported more than once, or tagging bugs ``fixed`` when they have already been fixed. Note that when you are neither the bug submitter nor the package maintainer, you should not actually close the bug (unless you secure permission from the maintainer).
ru: Для получения дополнительного кредита доверия вы можете просмотреть другие пакеты, сливая сообщения об ошибках, о которых было сообщено несколько раз, либо помечая ошибки как исправленные ``fixed``, если они уже исправлены. Заметьте, что если вы не являетесь ни автором сообщения об ошибке, ни сопровождающим пакета, вам не следует фактически закрывать ошибку (если только вы не получили на это разрешение от сопровождающего).

en: From time to time you may want to check what has been going on with the bug reports that you submitted. Take this opportunity to close those that you can't reproduce anymore. To find out all the bugs you submitted, you just have to visit ``https://bugs.debian.org/from:``\ *your-email-addr*.
ru: Время от времени вам может захотеться проверить, что происходит с отчётами об ошибках, которые вы отправили. Используйте эту возможность, чтобы закрыть те ошибки, которые вы более не можете воспроизвести. Чтобы найти все ошибки, о которых вы отправляли отчёты, вам следует перейти на страницу ``https://bugs.debian.org/from:``\ *ваш-адрес-электронной-почты*.

en: Reporting lots of bugs at once (mass bug filing)
ru: Отправка множества отчётов об ошибках за один раз (массовое заполнение отчётов об ошибках)

en: Reporting a great number of bugs for the same problem on a great number of different packages — i.e., more than 10 — is a deprecated practice. Take all possible steps to avoid submitting bulk bugs at all. For instance, if checking for the problem can be automated, add a new check to ``lintian`` so that an error or warning is emitted.
ru: Сообщение о большом количестве ошибок, связанных с одной и той же проблемой в большом количестве различных пакетов — напр., более 10 — является плохой практикой. Предпримите все возможные шаги, чтобы не допустить отправки массы сообщений об ошибках. Например, если проверка данной проблемы может быть автоматизирована, добавьте новую проверку в ``lintian``, так чтобы выводилось сообщение об ошибке или предупреждение.

en: If you report more than 10 bugs on the same topic at once, it is recommended that you send a message to ``debian-devel@lists.debian.org`` describing your intention before submitting the report, and mentioning the fact in the subject of your mail. This will allow other developers to verify that the bug is a real problem. In addition, it will help prevent a situation in which several maintainers start filing the same bug report simultaneously.
ru: Если вы сообщаете о более чем 10 ошибках на одну и ту же тему за раз, рекомендуется выслать сообщение на адрес ``debian-devel@lists.debian.org`` с описанием вашего намерения до того, как вы вышлете свой отчёт, укажите этот факт в теме сообщения. Это позволит другим разработчикам проверить, что ошибка действительно является проблемой. Кроме того, это позволит избежать ситуации, при которой несколько сопровождающих одновременно начинают заполнять один и тот же отчёт об ошибке.

en: Please use the programs ``dd-list`` and if appropriate ``whodepends`` (from the package ``devscripts``) to generate a list of all affected packages, and include the output in your mail to ``debian-devel@lists.debian.org``.
ru: Пожалуйста, используйте программы ``dd-list`` и, если это подходит, ``whodepends`` (из пакета ``devscripts``) для создания списка всех подверженных данной ошибке пакетов и добавьте вывод этих программ в ваше сообщение по адресу ``debian-devel@lists.debian.org``.

en: Note that when sending lots of bugs on the same subject, you should send the bug report to ``maintonly@bugs.debian.org`` so that the bug report is not forwarded to the bug distribution mailing list.
ru: Заметьте, что когда вы высылаете сразу много сообщений об ошибках на одну и ту же тему, вам следует выслать отчёт об ошибке по адресу ``maintonly@bugs.debian.org``, чтобы ваш отчёт об ошибке не был переслан в список рассылки об ошибках.

en: Usertags
ru: Пользовательские метки

en: You may wish to use BTS usertags when submitting bugs across a number of packages. Usertags are similar to normal tags such as 'patch' and 'wishlist' but differ in that they are user-defined and occupy a namespace that is unique to a particular user. This allows multiple sets of developers to 'usertag' the same bug in different ways without conflicting.
ru: Возможно вам захочется использовать пользовательские метки системы отслеживания ошибок при отправке сообщений об ошибках в нескольких пакетах. Пользовательские метки (usertags) схожи с обычные метками, такими как 'patch' и 'wishlist', но отличаются от них в том, что они определяются пользователями и занимают пространство имён, уникальное для каждого отдельного пользователя. Это позволяет нескольким подмножествам разработчиков отмечать пользовательскими метками одну и ту же ошибку разными способами без возникновения конфликтов.

en: To add usertags when filing bugs, specify the ``User`` and ``Usertags`` pseudo-headers:
ru: Чтобы добавить пользовательские метки при заполнении отчётов об ошибках, укажите псевдозаголовки ``User`` и ``Usertags``:

en: To view bugs tagged with a specific usertag, visit ``https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=``\ *email-addr*\ ``&tag=``\ *tag-name*.
ru: Чтобы просмотреть сообщения об ошибках, помеченные конкретной пользовательской меткой, посетите страницу ``https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=``\ *адрес-электронной-почты*\ ``&tag=``\ *имя-метки*.

en: Quality Assurance effort
ru: Работа по контролю качества

en: Daily work
ru: Ежедневная работа

en: Even though there is a dedicated group of people for Quality Assurance, QA duties are not reserved solely for them. You can participate in this effort by keeping your packages as bug-free as possible, and as lintian-clean (see :ref:`lintian`) as possible. If you do not find that possible, then you should consider orphaning some of your packages (see :ref:`orphaning`). Alternatively, you may ask the help of other people in order to catch up with the backlog of bugs that you have (you can ask for help on ``debian-qa@lists.debian.org`` or ``debian-devel@lists.debian.org``). At the same time, you can look for co-maintainers (see :ref:`collaborative-maint`).
ru: Даже несмотря на то, что у нас имеется выделенная группа людей, которые занимаются контролем качества (Quality Assurance), обязанности по контролю качества не резервируются исключительно за ними. Вы можете принять участие в этой работе, стараясь сделать так, чтобы в ваших пакетах было как можно меньше ошибок, и чтобы ваши пакеты проходили как можно большее количество проверок lintian (см. :ref:`lintian`). Если считаете, что это невозможно, вам, вероятно, следует отказаться (осиротить) некоторые из ваших пакетов (см. :ref:`orphaning`). С другой стороны, вы можете попросить о помощи других людей, чтобы наверстать отставание по количеству исправленных ошибок (вы можете попросить о помощи в списках рассылки ``debian-qa@lists.debian.org`` или ``debian-devel@lists.debian.org``). В то же время вы можете искать помощников сопровождающего (см. :ref:`collaborative-maint`).

en: Bug squashing parties
ru: Вечеринки по исправлению ошибок

en: If you don't feel confident about doing an NMU, just send a patch to the BTS. It's far better than a broken NMU.
ru: Если вы не чувствуете уверенности по поводу NMU, просто вышлите заплату в систему отслеживания ошибок. Это намного лучше, чем сломанная NMU.

en: Contacting other maintainers
ru: Связь с другими сопровождающими

en: During your lifetime within Debian, you will have to contact other maintainers for various reasons. You may want to discuss a new way of cooperating between a set of related packages, or you may simply remind someone that a new upstream version is available and that you need it.
ru: Во время срока вашей деятельности в Debian вам придётся связываться с другими сопровождающими по совершенно разным причинам. Возможно, вы захотите обсудить новый способ взаимодействия между наборами связных пакетов, или просто напомнить кому-то о том, что теперь доступна новая версия основной ветки разработки, и она вам нужна.

en: Looking up the email address of the maintainer for the package can be distracting. Fortunately, there is a simple email alias, *package*\ ``@packages.debian.org``, which provides a way to email the maintainer, whatever their individual email address (or addresses) may be. Replace *package* with the name of a source or a binary package.
ru: Поиск адреса электронной почты сопровождающего пакета может отвлекать. К счастью, существуют простые псевдонимы для электронной почты, *пакет*\ ``@packages.debian.org``, которые предоставляют способ отправки сообщения сопровождающему, каким бы ни был его индивидуальный адрес электронной почты (или адреса). Замените *пакет* на имя пакета с исходным кодом или имя двоичного пакета.

en: You may also be interested in contacting the persons who are subscribed to a given source package via :ref:`pkg-tracker`. You can do so by using the *package*\ ``@packages.qa.debian.org`` email address.
ru: Возможно, вы захотите связаться с теми, кто подписан на данный пакет с исходным кодом через систему отслеживания пакетов (:ref:`pkg-tracker`). Вы можете сделать это, используя адрес электронной почты *пакет*\ ``@packages.qa.debian.org``.

en: Dealing with inactive and/or unreachable maintainers
ru: Работа с неактивными и/или недоступными сопровождающими

en: There is a simple system (the MIA database) in which information about maintainers who are deemed Missing In Action is recorded. When a member of the QA group contacts an inactive maintainer or finds more information about one, this is recorded in the MIA database. This system is available in ``/org/qa.debian.org/mia`` on the host ``qa.debian.org``, and can be queried with the ``mia-query`` tool. Use ``mia-query --help`` to see how to query the database. If you find that no information has been recorded about an inactive maintainer yet, or that you can add more information, you should generally proceed as follows.
ru: Существует простая система (база данных MIA), в которую записывается информация о сопровождающих, которые считаются пропавшими без вести (Missing In Action). Когда член группы QA связывается с неактивным сопровождающим или находит дополнительную информацию о нём, это записывается в базу данных MIA. Эта система доступна в ``/org/qa.debian.org/mia`` на узле ``qa.debian.org`` и может быть запрошена с помощью инструмента ``mia-query``. Используйте ``mia-query --help``, чтобы узнать, как запрашивать базу данных. Если вы обнаружите, что о конкретном неактивном сопровождающем нет никакой информации, что вы можете добавить дополнительную информацию, вам следует действовать следующим образом.

en: The first step is to politely contact the maintainer, and wait a reasonable time for a response. It is quite hard to define reasonable time, but it is important to take into account that real life is sometimes very hectic. One way to handle this would be to send a reminder after two weeks.
ru: В качестве первого шага вежливо свяжитесь с сопровождающим, ждите его ответ разумное количество времени. Определить, какое количество времени является разумным, очень сложно, но важно принимать в расчёт то, что фактическая жизнь иногда может быть очень беспокойной. Например, можно отправить ещё одно напоминание через две недели.

en: If the maintainer doesn't reply within four weeks (a month), one can assume that a response will probably not happen. If that happens, you should investigate further, and try to gather as much useful information about the maintainer in question as possible. This includes:
ru: Если сопровождающий не отвечает в течении четырёх недель (месяца), можно предположить, что он вероятнее всего более не ответит. Если это произошло, вам нужно расследовать дальше и попытаться собрать как можно больше полезной информации о данном сопровождающем. Это предполагает следующее:

en: The ``echelon`` information available through the `developers' LDAP database <https://db.debian.org/>`__, which indicates when the developer last posted to a Debian mailing list. (This includes mails about uploads distributed via the ``debian-devel-changes@lists.debian.org`` list.) Also, remember to check whether the maintainer is marked as on vacation in the database.
ru: ``Эшелон`` информации доступен через `базу данных LDAP разработчиков <https://db.debian.org/>`__, в которой указывается, когда последний раз данный разработчик писал в список рассылки Debian. (База данных содержит информацию о почте по поводу загрузок, распространяемой через список рассылки ``debian-devel-changes@lists.debian.org``.) Кроме того, проверьте, отмечен ли данный сопровождающий в этой базе данных как находящийся в отпуске.

en: The number of packages this maintainer is responsible for, and the condition of those packages. In particular, are there any RC bugs that have been open for ages? Furthermore, how many bugs are there in general? Another important piece of information is whether the packages have been NMUed, and if so, by whom.
ru: Число пакетов, за которые ответственен этот сопровождающий, и состояние этих пакетов. В частности, имеются ли какие-либо критичные для выпуска ошибки, которые остаются открытыми долгое время? Более того, как много вообще ошибок? Другой важной информацией является то, были ли эти пакеты загружены несопровождающим, и если да, то кем.

en: Is there any activity of the maintainer outside of Debian? For example, they might have posted something recently to non-Debian mailing lists or news groups.
ru: Имеется ли какая-либо активность этого сопровождающего за пределами Debian? Например, он может написать что-то в список рассылки, не связанный с Debian, или в какую-нибудь новостную группу.

en: A bit of a problem are packages which were sponsored — the maintainer is not an official Debian developer. The ``echelon`` information is not available for sponsored people, for example, so you need to find and contact the Debian developer who has actually uploaded the package. Given that they signed the package, they're responsible for the upload anyhow, and are likely to know what happened to the person they sponsored.
ru: Некоторой проблемой являются пакеты, которые были поручены — их сопровождающий не является официальным разработчиком Debian. ``Эшелон`` информации не доступен для людей с поручителями, поэтому вам следует найти и связаться с разработчиком Debian, который фактически загрузил этот пакет. Учитывая, что они подписали пакет, они всё равно ответственны за загрузку и должны знать, что случилось с тем, за кого они поручались.

en: It is also allowed to post a query to ``debian-devel@lists.debian.org``, asking if anyone is aware of the whereabouts of the missing maintainer. Please Cc: the person in question.
ru: Также разрешается писать запрос в ``debian-devel@lists.debian.org``, спрашивая о том, знает ли кто-нибудь о том, где находится пропавший сопровождающий. Пожалуйста, вышлите копию письма этому человеку.

en: Once you have gathered all of this, you can contact ``mia@qa.debian.org``. People on this alias will use the information you provide in order to decide how to proceed. For example, they might orphan one or all of the packages of the maintainer. If a package has been NMUed, they might prefer to contact the NMUer before orphaning the package — perhaps the person who has done the NMU is interested in the package.
ru: Когда вы собрали всю эту информацию, вы можете связаться с ``mia@qa.debian.org``. Люди, получающие почту с этого псевдонима, будут использовать предоставленную вами информацию для того, чтобы решить, как действовать дальше. Например, они могут осиротить один или все пакеты данного сопровождающего. Если пакет был загружен несопровождающим, они могут связаться с тем, что осуществил эту загрузку, до того, как осиротят пакет — возможно, человек, который осуществил эту загрузку, заинтересован в этом пакете.

en: One last word: please remember to be polite. We are all volunteers and cannot dedicate all of our time to Debian. Also, you are not aware of the circumstances of the person who is involved. Perhaps they might be seriously ill or might even have died — you do not know who may be on the receiving side. Imagine how a relative will feel if they read the e-mail of the deceased and find a very impolite, angry and accusing message!
ru: Одно последнее слово: пожалуйста, будьте вежливы. Все мы являемся добровольцами, и мы не можем выделать всё наше время Debian. Кроме того, вам не известны обстоятельства, в которых находится этот человек. Возможно, он серьезно болен или даже мог умереть — вы не знаете, кто получает его почту. Представьте, как будут чувствовать себя родные, если они прочтут сообщение, адресованное умершему, и это сообщение будет невежливым, злым или будет содержать обвинения!

en: Interacting with prospective Debian developers
ru: Взаимодействие с будущими разработчиками Debian

en: Debian's success depends on its ability to attract and retain new and talented volunteers. If you are an experienced developer, we recommend that you get involved with the process of bringing in new developers. This section describes how to help new prospective developers.
ru: Успех Debian зависит от его способности привлекать и сохранять новых и талантливых добровольцев. Если вы являетесь опытным разработчиком, мы рекомендуем вам принять участие в процессе привлечения новых разработчиков. Данный раздел описывает то, как помогать новым будущим разработчиками.

en: Sponsoring packages
ru: Поручение пакетов

en: Debian Developers can sponsor packages. Debian Maintainers can't.
ru: Разработчики Debian могут выступать поручителями для пакетов. Сопровождающие Debian не могут.

en: The process of sponsoring a package is:
ru: Процесс поручения пакета таков:

en: The sponsor reviews the source package. If they find issues, they inform the maintainer and ask them to provide a fixed version (the process starts over at step 1).
ru: Поручитель проверяет пакет с исходным кодом. Если будут найдены какие-либо проблемы, он информируем об этом сопровождающего и просит его предоставить исправленную версию (процесс начинается снова с шага 1).

en: The sponsor could not find any remaining problem. They build the package, sign it, and upload it to Debian.
ru: Поручитель не нашёл каких-либо оставшихся проблем. Он собирает пакет, подписывает его и загружает пакет в Debian.

en: You should also ensure that the prospective maintainer is going to be a good maintainer. Do they already have some experience with other packages? If yes, are they doing a good job with them (check out some bugs)? Are they familiar with the package and its programming language? Do they have the skills needed for this package? If not, are they able to learn them?
ru: Кроме того, вам следует убедиться, что предполагаемый сопровождающий будет хорошим сопровождающим. Имеет ли он какой-либо опыт работы с другими пакетами? Если да, то хорошо ли он с ними работал (проверьте несколько ошибок)? Знаком ли он с пакетом и языком программирования, на котором написана программа? Имеет ли он требуемые для данного пакета навыки? Если нет, то способен ли он ими овладеть?

en: Sponsoring a new package
ru: Поручительство нового пакета

en: Don't ever sponsor a new package without reviewing it. The review of new packages done by ftpmasters mainly ensures that the software is really free. Of course, it happens that they stumble on packaging problems but they really should not. It's your task to ensure that the uploaded package complies with the Debian Free Software Guidelines and is of good quality.
ru: Никогда не поручайтесь за новый пакет, если вы его не изучили. Изучение новых пакетов осуществляется сопровождающими FTP-архива, это гарантирует, что ПО действительно является свободным. Конечно, иногда они обнаруживают проблемы создания пакета, но вообще они не должны этим заниматься. Это ваша задача, вы должны гарантировать, что загружаемый пакет соответствует Критериям Debian по определению Свободного ПО, и что он создан качественно.

en: Building the package and testing the software is part of the review, but it's also not enough. The rest of this section contains a non-exhaustive list of points to check in your review.  [1]_
ru: Сборка пакета и тестирование ПО являются частью исследования пакета, но этого не достаточно. Оставшаяся часть данного раздела содержит неполный список того, на что необходимо обратить внимание.  [1]_

en: Verify that the upstream tarball provided is the same that has been distributed by the upstream author (when the sources are repackaged for Debian, generate the modified tarball yourself).
ru: Убедитесь, что включённый в пакет tarball-архив, не отличается от архива, распространяемого автором основной ветки разработки (если архив с исходным кодом для Debian был создан заново, создайте изменённый tarball-архив самостоятельно).

en: Run ``licensecheck`` (part of :ref:`devscripts`) and verify that ``debian/copyright`` seems correct and complete. Look for license problems (like files with “All rights reserved” headers, or with a non-DFSG compliant license). ``grep -ri`` is your friend for this task.
ru: Запустите ``licensecheck`` (часть :ref:`devscripts`) и убедитесь, что файл ``debian/copyright`` корректен и полон. Проверьте проблемы с лицензиями (напр., файлы с заголовками “All rights reserved”, либо распространяемые под несовместимой с Критериями Debian лицензией). Команда ``grep -ri`` поможет вам в решении этой задачи.

en: Build the package with ``pbuilder`` (or any similar tool, see :ref:`pbuilder`) to ensure that the build-dependencies are complete.
ru: Соберите пакет с помощью ``pbuilder`` (или любого другого схожего инструмента, см. :ref:`pbuilder`) для того, чтобы гарантировать, что сборочные зависимости полны.

en: Proofread ``debian/control``: does it follow the best practices (see :ref:`bpp-debian-control`)? Are the dependencies complete?
ru: Проверьте ``debian/control``: подготовлен ли он в соответствии с лучшими практиками (см. :ref:`bpp-debian-control`)? Полны ли зависимости?

en: Proofread ``debian/rules``: does it follow the best practices (see :ref:`bpp-debian-rules`)? Do you see some possible improvements?
ru: Проверьте ``debian/rules``: подготовлен ли он в соответствии с лучшими практиками (см. :ref:`bpp-debian-rules`)? Можно ли что-либо улучшить?

en: Proofread the maintainer scripts (``preinst``, ``postinst``, ``prerm``, ``postrm``, ``config``): will the ``preinst``/``postrm`` work when the dependencies are not installed? Are all the scripts idempotent (i.e. can you run them multiple times without consequences)?
ru: Проверьте сценарии сопровождающего (``preinst``, ``postinst``, ``prerm``, ``postrm``, ``config``): будет ли ``preinst``/``postrm`` работать в том случае, если зависимости не установлены? Все ли сценарии идемпотентны (т. е., можете ли вы запустить их несколько раз без каких-либо последствий)?

en: Review any change to upstream files (either in ``.diff.gz``, or in ``debian/patches/`` or directly embedded in the ``debian`` tarball for binary files). Are they justified? Are they properly documented (with `DEP-3 <https://dep-team.pages.debian.net/deps/dep3/>`__ for patches)?
ru: Проверьте изменения в файлах из основной ветки разработки (либо в ``.diff.gz``, либо в ``debian/patches/``, либо в самом встроенном tarball-архиве ``debian`` для двоичных файлов). Обоснованы ли эти изменения? Правильно ли они документированы (с `DEP-3 <https://dep-team.pages.debian.net/deps/dep3/>`__ для заплат)?

en: For every file, ask yourself why the file is there and whether it's the right way to achieve the desired result. Is the maintainer following the best packaging practices (see :ref:`best-pkging-practices`)?
ru: Относительно каждого файла задайте себе вопрос о том, почему этот файл находится здесь, правильно достигнут желаемый результат. Следует ли сопровождающий лучшим практикам (см. :ref:`best-pkging-practices`)?

en: If you use ``debuild`` and ``debsign``, you can even configure it permanently in ``~/.devscripts``:
ru: Если вы используете ``debuild`` и ``debsign``, вы даже можете создать постоянную настройку в файле ``~/.devscripts``:

en: Sponsoring an update of an existing package
ru: Поручение обновления существующего пакета

en: If you compare the source packages (excluding upstream files in the case of a new upstream version, for example by filtering the output of ``debdiff`` with ``filterdiff -i '*/debian/*'``), you must understand all the changes you see and they should be properly documented in the Debian changelog.
ru: Если вы сравниваете пакеты с исходным кодом (исключая файлы из основной ветки разработки в случае новой версии из основной ветки разработки, например, фильтруя вывод команды ``debdiff`` с помощью ``filterdiff -i '*/debian/*'``), вам следует понять все изменения, которые вы видите, и они должны быть соответствующим образом документированы в журнале изменений Debian.

en: If you have found no major problem, upload the new version. Otherwise ask the maintainer to provide you a fixed version.
ru: Если вы не нашли серьёзных проблем, загрузите новую версию. В противном случае попросите сопровождающего предоставить вам исправленную версию.

en: Advocating new developers
ru: Поддержка новых разработчиков

en: See the page about `advocating a prospective developer <https://www.debian.org/devel/join/nm-advocate>`__ at the Debian web site.
ru: Смотрите страницу о `поддержке будущих разработчиков <https://www.debian.org/devel/join/nm-advocate>`__ на веб-сайте Debian.

en: Handling new maintainer applications
ru: Обработка заявок новых сопровождающих

en: Please see `Checklist for Application Managers <https://www.debian.org/devel/join/nm-amchecklist>`__ at the Debian web site.
ru: Пожалуйста, посмотрите `Перечень для менеджеров заявок <https://www.debian.org/devel/join/nm-amchecklist>`__ на веб-сайте Debian.
