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 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, acquiring, thus, 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 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:
Reglene 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.
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 and Chris Lamb.
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.
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:
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 DET GRUNNLEGGENDE Patch, måten å sende en fiks på).
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.
Brukerne har utnyttet disse verktøyene til effektivt å bidra. 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 fungerer 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 Linux-brukergrupper (også kjent som LUG - «Linux User Groups»), til foreningsstands på store teknologisamlinger som har med Linux å gjøre, 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 og underprosjekter

Helt fra starten av har Debian vært organisert rundt begrepet kildepakker, hver med sin vedlikeholder eller gruppe av vedlikeholdere. Mange arbeidsgrupper har dukket opp over tid, noe som sikrer administrasjon av infrastruktur og organisering av oppgaver som ikke gjelder en enkeltpakke (kvalitetssikring, Debian-retningslinjene, installerer, etc.). De siste i rekken av grupperinger har vokst opp rundt delprosjekter.

1.3.3.1. Eksisterende Debian-underprosjekter

En Debian til hver i sær! Et underprosjekt er en gruppe frivillige som vil tilpasse Debian til spesielle behov. Utover valg av et utvalg med programmer ment for et bestemt område (utdanning, medisin, lage multimedia, etc.), blir underprosjekter også involvert i å forbedre eksisterende pakker, få med manglende programvare, tilpasse installasjonsprogrammet, lage spesifikk dokumentasjon, med mer.
Her er et lite utvalg av aktuelle underprosjekter:
  • Debian-Junior, av Ben Armstrong, tilbyr et tiltalende og lettbrukt Debian-system for barn;
  • Debian-Edu, av Petter Reinholdtsen, er fokusert på å lage en distribusjon spesialisert for den akademiske verden;
  • Debian Med, av Andreas Tille, er dedikert 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 geografiske informasjonssystemer og deres brukere;
  • Til slutt, Debian Accessibility, forbedrer Debian for å dekke kravene som mennesker med nedsatt funksjonsevne stiller.
Denne listen vil mest sannsynlig fortsette å vokse etter hvert som tiden går og vi får bedre forståelse av fordelene med underprosjekter i Debian. Med full støtte fra den gjeldende Debian infrastrukturen, kan undergrupppene i praksis konsentrere arbeidet om det som gir reell merverdi, uten å bekymre seg om den gjenstående synkronisering med Debian, siden de utvikles som del av prosjektet.

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.
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 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-gruppen (DSA) er, som man kunne forvente, ansvarlig for systemadministrasjon for de mange tjenermaskinene prosjektet bruke. Gruppen sikrer optimal funksjon for alle basetjenester (DNS, Internett, e-post, skall, etc.), installerer programvare som Debian-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 (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 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. 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).