Debianprojektets lyckade slutresultat skapas av arbete med infrastrukturen utförd av erfarna Debianutvecklare, från individuella, det gemensamma arbetet med Debianpaket och från användaråterkoppling.
1.3.1. Debian-utvecklarna
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
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:
Riktlinjerna tillhandahåller en ganska omfattande information de tekniska detaljerna av paketering. Projektstorleken leder också till organisatoriska problem; de tas om hand av Debians författning, vilken etablerar en struktur och medel för beslutsunderlag. Med andra ord ett formellt styrsystem.
Författningen definierar ett visst antal roller och positioner samt deras ansvar och begränsningar. Det är speciellt värt att uppmärksamma att Debian-utvecklare alltid har det slutlig beslutsrätt genom en röst där en kvaliciferad majoritet av tre fjärdedelar (75%) av rösterna krävs för att betydande ändringar ska ske (exempelvis som de med en effekt på grunddokumenten). Utvecklare väljer årligen en ”ledare” som representerar dem i möten och sköter intern koordination mellan olika team. Valet sker alltid i samband med en period av intensiva diskussioner. Ledarens roll är inte formellt definierad i något dokument; kandidater för denna post föreslår vanligen deras egna definition av rollen. I praktiken omfattar ledarrollen att vara en representant till media, att koordinera mellan ”interna” team och att tillhandahålla övergripande vägledning till projektet, som också relaterar till utvecklarna: projektledarens åsikter är implicit godkända av majoriteten av projektanvändarna.
Ledaren har ett starkt mandat; deras röst avgör jämna röster; de kan ta vilket beslut som helst som inte redan är under någon annans ansvar och de kan delegera vidare delar av sitt ansvar.
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.
Författningen definierar också en ”teknisk kommitté”. Kommitténs essentiella roll är att bestämma om tekniska spörsmål när de involverade utvecklarna inte har kommer fram till en kompromiss. Kommittén har också en rådgörande roll till utvecklare som misslyckas med att ta ett beslut för vilka de är ansvariga. Observera att de endast blir involverade när de bjuds in av en av parterna i fråga.
Slutligen definierar författningen rollen ”projektsekreterare” som ansvarar för organisationen av röster relaterat till de olika valen och allmänna resultaten.
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:
Även om författningen påminner om demokrati är den dagliga verkligheten ganska annorlunda: Debian följer naturligt de fria programvarureglerna om gör-det-okrati: den som utför saker bestämmer hur de ska ske. Massor av tid kan gå åt till att diskutera olika sätt att angripa ett problem; den valda lösningen kommer att vara den första som är både funktionell och tillfredsställande... vilket är resultatet utav den tid en kompetent person lägger ned på att genomföra det.
Det enklaste sättet att få erkännande är att göra något nyttigt och visa att man har utfört arbeta. Många ”administrativa” Debian-team sköts genom samarbeten, och de föredrar volontärer som redan har bidragit effektivt och visat sin kompetens. Den naturliga öppenheten i dessa teams arbete gör det möjligt för nya volontärer att observera och börja hjälpa till utan speciella privilegium. Det är därför Debian ofta beskrivs som en ”meritokrati”.
Denna praktiska metod garanterar kvaliteten av bidragsgivare i Debians nyckelteam. Metoden är inte på något sätt perfekt och det finns det de som inte accepterar detta arbetssätt. Valet av utvecklare som accepteras i team kan verka lite godtyckligt, eller till och med orättvist. Vidare, alla har inte samma definitioner av vad som kan förväntas från dessa team. För vissa är det oacceptabelt att behöva vänta 8 dagar för att få in ett nytt Debian-paket, medan andra kan vänta tålamodigt i 3 veckor utan ett problem. Det finns därför återkommande klagomål från missnöjda om ”tjänstekvaliteten” hos vissa team.
1.3.2. Användarnas aktiva roll
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
Avsnitt 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.
Under ytan är Debian BTS e-postbaserat: all information den lagrar kommer från meddelanden skickade av involverade personer. Varje e-postmeddelande skickat till
12345@bugs.debian.org
kommer att läggas till historiken för fel nummer 12345. Behöriga personer kan ”stänga” ett fel genom att skriva ett meddelande som beskriver orsakerna för beslutet att stänga
12345-done@bugs.debian.org
(ett fel är stängt när det beskrivna problemet inte längre är relevant). Ett nytt fel rapporteras genom att skicka ett meddelande till
submit@bugs.debian.org
i ett specfikt format som identifierar paketet. Adressen
control@bugs.debian.org
möjliggör redigering av meta-informationen relaterad till ett fel.
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).
Verktyget siktar in sig på utvecklingsversioner, vilket är var felen kommer att repareras. Ändringar är med få undantag inte välkomna i en stabil version av Debian, undantagsvis säkerhetsuppdateringar eller andra viktiga uppdateringar (exempelvis om ett paket inte alls fungerar). En felrättning av ett mindre fel i ett Debianpaket måste därför vänta in nästa stabila version.
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.
En programfix är en fil som beskriver ändringar för en eller flera referensfiler. Mer specifikt innehåller den rader att lägga till och ta bort ur koden, så väl (ibland) som kringliggande rader tagna från referenstexten, (de gör det möjligt att hitta var ändringarna skett om radantalet har ändrats).
Verktyget som används för att tillämpa ändringarna beskrivna i en sådan fil kallas patch
. Verktyget som skapar dem kallas diff
. Exempel på användning:
$
diff -u fil.gammal fil.nya >fil.patch
Filen fil.patch
innehåller instruktionerna för att ändra innehållet för fil.gammal
till fil.ny
. Vi kan skicka den till någon som sedan kan använda den för att återskapa fil.ny
från de två andra. Exempel:
$
patch -p0 fil.gammal <fil.patch
Filen fil.gammal
är nu identisk med fil.ny
.
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
Användare hjälper inte bara varandra (och andra) med tekniska problem som direkt påverkar dem, men de diskuterar också de bästa sätten att bidra till Debianprojektet och dess framtid - diskussioner som ofta slutar i förslag på förbättringar.
Eftersom Debian inte bekostar marknadsföring spelar dess användare en viktig roll i spridningen av 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:
1.3.3. Grupper och underprojekt
Debain har från början varit organiserat kring konceptet med källpaket, var och en med dess ansvariga eller grupp av ansvariga. Många arbetsgrupper har uppstått över tid, försäkrande skötsel av infrastrukturen, hantering av uppgifter som inte är knutna till något paket (kvalitetsförsäkran, Debians riktlinjer, installeraren med mera) och där den senaste tillväxten av grupper har skett runt underprojekt.
1.3.3.1. Befintliga Debian-underprojekt
Till var och en deras Debian! Ett underprojekt är en grupp frivilliga som vill anpassa Debian till speciella behov. Förutom att välja undergrupper av speciellt anpassade program för olika domäner (utbildning, medicin, mediaskapande med mera), är de också inblandade i att förbättra befintliga paket, paket som saknar programvara, anpassa installeraren, skapa specifik dokumentation och mycket annat.
Ett litet urval av aktuella underprojekt:
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, av Andreas Tille, dedikeras till det medicinska fältet;
Debian Multimedia har att göra med ljud- och mediaarbete;
Debian GIS handhar program för geografiska gnformationssystem och dess användare;
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. Administrativa grupper
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
).
För att försäkra sig om att Debian kan distribuera paket, verifiera de licenserna för alla nya paket, innan de inkluderas i andra paket. När en utvecklare önskar att ta bort ett paket, adresserar de denna grupp genom felrapporteringssystemet och pseudo-paketet ftp.debian.org.
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.
Listmasters har hand om e-postservern som hanterar e-postlistorna. De skapar nya listor, hanterar studsar (aviseringar om leveransproblem), och hanterar spam-filter (oönskade massutskick).
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. Utvecklargrupper, överlappande grupper
Olikt de administrativa grupperna är utvecklingsgrupperna generellt ganska öppna, även för bidrag utifrån. Även om Debians syfte är att skapa program behöver projektet ändå en del specifika sådana för att nå sina mål. Verktygen, självklart fri programvara, använder beprövade metoder i fri programvaru-världen.
Debian har utvecklat några få programvaror, men vissa program har fått en ledande roll, och deras namn har spritt sig långt utanför projektet. Bra exempel är dpkg
, Debians-pakethanteringssystem (det är faktiskt en förkortning avv Debian PacKaGe, och uttalas som ”dee-package”), och apt
, ett verktyg för att automatiskt installera Debianpaket med beroenden, och som försäkrar sig om systemets samstämmighet efter en uppgradering (namnet är en akronym för Advance Package Tool). Deras team är mycket mindre eftersom det krävs en ganska hög färdighet i programmering för att förstå hur dessa programtyper fungerar.
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.
Det lilla teamet debian-cd
har ett ännu blygsammare mål. Många små ”medarbetare” är ansvariga för deras arkitektur, eftersom huvudutvecklaren inte kan känna till alla variationer, eller det exakta sättet att starta installationen från CD-ROM-skivan.