Jak přispívat do LibreOffice IX – Nahlášení a sledování chyby

LO.png V minulém díle seriálu jsme v Calcu objevili nepříjemnou chybu a ověřili, za jakých podmínek se projevuje. V dnešním pokračování ji nahlásíme do bugzilly tak, abychom měli co největší šanci na brzkou opravu.  

Nahlášení chyby do bugzilly

Z předchozího dílu víme, že se chyby LibreOffice hlásí do bugzilly. Uživatele, který ještě nikdy chybu neoznamoval, může množství vyplňovaných údajů úspěšně zmást, proto softwarové projekty mívají přívětivější a jednodušší způsob zadávání chyb. Pro LibreOffice byl k dispozici tzv. Bug Submission Assistant, webová stránka tvořící rozhraní k bugzille. S přechodem bugzilly na servery The Document Foundation byl však v lednu 2015 tento asistent nadobro zrušen. Jako jeho náhrada má být v bugzille připravena zjednodušená šablona pro zadávání chyb, několik měsíců ale zůstává jen u slibů.

Ukázková chyba vyplněná v dnes již zrušeném Bug Submission Assistantu Ukázková chyba vyplněná v dnes již zrušeném Bug Submission Assistantu

Absence zjednodušeného zadávání sice zamrzí, nicméně při znalosti významu vyplňovaných položek není přímé zadání do bugzilly o mnoho těžší než s pomocí asistenta.

Abychom mohli zadat novou chybu, napřed se do bugzilly přihlásíme. Jestliže tam dosud nemáme účet, je nutné se zaregistrovat (a doufat, že snad někdy vznikne jednotné přihlašování pro všechny služby spojené s LibreOffice).

Na úvodní stránce pro novou chybu zvolíme, jakého softwarového produktu se naše chyba týká. Nejspíš půjde o samotný „LibreOffice“, ve stejné bugzille se ale nachází i jiné projekty spravované The Document Foundation: především dálkové ovládání prezentací Impressu a různé knihovny, jež připravuje Document Liberation Project. Výběrem projektu se přesuneme na stránku s vyplňováním položek; ve výchozím stavu jsou zobrazeny jen ty nejdůležitější.

Formulář pro vyplnění chyby se zobrazením pouze některých položek Formulář pro vyplnění chyby se zobrazením pouze některých položek

Základní informace o chybě

Nejprve zvolíme kategorii (položka „Component“), ke které bude chyba přiřazena. Při výběru se zobrazuje podrobný popis kategorie. V našem případě je jasnou volbou „Calc“, chyby specifické pro dílčí programy totiž mají samostatné kategorie. Chyby týkající se uživatelského rozhraní nebo více součástí spadají do kategorie „UI“, existují také speciální kategorie jako „Documentation“ pro nápovědu a uživatelské příručky. Naproti tomu zde již nenalezneme kategorii pro webové stránky a podobnou infrastrukturu – související chyby se poněkud nelogicky hlásí prostřednictvím systému Redmine.

Kategorii lze upřesnit v názvu chyby klíčovým slovem, jehož návrhy se zobrazují v popisu kategorie. Na naši chybu nejlépe pasuje „Editing“, vztahující se k úpravám obsahu sešitu.

Poté přijde na řadu číslo verze LibreOffice, ve které se chyba prvně objevila. Pokud sahá až do doby, kdy existoval pouze OpenOffice.org, zvolíme „Inherited From OOo“. Vhodné je uvést také čísla testovaných verzí, v níž se chyba ještě neprojevovala, prostor na to máme v popisu chyby. Jestliže chyba vznikla během vývoje LibreOffice, jde o tzv. regresi (regression), tj. rozbití věci, která doposud fungovala – a takovým chybám je logicky věnována větší pozornost. Regresí je i naše ukázková chyba, objevila se totiž prvně v řadě 4.2.

Dalším údajem je operační systém, v němž se chyba projevuje. Pokud jsme ji zopakovali na více systémech, zvolíme „All“.

Následujícím krokem je vyplnění dostatečně výstižného názvu („Summary“), a to včetně případného upřesnění kategorie. Když název zadáváme, zobrazují se pod ním jako prevence vkládání duplicit názvy podobných chyb. Jistější je ale přímá kontrola v bugzille, kterou jsme provedli v minulém díle.

