#use wml::debian::template title="Debians fejlrapporteringssystem – oplysninger til udviklere" NOHEADER=yes NOCOPYRIGHT=true #include "$(ENGLISHDIR)/Bugs/pkgreport-opts.inc" #use wml::debian::translation-check translation="40a57e26c62893be7c80d82f1772999f68d51179"
Det første der sker er at en bruger indsender en fejlrapport per e-mail til
submit@bugs.debian.org
, som skal indeholde en
Package
-linje (se Vejledning i
fejlrapportering for flere oplysninger). Fejlrapporten tildeles dernæst et
nummer, der sendes retur til brugeren som kvittering, og siden videresendes til
debian-bugs-dist
. Hvis Package
-linjen indeholder en
pakke, der har en kendt vedligeholder, bliver der også sendt en kopi til
vedkommende.
Emne
-linjen får tilføjet teksten
Bug#
nnn:
, og Reply-To
opsættes så den indeholder både fejlrapportens afsender og
nnn@bugs.debian.org
.
X-Debian-PR: quiet
-funktionFejlrapporter i Debian bør lukkes når problemerne er løst. Problemer i pakker kan kun anses for løste når en pakke indeholdende fejlrettelsen er blevet optaget i Debians arkiv.
Normalt er de eneste personer der bør lukke en fejlrapport, den der indsendte fejlrapporten og den ansvarlige for pakken som fejlrapporten blev indsendt imod. Der findes undtagelser fra reglen, for eksempel fejl som indsendes mod ukendte pakker eller visse generelle pseudopakker. En fejl kan også lukkes af enhver bidragyder, hvis fejlen gælder en forældreløs pakke eller hvis vedligeholderen af pakken ikke har fået lukket fejlen. Det er meget vigtigt at nævne i hvilken version, fejlen blev rettet. Hvis du er usikker, så luk ikke fejlrapporter uden først at have bedt om råd på postlisten debian-devel.
Fejlrapporter lukkes ved at sende en e-mail til
nnn-done@bugs.debian.org
. Meddelelsens krop skal
indeholde en forklaring på hvordan fejlen blev rettet.
Med de e-mails som kommer fra fejlrapporteringssystemet er alt hvad du
behøver at gøre for at lukke fejlrapporten, at skrive et svar i dit postprogram
og redigere modtagerfeltet så der står
nnn-done@bugs.debian.org
i stedet for
nnn@bugs.debian.org
(nnn-close
findes også som alias for
nnn-done
).
Hvor det er relevant, bedes man også også tilføje en
Version
-linje i \
pseudo-headeren i meddelelsen, når en fejl lukkes, så fejlsporingssystemet
ved hvilken udgave af pakken, der indeholder fejlrettelsen.
Personen som lukker fejlrapporten, personen der oprindeligt rapporterede
den, såvel som postlisten debian-bugs-closed
vil alle få en
bekræftelse på ændringen rapportens status. Fejlrapportens afsender og
postlisten vil også modtage indholdet af meddelelser der sendes til
nnn-done
.
Fejlrapporteringssystemet indeholder afsenderens adresse og adressen på
fejlrapporten (nnn@bugs.debian.org
) i
Reply-To
-feltet når rapporten videresendes. Bemærk at dette er to
forskellige adresser.
Hvis en udvikler vil svare på en fejlrapport, er det nok at svare på
meddelelsen og respektere Reply-To
-feltets indhold. Dette vil
ikke lukke fejlrapporten.
Anvend ikke svar til alle modtagere
eller opfølgning
i
dit mailprogram, med mindre du har i sinde at redigere modtagerlisten betydeligt.
I særdeleshed skal du sørge for ikke at sende opfølgningsmeddelelser til
submit@bugs.debian.org
.
Meddelelser kan sendes til følgende adresser, for at blive registreret i fejlsporingssystemet:
@bugs.debian.org
— sådanne meddelelser sendes
også til pakkevedligeholderen og videresendes til
debian-bugs-dist
, men ikke til
indsenderen;
-submitter@bugs.debian.org
— disse sendes
også til indsenderen og videresendes til debian-bugs-dist
,
men ikke til pakkevedligeholderen;
-maintonly@bugs.debian.org
— disse sendes kun
til pakkevedligeholderen, ikke til indsenderen eller
debian-bugs-dist
;
-quiet@bugs.debian.org
— disse registreres
kun i fejlsporingssystemet (som det er tilfældet med alle ovennævnte),
de sendes ikke til nogen anden adresse.
For flere oplysninger om headerlinjer til undertrykkelse af ACK-meddelelser og hvordan man sender kopier ved hjælp af fejlsporingssystemet, se vejledningen om hvordan man rapporterer fejl.
Systemet gemmer en alvorsgrad
sammen med hver fejlrapport. Denne
sættes som standard til normal
, men kan ændres, enten ved at
tilføje en Severity
-linje i pseudo-brevhovedet
når fejlen
rapporteres (se vejledning i at rapportere
fejl, eller ved at anvende kontrolserverens
severity
-kommando.
Alvorsgraderne er:
critical
(kritisk)grave
(graverende)serious
(alvorlig)skal- eller
krav-direktiv), eller den gør efter den pakkeansvarliges eller udgivelsesansvarliges mening pakken uegnet til udgivelse.
important
(vigtig)normal
(normal)minor
(mindre)wishlist
(ønskeliste)Visse alvorsgrader anses for at være
kritiske nok til at
stoppe en udgivelse (release-critical
), hvilket betyder at
sådanne fejl vil afgøre om pakken kan udgives eller ej med den stabile udgave
af Debian. For tiden disse critical (kritisk),
grave (graverende) samt
serious (alvorlig).
For fuldstændige og kanoniske regler om hvilket problemer der fortjener
disse alvorsgrader, se listen over
udgivelseskritiske
problemer i den næste udgivelse.
Enhver fejlrapport kan have ingen eller flere givne markeringer. Disse markeringer vises i listen over fejlrapporter når du kigger på en pakkes side, og når du kigger på den komplette fejlrapportlog.
Markeringer kan sættes ved at medsende en Tags
-linje i
pseudohovedet når fejlrapporten indsendes (se
vejledning i fejlrapportering),
eller ved at anvende kommandoen tags
via
kontrolserveren. Adskil flere mærker med komma,
mellemrumstegn eller begge.
De aktuelle fejlrapporteringsmarkeringer er:
patch
wontfix
(retter ikke)moreinfo
(flere oplysninger)Det virker ikke. Hvad er det der ikke virker?
unreproducible
(kan ikke genskabes)help
(hjælp)newcomer
(nybegynder).newcomer
(nybegynder)pending
(i gang)fixed
(rettet)fixed-alvorsgrad.
security
(sikkerhed)denial of service) som bør rettes, osv.). De fleste sikkerhedsfejl bør også have alvorsgraden
criticaleller
grave.
upstream
(opstrøm)confirmed
fixed-upstream
fixed-in-experimental
d-i
ipv6
lfs
l10n
a11y
ftbfs
serious(udgivelseskritisk) i sådanne situationer.
Nogle oplysninger om distributionsspecifikke mærker:
-ignore
-mærkerne ignorerer fejlen med det formål at teste udbredelse.
Udgivelsesmærkerne indikerer at den pågældende fejl ikke skal arkiveres før den
er rettet i de angivne udgivelser. Udgivelsesmærkerne indikerer også, at fejlen
kun anses for at gælde i de angivne udgivelser. [Med andre ord, fejlen
findes ikke i nogen udgivelse, hvis tilsvarende
udgivelsesmærker ikke er opsat, såfremt et eller flere
udgivelsesmærker er opsat; ellers gælder de almindelige
fundet-/rettet-regler.]
Udgivelsesmærker bør ikke anvendes hvis den korrekte
versionering af fejlen ellers vil give den ønskede virkning, da de kræver
manuel tilføjelse og fjernelse. Hvis du er usikker på, hvorvidt et
udgivelsesmærke er krævet, så kontakt på engelsk Debian BTS Administrators
(
Når en udvikler videresender en fejlrapport til udvikleren af
opstrøms
-kildekodepakken, som Debians pakker er baseret på, skal det
noteres i fejlrapporteringssystemet som følger:
Sørg for at Til
-feltet i din e-mail forfatteren kun indeholder
forfatter(nes) adresse(r), indsæt både adressen på vedkommende som rapporterede
fejlen, og nnn-forwarded@bugs.debian.org
og
nnn@bugs.debian.org
i CC
-feltet.
Bed forfatteren om at beholde CC
til
nnn-forwarded@bugs.debian.org
når vedkommende svarer,
så fejlrapporteringssystemet arkiverer svaret sammen med den oprindelige
rapport. Disse meddelelser gemmes kun og videresendes ikke; for at sende en
meddelelse som normalt, skal de også sendes til
nnn@bugs.debian.org
.
Når fejlrapporteringssystemet modtager en meddelelse til
nnn-forwarded
, markerer det den relevante fejlrapport
som videresendt til adresse(rne) i e-mailens Til
-felt, hvis
fejlen ikke allerede er markeret som videresendt.
Du kan også ændre på forwarded to
-oplysningen ved at sende meddelelsen
til control@bugs.debian.org
.
I tilfælde hvor den ansvarlig for rettelsen af en fejl ikke er den angivne vedligeholder for de tilknyttede pakker (for eksempel når pakken vedligeholdes af et hold), det det være nyttigt at registrere denne oplysning i fejlsporingssystemet. Som en hjælp til dette, kan man ved alle fejl valgfrit have en ejer.
Ejeren kan registreres ved at tilføje en Owner
-linje (ejer) i
pseudoheaderen når fejlen indsendes (se \
vejledning i rapportering af fejl) eller ved at kommandoerne
owner
(ejer) og noowner
(ingen ejer) med
kontrolforespørgselsserveren.
Hvis en forkert person er angivet som en pakkes vedligeholder, er det
normalt fordi der nyligt er kommet en ny vedligeholder, og den nye
vedligeholder har endnu ikke overført en ny version af pakken med et ændret
Maintainer
-kontrolfelt. Dette ændres når pakken overføres,
alternativt kan vedligeholderen manuelt ændre i listen over vedligeholdere, for
eksempel hvis en ny version af pakken ikke forventes at være nødvendig indenfor
den nærmeste fremtid. Kontakt override-change@debian.org
vedrørende ændringer til filen override.
Det er muligt at omadressere fejlrapporter til andre pakker, at genåbne
fejlagtigt lukkede rapporter, at ændre oplysningerne om hvortil (om noget)
rapporten er blevet videresendt, at ændre alvorsgrader og overskrifter på
rapporter, samle og splitte fejlrapporter, og til at registrere pakkeversioner
hvor fejl blev fundet og hvor de blev rettet. Dette gøres ved at sende en
e-mail til control@bugs.debian.org
.
Formatet på disse kontrolmeddelelser er
beskrevet i et andet webdokument og i filen
bug-maint-mailcontrol.txt
. En udgave i ren tekst kan leveres ved
at sende en e-mail med ordet help
til serveren på adressen
overfor.
Fejlsporingssystemet gør det også muligt for indsendere af fejl, udviklere
og andre interesserede tredjeparter at tegne abonnement på individuelle fejl.
Denne funktion kan anvendes af dem, der ønsker at holde øje med en fejl, uden
at skulle tegne abonnement på pakken gennem
Debian Package Tracker. Alle
meddelelser der modtages på nnn@bugs.debian.org
,
sendes til dem, der har tegnet abonnement.
Tegnelse af abonnement kan gøres ved at sende en e-mail til
nnn-subscribe@bugs.debian.org
. E-mail'ens emne og
krop ignoreres af BTS. Når meddelelesen er blevet behandlet, sendes der en
bekræftelsesmeddelelse til brugeren, som vedkommende skal svare på før e-mail
vedrørende den pågældende fejl bliver sendt til brugeren.
Det er også muligt at ophæve abonnementet på en fejl. Abonnementsophævelse
sker ved at sende en e-mail til
nnn-unsubscribe@bugs.debian.org
. E-mail'ens emne og
krop ignoreres igen af BTS. Der sendes bekræftelsesmeddelelse til brugeren,
som vedkommende skal svare på for abonnementet kan blive ophævet.
Som standard bliver der tegnet abonnement til den adresse, som findes i
headerfeltet From
. Ønsker du at en anden adresse skal have
tegnet abonnement, er du nødt til at tilføje adresse i tegnelsesmeddelelsen.
Dette sker på følgende måde:
nnn-subscribe-
lokal-del=
example.com@bugs.debian.org
.
I eksemplet vil der blive sendt en tegnelsesmeddelelse til
lokal-del@example.com
vedrørende fejlen nnn.
@
-tegnet skal indkapsles ved at ændre det til et
=
-tegn. På lignende måde ophæves et abonnement:
nnn-unsubscribe-
lokal-del=
example.com@bugs.debian.org
.
I begge tilfælde vil e-mail'ens emne og krop blive videresendt til
e-mail-adressen i forespørgslen til bekræftelse.
Meddelelser som ankommer til submit
eller bugs
hvis emne begynder med Bug#
nnn vil blive behandlet som
de er sendt til nnn@bugs.debian.org
. Dette er både på
grund af bagudkompabilitetshensyn med e-mails videresendt fra de gamle adresser,
og for at opfange mails der fejlagtigt sendes til submit
(for
eksempel ved at svare til alle modtagere).
En lignende funktion findes til maintonly
, done
,
quiet
og forwarded
, som behandler e-mails der
ankommer med en emnelinje som svarer til at de er sendt til adressen
nnn-hvaddetnuvar@bugs.debian.org
.
Meddelelser som ankommer til forwarded
og done
– det vil sige uden et fejlrapportnummer i adressen - og uden et
fejlnummer i emnelinjen, vil blive arkiveret under affald
(junk
)
i nogle uger, men vil ellers blive ignoreret.
X-Debian-PR: quiet
-funktionTidligere var det muligt at forhindre at fejlrapporteringssystemet i alle
former for videresendelser modtaget på debian-bugs
, ved at tilføje
linjen X-Debian-PR: quiet
i brevhovedet.
Denne linje bliver nu ignoreret. Send i stedet din meddelelse til
quiet
eller nnn-quiet
(eller
maintonly
eller nnn-maintonly
).