Product SiteDocumentation Site

1.3. Den interne driften av Debianprosjektet

De rikholdige sluttresultat fra Debian-prosjektet kommer parallelt fra arbeidet med infrastrukturen utført av erfarne Debians utviklere, fra den enkeltes og fellesskapets utviklingsarbeid i Debian-pakkene, og til tilbakemeldingene 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 sin tilgjengelige tid og lyst, er det gratis å bli involvert i en rekke team, 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 Debian Policy. Heldigvis finnes det mange verktøy som letter vedlikeholsdarbeidet. Utvikleren kan dermed fokusere på det spesielle i sin pakke, og på mer komplekse oppgaver, for eksempel å fjerne bugs.
Policyen, en vesentlig del av Debian prosjektet, slår fast normene som sikrer både kvaliteten på pakkene og perfekt interoperabilitet for distribusjonen. Takket være denne policyen, forblir Debian konsistent til tross for sin gigantiske størrelse. Denne politikken ligger ikke fast i stein, men utvikler seg stadig takket være forslag formulert på postliste. Endringer som det er enighet om blant alle interesserte parter, blir akseptert og brukes 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 bugs:
Politikken gir betydelig dekning av de tekniske aspektene ved pakkingen. Størrelsen på prosjektet reiser også organisatoriske problemer som er behandlet i Debian Constitution. Den slår fast en struktur og måtene for beslutningstaking. Med andre ord, et formelt styringssystem.
Dette utgangspunktet definerer et visst 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 kvaifisert flertall på tre fjerdedeler (75 %) av stemmene er nødvendig om vesentlige endringer skal gjøres (for eksempel avgjørelser med en innvirkning på Foundation Documents). Utviklerne velger årlig en «leder» til å representere seg i møter, og sikre intern koordinering mellom ulike team. Dette valget gir 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 den å representere i media, koordinere mellom «interne» team, og gi generell veiledning til prosjektet, innenfor det som utviklerne kan forholde seg til. DPLs synspunkter er implisitt godkjent av flertallet av prosjektet medlemmer.
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 begynnelsen er prosjektet i rekkefølge ledet av Ian Murdock, Bruce Perens, Ian Jackson, Wichert Akkerman, Ben Collins, Bdale Garbee, Martin Michlmayr, Branden Robinson, Anthony Towns, Sam Hocevar, Steve McIntyre, Stefano Zacchiroli and Lucas Nussbaum.
Konstitusjonen definerer også en «teknisk komité». Denne komiteens vesentlig rolle er å bestemme i tekniske anliggender når de involverte utviklerne ikke har kommet 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 avstemningen ved de ulike valg og om forskjellige vedtak.
Prosedyren for «allment vedtak» er helt detaljert utformet i konstitusjonen, fra den innledende diskusjonen, og perioden frem til den endelige opptellingen av stemmene. For ytterligere informasjon se:
Selv om konstitusjonen slår fast en likhet med demokrati, er den daglige virkeligheten ganske annerledes: Debian følger naturlig nok gjørokrati-reglene i gratis programvare: Den som gjør ting kommer til å bestemme hvordan de gjøres. Mye tid kan være bortkastet på å debattere de respektive fordeler ved forskjellige måter å nærme seg et problem. Den valgte løsningen vil være den første som både er funksjonell og tilfredsstillende ... og som vil komme ut av den tiden som en kvalifisert person har anvendt.
Dette er den eneste måten å få belønning på: Å gjøre noe nyttig, og vise at man har fungert godt. Mange Debian «administrative» lag opererer med egensupplering, og foretrekker frivillige som allerede effektivt har bidratt og bevist sin kompetanse. Offentligheten rundt arbeidet med disse teamene gjør det mulig for nye bidragsytere til å følge med og bistå uten noen spesielle tillatelser. Dette er grunnen til Debian blir ofte beskrevet som et «elitestyre».
Denne effektive arbeidsmetoden garanterer kvaliteten på bidragsyterne i Debian «nøkkel»team. Metoden er på ingen måte perfekt, og noen ganger er det de som ikke aksepterer denne arbeidsmåten. Utvalget av utviklere i teamene kan virke litt vilkårlig, eller til og med urettferdig. Videre har ikke alle den samme definisjonen av den tjeneste som forventes fra disse teamene. For noen er det uakseptabelt å måtte vente åtte dager for å komme med i en ny Debian-pakke, mens andre vil vente tålmodigi tre uker uten problem. Skjønt det er regelmessige klager fra misfornøyde om «kvaliteten på tjenesten» fra noen team.

