3. Обязанности разработчика Debian

3.1. Обязанности сопровождающего пакетов

As a package maintainer, you're supposed to provide high-quality packages that are well integrated into the system and that adhere to the Debian Policy.

3.1.1. Работа по подготовке следующего стабильного выпуска

Providing high-quality packages in unstable is not enough; most users will only benefit from your packages when they are released as part of the next stable release. You are thus expected to collaborate with the release team to ensure your packages get included.

Более конкретно, вам необходимо отслеживать, мигрировали ли ваши пакеты в тестируемый выпуск (см. Тестируемый выпуск). Если миграция не произошла после периода тестирования, вам следует выяснить, почему так получилось, и поработать над исправлением проблемы. Это может предполагать исправление пакета (в случае критичных для выпуска ошибок или проблем сборки на некоторых архитектурах), но также это может предполагать обновление (или исправление, или удаление из тестируемого выпуска) других пакетов, чтобы помочь в завершении перехода пакетов, в котором ваш пакет застрял из-за своих зависимостей. Команда по выпуску может предоставить вам некоторую информацию о факторах, блокирующих некоторый данный переход пакетов, в случае, если вы сами не можете их определить.

3.1.2. Сопровождение пакетов в стабильном выпуске

Большая часть работы сопровождающего пакетов сводится к загрузке обновлённых версий пакетов в нестабильный выпуск, но также предполагается отслеживание пакетов в текущем стабильном выпуске.

Хотя вносить изменения в стабильный выпуск не рекомендуется, они возможны. Когда сообщается о проблеме безопасности, вам следует совместно с командой безопасности предоставить исправленную версию (см. Работа с ошибками, связанными с безопасностью). Если сообщается об ошибках с важностью important (или более) в стабильной версии вашего пакета, вам следует подумать над предоставлением целевого исправления. Вы можете спросить команду стабильного выпуска о том, примут они такое обновление или нет, и затем уже подготовить загрузку в стабильный выпуск (см. Специальный случай: загрузка в стабильный и предыдущий стабильный выпуски).

3.1.3. Работа с критичными для выпуска ошибками

Обычно вам следует работать с сообщениями об ошибках в ваших пакетах так, как это описано в Работа с ошибками. Тем не менее, имеется специальная категория ошибок, на которые следует обратить внимание — это так называемые критичные для выпуска ошибки (RC ошибки). Все такие сообщения об ошибках, имеющие важность critical, grave или serious, делают пакет неподходящим для включения в следующий стабильный выпуск. Таким образом, они могут задержать выпуск Debian (когда они затрагивают пакет из тестируемого выпуска), либо блокировать миграцию пакетов в тестируемый выпуск (когда они лишь затрагивают пакет из нестабильного выпуска). В худшем сценарии такие ошибки приведут к удалению пакета. Вот почему эти ошибки следует исправить как можно скорее.

Если по какой-либо причине вы не можете исправить критичную для выпуска ошибку в вашем пакете в течении двух недель (например, из-за нехватки времени, либо потому, что её очень сложно исправить), вам следует явно указать это в сообщении об ошибке, также вам следует отметить ошибку тегом help, который используется для привлечения добровольцев. Учтите, что критичные для выпуска ошибки часто исправляются путём обновления и загрузки пакета теми, кто не является сопровождающим (см. Загрузки не-сопровождающим (NMU)), поскольку они блокируют переход многих пакетов в тестируемый выпуск.

Отсутствие внимания к критичным для выпуска ошибкам обычно интерпретируется командой контроля качества как знак того, что сопровождающий прекратил свою работу без корректного придания своему пакету статуса осиротевшего пакета. Команда по поиску пропавших (MIA) может подключиться к работе, что может привести к тому, что ваши пакеты получат статус осиротевших пакетов (см. Работа с неактивными и/или недоступными сопровождающими).

3.1.4. Координация с разработчиками основной ветки

A big part of your job as Debian maintainer will be to stay in contact with the upstream developers. Debian users will sometimes report bugs that are not specific to Debian to our bug tracking system. These bug reports should be forwarded to the upstream developers so that they can be fixed in a future upstream release. Usually it is best if you can do this, but alternatively, you may ask the bug submitter to do it.

