1.3. Vnitřní fungování projektu Debian

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ů.

1.3.1. Vývojáři Debianu

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

NÁSTROJDatabáze vývojářů

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/

Zeměpisné souřadnice umožňují vytvoření mapy s umístěním všech vývojářů po celém světě. Debian je skutečně mezinárodní projekt: jeho vývojáře lze nalézt na všech kontinentech, i když většina je v “západních zemích”.

Obrázek 1.1. Celosvětové rozmístění vývojářů Debianu

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/

ZPĚT K ZÁKLADŮMÚdržba balíčků, práce vývojáře

Údržba balíčku znamená nejprve “balení” programu. Konkrétně to znamená definovat prostředky instalace tak, aby po instalaci tento program fungoval a dodržoval pravidla, která projekt Debian pro sebe stanovil. Výsledek této operace je uložen v souboru .deb. Účinná instalace programu pak nebude vyžadovat nic víc než extrakci tohoto komprimovaného archivu a spuštění některých předinstalačních nebo poinstalačních zde obsažených skriptů.

Po této počáteční fázi, cyklus údržby opravdu začíná: Příprava aktualizací podle nejnovějších Zásad Debianu, opravy chyb hlášených uživateli a zahrnutí nových “upstreamových” verzí programu, které se přirozeně i nadále současně vyvíjejí. Například v době počátečního balení byl program ve verzi 1.2.3. Po několika měsících vývoje, původní autoři vydávají novou stabilní verzi, očíslovanou 1.4.0. V tuto chvíli by měl správce Debianu balíček aktualizovat, aby uživatelé mohli využívat nejnovější stabilní verzi.

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

KOMUNITA Proces vydávání Zásad

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.

ZÁSADY DEBIANU dokumentace

Dokumentace pro každý balíček je uložena v /usr/share/doc/balíček/. Tento adresář často obsahuje soubor README.Debian, popisující specifické úpravy Debianu, které provádí správce balíčku. Je tedy moudré přečíst si tento soubor před jakýmkoliv nastavováním, a těžit z těchto zkušeností. Nalezneme také soubor changelog.Debian.gz popisující změny provedené správcem Debianu při přechodu z jedné verze na následující. To by se nemělo zaměňovat se souborem changelog.gz (nebo jeho obdobami), který popisuje změny provedené upstreamovými vývojáři. Soubor copyright obsahuje informace o autorech a o licenci vztahující se na software. A na závěr také můžeme najít soubor s názvem NEWS.Debian.gz, který vývojářům Debianu umožňuje sdělovat důležité informace týkající se aktualizací; Pokud je nainstalován apt-listchanges, zobrazí se tyto zprávy automaticky. Všechny ostatní soubory jsou specifické pro daný software. Především bychom chtěli poukázat na podadresář examples, který často obsahuje příklady konfiguračních souborů.

Zásady do značné míry pokrývají technické aspekty balíčků. Velikost projektu také vyvolává organizační problémy; ty jsou řešeny Stanovami Debianu, které vytváří strukturu a prostředky pro rozhodování. Jinými slovy, formální systém řízení.

Stanovy definují určitý počet rolí a postů, plus jejich odpovědnosti a pravomoce. Zejména je třeba poznamenat, že vývojáři Debianu mají vždy konečný rozhodovací pravomoc hlasováním o obecném usnesení, kde je vyžadována kvalifikovaná většina tří čtvrtin (75%) hlasů pro učinění významných změn (např. s dopadem na dokumenty nadace). Nicméně, vývojáři každoročně volí “vedoucího”, aby je zastupoval na schůzkách, a zajistit vnitřní koordinaci mezi různými týmy. Tato volba je vždy obdobím intenzivních diskuzí. Role vedoucího není formálně definována žádným dokumentem: kandidáti na tento post obvykle navrhují vlastní definice pozice. V praxi role vedoucího zahrnuje zastupování vůči sdělovacím prostředkům, koordinaci mezi “interními” týmy a zajišťování celkového vedení projektu, na kterém se vývojáři mohou podílet: záměry DPL jsou implicitně schvalovány většinou členů projektu.

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, Mehdi Dogguy, Chris Lamb and Sam Hartman.

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” 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

KULTURA Flamewar, diskuse, která zachytí požár

