Product SiteDocumentation Site

1.3. Wewnętrzne działania projektu 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 deweloperó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. Deweloperzy Debiana

Deweloperzy Debiana mają różne odpowiedzialności. Jako oficjalni członkowie projektu mają duży wpływ na kierunek, w jakim podąża projekt. Ogólnie, deweloper Debiana jest odpowiedzialny przynajmniej za jeden pakiet, lecz ta odpowiedzialność jest zależna od ilości czasu, jaką może deweloper poświęcić projektowi, i od jego indywidualnych potrzeb i możliwości twórczych. Deweloperzy mają wolny wybór, jeśli chodzi o rodzaj zaangażowania się w projekt i liczne zespoły tego projektu. Im większą aktywność przejawia deweloper, tym więcej odpowiedzialności uzyskuje wewnątrz projektu.
Utrzymywanie pakietów jest działalnością poddaną pewnym ograniczeniom proceduralnym, które są dobrze udokumentowane lub nawet regulowane. W rezultacie, aktywność, którą często określa się terminem "opieka nad pakietami" (stąd określenie "opiekun pakietu" – ang. package maintainer) musi być zgodna ze wszystkimi standardami ustanowionymi przez Politykę Debiana (ang. Debian Policy). Na szczęście, jest wiele narzędzi, które ułatwiają pracę opiekunów pakietów. Deweloper może więc skupić się na specyfice swojego pakietu, i na innych, bardziej złożonych zadaniach, takich jak śledzenie i likwidowanie błędów.
Polityka, zasadniczy element Projektu Debian, ustanawia normy zapewniające zarówno jakość pakietów, jak i doskonałą interoperacyjność dystrybucji. Dzięki swojej Polityce, Debian pozostaje spójny, niezależnie od gigantycznego rozmiaru. Ta polityka nie jest niezmienna, lecz podlega ewolucji dzięki propozycjom, formułowanym na liście dyskusyjnej . Poprawki, uzgadniane przez wszystkie zainteresowane strony, są akceptowane i wprowadzane do tekstu Polityki poprzez małą grupę opiekunów, posiadających odpowiedzialność wydawniczą (wprowadzają oni tylko te poprawki, które są uzgodnione przez deweloperów Debiana — członków wyżej wspomnianej listy). Bieżące propozycje poprawek można przeczytać w systemie śledzenia błędów:
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 dla każdej z nich. Szczególnie warto zwrócić uwagę na fakt, że deweloperzy 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, deweloperzy rokrocznie 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, ze rola lidera obejmuje służenie jako przedstawiciel wobec mediów, koordynowanie zespołów "wewnętrznych" i dostarczanie całkowitego przewodnictwa projektom deweloperów. Poglądy DPL (ang. Debian Project Leader — lider projektu Debian) są bezpośrednio aprobowane 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.
Od samego początku, projekt był pomyślnie prowadzony przez liderów, którymi byli kolejno: Ian Murdock, Bruce Perens, Ian Jackson, Wichert Akkerman, Ben Collins, Bdale Garbee, Martin Michlmayr, Branden Robinson, Anthony Towns, Sam Hocevar, Steve McIntyre, Stefano Zacchiroli i Lucas Nussbaum.
Konstytucja określa też 'komitet techniczny". Zasadniczą rolą tego komitetu jest decydowanie o sprawach technicznych w sytuacji, gdy deweloperzy nie mogą ze sobą dojść do porozumienia w jakiejś technicznej kwestii. Mówiąc inaczej, komitet odgrywa rolę doradczą, gdy deweloperowi 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 organizacje głosowania, związanego z różnymi wyborami i rezolucjami ogólnymi.
Procedura "rezolucji ogólnej" jest szczegółowo określona w konstytucji, od okresu wstępnej dyskusji, aż do końcowego liczenia głosów. Więcej szczegółów można znależć pod adresem:
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 jako "merytokracja".
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 deweloperó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 tych "niezadowolonych" na temat "jakości usług" tych zespołów.

1.3.2. Aktywna rola użytkowników

