Er zijn vele soorten problemen, die niet allemaal geschikt zijn voor een probleemrapport. Natuurlijk is niemand perfect dus zal het soms voorkomen dat u overtuigd bent dat u een bug in een programma heeft gevonden terwijl u in feite de syntaxis voor een commando verkeerd begrepen heeft of een typefout in een instellingenbestand gemaakt heeft (hoewel dat soms zelf al op slechte documentatie of slechte foutafhandeling in de applicatie kan wijzen). Er zijn nog steeds veel gevallen waarin het insturen van een probleemrapport duidelijk niet de juiste handeling is, en het alleen tot frustratie bij uzelf en de ontwikkelaars leidt. Omgekeerd zijn er gevallen waarin het juist kan zijn om een probleemrapport in te sturen over iets anders dan een bug—bijvoorbeeld voor een verbetering of een nieuwe mogelijkheid.
Dus hoe wordt bepaald of iets wel of niet een bug is? Een eenvoudige vuistregel is dat uw probleem geen bug is als het als een vraag kan worden uitgedrukt (meestal van de vorm “Hoe doe ik X?” of “Waar kan ik Y vinden?”). Het is niet altijd zo zwart-wit, maar de vraagregel gaat in de meeste gevallen op. Overweeg, als u een antwoord zoekt, om uw vraag aan de FreeBSD algemene vragen mailinglijst te stellen.
Enkele gevallen waar het juist kan zijn om een probleemrapport in te sturen over iets dat geen bug is zijn:
Meldingen van updates aan extern onderhouden software (over het algemeen ports, maar ook extern onderhouden componenten van het basissysteem zoals BIND of verscheidene gereedschappen van GNU).
Voor onbeheerde ports (MAINTAINER
bevat
ports@FreeBSD.org
) kan zo'n updatemelding
opgepakt worden door een geļnteresseerde committer, of u
kunt gevraagd worden om een patch aan te leveren om de port
bij te werken; door dit van te voren aan te bieden verhoogt u
in sterke mate de kans dat de port binnen een redelijk
tijdsbestek wordt bijgewerkt.
Als de port beheerd wordt, zijn PR's die nieuwe stroomopwaartse uitgaven aankondigen niet erg nuttig aangezien ze aanvullend werk voor de committers genereren, en waarschijnlijk weet de beheerder al dat er een nieuwe versie uit is, ze hebben er waarschijnlijk met de ontwikkelaars aan gewerkt, ze zijn waarschijnlijk regressietesten aan het uitvoeren, enzovoorts.
In beide gevallen zal het volgen van het proces zoals beschreven in het Porters Handboek tot de beste resultaten leiden. (U bent misschien ook geļnteresseerd in Bijdragen aan de FreeBSD Portscollectie.)
Een bug die niet reproduceerbaar is kan zelden gerepareerd worden. Als een bug slechts eenmalig voorkwam en u deze niet kunt reproduceren, en het bij niemand anders lijkt voor te komen, dan bestaat de kans dat geen van de ontwikkelaars het kan reproduceren of kan uitzoeken wat er mis is. Dit betekent niet dat het niet gebeurde, maar wel dat de kans dat uw probleemrapport ooit tot een reparatie leidt erg klein is. Om het allemaal erger te maken, worden dit soort bugs vaak veroorzaakt door falende harde schijven of oververhitte processoren — u dient altijd te proberen om deze oorzaken, indien mogelijk, uit te sluiten voordat u een PR instuurt.
Vervolgens, om te besluiten aan wie u uw probleemrapport dient te sturen, moet u weten dat de software waaruit FreeBSD bestaat uit verschillende elementen is opgebouwd:
Code in het basissysteem die geschreven is en onderhouden
wordt door FreeBSD-vrijwilligers, zoals de kernel, de
C-bibliotheek, en de apparaatstuurprogramma's (gecategoriseerd
als kern
); de binaire hulpmiddelen
(bin
); de handleidingpagina's en
documentatie (docs
); en de webpagina's
(www
). Alle bugs in deze gebieden dienen
aan de FreeBSD-ontwikkelaars gerapporteerd te worden.
Code in het basissysteem die geschreven is en onderhouden
wordt door anderen, en in FreeBSD is geļmporteerd en
aangepast. Voorbeelden zijn bind,
gcc(1), en sendmail(8). De meeste bugs in deze
gebieden dienen aan de FreeBSD-ontwikkelaars gerapporteerd te
worden; maar in sommige gevallen kan het zijn dat ze aan de
originele auteurs gerapporteerd moeten worden als de problemen
niet specifiek voor FreeBSD zijn. Gewoonlijk vallen deze bugs in
ofwel de categorie bin
ofwel de categorie
gnu
.
Individuele applicaties die niet in het basissysteem
zitten maar in plaats daarvan deel zijn van de Portscollectie
van FreeBSD (categorie ports
). De meeste van
deze applicaties zijn niet geschreven door FreeBSD-ontwikkelaars;
wat FreeBSD biedt is slechts een raamwerk om de applicatie te
installeren. Daarom dient u alleen een probleem aan de
FreeBSD-ontwikkelaars te rapporteren als u gelooft dat het
probleem specifiek voor FreeBSD is; anders dient u het aan de
auteurs van de software te rapporteren.
Daarna dient u vast te stellen of het probleem actueel is. Er zijn maar weinig dingen die een ontwikkelaar meer irriteren dan het ontvangen van een probleemrapport over een bug die reeds gerepareerd is.
Als het probleem in het basissysteem zit, dient u eerst het FAQ-gedeelte over FreeBSD-versies te lezen als u niet reeds bekend bent met het onderwerp. Het is niet mogelijk voor FreeBSD om problemen in iets anders dan bepaalde recente takken van het basissysteem op te lossen, dus leidt het insturen van een bug-rapport over een oudere versie waarschijnlijk alleen tot het advies van een ontwikkelaar om naar een ondersteunde versie bij te werken om te kijken of het probleem nog steeds voorkomt. Het Security Officer Team onderhoudt de lijst van ondersteunde versies.
Als het probleem in een port zit, moet u uw Portscollectie eerst naar de laatste versie bijwerken en kijken of het probleem nog steeds van toepassing is. Wegens de hoge snelheid waarmee deze applicaties veranderen, is het onhaalbaar voor FreeBSD om iets anders dan de allernieuwste versies te ondersteunen, problemen met oudere versies van applicaties kunnen simpelweg niet worden opgelost.
All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/
Questions that are not answered by the
documentation may be
sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.