QA/Bugzilla/Fields/Status/RESOLVED
TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate
Úč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:<LO version X.y.z>, 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' - tdf#86511
- 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é. 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 #INSUFFICIENTDATA (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
Tuto hodnotu prosím nepoužívejte, pokud stejná osoba nahlásila úplně stejný problém dvakrát, protože by to zkreslilo naše metriky. Místo toho zavřete duplikáty jako "INVALID".
WORKSFORME
Stručně řečeno, WORKSFORME je psáno "WFM".
Někdo v QA testoval tuto chybu pomocí poskytnutých kroků a/nebo testovacích dokumentů, mohl ji reprodukovat ve starší verzi, ale v aktuální verzi už to nejde.
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.
Rozhodnutí uzavřít chybu jako WFM bez zpětné vazby od původního reportéra nebo potvrzujících se provádí případ od případu. Normálně je dobré dát ostatním nějaký čas na testování. Je třeba vzít v úvahu stáří zprávy a její poslední potvrzení.
Důvodem, že chyba nejde zopakovat (WFM) ve stejném reprodukčním prostředí může být poškození uživatelského profilu. Nezapomeňte požádat oznamovatele chyby, aby vyzkoušel LibreOffice v nouzovém režimu a zjistil, zda obnovení uživatelského profilu (po zálohování) vyřeší jeho problém.
Opraveno v novější verzi
Pokud chyba zmizela v masteru, ale ne v jedné z aktuálně udržovaných větví vydání (viz náš plán vydání), považuje se chyba za vyřešenou, a proto ji označíme jako WFM.
Příklady:
- tdf#74300 - Base:Database "Position and Size" box does not paint - it displays what's beneath it instead
- tdf#79289 - 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:<active branch>. 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:
|
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ě nebo v gerritu), může být štítek backportRequest:X.y odstraněn a nahrazen štítkem backportDenied:X.y.
Pokud byl identifikován opravný commit, může být hlášení vyřešeno jako "FIXED" nebo "DUPLICATE", pokud tento commit zavře jinou zprávu, která popisovala v podstatě stejný problém.
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í tdf#85643
- Chyby zaokrouhlování, ke kterým dochází v důsledku pohyblivé řádové čárky na celočíselných hodnotách - tdf#86174
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 tdf#81854
- Excel má přetrvávající datovou chybu, kterou nemůže opravit kvůli problémům se zpětnou kompatibilitou tdf#86996
- Existuje software, který je mimo naši kontrolu, tdf#85652 redmine#845
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