1.3.2. Brukernes aktive rolle

Man kan lure på om det er relevant å nevne brukere blant dem som arbeider 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 å indikere problemer. Andre går enda lenger og sende inn ideer til forbedringer ved å sende en feilrapport med alvorlighetsgrad «wishlist», eller til og med sender inn rettelser til kildekoden som kalles «patcher» (se sidefelt DET GRUNNLEGGENDE Patch, måten å sende en fiks på).
I tillegg liker mange fornøyde brukere av tjenesten som tilbys av Debian å gi et eget bidrag til prosjektet. Da ikke alle har riktig kompetanse i programmering, kan de velge å hjelpe til med oversettelse og gjennomgang av dokumentasjon. Det er språkspesifikke postlister for å koordinere dette arbeidet.
Brukernes atferd har gjort alle disse verktøyene for bidrag mer effektive. Langt fra å bare være en samling av isolerte personer, er brukerne et ekte fellesskap der flere diskusjoner foregår. Vi merker oss spesielt imponerende aktivitet på brukerens postliste, (Kapittel 7, Å løse problemer og finne relevant informasjon drøftes dette i større detalj).
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.
Siden Debian ikke bruker midler til egenkampanjer, spiller brukerne en avgjørende rolle i spredningen av Debian, og sikrer at den blir kjent via munn til munn.
Denne metoden fungerer ganske godt, siden Debian-tilhengere finnes på alle fri programvare-nivåer: Fra installeringstreff (arbeidsgrupper der erfarne hjelper nykommere med å installere systemet) organisert av lokale Linux-brukergrupper (LGU-er «Linux User Groups»), til foreningstands på store teknikkarrangementer som berører 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:

1.3.3. Team og underprosjekter

Helt fra starten har Debian har vært organisert rundt begrepet kildepakker, hver med sin vedlikeholder eller gruppe vedlikeholdere. Mange arbeidsgrupper har dukket opp over tid, noe som sikrer administrasjon av infrastruktur og organisering av oppgaver som ikke er bestemt for en spesiell pakke (kvalitetssikring, Debian Policy, installerer, etc.). De siste i serien av team har vokst opp rundt delprosjekter.

1.3.3.1. Eksisterende Debian underprosjekter

Alle får sin egen Debian! Et delprosjekt er en gruppe frivillige som vil tilpasse Debian til spesielle behov. Utover valg av en undergruppe med programmer ment for et bestemt område (utdanning, medisin, multimediakonstruksjon, etc.), blir delprosjekter også involvert i å forbedre eksisterende pakker, få med manglende programvare, tilpasse installasjonsprogrammet, lage spesifikk dokumentasjon, og mer.
Her er et lite utvalg av aktuelle delprosjekter:
  • Debian-Junior, av Ben Armstrong, tilbyr et tiltalende og lettbrukt Debian-system for barn;
  • Debian-Edu, av Petter Reinholdtsen, er fokusert på å lage en spesialisert distribusjon for den akademiske verden;
  • Debian Med, av Andreas Tille, er dedikert til det medisinske feltet;
  • Debian Multimedia omhandler arbeid med lyd- og multimedia;
  • Debian-Desktop konsentrerer seg om skrivebordet, og koordinerer grafikk og illustrasjoner (artwork) for standardtemaet;
  • Debian GIS tar seg av Geographical Information Systems anvendelser og brukere;
  • Til slutt, Debian Accessibility, forbedrer Debian for å svare til kravene til mennesker med nedsatt funksjonsevne.
