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.