Product SiteDocumentation Site

1.3. Hvordan Debian-prosjektet fungerer på innsiden

Det overflodshorn som Debian-prosjektet er bygger både på infrastrukturarbeidet som erfarne Debian-utviklere står for, på pakkearbeidet som individer og fellesskapet bidrar med, og ikke minst på tilbakemeldinger fra brukerne.

1.3.1. Debian-utviklerne

Debian-utviklere har ulike ansvarsområder, og som offisielle prosjektmedlemmer har de stor innflytelse på den retningen prosjektet tar. En Debian-utvikler er vanligvis ansvarlig for minst én pakke, men ut fra ledig tid og lyst, står de fritt til å bli involvert i utallige grupper og prosjekter, og dermed få mer ansvar i prosjektet.
Pakkevedlikeholdet er en relativt disiplinert aktivitet, veldokumentert og også regulert. Det må i praksis samsvare med alle standarder som er etablert av Debianretningslinjene. Heldigvis finnes det mange verktøy som letter vedlikeholdsdarbeidet. Utvikleren kan dermed fokusere på det spesielle i sin pakke, og på mer komplekse oppgaver, for eksempel å fjerne feil.
Retningslinjene, en vesentlig del av Debian prosjektet, slår fast normene som sikrer både kvaliteten på pakkene og perfekt samvirke i distribusjonen. Takket være disse retningslinjene, forblir Debian konsistent til tross for sin gigantiske størrelse. Disse retningslinjene er ikke skrevet i stein, men utvikler seg stadig takket være forslag formulert på e-postlisten . Endringer som det er enighet om blant alle interesserte parter, blir akseptert og tas inn i teksten av en liten gruppe vedlikeholdere som ikke har noe redaksjonelt ansvar (de bare fører inn de endringer det er enighet om blant de Debian-utviklere som er medlemmer av den ovennevnte listen). Du kan lese aktuelle endringsforslag på sporingssystemet for feil:
Praksisen dekker i stor grad de tekniske aspektene ved pakkingen. Størrelsen på prosjektet gir også organisatoriske problemer. Disse er også håndtert i Debians grunnlagsdokumenter. De slår fast struktur og hvordan beslutninger tas. Med andre ord, et formelt styringssystem.
Statuttene definerer et antall roller og posisjoner, alle med ansvar og myndighet. Det er spesielt verdt å merke seg at Debian-utviklere alltid har den endelige beslutningsmyndighet i en avstemning om oppløsning, mens et kvalifisert flertall på tre fjerdedeler (75 %) av stemmene er nødvendig for vesentlige endringer (for eksempel avgjørelser med innvirkning på grunnlagsdokumentene). Utviklerne velger årlig en «leder» til å representere seg i møter, og sikre intern koordinering mellom ulike grupper. Før dette valget er det alltid en periode med intense diskusjoner. Denne lederrollen er ikke formelt definert i noe dokument: Kandidater for denne oppgaven foreslår gjerne sin egen definisjon av lederoppgaven. I praksis omfatter rollen å representere i media, koordinere mellom «interne» grupper, og gi generelle anbefalinger til prosjektet, innenfor det som utviklerne kan forholde seg til. DPLs synspunkter er implisitt godkjent av flertallet av prosjektmedlemmer.
Helt konkret har lederen reell myndighet. Stemmeretten deres gir utslaget ved stemmeliket; de kan beslutte om det som ikke allerede er under noen andres ansvar, og lederen kan delegere deler av sitt ansvar.
Siden det ble startet har Debian-prosjektet vært ledet av først Ian Murdock, deretter Bruce Perens, Ian Jackson, Wichert Akkerman, Ben Collins, Bdale Garbee, Martin Michlmayr, Branden Robinson, Anthony Towns, Sam Hocevar, Steve McIntyre, Stefano Zacchiroli, Lucas Nussbaum, Neill McGovern, Mehdi Dogguy, Chris Lamb, Sam Hartman og Jonathan Carter.
Statuttene definerer også en «teknisk komité». Denne komiteens vesentlige rolle er å bestemme i tekniske anliggender når de involverte utviklerne ikke kommer til enighet seg imellom. Ellers spiller denne komiteen en rådgivende rolle for alle utviklere som ikke klarer å ta en beslutning der de er ansvarlige. Det er viktig å merke seg at komiteen bare involveres når den blir bedt om det av en av de berørte partene.
Til slutt definerer konstitusjonen rollen som «prosjektsekretær», som er ansvarlig for organiseringen av avstemmingen ved de ulike valg og plenumsvedtak.
«Plenumsvedtak»-prosedyren (GR) er gitt i beskrevet i vedtektene, fra den innledende diskusjonsperioden til den endelige telling av stemmene. Det mest interessante aspektet ved denne prosessen er at ved stemmegivning, må utviklere rangere de forskjellige valgmulighetene, og vinneren blir valgt med en Condorcet method (mer spesifikt, Schulze-metoden). For videre detaljer se:
Selv om statuttene etablerer noe som ligner på demokrati, er den daglige virkeligheten ganske annerledes: Debian følger naturlig nok gjørokrati-reglene i fri programvare: Den som gjør noe får bestemme hvordan det gjøres. Mye tid kan være bortkastet på å debattere fordeler og ulemper ved forskjellige måter å løse et problem. Den valgte løsningen vil være den første som både er funksjonell og tilfredsstillende ... og den kommer som et resultat av at en kompetent person har brukt tid på det.
Dette er den eneste måten å få belønning på: Å gjøre noe nyttig, og vise at man har fungert godt. Mange av Debians «administrative» grupper er selvrekrutterende og foretrekker frivillige som allerede effektivt har bidratt og demonstrert sin kompetanse. Åpenheten rundt arbeidet med disse gruppene gjør det mulig for nye bidragsytere å følge med og bistå uten noen spesielle tillatelser. Dette er grunnen til at Debian ofte blir beskrevet som et «elitestyre».
Denne effektive arbeidsmetoden garanterer kvaliteten på bidragsyterne i Debians «nøkkel»-grupper. Metoden er på ingen måte perfekt, og av og til er det noen som ikke aksepterer denne arbeidsmåten. Utvalget av utviklere i gruppene kan virke litt vilkårlig, eller til og med urettferdig. Videre har ikke alle den samme oppfatning av hva slags tjeneste som forventes fra disse gruppene. For noen er det uakseptabelt å måtte vente åtte dager for å få inn ny Debian-pakke, mens andre vil vente tålmodig i tre uker uten problem. Dermed er det regelmessig klager fra de som er misfornøyd om «tjenestekvaliteten» som enkelte gruppe leverer.

