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, thus acquiring more responsibilities within the project.

→ https://www.debian.org/devel/people

→ https://www.debian.org/intro/organization

→ https://wiki.debian.org/Teams

VERKTØY Utviklerdatabase

Debian has a database including all developers registered with the project, and their relevant information (address, telephone, geographical coordinates such as longitude and latitude, etc.). Some of the information (first and last name, country, username within the project, IRC username, GnuPG key, etc.) is public and available on the Web.

→ https://db.debian.org/

De geografiske koordinatene gjør det mulig å lage et kart der en finner alle utviklere over hele verden. Debian er virkelig et internasjonalt prosjekt: Utviklerne finnes på alle kontinenter, selv om de fleste er i «vestlige land».

Figur 1.1. Debianutviklerne er spredt over hele verden

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.

→ https://www.debian.org/doc/debian-policy/

DET GRUNNLEGGENDE Pakkevedlikehold, utviklerens oppgave

Å vedlikeholde en pakke innebærer først «å pakke» et program. Konkret betyr dette å avgjøre hvordan installasjonen skal gjøres, slik at når den er installert, vil dette programmet fungere og være i samsvar med de regler som Debian-prosjektet setter for seg selv. Resultatet av denne operasjonen lagres i en .deb fil. Effektiv installasjon av programmet vil da ikke kreve mer enn å pakke ut dette komprimerte arkivet, og kjøre pre- eller post-installasjonsskript som er inkludert.

Etter denne første fasen, starter selve vedlikeholdssyklusen: Å forberede oppdateringer for å følge den nyeste versjonen av Debianretningslinjene, fikse innrapporterte feil og inkludere nye «oppstrøms» versjoner av programmet som naturligvis fortsetter å utvikle seg samtidig. For eksempel, ved tidspunktet for den første pakkingen var programmet versjon 1.2.3. Etter noen måneder med utvikling, slipper de opprinnelige forfatterne en ny stabil versjon, nummerert 1.4.0. På dette punktet bør Debians vedlikeholder oppdatere pakken, slik at brukerne kan dra nytte av den siste stabile versjonen.

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:

→ https://bugs.debian.org/debian-policy

FELLESSKAP Retningslinjenes redaksjonelle prosess

Anyone can propose an amendment to the Debian Policy just by submitting a bug report with a severity level of “wishlist” against the debian-policy package. The process that then starts is documented in https://www.debian.org/doc/debian-policy/ap-process.html: if it is acknowledged that the problem revealed must be resolved by creating a new rule in the Debian Policy, a discussion begins on the debian-policy@lists.debian.org mailing list until consensus is reached and a proposal issued. Someone then drafts a desired amendment and submits it for approval (in the form of a patch to review). As soon as two other developers approve the fact that the proposed amendment reflects the consensus reached in the previous discussion (they “second” it), the proposal can be included in the official document by one of the debian-policy package maintainers. If the process fails at one of these steps, the maintainers close the bug, classifying the proposal as rejected.

DEBIAN-RETNINGSLINJER Dokumentasjonen

Dokumentasjonen for hver pakke er lagret i/usr/share/doc/pakke/. Denne katalogen inneholder ofte en README.Debian-fil som beskriver de Debian-spesifikke tilpasninger som den som vedlikeholder pakken har laget. Det er derfor lurt å lese denne filen før endring av oppsett, for å dra nytte av deres erfaringer. Vi finner også en changelog.Debian.gz-fil som beskriver endringene en Debian-vedlikeholder har gjort fra en versjon til den neste. Dette er ikke å forveksles med changelog.gz-fil (eller tilsvarende), som beskriver endringene som gjøres av utviklere oppstrøms. Copyright-filen inneholder informasjon om forfatterne og lisensen som dekker programvaren. Endelig kan vi også finne en fil som heter NEWS.Debian.gz som lar Debian-utvikleren formidle viktig informasjon om oppdateringer. Hvis apt-listchanges er installert, vises meldingene derfra automatisk. Alle andre filer er spesifikke for den aktuelle programvaren. Vi ønsker spesielt å nevne underkatalogen examples som ofte inneholder eksempler på oppsettsfiler .

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, Chris Lamb and Sam Hartman.

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:

→ http://www.debian.org/devel/constitution.en.html

KULTUR Nettkrangel, diskusjonen som tar fyr

En «nettkrangel» er en lidenskapelig debatt, som ofte ender opp med at personangrep når all fornuftig argumentasjon er oppbrukt. Enkelte temaer er oftere gjenstand for polemikk enn andre (valg av tekst editor, «foretrekker du vi eller emacs?» er en gammel favoritt). Sakene provoserer ofte frem svært raske e-postutvekslinger på grunn av det store antallet mennesker med en mening om saken (alle), og sakenes svært personlige karakter.

