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

en: Debian Developer's Duties
ru: Обязанности разработчика Debian

en: Package Maintainer's Duties
ru: Обязанности сопровождающего пакетов

en: Work towards the next ``stable`` release
ru: Работа по подготовке следующего ``стабильного`` выпуска

en: More concretely, you should monitor whether your packages are migrating to ``testing`` (see :ref:`testing`). When the migration doesn't happen after the test period, you should analyze why and work towards fixing this. It might mean fixing your package (in the case of release-critical bugs or failures to build on some architecture) but it can also mean updating (or fixing, or removing from ``testing``) other packages to help complete a transition in which your package is entangled due to its dependencies. The release team might provide you some input on the current blockers of a given transition if you are not able to identify them.
ru: Более конкретно, вам необходимо отслеживать, мигрировали ли ваши пакеты в ``тестируемый`` выпуск (см. :ref:`testing`). Если миграция не произошла после периода тестирования, вам следует выяснить, почему так получилось, и поработать над исправлением проблемы. Это может предполагать исправление пакета (в случае критичных для выпуска ошибок или проблем сборки на некоторых архитектурах), но также это может предполагать обновление (или исправление, или удаление из ``тестируемого`` выпуска) других пакетов, чтобы помочь в завершении перехода пакетов, в котором ваш пакет застрял из-за своих зависимостей. Команда по выпуску может предоставить вам некоторую информацию о факторах, блокирующих некоторый данный переход пакетов, в случае, если вы сами не можете их определить.

en: Maintain packages in ``stable``
ru: Сопровождение пакетов в ``стабильном`` выпуске

en: Most of the package maintainer's work goes into providing updated versions of packages in ``unstable``, but their job also entails taking care of the packages in the current ``stable`` release.
ru: Большая часть работы сопровождающего пакетов сводится к загрузке обновлённых версий пакетов в ``нестабильный`` выпуск, но также предполагается отслеживание пакетов в текущем ``стабильном`` выпуске.

en: While changes in ``stable`` are discouraged, they are possible. Whenever a security problem is reported, you should collaborate with the security team to provide a fixed version (see :ref:`bug-security`). When bugs of severity important (or more) are reported against the ``stable`` version of your packages, you should consider providing a targeted fix. You can ask the ``stable`` release team whether they would accept such an update and then prepare a ``stable`` upload (see :ref:`upload-stable`).
ru: Хотя вносить изменения в ``стабильный`` выпуск не рекомендуется, они возможны. Когда сообщается о проблеме безопасности, вам следует совместно с командой безопасности предоставить исправленную версию (см. :ref:`bug-security`). Если сообщается об ошибках с важностью important (или более) в ``стабильной`` версии вашего пакета, вам следует подумать над предоставлением целевого исправления. Вы можете спросить команду ``стабильного`` выпуска о том, примут они такое обновление или нет, и затем уже подготовить загрузку в ``стабильный`` выпуск (см. :ref:`upload-stable`).

en: Manage release-critical bugs
ru: Работа с критичными для выпуска ошибками

en: Generally you should deal with bug reports on your packages as described in :ref:`bug-handling`. However, there's a special category of bugs that you need to take care of — the so-called release-critical bugs (RC bugs). All bug reports that have severity ``critical``, ``grave`` or ``serious`` make the package unsuitable for inclusion in the next ``stable`` release. They can thus delay the Debian release (when they affect a package in ``testing``) or block migrations to ``testing`` (when they only affect the package in ``unstable``). In the worst scenario, they will lead to the package's removal. That's why these bugs need to be corrected as quickly as possible.
ru: Обычно вам следует работать с сообщениями об ошибках в ваших пакетах так, как это описано в :ref:`bug-handling`. Тем не менее, имеется специальная категория ошибок, на которые следует обратить внимание — это так называемые критичные для выпуска ошибки (RC ошибки). Все такие сообщения об ошибках, имеющие важность ``critical``, ``grave`` или ``serious``, делают пакет неподходящим для включения в следующий ``стабильный`` выпуск. Таким образом, они могут задержать выпуск Debian (когда они затрагивают пакет из ``тестируемого`` выпуска), либо блокировать миграцию пакетов в ``тестируемый`` выпуск (когда они лишь затрагивают пакет из ``нестабильного`` выпуска). В худшем сценарии такие ошибки приведут к удалению пакета. Вот почему эти ошибки следует исправить как можно скорее.

