Bohaté konečné výsledky vyproduktované projektem Debian vycházejí současně z práce na infrastruktuře prováděné zkušenými vývojáři Debianu, z individuálních nebo kolektivních prací vývojářů na debianovských balíčcích a z reakcí uživatelů.
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 and projects, thus acquiring more responsibilities within the project.
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.
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:
The Policy provides considerable coverage of the technical aspects of packaging. The size of the project also raises organizational problems; these are dealt with by the Debian Constitution, which establishes a structure and means for decision making. In other words, a formal governance system.
This constitution defines a certain number of roles and positions, plus responsibilities and authorities for each. It is particularly worth noting that Debian developers always have ultimate decision making authority by a vote of general resolution, wherein a qualified majority of three quarters (75%) of votes is required for significant alterations to be made (such as those with an impact on the Foundation Documents). However, developers annually elect a “leader” to represent them in meetings, and ensure internal coordination between varying teams. This election is always a period of intense discussions. The Debian Project leader's (
DPL) role is not formally defined by any document: candidates for this post usually propose their own definition of the position. In practice, the leader's roles include serving as a representative to the media, coordinating between “internal” teams, and providing overall guidance to the project, within which the developers can relate: the views of the DPL are implicitly approved by the majority of project members.
V podstatě má vedoucí opravdové pravomoce; jejich zvolení vzešla z těsných hlasování; mohou učinit jakékoli rozhodnutí, které již není pod pravomocí někoho jiného a mohou delegovat části svých povinností.
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, Neill McGovern, Mehdi Dogguy, Chris Lamb, Sam Hartman, and Jonathan Carter.
Stanovy rovněž definují “technickou komisi”. Hlavní úlohou této komise je rozhodovat v technických otázkách, pokud se zúčastnění vývojáři mezi sebou nedohodnou. Jinak má tato komise roli rádce pro vývojáře, kterému se nepodařilo učinit rozhodnutí, za které má odpovědnost. Je důležité poznamenat, že se zapojí pouze v případě, kdy je k tomu jednou ze zainteresovaných stran vyzvána.
A konečně stanovy definují pozici “tajemníka projektu”, který má na starosti organizaci hlasování v souvislosti s různými volbami a obecnými usneseními.
The “general resolution” (
GR) 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:
Even if this constitution establishes a semblance of democracy, the daily reality is quite different: Debian naturally follows the free software rules of the do-ocracy: the one who does things gets to decide how to do them. A lot of time can be wasted debating the respective merits of various ways to approach a problem; the chosen solution will be the first one that is both functional and satisfying… which will come out of the time that a competent person put into it.
To je jediný způsob, jak si vysloužit ostruhy: udělat něco užitečného a ukázat, že se pracovalo dobře. Mnoho “administrativních” týmů Debianu působí za pomocí kooptace, upřednostňující dobrovolníky, kteří již efektivně přispěli a prokázali svou schopnost. Veřejná podstata práce těchto týmů umožňuje novým přispěvatelům pozorovat a začít pomáhat bez zvláštních privilegií. Proto je Debian často popisován jako “meritokracie”.
Tato účinná operativní metoda zaručuje kvalitu přispěvatelů v “klíčových” týmech Debianu. Tato metoda není v žádném případě dokonalá a občas se vyskytnou tací, kteří nepřijmou tento způsob fungování. Výběr vývojářů přijatých do týmů se může zdát trochu svévolný, nebo dokonce nespravedlivý. Navíc, ne každý má stejnou představu o službách očekávaných od těchto týmů. Pro někoho je nepřijatelné muset čekat osm dní pro zahrnutí nového debianovského balíčku, zatímco ostatní budou trpělivě čekat tři týdny bez problémů. Jako takové, se pravidelně vyskytují stížnosti od těch nespokojených na “kvalitu služeb” některých týmů.
1.3.2. Aktivní role uživatelů
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“).
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.
Pod povrchem je Debian BTS založen na e-mailu: všechny informace, které uchovává, pocházejí ze zpráv odeslaných různými osobami. Všechny e-maily odeslané na
12345@bugs.debian.org budou tedy přiřazeny k historii chyby číslo 12345. Oprávněné osoby mohou chybu “uzavřítٌ” napsáním zprávy popisující důvody rozhodnutí o uzavření na
12345-Done@bugs.debian.org (chyba je uzavřena, pokud je uvedený problém vyřešen nebo již není relevantní). Nová chyba je hlášena zasláním e-mailu na
Submit@bugs.debian.org podle konkrétního formátu, který identifikuje dotyčný balíček. Adresa
Control@bugs.debian.org umožňuje editaci všech “meta-informací” vztahujících se k chybě.
The Debian BTS has other functional features, as well, such as the use of tags for labeling bugs. For more information, see
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).
Tento nástroj se nejdříve zaměřuje na vývojové verze, což je místo, kde jsou chyby opraveny. V praxi nejsou chyby ve stabilní verzi Debianu vítány, s velmi málo vyjímkami pro bezpečnostní aktualizace nebo důležité aktualizace (pokud, například, balíček vůbec nefunguje). Náprava menší chyby v debianovském balíčku musí tak počkat na další stabilní verzi.
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.
More advanced users might be able to provide a fix to a program by sending a patch.
Patch je soubor popisující změny, které mají být provedeny na jednom nebo více odkazovaných souborech. Konkrétně, obsahuje seznam řádků k odstranění nebo přidání do kódu, stejně jako (někdy) řádky odebrané z referenčního textu, nahrazující modifikace v kontextu (umožňující identifikaci umístění změn, pokud čísla řádlů byla změněna).
Nástroj používaný pro uplatnění modifikací předávaných v takovém souboru je jednoduše nazýván patch. nástroj, který jej vytváří se jmenuje diff a používá se takto:
$ diff -u file.old file.new >file.patch
Soubor file.patch obsahuje instrukce pro provedení obsahových změn file.old na file.new. Můžeme jej poslat někomu, kdo jej dokáže použít k vytvoření file.new z těch ostatních dvou, tímto způsobem:
$ patch -p0 file.old <file.patch
Soubor, file.old, je nyní identický s file.new.
In practice, most software is currently maintained in Git repositories and contributors are thus more likely to use git to retrieve the source code and propose changes. git diff will generate a file in the same format as what diff -u would do and git apply can do the same as patch.
While the output of git diff is a file that can be shared with other developers, there are usually better ways to submit changes. If the developers prefer to get patches by email, they usually want patches generated with git format-patch so that they can be directly integrated in the repository with git am. This preserves commits meta-information and makes it possible to share multiple commits at once.
This email-based workflow is still popular but it tends to be replaced by the usage of merge requests (or pull requests) whenever the software is hosted in a platform like GitHub or GitLab — and Debian is using GitLab on its salsa.debian.org server. On those systems, once you have created an account, you fork the repository, effectively creating a copy of the repository in your own account, and you can then clone that repository and push your own changes in it. From there, the web interface will suggest you to submit a merge request, notifying the developers of your changes, making it easy for them to review and accept your changes with a single click.
1.3.2.4. Other ways of contributing
Nejen, že uživatelé pomáhají sobě (i ostatním) s technickými věcmi, které se jich bezprostředně týkají, ale také diskutují o nejlepších způsobech, jak přispět k debianovskému projektu a posunout jej dál - diskutování, které často vede k návrhům na vylepšení.
Protože Debian nevydává žádné prostředky na žádnou sebepropagační kampaň, jeho uživatelé hrají podstatnou roli v jeho rozšiřování a tím upevňování jeho věhlasu prostřednictvím osobních rozhovorů apod.
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:
1.3.3. Teams, Blends, and Sub-Projects
From the start, Debian has been organized around the concept of source packages, each with its maintainer or group of maintainers. Many work teams have emerged over time, ensuring administration of the infrastructure, management of tasks not specific to any package in particular (quality assurance, Debian Policy, installer, etc.), with the latest series of teams growing up around sub-projects and blends.
1.3.3.1. Existing Debian Sub-Projects and Blends
To each their own Debian! A sub-project is a group of volunteers interested in adapting Debian to specific needs. Beyond the selection of a sub-group of programs intended for a particular domain (education, medicine, multimedia creation, etc.), sub-projects are also involved in improving existing packages, packaging missing software, adapting the installer, creating specific documentation, and more. While a "blend" might not be exactly the same, it works quite similar and also tries to provide a solution for groups of people intending to use Debian for a particular domain. One could say that "Debian Pure Blends" is the successor of sub-projects.
Here is a small selection of current released Debian Pure Blends:
Debian Junior, 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 and educational world;
Debian Med, od Andrease Tilleho, věnuje se lékařství;
Debian Multimedia, which deals with audio and multimedia work;
Debian GIS, which takes care of Geographical Information Systems applications and users;
Debian Astro, for both professionals and hobby astronomers;
Debian Science, working on providing researchers and scientists a better experience using Debian;
Freedombox, made to develop, design and promote personal servers running free software for private, personal communications;
Debian Games, providing games in Debian from arcade and adventure to simulation and strategy;
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 Pure Blends. 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. Administrativní týmy
Most administrative teams are relatively closed and recruit only by co-optation. The best means to become a part of one is to intelligently assist the current members, demonstrating that you have understood their objectives and methods of operation.
The ftpmasters are in charge of the official archive of Debian packages. They maintain the program that receives packages sent by developers and automatically stores them, after some checks, on the reference server (ftp-master.debian.org).
Musí také ověřovat licence všech nových balíčků, za účelem ujištění se, je může Debian rozšiřovat, před jejich zahrnutím do tělesa ostatních, už existujících balíčků. Pokud si vývojář přeje balíček vyjmout, oslovuje tento tým skrze systém sledování chyb a ftp.debian.org “pseudo-package”.
The
Debian System Administrators (
DSA) team (
debian-admin@lists.debian.org), as one might expect, is responsible for system administration of the many servers used by the project. They ensure optimal functioning of all base services (DNS, Web, e-mail, shell, etc.), install software requested by Debian developers, and take all precautions in regards to security.
Listmasteři obhospodařují emailový server který řídí seznamy pošty. Vytvářejí nové seznamy, zpracovávají odskoky (zprávy o selhání doručení) a udržují spamové filtry (nevyžádané hromadné emaily).
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 for 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. Vývojové týmy, Týmy napříč
Na rozdíl od administrativních týmů, vývojové týmy jsou spíše doširoka otevřené, i k spolupracovníkům zvenčí. I když posláním Debianu není vytvářet software, projekt potřebuje určité programy k dosažení svých cílů. Je samozřejmostí, že nástroje vyvinuté pod licencí svobodného softwaru využívají metod ověřených jinde ve světě svobodného softwaru.
Debian vyvinul málo softwaru ve vlastní režii, ale některé programy se staly hvězdami a jejich věhlas se rozšířil za hranice projektu. Dobrými přiklady jsou dpkg, program Debianu pro řízení balíčků (což je vlastně zkratka sousloví Debian PacKaGe a obvykle se vyslovuje “di:pekidž”) a apt, nástroj pro automatickou instalaci jakéhokoliv debianovského balíčku a jejo závislostí, zaručující stálost systému po upgradu (jeho jméno je vytvořeno z počátečních písmen slov Advanced Package Tool). Jejich týmy jsou nicméně mnohem menší, protože je zapotřebí spíše programátorského umu k získání všeobecného porozumění operací takového typu programů.
The most important team is probably that for the Debian installation program,
debian-installer, which has accomplished a work of momentous proportions since its conception in 2001. Numerous contributors were needed, since it is difficult to write a single program able to install Debian on a dozen different architectures. Each one has its own mechanism for booting and its own bootloader. All of this work is coordinated on the
debian-boot@lists.debian.org mailing list, under the direction of Cyril Brulebois.
Velmi malý programátorský tým pro debian-cd má neméně skromný úkol. Velké množství spolupracovníků je zodpovědných za svoji architekturu, protože hlavní vývojář nemůže znát drobné nuance ani znát přesný způsob spuštění instalátoru z CD-ROM.
