1.3. Внутреннее устройство Проекта Debian

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

1.3.1. Разработчики Debian

Debian developers have various responsibilities, and as official project members, they have great influence on the direction the project takes. A Debian developer is generally responsible for at least one package, but according to their available time and desire, they are free to become involved in numerous teams, thus acquiring more responsibilities within the project.

→ https://www.debian.org/devel/people

→ https://www.debian.org/intro/organization

→ https://wiki.debian.org/Teams

ИНСТРУМЕНТ База данных разработчиков

Debian has a database including all developers registered with the project, and their relevant information (address, telephone, geographical coordinates such as longitude and latitude, etc.). Some of the information (first and last name, country, username within the project, IRC username, GnuPG key, etc.) is public and available on the Web.

→ https://db.debian.org/

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

Рисунок 1.1. Распространение разработчиков Debian по миру

Package maintenance is a relatively regimented activity, very documented or even regulated. It must, in effect, comply with all the standards established by the Debian Policy. Fortunately, there are many tools that facilitate the maintainer's work. The developer can, thus, focus on the specifics of their package and on more complex tasks, such as squashing bugs.

→ https://www.debian.org/doc/debian-policy/

К ОСНОВАМ Сопровождение пакета, работа разработчика

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

После этого начинается сам цикл сопровождения: подготовка обновлений, чтобы пакет соответствовал последней версии Политики Debian, исправление ошибок, о которых сообщают пользователи, добавление новых версий из «основной ветки разработки», где всё это время разработка обычно продолжается. Например, во время создания пакета программа имела версию 1.2.3. После нескольких месяцев разработки авторы этой программы выпустили новую стабильную версию, 1.4.0. Теперь сопровождающий Debian должен обновить этот пакет, чтобы пользователи смогли использовать последнюю версию этой программы.

The Policy, an essential element of the Debian Project, establishes the norms ensuring both the quality of the packages and perfect interoperability of the distribution. Thanks to this Policy, Debian remains consistent despite its gigantic size. This Policy is not fixed in stone, but continuously evolves thanks to proposals formulated on the debian-policy@lists.debian.org mailing list. Amendments that are agreed upon by all interested parties are accepted and applied to the text by a small group of maintainers who have no editorial responsibility (they only include the modifications agreed upon by the Debian developers that are members of the above-mentioned list). You can read current amendment proposals on the bug tracking system:

→ https://bugs.debian.org/debian-policy

СООБЩЕСТВО Процесс редактирования Политики

Anyone can propose an amendment to the Debian Policy just by submitting a bug report with a severity level of “wishlist” against the debian-policy package. The process that then starts is documented in https://www.debian.org/doc/debian-policy/ap-process.html: if it is acknowledged that the problem revealed must be resolved by creating a new rule in the Debian Policy, a discussion begins on the debian-policy@lists.debian.org mailing list until consensus is reached and a proposal issued. Someone then drafts a desired amendment and submits it for approval (in the form of a patch to review). As soon as two other developers approve the fact that the proposed amendment reflects the consensus reached in the previous discussion (they “second” it), the proposal can be included in the official document by one of the debian-policy package maintainers. If the process fails at one of these steps, the maintainers close the bug, classifying the proposal as rejected.

ПОЛИТИКА DEBIAN Документация

Документация для каждого пакета хранится в каталоге /usr/share/doc/package/. Обычно этот каталог содержит файл README.Debian, описывающий конкретные изменения, внесённые сопровождающим пакета Debian. Таким образом, полезно ознакомиться с этим файлом до выполнения какой-либо настройки программы для того, чтобы использовать опыт сопровождающего по использованию пакета. Также имеется файл changelog.Debian.gz, описывающий изменения, внесённые сопровождающим различные версии пакета Debian. Его не следует путать с файлом changelog.gz (или его эквивалентом), в котором описываются изменения, внесённые разработчиками основной ветки разработки. Файл copyright содержит информацию об авторах и лицензии, под которой распространяется данное ПО. Наконец, имеется файл NEWS.Debian.gz, который позволяет разработчику Debian сообщать важную информацию об обновленияx; если установлен пакет apt-listchanges, то эти сообщения будут отображаться автоматически. Все другие файлы относятся исключительно к конкретному данному ПО. Хотелось бы особенно упомянуть подкаталог examples, в котором часто содержатся примеры файлов настройки.

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

