Product SiteDocumentation Site

1.3. Wewnętrzne prace w projekcie Debian

Obfite wyniki końcowe, uzyskane przez projekt Debian, pochodzą jednocześnie z działań w obrębie infrastruktury. Działania te wykonywane są przez doświadczonych twórców Debiana, począwszy od indywidualnych lub zbiorowych prac programistów, tworzących i modyfikujących pakiety Debiana, a kończąc na informacjach zwrotnych od użytkowników.

1.3.1. Twórcy Debiana (ang. the Debian Developers)

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.
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 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:
Polityka dostarcza znaczną ilość technicznych aspektów pakietowania. Rozmiar projektu zwiększa też problemy organizacyjne. Są one rozwiązywane w oparciu o Konstytucję Debiana, która ustanawia strukturę i środki do podejmowania decyzji. Innymi słowy — ustanawia formalny system zarządzania.
Konstytucja Debiana określa pewną liczbę ról i pozycji społecznych, a także odpowiedzialności i władze każdej z nich. Warto zwrócić uwagę na fakt, że twórcy Debiana zawsze mają najwyższą władzę decyzyjną podczas głosowania nad rezolucją ogólną, gdzie wymagana jest większość trzech czwartych (75%), aby dokonać znaczących zmian w konstytucji (takich, jak wpływ na Dokumenty Założycielskie). Jednakże, twórcy co roku wybierają „lidera", który ma ich reprezentować na mitingach, i który ma zapewniać wewnętrzną koordynację pomiędzy różnymi zespołami. Wybory lidera są zawsze okresem intensywnych dyskusji. Rola lidera nie jest formalnie zdefiniowana w żadnym dokumencie: kandydaci do tej pozycji zwykle proponują jej własną definicję. W praktyce oznacza to, że rola lidera obejmuje służenie jako przedstawiciel wobec mediów, koordynowanie zespołów „wewnętrznych" i dostarczanie całkowitego przewodnictwa projektom twórców. Poglądy lidera projektu Debian (ang. Debian Project Leader — DPL) są aprobowane bezpośrednio przez członków projektu.
Szczególnie, lider ma rzeczywistą władzę. Głosy liderów mają moc wiążącą; lider może podjąć dowolną decyzję, której wykonanie nie jest już w mocy kogoś innego i może delegować część swoich obowiązków.
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.
Konstytucja określa też „komitet techniczny". Zasadniczą rolą tego komitetu jest decydowanie o sprawach technicznych w sytuacji, gdy twórcy nie mogą ze sobą dojść do porozumienia w jakiejś kwestii technicznej. Mówiąc inaczej, komitet odgrywa rolę doradczą, gdy twórcy nie udaje się podjąć decyzji, za jaką jest odpowiedzialny. Warto zapamiętać, że komitet techniczny angażuje się tylko wtedy, gdy jest poproszony, aby być jedną ze stron potencjalnego konfliktu.
W końcu, konstytucja określa stanowisko „sekretarza projektu", który jest odpowiedzialny za organizację głosowania, związanego z różnymi wyborami i rezolucjami ogólnymi.
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:
Nawet jeśli ta konstytucja ustanawia pozory demokracji, codzienna rzeczywistość jest zupełnie inna: Debian w sposób naturalny i niewymuszony przestrzega zasad wolnego oprogramowania: kto robi jakieś rzeczy, ten decyduje o tym, jak je robić (tzw. zasada „rób-to-kracji"; w oryginale angielskim: do-cracy). Dużo czasu można zmarnować rozważając korzyści płynące z różnych sposobów podejścia do problemu; wybrane rozwiązanie będzie pierwszym, zarówno funkcjonalnym, jak i satysfakcjonującym, a jednocześnie podanym przez kompetentną osobę ... Jednak, okaże się to dopiero po pewnym czasie.
Jest to jedyny sposób, aby zasłużyć sobie na szacunek: zrobić coś pożytecznego i pokazać, że się pracowało dobrze. Wiele „administracyjnych" zespołów Debiana działa za pomocą kooptacji, preferując wolontariuszy, którzy już efektywnie przyczynili się do czegoś i potwierdzili swoje kompetencje. Publiczna natura pracy tych zespołów sprawia, że nowi współpracownicy mogą obserwować tę pracę i mogą zacząć pomagać bez specjalnych przywilejów. Z tego powodu Debian jest często określany mianem „merytokracji".
Ta efektywna metoda operacyjna gwarantuje jakość współpracowników w „kluczowych" zespołach Debiana. W żaden jednak sposób metoda ta nie jest doskonała i okazjonalnie ujawniają się również ci, którzy nie akceptują tego sposobu działania. Dobór twórców, akceptowanych w zespołach, może wydawać się trochę arbitralny lub nawet nieuczciwy. Co więcej, nie każdy ma te samą definicję służby na rzecz innych, oczekiwaną przez te zespoły. Dla niektórych nie do zaakceptowania jest fakt oczekiwania przez osiem dni na włączenie nowego pakietu Debiana, natomiast inni cierpliwie czekają na to samo przez trzy tygodnie, bez problemu. Tak więc, pojawiają się regularne skargi ze strony „niezadowolonych" na temat „jakości usług" tych zespołów.

1.3.2. Aktywna rola użytkowników

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 Sekcja 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.
Mówiąc bardziej szczegółowo, Debian BTS jest oparty na poczcie elektronicznej: wszystkie informacje, które przechowuje, pochodzą z wiadomości przesyłanych przez różne zaangażowane w ten proces osoby. Dowolny e-mail przesłany na adres będzie więc przypisany do historii błędu jako numer 12345. Autoryzowane osoby mogą "zamknąć" błąd pisząc wiadomość opisującą powody decyzji zamknięcia na adres (błąd jest zamknięty wtedy, gdy wskazany problem jest rozwiązany lub nie ma już znaczenia). Nowy błąd jest raportowany poprzez przesłanie e-mail na adres , zgodnie ze specyficznym formatem, który identyfikuje problematyczny pakiet. Adres pozwala na modyfikację wszystkich "meta-informacji", odnoszących się do błędu.
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).
Narzędzie do raportowania błędów jest nakierowane, przede wszystkim, na wersje testowe, i właśnie w tych wersjach błędy będą naprawiane. Zmiany w stabilnej wersji Debiana nie są mile widziane, z bardzo nielicznymi wyjątkami, dotyczącymi aktualizacji zabezpieczeń lub innych ważnych aktualizacji (jeśli, na przykład, pakiet nie działa w ogóle). Korekta drobnych błędów w pakiecie Debiana musi więc czekać do następnej, stabilnej wersji.

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.