Хотя вашей задачей не является исправление ошибок, которые не касаются непосредственно Debian, вы вполне можете это делать, если имеете необходимые знания и навыки. Когда вы вносите такие исправления, обязательно передайте их и сопровождающим основной ветки разработки. Пользователи и разработчики Debian иногда присылают заплаты, исправляющие ошибки основной ветки разработки — вам следует оценить их и переслать в основную ветку разработки.

In cases where a bug report is forwarded upstream, it may be helpful to remember that the bts-link service can help with synchronizing states between the upstream bug tracker and the Debian one.

Если вам необходимо изменить исходный код из основной ветки разработки для того, чтобы собрать пакет, соответствующий правилам, то вам следует предложить своё исправление разработчикам основной ветки, которые может быть включено ими в основную ветку разработки, чтобы вам не пришлось изменять исходный код последующих выпусков основной ветки. Какие бы изменения вы не производили, попытайтесь не создавать ответвлений от основной ветки.

Если вы обнаружите, что разработчики основной ветки враждебны по отношению к Debian или сообществу Свободного ПО, ещё раз подумайте о том, так ли необходимо включать данное ПО в Debian. Иногда социальная стоимость, которую платит сообщество Debian, не покрывается прибылью, которую может принести какое-либо ПО.

3.2. Административные обязанности

Проект, имеющий размеры, сопоставимые с Debian, полагается на некоторую административную инфраструктуру для того, чтобы всё можно было отследить. Как у члена проекта у вас будут некоторые обязанности, исполнение которых гарантирует, что всё идёт гладко.

3.2.1. Сопровождение вашей связанной с Debian информации

База данных LDAP, содержащая информацию о разработчиках Debian, расположена по адресу https://db.debian.org/. Вам следует ввести информацию о себе в эту базу данных и обновлять её по мере изменения. В первую очередь, убедитесь, что адрес электронной почты, на который пересылается ваша почта с ящика на debian.org, актуален, также проверьте ваш адрес, на который оформлена подписка на рассылку debian-private, если вы подписаны на неё.

Дополнительную информацию о базе данных см. в База данных разработчиков.

3.2.2. Сопровождение вашего открытого ключа

Be very careful with your private keys. Do not place them on any public servers or multiuser machines, such as the Debian servers (see Машины Debian). Back your keys up; keep a copy offline. Read the documentation that comes with your software; read the PGP FAQ and OpenPGP Best Practices.

Вам следует убедиться в том, что ваш ключ не только защищён от кражи, но также и в том, что он не может быть потерян. Создайте и сделайте копию (лучше всего сделать также и бумажную копию) вашего сертификата отзыва ключа; он понадобится в случае потери ключа.

If you add signatures to your public key, or add user identities, you can update the Debian key ring by sending your key to the key server at keyring.debian.org. Updates are processed at least once a month by the debian-keyring package maintainers.

If you need to add a completely new key or remove an old key, you need to get the new key signed by another developer. If the old key is compromised or invalid, you also have to add the revocation certificate. If there is no real reason for a new key, the Keyring Maintainers might reject the new key. Details can be found at https://keyring.debian.org/replacing_keys.html.

Применимы процедуры разворачивания ключа, обсуждаемые в Registering as a Debian member.

You can find a more in-depth discussion of Debian key maintenance in the documentation of the debian-keyring package and the https://keyring.debian.org/ site.

3.2.3. Голосование

Даже несмотря на то, что Проект Debian в действительности не представляет собой демократию, мы используем демократический процесс для выбора лидеров Проекта и утверждения общих решений. Эти процедуры определяются Конституцией Проекта Debian.

Помимо ежегодных выборов лидера Проекта, голосования не проводятся регулярно, и к ним не относятся легкомысленно. Каждое предложение сначала обсуждается в списке рассылки debian-vote@lists.debian.org, требуется некоторое одобрение любого предложения до того, как секретарь Проекта инициирует процедуру голосования.