popisu chyby („Description“) podrobněji vysvětlíme, v čem problém spočívá, vypíšeme stručný, ale jednoznačný postup, jak chybu zopakovat včetně toho, co se po jeho dokončení stane a co bychom ve skutečnosti očekávali. V našem konkrétním příkladu se tedy jedná o vše, co bylo součástí popisu chyby v úvodu minulého dílu. Doplněny mohou být další okolnosti a postřehy z testování chyby, v našem případě to, kdy se chyba naopak neprojevuje.

Zopakujme, že hlášení a jeho popis se vždy týkají jediné, samostatné chyby. Nesouvisející či rozvláčné povídání nemá v popisu co dělat; nikoho vážně nezajímá třeba to, kolik hodin svého drahocenného času jsme pátráním po chybě strávili. Na závěr popis důkladně zkontrolujeme (aby se nám jako například v ukázce nestalo, že v první větě napíšeme „row“ místo „column“).

Stejně jako u jiných činností popsaných v předešlých dílech seriálu, v hlášeních a při komunikaci v bugzille stačí používat mezinárodní verzi angličtiny, která si neláme hlavu s jemnostmi Shakespearova jazyka a jejímž jediným kritériem správnosti je srozumitelnost.

K hlášení můžeme připojit soubor. Pokud k zopakování chyby nestačí použít výchozí dokument, přikládá se vzorový dokument – ten má obsahovat pouze obsah nutný k vyvolání chyby, žádné zbytečnosti navíc. Rovněž bychom si měli dát pozor na to, abychom v dokumentu nezanechali citlivé údaje. Dalšími přikládanými soubory bývají ilustrace chyb na snímcích obrazovky (zejména u chyb v uživatelském rozhraní, při tom je vhodné mít nastavené anglické rozhraní) či cokoliv dalšího, co přispěje k snazšímu pochopení či reprodukci problému. Přiložit lze pouze jeden soubor, což můžeme obejít vytvořením společného obrázku u snímků obrazovky nebo použitím archivu souborů; alternativně můžeme přidat jednotlivé soubory u dalších komentářů v bugzille.

Návod na vyplnění položek v bugzille LibreOffice je k dispozici také na příslušných wiki stránkách (jak nahlásit chybu, podrobnosti k položkám). Nápovědu obsahuje i přímo systém Bugzilla (zobrazuje se při najetí myší nad název položky), ta však bývá příliš obecná.

Další podrobnosti o chybě

Kromě výše uvedených nezbytností můžeme uvést další podrobnosti. Klepnutím na odkaz „Show Advanced Field“ v horní části stránky zobrazíme doposud skryté položky.

Kompletní formulář pro vyplnění chyby Kompletní formulář pro vyplnění chyby

Závažnost („Severity“) a priorita („Priority“) jsou ožehavými údaji, neboť na jejich základě se chyby dostávají do centra či na periferii pozornosti vývojářů. Při nahlašování chyby se jimi nemusíme zabývat, stačí ponechat výchozí hodnoty „normal“ a „medium“. V případě potřeby je ten, kdo bude chybu ověřovat, posléze upraví.

Jsme-li v hlášení chyb zběhlí, můžeme závažnost a prioritu nastavit sami. K poměrně objektivnímu stanovení jejich hodnot slouží rozhodovací diagram. Při zadávání požadavku na vylepšení programu se jako závažnost nastavuje „enhancement“. Dospějeme-li k závažnější než výchozí hodnotě, sluší se ji zdůvodnit v popisu chyby. To jsme učinili i v našem příkladu: jelikož má špatně přepočítaný sešit za následek chybné hodnoty v buňkách, zvýšili jsme závažnost z „normal“ na „major“.

Inteligentnímu čtenáři je zbytečné zdůrazňovat, že hlášení vyplňujeme pravdivě, objektivně a bez emocí. Dvojnásob to platí při zadávání závažnosti a priority a označování chyby jako regrese. Určitá chyba pro nás sice může být velmi důležitá, ale jejím nepodloženým upřednostňováním docílíme jen toho, že správce chyb a vývojáře naštveme.

klíčových slov („Keywords“) je nejvýznamnějším „regression“, označující regresi programu, kterou je i naše ukázková chyba. Obdobnou položkou, přístupnou až po odeslání chyby, je „Whiteboard“. Další použití těchto položek bude zmíněno v příštím díle seriálu.

