Как сопровождающий пакета вы должны предоставлять пакеты высокого качества, которые хорошо интегрируются в систему и соответствуют Политике Debian.
Предоставление пакетов высокого качества в нестабильный
выпуск
не достаточно, большинство пользователей извлекут пользу из
ваших пакетов в том случае, если они будут выпущены в составе следующего
стабильного
выпуска. Поэтому вам следует
взаимодействовать с командой, курирующей выпуск, чтобы подстраховаться, что
ваши пакеты будут добавлены в выпуск.
Более конкретно, вам необходимо отслеживать, мигрировали ли ваши пакеты в
тестируемый
выпуск (см. раздел 5.13, «Тестируемый выпуск»). Если миграция не
произошла после периода тестирования, вам следует выяснить, почему так
получилось, и поработать над исправлением проблемы. Это может предполагать
исправление пакета (в случае критичных для выпуска ошибок или проблем сборки
на некоторых архитектурах), но также это может предполагать обновление (или
исправление, или удаление из тестируемого
выпуска) других
пакетов, чтобы помочь в завершении перехода пакетов, в котором ваш пакет
застрял из-за своих зависимостей. Команда по выпуску может предоставить вам
некоторую информацию о факторах, блокирующих некоторый данный переход
пакетов, в случае, если вы сами не можете их определить.
Большая часть работы сопровождающего пакетов сводится к загрузке обновлённых
версий пакетов в нестабильный
выпуск, но также
предполагается отслеживание пакетов в текущем стабильном
выпуске.
Хотя вносить изменения в стабильный
выпуск не
рекомендуется, они возможны. Когда сообщается о проблеме безопасности, вам
следует совместно с командой безопасности предоставить исправленную версию
(см. раздел 5.8.5, «Работа с ошибками, связанными с безопасностью»). Если сообщается об ошибках с важностью important (или
более) в стабильной
версии вашего пакета, вам следует
подумать над предоставлением целевого исправления. Вы можете спросить
команду стабильного
выпуска о том, примут они такое
обновление или нет, и затем уже подготовить загрузку в
стабильный
выпуск (см. раздел 5.5.1, «Специальный случай: загрузка в стабильный
и
предыдущий стабильный
выпуски»).
Обычно вам следует работать с сообщениями об ошибках в ваших пакетах так,
как это описано в разделе 5.8, «Работа с ошибками». Тем не менее, имеется специальная категория ошибок,
на которые следует обратить внимание — это так называемые критичные для
выпуска ошибки (RC ошибки). Все такие сообщения об ошибках, имеющие важность
critical
, grave
или
serious
, делают пакет неподходящим для включения в
следующий стабильный
выпуск. Таким образом, они могут
задержать выпуск Debian (когда они затрагивают пакет из
тестируемого
выпуска), либо блокировать миграцию пакетов
в тестируемый
выпуск (когда они лишь затрагивают пакет из
нестабильного
выпуска). В худшем сценарии такие ошибки
приведут к удалению пакета. Вот почему эти ошибки следует исправить как
можно скорее.
Если по какой-либо причине вы не можете исправить критичную для выпуска
ошибку в вашем пакете в течении двух недель (например, из-за нехватки
времени, либо потому, что её очень сложно исправить), вам следует явно
указать это в сообщении об ошибке, также вам следует отметить ошибку тегом
help
, который используется для привлечения
добровольцев. Учтите, что критичные для выпуска ошибки часто исправляются
путём обновления и загрузки пакета теми, кто не является сопровождающим
(см. раздел 5.11, «Загрузки не-сопровождающим (NMU)»),
поскольку они блокируют переход многих пакетов в
тестируемый
выпуск.
Отсутствие внимания к критичным для выпуска ошибкам обычно интерпретируется командой контроля качества как знак того, что сопровождающий прекратил свою работу без корректного придания своему пакету статуса осиротевшего пакета. Команда по поиску пропавших (MIA) может подключиться к работе, что может привести к тому, что ваши пакеты получат статус осиротевших пакетов (см. раздел 7.4, «Работа с неактивными и/или недоступными сопровождающими»).
Большая часть вашей работы в качестве сопровождающего Debian будет состоять во взаимодействии с разработчиками основной ветки. Пользователи Debian иногда будут сообщать об ошибках, которые не касаются непосредственно Debian. Вам следует пересылать эти сообщения об ошибках разработчикам основной ветки, чтоб они могли исправить эти ошибки в последующем выпуске основной ветки разработки.
Хотя вашей задачей не является исправление ошибок, которые не касаются непосредственно Debian, вы вполне можете это делать, если имеете необходимые знания и навыки. Когда вы вносите такие исправления, обязательно передайте их и сопровождающим основной ветки разработки. Пользователи и разработчики Debian иногда присылают заплаты, исправляющие ошибки основной ветки разработки — вам следует оценить их и переслать в основную ветку разработки.
Если вам необходимо изменить исходный код из основной ветки разработки для того, чтобы собрать пакет, соответствующий правилам, то вам следует предложить своё исправление разработчикам основной ветки, которые может быть включено ими в основную ветку разработки, чтобы вам не пришлось изменять исходный код последующих выпусков основной ветки. Какие бы изменения вы не производили, попытайтесь не создавать ответвлений от основной ветки.
Если вы обнаружите, что разработчики основной ветки враждебны по отношению к Debian или сообществу Свободного ПО, ещё раз подумайте о том, так ли необходимо включать данное ПО в Debian. Иногда социальная стоимость, которую платит сообщество Debian, не покрывается прибылью, которую может принести какое-либо ПО.
Проект, имеющий размеры, сопоставимые с Debian, полагается на некоторую административную инфраструктуру для того, чтобы всё можно было отследить. Как у члена проекта у вас будут некоторые обязанности, исполнение которых гарантирует, что всё идёт гладко.
База данных LDAP, содержащая информацию о разработчиках Debian, расположена по адресу https://db.debian.org/. Вам следует ввести информацию о себе в эту базу данных и обновлять её по мере изменения. В первую очередь, убедитесь, что адрес электронной почты, на который пересылается ваша почта с ящика на debian.org, актуален, также проверьте ваш адрес, на который оформлена подписка на рассылку debian-private, если вы подписаны на неё.
Дополнительную информацию о базе данных см. в разделе 4.5, «База данных разработчиков».
Будьте аккуратны с вашими закрытыми ключами. Не размещайте их на публичных серверах или многопользовательских машинах, таких как серверы Debian (см. раздел 4.4, «Машины Debian»). Сделайте резервную копию ваших ключей; храните копию автономно. Прочтите документацию, поставляемую с вашим ПО; прочтите ЧаВО по PGP.
Вам следует убедиться в том, что ваш ключ не только защищён от кражи, но также и в том, что он не может быть потерян. Создайте и сделайте копию (лучше всего сделать также и бумажную копию) вашего сертификата отзыва ключа; он понадобится в случае потери ключа.
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, «Регистрация в качестве разработчика Debian».
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.
Помимо ежегодных выборов лидера Проекта, голосования не проводятся
регулярно, и к ним не относятся легкомысленно. Каждое предложение сначала
обсуждается в списке рассылки <debian-vote@lists.debian.org>
, требуется некоторое
одобрение любого предложения до того, как секретарь Проекта инициирует
процедуру голосования.
Вам не нужно отслеживать предваряющие голосование обсуждения, поскольку
секретарь опубликует несколько требований голосования в списке рассылки
<debian-devel-announce@lists.debian.org>
(все разработчики должны быть подписаны на
этот список рассылки). Демократия не работает, если люди не принимают
участия в голосовании, поэтому мы просим разработчиков голосовать.
Голосование происходит при помощи GPG-подписанных/зашифрованных сообщений
электронной почты.
Список всех предложений (прошлых и текущих) доступен на странице Информации о голосованиях Debian, там же доступна информация о том, как выдвинуть, поддержать и проголосовать по поводу предложения.
Разработчики могут отсутствовать, это нормально, это может быть запланированный отпуск, либо они могут быть загружены другой работой. Важно, чтобы остальные разработчики знали о том, что вы находитесь в отпуске, чтобы они могли сделать то, что нужно, если возникнут проблемы в ваших пакетах, либо от вас требуется выполнение каких-либо других обязанностей в Проекте.
Обычно это означает, что другие разработчики могут осуществлять загрузки, не будучи сопровождающими (см. раздел 5.11, «Загрузки не-сопровождающим (NMU)»), в случае если во время вашего отсутствия возникнет какая-либо большая проблема (критичная для выпуска ошибка, обновление безопасности и т. д.). Иногда ничего критичного не происходит, но всё равно лучше предупредить остальных о том, что вы будете недоступны.
Для того, чтобы проинформировать других разработчиков, вам следует сделать
две вещи. Во-первых, отправьте сообщение по адресу
<debian-private@lists.debian.org>
с [VAC] в начале темы
сообщения[2], в сообщении укажите
промежуток времени, когда вы будете находиться в отпуске. Вы также можете
указать какие-либо специальные инструкции по поводу того, что нужно
предпринять в случае, если возникнет проблема.
Далее, следует отметить себя как находящегося в отпуске в базе данных LDAP разработчиков Debian (эта информация доступна только разработчикам Debian). Не забудьте удалить флаг статуса «в отпуске» по своему возвращению!
В идеале вам следует зайти на координационные страницы GPG во время планирования своего отпуска и выяснить, хочет ли кто-либо подписать свой ключ. Это особенно важно, когда люди едут в экзотические места, где у нас пока нет разработчиков, но где есть заинтересованные в участии в Проекте люди.
Если вы решили покинуть Проект Debian, вам следует убедиться, что вы выполнили следующие шаги:
Придайте всем ваши пакетам статус осиротевших пакетов как это описано в разделе 5.9.4, «Придание статуса осиротевшего пакета».
Вышлите подписанное с помощью gpg электронное письмо о том, что вы хотите
покинуть Проект, по адресу <debian-private@lists.debian.org>
.
Сообщите сопровождающим брелока Debian, что вы выходите из Проекта, открыв
запрос в Debian RT путём отправления сообщения на адрес <keyring@rt.debian.org>
со
словами «Debian RT» в теме сообщения (регистр не имеет значения).
Если вы получали сообщения через алиас @debian.org (напр. press@debian.org)
и хотите удалить свой адрес из рассылки, откройте билет RT для системных
администраторов Debian. Просто отправьте сообщение на адрес <admin@rt.debian.org>
со словами "Debian RT" где-нибудь в теме сообщения, в сообщении укажите, от
каких алиасов вы более не хотите получать сообщения.
Важно, чтобы весь приведённый выше процесс был соблюдён, поскольку поиск неактивных разработчиком и пометка их пакетов как осиротевших занимает значительное количество времени и требует усилий.
Учётная запись разработчика получает отметку «emeritus» в случае, если выход в отставку выполнен в соответствии с разделом 3.2.5, «Уход в отставку», и «disabled» в противном случае. Вышедшие в отставку разработчики, имеющие учётную запись с отметкой «emeritus», могут заново активировать свою учётную запись следующим образом:
Свяжитесь с <da-manager@debian.org>
.
Пройдите через укороченную процедуру получения статуса нового члена (это необходимо для того, чтобы убедиться, что возвращающийся разработчик всё ещё помнит важные части P&P и T&S).
Докажите, что вы всё ещё контролируете ключ GPG, ассоциированный с учётной записью, либо предоставьте доказательство того, что новый ключ GPG принадлежит именно вам, для этого необходимы как минимум две подписи других разработчиков.
Прошлые разработчики, учётные записи которых были «отключены», должны заново проходить через процесс NM.
[2] Это нужно для того, чтобы те, кто не хочет читать сообщения об отпусках, могли отфильтровать такие сообщения.