1.3.2.3. Sending fixes

More advanced users might be able to provide a fix to a program by sending a patch.
„Łata" jest to plik opisujący zmiany dokonane w pliku lub plikach odniesienia. Szczególnie, łatka będzie zawierać listę wierszy, które mają być usunięte z kodu lub do niego dodane, jak też (czasami) wiersze wzięte z innego tekstu odniesienia, zamieniające modyfikacje kontekstowe (łatki pozwalają zidentyfikować umiejscowienia zmian, jeśli zmieniły się numery wierszy).
Narzędzie, używane do zastosowania modyfikacji, podanych w takim pliku, jest nazywane po prostu „łatką" (ang. patch). Narzędzie, które ją tworzy jest nazywane diff i używane jest w następujący sposób:
$ diff -u plik.stary plik.nowy >plik.łata
Plik plik.łata zawiera instrukcje do zamiany treści z pliku.starego na plik.nowy. Można go do kogoś przesłać, a ten ktoś może następnie ten plik użyć do odtworzenia pliku.nowego z dwóch innych, w ten sposób:
$ łata -p0 plik.stary <plik.łata
Plik, plik.stary, jest teraz identyczny z plikiem plik.nowy.
In practice, most software is 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

All of these contribution mechanisms are made more efficient by users' behavior. Far from being a collection of isolated persons, users are a true community within which numerous exchanges take place. We especially note the impressive activity on the user discussion mailing list, (Rozdział 7, Rozwiązywanie problemów i poszukiwanie informacji discusses this in greater detail).
Użytkownicy nie tylko pomagają sobie wzajemnie (i innym) w kwestiach technicznych, bezpośrednio ich dotyczących, ale także dyskutują na temat najlepszych sposobów, za pomocą których można przyczyniać się do projektu Debian. Dzięki temu pomagają poruszać się do przodu, a dyskusje prowadzą często do sugestii na temat ulepszeń.
Ponieważ Debian nie przeznacza funduszy na jakąkolwiek własną kampanię promocyjną, więc jego użytkownicy odgrywają istotną rolę w rozpowszechnianiu projektu, zapewniając mu renomę poprzez przekazywanie sobie informacji "z ust do ust".
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. Zespoły i Pod-Projekty

Debian jest zorganizowany, od samego początku, wokół koncepcji pakietów źródłowych. Każdy taki pakiet ma swojego opiekuna lub grupę opiekunów. Z czasem pojawiło się wiele zespołów roboczych, zapewniając w ten sposób administrację infrastruktury, zarządzanie zadaniami nie specyficznymi dla żadnego pakietu w szczególności (zapewnienie jakości, Polityka Debiana, Instalator, itd). Ostatnio pojawiają się najnowsze serie zespołów, które tworzą się wokół pod-projektów.

