Hoe een Probleem te melden

Probleemmeldingen voor uitgebrachte versies

1. Controleer eerst voor patches en opmerkingen over de versie.
2. Zoek daarna uit of er een nieuwere versie beschikbaar is.
3. Controleer als laatste de wijzigingen die aangebracht zijn tussen de versies van OpenBSD.

Als het er op lijkt dat uw probleem nergens aangekaart wordt, raak dan eerst bekend met sendbug(1) voordat u een probleemmelding maakt.

Lees verder onderaan de typen probleemmeldingen die gewenst zijn.

Probleemmeldingen voor de huidige versie

1. Test het probleem op zijn minst tweemaal, met de laatste broncode en een tussenperiode van een paar dagen.
2. Meld geen problemen over de compilatie van de broncode tenzij ze aanhouden. Dat is meestal uw fout of er wordt al aan gewerkt op het moment dat u ze tegenkomt. Mensen die aan het project werken voeren minstens één keer per dag make build uit en gewoonlijk enkele keren per dag met verschillende architecturen.
3. Wees erop bedacht dat de anoncvs servers significant achterlopen op de werkelijk huidige broncode.
4. Controleer voor wijzigingen tussen versies van OpenBSD om te zien of het probleem aangekaart is.
5. Er wordt veel aandacht besteed aan het maken van snapshots. Soms worden er fouten gemaakt, hiervoor onze excuses. Het lezen/schrijven naar de e-mail lijsten is toepasselijker dan een probleemmelding sturen.

Het sturen van een probleemmelding

Begin alstublieft geen problemen op te lossen die veel werk vereisen totdat u er zeker van bent dat u ze begrijpt, vooral tijdens de periode van een nieuwe uitgave wanneer we geen grote delen van de code moeten veranderen. Controleer als u grote hoeveelheden code gaat schrijven de verschillende forums om er zeker van te zijn dat niemand anders aan het probleem werkt (om te voorkomen dat werk dubbel wordt gedaan).

Elke probleemmelding moet het volgende bevatten:

1. De precieze volgorde van stappen die het probleem reproduceren. Het is niet genoeg om enkel het commando te melden zonder de argumenten en andere data die u het meegegeven heeft. Als een bug een bepaalde volgorde van gebeurtenissen vereist, meld deze dan alstublieft. U wordt aangeraden de grootte van het voorbeeld klein te houden, maar dit is niet noodzakelijk. Als de bug te reproduceren is zullen we hem evengoed vinden.

2. De uitvoer die u kreeg. Zeg alstublieft niet dat het "niet werkte" of "faalde". Laat de foutmelding zien als deze er is zelfs wanneer u hem niet begrijpt. Als zich een panic voordoet met een bepaalde foutmelding, vermeld deze dan. Als er niets gebeurt, vermeld dat dan. Zelfs wanneer het resultaat van uw test het crashen van een programma is of iets vanzelfsprekend, hoeft het niet voor te komen in onze test. Het is het makkelijkst om indien mogelijk de uitvoer van de terminal te kopiëren.

   N.b.: Bij fatale fouten kan het zijn dat de foutmelding niet alle informatie bevat. Kijk in dat geval ook naar de uitvoer in de systeemlogbestanden, zoals degene die in /var/log bewaard worden. Als het een toepassing betreft die zijn eigen log heeft, zoals httpd, controleer dan de plaats waar het z'n logs bewaard voor foutmeldingen (in het geval van httpd is dit /var/www/logs).

3. De uitvoer van de OpenBSD kernel. U kunt deze krijgen met het commando dmesg, maar het is mogelijk dat de uitvoer van dmesg niet alle informatie bevat die opgeslagen is in /var/run/dmesg.boot. Geef in dit geval de informatie van beide. Stuur dit alstublieft bij alle probleemmeldingen.

4. Als u software van een derde partij draait die te maken heeft met uw probleem, vermeld dit dan, inclusief de subversie van de software. Wanneer u het heeft over een snapshot via CVS of FTP, vermeld dat dan, inclusief de datum en tijd van de snapshot.

5. Een traceback van uw kernel panic. Wanneer een panic is opgetreden bij uw kernel en u bent bij een ddb> prompt, vermeld dan alstublieft zoals geadviseerd is de panic-boodschap en de uitvoer van de commando's trace en ps in uw probleemmmelding. Als de machine vastloopt, probeer dan sysctl ddb.console=1 in te schakelen voordat hij vastloopt en in DDB te geraken via Ctl+Alt+Esc op het toetsenbord (moet buiten X), of een BREAK te sturen wanneer u een seriële console gebruikt.
   Als om één of andere reden de panic-boodschap niet zichtbaar is, kunt u deze opnieuw opvragen met het commando show panic.
   Dit is waar mogelijk essentieel. Meldingen over een panic zonder de panic-boodschap, traceback- en ps-uitvoer zijn nutteloos.
   De uitvoer van show registers zou ook interessant kunnen zijn. Daarna zou u kunnen rebooten met boot dump zodat een image van de kernel door savecore(8) opgeslagen kan worden voor verdere post-mortem debugging zoals beschreven wordt in de crash(8) manpagina.

6. Als u een probleem meldt over het X Window systeem op een architectuur die de X.Org server gebruikt, voeg dan alstublieft het gehele bestand /var/log/Xorg.0.log bij uw bericht samen met de informatie van dmesg.boot.

Wees niet bezorgd wanneer uw probleemmelding erg lang wordt. Zo is het leven. Het is beter om alles de eerste keer te melden dan dat we feiten uit u moeten persen. Aan de andere kant, als de bestanden erg groot worden is het goed om eerst te vragen of iemand geïnteresseerd is om ernaar te kijken.

Probleemmeldingen opsturen

Gebruik, indien mogelijk, het commando sendbug(1) om het probleem in ons volgsysteem te krijgen. Voor sendbug moet uw systeem Internet email kunnen sturen. Als u sendbug niet kunt gebruiken op een functionele OpenBSD machine, stuur dan uw probleemmelding naar bugs@openbsd.org.

Wellicht is datgene wat u stuurt een verzoek voor een functionaliteit en niet per se een probleem. Nieuwe functionaliteiten worden aangenomen, zeker met code die uw voorgestelde functionaliteit implementeert. Als iemand anders code voor uw nieuwe functionaliteit schrijft, bestaat de kans dat het verkeerd wordt begrepen en zo wordt ontwikkeld dat u het niet herkent.

Voor het debuggen van sommige problemen moeten we de hardware hebben die het probleem heeft. Denk er alstublieft aan dat de bronnen van het OpenBSD project beperkt zijn. U zou wat hardware kunnen schenken.

De typen probleemmeldingen gesorteerd op wenselijkheid:

1. Herhaalbare problemen met reparatiecode zijn het beste.
2. Herhaalbare problemen die niet specifiek te maken hebben met uw hardware/software layout.
3. Herhaalbare problemen die specifiek zijn aan uw softwarelayout.
4. Herhaalbare problemen die specifiek zijn aan uw hardwarelayout.
5. Niet-herhaalbare problemen -- of problemen die u niet wilt herhalen.