1.3.2. Brukernes aktive rolle

Man kan lure på om det er relevant å nevne brukere blant dem som bidrar innenfor Debian-prosjektet, men svaret er et klart ja: De har en avgjørende rolle i prosjektet. Langt fra å være «passive» kjører noen brukere utviklingsversjoner av Debian, og sender regelmessig feilrapporter for å melde om problemer. Andre går enda lenger og sender inn feilrapporter med ideer til forbedringer, med alvorlighetsgrad «wishlist». Noen brukere sender til og med inn rettelser til kildekoden som kalles «patcher» (se sidefelt Seksjon 1.3.2.3, «Å sende fikser»).

1.3.2.1. Rapportering av feil

Det grunnleggende verktøyet for å sende inn feil i Debian er Bug Tracking System (Debian BTS), som brukes i store deler av prosjektet. Gjennom den offentlige delen (webgrensesnittet) gis brukere innsyn i alle rapporterte feil. Listen over rapporterte feil kan sorteres etter ulike kriterier, for eksempel: Berørt pakke, alvorlighetsgrad, status, rapportørens adresse, adressen til ansvarlig vedlikeholder, merkelapp etc. Det er også mulig å bla gjennom hele den historiske oversikten over alle diskusjoner om hver feil.
Under overflaten er Debian BTS e-postbasert: All informasjon den lagrer kommer fra meldinger sendt av ulike berørte personer. All e-post sendt til vil dermed bli lagt til historien for feil nummer 12345. Autoriserte personer kan «lukke» en feil ved å skrive en melding som beskriver bakgrunnen for beslutningen om å lukke til (en feil lukkes når det indikerte problemet er løst, eller ikke lenger er relevant). En ny feil rapporteres ved å sende en e-post til i henhold til et bestemt format som identifiserer pakken den gjelder. Adressen tillater redigering av all «meta-informasjon» knyttet til en feil.
Debian BTS har også andre funksjonelle egenskaper, som for eksempel bruk av koder for merking av feil. For mer informasjon, se
Brukere kan også bruke kommandolinjen til å sende feilrapporter for en Debian-pakke med verktøyet reportbug. Det hjelper til med å sikre at feilen det gjelder ikke allerede er rapportert, og dermed hindre duplikater i systemet. Det minner brukeren på viktighetsdefinisjonene slik at rapporten skal være så presis som mulig (utvikleren kan alltid finjustere disse parametrene senere om nødvendig). Verktøyet hjelper til med å skrive og redigere en fullstendig feilrapport, uten at brukeren trenger å kunne syntaksen nøyaktig, ved å skrive den og tillate brukeren å redigere den. Rapporten blir så sendt via en e-posttjener (som standard, en ekstern kjørt av Debian, men reportbug kan også benytte en ekstern tjener).
Dette verktøyet er først og fremst rettet mot utviklingsversjoner, det er der feil rettes. Med få unntak er endringer I en stabil Debian-versjon ikke ønsket. Unntak gjøres for sikkerhetsoppdateringer og andre viktige oppdateringer (hvis for eksempel en pakke ikke fungerer i det hele tatt). En korreksjon av en mindre viktig feil i en Debian-pakke må dermed vente på neste stabile versjon.

