Глава 7. Помимо создания пакетов

Содержание

7.1. Отправка отчётов об ошибках
7.1.1. Отправка множества отчётов об ошибках за один раз (массовое заполнение отчётов об ошибках)
7.1.1.1. Пользовательские метки
7.2. Работа по контролю качества
7.2.1. Ежедневная работа
7.2.2. Вечеринки по исправлению ошибок
7.3. Связь с другими сопровождающими
7.4. Работа с неактивными и/или недоступными сопровождающими
7.5. Взаимодействие с будущими разработчиками Debian
7.5.1. Поручение пакетов
7.5.1.1. Поручительство нового пакета
7.5.1.2. Поручение обновления существующего пакета
7.5.2. Поддержка новых разработчиков
7.5.3. Обработка заявок новых сопровождающих

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

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

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

Прочтите инструкции по отправке отчётов об ошибках в систему отслеживания ошибок Debian.

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

Вы можете использовать инструмент на подобие reportbug(1) для отправки сообщений об ошибках. Это может автоматизировать и в целом упростить процесс.

Убедитесь, что о данной ошибке в данном пакете ещё не сообщали. Всякий пакет имеет свой список ошибок, доступ к которому можно легко получить, по адресу https://bugs.debian.org/имя-пакета. Такие утилиты как querybts(1) также могут предоставить вам информацию (reportbug обычно вызывает команду querybts до отправки отчёта).

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