You don't have to track the pre-vote discussions, as the secretary will issue several calls for votes on debian-devel-announce@lists.debian.org (and all developers are expected to be subscribed to that list). Democracy doesn't work well if people don't take part in the vote, which is why we encourage all developers to vote. Voting is conducted via OpenPGP-signed/encrypted email messages.

Список всех предложений (прошлых и текущих) доступен на странице Информации о голосованиях Debian, там же доступна информация о том, как выдвинуть, поддержать и проголосовать по поводу предложения.

3.2.4. Вежливый уход в отпуск

Разработчики могут отсутствовать, это нормально, это может быть запланированный отпуск, либо они могут быть загружены другой работой. Важно, чтобы остальные разработчики знали о том, что вы находитесь в отпуске, чтобы они могли сделать то, что нужно, если возникнут проблемы в ваших пакетах, либо от вас требуется выполнение каких-либо других обязанностей в Проекте.

Обычно это означает, что другие разработчики могут осуществлять загрузки, не будучи сопровождающими (см. Загрузки не-сопровождающим (NMU)), в случае если во время вашего отсутствия возникнет какая-либо большая проблема (критичная для выпуска ошибка, обновление безопасности и т. д.). Иногда ничего критичного не происходит, но всё равно лучше предупредить остальных о том, что вы будете недоступны.

Для того, чтобы проинформировать других разработчиков, вам следует сделать две вещи. Во-первых, отправьте сообщение по адресу debian-private@lists.debian.org с [VAC] в начале темы сообщения [1], в сообщении укажите промежуток времени, когда вы будете находиться в отпуске. Вы также можете указать какие-либо специальные инструкции по поводу того, что нужно предпринять в случае, если возникнет проблема.

Далее, следует отметить себя как находящегося в отпуске в База данных разработчиков (эта информация доступна только разработчикам Debian). Не забудьте удалить флаг статуса «в отпуске» по своему возвращению!

Ideally, you should sign up at the OpenPGP coordination pages when booking a holiday and check if anyone there is looking for signing. This is especially important when people go to exotic places where we don't have any developers yet but where there are people who are interested in applying.

3.2.5. Уход в отставку

Если вы решили покинуть Проект Debian, вам следует убедиться, что вы выполнили следующие шаги:

  • Orphan all your packages, as described in Придание статуса осиротевшего пакета.

  • Remove yourself from uploaders for co- or team-maintained packages.

  • Если вы получали сообщения через алиас @debian.org (напр. press@debian.org) и хотите удалить свой адрес из рассылки, откройте билет RT для системных администраторов Debian. Просто отправьте сообщение на адрес admin@rt.debian.org со словами "Debian RT" где-нибудь в теме сообщения, в сообщении укажите, от каких алиасов вы более не хотите получать сообщения.

  • Please remember to also retire from teams, e.g. remove yourself from team wiki pages or salsa groups.

  • Use the link https://nm.debian.org/process/emeritus to log in to nm.debian.org, request emeritus status and write a goodbye message that will be automatically posted on debian-private.

    Authentication to the NM site requires an SSO browser certificate. You can generate them on https://sso.debian.org.

    In the case you run into problems opening the retirement process yourself, contact NM front desk using nm@debian.org

Важно, чтобы весь приведённый выше процесс был соблюдён, поскольку поиск неактивных разработчиком и пометка их пакетов как осиротевших занимает значительное количество времени и требует усилий.

3.2.6. Возвращение после ухода

A retired developer's account is marked as "emeritus" when the process in Уход в отставку is followed, and "removed" otherwise. Retired developers with an "emeritus" account can get their account re-activated as follows:

  • Get access to an salsa account (either by remembering the credentials for your old guest account or by requesting a new one as described at SSO Debian wiki page.

  • Mail nm@debian.org for further instructions.

  • Пройдите через укороченную процедуру получения статуса нового члена (это необходимо для того, чтобы убедиться, что возвращающийся разработчик всё ещё помнит важные части P&P и T&S).

Retired developers with a "removed" account need to go through full NM again.