1.3.2.2. Oversettelse og dokumentasjon

I tillegg liker mange fornøyde brukere av tjenesten som Debian tilbyr å bidra i prosjektet. De som ikke har relevant kompetanse i programmering kan hjelpe til med oversettelse og gjennomgang av dokumentasjon. Det er språkspesifikke e-postlister for å koordinere dette arbeidet.

1.3.2.3. Å sende fikser

Mer avanserte brukere kan være i stand til å gi en fiks til et program ved å sende en oppdatering.
En programfiks (patch) er en fil som beskriver forandringer som må utføres i en eller flere refererte filer. Spesielt vil patchen inneholde en liste over linjer som skal fjernes eller legges til i koden. Ofte følger også noen linjer fra originalteksten rundet stedet som skal endres (konteksten) med slik at endringsstedet kan finnes selv om linjenummeret i originalteksten har endret seg.
Verktøyet som brukes for å aktivere de endringer som er gitt i en slik fil, er ganske enkelt kalt patch. Verktøyet som lager slike kalles diff, og brukes som følger:
$ diff -u fil.old fil.new >fil.patch
Filen fil.patch har instruksjonene for å forandre innholdet i fil.old til fil.new. Den sender vi til andre som så kan bruke den til å lage (gjenskape) fil.new fra de to andre, slik:
$ patch -p0 fil.old <fil.patch
Filen fil.old er nå identisk med fil.new.
I praksis vedlikehoildes for tiden det meste av programvaren i Git-mapper, og bidragsytere vil dermed sansynligvis bruke git til å hente kildekoden og foreslå endringer. git diff vil generere en fil i samme format som det diff -u ville gjøre, og git apply kan gjøre det samme som patch.
Selv om resultatet fra git diff er en fil som kan deles med andre utviklere, det er vanligvis bedre måter å sende inn endringer på. Hvis utviklerne foretrekker å få programfikser via e-post, vil de vanligvis ha oppdateringer generert med git format-patch slik at de direkte kan integreres i mappen med git am. Dette bevarer innsendelsenes metainformasjon og gjør det mulig å dele flere innsendelser samtidig.
Denne e-postbaserte arbeidsflyten er fremdeles populær, men tenderer å bli erstattet med bruk av merge requests (eller pull requests) når programvaren ligger i en plattform som GitHub eller GitLab - og Debian bruker GitLab på sin salsa.debian.org-tjener. Når du har opprettet en konto på disse systemene, du fork mappen, oppretter effektivt en kopi av mappen i din egen konto, og deretter kan du klone den mappen, og skyve dine egne endringer inn i det . Derfra vil nettgrensesnittet foreslå at du sender inn en sammenslåingsforespørsel, og informere utviklerne om endringene dine, og gjør det enkelt for dem å gjennomgå og godta endringene dine med et enkelt klikk.

