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

Содержание

3.1. Обязанности сопровождающего пакетов
3.1.1. Работа по подготовке следующего стабильного выпуска
3.1.2. Сопровождение пакетов в стабильном выпуске
3.1.3. Работа с критичными для выпуска ошибками
3.1.4. Координация с разработчиками основной ветки
3.2. Административные обязанности
3.2.1. Сопровождение вашей связанной с Debian информации
3.2.2. Сопровождение вашего открытого ключа
3.2.3. Голосование
3.2.4. Вежливый уход в отпуск
3.2.5. Уход в отставку
3.2.6. Возвращение после ухода

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.

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.

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

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

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

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

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

Отсутствие внимания к критичным для выпуска ошибкам обычно интерпретируется командой контроля качества как знак того, что сопровождающий прекратил свою работу без корректного придания своему пакету статуса осиротевшего пакета. Команда по поиску пропавших (MIA) может подключиться к работе, что может привести к тому, что ваши пакеты получат статус осиротевших пакетов (см. раздел 7.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, не покрывается прибылью, которую может принести какое-либо ПО.

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

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

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

Be very careful with your private keys. Do not place them on any public servers or multiuser machines, such as the Debian servers (see Раздел 4.4, «Машины 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.

Если вам необходимо добавить абсолютно новый ключ или удалить старый, вам следует получить подпись на новом ключе от другого разработчика. Если старый ключ скомпрометирован, либо недействителен, вам также следует добавить сертификат отзыва ключа. Если реальных причин для создания нового ключа нет, сопровождающие брелока могут отклонить новый ключ. Подробности могут найдены по адресу http://keyring.debian.org/replacing_keys.html.

Применимы процедуры разворачивания ключа, обсуждаемые в разделе 2.3, «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 http://keyring.debian.org/ site.

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

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

Вам не нужно отслеживать предваряющие голосование обсуждения, поскольку секретарь опубликует несколько требований голосования в списке рассылки (все разработчики должны быть подписаны на этот список рассылки). Демократия не работает, если люди не принимают участия в голосовании, поэтому мы просим разработчиков голосовать. Голосование происходит при помощи GPG-подписанных/зашифрованных сообщений электронной почты.

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

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

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

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

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

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

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

  1. Придайте всем ваши пакетам статус осиротевших пакетов как это описано в разделе 5.9.4, «Придание статуса осиротевшего пакета».

  2. Вышлите подписанное с помощью gpg электронное письмо о том, что вы хотите покинуть Проект, по адресу .

  3. Notify the Debian key ring maintainers that you are leaving by opening a ticket in Debian RT by sending a mail to with the words "Debian RT" somewhere in the subject line (case doesn't matter).

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

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

Учётная запись разработчика получает отметку «emeritus» в случае, если выход в отставку выполнен в соответствии с разделом 3.2.5, «Уход в отставку», и «disabled» в противном случае. Вышедшие в отставку разработчики, имеющие учётную запись с отметкой «emeritus», могут заново активировать свою учётную запись следующим образом:

  • Свяжитесь с .

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

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

Прошлые разработчики, учётные записи которых были «отключены», должны заново проходить через процесс NM.



[2] Это нужно для того, чтобы те, кто не хочет читать сообщения об отпусках, могли отфильтровать такие сообщения.