1.3.3.1. Istniejące Pod-Projekty Debiana

Dla każdego jego własny Debian! Pod-projekt utworzony przez grupę wolontariuszy zainteresowanych adaptowaniem Debiana do specyficznych potrzeb. Poza wyborem podgrupy programów, przeznaczonych do poszczególnych dziedzin (edukacja, medycyna, tworzenie multimediów, itd.), pod-projekty są również zaangażowane w ulepszanie istniejących pakietów, pakietowanie brakującego oprogramowania, adaptację instalatora, tworzenie specyficznej dokumentacji i inną działalność.
Oto niewielki wybór obecnych pod-projektów:
  • 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, stworzony przez Andreas Tille, dedykowany dziedzinom medycznym;
  • Debian Multimedia, który obsługuje pracę z audio i multimediami;
  • Debian GIS, który opiekuje się aplikacjami i użytkownikami systemów informacji geograficznej (ang. Geographical Information Systems);
  • 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. Zespoły Administracyjne

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).
Zanim włączą nowe pakiety do istniejącego korpusu pakietów Debiana — muszą też zweryfikować wszystkie licencje tych pakietów, aby upewnić się, że Debian może je rozpowszechniać. Gdy twórca pragnie usunąć jakiś pakiet, zwraca się z tym do zespołu za pomocą systemu śledzenia błędów (ang. bug tracking system) i wysyła "pseudo-pakiet" na ftp.debian.org.
The Debian System Administrators (DSA) team (), 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.
listmasters administrują serwerem e-mail, który zarządza listami dyskusyjnymi. Tworzą nowe listy, obsługują "odbicia" (ang. bounces), czyli uwagi o niedostarczeniu e-mail, i zarzadzają filtrami spamu (niechcianej, masowej poczty elektronicznej).
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. Zespoły twórców, Zespoły przekrojowe

Zespoły twórców, odmiennie niż zespoły administracyjne, są raczej szeroko otwarte, nawet dla zewnętrznych współpracowników. Nawet jeśli Debian nie ma powołania do tworzenia oprogramowania, projekt potrzebuje konkretnych programów, aby osiągnąć własne cele. Oczywiście narzędzia, opracowane na wolnych licencjach, wykorzystują metody już sprawdzone w świecie wolnego oprogramowania.
Debian opracował małe, własne oprogramowanie, ale niektóre programy przyjęły odrębne systemy, których sława wykroczyła poza zakres projektu. Dobrymi przykładami są: dpkg, program do zarządzania pakietami Debiana (w rzeczywistości, jest to skrót od angielskiej nazwy pakietu Debiana — PacKaGe — ogólnie wymawiany jako "dee package") i apt, narzędzie do automatycznej instalacji dowolnego pakietu Debiana i jego zależności, gwarantujące spójność systemu po aktualizacji (jego nazwa jest skrótem do ang. Advanced Package Tool — zaawansowane narzędzie pakietowania). Zespoły, odpowiedzialne za te narzędzia, są stosunkowo niewielkie, ponieważ do uzyskania całkowitego zrozumienia działania tego typu programów wymagany jest raczej wysoki poziom umiejętności programowania.
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 mailing list, under the direction of Cyril Brulebois.
Zespół (bardzo mały) programu debian-cd ma jeszcze bardziej skromny cel. Wielu "małych" współpracowników jest odpowiedzialnych za wyznaczona im "własną" architekturę sprzętową, ponieważ główny twórca nie może (nie musi) znać wszystkich subtelności oprogramowania, ani dokładnego sposobu uruchomienia instalatora z CD-ROM.
Wiele zespołów musi współpracować z innymi osobami w zakresie pakietowania: próbuje, na przykład, zapewniać jakość na wszystkich poziomach projektu Debian. Na liście rozwija się polityka Debiana, zgodnie z propozycjami od wszystkich zespołów. Zespoły odpowiedzialne za każdą architekturę () kompilują wszystkie pakiety, przystosowując je, w razie potrzeby, do konkretnej architektury.
Inne zespoły zarządzają najważniejszymi pakietami, aby w zapewnić ich utrzymanie bez nadmiernego obciążania pracą jednego współpracownika (jednego zespołu); tak jest w przypadku biblioteki C i kompilatora C, na liście , albo Xorg na liście (Ta grupa jest również znana jako X Strike Force).