en: If, for any reason, you aren't able fix an RC bug in a package of yours within 2 weeks (for example due to time constraints, or because it's difficult to fix), you should mention it clearly in the bug report and you should tag the bug ``help`` to invite other volunteers to chime in. Be aware that RC bugs are frequently the targets of Non-Maintainer Uploads (see :ref:`nmu`) because they can block the ``testing`` migration of many packages.
ru: Если по какой-либо причине вы не можете исправить критичную для выпуска ошибку в вашем пакете в течении двух недель (например, из-за нехватки времени, либо потому, что её очень сложно исправить), вам следует явно указать это в сообщении об ошибке, также вам следует отметить ошибку тегом ``help``, который используется для привлечения добровольцев. Учтите, что критичные для выпуска ошибки часто исправляются путём обновления и загрузки пакета теми, кто не является сопровождающим (см. :ref:`nmu`), поскольку они блокируют переход многих пакетов в ``тестируемый`` выпуск.

en: Lack of attention to RC bugs is often interpreted by the QA team as a sign that the maintainer has disappeared without properly orphaning their package. The MIA team might also get involved, which could result in your packages being orphaned (see :ref:`mia-qa`).
ru: Отсутствие внимания к критичным для выпуска ошибкам обычно интерпретируется командой контроля качества как знак того, что сопровождающий прекратил свою работу без корректного придания своему пакету статуса осиротевшего пакета. Команда по поиску пропавших (MIA) может подключиться к работе, что может привести к тому, что ваши пакеты получат статус осиротевших пакетов (см. :ref:`mia-qa`).

en: Coordination with upstream developers
ru: Координация с разработчиками основной ветки

en: While it's not your job to fix non-Debian specific bugs, you may freely do so if you're able. When you make such fixes, be sure to pass them on to the upstream maintainers as well. Debian users and developers will sometimes submit patches to fix upstream bugs — you should evaluate and forward these patches upstream.
ru: Хотя вашей задачей не является исправление ошибок, которые не касаются непосредственно Debian, вы вполне можете это делать, если имеете необходимые знания и навыки. Когда вы вносите такие исправления, обязательно передайте их и сопровождающим основной ветки разработки. Пользователи и разработчики Debian иногда присылают заплаты, исправляющие ошибки основной ветки разработки — вам следует оценить их и переслать в основную ветку разработки.

en: If you need to modify the upstream sources in order to build a policy compliant package, then you should propose a nice fix to the upstream developers which can be included there, so that you won't have to modify the sources of the next upstream version. Whatever changes you need, always try not to fork from the upstream sources.
ru: Если вам необходимо изменить исходный код из основной ветки разработки для того, чтобы собрать пакет, соответствующий правилам, то вам следует предложить своё исправление разработчикам основной ветки, которые может быть включено ими в основную ветку разработки, чтобы вам не пришлось изменять исходный код последующих выпусков основной ветки. Какие бы изменения вы не производили, попытайтесь не создавать ответвлений от основной ветки.

en: If you find that the upstream developers are or become hostile towards Debian or the free software community, you may want to re-consider the need to include the software in Debian. Sometimes the social cost to the Debian community is not worth the benefits the software may bring.
ru: Если вы обнаружите, что разработчики основной ветки враждебны по отношению к Debian или сообществу Свободного ПО, ещё раз подумайте о том, так ли необходимо включать данное ПО в Debian. Иногда социальная стоимость, которую платит сообщество Debian, не покрывается прибылью, которую может принести какое-либо ПО.

