Linux E X P R E S

V minulém článku, kde jsem popisoval dosavadní zkušenosti s Fedorou 19, jsem si dal závazek, že v následujících týdnech pomůžu ve volném čase s testováním. Bylo to hlavně kvůli tomu, že velká část brněnské části Fedora QA měla dovolenou kvůli zkouškovému či státnicím. A zrovna posledních několik týdnů před vydáním je z pohledu testování velmi důležitých.

Na dva týdny jsem se tedy připojil k Fedora QA a na vlastní kůži si zkusil, jak takové organizované testování Fedory funguje. Je rozděleno do tří hlavních milníků: alpha, beta a final. Při testování každého milníku vycházejí tzv. test composy, což jsou aktuální sestavení vývojové verze Fedory. Tyto composy se musí opakovaně testovat, jestli v nich nedošlo k regresím nebo jestli byly opraveny chyby, které byly nalezely dříve. Organizaci testování composů usnadňují tzv. testovací matice, které obsahují test casy, což jsou postupy, jak otestovat určitou funkcionalitu za určitých okolností. Můžete se podívat např. na testovací matice instalátoru, abyste měli představu, jak to vypadá. Funguje to tak, že s daným composem projdete daný test case a pokud se vašem výsledky shodují s předpokládanými, dáte danému test casu zelenou fajfku. Pokud narazíte na nějaký problém, označíte jej neúspěšných výsledkem a problém nahlásíte v bugzille.

Já jsem se vrhnul do testování instalátoru opravdu energicky a nejdříve zkoušel různé hodně divoké kombinace jako např. instalaci na BTRFS s x různými oddíly a šifrováním. Ukázalo se, že to byly hodně divoké kombinace, protože instalátor je v mnoha případech nedal. Proto jsem se nadále držel testovacích matic a testoval jen scénáře, které jsou mnohem blíže skutečnému použití. Poté už jsem v instalátoru nenarazil na žádnou vyloženou chybu, ale přece jen jsem jednu chybu nahlásil. Instalátor se totiž hodně divně choval, když jste při instalaci zachovali /home a nově vytvořený uživatel už měl vytvořený adresář. V tomto případě uživatele sice vytvořil, ale účet zamknul. Po nahlášení se to opravilo do stavu, kdy instalátor uživatele vytvoří, spáruje ho to s adresářem a ještě případně změní UID souborů v adresáři, pokud se neshoduje - výrazně uživatelsky přívětivější řešení.

Další zajímavou maticí je desktopová, kde se testuje základní funkcionalita prostředí a výchozích aplikací. Tady se primárně testují GNOME a KDE, což jsou oficiální desktopy, jejichž chyby mohou zablokovat vydání. Testovat lze ale i ostatní prostředí: Xfce, LXDE, MATE, Cinnamon,... jen chyby proti nim nahlášené nemůžou zdržet vydání. Tzv. blocker bugy, neboli chyby blokující vydání, jsou zajímavostí testování Fedory. Ta totiž na rozdíl např. od Ubuntu, které vyjde v určité datum stůj co stůj, může nabrat zpoždění kvůli blocker bugům. Ty mají svá kritéria, které musí splnit, aby mohly být označeny za blockery. Každé vydání (alpha, beta, final) má svá kritéria, postupně přísnější. Pokud si myslíte, že nějaká chyba splňuje kritéria, můžete ji speciálním tagem v bugzille nominovat. Každý týden se potom koná blocker bug meeting, kde tým Fedora QA hlasuje, které problémy kritéria opravdu splňují. Pokud je schválen jako blocker, Fedora nevyjde dřív, než je opravený, což je určitě dobrá motivace a tlak na vývojáře.

Mně se podařilo v desktopové testovací matici narazit na jeden blocker bug, kdy GNOME Shell nedokázal zobrazit všechny ikony v nabídce aplikací. Ten byl vývojáři GNOME posléze rychle opravený. V KDE jsem narazil na problém, že po aktualizaci systemd nestartoval polkit-kde-auth, což vyřadilo z provozu všechny aplikace, které žádaly PolKitu o práva roota. I když se mi chybu podařilo několikrát spolehlivě reprodukovat, nikomu jinému ne a při dalším test composu už jsem měl problémy ji spolehlivě reprodukovat i já, takže skončila v kategorii zvláštních, nereprodukovatelných chyb.

Jak jsem říkal, i aktualizace ve vývojové verzi mohou přinést regrese. Docela dost jich přišlo s aktualizací GNOME 3.8.3. Např. knihovna gogl byla sestavena s aktivovanou podporou Waylandu, což vyřadilo GNOME na proprietárních ovladačích od nVidie, které Wayland ještě nepodporují. Díky testerům to bylo brzo odhaleno a opraveno. Já jsem potom narazil na problém, kdy po připojení GNOME Documents ke Google Docs aplikace padala. Po debugování společně s vývojářem aplikace jsme přišli na to, že GD si stahují ze serveru i náhledy dokumentů a nebyla ošetřena situace, kdy dokument z nějakého důvodu náhled na serveru nemá. I tato chyba byla velmi rychle opravena. Pořád mi sice přijde, že indexování souborů nefunguje zcela v pořádku, protože se na některých souborech zasekne až neuměrně dlouho, ale už to neshazuje celou aplikaci a týká se to jen některých souborů, takže to nebylo uznáno jako blocker bug.

Zajímavým nástrojem, který pomáhá při testování Fedory, je ABRT, což je asi nejpropracovanější nástroj na hlášení chyb, jaký jsem kdy viděl. Nejenže už dokáže velmi dobře detekovat duplicitní chyby a nezaplavovat tak bugzillu, ale má i vlastní databázi problémů vně bugzilly, kde si může člověk prohlédnout statistiky chyb, vylistovat si nejčastější problémy podle balíčků či správců, což může sloužit jako vodítko pro vývojáře, na jaké chyby se zaměřit.

Testování Fedory 19 se dostává do finální rovinky. Pokud se neobjeví žádné zásadní problémy, měla by za 14 dní vyjít ostrá verze. Jsem rád, že jsem měl tu příležitost nahlédnout v posledních 14 dnech trochu víc pod pokličku testování Fedory a taky pomoct k tomu, aby byla Fedora 19 kvalitnějším vydáním. A třeba se dostanu i mezi Heroes of Fedora Testing :-)