1.3.2.4. Andre måter å bidra på

Brukernes atferd har gjort alle disse bidrdagsmekanismene mer effektive. Langt fra å bare være en samling av isolerte personer, utgjør brukerne et ekte fellesskap der flere diskusjoner foregår. Vi merker oss spesielt imponerende aktivitet på brukerens e-postliste, (Kapittel 7, Problemløsning og oppsporing av relevant informasjon drøfter dette mer detaljert).
Ikke bare hjelper brukere seg selv (og andre) med tekniske problemer som direkte påvirker dem, men de kan også diskutere de beste måtene å bidra til Debian-prosjektet, og hjelpe det videre – diskusjoner som ofte resulterer i forslag til forbedringer.
Debian markedsfører ikke seg selv og derfor spiller brukerne en avgjørende rolle i utbredelsen av Debian, det skjer mest med jungeltelegrafen.
Denne metoden arbeider ganske godt, siden Debian-tilhengere finnes på alle nivåer i fri programvare-fellesskapet: Fra installasjonsfester (samlinger der erfarne hjelper nykommere med å installere systemet) organisert av lokale LUGer eller Linux-brukergrupper (også kjent som LUG - «Linux User Groups»), til forening-stands på store teknologiarrangementer som omhandler Linux, etc.
Frivillige lager plakater, brosjyrer, klistremerker og annet nyttig informasjonsmateriell om prosjektet, som de gjør tilgjengelig for alle, og som Debian formidler fritt fra sin hjemmeside og på sin wiki:

1.3.3. Teams, Blends, and Sub-Projects

From the start, Debian has been organized around the concept of source packages, each with its maintainer or group of maintainers. Many work teams have emerged over time, ensuring administration of the infrastructure, management of tasks not specific to any package in particular (quality assurance, Debian Policy, installer, etc.), with the latest series of teams growing up around sub-projects and blends.

1.3.3.1. Existing Debian Sub-Projects and Blends

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. While a "blend" might not be exactly the same, it works quite similar and also tries to provide a solution for groups of people intending to use Debian for a particular domain. One could say that "Debian Pure Blends" is the successor of sub-projects.
Here is a small selection of current released Debian Pure Blends:
  • 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 and educational world;
  • Debian Med, av Andreas Tille, er dedikert det medisinske feltet;
  • Debian Multimedia, which deals with audio and multimedia work;
  • Debian GIS, which takes care of Geographical Information Systems applications and users;
  • Debian Astro, for både profesjonelle og hobbyastronomer.
  • Debian Science jobber med å gi forskere og vitenskapspersonale en bedre opplevelse ved å bruke Debian;
  • Fredombox, laget for å utvikle, designe og tilby personlige tjenere som kjører fri programvare for privat og personlig kommunikasjon;
  • Debian-spill, tilbyr spill i Debian i form av alt fra arkade-spill til eventyr, simulasjon og strategi;
  • DebiChem, målrettet mot kjemi, tilbyr kjemiske tilpasninger og programmer.
The number of projects will most likely continue to grow with time and improved perception of the advantages of Debian Pure Blends. 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 grupper