Można się zastanawiać, czy warto zaliczać "zwykłych" użytkowników do tych współpracowników, którzy działają wewnątrz projektu Debian. Odpowiedzią jest definitywne TAK: odgrywają oni kluczową rolę w tym projekcie. Niektórzy użytkownicy, będąc dalekimi od bycia "pasywnymi", uruchamiają testowe wersje Debiana i regularnie wypełniają raporty o błędach, wskazując na problemy. Inni idą jeszcze dalej i przesyłają pomysły ulepszeń wypełniając raport o błędzie zawierający "listę życzeń" lub nawet przesyłają poprawki kodu źródłowego, zwane "łatkami" (ang "patches"). Zobacz pasek boczny WRACAJĄC DO PODSTAW "Łatka", sposób na wysłanie poprawki.
Dodatkowo, wielu zadowolonych użytkowników usługi oferowanej przez Debian chciałoby przyczynić wnieść swój wkład do projektu. Ponieważ nie każdy ma odpowiednie poziom doświadczenia w programowaniu, może więc wybrać pomoc w tłumaczeniu i dokonywaniu przeglądów dokumentacji. Istnieją listy dyskusyjne, specyficzne dla poszczególnych języków, które koordynują tę pracę.
Wszystkie te mechanizmy współpracy działają bardziej efektywnie dzięki zachowaniom użytkowników. Użytkownicy, których w żaden sposób nie można określić mianem zbioru wyizolowanych osób, tworzą prawdziwą społeczność, w której mają miejsce liczne wymiany. Szczególnie chcemy zwrócić uwagę na imponującą aktywność na liście dyskusyjnej (Rozdział 7, Rozwiązywanie problemów i poszukiwanie informacji omawia to bardziej szczegółowo).
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".
Metoda ta działa całkiem dobrze, ponieważ fanów Debiana można znaleźć na wszystkich poziomach społeczności wolnego oprogramowania: od spotkań instalacyjnych (są to warsztaty, podczas których doświadczeni użytkownicy pomagają początkującym w instalacji systemu), które są organizowane przez lokalne "Grupy Użytkowników Linuksa" (ang. "Linux User Groups" — LUG), na dużych konwencjach stowarzyszeń dotyczących Linuksa kończąc.
Wolontariusze tworzą plakaty, broszury, naklejki i inne przydatne materiały promocyjne w ramach projektu, które udostępniają wszystkim, a które Debian dostarcza za darmo na swojej stronie internetowej:

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

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.
Here is a small selection of current sub-projects:
  • 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 world;
  • Debian Med, by Andreas Tille, dedicated to the medical field;
  • Debian Multimedia which deals with audio and multimedia work;
  • Debian-Desktop which focuses on the desktop and coordinates artwork for the default theme;
  • Debian GIS which takes care of Geographical Information Systems applications and users;
  • Debian Accessibility, finally, improving Debian to match the requirements of people with disabilities.
This list 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. Administrative Teams

Most administrative teams are relatively closed and recruit only by cooptation. 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).
They must also verify the licenses of all new packages, in order to ensure that Debian may distribute them, prior to including them in the corpus of existing packages. When a developer wishes to remove a package, they address this team through the bug tracking system and the ftp.debian.org “pseudo-package”.
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.
The listmasters administer the e-mail server that manages the mailing lists. They create new lists, handle bounces (delivery failure notices), and maintain spam filters (unsolicited bulk e-mail).
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, alioth.debian.org (FusionForge server, see sidebar TOOL FusionForge, the Swiss Army Knife of collaborative development), the services available on qa.debian.org, lintian.debian.org, buildd.debian.org, cdimage.debian.org, etc.

1.3.3.3. Development Teams, Transversal Teams

Unlike administrative teams, the development teams are rather widely open, even to outside contributors. Even if Debian does not have a vocation to create software, the project needs some specific programs to meet its goals. Of course, developed under a free software license, these tools make use of methods proven elsewhere in the free software world.
Debian has developed little software of its own, but certain programs have assumed a starring role, and their fame has spread beyond the scope of the project. Good examples are dpkg, the Debian package management program (it is, in fact, an abbreviation of Debian PacKaGe, and generally pronounced as “dee-package”), and apt, a tool to automatically install any Debian package, and its dependencies, guaranteeing the consistency of the system after an upgrade (its name is an acronym for Advanced Package Tool). Their teams are, however, much smaller, since a rather high level of programming skill is required to gain an overall understanding of the operations of these types of programs.
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.
The (very small) debian-cd program team has an even more modest objective. Many “small” contributors are responsible for their architecture, since the main developer can not know all the subtleties, nor the exact way to start the installer from the CD-ROM.
Many teams must collaborate with others in the activity of packaging: tries, for example, to ensure quality at all levels of the Debian project. The list develops Debian Policy according to proposals from all over the place. The teams in charge of each architecture () compile all packages, adapting them to their particular architecture, if needed.
Other teams manage the most important packages in order to ensure maintenance without placing too heavy a load on a single pair of shoulders; this is the case with the C library and , the C compiler on the list, or Xorg on the (this group is also known as the X Strike Force).