Конституция определяет ряд ролей и должностей, а также ответственности и полномочия каждой их них. Особенно следует заметить, что разработчики Debian всегда имеют полномочия принятия окончательного решения путём общего решения, в котором для внесения существенных изменений (например, изменения основополагающих документов) требуется квалифицированное большинство из трёх четвёртых (75%) голосов. Тем не менее, ежегодно разработчики выбирают «лидера», который представляет проект на различных мероприятиях и гарантирует внутреннее взаимодействие между различными командами. Эти выборы всегда представляют собой период интенсивных обсуждений. Эта роль лидера формально не определена ни одним документом, кандидаты на этот пост обычно предлагают своё собственное видение этой должности. На практике роль лидера предполагает представление проекта средствам массовой информации, координацию между «внутренними» командами, общее управление проектом, в котором участвуют и разработчики (взгляды DPL имплицитно принимаются большинством членов проекта).

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

Since its inception, the project has been successively led by Ian Murdock, Bruce Perens, Ian Jackson, Wichert Akkerman, Ben Collins, Bdale Garbee, Martin Michlmayr, Branden Robinson, Anthony Towns, Sam Hocevar, Steve McIntyre, Stefano Zacchiroli, Lucas Nussbaum, Mehdi Dogguy, Chris Lamb and Sam Hartman.

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

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

The “general resolution” procedure is fully detailed in the constitution, from the initial discussion period to the final counting of votes. The most interesting aspect of that process is that when it comes to an actual vote, developers have to rank the different ballot options between them and the winner is selected with a Condorcet method (more specifically, the Schulze method). For further details see:

→ http://www.debian.org/devel/constitution.en.html

КУЛЬТУРА Флейм, горячее обсуждение

«Флейм» представляет собой чрезвычайно бурный спор, который зачастую заканчивается тем, что люди нападают друг на друга сразу же, как только у обеих сторон заканчиваются разумные аргументы. Некоторые темы значительно чаще являются предметом полемики (спор о выборе текстового редактора, «ты предпочитаешь vi или emacs?», традиционно является одним из самых популярных). Такие вопросы часто приводят к очень бурному обмену сообщениями электронной почты из-за того, что по этому конкретному вопросу каждый раз находится огромное количество людей (вообще-то, все), которые имеют своё мнение, а также из-за личной сути таких вопросов.

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

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

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

КУЛЬТУРА Меритократия, господство знания

Меритократия — это форма правления, при которой власть принадлежит тем, кто имеет наибольшие заслуги. В Debian заслуги являются мерой компетентности, которая сама по себе определяется исходя из предыдущих действий (Стефано Дзаккироли, бывший Лидер Проекта, говорит в таком случае и «делание-кратии», имея в виду, что «власть должна принадлежать тем, кто что-то делает»). Просто то, что в прошлом были предприняты какие-то действия, доказывает определённый уровень компетентности; достижениями обычно является свободное ПО, исходный код которого доступен и легко может быть просмотрен другими участниками на предмет качества этого кода.

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

СООБЩЕСТВО Включение новых сопровождающих

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

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

1.3.2. Активная роль пользователей

One might wonder if it is relevant to mention the users among those who work within the Debian project, but the answer is a definite yes: they play a critical role in the project. Far from being “passive”, some users run development versions of Debian and regularly file bug reports to indicate problems. Others go even further and submit ideas for improvements, by filing a bug report with a severity level of “wishlist”, or even submit corrections to the source code, called “patches” (see Раздел 1.3.2.3, «Sending fixes»).

1.3.2.1. Reporting bugs

