Nedávno se oficiální účet Fedory na sociálních sítích ptal, proč uživatelé tuto distribuci používají. Asi nejčastější odpovědí bylo, že je to distro s nejlepší podporou GNOME, což mě potěšilo, ale možná ještě více mě u srdce zahřálo, když jsem tam našel hodně odpovědí typu „Nebudete tomu věřit, ale Fedoru používám kvůli stabilitě“. Stabilita Fedory se od doby, kdy jsem ji začal používat, opravdu hodně zvedla a to především v posledních vydáních. Jak se nám to povedlo?

Důvodů, proč je dnes Fedora stabilnější, než kdy dříve, je hned několik. Do značné míry je to dáno tím, že si podstatné změny takzvaně sedly. GNOME 3 zraje jako víno, systemd už má také divoké začátky za sebou a o instalátoru Anaconda ani nemluvím. Dalším důvodem je tým Fedora QA, který má dnes už 10 lidí, kteří Fedoru testují na plný úvazek. To nemá žádná jiná komunitní distribuce. Připočítejte k tomu další testery z řad dobrovolníků a také to, že se rozjíždí automatizované testování. Myslím si, že pomohlo také zaměření, kdy se jsme určili tři hlavní edice – Workstation, Server, Cloud, čímž se určilo to, co musíme mít dobré (tyto tři) a co můžeme mít dobré (všechno ostatní).

Nicméně dnes bych se chtěl věnovat jinému faktoru – ABRT, což je zkratka pro Automatic Bug Reporting Tool. To je nátroj, který pomáhá uživatelům hlásit problémy. Základním problém, který v této oblasti musíte vyřešit, je, aby vám uživatel nahlásil problém v softwaru tak, že jej můžete identifikovat a opravit. Pokud v bugzille najdete hlášení, které říká: „Klikl jsem na čudlík v tabulce a okno zmizelo“, tak vám to při hledání problému moc nepomůže a chyba se s největší pravděpodobností neopraví. Pokud k tomu ale uživatel doplní backtrace a hromadu logů, tak se ta šance výrazně zvyšuje. To byla také první meta ABRTu – posbírat v systému všechny relevantní informace o pádu a umožnit uživateli jej jednoduše nahlásit.

Dopadlo to ale tak, že bugzillu zahltilo obrovské množství hlášení z ABRTu. V možnostech vývojářů prostě nebylo je všechny procházet a analyzovat. Často to tedy dopadalo tak, že vývojáři hlášení z ABRTu rovnou filtrovali pryč. Následovala tedy druhá meta ABRTu – vytvořit na základě hlášení statistiky, které by dokázaly vývojářům říct, které problémy se týkají velkého množství uživatelů (a měly by se tedy opravit) a které problémy jsou okrajové. A pravdě díky tomuto se stal ABRT pro vývojáře Fedory velmi zajímavým nástrojem.

Statistiky pro Fedoru lze najít na Retrace Serveru. Statistiky jsou to opravdu obsáhlé. Nejenže zjistíte, kolik pádů ona chyba způsobila, což je z pohledu prioritizace nejdůležitější informace, ale dozvíte se také, v jaké verzi Fedory, na jaké architektuře, jak se četnost vyvíjela v čase atd. Velmi užitečnou věcí je také to, že ABRT dokáže sdružovat pády na základě podobnosti dohromady, takže je pěkně odhalitelné, že třeba pády v deseti různých komponentách způsobuje chyba v jedné knihovně, kterou tyto komponenty společně používají. Množství hlášení v bugzille se také výrazně snížilo, protože se začaly odhalovat duplikáty a hlášení v bugzille vytvářet pouze, pokud bylo sesbíráno dostatek informací o pádu.

V desktop týmu jsme začali ABRT intenzivně používat před rokem a půl. Vývojářům je kladeno na srdce, aby statistiky pravidelně procházeli a kontrolovali, jestli se náhodou jejich komponenty nenacházejí ve statistikách častých pádů. Pravidelně to procházím i já a pokud narazím na něco, co má na starosti můj tým, daného vývojáře na to upozorním. Nicméně v poslední době je to spíše nuda. Když se podíváte na statistiky ze stabilních verzí, budete tam komponenty z desktopu dlouze hledat. A když na něco narazíte, tak už to je většinou označené jako opravené.

Přitom dřív tomu tak nebylo. Fedora je stále primárně využívaná na desktopu, takže desktopové komponenty jsou dost exponované a dříve se ve statistikách objevovaly vysoko. ABRT nám ale umožnil efektivně prioritizovat a zaměřit se na opravdu exponované chyby. A jde to vidět i v reálném použití. Na pády v GNOME nebo výchozích aplikacích dnes narážím zcela výjimečně.

Po dobrých zkušenostech v GNOME, jsem řekl také klukům, kteří se starají o KDE, aby ABRT více využívali. Když statistiky procházeli, narazili na pády, které měly původně někde na úrovni X nebo ovladačů, takže mimo jejich dosah, ale také tam bylo plno chyb, které byly triviální „onelinery“ a přitom otravovaly život tisícům uživatelů. Statistiky ABRTu dnes používají také někteří naši partneři. Vím, že Intel je používá na sledování problémů v jejich grafickém ovladači (problémů v kernelu je ve statistikách zdaleka nejvíce, ale nejedná se o klasické pády, ale v drtivé většině případů hlášení problémového chování, kterého si uživatel ani nevšimne). ABRT nasadili také v CentOS, jehož statistiky se hodí při hledání chyb, které nás trápí v Red Hat Enterprise Linuxu.

ABRT je také velmi užitečný z pohledu uživatele. Nejenže za vás posbírá všechny relevantní informace o pádu a nabídne vám jejich nahlášení do bugzilly, ale pokud tyto věci nechcete řešit, můžete povolit jen automatické zkrácené hlášení, které bude posílat otisky pádů do statistik, čímž nám minimálně dáte vědět, že se vás daný problém taky týká. Toto zkrácené hlášení lze posílat také na pozadí. To zapínám u těch lidí, které nějaké hlášení problémů nezajímá a ani o pádech nechtějí být informovaní, přesto ale můžou svým dílem přispívat ke kvalitě Fedory. ABRT využívám také u pádů, které se týkají cizího softwaru, který není v repozitářích Fedory. Pokud totiž chci nějaký problém vývojářům takového softwaru nahlásit, ABRT mi nabídne o pádu ucelené informace, z kterých si můžu vyzobnout potřebné informace, a nebo je rovnou všechny jako jeden balík vývojářům poslat.

ABRT opravdu velkou měrou přispěl ke zkvalitnění Fedory, minimálně v oblasti desktopu. A za to abrťákům patří velký dík.