QA/Bugzilla/FAQ

From The Document Foundation Wiki
< QA‎ | Bugzilla
Jump to: navigation, search
This page is a translated version of the page QA/Bugzilla/FAQ and the translation is 100% complete.

Other languages:
čeština • ‎English • ‎русский

Zde najdete odpovědi na často kladené otázky (FAQ) o Bugzille.

Pro odpovědi na obecnější otázky o QA viz QA/FAQ.

Jak odeslat požadavky na vylepšení samotné Bugzilly?

Pošlete žádosti o vylepšení " Bugzilla" a další související infrastruktury jako ticket Redmine pro kategorii Bugzilla.

Jak pracovat s komentáři ostatních?

Prosím vyhněte se nadbytečným a zdlouhavým citacím. Je únavné číst nekonečná opakování. Pokud neodpovídáte na předchozí komentář, je užitečné použít funkci Bugzilla [reply] (odpovědět). Pokud si myslíte, že je nezbytné uvést váš komentář v kontextu, můžete citovat 1 nebo 2 relevantní řádky diskuze k danému bodu, ale nikoliv mnohořádkové citace.

NIKDY nepoužívejte pro své komentáře email interface. Přidejte komentáře k chybě pomocí webové stránky Bugzilla, kde je řada informací, které nejsou viditelné v posledním komentáři, který vidíte v e-mailové zprávě.

Jak komentovat ostatní LibreOffice chyby v Bugzille?

Chcete-li do odkazu přidat odkaz na další chybu, jednoduše napište něco jako Bug 12345 , kde "12345" nahrazuje Bug Number (číslo chyby). Žádné "#", nic dalšího nepřidávejte do čísla chyby. Obecně je užitečné zkopírovat a vložit celý řádek Shrnutí chyby, kterou citujete.

Jak interpretovat Whiteboard Target information

"target:3.7.0" v Whiteboardu znamená, že oprava byla "nahrána" do kódu pro master. První veřejná verze, kde bude k dispozici, bude ""4.0.0""x. Pokud vás zajímá, proč oprava nebyla do kódu integrována pro konkrétní verzi, buďte trpěliví! Předtím, než může být oprava integrována do aktuálních větví kódu, musí být oprava zkontrolována jinými vývojáři, aby nedošlo k regresním chybám. To trvá nějakou dobu. Dokud chyba nezmění status na "FIXED", můžete doufat v integraci oprav do kódu aktuálních větví.

Jak zacházet s klony chybových hlášení

Screenshot

Někdy oznamovatel chyby náhodně vytvoří několik klonů zamýšleného hlášení o chybě. Prosím NEOZNAČUJTE tyto zbytečné klony jako DUPLIKÁTY. Mnoho duplikátů by mělo být indikátor, že se určitý problém dotýká mnoha uživatelů. Namísto toho uzavřete každou nepotřebnou zprávu jako RESOLVED - INVALID s poznámkou „Clone of Bug xxxxx“ (klon chyby xxxxx).

Jak používat přiložené příklady dokumentů pro více hlášení o chybách

Screenshot, prosím smažte "Details" po copy&paste (zkopírování a vložení) "Přílohy ..." z nadpisu Okna pro komentář.

Není nutné ani užitečné připojovat tentýž dokument do více hlášení o chybách znovu a znovu. Místo toho vytvořte odkaz s textem ""příloha 12345" z "Bug 6789"" v textu komentáře nebo v textu zprávy o nové chybové zprávě. Tím vytvoříte odkaz pro snadné stažení přílohy a přispíváte informacemi o tom, jaké další zprávy o chybách mohou obsahovat zajímavé informace týkající se dokumentu.

Chcete-li najít číslo přílohy, najeďte myší na odkaz v původní zprávě, jak ukazuje obrázek. Nebo můžete tyto informace zkopírovat / vložit ze stránky "Bugzilla Attachment Details Info" ("Informace o přílohách Bugzilly"). Je důležité vědět, pro jakou zprávu o chybě byla odeslána příloha, protože komentáře často obsahují důležité doplňující informace.

