QA/Bugzilla/Fields/Status/RESOLVED/cs

Účel této stránky
Tato stránka je o stavu RESOLVED v poli Status v Bugzille. Je věnována vysvětlení a objasnění účelu vícero stavů RESOLVED a také popisuje kroky, které může QA provést při řešení RESOLVED chyb.

Význam RESOLVED
Pro RESOLVED existuje mnoho podstavů:
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 * 

FIXED
Tato chyba byla opravena konkrétním potvrzením. Ve Whitboardu by měla být jedna nebo více štítků target:, z nichž každý označuje verzi/větev LibreOffice, do které bude toto potvrzení zahrnuto.

Příklady:
 * 'Blue 1' je nastaven na stejnou barvu jako 'Sky Blue 1' -
 * Whiteboard: target:4.5.0 target:4.4.0.0.beta2

Pokud nevíte, kterým potvrzením byla chyba opravena, použijte místo toho RESOLVED WORKSFORME.

INVALID
Něco v tomto hlášení o chybě je neplatné nebo se nevypočítává. Pokud například někdo podá zprávu, jako je tato, vyřešili bychom ji jako INVALID:

Jsem mrož Jsem mrož a myslím, že by to měli vědět všichni. Repro kroky jsou jíst ryby.

Dříve jsme stav RESOLVED INVALID používali, abychom zachytili různé skupiny chyb, včetně chyb, které byly ve stavu NEEDINFO déle než půl roku a které jsme chtěli vyčlenit. Nyní máme stav (nedostatečná data), který se lépe hodí pro tyto kategorie chyb.

WONTFIX
Může to být chyba, ale z nějakého důvodu ji neplánujeme opravit (což je obvykle podrobně uvedeno v komentáři, když je chyba vyřešena jako WONTFIX). Příklady zahrnují:
 * Chyba, která nemá vliv na skutečné uživatele

DUPLICATE
Tato chyba je duplikátem další chyby, která je již v systému

WORKSFORME
Stručně řečeno, WORKSFORME je psáno "WFM".

Někdo v QA tuto chybu testoval a není schopen ji reprodukovat pomocí poskytnutých kroků a nebo testovacích dokumentů.

Stejné reprodukční prostředí
Pokud máte stejné prostředí jako reportér chyb (např. stejný OS, stejná verze LibreOffice), více důvěřujeme označení chyby jako WFM. Pokud nemáte stejné prostředí (např. stejnou verzi LO, ale reportér je na Windows a vy na MacOS), zkontrolujte, zda má někdo v kanálu QA/IRC stejné prostředí a může tak podruhé zkontrolovat vaši práci.

Opraveno v novější verzi
Pokud je chyba opravena v master, ale ne v Fresh nebo Fresh, ale ne v Still, chyba je považována za opravenou, a tak ji označíme jako WFM.

Příklady:
 * - Base:Database "Position and Size" box does not paint - it displays what's beneath it instead
 * - FILEOPEN: Tvary DOCX se změní na rámečky a pozadí výplně není zachováno

Pokud víme, které potvrzení problém vyřešilo, je dobré požádat autora (vývojáře), zda je možné opravu opravit. Pokud nevíme, kterým potvrzením je chyba opravena, musíme to zjistit. Můžeme přidat klíčové slovo bibisectRequest a zadat na whiteboard backportRequest:. To bude znamenat, že musíme udělat reverse bibisect (zjistit, kdy byla chyba opravena, místo toho, kdy byla chyba zavedena :-)

Příklad whiteboard: backportRequest:4.2 backportRequest:4.3

''POZNÁMKA: Než požádáte vývojáře o pomoc, zkuste udělat Bibisect práci sami, aby zjistili, kterým potvrzením byla chyba opravena. To pomůže deva udělat každý den co nejvíce práce!''

Jakmile je chyba opravena na všech aktivních větvích LibreOffice (buď backportingem nebo pobočkami dosahujícími EOL), nebo pokud vývojář odmítne požadavek backportu (přidáním komentáře k chybě), může být štítek backportRequest:X.y odstraněn a nahrazen štítkem backportDenied:X.y.

MOVED
Používá se, když Bugzilla není tím správným místem pro zprávu.

NOTABUG
"Problém" popsaný reportérem chyb je součástí očekávaného chování LibreOffice. Příklady:
 * Funkce funguje podle očekávání
 * Chyby zaokrouhlování, ke kterým dochází v důsledku pohyblivé řádové čárky na celočíselných hodnotách -

NOTOURBUG
Problém je tady, ale v LibreOffice to problém není.

Příklady:
 * LibreOffice čte/zapisuje formát souboru správně, ale jiný software ne
 * Excel má přetrvávající datovou chybu, kterou nemůže opravit kvůli problémům se zpětnou kompatibilitou
 * Existuje software, který je mimo naši kontrolu,

INSUFFICIENTDATA
Jak bylo požadováno, byl stav přidán ESC, aby zahrnoval chyby, které přestaly být řešeny nebo nemají dostatek dat, abychom mohli pokračovat s tříděním a opravami chyb.

Příklady:
 * Uživatel není ochoten sdílet soukromý dokument s "kýmkoli" a my jej nemůžeme reprodukovat
 * Chyba je ve stavu NEEDINFO po dobu více než 6 měsíců

Úvaha:
 * V současné době označujeme odložené chyby jako RESOLVED WORKSFORME nebo RESOLVED INVALID, ale další hodnota stavu nám může pomoci přesněji určit, proč byla chyba odložena.
 * Další status by nám umožnil být více diplomatičtí s tvrdými uživateli a vyhnout se v takových chybách potenciálním negativům stavu "INVALID" nebo "WORKS FOR ME"

Pojmenování:
 * Bylo navrženo několik jmen pro tento stav:
 * ABANDONED
 * INSUFFICIENT_DATA (Red Hat bugzilla)
 * EXPIRED (Launchpad)
 * Podtržítko mezi dvěma slovy „INSUFFICIENT_DATA“ bylo odstraněno, aby odpovídalo stylu stávajících stavů RESOLUTION v Bugzille