iCe Online - stránky free World of Warcraft: Cataclysm serveru

Byl spuštěn (a konečně nyní oficiálně otevřen) nový ice bug tracking systém (rozumněj: systém na klasifikaci chyb a jejich systematické odstraňování). Měl by tak nahradit relativně nepřehledné fórum Hlášení chyb (a jeho sub-, subsub-, subsubsub-fóra).

Adresa toho systému je http://server.ice-wow.eu/bugzilla/ , jako neregistrovaní můžete pouze prohlížet bugy (tam nazvané "úkoly") a jejich komentáře.
Pokud chcete přidat (nahlásit) nový bug, musíte se zaregistrovat (uprostřed nahoře - Registrace).

Pozorně si přečtěte informace v tomto threadu - je ve vašem zájmu, abyste bugreport udělali co nejvýstižnější, protože tím podstatně zvýšíte šanci, že se jím GM bude zabývat.


Registrace - postup pro ne-moc-počítačově-gramotné
Vyzve vás to k zadání uživatelského jména (jméno, pod kterým se budete přihlašovat), "skutečného" jména (které bude vidět v seznamu, může být stejné, jako uživatelské, a emailu - ten vyplňte poctivě, protože na něj bude poslán potvrzovací email. Časové pásmo změňte na GMT+1.
Poté mrkněte na mail, měl by tam být jeden nový od admin@ice-wow.eu (kdyžtak mrkněte do spamu), ve kterém najdete jednak link na dokončení registrace, jednak "confirmation code" (potvrzovací kód). Kód označte a zkopírujte přes ctrl-c, poté klikněte na link v emailu, vyplňte požadované heslo (zopakujte ho) a vložte potvrzovací kód přes ctrl-v. Pak už by mělo stačit jen zmáčknout tlačítko pod formuláři.

Nyní se můžete přihlásit nahoře přes uživatelské jméno a heslo ("Zapamatovat" přidá cookie, takže se nebudete muset znova přihlašovat při další návštěvě). Poté už můžete kliknout nahoře na "Přidat úkol" a vyplnit bugreport.


Co by měl dobrý bugreport splňovat:

* výstižný nadpis (souhrn) - vyhněte se věcem jako "pls nefunguje to" nebo "gm mam problem nefunguje mi abilita", tvořte nadpis co nejvýstižněji - pro buglý spell stačí název spellu, pro NPC zase jméno NPC, případně lokalita, apod. Můžete použít i něco jako "Mel Gibson - nejde promluvit" u NPC bugreportu, ale nedělejte souhrn moc dlouhý
* zařaďte bug do správné kategorie
* vyberte správnou závažnost - buďte objektivní !! .. to, že vás štve, že nějaká abilita nepřidává 0.1% spell hit neznamená, že bug má mít nejvyšší závažnost - maximální závažnost by měly mít jen chyby, které (prokázaně) shazují server
* podrobně popište (ale jen k věci) detaily bugu v Detailech, pokud se bug týká něčeho, co jde nalinkovat z wowheadu, udělejte to + připojte popis spellu / itemu z wowheadu (jako tomu je např. u bugu #2, protože najetí myši na link funguje jen zde na fóru
* dále přidejte veškeré prodrobnosti, které jsou k tématu - např. že ten engineering nůž šel použít všemi, ale testovali jste to jen na hunterovi alchemistovi (tedy že to jde vám nemusí znamenat, že to jde všem)
* přidejte i svoje domněnky o tom, co by mohlo být příčinou bugu, věci, které by mohly pomoci při opravě, věci, které jste netestovali, ale které by s tím mohly souviset, ale vždy zůstaňte u tématu - důležitý je bug a jeho popis, ne seriál, který jste sledovali předtím, než jste našli tento bug
* ...
* bugreport je obecně spíš listem faktů, takže není třeba tvořit sálodlouhé slohy o tom, jak jste tadyhle s kamarádem byli rybařit v tundře a potom vás RL invitnul na raid a vy jste sundali prvního, druhého bosse a až na třetím jste si všimli, že tahle abilita nefunguje, jak má --- prostě rovnou napište, o co jde
* Přesto však nebuďte moc struční, pokud to přímo souvisí s bugem, pokud máte další informace, klidně rozepište podrobnosti.



Komentáře pod výpisem detailů
Každý bug má i svoji diskuzi, ve které můžete doplnit další detaily, které autor bugreportu neměl, případně upřesnit / opravit / úplně vyvrátit informace zmíněné v detailech bugreportu. Prostě něco jako tady na fóru. Pokud například najdete patch na mangos fóru, který by mohl pomoci vyřešení bugu, přidejte link na onen topik. Pokud napíšete patch sami, buď využijte pastebinu (např. http://paste2.org/ ), anebo patch přiložte jako přílohu. V žádném případě velké patche neposílejte v těle komentáře.
Prosím, ŽÁDNÝ offtopic v komentářích k bugům!


Jak někoho odkázat na konkrétní bug
Spíše než přes URL je lepší odkazovat se přes tzv. "bug ID" to je unikátní pořadové číslo bugu. Dotyčný pak jen toto číslo zadá v bugtrackeru vpravo nahoru a hned se dostane na detaily. Netřeba tedy udržovat ve "schránce" (ctrl-c) link z prohlížeče. ID bugů se v tom systému vyskytují se znakem "#", tedy když nějakému GM řeknu, že "nejde promluvit s Mel Gibsonem, podrobnosti jsou v bugu #1234", mám vysokou pravděpodobnost, že se tím GM bude zabývat a že neskončím v ignore.


Před přidáním bugu si důkladně ověřte, zda už daná chyba nebyla před vámi hlášena!
Bugtracker podporuje rozsáhlé možnosti filtrace (stačí kliknout nahoře ve výpisu bugů "+ Rozšířené") i klasické hledání, využívejte toho!

Tak jsem přidal zvýrazňování syntaxe a obecně syntaxi DokuWiki, příklady najdete třeba zde -http://flyspray.org/wiki:syntax .

Taky tam přibyl panel jak u Detailů, tak u komentářů, kde je zvláště zajímavá poslední část za oddělovačem:

* předposlední položka přidáva tag , kterým můžete obalit malé kousky C++ kódu z mangosu, třeba pro referenci k danému bugu
* poslední položka přidává tag , do kterého můžete vložit KRÁTKÝ patch, který by mohl pomoci s řešením bugu

časem jim zkusím sehnat lepší ikony, ať se dají lépe vizuálně oddělit. Taky zvýraznění patche nefunguje ideálně, ale to doladím za běhu 

vizte třeba můj testovací bug #29

Stavy bugů:

* Nový - je bug hned po nahlášení a tak zůstane asi po většinu času své existence
* Přiřazen - zatím slouží k účelu popsanému v 1. postu, možná bychom to mohli vylepšit tak, že věci jako questy/NPC se budou automaticky přiřazovat LK, ale zbytek je víceméně obecný. Původní využití té vlastnosti je pro projekty, kde je jeden hlavní správce a ten přiděluje bugy vývojářům subsystémů. Vývojář si pak jen najde bugy přiřazené k sobě a vyřeší je. To tady na icu moc asi fungovat nebude, protože víc lidí tu nezávisle na sobě řeší víc věcí, proto by možná bylo lepší zůstat u současného stavu -- přiřadit jen k sobě, pokud bug plánujete vyřešit osobně.
* Má patch - není pro fixy v mangosu, ale čistě pro to, aby Puny, LK nebo kdokoli bez znalostí aplikace patche (a možnosti ho otestovat) mohl těm ostatním naznačit, že daný bug má řešení přes externí patch, referencovaný v diskuzi toho bugu - po aplikace patche a vyzkoušení funkčnosti je bug uzavřen
* Potřebuje otestovat - rozšiřuje předchozí stav, možná to smažu. Měl sloužit pro stav po aplikaci patche, kdy je potřeba, aby hráči potvrdili funkčnost (např. u rozsáhlejší chyby, kterou je těžké reprodukovat).


Stavy pro uzavření:

* Opraveno - bug byl vyřešen / opraven / kladně vyřízen.
* Není bug - je to featura / vlastnost. Věci jako nadměrný dmg v naxxu / non-blizzlike ability v naxxu a podobně.
* Duplikát - bug je duplikátem jiného, v tom případě uveďte v důvodu link na bug, jehož je tento duplicitou (stačí napsat FS#1234 pro bug 1234, bugzilla z toho udělá link automaticky)
* Mě to funguje - (překlad WORKSFORME) typický příklad bug ##32, prostě věc, která už funguje a fungovala před nahlášením, nedávejte "Opraveno" ani "Není bug", sem spadají i věci jako "Funguje, vysvětlení na fóru"
* Nebude opraveno - doslovný překlad od WONTFIX, tzn. bug, který z nějakého důvodu nesplňuje vlastnosti tak, aby mohl být opraven - je to trochu na hranici s "Není bug", párkrát jsem to už použil pro věci, které byly součástí nějakého globálnějšího problému - např. bug ##38 (vizte podrobnosti uzavření toho bugu). Taky se používá pro bugy, které svým způsobem vyhovují v současném stavu, v rámci kompatibility (chtěl jsem uvést aukcionáře, ale to je featura ("Není bug"), prostě věci, které se ani GM, ani hráčům nehodí, ale z nějakého důvodu tak musí být, aby se zabránilo zmatení hráčů, kteří "tam dřív to NPC měli a teď tam není", protože podle wowheadu má být jinde). Pokud si nejste jisti, raději nepoužívejte.
* Fix v mangosu - např. bug ##40, tzn. bug, který byl opraven v upstreamu (mangos/master) a který bude fixnut s dalším mangos updatem. Do popisku dávám osobně commit hash daného commitu. Je pravda, že máme větev pro "backport" fixů z mangosu na naši revizi, ale ta je spíš pro crashfixy / kritické bugy.



Ostatní:

* Pokud uzavřete bug, pište důvod (pokud je krátký) do Důvodu k uzavření, ne do diskuze. Je zbytečné přidávat další komentář s obsahem "opraveno", je zbytečné to dokonce psát i do Důvodu k uzavření, protože to je zjevné ze Stavu. Tzn. pište jen doplňující informace, ne zbytečnosti.
* Při hlášení bugu si zapamatujte "pořadové číslo" a pomocí toho si bug kontrolujte. Tzn. používejte formulář vpravo nahoře na bugtrackeru, protože jakmile je jednou bug uzavřen, nezobrazí se v úvodním seznamu bugů a dostanete se na něj buď přes Mé hledání -> Mnou hlášené (vlevo nahoře), přes Rozšířené hledání, nebo právě a nejjednoduššeji přes bug ID - formulář napravo nahoře.
* Pokud si myslíte, že bug byl uzavřen neprávem a (ani po restartu) vlasntost nefunguje, pošlete požadavek na znovuotevření, nezakládejte nový bug. Chtěl jsem udělat znovuotevření bez nutnosti potvrzení správcem projektu, ale nějak to (stejně jako editace vlastního bugreportu) záhadně nefunguje.

Další informace je možné nalézt na foru v sekci Dúležité informace.