Bugzilla/da
TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate
Her kan du finde svar på Ofte Stillede Spørgsmål (OSS/FAQ) om Bugzilla.
[[Se svar på mere generelle spørgsmål om QA, på QA/FAQ.
Hvordan indsender jeg forespørgsler om forbedringer af selve Bugzilla '*
Bemærk: LibreOffice migrerer snart til et separat eksemplar af Bugzilla; disse politikker kan ændre sig.
Indsend forespørgsler om forbedringer af Bugzilla og andet i relation til infrastruktur som forespørgsler til produktet LibreOffice, så ESC kan sende dem videre til Bugzilla admin. Dette sikrer, at forslagene er udtryk for LibO-fællesskabets vilje og vil speede processen op. Et relevant ESC-medlem (fx Joel Madero) bør tilføjes til CC, så forslaget vil komme komme på dagsordenen på et ESC Call.
Hvordan citerer jeg andre kommentarer?
Undgå venligst at citere overflødigt og langtrukkent! Det er kedeligt at skulle læse endeløse gentagelser. Hvis du ikke svarer på kommentaren før, er det nyttigt at bruge Bugzillas [reply] (svar-) funktion. Hvis du mener, at det er nødvendigt at sætte din kommentar i kontekst, kan du citere 1 eller 2 relevante linjer af diskussionen af det punkt, men ikke et flerlinjers citat.
Altså: Brug ALDRIG dit email-program til dine kommentarer. Tilføj kommentarer til fejlen ved at bruge Bugzillas webside, hvor du har masser af information, der ikke er synlig i den sidste kommentar, du ser i en email-meddelelse.
Hvordan citerer jeg andre Libreoffice-fejl i Bugzilla?
For at få et link til din kommentar, skriver du bare noget i retning af ”Bug 12345“, hvor du erstatter ”12345“ med Bug-nummeret. Ingen ”#“, ingen andre dikkedarer i Bug-nummeret.
Generelt er det nyttigt at kopiere og indsætte hele resumé-linjen for den fejl, du citerer.
Hvor fortolker jeg information på Whiteboard Target
target:3.7.0 på Whiteboard betyder, at et fix er blevet ”skubbet“ til masterkoden. Den første offentlige version, hvor den bliver tilgængelig bliver 4.0.0.x. Hvis du undrer dig over, at en løsning ikke er blevet integreret i koden til en bestemt version, skal du være tålmodig. Før en løsning kan integreres i aktuelle kodeforgreninger, skal den gennemses af andre udviklere for at undgå regressionsfejl. Det tager noget tid. Så længen at fejlen ikke har skiftet status til FIXED kan du håbe på integration af løsningen i koden til den aktuelle forgrening.
Hvordan håndterer jeg kloner af fejrapporter?
Sommetider opretter en rapportør tilfældigvis flere kloner af den tilsigtede fejlrapport. Mærk venligst IKKE disse nyttesløse kloner som DUPLICATES (kopier). Mange duplikater kunne være et indicator signal om at et bestemt problem berører mange brugere. Luk i stedet hver unødvendig rapport som RESOLVED - INVALDIG (løst - ugyldig) med kommentaren Clone of Bug xxxxx (klon af fejl xxxxx).
Hvordan bruger jeg vedhæftede prøvedokumenter til flere fejlrapporter?
Det er hverken nødvendigt eller nyttigt at knytte det samme dokument til flere fejlrapporter igen og igen. Opret i stedet et Link med teksten 'vedhæftning 12345 til fejl 6789' i kommentarteksten eller rapportteksten til den nye fejlrapport. Dette opretter et link, så vedhæftningen let kan downloades, og du bidrager med oplysninger om, hvilken anden fejlrapport, der kan indeholde interessant information vedrørende dokumentet. For at finde vedhæftningsnummeret holder du musen over linket i den oprindelige rapport, som billedet af skærmen viser. Eller du kan kopiere / indsætte denne information fra siden Bugzilla Attachment Details Info Det er vigtigt at vide, hvilken fejlrapport vedhæftningen blev indsendt til, eftersom kommentarer ofte indeholder vigtig supplerende information.
På denne måde ved alle, at prøvedokumentet er identisk med dokumentet i den tidligere fejlrapport, så det er meget lettere at sammenligne resultater.
Hvordan tilføjer jeg fejlrapporter til MAB fejlsporing?
Se specialsiden om Most Annoying Bugs (mest irriterende fejl).
Hvordan validerer jeg en fejlløsning?
Hvis du prøvede at reproducere en med en version, som skulle have medtaget løsningen (se target-informationen på whiteboardet) og du kan bekræfte, at fejlen ikke længere eksisterer, kan du ændre fejlrapportens status til 'VERIFIED. (bekræftet). Dette viser, at løsningen er blevet bekræftet. Hvis du stadig kan reproducere fejlen, husk venligst How to reopen a bug (#Hvordan genåbnes en fejl).
Hvordan vedhæfter jeg Backtraces fejlsporinger?
Hvis du vil give udviklerne ekstra information som fejlsporinger og lignende materiale, skal du bestemme, om du vil bidrage med informationen
- som tekst i en kommentar
- Fordele:
- der kan søges efter indhold af fejlsporingen
- Ulemper:
- strenge i fejlsporingen kan frembringe uønskede hits i søgninger
- dårlig læselighed i Bugzilla fejlrapporten pga. endeløse kommentartekster i fejlsporingen
- Fordele:
- som et vedhæftet - tekstdokument
- Fordele
- læseligheden af Bugzilla-fejlen bliver ikke reduceret
- hvis der er nye fund, kan du mærke en vedhæftning som forældet
- Ulemper:
- Søgninger vedrørende fejlsporingsindhold er ikke muligt
- Ingen uønskede hits i søgninger på strenge i fejlsporingen, der matcher normale søgestrenge
- Fordele
Du bestemmer, hvad du foretrækker.
Hvordan nævner jeg vedhæftninger eller andre beslægtede fejlrapporter?
Det mest enkle og pålidelige er at skrive Bug 47712 (fx) i stedet for <https://bugs.documentfoundation.org/show_bug.cgi?id=47712>. Bugzilla vil tilføje et link til teksten, når den forekommer i en rapport eller kommentar. Ved vedhæftninger skal du skrive attachment 61814 i stedet for <https://bugs.documentfoundation.org/attachment.cgi?id=61814>.
Hvad er libreoffice.org/bugzilla?
Nej, ikke vores egen nye bugzilla, men Bugzilla-miljøet for vores Bugzilla. For det meste skulle du, når du møder sådan et link (i et URL-felt) vedrørende rapporterede fejl, udskifte det med et bugs.documentfoundation.org/ URL for at undgå login-problemer og lignende (sammenlign venligst med fejllinks i [#How to mention Attachments or other LibO related bug reports]].
Hvordan finder jeg de oplysninger, jeg har brug for?
Her kan du finde adskillige nyttige forespørgsler:
- Bugs still waiting for a developer (Fejl, der stadig venter på en udvikler)
- Fejl, der venter på QA-gennemsyn
For brugere af 64-bit operativsystemer
Det er muligt at køre 32-bit applikationer på 64-bit operativsystemer. Dette kan gøre Platform-vælgeren i Bugzilla en smule forvirret. Generelt skal du venligst skrive, hvilken version din LibreOffice blev bygget til. Denne information er desværre ikke synlig i applikationen, imidlertid:
- Windowsbrugere: Der aktuelt ingen officiel 64-bit version. Du bruger mest sandsynligt en 32-bit version, brug x86 (IA32). Nævn venligst dit operativsystem under Beskrivelse.
- Linux-brugere: I de fleste tilfælde skulle du bruge en 64-bit version af LibreOffice, hvis dit system også er 64-bit. Dit package manager kunne give yderligere vink. Der er mest sandsynligt, at du kan bruge "x86-64 (AMD64)".
- Mac OS users: ...
Hvordan åbner jeg en fejlrapport
Se detaljer [[QA/BSA/BugReport Details|here].
- == Hvordan mærker jeg en en fejlrapport som som et duplikat ==
Hvis du finder ud af, at en fejlrapport (fx tdf#40691) er et DUPLICATE af en eksisterende (tdf#37195), skal du bestemme, hvilken af de to, der skal bevares. Sædvanligvis beholder du den ældste rapport, men sommetider har den nyeste yderligere værdifuld information, eller den har en mere avanceret status (Tildelt).
Når du har bestemt, hvilken rapport, der skal bevares, mærker du den anden som Duplikat, (tdf#40691) og indsætter nummeret på den rapport du beholder (37195) i panelet, der åbnes, når du klikker på ”Mærk som duplikat“. Det er ikke nødvendigt at overføre rapportør og CC-liste til den bestående rapport tdf#37195, fordi Bugzilla vil sende oplysninger om alle ændringer i den bestående rapport til rapportører og CC af rapporter, der er lukket som duplikater.
Hvordan lukker jeg en fejlrapport, hvis fejlen ikke længere kan reproduceres?
Hvis en fejlrapport er blevet bekræftet, men problemet er forsvundet med en senere LibreOffice-version, skal du ikke bruge Resolved Fixed til at lukke rapporten. Det er reserveret til fejl med en reelt gennemset løsning. Den passende Status for en fejl, hvor problemet simpelthen er forsvundet er Resolved WORKSFORME (fungerer for mig).
En gennemset løsning er meget mere pålidelig end en ukendt grund til et forsvundet problem. Denne forskel skulle være synlig i Status-informationen. Den version, hvor fejlen ikke længere kan reproduceres, bør nævnes på whiteboardet som Target. Specielt hvis det er din første kontakt med en bestemt fejl (så du aldrig har reproduceret problemet), skal du beskrive trin for trin, hvordan du gennemførte din test. Det kan give vigtig information:
- Mulige grunde til, at det virker nu
- Trin for trin instruktioner til at reproducere fejlen er så uklare, at du udførte en test, der var forskellig fra rapportørens test.
- problemet er reelt, men er relateret til en bestemt, for tiden udkendt, betingelse. Din test inkluderede ikke den betingelse.
Hvordan tildeler jeg en fejlrapport (kun QA-team)?
- Brugerkonto for Friendly Expert (eller kendt udvikler af problemet) vil blive indsat i CC af en erfaren bruger. Status forbliver (eller bliver) New (ny)
- Udvikleren accepterer fejlen ved
- at til føje sigselv til ”'Tildelt til og
- skifte status til ”TILDELT“
Eller accepterer ikke tildeling af fejlen.
Fejlen er stadig synlig, selv om fejlstatus er FIXED (løst)?
Løsningen er måske ikke blevet integreret i den næste udgave. Se venligst Target (mål)-informationen på whiteboardet eller i GIT linket.
Er RC-versionen forsvundet?
Du har indsendt en fejlrapport, men nu kan du ikke finde den med Search by Version ((søg efter version) fx med et link, du har bogmærket)? Årsagen kan være, at du opdagede fejlen i den sidste Release Candidate før udgivelsen. Hvis LibreOffice udgivelsesversion bit for bit er identisk med den sidste RC-version, vil RC-versionen af versionsvælgeren blive omdøbt til Udgivelsesversion (fx 3.4.2 RC til 3.4.2 Release af administratoren.
Bugzilla-afstemning?
Bugzilla har en funktionalitet, som lader projektmedlemmer stemme på fejlrapporter, som de mener skal have opmærksomhed tidligere. LibreOffice bruger ikke denne funktionalitet, da Engineering Steering Committee ikke tror, at enkle afstemninger giver tilstrækkelig ny information.
Det betyder imidlertid ikke, at der er en fundamental modstand mod enhver form for brugerafstemning“. Hvis nogen har et velfunderet, overbevisende forslag , kan vi diskutere spørgsmålet igen; og hvis svaret er positivt, vil vi finde en infrastruktur til processen. Vi har en eksperimentel Vote for Enhancement funktionalitet, men brugerinteressen synes ikke at være vældig stor og den aktuelle brug er langt fra målet om at give gode argumenter i stedet for bare at tælle stemmer.