The fundamental tool for submitting bugs in Debian is the Debian Bug Tracking System (Debian BTS), which is used by large parts of the project. The public part (the web interface) allows users to view all bugs reported, with the option to display a sorted list of bugs selected according to various criteria, such as: affected package, severity, status, address of the reporter, address of the maintainer in charge of it, tag, etc. It is also possible to browse the complete historical listing of all discussions regarding each of the bugs.

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

По сути, Debian BTS построена на основе электронной почты: вся информация, хранимая в системе, берётся из сообщений, отправленных различными участниками. Любое сообщение, отправленное на адрес 12345@bugs.debian.org будет приписано к истории сообщения об ошибке под номером 12345. Уполномоченные лица могут «закрыть» ошибку, написав сообщение, описывающее причины этого решения на адрес 12345-done@bugs.debian.org (ошибка закрывается в том случае, если соответствующая проблема решена или более не релевантна). Чтобы сообщить о новых ошибках, нужно отправить сообщение определённого формата с указанием подверженного ошибке пакета на адрес submit@bugs.debian.org. Адрес control@bugs.debian.org позволяет редактировать «метаинформацию» об ошибке.

The Debian BTS has other functional features, as well, such as the use of tags for labeling bugs. For more information, see

→ https://www.debian.org/Bugs/

СЛОВАРЬ Степень серьёзности ошибки

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

Debian uses an extended scale to describe the severity of a bug. Each level is defined precisely in order to facilitate the selection thereof.

→ https://www.debian.org/Bugs/Developer#severities

Users can also use the command line to send bug reports on a Debian package with the reportbug tool. It helps making sure the bug in question hasn't already been filed, thus preventing redundancy in the system. It reminds the user of the definitions of the severity levels, for the report to be as accurate as possible (the developer can always fine-tune these parameters later, if needed). It helps writing a complete bug report without the user needing to know the precise syntax, by writing it and allowing the user to edit it. This report will then be sent via an e-mail server (by default, a remote one run by Debian, but reportbug can also use a local server).

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

1.3.2.2. Translation and documentation

Additionally, numerous satisfied users of the service offered by Debian like to make a contribution of their own to the project. As not everyone has appropriate levels of expertise in programming, they may choose to assist with the translation and review of documentation. There are language-specific mailing lists to coordinate this work.

→ https://lists.debian.org/i18n.html

→ https://www.debian.org/international/

К ОСНОВАМ Что такое i18n и l10n?

“i18n” и “l10n” являются сокращениями от слов, соответственно, «интернационализация» и «локализация», в этих сокращениях сохранены первые и последние буквы английских слов и указано количество букв между ними (также в английских словах).

«Интернационализация» программы состоит в изменении её таким образом, чтобы её можно было перевести (локализовать). Это предполагает частичное переписывание программы, изначально написанной для работы только с одним языком, так, чтобы открыть её для всех языков.

«Локализация» программы состоит в переводе оригинальных сообщений (зачастую на английском языке) на другой язык. Для этого программа уже должна быть интернационализирована.

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

1.3.2.3. Sending fixes

More advanced users might be able to provide a fix to a program sending a patch.

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

Инструмент, используемый для применения изменений, указанных в таком файле, называется patch. Инструмент, создающий такие файлы, называется diff, он используется следующим образом:

$ diff -u старый.файл новый.файл >файл.заплаты

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

$ patch -p0 старый.файл <файл.заплаты

Файл старый.файл теперь идентичен новому.файлу.

TOOL Git, the preferred way to send patches

Git is a version-control system designed for coordinating work among developers and track their changes. It was programmed by Linus Torvalds (the creator of Linux) in 2005 to coordinate the development of the Linux kernel.

Nowadays, it is common to send patches using Git. Many Debian projects using Git can be found on https://salsa.debian.org/.