Stisknutím „Submit Bug“ se vyplněná chyba zařadí do bugzilly. Ukázková chyba v Calcu obdržela krásné pořadové číslo 80284.

Hlášení o ukázkové chybě před odesláním (ještě v původní bugzille, některé položky se proto od stávajících mírně odlišují) Hlášení o ukázkové chybě před odesláním (ještě v původní bugzille, některé položky se proto od stávajících mírně odlišují)

Sledování chyby

Zadání chyby do bugzilly neznamená, že jsme svou povinnost splnili a problém házíme za hlavu. Naopak se očekává, že jakožto oznamovatelé chyby budeme sledovat a případně reagovat na další vývoj záznamu v bugzille. Přidat ke stávajícímu záznamu komentář či změnit nějakou vlastnost může kdokoliv registrovaný. Stačí upravit potřebné údaje, případně dopsat komentář a použít tlačítko „Save Changes“.

Autorům záznamu se automaticky posílají oznámení o jeho změně na e-mail zadaný při registraci. Místo odeslání e-mailové odpovědi raději odpovídáme novým komentářem na stránce se záznamem chyby, jinak se k chybě vloží celá e-mailová zpráva i s historií.

Chceme-li sledovat pomocí e-mailu jinou než námi nahlášenou chybu, zaškrtneme na její stránce „Add me to CC list“ a změnu uložíme. Sousední položka „Add“ může posloužit k tomu, že na chybu upozorníme jiného registrovaného člena, o němž víme, že se podobnými problémy zabývá. Touto funkcí je záhodno šetřit, zájmem dotyčného si musíme být stoprocentně jisti a navrch je vhodné přidat zdůvodnění či vzkaz do komentáře.

Zásadní informací z hlediska klasifikace chyby je její stav („Status“). Při úvodním vyplňování je nastaven na hodnotu „Unconfirmed“, kterou rozhodně neměníme – značí totiž, že chybu je nutno nejprve nezávisle na zadavateli ověřit. Když se to podaří, dostává se do stavu „New“, jinou možností je „NeedInfo“, požadavek na doplnění dalších informací. Další stavy značí, že chyba se nebude řešit: „Resolved Invalid“ (nejedná se o chybu), „Resolved WorksForMe“ (chybu nelze zopakovat) a několik podobných. S dalšími hodnotami stavu se seznámíme příště.

Vraťme se k příkladu z Calcu a jeho záznamu v bugzille: záhy po nahlášení se objevil komentář, který naši chybu označil jako duplicitní, tj. stav „Resolved Duplicate“. U tohoto stavu je uvedeno i číslo původní chyby, se kterou se označená shoduje. Je pravda, že ani při největší snaze se nemusí podařit odhalit, že stejná chyba už je v bugzille zapsána. Tentokrát je ovšem špatné označení za duplicitu – domněle duplicitní chyba se jinak projevuje a rovněž byla zaznamenána v jiných verzích programu. Stav proto s příslušným odůvodněním vrátíme zpátky.

Další komentář už chybu potvrzuje a mění její stav na „New“. Podobně označených chyb jsou v bugzille řádově tisíce, naděje na opravu této by však měla být vyšší díky tomu, že se jedná o regresi, navíc s vyšší závažností.

Pokračování příště

Důkladně vyplněné hlášení o chybě jsme vložili do bugzilly a chyba byla potvrzena. Příště se dozvíme, čím ještě můžeme napomoci jejímu vyřešení, a dočkáme se šťastného konce celého příběhu.

(Jako ve škole) Průměr: 1,00 | Hodnotilo: 2
 

Přidat názor

 

Nejsou podporovány žádné značky, komentáře jsou jen čistě textové. Více o diskuzích najdete v nápovědě. Diskuzi můžete sledovat pomocí RSS kanálu.

 
Stanislav Horáček

Stanislav Horáček

OpenOffice.org jsem objevil ve verzi 1.1, posléze jsem přešel na LibreOffice. Nejvíc používám Writer, ostatní součásti spíš doplňkově. V posledních letech přispívám ke tvorbě LibreOffice (česká lokalizace, drobné úpravy nápovědy). Od roku 2014 jsem členem The Document Foundation.

 
LinuxEXPRES (news 300px)
 
 
woo jaw demo hz