Vanligvis kommer det Ingenting spesielt nyttig ut av slike diskusjoner. En generell anbefaling er å holde seg unna, kanskje raskt skumme gjennom innholdet. Å debattene lese i sin helhet er for tidkrevende.

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».

KULTUR Elitestyre, kunnskapsregimet

I elitestyre utøves myndighet av dem som gir størst bidrag. For Debian er bidraget et mål på kompetanse, der bidraget vurderes av en eller flere andre personer i prosjektet (Stefano Zacchiroli, en tidligere prosjektleder, snakker om «gjørokrati», som betyr «makt til dem som får ting gjort»). Deres blotte eksistens viser et visst kompetansenivå: det de har bidratt med er fri programvare med tilgjengelig kildekode som kan vurderes av fagfeller for å sjekke kvaliteten.

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.

FELLESSKAP Integrasjon av nye vedlikeholdere

Gruppen med ansvar for opptak av nye utviklere er oftest kritisert. Man må erkjenne at etter hvert som årene går, krever Debian-prosjektet mer og mer av utviklerne. Noen ser det som litt urettferdighet. Men når en skal sikre kvaliteten og integriteten til alt som Debian produserer for sin brukere må vi innrømme at det som bare var små utfordringer i begynnelsen, har blitt mye større i et fellesskap med over 1000 deltakere.

Godkjenningsprosedyren avsluttes videre med en vurdering av en kandidat utført av et lite team: Debians kontoadministratorer. Disse lederne er spesielt utsatt for kritikk, siden de avgjør om en frivillig skal innlemmes i eller avvises fra Debians utviklersamfunn. I praksis må de noen ganger utsette godkjenningen av en person til de har lært mer om driften av prosjektet. Man kan selvsagt bidra til Debian før en er akseptert som en offisiell utvikler, ved å samarbeide med eksisterende utviklere.

1.3.2. Brukernes aktive rolle

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 Seksjon 1.3.2.3, «Sending fixes»).

1.3.2.1. Reporting bugs

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.

Debians sporingssystem for feil, Bug Tracking System (Debian BTS), 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 12345@bugs.debian.org 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 12345-done@bugs.debian.org (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 submit@bugs.debian.org i henhold til et bestemt format som identifiserer pakken den gjelder. Adressen control@bugs.debian.org tillater redigering av all «meta-informasjon» knyttet til en feil.

The Debian BTS has other functional features, as well, such as the use of tags for labeling bugs. For more information, see

→ https://www.debian.org/Bugs/

ORDFORRÅD Feilens alvorlighetsgrad

Alvorlighetsgraden til en feil tilordner formelt en viss tyngde til det rapporterte problemet. For ikke alle feil er like viktige. For eksempel er en skrivefeil på en manualside ubetydelig sammenlignet med et sikkerhetsproblem i tjenerprogramvaren.

Debian uses an extended scale to describe the severity of a bug. Each level is defined precisely in order to facilitate the selection thereof.

→ https://www.debian.org/Bugs/Developer#severities

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).

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. 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.

→ https://lists.debian.org/i18n.html

→ https://www.debian.org/international/

DET GRUNNLEGGENDE Hva er i18n og l10n?

Begrepene «i18n» og «l10n» er forkortelser for ordene «internationalization» som betyr internasjonalisering og «localization» som betyr lokalisering. Forkortelsene er den første og siste bokstaven i hvert ord og antall bokstaver i mellom.

Å «internasjonalisere» et program består i å endre det slik at det kan bli oversatt (lokalisert). Dette innebærer delvis å skrive om et program, som i utgangspunktet er skrevet for å fungere på ett språk, slik at det kan gjøres tilgjengelig på alle språk.

Å «lokalisere» et program består i oversette de opprinnelige meldingene (ofte på engelsk) til et annet språk. For å få dette til må programmet allerede ha blitt internasjonalisert.

Oppsummert; internasjonalisering forbereder programvaren for oversettelse, som deretter utføres ved lokalisering.

1.3.2.3. Sending fixes

More advanced users might be able to provide a fix to a program sending a patch.

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.

TOOL Git, the preferred way to send patches

Git is a version-control system designed for coordinating work among developers and track their changes. It was programmed by Linus Torvalds (the creator of Linux) in 2005 to coordinate the development of the Linux kernel.

Nowadays, it is common to send patches using Git. Many Debian projects using Git can be found on https://salsa.debian.org/.