Takto každý bude vědět, že ukázkový dokument v nové zprávě o chybách je totožný s dokumentem v dřívější zprávě o chybách, takže je mnohem snazší porovnávat výsledky.

Jak přidat hlášení o chybách do sledování chyb MAB

Viz zvláštní stránka o MostAnnoyingBugs.

Jak ověřit opravu chyby

Pokud jste se pokusili reprodukovat chybu s verzí, která měla obsahovat opravu (viz informace "target" ve Whiteboard) a můžete potvrdit, že chyba již neexistuje, můžete upravit stav hlášení chyb na "VERIFIED". To znamená, že oprava byla potvrzena. Pokud stále dokážete chybu reprodukovat, mějte na paměti Jak znovu otevřít hlášení o chybě.

Jak připojit Backtraces

Pokud chcete vývojářům poskytnout další informace, jako je Backtraces a podobný materiál, musíte se rozhodnout, zda přispějete informacemi

  • Jako text v komentáři
    • Výhody:
      • lze provést dotazy pro obsah Backtrace
    • Nevýhody:
      • řetězce v Backtrace mohou vyvolat nechtěné požadavky na dotazy
      • špatná čitelnost hlášení o chybě Bugzilla kvůli nekonečným textům komentářů Backtrace
  • Textový dokument jako příloha
    • Výhody:
      • čitelnost Bugzilla Bug není snížena
      • Pokud existují nová zjištění, můžete označit přílohu jako zastaralou
    • Nevýhody:
      • Nejsou možné žádné dotazy týkající se obsahu Backtrace
      • Žádné nežádoucí zásahy v dotazech pomocí řetězců v Backtrace, které by se shodovaly s „normálními“ řetězci dotazů

Je to vaše rozhodnutí, čemu dáte přednost.

Jak zmínit přílohy nebo jiné zprávy o chybách souvisejících s LibO

Nejjednodušší a spolehlivý způsob je napsat "Bug 47712" (například) místo "<https://bugs.documentfoundation.org/show_bug.cgi?id=47712>". Bugzilla přidá odkaz na text, když se objeví v hlášení nebo komentáři. Pro přílohy byste měli napsat "attachment 61814" místo "<https://bugs.documentfoundation.org/attachment.cgi?id=61814>".

Co je "libreoffice.org/bugzilla"?