De fleste administrative gruppene er relativt lukket, og rekrutterer bare ved selvrekruttering. Den beste måten å bli med, er å dyktig bistå nåværende medlemmer, og vise at du har forstått målene og metoder for drift.
ftpmasters er ansvarlig for det offisielle arkivet med Debian-pakker. De vedlikeholder programmene som mottar pakker fra utviklere og, etter noen sjekker, lagrer dem på referansetjeneren (ftp-master.debian.org).
De må også kontrollere lisenser for alle nye pakker, for å sikre at Debian har lov til å distribuere dem, før pakkene kan inkluderes i samlingen av tilgjengelige pakkene. Når en utvikler ønsker å fjerne en pakke, tar vedkommende det opp med denne gruppen via feilhåndteringssystemet og pseudo-pakken ftp.debian.org.
Debian-systemadministrator (DSA) team er, som man kan forvente, ansvarlig for systemadministrasjon for de mange tjenermaskinene prosjektet bruker. Gruppen sikrer optimal funksjon for alle basetjenester (DNS, Internett, e-post, skall, etc.), installerer programvare som Debian-utviklere ber om, og tar alle forholdsregler for sikkerheten.
Listmasters administrerer e-postserveren som håndterer e-postlister. De lager nye lister, håndterer returmeldinger (meldinger om leveringsfeil), og opprettholder spamfiltre (mot uønsket masseutsendt e-post).
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 for the bug tracking system (BTS), the package tracker, salsa.debian.org (GitLab server, see sidebar VERKTØY GitLab, Git mappevertskap og mye mer), the services available on qa.debian.org, lintian.debian.org, buildd.debian.org, cdimage.debian.org, etc.

1.3.3.3. Utviklingsgrupper, tverrgående grupper

I motsetning til administrative grupper, er utviklingsgruppene ganske åpne, selv for eksterne bidragsytere. Selv om Debian ikke ser det som sin oppgave å lage programvare, må prosjektet ha noen spesifikke programmer for å nå sine mål. Selvfølgelig bruker disse verktøyene, som er utviklet med en fri programvarelisens, metoder som er utprøvd i andre deler av fri programvareverden.
Debian har utviklet lite programvare selv, men enkelte program har inntatt en hovedrolle, og berømmelsen har spredt seg utenfor prosjektet grenser. Gode eksempler er dpkg, Debians pakkestyringsprogram (det er faktisk en forkortelse for Debian PacKaGe, uttales som «dee-package»), og apt, et verktøy for automatisk å installere alle eventuelle Debian-pakker med sine avhengigheter (gjensidig avhengig av), og garanterer at de er forenlige med systemet etter en oppgradering (navnet er en forkortelse for Advanced Package Tool). Gruppene deres er imidlertid mye mindre, ettersom det er nødvendig med programmeringsdyktighet på et temmelig høyt nivå for å oppnå en samlet forståelse av hvordan denne typene programmer fungerer.
Den viktigste gruppen er nok den for Debians installasjonsprogram, debian-installer, som har utført et arbeid av meget viktig og betydningsfullt omfang etter oppstarten i 2001. Det var nødvendig med mange bidragsytere, da det er vanskelig å skrive et enkelt program som installerer Debian på et dusin forskjellige arkitekturer. Hver og en har sin egen mekanisme for oppstart, og sin egen oppstartslaster. Alt dette arbeidet er koordinert på e-postlisten og koordineres av Cyril Brulebois.
Den lille gruppen til programmet debian-cd har en enda mer beskjeden målsetting. Mange «små» bidragsytere har ansvar for sin arkitektur, siden hovedutvikleren ikke kan kjenne alle finesser, og heller ikke den nøyaktige måten å starte installasjonsprogrammet fra CD-ROM på.
Mange grupper må samarbeide med andre om pakkeaktivitet. For eksempel som prøver å sikre kvaliteten på alle nivåer i Debian-prosjektet. Et annet er -listen som utvikler Debian-retningslinjene etter forslag som kommer fra hele Debian-prosjektet. De gruppene med ansvaret for hver arkitektur () setter sammen alle pakkene, og tilpasser dem til sin bestemte arkitektur, hvis det trengs.
For å sikre vedlikeholdet uten å plassere for tung bør på bare et par skuldre, administrerer andre grupper de viktigste pakkene. Dette er tilfelle med C-biblioteket og , og C biblioteket på -listen, eller Xorg på (denne gruppen er også kjent som X Strike Force).