NB: Originalen er nyere enn denne oversettelsen.
Utviklerinformasjon om feilrapportsystemet
Feilrapporter blir først sendt som en vanlig e-post til
submit@bugs.debian.org
som må inkludere en
Package
-linje (se Instruksjoner for
feilrapportering for mer informasjon). Rapporten får deretter et
nummer, en kvittering blir sendt til innsenderen og rapporten blir
videresendt til debian-bugs-dist
. Hvis
Package
-linja inneholder en pakke som har en kjent
utvikler, så sendes det en kopi til utvikleren også.
Subject
-feltet vil få lagt til
Bug#
nnn:
og
Reply-To
settes slik at den inkluderer både
innsenderen og nnn@bugs.debian.org
.
- Lukke feilrapporter
- Oppfølgingsmeldinger
- Alvorlighetsgrader
- Merkelapper for feilrapporter
- Informere om at du har videresendt en feilrapport
- Endre eierskap på feilrapporter
- Feilangitte pakkeutviklere
- Gjenåpne, tildele og endre på feilrapporter
- Abonner på feilrapporter
- Mer eller mindre avlegs tittelfeltsøk
- Avlegs
X-Debian-PR: quiet
-egenskap
Lukke feilrapporter
Debians feilrapporter skal lukkes når feilen er rettet. Problemer i pakkene kan kun anses som rettet etter at en pakke som innholder rettelsen på feilen er lastet inn i Debian-arkivet.
Vanligvis er de eneste personene som kan lukke en feilrapport innsenderen av rapporten og vedlikeholderen(e) av pakken rapporten var sendt inn mot. Det finnes unntak til denne regelen, eksempelvis for feilrapporter som er sendt inn mot ukjente pakker eller visse generelle pseudo-pakker. En feil kan også lukkes av hvem som helst. hvis feilen er for en orphaned pakke, en pakke uten vedlikeholder, eller hvis vedlikeholderen av en pakke har glemt å lukke den. Det er veldig viktig å nevne i hvilken versjon feilen ble rettet. Hvis du er i tvil, ikke lukk feilrapporter uten å spørre om råd i e-postlisten debian-devel.
Feilrapporter lukkes ved å sende en e-post til
nnn-done@bugs.debian.org
. Kroppen av
meldingen må inneholde en forklaring av hvordan feilen ble fikset.
Med en e-postene du har mottatt fra feilrapportsystemet er alt du
trenger å gjøre for å lukke en feilrapport å svare på meldingen i
e-postleseren din, og endre To
- eller
Til
-feltet til
nnn-done@bugs.debian.org
i stedet for
nnn@bugs
(nnn-close
er et alias for
nnn-done
).
Der det er anvendelig vennligst angi en Version
-linje i
pseudo-headeren av din melding
når du lukker en feilrapport. Slik vet feilrapportsystemet hvilken
utgivelse av pakken som inneholder en rettelse av feilen.
Personen som lukker feilrapporten, den som sendte den inn, og
e-postlisten debian-bugs-closed
vil hver få en melding om
endring av status i feilrapporten. Innsenderen og e-postlisten
vil også motta innholdet av meldingen som ble sendt til
nnn-done
.
Oppfølgingsmeldinger
Feilrapportsystemet vil inkludere innsenderen's adresse og
feilrapportsadressen (nnn@bugs.debian.org
) i
Reply-To
-feltet når feilrapporten videresendes til
pakkeutvikleren. Merk at disse er to adskilte adresser.
Enhver utvikler som ønsker å svare på en feilmelding kan rett og
slett svare på e-posten i samsvar med Reply-To
-feltet.
Dette vil ikke markere feilrapporten som lukket.
Ikke bruk svar til alle
eller followup
dersom du ikke
har til hensikt å vesentlig redigere på mottakerlisten. Pass spesielt på at
du ikke sender oppfølgingsmeldinger til
submit@bugs.debian.org
.
Meldinger kan sendes til følgende adresser for å bli lagret i feilrapportsystemet:
-
nnn
@bugs.debian.org
— slike meldinger sendes også til pakkeutvikleren og blir videresendt tildebian-bugs-dist
, men ikke til innsenderen; -
nnn
-submitter@bugs.debian.org
— disse sendes også til innsenderen og blir videresendt tildebian-bugs-dist
, men ikke til pakkeutvikleren; -
nnn
-maintonly@bugs.debian.org
— disse sendes kun til pakkeutvikleren, ikke til innsenderen ellerdebian-bugs-dist
; -
nnn
-quiet@bugs.debian.org
— disse blir kun lagret i feilrapportsystemet (som alle over), ikke sendt til noen andre.
For mer informasjon om linjer til å dempe ACK-meldinger og hvordan sende kopier ved bruk av feilrapportsystemet, se Instruksjoner for feilrapportering.
Alvorlighetsgrader
Feilrapportsystemet lagrer en alvorlighetsgrad sammen med hver
feilrapport. Denne settes til normal
til vanlig, men
kan overstyres, enten ved å ha en Severity
-linje i
pseudo-hodet på eposten når den sendes inn (se
instruksjonene for
feilrapportering), eller ved å bruke
severity
-kommandoen med kontrolltjeneren.
Alvorlighetsgradene er:
critical
(kritisk)- en feil som får annen ubeslektet programvare på systemet (eller hele systemet) til å slutte å fungere, eller forårsaker alvorlig datatap, eller lager et sikkerhetshull på systemer der pakken installeres.
grave
(graverende)- gjør pakken det er snakk om helt eller for det meste ubrukelig, forårsaker datatap eller lager et sikkerhetshull som gir tilgang til kontoene til brukerne som bruker pakken.
serious
(alvorlig)-
et alvorlig brudd på Debians retningslinjer (det vil si, pakken bryter
mot et
må
ellerpåkrevd
-krav) eller, i følge pakkeutvikleren, gjør pakken uegnet for utgivelse. important
(viktig)- en feil som har gjør at pakken ikke virker skikkelig, uten å gjøre den fullstendig ubrukelig.
normal
(vanlig)- standardverdien og den mest vanlige
minor
(liten)- et problem som ikke påvirker pakkens nytteverdi, og som sannsynligvis er trivielt å rette.
wishlist
(ønske)- for spørsmål om nye funksjoner og feil som er vanskelige å rette på grunn av designvalg.
Visse alvorlighetsgrader anses som utgivelseskritisk, noe som betyr at feilen vil bestemme om pakken blir utgitt sammen med den stabile utgaven av Debian. For tiden er disse gradene critical, grave, og serious. For fullstendige regler om disse alvorlighetsgradene, se listen med utgivelseskritiske feil for neste utgaven.
Merkelapper for feilrapporter
Hver rapport kan ha null eller flere merkelapper angitt. Disse blir vist både i listen over feilrapporter på pakkens egen side, og på den fullstendige feilrapportloggen.
Merkelapper kan settes ved å bruk en Tags
-linje i
pseudo-linjen når feilen meldes inn (se instruksjoner for
feilrapportering), eller ved å bruke
tags
-kommandoen til kontrolltjeneren.
Separer flere merkelapper med komma, mellomrom eller begge.
Gjeldende merkelapper er:
patch
, wontfix
, moreinfo
, unreproducible
,
help
, security
, upstream
, pending
, confirmed
,
ipv6
, lfs
, d-i
, l10n
, newcomer
, a11y
, ftbfs
,
fixed-upstream
, fixed
, fixed-in-experimental
,
potato
,
woody
,
sarge
,
etch
,
lenny
,
squeeze
,
wheezy
,
jessie
,
stretch
,
buster
,
bullseye
,
bookworm
,
trixie
,
forky
,
sid
,
experimental
,
sarge-ignore
,
etch-ignore
,
lenny-ignore
,
squeeze-ignore
,
wheezy-ignore
,
jessie-ignore
,
stretch-ignore
,
buster-ignore
,
bullseye-ignore
,
bookworm-ignore
,
trixie-ignore
forky-ignore
.
Nedenfor finner du litt detaljert informasjon om hver merkelapp.
patch
(lapp)- En lapp eller en annen enkel prosedyre for å rette feilen er inkludert i feilrapporten. Hvis det er en lapp tilgjengelig, men den ikke retter feilen ordentlig eller forårsaker et annet problem skal ikke denne merkelappen brukes.
wontfix
(kommer ikke til å rettes)- Denne feilen kommer ikke til å bli rettet. Dette kan skyldes at man har valgt en av to likeverdige måter å gjøre noe på og utvikleren og innsenderen foretrekker to forskjellige måter, fordi endring av oppførselen vil forårsake andre, verre problemer for andre, eller av andre grunner.
moreinfo
(mer informasjon trengs)-
Denne feilen kan ikke rettes før mer informasjon blir gjort
tilgjengelig. Feilrapporten kommer til å bli lukket dersom ny
informasjon ikke kommer i løpet av noe tid (et par måneder).
Denne merkelappen er for feilrapporter av typen
Dette virker ikke!
. Hva virker ikke? unreproducible
(ikke reproduserbar)- Denne feilen kan ikke reproduseres på utviklerens system. Assistanse fra tredjepart er nødvendig for å diagnostisere problemet.
help
(hjelp)-
Utvikleren trenger hjelp for å fikse denne feilen.
Enten har ikke utvikleren de nødvendige ferdighetene for å
rettet feilen og ønsker samarbeid, eller så er utvikleren
overarbeidet og ønsker å delegere oppgaven. Feilen er kanskje
ikke passende for nye bidragsytere med mindre den også er merket
med
newcomer
-merkelapper. newcomer
(nybegynnere)- Denne feilen har en kjent løsning, men utvikleren ber om at noen andre implementerer løsningen. Dette er en ideell oppgave for nye bidragsytere som ønsker å bli involvert i Debian eller som ønsker forbedre sine ferdigheter.
pending
(i kø)- En løsning på denne feilen har blitt funnet og en opplasting vil bli gjort snarlig.
fixed
(rettet)-
Denne feilen er rettet eller jobbet seg rundt (ved en
opplasting av pakken av en annen utvikler enn den som er
ansvarlig for den, f.eks), men problemet må fremdeles løses av
utvikleren. Denne merkelappen erstatter den gamle
fixed
alvorlighetsgraden. security
(sikkerhet)- Denne rapporten beskriver et sikkerhetsproblem i en pakke (f.eks feil rettigheter som gir tilgang til data som ikke skal være tilgjengelig; bufferoverflyt som kan gi uautorisert tilgang til systemet, etc). De fleste sikkerhetsrelaterte feil bør også ha alvorlighetsgrad critical eller grave.
upstream
(oppstrøms)- Denne rapporten gjelder oppstrømsdelen av pakken.
confirmed
(bekreftet)- Utvikleren har sett, forstått og generelt sett er enig med at det er en feil, men har ikke fikset det. (Bruk av denne merkelappen er valgfri; den er til hovedsaklig for utviklere som behandler store mengder av åpne feilrapporter.)
fixed-upstream
(fikset oppstrøms)- Feilen har blitt fikset hos en utvikler oppstrøms, men er fortsatt ikke inkludert i pakken (for hva enn grunn: kanskje det er altfor komplisert å anvende i en eldre versjon eller altfor liten til å være verdt bryet).
fixed-in-experimental
(fikset i eksperimentell)- Feilen har blitt fikset i en pakke hos den eksperimentelle utgaven, men ikke i den ustabile.
d-i
- Denne feilen er relevant for utviklingen av debian-installer. Det er forventet at denne vil bli brukt når feilen påvirker utvikling av installasjonsprogrammet, men ikke når feilen er innsendt mot en pakke som påvirker installasjonsprogrammet direkte.
ipv6
- Denne feilen påvirker Internet Protocol version 6.
lfs
- Denne feilen påvirker støtte for store filer (over 2 GB).
l10n
- Denne feilen er relevant for lokalisering av pakken.
a11y
- Denne feilen er relevant for pakkens tilgjengelighet.
ftbfs
-
Pakken bygger ikke fra kilde. Hvis feilen er tilordnet en
kildepakke, så er det den pakken som ikke bygger. Hvis feilen
er tilordnet en binærpakke, så er det den tilhørende kildepakken
som ikke bygger. Merkelappen kan brukes for ikke-standard
byggemiljø, men da skal alvorlighetsgrad være lavere enn
serious
. -
potato
,woody
,sarge
,etch
,lenny
,squeeze
,wheezy
,jessie
,stretch
,buster
,bullseye
,bookworm
,trixie
,forky
,sid
,experimental
- Dette er utgave-merkelapper som har to innvirkninger. Når denne blir satt på en feilrapport kan feilen kun påvirke den aktuelle utgaven (men det kan påvirke andre utgaver hvis merkelapper for andre utgaver er satt) men ellers normale buggy/fixed/absent-regler gjelder. Feilen burde ikke bli arkivert før den har blitt fikset i denne utgaven.
-
sarge-ignore
,etch-ignore
,lenny-ignore
,squeeze-ignore
,wheezy-ignore
,jessie-ignore
,stretch-ignore
,buster-ignore
,bullseye-ignore
,bookworm-ignore
,trixie-ignore
forky-ignore
- Denne utgavelseskritiske feilrapporten skal bli ignorert med målet om å få gi ut den aktuelle utgaven. Denne merkelappen skal kun bli brukt av utgavelsesansvarlig(e); ikke sett denne selv uten eksplisitt autorisasjon fra dem.
Noe informasjon om distribusjonsspesifikke merkelapper:
-ignore
-merkelappene ignorerer feilen for videre testing.
Merkelappene for utgivelse indikerer
at aktuelle feilrapporter ikke skal bli arkivert før det har blitt
ordnet i settet av utgivelser angitt. Merkelappen for utgivelse
skal også indikere at feilrapporten er kun betenkt en feil i det
settet med utgivelser angitt (med andre ord så er feilen
ikke tilstede i utgivelser hvor merkelappen for
utgivelsen ikke er satt i feilrapporten).
Merkelappene for utgivelser burde ikke bli brukt hvis rett angivelse av versjonen til feilrapporten ville utgjort nødvendig effekt, siden de krever manuelle tillegg og fjerning. Hvis du er usikker på om en merkelapp for utgivelser er nødvendig, kontakt Debian sine administratorer for feilrapportsystemet (BTS) (owner@bugs.debian.org) eller utgivelseslaget for råd.
Informere om at du har videresendt en feilrapport
Når en Debian-utvikler videresender en feilrapport til utvikleren av den orginale kildekoden som gav opphav til Debian-pakken, skal dette lagres i feilrapportsystemet som følger:
Pass på at Til
-feltet på meldingen kun har
adressen(e) til forfatteren(e). Legg både personen som
rapporterte feilen,
nnn-forwarded@bugs.debian.org
,
og nnn@bugs.debian.org
i
Cc
-feltet.
Be forfatteren om å bevare Cc
-feltet til
nnn-forwarded@bugs
når de svarer slik at
feilrapportsystemet lagrer svaret deres sammen med den
opprinnelige rapporten. Disse meldingen er kun lagret, ikke sendt
videre; for å sende en melding som normalt, send den til
nnn@bugs.debian.org
også.
Når feilrapportsystemet får en melding på adressen
nnn-forwarded
så vil den merke den
aktuelle feilrapporten med at den har blitt videresendt til
adresse(ne) iTil
-feltet på meldingen den får,
med mindre den allerede er merket som videresendt.
Do kan også endre på forwarded to
-informasjonen ved å sende
meldinger til
control@bugs.debian.org
.
Endre eierskap på feilrapport
I tilfeller der personen som er ansvarlig for å fikse en feil ikke er en tilegnet utvikler for en assosierte pakken (for eksempel hvis pakken er utviklet av et lag), så kan det være nyttig å rapportere dette i feilrapportsystemet. For å hjelpe med dette kan hver feilrapport valgfritt ha en eier.
Eieren kan bli sett ved å angi en Owner
-linje i
pseudo-hodet når en feilrapport en innsendt (se
instruksjoner for feilrapportering),
eller ved å bruke owner
og noowner
-kommandoene
med kontrolltjeneren.
Feilangitte pakkeutviklere
Hvis den ansvarlige for en pakke er oppgitt feil, er dette
vanligvis fordi pakkeansvarlig har skiftet nylig, og den nye
ansvarlige har ikke lastet opp en ny versjon av pakken med endret
Maintainer
-felt i kontrollfilen. Dette blir rettet på
når pakken lastes opp; alternativt kan de arkivansvarlige
overstyre angitt pakkeansvarlig for en pakke manuelt, særlig gjelder
dette dersom det ikke forventes at pakken kommer til å bli lastet
opp snarlig. Kontakt override-change@debian.org
for
endringer.
Gjenåpne, tilegne og endre på feilrapporter
Det er mulig å tilegne feilrapporter til andre pakker, gjenåpne
rapporter som ikke skulle vært lukket, endre på informasjonen om
hvor (hvis) feilrapporten er videresendt, endre på alvorlighetsgrad
og titler på feilrapporter, sette eierskap, slå sammen og ta
fra hverandre feilrapporter og angi versjoner av pakker der feilen ble
funnet og i hvilken det er fikset. Dette gjøres ved å sende epost til
control@bugs.debian.org
.
Formatet på disse meldingene er
beskrevet i et annet dokument tilgjengelig på WWW, eller i filen
bug-maint-mailcontrol.txt
. En ren tekstutgave kan
anskaffes ved å sende help
til adressen over.
Abonnere på feilrapporter
Feilrapportsystemet tillater også innsendere, utviklere og andre
interesserte tredjeparter å abonnere på individuelle feilrapporter.
Denne funksjonen kan bli brukt av de som ønsker å holde et øye med en
feilrapport, uten å måtte abonnere på en pakke gjennom
Debian Package Tracker.
Alle meldinger som er mottatt gjennom nnn@bugs.debian.org
,
er sendt til abonnenter.
Abonnere på en feilrapport kan bli gjort ved å sende en e-post til
nnn-subscribe@bugs.debian.org
. Tittelen og
kroppen til e-posten blir ignorert av feilrapportsystemet. Når en melding
har blitt behandlet vil brukeren få en bekreftelsesmelding som de er
nødt til å svare på før de får tilsendt meldinger som er relatert til
feilrapporten.
Det er også mulig å avslutte et abonnent på en feilrapport.
For å avslutte abonnentet må man send en e-post til
nnn-unsubscribe@bugs.debian.org
. Tittelen
og kroppen på e-posten er igjen ignorert av BTS. Brukerene vil få
tilsendt en bekreftelse som de må svare på hvis de ønsker å
avslutte abonnentet på feilrapporten.
Som standard vil adressen som blir funnet i Fra
-feltet
blir abonnenten. Hvis du ønsker å abonnere en annen adresse til en
feilrapport så må du endre på måten du abonnerer på. Dette tar følgende
form:
nnn-subscribe-
localpart=
example.com@bugs.debian.org
.
Det eksempelet ville sendt localpart@example.com
som en
abonneringsmelding til feilrapport nnn. Alfakrøll blir endret
til å være et erlik-tegn (=
). På samme måte tar en avslutning
på abonnentet form nnn-unsubscribe-
localpart=
example.com@bugs.debian.org
.
I begge tilfeller vil tittelen og kroppen av e-posten bli videresendt til e-postadressen
angitt for bekreftelse.
Mer eller mindre avlegs tittelfelt-søk
Meldinger som kommer til submit
eller
bugs
og hvis tittelfelt starter med
Bug#
nnn blir behandlet som om de hadde
blitt sendt til nnn@bugs
. Dette er både
av hensyn til bakoverkompatibilitet og for å hindre at
oppfølginger på feilrapporter havner som nye feilrapporter ved en
feil (f.eks at noen har brukt svar til alle).
Meldinger sendt til maintonly
, done
,
quiet
og forwarded
behandles på en
tilsvarende måte.
Meldinger som kommer til forwarded
og
done
— uten feilrapportnummer i adressen —
eller tittelfeltet blir lagret under junk
(søppel) og bevart i noen
uker, men ellers ignorert.
Avlegs X-Debian-PR: quiet
-egenskap
Tidligere kunne man unngå at feilrapportsystemet videresendte
innkommende meldinger til debian-bugs
ved å legge til
en X-Debian-PR: quiet
-linje i hodet på eposten.
Denne linjen blir nå ignorert. Send i stedet meldingen til
quiet
eller nnn-quiet
(eller
maintonly
eller
nnn-maintonly
).
Andre sider i feilrapporteringssystemet
- Forsiden til feilrapportsystemet.
- Hvordan rapportere feil.
- Komme til loggene på annet måter enn via web.
- Bruksansvisning for utviklere.
- Informasjon om hvordan man jobber med feilrapporter via epost.
- Referansekort for epost-tjeneren.
- Etterspør feilrapporter via epost.
Debian BTS administrators <owner@bugs.debian.org>
Debian bug tracking system
Copyright © 1999 Darren O. Benham, 1997, 2003 nCipher Corporation Ltd,
1994-1997 Ian Jackson.