To send a patch using Git, you must download a copy of the repository, make the fixes, add them to the stage area, commit the changes, upload your changes, and request the maintainer to accept your changes. It is beyond the scope of this book to provide a detailed explanation about Git, for that you can refer to the Pro Git book (https://git-scm.com/book/).

Below is an example of the commands needed to submit a patch to this book. You can use GitLab's web interface to make the pull request; another option is to use the command git request-pull and send its output to the developers.

$ git clone https://salsa.debian.org/youruser/debian-handbook/
Cloning into 'debian-handbook'...
remote: Enumerating objects: 20838, done.
remote: Counting objects: 100% (20838/20838), done.
remote: Compressing objects: 100% (4510/4510), done.
remote: Total 20838 (delta 16316), reused 20809 (delta 16307)
Receiving objects: 100% (20838/20838), 139.41 MiB | 131.00 KiB/s, done.
Resolving deltas: 100% (16316/16316), done.
Checking out files: 100% (1351/1351), done.
$ editor file
$ git add file
$ git commit -m "Correct typo in chapter 3"
[buster/master ca5a0039] Update chapter 1
 1 file changed, 98 insertions(+), 54 deletions(-)
$ git push
Username for 'https://salsa.debian.org': youruser
Password for 'https://youruser@salsa.debian.org': yourpasswd
Enumerating objects: 96, done.
Counting objects: 100% (96/96), done.
Delta compression using up to 2 threads
Compressing objects: 100% (80/80), done.
Writing objects: 100% (80/80), 456.23 KiB | 3.83 MiB/s, done.
Total 80 (delta 59), reused 2 (delta 0)
To https://salsa.debian.org/youruser/debian-handbook.git/
   18e0e26c..ca5a0039  buster/master -> buster/master

It is a good practice to review the changes before executing git add. You can execute git diff for that. It will open the default pager (usually less) to display the differences. The lines starting with - are the removed lines, whereas the lines starting with + show added lines.

1.3.2.4. Other ways of contributing

Все эти механизмы участия становятся более эффективными благодаря пользователям. Не будучи собранием изолированных индивидов, пользователи представляют собой настоящее сообщество, внутри которого постоянно происходят различные взаимодействия. Мы особенно выделяем впечатляющую активность в пользовательском списке рассылки, debian-user@lists.debian.org (в Глава 7, Решение проблем и поиск необходимой информации содержит более подробное описание).

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

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

This method works quite well, since Debian fans are found at all levels of the free software community: from install parties (workshops where seasoned users assist newcomers to install the system) organized by local LUGs or “Linux User Groups”, to association booths at large tech conventions dealing with Linux, etc.

Volunteers make posters, brochures, stickers, and other useful promotional materials for the project, which they make available to everyone, and which Debian provides freely on its website and on its wiki:

→ https://www.debian.org/events/material

1.3.3. Команды и подпроекты

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

1.3.3.1. Существующие подпроекты Debian

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

СЛОВАРЬ Подпроекты и производные дистрибутивы

Процесс разработки производного дистрибутива состоит в том, чтобы начать с определённой версии Debian и внести в неё некоторое количество изменений. Инфраструктура, используемая для этой работы, целиком является внешней по отношению к Проекту Debian. Внесение улучшений не обязательно подчиняется какой-то политике. Это отличие объясняет то, в каком смысле производный дистрибутив может «отходить» от своего первоисточника, а также то, почему они вынуждены регулярно производить повторные сверки, чтобы использовать улучшения, внесённые в основной ветке разработки.

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

Наиболее известным производным от Debian дистрибутивом без сомнения является Ubuntu, но на самом деле их много. См. Приложение A, Производные дистрибутивы, где приводятся их особенности и их позиционирование в плане отношений с Debian.

Ниже приведена небольшая выборка текущих подпроектов:

Debian Jr., by Ben Armstrong, offering an appealing and easy to use Debian system for children;
Debian Edu, by Petter Reinholdtsen, focused on the creation of a specialized distribution for the academic world;
Debian-Med, разрабатываемый Андреасом Тилле, посвящён медицине;
Debian Multimedia, который касается работы с аудио и мультимедиа;
Debian GIS, который заботится о приложениях и пользователях геоинформационных систем;
Debian Accessibility, improving Debian to match the requirements of people with disabilities;
Debian Science, finally, working on providing researchers and scientists a better experience using Debian.
DebiChem, targeted at Chemistry, provides chemical suites and programs.

The number of projects will most likely continue to grow with time and improved perception of the advantages of Debian sub-projects. Fully supported by the existing Debian infrastructure, they can, in effect, focus on work with real added value, without worrying about remaining synchronized with Debian, since they are developed within the project.

1.3.3.2. Административные команды

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

Команда ftp-мастеров ответственная за официальный архив пакетов Debian. Они сопровождают программу, которая получает пакеты, отправленные разработчиками, и автоматически сохраняет их после некоторых проверок на соответствующем сервере (ftp-master.debian.org).

Также они должны проверять лицензии всех новых пакетов до их включения в набор существующих пакетов с тем, чтобы убедиться, что Debian может их распространять. Когда разработчик хочет удалить пакет, они обращаются к этой команде через систему отслеживания пакетов и «псевдопакет» ftp.debian.org.

СЛОВАРЬ Псевдопакет, инструмент отслеживания

Система отслеживания ошибок, изначально разработанная для связывания отчётов об ошибках с пакетами Debian, оказалась весьма полезной и для других целей. С её помощью можно создавать списки проблем, которые следует решить, или задач, которые следует выполнить, без относительно какого-то отдельного пакета Debian. Таким образом, «псевдопакеты» позволяют отдельным командам использовать систему отслеживания ошибок без указания реально существующего пакета. Так, каждый может сообщать о проблемах, которые следует решить. Например, в BTS есть элемент ftp.debian.org, который используется для сообщения о проблемах в официальном архиве пакетов, отслеживания этих проблем или запросов об удалении того или иного пакета. Сходным образом псевдопакет www.debian.org используется для работы с ошибками на веб-сайте Debian, а lists.debian.org накапливает проблемы со списками рассылки.

TOOL GitLab, Git repository hosting and much more

A GitLab instance, known as salsa.debian.org, is used by Debian to host the Git packaging repositories but this software offers much more than simple hosting and Debian contributors have been quick to leverage the continuous integration features (running tests, or even building packages, on each push). Debian contributors also benefit from a cleaner contribution workflow thanks the well understood merge request process (similar to GitHub's pull requests).

GitLab replaced FusionForge (which was running on a service known as alioth.debian.org) for collaborative package maintainance. This service is administered by Alexander Wirt, Bastian Blank and Jörg Jaspert.

→ https://salsa.debian.org/

→ https://wiki.debian.org/Salsa/Doc

Команда системных администраторов Debian (DSA) (debian-admin@lists.debian.org), как и ожидается, ответственна за системное администрирование многих серверов, используемых Проектом. Они гарантируют оптимальное функционирование всех базовых служб (DNS, веб, электронная почты, командная оболочка и т. д.), по требованию разработчиков Debian устанавливают ПО и предпринимают все предосторожности в плане безопасности.

→ https://dsa.debian.org

ИНСТРУМЕНТ Система отслеживания пакетов Debian

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

→ https://tracker.debian.org/

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

Advanced users can, thus, follow all of this information closely and even contribute to the project, once they have got a good enough understanding of how it works.

Другой веб-интерфейс, известный как Обзор пакетов разработчика Debian (DDPO), предоставляет каждому разработчику краткий обзор статуса всех пакетов Debian, размещённых от его имени.

→ https://qa.debian.org/developer.php

Эти два веб-сайта являются инструментами, которые разрабатываются и сопровождаются группой, ответственной за гарантию качества в Debian (эта группа известна как Debian QA).

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

Each specific service has its own administration team, generally composed of volunteers who have installed it (and also frequently programmed the corresponding tools themselves). This is the case of the bug tracking system (BTS), the package tracker, salsa.debian.org (GitLab server, see sidebar TOOL GitLab, Git repository hosting and much more), the services available on qa.debian.org, lintian.debian.org, buildd.debian.org, cdimage.debian.org, etc.

1.3.3.3. Команды разработки, трансверзальные команды

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

КУЛЬТУРА Git

Git — инструмент для совместной работы над несколькими файлами, сохраняющий историю изменений. Обычно это текстовые файлы, такие как исходный код программы. Если несколько людей работают вместе над одним и тем же файлом, git может объединять внесённые изменения только в том случае, если они касаются разных частей одного и того же файла. В противном случае «конфликты» следует разрешить вручную.

Git is a distributed system where each user has a repository with the complete history of changes. Central repositories are used to download the project (git clone) and to share the work done with others (git push). The repository can contain multiple versions of the files but only one version can be worked on at a given time: it's called the working copy (it can be changed to point to another version with git checkout). Git can show you the modifications made to the working copy (git diff), can add (git add) the selected files for inclusion in a new entry in the repository, with the added files it can create a new entry in the versions history (git commit), it can update the working copy to include modifications made in parallel by other users (git pull), and can record a particular configuration in the history in order to be able to easily extract it later on (git tag).

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

На сегодняшний день Git является самой популярной системой управления версиями, но это не единственная такая система. Исторически первым широко используемым инструментом был CVS (Concurrent Versions System, система одновременных версий), но её многочисленные ограничения всё ещё встречаются в более современных свободных альтернативах. Среди них особо можно выделить subversion (svn), git, bazaar (bzr) и mercurial (hg).

→ http://www.nongnu.org/cvs/

→ http://subversion.apache.org/

→ http://git-scm.com/

→ http://bazaar.canonical.com/

→ http://mercurial.selenic.com/

В Debian было разработано не очень много собственного ПО, но некоторые программы играют звёздные роли, а их слава распространилась далеко за пределы Проекта. Прекрасными примерами такого рода являются dpkg, программа управления пакетами Debian (фактически, это сокращение от слов Debian PacKaGe, пакет Debian, а обычно произносится как "dee-package"), и apt, инструмент для автоматической установки любого пакета Debian вместе с его зависимостями, что гарантирует целостность системы после выполнения обновления (называние этого инструмента является сокращением от Advanced Package Tool, продвинутый инструмент для работы с пакетами). Тем не менее, команды, занимающиеся разработкой этих инструментов, не настолько обширны как слава этих инструментов, поскольку для понимания работы такого типа программ требуются довольно глубокие навыки программирования.

Вероятно, самой важной командой является команда, которая занимается программой установки Debian, debian-installer, с момента своего создания в 2001 году она выполнила весьма важную работу. Команде требуются многочисленные участники, поскольку написать одну единственную программу, способную установить Debian на дюжину разных архитектур, довольно сложно. Каждая архитектура имеет свой собственный механизм загрузки и свой собственный загрузчик. Вся работа координируется через список рассылки debian-boot@lists.debian.org и управляется Сирилом Брулбуа.

→ http://www.debian.org/devel/debian-installer/

→ http://joeyh.name/blog/entry/d-i_retrospective/

Другая (очень маленькая) команда, debian-cd, выполняет более скромные задачи. Множество «скромных» участников ответственно за свои отдельные архитектуры, поскольку основной разработчик не может знать всех нюансов и точного способа запустить программу установки с компакт-диска.

Многим командам при создании пакетов приходится работать вместе с другими командами: например, debian-qa@lists.debian.org стремится гарантировать качество на всех уровнях Проекта Debian. Список debian-policy@lists.debian.org служит для разработки Политики Debian в соответствии с предложениями от различных участников. Команды, ответственные за каждую отдельную архитектуру (debian-architecture@lists.debian.org) собирают пакеты и при необходимости адаптируют их под конкретную архитектуру.

Другие команды следят за наиболее важными пакетами, гарантируя сопровождение этих пакетов без того, чтобы эта тяжёлая нагрузка лежала на одних плечах; это касается библиотеки C и списка рассылки debian-glibc@lists.debian.org, компилятора C и списка debian-gcc@lists.debian.org, а также Xorg и debian-x@lists.debian.org (это группа также известна как X Strike Force).