Denne listen vil mest sannsynlig med tiden fortsette å vokse, og med bedre forståelse av fordelene med Debian underprosjekter. Med full støtte av den gjeldende Debian infrastrukturen, kan de i praksis konsentrere arbeidet om det som gir reell merverdi, uten å bekymre seg om den gjenstående synkronisering med Debian, siden de er utviklet innenfor prosjektet.

1.3.3.2. Administrative team

De fleste administrative teamene 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.
FTP-mesterne er ansvarlig for det offisielle arkivet med Debian-pakker. De vedlikeholder programmene som mottar pakker fra utviklere og, etter noen sjekker, lagrer dem på referanseserveren (ftp-master.debian.org).
De må også kontrollere lisenser for alle nye pakker, for å sikre at Debian kan distribuere dem, før de kan inkluderes i de eksisterende basispakkene. Når en utvikler ønsker å fjerne en pakke, tar dette teamet det opp gjennom feilrapportsystemet ftp.debian.org «pseudo-package» («pseudo-pakker»).
Debian System Administrators (DSA) team , som man kunne forvente, er ansvarlig for systemadministrasjon for de mange servere som brukes av prosjektet. Teamet sikrer optimal funksjon for alle basetjenester (DNS, Internett, e-post, skall, etc.), installerer programvare som Debians utviklere ber om, og tar alle forholdsregler i forhold til sikkerhet.
Listmasters administrerer e-postserveren som håndterer e-postlister. De lager nye lister, håndterer returmeldinger (merknader om leveringsfeil), og opprettholder spamfiltre (mot uønsket masseutsendt e-post).
Hver bestemt tjeneste har sitt egen administrasjonsteam, vanligvis sammensatt av frivillige som har installert den (og også ofte programmert de tilsvarende verktøyene selv). Dette er tilfellet for feilrapportsystemet (BTS), sporingspakken, alioth.debian.org (FusionForge server, se sidefelt VERKTØY FusionForge, den sveitsiske armekniven for utvikling i samarbeid), tjenestene er tilgjengelige på qa.debian.org, lintian.debian.org, buildd.debian.org, cdimage.debian.org, og flere.

1.3.3.3. Utviklingsteam, tverrgående team

I motsetning til administrative team, er utviklingslagene ganske åpne, selv for bidragsytere utenfor. Selv om Debian ikke har en kallfølelse for å lage programvare, må prosjektet ha noen spesifikke programmer for å nå sine mål. Selvfølgelig, utviklet under en fri programvarelisens, bruker disse verktøyene metoder som er utprøvd i andre deler av det store frie programvareområdet.
Debian har utviklet lite programvare selv, men enkelte program har oppnådd en hovedrolle, og berømmelsen har spredt seg utenfor rammen av prosjektet. Gode eksempler er dpkg, Debians pakkestyringsprogram (det er faktisk en forkortelse av Debian PacKaGe, uttales som «dee-package»), og apt er 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). Deres team er imidlertid mye mindre, ettersom det er nødvendig med programmeringsdyktighet på et temmelig høyt nivå for å oppnå en samlet forståelse av driften av disse typene programmer.
Det viktigste teamet er nok det for Debians installasjonsprogram, debian-installer, som har utført et arbeid av meget viktig og betydningsfullt omfang etter fødselen 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å postlisten som Cyril Brulebois koordinerer.
Det lille debian-cd programteamet 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 team må samarbeide med andre om pakkeaktivitet: prøver, for eksempel, å sikre kvaliteten på alle nivåer i Debian-prosjektet. -listen utvikler Debian Policy etter forslag fra over det hele. De teamene 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 en skulder, administrerer andre team 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).