“Flamewar” je mimořádně vášnivá debata, která často končí s lidmi napadajícími se navzájemm, jakmile všechny rozumné argumentace byly vyčerpána na obou stranách. Některá témata jsou častěji předmětem polemik než ostatní (volba textového editoru, “dáváte přednost vi nebo emacsu?”, je staré oblíbené). Tyto věci často vyvolávají velmi rychlé výměny emailů v důsledku velkého počtu lidí se stanoviskem k této záležitosti (všichni) a velmi osobní povahu takových námitek.

Obecně, nic zvlášť užitečného z takových diskusí nevzejde; Všeobecné doporučení je zůstat mimo takové debaty a asi rychle prolistovat jejich obsah, protože jejich čtení v plném rozsahu by bylo příliš časově náročné.

I když stanovy vytváří zdání demokracie, denní realita je zcela odlišná: Debian přirozeně dodržuje pravidla svobodného softwaru do-ocracie: ten, kdo dělá věci rozhoduje, jak je dělat. Mnoho času může být vyplýtváno debatováním o jednotlivých přínosech různých cest, jak přistupovat k problému; zvolené řešení bude to první, která je obojí - funkční a uspokojující..., které vyjde z času, který do něj způsobilá osoba vložila.

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”.

KULTURA Meritokracie, vláda znalostí

Meritokracie je forma vlády, v níž je autorita vykonávána těmi, kteří mají největší zásluhy. Pro Debian, jsou zásluhy měřítkem kompetence, která je sama o sobě, posuzována sledováním dřívějších činností jednoho nebo více lidí v rámci projektu (Stefano Zacchiroli, bývalý vedoucí projektu, hovoří o “do-okracii”, což znamená “moc pro ty, kteří věci dělají”). Jejich prostá existence dokazuje určitou úroveň kompetence; jejich úspěchy obecně je svobodný software, s dostupným zdrojovým kódem, který může být snadno přezkoumán ostatními k posouzení jejich kvality.

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ů.

KOMUNITA Začleňování nových správců

Tým, který má na starosti přijímání nových vývojářů, je pravidelně nejvíce kritizován. Je třeba uznat, že v průběhu let se debianovský projekt stává stále náročnějším pro vývojáře, které bude přijímat. Někteří lidé v tom mohou vidět nespravedlnost, musíme ale přiznat, že to, co se jevilo jako malá výzva na začátku se stalo výzvou mnohem větší ve společenství čítajícím více než 1 000 lidí, pokud jde o zajištění kvality a integrity všeho, co Debian produkuje pro své uživatele.

Dále, postup přijetí je ukončen přezkoumáním kandidatury malým týmem - account manažery Debianu. Tito manažeři jsou také obzvláště vystaveni kritice, protože mají konečné slovo v přijetí nebo odmítnutí dobrovolníka v rámci komunity vývojářů Debianu. V praxi, musí někdy zpozdit přijetí osoby, aby se dozvěděli více o činnosti projektu. Člověk může samozřejmě přispívat k Debianu i před přijetím za oficiálního vývojářáře tím, že je zaštiťován vývojáři současnými.

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“).

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.

Sledovcí systém chyb Debianu (Debian BTS) je používán velkými částmi projektu. Veřejná část (webové rozhraní) umožňuje uživatelům zobrazit všechny ohlášené chyby, s možností zobrazit seřazený seznam chyb vybraných podle různých kritérií, jako například: dotčený balíček, závažnost, stav, adresa ohlašovatele, adresa zodpovědného správce, tag, apod. Je také možné procházet celý historický výpis všech diskusí týkajících se jednotlivých chyb.

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

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

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.

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

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

ZPĚT K ZÁKLADŮM Co je to i18n a l10n?

“i18n” a “l10n” jsou zkratky slov “internacionalizace” a “lokalizace”, respektive, ponechání prvního a posledního písmena z každého slova a počet písmen uprostřed.

“Internacionalizování” programu spočívá v jeho modifikaci, kdy může být přeložen (lokalizován). To obnáší částečné přepsání programu původně napsaného pro fungování v jednom jazyku za účelem možnosti jeho otevření ve všech jazycích.

“Lokalizace” programu spočívá v překladu původních zpráv (často v angličtině) do jiného jazyka. Abychom toho dosáhli, musí být již program internacializován.

Abychom to shrnuli, internacionalizace připravuje software pro překlad, který je potom spuštěn lokalizací.

1.3.2.3. Sending fixes

More advanced users might be able to provide a fix to a program 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.

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

