Jak přispívat do LibreOffice X – Vyřešení chyby a správa bugzilly

LO.png V dnešním pokračování seriálu se budeme naposledy zabývat příkladem chyby v Calcu, kterou jsme posledně nahlásili se všemi náležitostmi do bugzilly. Zbývá dopovědět, čím ještě můžeme hlášení doplnit, a dospět k úspěšnému vyřešení problému. Seznámíme se také s činností týmu, který se o chyby v bugzille stará.  

Bibisect a backtrace

Kromě údajů, jež jsme podle svého nejlepšího vědomí minule zadali do bugzilly, můžeme ve specifických případech šance na opravu chyby ještě zvýšit. U regresí, tedy chyb, které se v dřívějších verzích nevyskytovaly (mezi něž spadá náš příklad), lze zjistit, jakými úpravami kódu byla příslušná funkce rozbita, u chyb končících pádem aplikace lze připojit záznam o pádu.

Jeden z předchozích dílů týkajících se nápovědy nastínil, jak je organizován vývoj LibreOffice. Zdrojový kód je uložen v repozitáři systému pro správu verzí a jeho úpravy jsou zaznamenávány jako tzv. commity. Kolik obsahuje repozitář commitů (a je jich v současnosti mnoho desítek tisíc), tolik různých verzí programu můžeme sestavit a spustit. Nabízí se tedy možnost testovat chybu v různých verzích tak dlouho, dokud nezjistíme, který commit způsobil její vznik. A znalost příčiny problému samozřejmě velmi napomůže jeho vyřešení.

Na tomto principu je založena metoda označovaná jako bibisect („binary bisect“). Při ní pracujeme s adresářem, který obsahuje mnoho různých spustitelných verzí LibreOffice – vzhledem k tomu nabývá značné velikosti (v současnosti přes 10 GB pro variantu s největším počtem zahrnutých verzí). Testování spustíme příkazem git bisect start latest oldest.

Postupně se budou automaticky spouštět různá sestavení programu, přičemž – jak název metody napovídá – další testované sestavení bude vybráno v polovině historie verzí mezi posledním známým úspěšným a neúspěšným pokusem. V každé verzi chybu otestujeme; jestliže se projeví, zadáme git bisect bad, v opačném případě git bisect good. Takto dospějeme až k závěrečné dvojici, mezi níž chyba spatřila světlo světa.

Nejde se přitom na úroveň jednotlivých commitů, výsledkem je jejich série, z níž je některý commit za chybu odpovědný. Na závěr si necháme pomocí git bisect log vypsat záznam bibisectu, přidáme jej jako nový komentář do bugzilly a do položky „Whiteboard“ doplníme slovo „bibisected“. Jestliže se vyznáme ve zdrojovém kódu, můžeme ze série commitů přesně identifikovat ten, který chybu způsobil. V tom případě bychom vyplnili do položky „Keywords“ slovo „bisected“.

Podrobně je bibisect rozebrán v návodu na wiki, kde najdeme i odkazy ke stažení repozitáře. Jsou tam také vypsány chyby, u nichž byl vznesen požadavek na bibisect. Pokud nás hra na hledání zlých commitů zaujala, můžeme ji dle libosti opakovat na chybách z tohoto seznamu a pohnout tak s jejich řešením.

Obzvlášť nepřátelskými jsou chyby způsobující pád programu, a vývojáři se je proto snaží rychle a nemilosrdně zneškodnit. Při tom využívají tzv. backtrace, výpis o stavu programu v okamžiku pádu. Získáme jej podle návodu na wiki – vytvoří se, když násilím ukončíme LibreOffice spuštěný s určitým parametrem. Výpis přiložíme k záznamu chyby v bugzille a mezi klíčová slova doplníme „have-backtrace“.

Získávání výpisu z bibisectu a backtrace zvládneme poměrně hladce jen v linuxovém prostředí. V jiných operačních systémech jsou tyto činnosti mnohem komplikovanější a přesahují možnosti začátečníků.

Oprava chyby

Když máme v bugzille nezávisle potvrzený záznam o chybě (v našem případě navíc doplněný bibisectem), nezbývá než čekat, zda se záležitosti chopí některý vývojář. Možností je také – pokud disponujeme příslušnými schopnostmi či finančními možnostmi – pustit se do opravy chyby vlastními nebo najatými silami, o tom ale bude řeč až v dalším pokračování seriálu.

Na místě je značná dávka trpělivosti. Kritické záležitosti bývají opravovány rychle, na méně závažné můžeme čekat měsíce a řešení okrajových chyb či požadavků na nové vlastnosti se může táhnout dlouhá léta.

Jakmile začne nějaký vývojář na opravě chyby pracovat, zapíše se v bugzille do položky „Assigned To“, změní stav na „Assigned“ a případně v komentáři nastíní své plány. Tím zabrání tomu, aby se stejnou chybou zabývalo nezávisle na sobě více vývojářů. Stav „Assigned“ by měl trvat jen po dobu, kdy se vývojář chybě skutečně věnuje; když opravu vzdá, měl by své jméno smazat a vrátit stav na „New“.