Для получения дополнительного кредита доверия вы можете просмотреть другие пакеты, сливая сообщения об ошибках, о которых было сообщено несколько раз, либо помечая ошибки как исправленные (`fixed'), если они уже исправлены. Заметьте, что если вы не являетесь ни автором сообщения об ошибке, ни сопровождающим пакета, вам не следует фактически закрывать ошибку (если только вы не получили на это разрешение от сопровождающего).

Время от времени вам может захотеться проверить, что происходит с отчётами об ошибках, которые вы отправили. Используйте эту возможность, чтобы закрыть те ошибки, которые вы более не можете воспроизвести. Чтобы найти все ошибки, о которых вы отправляли отчёты, вам следует перейти на страницу https://bugs.debian.org/from:ваш-адрес-электронной-почты.

Сообщение о большом количестве ошибок, связанных с одной и той же проблемой в большом количестве различных пакетов — напр., более 10 — является плохой практикой. Предпримите все возможные шаги, чтобы не допустить отправки массы сообщений об ошибках. Например, если проверка данной проблемы может быть автоматизирована, добавьте новую проверку в lintian, так чтобы выводилось сообщение об ошибке или предупреждение.

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

Пожалуйста, используйте программы dd-list и, если это подходит, whodepends (из пакета devscripts) для создания списка всех подверженных данной ошибке пакетов и добавьте вывод этих программ в ваше сообщение по адресу .

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

Возможно вам захочется использовать пользовательские метки системы отслеживания ошибок при отправке сообщений об ошибках в нескольких пакетах. Пользовательские метки (usertags) схожи с обычные метками, такими как 'patch' и 'wishlist', но отличаются от них в том, что они определяются пользователями и занимают пространство имён, уникальное для каждого отдельного пользователя. Это позволяет нескольким подмножествам разработчиков отмечать пользовательскими метками одну и ту же ошибку разными способами без возникновения конфликтов.

Чтобы добавить пользовательские метки при заполнении отчётов об ошибках, укажите псевдозаголовки User и Usertags:

To: submit@bugs.debian.org
Subject: заголовок-ошибки

Package: имяпакета
[ ... ]
User: адрес-email
Usertags: имя-метки [ имя-метки ... ]

описание-ошибки ...

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

Чтобы просмотреть сообщения об ошибках, помеченные конкретной пользовательской меткой, посетите страницу https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=адрес-электронной-почты&tag=имя-метки.

Даже несмотря на то, что у нас имеется выделенная группа людей, которые занимаются контролем качества (Quality Assurance), обязанности по контролю качества не резервируются исключительно за ними. Вы можете принять участие в этой работе, стараясь сделать так, чтобы в ваших пакетах было как можно меньше ошибок, и чтобы ваши пакеты проходили как можно большее количество проверок lintian (см. раздел A.2.1, «lintian»). Если считаете, что это невозможно, вам, вероятно, следует отказаться (осиротить) некоторые из ваших пакетов (см. раздел 5.9.4, «Придание статуса осиротевшего пакета»). С другой стороны, вы можете попросить о помощи других людей, чтобы наверстать отставание по количеству исправленных ошибок (вы можете попросить о помощи в списках рассылки или ). В то же время вы можете искать помощников сопровождающего (см. раздел 5.12, «Совместное сопровождение»).

Время от времени группа QA организует вечерники по исправлению ошибок для того, чтобы избавиться от как можно большего количества проблем. Они анонсируются в списке рассылки , анонс содержит информацию о том, на каких областях будет сфокусирована вечеринка: обычно они концентрируются на критичных для выпуска ошибках, но может случиться и так, что они решать помочь завершить крупное обновление (например, до новой версии perl, что потребует перекомпиляции всех двоичных модулей).

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

Люди, принимающие участие в такой вечеринке, имеют специальные правила для NMU, они могут осуществлять NMU без предварительного объявления об этом, если они загружают свою NMU по меньшей мере в DELAYED/3-day. Все другие правила NMU применяются как обычно; они должны выслать заплату NMU в систему отслеживания ошибок (в один из открытых отчётов об ошибке, исправленных NMU, либо в новый отчёт об ошибке, пометив его как исправленный). Также они должны уважать любых конкретные пожелания сопровождающего.

Если вы не чувствуете уверенности по поводу NMU, просто вышлите заплату в систему отслеживания ошибок. Это намного лучше, чем сломанная NMU.

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

Поиск адреса электронной почты сопровождающего пакета может отвлекать. К счастью, существуют простые псевдонимы для электронной почты, пакет@packages.debian.org, которые предоставляют способ отправки сообщения сопровождающему, каким бы ни был его индивидуальный адрес электронной почты (или адреса). Замените пакет на имя пакета с исходным кодом или имя двоичного пакета.

Возможно, вы захотите связаться с теми, кто подписан на данный пакет с исходным кодом через систему отслеживания пакетов (раздел 4.10, «Система отслеживания пакетов Debian»). Вы можете сделать это, используя адрес электронной почты пакет@packages.qa.debian.org.

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

Существует простая система (база данных MIA), в которую записывается информация о сопровождающих, которые считаются пропавшими без вести (Missing In Action). Когда член группы QA связывается с неактивным сопровождающим или находит дополнительную информацию о нём, это записывается в базу данных MIA. Эта система доступна в /org/qa.debian.org/mia на узле qa.debian.org и может быть запрошена с помощью инструмента mia-query. Используйте mia-query --help, чтобы узнать, как запрашивать базу данных. Если вы обнаружите, что о конкретном неактивном сопровождающем нет никакой информации, что вы можете добавить дополнительную информацию, вам следует действовать следующим образом.

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

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

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

  • Число пакетов, за которые ответственен этот сопровождающий, и состояние этих пакетов. В частности, имеются ли какие-либо критичные для выпуска ошибки, которые остаются открытыми долгое время? Более того, как много вообще ошибок? Другой важной информацией является то, были ли эти пакеты загружены несопровождающим, и если да, то кем.

  • Имеется ли какая-либо активность этого сопровождающего за пределами Debian? Например, он может написать что-то в список рассылки, не связанный с Debian, или в какую-нибудь новостную группу.

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

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

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

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

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

Если вы заинтересованы в работе в команде MIA, посмотрите файл README в /org/qa.debian.org/mia на qa.debian.org, где описаны технические детали и процедуры MIA, а также свяжитесь с .

Успех Debian зависит от его способности привлекать и сохранять новых и талантливых добровольцев. Если вы являетесь опытным разработчиком, мы рекомендуем вам принять участие в процессе привлечения новых разработчиков. Данный раздел описывает то, как помогать новым будущим разработчиками.

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

Разработчики Debian могут выступать поручителями для пакетов. Сопровождающие Debian не могут.

Процесс поручения пакета таков:

  1. Сопровождающий готовит пакет с исходным кодом (.dsc) и помещает его куда-нибудь в сеть (например, на mentors.debian.net) или, что даже лучше, предоставляет ссылку на публичный репозиторий системы управления версиями (см. раздел 4.4.5, «Серверы систем управления версиями»), в рамках которого осуществляется сопровождение пакета.

  2. Поручитель скачивает (или получает) пакет с исходным кодом.

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

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

До того как вникнуть в детали, как осуществлять поручение пакета, вам следует спросить себя, является ли добавление предложенного пакета полезным для Debian.

Нет никакого простого правила для ответа на этот вопрос, это может зависеть от множества факторов: является ли кодовая база основной ветки разработки достаточно зрела и в ней не так много дыр в безопасности? Имеется ли уже существующий пакет, которые может выполнять ту же задачу, и каково различие между существующими пакетами и этим новым пакетом? Был ли новый пакет запрошен пользователями, какова его пользовательская база? Насколько активны разработчики основной ветки?

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

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

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

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

Сборка пакета и тестирование ПО являются частью исследования пакета, но этого не достаточно. Оставшаяся часть данного раздела содержит неполный список того, на что необходимо обратить внимание. [7]

  • Убедитесь, что включённый в пакет tarball-архив, не отличается от архива, распространяемого автором основной ветки разработки (если архив с исходным кодом для Debian был создан заново, создайте изменённый tarball-архив самостоятельно).

  • Запустите lintian (см. раздел A.2.1, «lintian»). Он обнаружил многие часто встречающиеся проблемы. Убедитесь, что все настройки по игнорированию lintian, выполненные сопровождающим, обоснованы.

  • Запустите licensecheck (часть раздела A.6.1, «devscripts») и убедитесь, что файл debian/copyright корректен и полон. Проверьте проблемы с лицензиями (напр., файлы с заголовками “All rights reserved”, либо распространяемые под несовместимой с Критериями Debian лицензией). Команда grep -ri поможет вам в решении этой задачи.

  • Соберите пакет с помощью pbuilder (или любого другого схожего инструмента, см. раздел A.4.3, «pbuilder») для того, чтобы гарантировать, что сборочные зависимости полны.

  • Проверьте debian/control: подготовлен ли он в соответствии с лучшими практиками (см. раздел 6.2, «Лучшие практики для debian/control»)? Полны ли зависимости?

  • Проверьте debian/rules: подготовлен ли он в соответствии с лучшими практиками (см. раздел 6.1, «Лучшие практики для debian/rules»)? Можно ли что-либо улучшить?

  • Проверьте сценарии сопровождающего (preinst, postinst, prerm, postrm, config): будет ли preinst/postrm работать в том случае, если зависимости не установлены? Все ли сценарии идемпотентны (т. е., можете ли вы запустить их несколько раз без каких-либо последствий)?

  • Проверьте изменения в файлах из основной ветки разработки (либо в .diff.gz, либо в debian/patches/, либо в самом встроенном tarball-архиве debian для двоичных файлов). Обоснованы ли эти изменения? Правильно ли они документированы (с DEP-3 для заплат)?

  • Относительно каждого файла задайте себе вопрос о том, почему этот файл находится здесь, правильно достигнут желаемый результат. Следует ли сопровождающий лучшим практикам (см. раздел 6, «Лучшие практики создания пакетов»)?

  • Соберите пакеты, установите их и попробуйте поработать с эти ПО. Убедитесь, что вы можете удалить и очистить пакеты. Можно протестировать пакеты с помощью piuparts.

Если аудит не выявил каких-либо проблем, вы можете собрать пакет и загрузить его в Debian. Помните, что даже если вы не являетесь сопровождающим, как поручитель вы всё равно ответственны за то, что вы загружаете в Debian. Вот почему вам нужно отслеживать пакет при помощи информации из раздела 4.10, «Система отслеживания пакетов Debian».

Заметьте, что вам не нужно изменять пакет с исходным кодом для указания своего имени в файле changelog или в файле control. Поле Maintainer файла control и файла changelog должно сдержать имя того, кто создал пакет, т. е., того, за кого вы поручились. Так этот человек будет получить всю почту от системы отслеживания ошибок.

Вместо этого вам следует явным образом настроить dpkg-buildpackage на использование вашего ключа для подписи пакета. Вы можете сделать это при помощи опции -k:

dpkg-buildpackage -kИДЕНТИФИКАТОР-КЛЮЧА

Если вы используете debuild и debsign, вы даже можете создать постоянную настройку в файле ~/.devscripts:

DEBSIGN_KEYID=ИДЕНТИФИКАТОР-КЛЮЧА

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

Чтобы проверить различия вам нужны обе версии пакета. Загрузите текущую версию пакета с исходным кодом (при помощи команды apt-get source) и соберите его заново (либо загрузите текущий двоичный пакет при помощи команды aptitude download). Загрузите поручаемый пакет с исходным кодом sponsor (обычно при помощи команды dget).

Прочтите новую запись в журнале изменений, она должна сообщить вам, что следует ожидать во время проверки. Основным инструментом, который вы будете использовать, является debdiff (предоставляется пакетом devscripts), вы можете запустить её, указав два пакета с исходным кодом (файлы .dsc), либо двумя двоичными пакетами, либо двумя файлами .changes (затем эта утилита сравнит все двоичные пакеты из списка .changes).

Если вы сравниваете пакеты с исходным кодом (исключая файлы из основной ветки разработки в случае новой версии из основной ветки разработки, например, фильтруя вывод команды debdiff с помощью filterdiff -i '*/debian/*'), вам следует понять все изменения, которые вы видите, и они должны быть соответствующим образом документированы в журнале изменений Debian.

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

Возможно, вам захочется обратиться к системе отслеживания пакетов (см. раздел 4.10, «Система отслеживания пакетов Debian»), чтобы убедиться в том, что сопровождающий не пропустил ничего важного. Возможно, в системе отслеживания ошибок имеются обновления перевода, которое может быть добавлено в пакет. Возможно, пакет был загружен тем, кто сопровождающим не является, и сопровождающий забыл добавить изменения, добавленные в этой загрузке, в свой пакет. Возможно, имеется критичная для выпуска ошибка, на которую не обратили внимания и которая блокирует миграцию пакета в тестируемый выпуск. Если обнаружите что-то, что может быть сделано (лучше), нужно сообщить сопровождающему, что он может улучшить в следующий раз, так он будет лучше понимать свою ответственность.

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



[7] Дополнительные проверки вы можете найти в wiki, там некоторые разработчики размещают свои собственные списки требований для поручения пакетов.