Effektiv fejlrapportering

Ude over selve det ideologiske frihedsaspekt er det vigtigste ved open source det tætte samspil mellem udviklere og brugere/testere. Derfor er det vigtigt af brugere ved hvordan man effektivt rapporterer fejl. Dette foredrag forsøger at forklare hvordan det gøres.


Hvorfor fejlrapportering?


Hvortil sendes fejlrapporteringer?

Selvbyggede programmer
Fejl sendes til forfatteren af programmet.
Fejl i distributioner (Debian, TurboLinux, Storm etc)
Fejl skal altid sendes til distributøren. De ved bedst hvordan programmet er oversat, samt hvilke biblioteker, der kan have indvirkning på fejlen

Er fejlen allerede kendt?

Det er generende som udvikler at modtage samme fejlrapport for mange gange. Derfor bør man tjekke om fejlen allerede er rapporteret.

Projekter med åbne fejlrapporteringssystemer søges der. (Debian, Mozilla, Sourceforgeprojekter)

Ellers søges med for eksempel www.google.com efter nogle passende ord: "gcc, segfaul t, nested function declarations".


Hvad skal rapporten bestå af (Hvad er der problemer med?)


Hvad skal rapporten bestå af (Hvad er problemet?)

Gentag problemet og prøv at find det mindste tilfælde der fejler.


Værktøjer

Til fejlrapportering:

Til fejlfinding:


Værktøjer til fejlrappotering

reportbug

Finder versionsnummer og pakkeafhængigheder og kan søge efter kendte fejl. Nyere versioner kan sende fejlen det rigtige sted hen (Debian, Helix, Storm...)

bugbuddy

Jeg kender det ikke, men Debian får en række fejlrapporteringer med et "Distribution: RedHat"-tag.


strace

Et program, der gør det muligt at følge systemkald. Kræver ikke genoversættelse af programmet. Hvert systemkald skriver en linje med systemkald, argumenter og resultat:

Åbne en fil:

open("/etc/passwd", O_RDONLY)  = 3

Åbne en fil der ikke findes:

open("foobar", O_RDONLY|0x8000) = -1 ENOENT (No such file or directory)

Ting du aldrig skal gøre...

... selvfølgelig medmindre at den du rapportere fejlen til netop har bedt dig om disse oplysninger


Opsumering

En god fejlrapportering indeholder altid:

Peter Makholm, peter@makholm.net