Chyba je opravena určitým commitem či sérií commitů. Každý související commit má ve shrnutí uveden kód tdf# následovaný číslem chyby (v dřívější bugzille umístěné na freedesktop.org šlo o kód fdo#). Díky němu jsou do bugzilly automaticky přidány komentáře s odkazem na příslušný commit ve webovém rozhraní repozitáře. (Náš příklad s chybou v Calcu v tomto není dostatečně ilustrativní, v době její opravy bylo propojení s repozitářem rozbité a odkazy byly vloženy ručně.) Ve shrnutích commitů se můžeme setkat i s kódy jiných databází chyb, jakými jsou #i pro bugzillu Apache OpenOffice (v přebraných opravách pro tento balík), rhbz# pro databázi RedHatu, coverity# pro výsledky kontroly kvality kódu Coverity a podobně.

Pokud je patch před commitnutím posuzován pomocí nástroje Gerrit (o němž pojednával díl o posílání patchů do nápovědy), informace o tom se do bugzilly automaticky nevloží a je vhodné tak učinit ručně. Díky tomu se totiž mohou ti, kdo chybu sledují, vyjádřit k návrhu na její opravu.

Je-li patch s opravou připraven, ideálně by se měl dostat nejen do hlavní větve master, ale i do dalších větví pro řady, v nichž se chyba objevuje a které jsou ze strany vývojářů ještě podporovány (jedna nebo dvě poslední řady). Pokud se tak stane, budeme v bugzille opět informováni automatickými komentáři. Někdy však může být jednoduchá oprava ve větvi master ve starší verzi příliš složitá nebo způsobovat nežádoucí vedlejší efekty. Pak se musíme smířit s tím, že ač byla chyba vyřešena, dočkáme se opravy až v další, dosud nevydané řadě programu. Začleňování mimo větev master se navíc týká pouze chyb v pravém slova smyslu, nikoliv nových vlastností.

Informace o tom, v jaké verzi bude chyba opravena, je díky propojení s repozitářem automaticky umísťována do pole „Whiteboard“. Kromě toho vývojář změní spolu s posledním souvisejícím commitem stav chyby na „Resolved Fixed“.

Naše ukázková chyba se zdála být po potvrzení dlouhé měsíce zapomenuta. Po necelém půlroce se jí však ujal Kohei Yoshida, strůjce přepracování Calcu. Chybu rychle opravil (commit byl záležitostí doslova pár správných řádků kódu) a portoval do řady 4.3, takže se spořádaně chovají jak verze řady 4.4, tak řady předchozí od čísla 4.3.4.

Záhlaví záznamu opravené chyby; pole „Whiteboard“ obsahuje čísla verzí, v nichž bude oprava dostupná Záhlaví záznamu opravené chyby; pole „Whiteboard“ obsahuje čísla verzí, v nichž bude oprava dostupná

Doba čekání na tuto opravu může někomu připadat neúnosně dlouhá, jinému jako v rámci možností přijatelná. Měli bychom však mít na paměti, že nebýt nahlášení, mohla chyba znepříjemňovat práci v Calcu ještě mnohem déle.

Testování opravy

Po zveřejnění opravy bychom měli vyzkoušet, zda chyba z programu skutečně zmizela. Nejdůležitější je ověřit opravu ve vývojové větvi master: pro ni jsou pro různé operační systémy dostupná každý den aktualizovaná sestavení programu (daily builds). V adresářové struktuře se nacházejí i sestavení pro jednotlivé řady, vzhledem k častému vydávání opravných verzí je ale možná pohodlnější počkat na předběžné testovací RC verze, zveřejňované na stránkách se stažením LibreOffice.

Pokud je nová verze v pořádku, je slušností funkčnost opravy potvrdit komentářem. Ve vzácných případech, kdy oprava nefunguje, chybu v bugzille s patřičným zdůvodněním znovu otevřeme (stav „Reopened“).

Naše chyba v Calcu pěkně ilustruje to, že oprava je sice fajn, ale samotná nestačí. Neméně důležité je zabránit tomu, aby se chyba o pár vydání později vrátila zpátky – pak by ztratili trpělivost i vysoce flegmatičtí uživatelé. Vývojáři na to myslí, a proto k opravám přidávají automaticky spouštěné testy, které vyhodnocují, zda použití určité funkce vede k požadovaným výsledkům. Byť se jimi nedá pokrýt vše, mohou díky nim klidněji spát jak vývojáři, jejichž commity nemohou jako neřízené střely rozbíjet stávající funkčnost, tak uživatelé, jejichž oblíbené chyby jsou opravovány s definitivní platností. U naší ukázkové chyby byl test přidán a z jeho kódu snadno vyčteme, jaké vstupy a výstupy se v něm používají.