Všechny tyto příspěvkové mechanismy se stávají více efektivními díky chování uživatelů. Uživatelé jsou daleko tomu být skupinou izolovaných osob, jsou naopak komunitou, kde se spousta výměnných činností děje. Obzvláště sledujeme obdivuhodnou aktivitu na diskuzních emailových seznamech uživatelů, debian-user@lists.debian.org (7 – „Solving Problems and Finding Relevant Information“ se tomu detailněji věnuje).

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:

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

1.3.3. Týmy a podprojekty

Debian byl od samého počátku organizován kolem konceptu zdrojových balíčků, každý se svým správcem nebo skupinou správců. Časem se vytvořilo hodně pracovních týmů, zabezpečujících administrativu infrastruktury, řízení úkolů nepatřících k žádnému konlrétnímu balíčku (zajišťování kvality, zásady Debianu, instalace, apod.), spolu s posledními týmy, které vyrostly kolem podprojektů.

1.3.3.1. Současné podprojekty Debianu

Každému jeho vlastní Debian! Podprojekt je skupina dobrovolníků zajímajících se o přizpůsobení Debianu zvláštním požadavkům. Za výběrem podskupiny programů stojí jejich směřování k určité oblasti (vzdělávání, lékařství, multimediální tvorba, apod.), podprojekty jsou také mimo jiné zahrnuty ve zdokonalování existujících balíčků, balení chybějícího softwaru, adaptace instalátorů, tvoření zvláštní dokumentace.

SLOVNÍK Podprojekt a odvozená distribuce

Vývojový proces odvozené distribuce spočívá v začátcích s určitou verzí Debianu a k ní vytváření určitého počtu modifikací. Infrastruktura používaná pro tuto práci je zcela vně debianovského projektu. Zde nejsou nutné žádné zásady pro vylepšení plynoucí ze spolupráce. Tento rozdíl vysvětluje jak moc se může odvozená distribuce “odchylovat” od svého originálu a proč musejí pravidelně resynchronizovat svůj zdrojový kód, aby mohli těžit z upstreamových vylepšení.

Na druhou stranu, podprojekt se nemůže odchylovat, protože veškerá na něm vykonaná práce spočívá v přímém zdokonalování Debianu za účelem jeho adaptace ke zvláštnímu úkolu.

Nejznáměšjší distribucí odvozenou z Debianu je bezpochyby Ubuntu, ale je jich hodně. Pokud se chcete o nich dozvědět více podrobností a jejich pozici ve vztahu vůči Debianu, navštivte A – „Derivative Distributions“.

Zde je malý výběr současných podprojektů:

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, od Andrease Tilleho, věnuje se lékařství;
Debian Multimedia se zaobírá audiem a multimediální tvorbou;
Debian GIS, který se stará o aplikace Geografického informačního systému;
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. Administrativní týmy

Většina administrativních týmů je relativně uzavřená a nabírá nové členy interním zvolením. Nejlepším způsobem jak se stát jejich součástí je intelegentně asistovat současným členům a dávat najevo, že rozumíte jejich cílům a metodám práce.

Ftpmasteři mají na starosti oficiální archív debianovských balíčků. Obhospodařují program, který se přejímá balíčky poslané vývojáři a automaticky je po následné kontrole ukládá na referenční 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”.

SLOVNÍČEK Pseudo-package, monitorovací nástroj

Systém sledování chyb, původně vyvinutý pro spojení chyby s balíčkem Debianu, se v praxi osvědčil v zabezpečení dalších záležitostí: seznamů problémů k řešení nebo provádění úkolů bez provázanosti s konkrétním balíčkem Debianu.“Pseudo-packages” tedy dovolují jistým týmům používat systém sledování chyb bez spojení opravdového balíčku s jejich týmem. Každý tedy může hlásit záležitosti, které je zapotřebí řešit. Například BTS má ftp.debian.org vstup, který se používá k nahlašování a sledování problémů v oficiálním archivu balíčků nebo jednoduše k žádostem o odstranění balíčku. Obdobně,www.debian.org pseudo-package odkazuje na chyby na internetových stránkách Debianu a lists.debian.org shromažďuje všechny problémy týkající se mailing listů.

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

Tým Debian System Administrators (DSA) (debian-admin@lists.debian.org), jak už název napovídá, je zodpovědný za systémovou administraci řádky servrů používaných projektem. Zabezpečují optimální funkčnost všech základních služeb (DNS, Web, e-mail, shell, apod.), instalačního softwaru požadovaného vývojáři Debianu a provádějí veškerá preventivní bezpečnostní opatření.

