Podle známého programátorského zákona je v každém programu schována alespoň jedna chyba. Některé z nich se projeví okamžitě, další vyjdou na povrch až úplně náhodou při ne zcela typickém použití programu. Pokud objevíme chybu v programu a máme v úmyslu ohlásit ji vývojářům (a to bychom rozhodně měli udělat), musíme mít na paměti, že její popis by měl směřovat k tomu, aby ji vývojáři byli schopni zreprodukovat. Pokud se jim to nepodaří, nebudou ani schopni chybu opravit.
Je to skutečně chyba?
Máloco dovede vývojáře k takovému zoufalství jako zjištění, že problém, který se dlouhé hodiny snažil zreprodukovat, ve skutečnosti existuje jen "mezi židlí a klávesnicí". Proto bychom se měli nejprve ujistit, že chyba, kterou chceme ohlásit, nespočívá jen v tom, že jsme si pořádně nepřečetli dokumentaci. Příkaz man by měl být prvním příkazem, který se linuxový nováček naučí.
U některých problémů samozřejmě není o čem diskutovat. Pokud program spadne hned po spuštění, je určitě nejvyšší čas začít se shánět po bugzille. Naopak, hlášení typu "v xxx není yyy" si dvakrát rozmyslete a než na nich začnete pracovat, rozhlédněte se po internetu, jestli to náhodou není záměr. Tento příklad, stejně jako všechny další, pochází z bugzilly projektu openSUSE, kde ho najdete pod číslem #117825:
There is no rpm package with acroread (Adobe Reader) on Suse Linux 10.0 RC1, at least not in the version available in our university.
V Suse Linuxu 10.0 RC1 není rpm balíček acroread (Adobe Reader), aspoň ne ve verzi dostupné na naší univerzitě.
Pro vývojáře je ztrátou času odpovídat na toto a spousty podobných hlášení, když se na projektové stránce může každý návštěvník dočíst, že tato distribuce neobsahuje komerční balíčky. Podobná hlášení bývají označena jako INVALID - tento konkrétní bugreport je poměrně neškodný, ale mnoho dalších INVALID bugů za sebou skrývá hodiny a hodiny zbytečné práce, která mohla být věnována vývoji nějaké nové zajímavé vlastnosti.
Podobný osud, tedy Resolution: INVALID, potkává i mnohá hlášení, která se týkají vzhledu jednotlivých programů nebo jejich částí. Často se stane, že uživatele příliš netěší náhlá změna vzhledu programu. Pokud je ale tato změna zamýšlená (což poznáte např. podle toho, že je zmíněna v changelogu), těžko přesvědčíte vývojáře ke změně. A dopadnete podobně jako autor hlášení #104560:
fontconfig-2.2.99 from SUSE 9.3 vs fontconfig-2.3.2 from SUSE 10.0 Beta 1. The font remained the same (Tahoma), but it looks different, e.g. the "m" in xterm is has become wider in 10.Beta1.
fontconfig-2.2.99 z SUSE 9.3 proti fontconfig-2.3.2 z SUSE 10.0 Beta 1. Font zůstal stejný (Tahoma), ale vypadá jinak, konkrétně "m" v xtermu je v 10.Beta1 širší.
To bylo nakonec uzavřeno jako INVALID s komentářem:
The current defaults are a compromise which seems to be what most people like.
Současný stav je kompromis, který zhruba odpovídá tomu, co se líbí většině lidí.
Samozřejmě nemám v úmyslu uživatele přesvědčovat, že snaha o změnu vzhledu je předem odsouzena k neúspěchu. Některé věci si autoři GUI sami neuvědomí. A bug #114373, přestože nakonec skončil jako WONTFIX, je tak zcela v pořádku:
When the user chooses GNOME as the graphical interface in the installer, the initial theme is very depressing - everything is gray, no bright colors. In comparison with the colorful, bright KDE theme it makes a big difference. Also it does not much play with the default set of wallpapers, which are mostly very colorful.
Of course, it's a matter of personal taste. However, I looked at the other default themes and found them *all* almost equally gray, blurred, and depressive. This is a problem because more color-loving user simply does not have an easy alternative.
Když si uživatel vybere v instalátoru jako grafické rozhraní GNOME, nastavené téma je velmi skličující - všechno je šedé, žádné ostré barvy. V porovnání s barevným a jasným tématem v KDE je to dost velký rozdíl. A taky to moc nepasuje dohromady se sadou obrázků pozadí, které jsou většinou velmi pestré.
Jasně, je to otázka osobního vkusu. Nicméně - díval jsem se na ostatní témata a musím říct, že jsou *všechna* převážně šedá, rozmazaná a depresivní. To je docela problém, protože uživatel, který má rád barvy, nemá snadnou alternativu.
Kam poslat bugreport?
Jestliže jste dospěli k závěru, že by o vašem problému měli vědět vývojáři, můžete pomalu začít uvažovat o psaní bugreportu. Než se do toho pustíte, měli byste si ale rozmyslet, kde chybu vlastně oznámit. Občas totiž budete mít i více než jednu možnost.
Pokud problém nastal při používání některého balíčku z vaší oblíbené distribuce, máte obvykle dvě možnosti. Buď můžete ohlásit chybu v bugzille své distribuce, nebo přímo v bugzille onoho programu. První řešení je o něco lepší - distribuční balíčky se od původních mohou významně lišit a chyba se mohla objevit až v kódu, který do programu přidal správce balíčku. Pokud se bugreport dostane k němu, bude mít mnohem větší šanci, že chybu zreprodukuje. A když se přece jen ukáže, že za chybu mohou vývojáři programu, tak už si to s nimi správce balíčku nějak vyřídí.
Začínáme psát
Nezní to sice nijak povzbudivě, ale ačkoliv je většina softwaru, který běžně používáme, dostupná i s českou lokalizací, vývojáři se s námi téměř určitě česky bavit nebudou. Takřka všechny bugzilly používají angličtinu, bez které se tedy při psaní bugreportu bohužel neobejdeme. Jsou-li naše znalosti angličtiny mizerné, je nejvyšší čas s tím něco udělat - nejednoznačná, zmatená hlášení jsou vývojářům k ničemu.
Než začneme vytvářet nové hlášení, měli bychom se porozhlédnout, jestli už naše chyba není známá. V bugzille lze efektivně vyhledávat, proto by mělo být povinností vyzkoušet pár klíčových slov vztahujících se k našemu problému. Pokud již záznam obsahující popis stejného problému existuje, můžeme své problémy popsat tam. Jen kvůli tomu nebudeme zakládat zbytečně nový.
Dříve než se pustíme do psaní, měli bychom si rozmyslet, jak moc je náš problém závažný. Bugzilla nám totiž nabízí možnost přiřadit chybě určitou prioritu. Uživatelé bohužel mívají tendenci důležitost svých problémů přeceňovat. Díky tomu se noční můry všech vývojářů občas stanou realitou - mnohému se občas zdá, že zrána našel ve své schránce dvacet Blocker bugů. Většina z nich ale ve skutečnosti vystačí s prioritou Normal, ne-li Minor.
Pokud přiřazujeme chybě prioritu, měli bychom uvažovat o její důležitosti z hlediska ostatních, nikoli z hlediska svého. Priority Blocker a Critical vyhradíme chybám, které způsobují nefunkčnost programu nebo jeho podstatné části. Uvažovat o nich je na místě také tehdy, pokud hrozí ztráta dat, nebo pokud máme podezření na nějaké licenční problémy. V popisu chyby je každopádně vhodné zmínit se o tom, proč považujeme za nutné nastavit chybě vysokou prioritu.
Téměř každá bugzilla nabízí k přečtení nějaké FAQ týkající se správného používání, kde většinou najdeme i přesnější návod, jaká vodítka vývojáři používají k nastavování priorit u tohoto konkrétního projektu. Jestliže si přesto nejsme jistí, určitě není chyba ponechat prioritu na výchozí úrovni Normal, vývojáři už si se správným nastavením poradí.
A jako ilustraci si ukážeme chybu #104116, která nese téměř všechny symptomy špatně napsaného bugreportu. Kromě příšerné angličtiny znemožňující porozumět podstatě problému si povšimněte také nicneříkajícího Summary: ZipDrive a priority, původně nastavené jako Blocker:
I want related that device don't work. And add when a try monted this device, i don't make because the system said that i don't permissiom, same using count of "root". I wanna some help for resolve this case.
Já chci uvádět že zařízení nefungovat. A když přidávat pokus připojit toto zařízení, neudělám to, protože systém říká, že nemám právo, stejně tak při použití účtu "root". Chci nějakou pomoc, abych tento případ vyřešil.
Nadpis
Jednou z důležitých součástí každého bugreportu je nadpis čili Summary. Toto políčko formuláře vyžaduje splnit úkol pro mnohé uživatele dosti náročný: v jediné větě shrnout podstatu celého problému a zahrnout vše, co je důležité. Dobře napsané Summary ovlivní mnohé - umožní jednoduše rozhodnout, kterému vývojáři bug přiřadit. A hlavně, pokud se vývojář přihlásí do bugzilly, kde na něj vybafne záplava chyb, kromě priority rozhoduje zejména Summary o tom, na které bude pracovat dřív než na dalších.
Jak tedy na to? Předně zapomeňte na jednoslovné Summary a nutkání vše podstatné napsat do samotného popisu problému (Description). I kdyby byl popis stručný a stačila na něj jediná věta (nejsem si jistá, jestli takové existují), je pořád lepší zkopírovat jej do Summary, než napsat tam nějaký nesmysl jako "error". Neomezujte se, napište vše potřebné.
Jako příklad toho, jak se to dělat nemá, si vezmeme třeba bug #114154, jehož Summary zní: "blender segfault". Je to lepší než "problem", případně "problem with blender" (ano, i takové věci můžeme vidět v mnoha bugzillách). Zároveň by ale bylo namístě zmínit se ve stručnosti i o tom, za jakých okolností segfault nastává. Tedy v tomto případě něco jako: Running Blender Game from menu causes segfault.
Zpráva - buďte struční a věcní
Při psaní zprávy samotné je samozřejmě každá rada drahá, každý program i problém vyžaduje poskytnutí jiných informací, a tak nezbývá, než spoléhat se na zdravý rozum. Snažte se poskytnout maximum informací popisujících, jak chybu zreprodukovat. Nezapomeňte na verzi (pokud nejde o distribuční balíček, rozhodně vyzkoušejte nejnovější verzi) programu, použitý hardware a prostředí, v kterém program spouštíte.
Samotný text by měl být maximálně stručný, vývojář rozhodně nestojí o to, prokousávat se půlstránkovým elaborátem, aby se dobral k nějaké informaci - koneckonců, ani pro něj pravděpodobně není angličtina mateřským jazykem. Pokud máte chuť si v popisu trochu zavtipkovat, dělejte to s mírou. Některé vtípky vývojáře osvěží, mně se kupříkladu líbil tento (chyba #113922):
XLogical game icon is missing from the KDE menu.
...would be a logical move to add it.
Steps to reproduce: Install the software above from any BETA3 mirror, then look for this software in KDE menu.
V menu KDE chybí ikona hry Xlogical.
...bylo by logické ji tam přidat.
Postup, jak to zopakovat: nainstalujte zmíněný software z jakéhokoliv zrcadla BETA3 a potom ho hledejte v nabídce KDE.
Přestože jde o banalitu (a tomu odpovídá správně nastavená priorita Minor), můžeme tento popis použít jako příklad skutečně pěkného bugreportu.
Přílohy
V bugzille máte možnost slovní popis chyby doprovodit přílohami - logy (pokud problematický program obsahuje nějakou verbose nebo debug volbu, určitě ji zapněte a nezapomeňte debug log přiložit), skripty, nebo dokonce patchem, který chybu opravuje (bugreporty obsahující opravu jsou samozřejmě nejoblíbenější, ale s tím si nelámejte hlavu, dobrý popis bohatě stačí).
Další komunikace
Pokud vyplňujete bugreport, buďte připraveni na další spolupráci. Bez dodatečných informací může být často reprodukce nemožná - proto většina bugtracking systémů vyžaduje registraci, ačkoliv to mnoho uživatelů otravuje. Sledujte další vývoj týkající se vašeho hlášení a spolupracujte - připravte se na to, že vývojáři vás nejspíš nakonec přinutí zaslat i informace, o kterých jste do té doby neměli tušení.
Závěr - je to moc těžké?
Po přečtení tohoto článku můžete mít pocit, že napsat správně bugreport je obtížná práce. Přesto prosím neberte tyto rady na lehkou váhu, zadostiučiněním vám může být pocit, že se podílíte na vývoji svého oblíbeného softwaru. A nezapomeňte: každá minuta ušetřená odfláknutím bugreportu znamená mnohonásobně víc času, který vývojář zbytečně ztratí, až se váš problém bude snažit řešit.