en: Administrative Duties
ru: Административные обязанности

en: A project of the size of Debian relies on some administrative infrastructure to keep track of everything. As a project member, you have some duties to ensure everything keeps running smoothly.
ru: Проект, имеющий размеры, сопоставимые с Debian, полагается на некоторую административную инфраструктуру для того, чтобы всё можно было отследить. Как у члена проекта у вас будут некоторые обязанности, исполнение которых гарантирует, что всё идёт гладко.

en: Maintaining your Debian information
ru: Сопровождение вашей связанной с Debian информации

en: There's a LDAP database containing information about Debian developers at https://db.debian.org/\ . You should enter your information there and update it as it changes. Most notably, make sure that the address where your debian.org email gets forwarded to is always up to date, as well as the address where you get your debian-private subscription if you choose to subscribe there.
ru: База данных LDAP, содержащая информацию о разработчиках Debian, расположена по адресу https://db.debian.org/\ . Вам следует ввести информацию о себе в эту базу данных и обновлять её по мере изменения. В первую очередь, убедитесь, что адрес электронной почты, на который пересылается ваша почта с ящика на debian.org, актуален, также проверьте ваш адрес, на который оформлена подписка на рассылку debian-private, если вы подписаны на неё.

en: For more information about the database, please see :ref:`devel-db`.
ru: Дополнительную информацию о базе данных см. в :ref:`devel-db`.

en: Maintaining your public key
ru: Сопровождение вашего открытого ключа

en: You need to ensure not only that your key is secure against being stolen, but also that it is secure against being lost. Generate and make a copy (best also in paper form) of your revocation certificate; this is needed if your key is lost.
ru: Вам следует убедиться в том, что ваш ключ не только защищён от кражи, но также и в том, что он не может быть потерян. Создайте и сделайте копию (лучше всего сделать также и бумажную копию) вашего сертификата отзыва ключа; он понадобится в случае потери ключа.

en: The same key extraction routines discussed in :ref:`registering` apply.
ru: Применимы процедуры разворачивания ключа, обсуждаемые в :ref:`registering`.

en: Voting
ru: Голосование

en: Even though Debian isn't really a democracy, we use a democratic process to elect our leaders and to approve general resolutions. These procedures are defined by the `Debian Constitution <https://www.debian.org/devel/constitution>`__.
ru: Даже несмотря на то, что Проект Debian в действительности не представляет собой демократию, мы используем демократический процесс для выбора лидеров Проекта и утверждения общих решений. Эти процедуры определяются `Конституцией Проекта Debian <https://www.debian.org/devel/constitution>`__.

en: Other than the yearly leader election, votes are not routinely held, and they are not undertaken lightly. Each proposal is first discussed on the ``debian-vote@lists.debian.org`` mailing list and it requires several endorsements before the project secretary starts the voting procedure.
ru: Помимо ежегодных выборов лидера Проекта, голосования не проводятся регулярно, и к ним не относятся легкомысленно. Каждое предложение сначала обсуждается в списке рассылки ``debian-vote@lists.debian.org``, требуется некоторое одобрение любого предложения до того, как секретарь Проекта инициирует процедуру голосования.

en: The list of all proposals (past and current) is available on the `Debian Voting Information <https://www.debian.org/vote/>`__ page, along with information on how to make, second and vote on proposals.
ru: Список всех предложений (прошлых и текущих) доступен на странице `Информации о голосованиях Debian <https://www.debian.org/vote/>`__, там же доступна информация о том, как выдвинуть, поддержать и проголосовать по поводу предложения.

en: Going on vacation gracefully
ru: Вежливый уход в отпуск