Commit s testem opravy chyby v Calcu v rozhraní Gitk Commit s testem opravy chyby v Calcu v rozhraní Gitk

Správa chyb

Potvrzováním, upřesňováním a klasifikací chyb v bugzille se – kromě dalších činností – zabývá tým QA (quality assurance), jehož úkolem je dbát na to, aby LibreOffice spolehlivě fungoval. Stejně jako jiné týmy má své místo na wiki stránkách, kde nalezneme přehled činností a návody, jak se zapojit. Rovněž používá mailovou konferenci na adrese libreoffice-qa@lists_freedesktop_org (archiv konference).

Zapojit se do správy chyb není žádná věda. Nejjednodušší, a přitom velmi cenné je třídění chyb (bug triaging), jehož předmětem jsou chyby označené jako „Unconfirmed“, tedy ty čerstvě nahlášené a ještě nepotvrzené. U takové chyby je třeba nejprve zkontrolovat, zda už nebyla nahlášena dříve (pokud byla, bude označena jako „Duplicate“). Následně se ji pokusíme reprodukovat a změníme podle výsledku stav (při potvrzení chyby na „New“), případně upřesníme popis a další informace. Mějme přitom na paměti, že mezi oznamovateli jsou i nováčci – a není záměrem, aby nevlídný přístup „třídiče“ k nedostatkům jejich hlášení způsobil, že jejich první hlášení do bugzilly bude zároveň i posledním.

Mohlo by se zdát, že klasifikování chyb je nudnou byrokratickou záležitostí. Jde však o činnost nesmírně důležitou, na jejímž základě se dostává k vývojářům relevantní zpětná vazba a která tvoří nezbytný předpoklad tvorby spolehlivě fungujícího softwaru. Navíc si můžeme testováním chyb z různých zákoutí programu značně rozšířit obzory. Výhodou je také nenáročnost, pro úplné otestování chyby potřebujeme jen chvíli času a několik nainstalovaných verzí LibreOffice.

Za zmínku ještě stojí, že chyby lze v bugzille podmiňovat vyřešením jiných chyb („Depends on“) a sdružovat je do metachyb (metabugs), které se vztahují k určitému tématu. Speciálním případem jsou seznamy nejnepříjemnějších chyb pro jednotlivé řady (Most Annoying Bugs, MAB, například pro řadu 5.0). Další informace o chybě obsahuje pole „Whiteboard“, jde mimo jiné o kategorizaci tzv. EasyHacks, kterými se v seriálu ještě budeme zabývat. Význam těchto charakteristik je i ten, že se na jejich základě automaticky posílají změny u záznamů do určitých mailových konferencí, například vývojářské.

Jakmile jsou k dispozici beta verze nové řady, propaguje tým QA jejich testování a hlášení chyb. V rámci toho dvakrát pořádá několikadenní Bug Hunting Session, během níž se členové týmu maximálně věnují novým hlášením a jsou k dispozici na IRC. Je to tedy ideální příležitost, jak s hlášením začít, na lov chyb se však pochopitelně můžeme vydat i kdykoliv jindy.

Nepostradatelnost automatických testů už zmíněna byla. Poněkud odlišnějším a komplexnějším je ruční testování s využitím webové aplikace MozTrap. Toto testování simuluje běžné používání LibreOffice: uživatel v jeho rozhraní následuje předepsané postupy a případné nesrovnalosti hlásí do bugzilly. Vzhledem k obsáhlosti kancelářského balíku nepřekvapí, že jednoduchých testů je mnoho stovek.

Shrnutí odkazů k hlášení a správě chyb LibreOffice

Shrnutí: jak se zapojit do hlášení a správy chyb

  • Hlásit nalezené chyby do bugzilly (nejprve zkontrolovat, zda již chyba není nahlášena, a otestovat podmínky, za kterých se vyskytuje); poté sledovat další vývoj záznamu o chybě a ověřit opravu chyby.
  • Třídit nepotvrzené chyby v bugzille (otestovat chybu a doplnit informace o ní).
  • Zjišťovat příčinu regresí nástrojem bibisect.
  • Zapojit se do ručního testování pomocí MozTrapu.

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

Seriál se chýlí ke svému závěru, v posledním bloku se seznámíme s fungováním organizace The Document Foundation, přejdeme ke královské disciplíně – úpravě zdrojového kódu jádra a dostane se i na některá zbývající témata.

(Jako ve škole) Průměr: 1.00 | Hodnotilo: 1
 

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ě. Přispívám ke tvorbě LibreOffice (česká lokalizace, drobné úpravy nápovědy), vytvářím rozšíření „České CC0 slovníky“ a jeho stránku ceskeslovniky.cz. Od roku 2014 jsem členem The Document Foundation.

 
 
 
woo jaw demo hz