To send a patch using Git, you must download a copy of the repository, make the fixes, add them to the stage area, commit the changes, upload your changes, and request the maintainer to accept your changes. It is beyond the scope of this book to provide a detailed explanation about Git, for that you can refer to the Pro Git book (https://git-scm.com/book/).

Below is an example of the commands needed to submit a patch to this book. You can use GitLab's web interface to make the pull request; another option is to use the command git request-pull and send its output to the developers.

$ git clone https://salsa.debian.org/youruser/debian-handbook/
Cloning into 'debian-handbook'...
remote: Enumerating objects: 20838, done.
remote: Counting objects: 100% (20838/20838), done.
remote: Compressing objects: 100% (4510/4510), done.
remote: Total 20838 (delta 16316), reused 20809 (delta 16307)
Receiving objects: 100% (20838/20838), 139.41 MiB | 131.00 KiB/s, done.
Resolving deltas: 100% (16316/16316), done.
Checking out files: 100% (1351/1351), done.
$ editor file
$ git add file
$ git commit -m "Correct typo in chapter 3"
[buster/master ca5a0039] Update chapter 1
 1 file changed, 98 insertions(+), 54 deletions(-)
$ git push
Username for 'https://salsa.debian.org': youruser
Password for 'https://youruser@salsa.debian.org': yourpasswd
Enumerating objects: 96, done.
Counting objects: 100% (96/96), done.
Delta compression using up to 2 threads
Compressing objects: 100% (80/80), done.
Writing objects: 100% (80/80), 456.23 KiB | 3.83 MiB/s, done.
Total 80 (delta 59), reused 2 (delta 0)
To https://salsa.debian.org/youruser/debian-handbook.git/
   18e0e26c..ca5a0039  buster/master -> buster/master

It is a good practice to review the changes before executing git add. You can execute git diff for that. It will open the default pager (usually less) to display the differences. The lines starting with - are the removed lines, whereas the lines starting with + show added lines.

1.3.2.4. Other ways of contributing

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, debian-user@lists.debian.org (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.

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:

→ https://www.debian.org/events/material

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.

ORDFORRÅD Underprosjekt og avledede distribusjoner

Prosessen for å lage en avledet distribusjon starter med å lage endringer i en spesifikk versjon av Debian. Infrastrukturen som brukes til dette arbeidet er utenfor selve Debian-prosjektet. Det finnes ikke nødvendigvis retningslinjer for å bidra med forbedringer. Denne forskjellen forklarer hvordan en avledet distribusjon kan «avvike» fra sin opprinnelse, og hvorfor den jevnlig må synkroniseres igjen med sitt utspring for å dra nytte av forbedringer laget oppstrøms.

På den annen side kan et delprosjekt ikke tillates å avvike for mye fordi alt arbeidet med den består av direkte forbedringer av Debian for å tilpasse den til et bestemt formål.

Den mest kjente distribusjon som stammer fra Debian er, uten tvil, Ubuntu, men det er mange andre. Se Tillegg A, Avledede distribusjoner for å lære om deres spesialiteter og hvordan de er posisjonert i forhold til Debian.

Her er et lite utvalg av aktuelle underprosjekter:

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, er dedikert det medisinske feltet;
Debian Multimedia omhandler arbeid med lyd- og multimedia;
Debian GIS tar seg av geografiske informasjonssystemer og deres brukere;
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. 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.

ORDFORRÅD Pseudo-pakke, et monitoreringsverktøy

Sporingssystemet for feil, opprinnelig laget for å knytte feilrapporter til en Debian-pakke, har vist seg svært hensiktsmessig å håndtere andre saker, som lister over problemer som må løses, eller oppgaver å administrere uten kobling til en bestemt Debian-pakke. Pseudo-pakke tillater dermed bestemte grupper å bruke feilsporingssystemet uten å knytte en bestemt pakke til sin gruppe. Alle kan derfor rapportere problemer som må håndteres. For eksempel har BTS en oppføring for ftp.debian.org som brukes til å melde og følge opp problemer i det offisielle pakkearkivet, eller rett og slett å be om fjerning av en pakke. Likeledes refererer pseudo-pakken www.debian.org til feil på nettsiden til Debian, og lists.debian.org samler alle problemer som gjelder e-postlister.

TOOL GitLab, Git repository hosting and much more

A GitLab instance, known as salsa.debian.org, is used by Debian to host the Git packaging repositories but this software offers much more than simple hosting and Debian contributors have been quick to leverage the continuous integration features (running tests, or even building packages, on each push). Debian contributors also benefit from a cleaner contribution workflow thanks the well understood merge request process (similar to GitHub's pull requests).

GitLab replaced FusionForge (which was running on a service known as alioth.debian.org) for collaborative package maintainance. This service is administered by Alexander Wirt, Bastian Blank and Jörg Jaspert.

→ https://salsa.debian.org/

→ https://wiki.debian.org/Salsa/Doc

Debian-systemadministrator-gruppen (DSA) debian-admin@lists.debian.org 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.

→ https://dsa.debian.org

VERKTØY Debian-pakkesporingssystem

Dette er et av Raphaëls verk: Den grunnleggende ideen er å sentralisere så mye informasjon som mulig for en gitt pakke på en enkelt side. Dermed kan man raskt sjekke status for et program, identifisere oppgaver som skal bli ferdig, og tilby sin hjelp. Dette er årsaken til at denne siden samler alle feilstatistikk, tilgjengelige versjoner i hver distribusjon, fremdriften for en pakke mot Testing-distribusjonen, status for oversettelser av beskrivelser og debconf-maler, mulig tilgjengelighet av en ny oppstrøms versjon, meldinger om mangel på samsvar med den nyeste versjonen av Debian Policy, informasjon om vedlikehold, og eventuelle andre opplysninger som vedlikeholderen ønsker å inkludere.

→ https://trac er.debian.org/

En e-postabonnementstjeneste fullfører dette nettgrensesnittet. Det sender automatisk følgende informasjonutvalg til listen: Feil og beslektet diskusjoner, tilgjengelighet av en ny versjon på Debian-serverne, nye oversettelser klare for korrekturlesing , etc.

Advanced users can, thus, follow all of this information closely and even contribute to the project, once they have got a good enough understanding of how it works.

Et annet nettbrukergrensesnitt, kjent som Debianutviklernes pakkeoversikt (DDPO), gir hver utvikler et sammendrag av status for alle Debian-pakker som vedkommende har ansvar for.

→ https://qa.debian.org/developer.php

Disse to nettstedene er verktøy utviklet og forvaltet av gruppen som er ansvarlig for kvalitetssikring innen Debian (kjent som Debian QA).

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.

KULTUR Git

Git er et verktøy for å samarbeide om flere filer, og samtidig opprettholde endringshistorikken. Filene det gjelder er vanligvis tekstfiler, for eksempel et programs kildekode. Hvis flere personer arbeider sammen på samme fil, kan git bare slå sammen endringer som er gjort når de er laget til forskjellige deler av filen. Ellers må disse «konfliktene» løses opp i for hånd.

Git is a distributed system where each user has a repository with the complete history of changes. Central repositories are used to download the project (git clone) and to share the work done with others (git push). The repository can contain multiple versions of the files but only one version can be worked on at a given time: it's called the working copy (it can be changed to point to another version with git checkout). Git can show you the modifications made to the working copy (git diff), can add (git add) the selected files for inclusion in a new entry in the repository, with the added files it can create a new entry in the versions history (git commit), it can update the working copy to include modifications made in parallel by other users (git pull), and can record a particular configuration in the history in order to be able to easily extract it later on (git tag).

Git gjør det lett å håndtere flere samtidige utgaver av et utviklingsprosjekt uten at de forstyrrer hverandre. Disse versjonene er kalt avgreninger. Denne metaforen fra et tre er ganske presis, siden et program er opprinnelig utviklet fra en felles stamme. Når en milepæl er nådd (for eksempel versjon 1.0), fortsetter utviklingen i to grener: Utviklingsgrenen forbereder den neste store utgivelsen, og vedlikeholdsgrenen styrer oppdateringer og feilrettinger for versjon 1.0.

Git er i dag det mest populære versjonskontrollsystemet, men det er ikke det eneste. Historisk var CVS (Concurrent Versions System) det første allment brukte verktøyet, men dets mange begrensninger bidro til at mer moderne fritt tilgjengelige alternativer kom frem. Vi vil spesielt nevne subversion (svn), git, bazaar (bzr), og mercurial (hg).

→ http://www.nongnu.org/cvs/

→ http://subversion.apache.org/

→ http://git-scm.com/

→ http://bazaar.canonical.com/

→ http://mercurial.selenic.com/

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 debian-boot@lists.debian.org og koordineres av Cyril Brulebois.

→ http://www.debian.org/devel/debian-installer/

→ http://joeyh.name/blog/entry/d-i_retrospective/

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 debian-qa@lists.debian.org som prøver å sikre kvaliteten på alle nivåer i Debian-prosjektet. Et annet er debian-policy@lists.debian.org-listen som utvikler Debian-retningslinjene etter forslag som kommer fra hele Debian-prosjektet. De gruppene med ansvaret for hver arkitektur (debian-architecture@lists.debian.org) 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 debian-glibc@lists.debian.org, og C biblioteket på debian-gcc@lists.debian.org-listen, eller Xorg på debian-x@lists.debian.org (denne gruppen er også kjent som X Strike Force).