Ne, ne naše nová bugzilla, ale prostředí Bugzilla pro naši Bugzillu. Většinou pokud najdete takový odkaz (v poli URL) týkající se nahlášených chyb, měli byste jej nahradit URL "bugs.documentfoundation.org/", abyste se vyhnuli problémům s přihlášením a podobně (porovnejte odkazy na chyby (Bug links) v #Jak zmínit přílohy nebo jiné zprávy o chybách souvisejících s LibO.

Jak najdu potřebné informace?

Zde je několik užitečných dotazů:

Pro uživatele 64bitových operačních systémů

Je možné spustit 32bitové aplikace na 64bitových operačních systémech. To může způsobit, že výběr platformy v Bugzille je trochu matoucí. Obecně zadejte, pro co byla vaše verze LibreOffice vytvořena. Tato informace bohužel není v aplikaci viditelná:

  • "'Uživatelé Windows'": jsou k dispozici jak 32bitové, tak 64bitové verze. V případě 32bitové verze použijte ""x86 (IA32)"". V části „Popis“ uveďte svůj operační systém.
  • "'Uživatelé Linuxu'": ve většině případů používáte 64bitovou verzi LibreOffice, pokud je váš systém 64bitový. Tip - váš package manager může poskytnout další rady. U 64bitové verze použijte ""x86-64 (AMD64)"".
  • "'Uživatelé MacOS'": MacOS podporuje pouze 64-bit.

Jak znovu otevřít hlášení o chybě

Podrobnosti viz "'zde.'"

Jak označit hlášení o chybě jako duplikát

MarkAsDuplicate.png

Pokud zjistíte, že hlášení o chybě (například tdf#40691) je DUPLIKÁTEM již existujícího (tdf#37195), rozhodněte se, který z nich ponecháte. Obvykle ponecháte starší hlášení, ale někdy novější hlášení obsahuje další cenné informace nebo má pokročilejší stav (Assigned).

Když jste se rozhodli, které hlášení ponechat, označte druhé hlášení jako duplikát, (tdf#40691) vložte číslo hlášení, které uchováváte (37195), do podokna, které se otevře po kliknutí na tlačítko "Mark as Duplicate" („Označit jako duplikát“). Není nutné přenášet seznam reportérů a CC do zbývající zprávy tdf#37195, protože Bugzilla bude zasílat informace o všech změnách ve zbývající zprávě reportérům a CC zpráv uzavřených jako duplikáty.

Jak zavřít hlášení o chybě, pokud již nelze chybu reprodukovat

Pokud byla zpráva o chybě potvrzena, ale problém zmizel s novější verzí LibreOffice, nepoužívejte k uzavření hlášení "Resolved Fixed". To je vyhrazeno pro chyby s reálnou opravenou opravou. Pro chyby, kde problém jednoduše zmizel je vhodný Status ""Resolved WORKSFORME""

Revidovaný "Fix" je mnohem spolehlivější řešení než neznámý důvod zmizelého problému. Tento rozdíl by měl být viditelný v informacích o stavu. Verze, ve které již chybu nelze reprodukovat, by měla být uvedena ve Whiteboard jako Target. Zejména pokud se jedná o váš první kontakt s konkrétní chybou (abyste problém nikdy neopakovali), popište, krok za krokem, jak jste provedli test. To by mohlo poskytnout důležité informace:

  • Možné důvody, proč to nyní funguje
    • Pokyny k reprodukci chyby krok za krokem jsou příliš nejasné, takže jste provedli test odlišný od testu reportéra.
    • problém je skutečný, ale souvisí s konkrétní, dosud neznámou podmínkou. Váš test tuto podmínku nezahrnul.

Jak přiřadit hlášení o chybě (pouze tým QA)

  • Uživatelský účet „Friendly Expert" (nebo známý vývojář problému) vloží zkušený uživatel do "CC". Status zůstává (nebo se stává) "New"
  • Vývojář přijímá hlášení o chybě
    • přidává se k položkám "Assigned to", ""a""
    • změna stavu na "ASSIGNED"

nebo nepřijímá přiřazení chyby.

Chyba stále viditelná, i když je status chyby FIXED?

Oprava pravděpodobně nebyla integrována do příští verze. Přečtěte si informace o "Target" ve "Whiteboard" nebo odkazu GIT.

RC verze zmizela?

Podali jste hlášení o chybě, ale nyní jej nemůžete najít pomocí „Search by Version“ (například pomocí odkazu, který jste si zaregistrovali)? Důvodem může být to, že jste chybu objevili v posledním kandidátovi na verzi před vydáním. Pokud je verze LibreOffice Release bit by bit totožná s poslední RC, verze RC z Version Picker bude změněna na Release Version (například: "3.4.2 RC" na "3.4.2 release") administrátorem.

Hlasování v Bugzille?

Bugzilla má funkci, která umožňuje členům projektu hlasovat pro hlášení o chybách, o kterých si myslí, že by se jim měla věnovat pozornost dříve. LibreOffice tuto funkci nepoužívá, protože Engineering Steering Committee nevěří, že pouhé hlasování přináší dostatek nových informací.

To však neznamená, že existuje zásadní odpor vůči jakémukoli „uživatelskému hlasování“. Pokud má někdo opodstatněný a přesvědčivý návrh, můžeme tuto otázku znovu projednat; a pokud je zpětná vazba pozitivní, najdeme infrastrukturu pro tento proces.

Statistiky Bugzilla

Viz QA/Bugzilla/Statistics.