NÁSTROJ Sledovač balíčků Debianu

Toto je jeden z Raphaëlových výtvorů. Základní myšlenkou je pro daný balíček nashromáždit co možná nejvíce inforamací na jedné stránce. Takže se dá rychle překontrolovat status programu, zjistit úloly, co se mají provést a nabídnout podporu. Proto tato stránka shromažďuje veškeré statistiky chyb, v každé distribuci verze, které jsou k dispozici, pokroky balíčku v testovací distribuci, status překladů popisů a šablon debconf, případnou dostupnost nových upstreamových verzí, poznámky o neshodách s nejnovější verzí Zásad Debianu, informaci o správci a další informace, které si správce přál uvést.

→ https://tracker.debian.org/

Emailová upisovací služba dovršuje toto webové rozhraní. Automaticky posílá následující vybrané informace na seznam: chyby a související diskuze, zpřístupnění nové verze na servrech Debianu, nové překlady zpřístupněné pro kontrolní čtení, apod.

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.

Další webové rozhraní, známé jako Přehled balíčků vývojáře Debianu (DDPO), poskytuje ke každému vývojáři souhrn statusů všech balíčků Debianu umístěných do jeho pravomoce.

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

Tyto dvě internetové stránky jsou vyvinuté a spravované skupinou zodpovědnou za zajišťování kvality v rámci Debianu (známou jako Debian QA).

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 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. 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.

KULTURA Git

Git je nástroj pro spolupráci na velkém množství souborů, za uchovávání historie změn. Bavíme se především o textových souborech, jako jsou zdrojové kódy programů. Pokud pár lidí pracuje společně na tom samém souboru, git může pouze zahrnovat zpracované rozdílnosti, pokud byly provedeny na rozdílných částech souboru. V opačném případě musí být tyto “konflikty” vyřešeny ručně.

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).

Za pomocí Gitu je snadné spravovat mnoho souběžných verzí projektu ve vývoji bez jejich vzájemného narušování. Tyto verze se nazývají větve. Tato symbolika se stromem je více než přiléhavá, protože vývoj programu je započat na společném kmeni. Když je dosaženo nějakého mezníku (jako je verze 1.0), vývoj pokračuje na dvou větvích: vývojová větev připravuje další vydání, zatímco údržbářská větev řídí aktualizace a opravy pro verzi 1.0.

Git je, v současnosti, nejpopulárnější systém pro kontrolu verzí, ale není jediný. Historicky, prvním široce používaným nástrojem byl CVS (Concurrent Versions System), ale měl několik omezení, která vedla k výskytu modernějších, volně dostupných alternativ. Mezi ně patří především subversion (svn), git, bazaar (bzr), a mercurial (hg).

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

→ http://subversion.apache.org/

→ http://git-scm.com/

→ http://bazaar.canonical.com/

→ http://mercurial.selenic.com/

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ů.

Nejdůležitějším týmem je asi ten pro instalační program Debianu, debian-installer, který zabezpečuje práci na důležitých součástech od svého počátku, roku 2001. Bylo zapotřebí bezpočet spolupracovnílů, protože je velmi náročné napsat jeden program, který je schopný nainstalovat Debian na různé architektury. Každá má svůj vlastní mechanismus bootování a svůj vlastní bootloader. Všechny tyto práce jsou koordinovány na poštovním seznamu debian-boot@lists.debian.org, pod taktovkou Cyrila Bruleboise.

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

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

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.

Mnoho týmů spolu musí splupracovat na aktivitě balíčkování: debian-qa@lists.debian.org se kupříkladu pokouší zajistit kvalitu projektu Debian na všech úrovních. Seznam debian-policy@lists.debian.org rozvíjí Zásady Debianu podle návrhů ze všech míst. Týmy, které mají na starosti některou z architektur (debian-architecture@lists.debian.org) sestavují všechny balíčky, adoptují je tak na své jednotlivé architektury, pokud je třeba.

Další týmy řídí nejdůležitější balíčky za účelem zajištění údržby aniž by naložili příliš velký náklad pouze na jedna ramena; toto je příklad knihovny jazyka C a debian-glibc@lists.debian.org, kompilátoru C na seznamu debian-gcc@lists.debian.org nebo Xorg na debian-x@lists.debian.org (tato skupina je také známá jako X Strike Force).