Het overvloedig resultaat geproduceerd door het Debian project leiden gelijktijdig af van het werk aan de infrastructuur uitgevoerd door ervaren Debian ontwikkelaars, van individueel of collectief werkt of ontwikkelaars van Debian pakketten en van feedback van gebruikers.
1.3.1. De Debian Ontwikkelaars
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:
Het Beleid bied een aanzienlijke dekking van de technische aspecten van pakketbeheer. De grote van het project brengt ook organisatorische problemen. Deze worden behandeld in de Debian Grondwet, welke een structuur en manier van beslissingen nemen tot stand brengt. In andere woorden een formele overheidsstructuur.
Deze grondwet definieert een aantal rollen en posities plus verantwoordelijkheden en autoriteiten voor ieder. Het is vooral noemenswaardig dat de Debian ontwikkelaars altijd de beslissing-nemende autoriteit hebben bij een stemming of resolutie, waarin een gekwalificeerde meerderheid van drie kwart (75%) van de stemmen vereist is om significantie wijzigingen te maken (zoals al deze met een impact op de Oprichtings-Documenten). Hoewel ontwikkelaars jaarlijks een "leider" verkiezen die hen vertegenwoordigt bij meetings en interne coördinatie tussen verschillende teams verzekert. Deze verkiezing is altijd een periode van intensieve discussies. De rol van deze leider is niet formeel gedefinieerd in enig document: kandidaten voor deze positie stellen meestal hun eigen definitie van deze positie voor. In de praktijk bevat de rol van de leider het zijn van een vertegenwoordiger tegenover de media, "interne" teams coördineren en algemene leiding bieden over het project, waarin de ontwikkelaar kan meegaan: De visies van de DLP zijn impliciet goedgekeurd door de meerderheid van de project leden.
specifiek heeft de leider echter autoriteit; hun stem lost gelijke-stemmingen op, ze kunnen iedere beslissing nemen welke niet al onder de autoriteit van iemand anders vallen en kunnen delen van hun verantwoordelijkheid delegeren.
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.
De grondwet definieert ook een "technische commissie". de essentiële rol van deze commissie is beslissingen nemen op technisch niveau wanneer de betrokken ontwikkelaars het niet eens kunnen worden waarvoor zijn verantwoordelijk zijn. Het is belangrijk te vermelden dat zij enkel optreden nadat ze zijn gevraagd door één van de partijen in kwestie.
Tenslotte, de grondwet definieert de positie van "project secretaris" welke de leiding heeft over stemmingen in verband met de verschillende verkiezingen en algemene resoluties.
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:
Zelfs indien deze grondwet een schijn van democratie vast stelt is de dagelijkse realiteit zeer verschillend: Debian volgt natuurlijk de vrije software regels van de doe-ocratie: diegene die iets doet mag beslissen hoe het te doen. Er kan veel tijd verspild worden tijdens het debatteren van respectievelijke voordelen van verschillende manieren va aanpak van een probleem; de gekozen oplossing zal de eerste zij die zowel functioneel is en voldoet... welke er uit zal komen hangt af van de tijd die een competent persoon er insteekt.
Dit is de enige manier om je strepen te verdienen: Doe iets nuttigs en toon aan dat je goed gewerkt hebt. Vele Debian “beheerders” team werken door coöptatie, verkiezen vrijwilligers die reeds effectief hebben bijgedragen en hun competentie hebben bewezen. De publieke aard van het werk van de teams maakt het mogelijk voor nieuwe bijdragers om te observeren en te beginnen met helpen zonder enige specifieke privileges. Dit is waarom Debian vaak wordt omschreven als en “meritocracy”.
Deze effectieve operationele methode garandeert de kwaliteit van de bijdragers binnen de “key” Debian teams. Deze methode is zeker niet perfect en occasioneel zijn er diegene die niet akkoord gaan met deze manier van werken. De selectie van ontwikkelaars geaccepteerd in de teams kan arbitrair of zelf oneerlijk lijken. Verder heeft niet iedereen dezelfde definitie van de te verwachten service van deze teams. Voor sommigen is het onacceptabel om acht dagen te moeten wachten voordat een nieuw Debian pakket word toegevoegd, terwijl anderen geduldig zonder probleem drie weken kunnen wachten. Als dusdanig zijn er regelmatig klachten van ontevreden mensen over de “kwaliteit van de service” van sommige teams.
1.3.2. De Actieve Rol van Gebruikers
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
Paragraaf 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.
Onder de oppervlakte is de Debian BTS gebaseerd op e-mail: alle informatie die het bewaart komt van berichten gezonden door de verschillende betrokken personen. Iedere e-mail gezonden naar
12345@bugs.debian.org
zal dus, worden toegewezen aan de geschiedenis van fout nummer 12345. Geautoriseerde personen kunnen een fout “sluiten” door een bericht te schrijven met de reden van de beslissen om de fout te sluiten te sturen naar
12345-done@bugs.debian.org
(een fout wordt gesloten wanneer het aangegeven probleem is opgelost or niet langer relevant is). Een nieuwe fout wordt gerapporteerd door een email te sturen naar
submit@bugs.debian.org
volgens een specifieke indeling welke het betreffende pakket identificeert. Het adres
control@bugs.debian.org
laat toe om alle “meta-informatie” gerelateerd tot een fout te bewerken.
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).
Dit gereedschap richt zich eerst op de ontwikkel versies, dit is waar de fouten opgelost worden. Veranderingen zijn in principe niet welkom in een stabiele versie van Debian, met zeer weinig uitzonderingen voor beveiligings- of andere belangrijke updates (als bijv. een pakket helemaal niet werkt). Een correctie van een kleine fout in een Debian pakket moet dus wachten op de volgende stabiele versie.
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.
Een patch is een bestand dat aanpassingen beschrijft aan één of meer referentie bestanden. Specifiek zal het een lijst bevatten met lijnen die toegevoegd of verwijderd moeten worden aan de code en (soms) ook lijnen genomen uit het referentie bestand om aanpassingen in de context te vervangen (ze staan identificatie van de plaatsing van aanpassingen toe indien de lijn nummers zijn verandert).
Het gereedschap dat gebruikt wordt om aanpassingen in zo'n bestand uit te voeren heet simpelweg patch
. Het gereedschap dat ze creëert is diff
, en wordt als volgt gebruikt:
$
diff -u bestand.oud bestand.nieuw >bestand.patch
Het bestand.patch
bestand bevat de instructies om de inhoud van bestand.oud
te veranderen in die van bestand.nieuw
. We kunnen het ook naar iemand toezenden, die het dan zelf kan gebruiken om het bestand.nieuw
na te maken uit de twee andere, zoals:
$
patch -p0 bestand.oud <bestand.patch
Het bestand, bestand.oud
, is nu identiek aan bestand.nieuw
.
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
Gebruikers helpen niet alleen zichzelf (en anderen) op technische problemen die rechtstreeks invloed hebben op hen, maar zij discussiëren ook over de beste manier op bij te dragen aan het Debian project en helpen het vooruit — discussies die vaak resulteren in voorstellen van verbeteringen.
Omdat Debian geen geld uitgeeft aan enige vorm van zelf-promotie en marketing campagnes, spelen zijn gebruikers een grote rol in de circulatie ervan, zijn roem verzekeren via mond op mond.
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. Team en Sub-Projecten
Debian is sinds zijn ontstaan georganiseerd geweest rond het concept van bron pakketten, ieder met zijn onderhouder of groep onderhouders. gedurende de jaren zijn er veel werk teams verschenen, die in het bijzonder de administratie van de infrastructuur van niet pakket specifieke taken verzekerend (kwaliteit verzekeren, Debian beleid, installatie programma, enz.), met de laatste reeks van teams die opgroeien rondt sub-projecten.
1.3.3.1. Bestaande Debian Sub Projecten
Aan ieder zijn eigen Debian! Een sub-project is een groep van vrijwilligers geïnteresseerd in het aanpassen van Debian aan specifieke noden. Voorbij de selectie van een sub-groep van programma's voor een bepaald domein (educatie, gezondheid, multimedia maken, enz.), sub-projecten zijn ook betrokken in het verbeteren van bestaande pakketten, pakketten met ontbrekende software, het installatie programma aanpassen, specifieke documentatie schrijven, en meer.
Hier is een kleine selectie van huidige sub-projecten:
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, door Andreas Tille, toegewijd aan het medische veld;
Debian Multimedia welke zich richt met audio en multimedia werk;
Debian GIS draagt zorg voor Geografische Informatie Systemen, toepassingen en gebruikers;
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. Administratieve Teams
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
).
Ze moeten ook de licenties van alle nieuwe pakketten controleren, om er zeker van te zijn dat Debian ze mag distribueren, voordat ze toegevoegd worden aan het corpus van bestaande pakketten. Wanneer een ontwikkelaar een pakket wenst te verwijderen, spreken ze dit team aan door het fouten-beheer systeem en het ftp.debian.org “pseudo-pakket”.
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.
De listamster beheert de email server die de mail lijsten beheert. Ze creëren nieuwe lijsten, behandelen bounces (meldingen van gefaalde aflevering) en beheren spam filters (ongewenste bulk email).
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. Ontwikkel Teams, Transversale teams
In tegenstelling tot administratieve teams zijn ontwikkel teams vrij open, zelfs voor bijdragers van buiten. Zelfs al voelt Debian zich niet geroepen om software te maken, heeft het project bepaalde specifieke programma's nodig om zijn doelen te bereiken. Natuurlijk ontwikkeld onder een vrije software licentie, deze gereedschappen maken gebruik van methodes uit de vrije software wereld die zich al bewezen hebben.
Debian heeft zelf weinig software ontwikkeld, maar bepaalde programmeurs hebben een hoofdrol opgenomen, en hun faam heeft zich verspreid ver voorbij het bereik van het project. Goede voorbeelden zijn dpkg
, het Debian pakket beheer programma (het is, in feiten een afkorting van Debian PacKaGe en is gewoonlijk uitgesproken als "dee-package"), en apt
een gereedschap om automatisch Debian pakketten te installeren samen met de afhankelijke software, en garandeert de consistentie van het systeem na een upgrade (de naam is een acroniem voor Advanced Package Tool). Hun teams zijn veel kleiner omdat er een redelijk hoge programmeer kennis nodig is om een algemeen begrip te krijgen van de werking van dit type programma's.
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.
Het (zeer kleine) debian-cd
programma team heeft zelfs een nog nederiger doel. Veel “kleine” bijdragers zijn verantwoordelijk voor hun architectuur, omdat de hoofd ontwikkelaar niet alle subtiele verschillen kent noch de exacte manier om het installatie programma vanaf de CD-ROM te starten.
Vele teams moeten samenwerken met anderen op het gebied van inpakken:
debian-qa@lists.debian.org
probeert, bij voorbeeld, de kwaliteit op alle niveaus van het Debian project te verzekeren. Het
debian-policy@lists.debian.org
mail lijst ontwikkeld Debian Beleid volgens de voorstellen vanaf iedere locatie. Het team dat de leiding heeft over iedere architectuur (
debian-architecture@lists.debian.org
) compileren alle pakketten en indien nodig passen ze het aan hun specifieke architectuur aan.