en: It is common for developers to have periods of absence, whether those are planned vacations or simply being buried in other work. The important thing to notice is that other developers need to know that you're on vacation so that they can do whatever is needed if a problem occurs with your packages or other duties in the project.
ru: Разработчики могут отсутствовать, это нормально, это может быть запланированный отпуск, либо они могут быть загружены другой работой. Важно, чтобы остальные разработчики знали о том, что вы находитесь в отпуске, чтобы они могли сделать то, что нужно, если возникнут проблемы в ваших пакетах, либо от вас требуется выполнение каких-либо других обязанностей в Проекте.

en: Usually this means that other developers are allowed to NMU (see :ref:`nmu`) your package if a big problem (release critical bug, security update, etc.) occurs while you're on vacation. Sometimes it's nothing as critical as that, but it's still appropriate to let others know that you're unavailable.
ru: Обычно это означает, что другие разработчики могут осуществлять загрузки, не будучи сопровождающими (см. :ref:`nmu`), в случае если во время вашего отсутствия возникнет какая-либо большая проблема (критичная для выпуска ошибка, обновление безопасности и т. д.). Иногда ничего критичного не происходит, но всё равно лучше предупредить остальных о том, что вы будете недоступны.

en: In order to inform the other developers, there are two things that you should do. First send a mail to ``debian-private@lists.debian.org`` with [VAC] prepended to the subject of your message [1]_ and state the period of time when you will be on vacation. You can also give some special instructions on what to do if a problem occurs.
ru: Для того, чтобы проинформировать других разработчиков, вам следует сделать две вещи. Во-первых, отправьте сообщение по адресу ``debian-private@lists.debian.org`` с [VAC] в начале темы сообщения [1]_, в сообщении укажите промежуток времени, когда вы будете находиться в отпуске. Вы также можете указать какие-либо специальные инструкции по поводу того, что нужно предпринять в случае, если возникнет проблема.

en: The other thing to do is to mark yourself as on vacation in the :ref:`devel-db` (this information is only accessible to Debian developers). Don't forget to remove the on vacation flag when you come back!
ru: Далее, следует отметить себя как находящегося в отпуске в :ref:`devel-db` (эта информация доступна только разработчикам Debian). Не забудьте удалить флаг статуса «в отпуске» по своему возвращению!

en: Retiring
ru: Уход в отставку

en: If you choose to leave the Debian project, you should make sure you do the following steps:
ru: Если вы решили покинуть Проект Debian, вам следует убедиться, что вы выполнили следующие шаги:

en: If you received mails via a @debian.org e-mail alias (e.g. press@debian.org) and would like to get removed, open a RT ticket for the Debian System Administrators. Just send an e-mail to ``admin@rt.debian.org`` with "Debian RT" somewhere in the subject stating from which aliases you'd like to get removed.
ru: Если вы получали сообщения через алиас @debian.org (напр. press@debian.org) и хотите удалить свой адрес из рассылки, откройте билет RT для системных администраторов Debian. Просто отправьте сообщение на адрес ``admin@rt.debian.org`` со словами "Debian RT" где-нибудь в теме сообщения, в сообщении укажите, от каких алиасов вы более не хотите получать сообщения.

en: It is important that the above process is followed, because finding inactive developers and orphaning their packages takes significant time and effort.
ru: Важно, чтобы весь приведённый выше процесс был соблюдён, поскольку поиск неактивных разработчиком и пометка их пакетов как осиротевших занимает значительное количество времени и требует усилий.

en: Returning after retirement
ru: Возвращение после ухода

en: Go through a shortened NM process (to ensure that the returning developer still knows important parts of P&P and T&S).
ru: Пройдите через укороченную процедуру получения статуса нового члена (это необходимо для того, чтобы убедиться, что возвращающийся разработчик всё ещё помнит важные части P&P и T&S).

en: This is so that the message can be easily filtered by people who don't want to read vacation notices.
ru: Это нужно для того, чтобы те, кто не хочет читать сообщения об отпусках, могли отфильтровать такие сообщения.
