Wikimedia přešla z Bugzilly na Phabricator

V listopadu přešla Wikimedia z Bugzilly na Phabricator. K migraci se v příspěvku na svém blogu vrací André Klapper. Bugzilla byla používána 10 let. Vloženo bylo 73681 oznámení. Registrováno bylo přibližně 20000 uživatelských účtů. Porovnání Bugzilly s Phabricatorem na stránkách MediaWiki.

19.12.2014 02:09 | Ladislav Hagara | Komunita

Komentáře

[Jirka]

Nechápu, proč všichni přechází na Phabricator, když je tu IMHO mnohem lepší GitLab: https://about.gitlab.com/

[Bystroushaak]

Cokoliv bude lepší než Buhzilla.

[pavlix]

Bugzilla má svoje vady, ale už je relativně usazená. Spíš bych řekl, že skoro cokoliv bude horší.

[Bystroushaak]

Bugzilla mi přijde jako nejmíň ergonomický software pro hlášení chyb, co jsem kdy v životě používal. Lepší by podle mě bylo to i posílat emailem.

[----]

já s bugzillou problémy nemám, hlášení chyb mi přijde triviální.

[pavlix]

Tak to přeju dobrou chuť. Jeden z důvodů, proč za život nahlásil jen minimum problémů v Debianu je ten, že nemají ani tu pitomou bugzillu a bugy se řeší příšerným způsobem. Bugzillu považuju za triviálně zvládnutelný software a relativně pohodlný.

[Bystroushaak]

Imho je to případ slepoty programátorů. Osobně neznám moc jiných kusů software, kterých bych používal míň rád. Jediné co to překonává je snad jen outlook a windows. Když to porovnám s použitím třeba github issues, tak je to pro mě, jakožto uživatele co chce nahlásít bug, úplně o řády jinde.

[pavlix]

Imho je to případ slepoty programátorů.

Samozřejmě máš právo na své názory a teorie, nicméně bez konkrétního zdůvodnění nejsou moc zajímavé. Osobně jako nejsložitější pro uživatele vnímám na bugzille dvě věci.

1) Vymyslet si heslo a pamatovat si ho.

2) Vyplnit to textové pole, kde se popisuje problém.

[Bystroushaak]

1) Vymyslet si heslo a pamatovat si ho.

Chceš říct registrovat se, ověřovat si účet emailem a kdesi cosi, abych se vůbec dostal k nahlášení chyby.

2) Vyplnit to textové pole, kde se popisuje problém.

Jedno? :)

[Michal Kubeček]

Není jen jedno, ale paradoxně právě to hlavní, kam se popisuje problém, je nejtěžší vyplnit tak, aby byl bugreport použitelný a užitečný. Divil byste se, kolik lidí má problém pochopit, že bugreport "Padá mi KDE. Každou chvíli. Dělejte s tím něco." je úplně k ničemu.

[Bystroushaak]

Divil byste se, kolik lidí má problém pochopit, že bugreport "Padá mi KDE. Každou chvíli. Dělejte s tím něco." je úplně k ničemu.

Ne, nedivil. Po 2 letech řešení zákaznických problémů v o2 jsem zažil asi úplně všechny způsoby, jak někdo může (ne)popsat problém. To je ovšem obecný problém s uživateli hlásícími problémy. Systém by se jim to imho měl snažit co nejvíc usnadnit. Nechci tvrdit, že bugzilla v tomhle ohledu úplně selhává, ale rozhodně je to nejhorší software na hlášení chyb, co jsem kdy byl nucen použít.

[Michal Kubeček]

Tak to máte velké štěstí. :-)

[pavlix]

+1

[little.owl]

ale rozhodně je to nejhorší software na hlášení chyb, co jsem kdy byl nucen použít.

A jake jine jste tedy pouzival? Co byl ten lepsi software? Proc konkretne je bugzilla az tak spatna?

[FrostyX]

Co byl ten lepsi software?

O pár příspěvků výše zmínil GitHub issues.

[Bystroushaak]

A jake jine jste tedy pouzival? Co byl ten lepsi software?

Github issues, jiru a i zde zmíněný gitlab.

Proc konkretne je bugzilla az tak spatna?

To jsem už taky psal - protože nemá žádnou ergonomii. Prostě celý vzhled je matoucí a složitý a počet kroků, které musím udělat než můžu konečně kliknout na SEND je ve srovnání s ostatními příliš velký. K tomu se váže ta programátorská slepota - když s tím budu jako programátor pracovat den za dnem, tak mi to za měsíc taky přijde OK.

Většinou tam není ani přihlašování přes openid, takže nemůžu použít existující účet a musím se ještě navíc registrovat. Jako filtr, který má odradit lidi co nemají hodinu času, aby mohli nahlásit nějakou chybku která je moc nepálí je to dobré, ale jinak hrůza.

[Michal Kubeček]

Github issues, jiru a i zde zmíněný gitlab.

Ze jmenovaných znám jen JIRu a tam je můj názor přesně opačný. Sice tam - aspoň v té instanci, kterou znám - není potřeba vyplňovat tolik políček, ale pak člověk při práci s bugem rychle zjistí, že to není výhoda, protože mu ty funkce chybějí.

Jako filtr, který má odradit lidi co nemají hodinu času, aby mohli nahlásit nějakou chybku která je moc nepálí je to dobré

Vycházíte z toho, že je žádoucí podporovat uživatele v tom, aby co nejrychleji s minimem vlastního úsilí nahlásili chybu (dokonce takovou, "která je moc nepálí") a tím to pro ně skončilo. Jako člověk, který se většinu času pohybuje na opačné straně bugzilly, musím s takovým názorem zcela zásadně nesouhlasit.

[Martin Böhm]

Jako člověk, který se většinu času pohybuje na opačné straně bugzilly, musím s takovým názorem zcela zásadně nesouhlasit.

Rad bych vyuzil teto vety a poukazal na to, ze casto my jako lide zapomeneme na to, co je cilem nasi prace.

Nejtypictejsi priklad je kazdym zazity "neprijemny urednik" -- on je na Vas neprijemny, protoze jste nevyplnil formular v predstihu (a tim mu ztizil praci) ... jenze Vy jste prisel na urad a ani nevedel, ze formular je treba vyplnit, potreboval jste nekoho, kdo Vam pomuze vyresit nejakou byrokracii.

Je videt, proc jste z pohledu urednika clovek, co neprisel poradne pripraveny a tim zpomaluje proces? A je videt, proc takovehle uvazovani urednika zkazi den jemu a jeho chovanim pak i Vam?

---

Disclaimer: Nerikam, ze svou praci delate spatne nebo ze jste neprijemny -- co rikam je, ze lide znali aparatu obcas zapomenou na svou ulohu pomahat, a tak je treba to mit vzdycky nekde vzadu v hlave, abychom se nestali neprijemnymi uredniky. Ja jsem ted na doktoratu a ucitele maji stejnou naturu -- obcas se vic na studenty mraci za jejich neznalost, nez aby jim pomahali s latkou.

[Michal Kubeček]

Člověk, který jen tak, jda kolem, nahlásí chybu, nezajímá se o to, jaké by měl mít report náležitosti, a zase jsem pryč, takže se ho na chybějící informace nelze zeptat, nelze s ním dál spolupracovat a nejde mu ani dát opravenou verzi k otestování, by mohl být přínosem leda u projektu, kde se vývojáři koušou nudou, nemají do čeho píchnout a zoufale čekají na nějaký bugreport, kterému by se mohli věnovat. Kolik takových projektů znáte?

Jistě, teoreticky je samozřejmě možné, že i takový náhodný kolemjdoucí vyrobí perfektní bugreport, ke kterému žádná další komunikace není potřeba. Ale předpokládám, že máte nějaké praktické zkušenosti, takže asi nemusím vysvětlovat, jak pravděpodobné to je.

[pavlix]

Člověk, který jen tak, jda kolem, nahlásí chybu, nezajímá se o to, jaké by měl mít report náležitosti, a zase jsem pryč, takže se ho na chybějící informace nelze zeptat, nelze s ním dál spolupracovat a nejde mu ani dát opravenou verzi k otestování, by mohl být přínosem leda u projektu, kde se vývojáři koušou nudou, nemají do čeho píchnout a zoufale čekají na nějaký bugreport, kterému by se mohli věnovat. Kolik takových projektů znáte?

+1

Nevím jak Martin, ale mám podezření, že Bystroušák zcela ignoruje to, že bug reporting je o oboustranné komunikaci mezi nálezcem chyby a vývojářem, který se chce o chybu postarat.

[Bystroushaak]

Nevím jak Martin, ale mám podezření, že Bystroušák zcela ignoruje to, že bug reporting je o oboustranné komunikaci mezi nálezcem chyby a vývojářem, který se chce o chybu postarat.

Tož můžeš si vybrat, jestli je pro tebe lepší o chybě nevědět vůbec nic, ani to že existuje, nebo vědět že existuje a nevědět podrobnosti.

Jinak já neříkám, že to má být pro anonymní účastníky, tak nějak nechápu, co by ti mělo v oboustranné komunikaci bránit.

[Michal Kubeček]

Tož můžeš si vybrat, jestli je pro tebe lepší o chybě nevědět vůbec nic, ani to že existuje, nebo vědět že existuje a nevědět podrobnosti.

V ideálním případě, kdy je vývojář schopen na základě toho kusého popisu problém zreprodukovat, to přínos být může. Podle mých zkušeností to tak ale většinou není. Chyby se často projevují jen za specifických okolností, čehož si autor reportu nemusí být vědom. Mně už se třeba také několikrát stalo, že se chyba projevovala spolehlivě na všech mých systémech, ale nikdo jiný ji nebyl schopen reprodukovat, protože byla závislá na specifických podmínkách, které na všech mnou spravovaných systémech jsou, ale jinak jsou jen řídkou výjimkou.

A v těch zbývajících případech takový report jen spotřebuje nějaké ty člověkohodiny, ale nic pozitivního nepřinese.

Jinak já neříkám, že to má být pro anonymní účastníky, tak nějak nechápu, co by ti mělo v oboustranné komunikaci bránit.

Teoreticky nic. V praxi registraci odmítají až na řídké výjimky právě ti, kdo nemají v úmyslu se bugu dále věnovat.

Ono je to celé právě o té představě, že (jakkoli) nahlášená chyba je automaticky přínosem. Jenže to není zdaleka vždy pravda. Trochu bych to přirovnal k postoji některých firem, které se strašně diví, že když pošlou nějaký driver, vývojáři jádra jim nejen nelíbají ruce, ale ještě se rozmýšlejí, jestli ho vůbec začlenit, a kladou podivné otázky jako třeba kdo bude maintainer. Podstatu problému IMHO pěkně vystihuje termín "hodit přes plot", který se pro tento přístup používá.

[Bystroushaak]

Teoreticky nic. V praxi registraci odmítají až na řídké výjimky právě ti, kdo nemají v úmyslu se bugu dále věnovat.

To jsou opravdu divné důvody, proč nepoužívat openid.

Ono je to celé právě o té představě, že (jakkoli) nahlášená chyba je automaticky přínosem. Jenže to není zdaleka vždy pravda.

Jen by mě zajímalo, proč potom nějaký bugreporting chceš provozovat, když není v tvém zájmu, aby ti tam lidi něco hlásili. Z diskuze tak nějak získávám pocit, že ideální bugreport systém by vypadal tak, že se probojuješ trnitým bludištěm, zabiješ draka a pak za odměnu dostaneš místo princezny možnost nahlásit chybu. Jenže až po tom, co odevzdáš vzorky krve, semene a slin a potvrdíš registrační pergamen.

Když ti chyby nepřijdou přínosem, tak je prostě zavři, nebo ignoruj.

[Michal Kubeček]

To jsou opravdu divné důvody, proč nepoužívat openid.

Znamená "openid" automaticky např. funkční e-mailovou adresu?

Jen by mě zajímalo, proč potom nějaký bugreporting chceš provozovat, když není v tvém zájmu, aby ti tam lidi něco hlásili.

Zajímavá "logická" úvaha. Já napíšu, že ne každý bugreport je automaticky přínosem, a vy si to interpretujete jako tvrzení, že žádný bugreport není přínosem… Zkuste pro změnu polemizovat s tím, co jsem opravdu napsal.

[pavlix]

Fedora například OpenID pro single sign on používá, ale asi ne způsobem, který by se líbil Bystroušákovi a hlavně chybí integrace právě konkrétně bugzilly. Souhlasím s tím, že by všechny systémy spojené s distribucí nebo větším upstreamovým projektem měly používat single sign on, že to může být OpenID, ale nijak netrvám na tom, aby to OpenID bylo otevřené i dalším providerům a pokud ano, tak určitě netrvám na tom, aby to fungovalo bez registrace, popřípadě bez ověření e-mailu. Pokud se chce člověk projektu trochu věnovat (i kdyby jen občasným hlášením bugů, sledováním jejich průběhu a doplňováním informací dle potřeby), tak potřebu registrace nevidím jako překážku.

[Bystroushaak]

Znamená "openid" automaticky např. funkční e-mailovou adresu?

Nejsem si vědom toho, že ne. Neověřoval jsem to, ale mám za to, že openid je vždy provázané s adresou. Pokud ho použiješ, tak se tě ten provider openid většinou ptá, co chceš té stránce poskytnout (email, jméno a tak).

Zajímavá "logická" úvaha. Já napíšu, že ne každý bugreport je automaticky přínosem, a vy si to interpretujete jako tvrzení, že žádný bugreport není přínosem… Zkuste pro změnu polemizovat s tím, co jsem opravdu napsal.

Důraz na něco a poslední větu.

[pavlix]

Nejsem si vědom toho, že ne.

E-mailová adresa je volitelná součást informací a teď si ani nejsem jistý, zda standard umožňuje nějak označit adresy, které jsou ověřené alespoň OpenID providerem, i když ten samozřejmě není spolehlivý a nemusí být od věci adresu stejně samostatně ověřit.

Neověřoval jsem to, ale mám za to, že openid je vždy provázané s adresou.

OpenID identifikuje pomocí URL, nikoli e-mailové adresy a nemusí být na něj navázaný žádný e-mail.

Pokud ho použiješ, tak se tě ten provider openid většinou ptá, co chceš té stránce poskytnout (email, jméno a tak).

To platí.

[Fluttershy, yay!]

Bug reporting ve spoustě případů opravdu žádnou komunikaci nevyžaduje, jenže protože to nástroje pro hlášení znepříjemňují, málokdo se s těmi reporty namáhá. Přitom jsou to problémy pro uživatele patrné na první pohled a docela otravné — denně čumím na prohozená tlačítka ve formulářích, popisky vyhlížející jako od Frice, dialogy vytékající z obrazovky apod.

[j]

A pak chodite po netu a placete v diskusi, ze ten bug nikdo nenahlasi. Neni se co divit. Nejde totiz ani zdaleka jen o registraci, to je spis posledni kapka. Staci kdyz clovek zjisti, ze tam visej triviality dlouhy roky. A jeste to po nem chce registraci, a jako bonus ho vyvojar posle dohaje, protoze k tomu nepriflak rovnou patch, a kdyz priflakne, tak ho posle dohaje proto, ze tam ma misto tabu mezery nebo naopak.

[pavlix]

Nahlášení chyby je to nejmenší, co člověk může udělat. Pokud neudělá ani to, a chodí pak brečet po diskuzích jen na základě toho, že existují vyhnívající bugy, nevidím důvod s ním mít jakýkoli soucit. A pokud chceš Michalovi nadávat za triviální bugy, které visí roky v bugzille, tak bych doporučil neprve takové triviální bugy, za který je Michal Kubeček alespoň nějakým způsobem zodpovědný. To můžu jít rovnou řvát na prvního zedníka, co potkám, že bydlím v domě, kde jsou špatně udělané zdi.

[pavlix]

když s tím budu jako programátor pracovat den za dnem, tak mi to za měsíc taky přijde OK.

Tuhle vlastnost bohužel nemám.

Jako filtr, který má odradit lidi co nemají hodinu času, aby mohli nahlásit nějakou chybku která je moc nepálí je to dobré, ale jinak hrůza.

V tom případě to funguje správně. O reporty od uživatelů, kteří vyplodí nějaký velmi špatný popis problému, utrousí dvacet poznámek o tom, proč jsou vývojáři debilní a co by měli dělat, a ani se už nikdy nevrátí, aby odpověděl na doplňující dotazy, opravdu nikdo nemá zájem. A v upstreamu zvlášť.

Pokud má člověk málo času, tak je dobré si udělat registraci alespoň v bug trackeru distribuce, kterou používá. To je jedna registrace na celou open source distribuci, kterou dotyčný dostal zcela zdarma! Ten jeden formulář jednoho bug trackeru se nějak naučí používat, ať už je to formulář bugzilly nebo něčeho jiného. A hlavně ať použije aktivní e-mailovou adresu, na kterou mu budou chodit doplňující dotazy s odkazem na další formulář, kde na ně může odpovědět.

[Bystroushaak]

V tom případě to funguje správně. O reporty od uživatelů, kteří vyplodí nějaký velmi špatný popis problému, utrousí dvacet poznámek o tom, proč jsou vývojáři debilní a co by měli dělat, a ani se už nikdy nevrátí, aby odpověděl na doplňující dotazy, opravdu nikdo nemá zájem. A v upstreamu zvlášť.

Cítím z toho implikaci, jako že čím horší systém nahlášení pro uživatele, tím kvalitnější bude popis. To imho neplatí.

Pokud má člověk málo času, tak je dobré si udělat registraci alespoň v bug trackeru distribuce, kterou používá. To je jedna registrace na celou open source distribuci, kterou dotyčný dostal zcela zdarma! Ten jeden formulář jednoho bug trackeru se nějak naučí používat, ať už je to formulář bugzilly nebo něčeho jiného. A hlavně ať použije aktivní e-mailovou adresu, na kterou mu budou chodit doplňující dotazy s odkazem na další formulář, kde na ně může odpovědět.

Tak jo, dají se vymýšlet všelijaké blbosti, nebo prostě použít openid na facebook, github a google a člověk pokreje 90% populace (s ověřeným emailem!) bez nutnosti zakládat další zbytečný účet, který mít nechci.

[radix]

Cítím z toho implikaci, jako že čím horší systém nahlášení pro uživatele, tím kvalitnější bude popis. To imho neplatí.

Presne tak - ja, kdyz uz teda reportuju nejakou chybu, tak si na popisu dam zalezet a klidne pak s nekym dal komunikuju a doplnuju informace. Ale ruzne registrace, aktivace uctu, kontroly existence mailu jsou filtry me vetsinou odradi. Funguje to jako filtr, ale ne kvality popisu.

Ted sem hlasil chybu ke ctecce Mantano - autor (resp. firma) ma proste na strankach formular - email, subject, description; to vyplnim a odeslu. Po nejake dobe mne autor odpovedel mailem, a tak jsme komunikovali mailem. Jednoduche jak facka.

[pavlix]

Po nejake dobe mne autor odpovedel mailem, a tak jsme komunikovali mailem. Jednoduche jak facka.

Existují i open source projekty, které nejsou one man show. Pokud očekáváš, že se o tebe u všech open source projektů bude vždy starat jeden vývojář a aktivně si s tebou povídat po e-mailu, tak asi nemáme o čem debatovat.

[radix]

Byl to priklad jednoducheho a uzivatelsky privetiveho reportovani chyb. Tohle nema nic spolecneho s tim, jestli je to one-man-show nebo ne - integrace mailove schranky s bugtrackovacim systemem neni zrovna zhava novinka.

[pavlix]

Obávám se, že se naprosto míjíme, ale nejsem si jistý, jestli tím hodlám ztrácet více času. Stejně jako při komunikaci s uživateli, se i v diskuzi občas stane, že člově pro vynaložené úsilí přestává cítit motivaci.

[Bystroushaak]

Stejně jako při komunikaci s uživateli, se i v diskuzi občas stane, že člově pro vynaložené úsilí přestává cítit motivaci.

Člověk člověku bugzillou ;)

[pavlix]

Chceš říct...

Chci říct to, co říkám.

Jedno?

Ano, jedno pole určené k popisu problému tedy to největší pole ve formuláři.

[Bystroushaak]

Ano, jedno pole určené k popisu problému tedy to největší pole ve formuláři.

To jako že to půjde odeslat, když nevyplním nic dalšího?

[Michal Kubeček]

Ne. Ale že dobře vyplnit tohle pole je ta opravdu náročná část, přestože se některé příspěvky snaží tvrdit opak.

[Josef Kufner]

Tak proč plýtvat energií na blbosti okolo?

[pavlix]

Nevím jak jinde, ale na sourceware.org vidím okolo už jen (jednořádkové) shrnutí, které člověk vidí v seznamu bugů a to bych tak úplně nevyhazoval.

[Michal Kubeček]

3) Pochopit, že nahlášením chyby to pro něj (většinou) nekončí.

[pavlix]

+1

[FrostyX]

Souhlasím s Bystroushaakem, tak zkusím odpovědět.

První věc kterou vidím, když si zobrazím existující bug, je 31 inputů, které mě absolutně nezajímají. Víc než 3/4 není vyplněná (proč se teda vůbec vypisuje?), zhruba o polovině vůbec nevím co znamená. Nemám tušení, jestli je jako běžný uživatel (případně vlastník bugu) vůbec můžu vyplňovat.

Abych se podíval na popis bugu, který je mimochodem vložený jako komentář, musím sescrollovat o jednu výšku stránky dolů. Komentáře nepodporují formátování, což je v případě bug trackeru, kde se do spousty příspěvků vkládají kusy kódů, nebo výstupů, docela k pláči. Alespoň citace mění barvu, jupí. Buď jsem úplně slepý, nebo se komentáře nedají editovat. Soubory se nedají vložit současně s příspěvkem, dají se vkládat pouze po jednom a ještě k tomu musím přejít na jinou stránku.

Už první pohled na úvodní stránku, případně na nějaký bug, musí odradit značnou část lidí od nahlášení chyby, protože jim to složitostí bude připadat jako raketová věda. Námět na "zlepšení" dle mého - Jako příležitostný uživatel chci jen minimum. Vidět jednoduchý přehled svých bugů, přehled projektů do kterých můžu nějaký bug nahlásit a při vkládání chci vidět maximálně tolik políček, kolik je nezbytně nutné. Což jsou asi úplně jiné věci, než potřebují správci těch projektů. Ti ať vidí co potřebují, do toho jim kecat nechci.

Nikdy jsem neměl možnost použít něco jiného, než Bugzillu a GitHub issues, takže neznám ty o dost horší systémy. Musí to být asi docela tragédie.

[Michal Kubeček]

Při zadávání nového bugu je těch polí podstatně ména (a nejspíš je to konfigurovatelné, protože v různých instancích to vypadá různě). Já mívám problém spíš opačný - štve mne, že některé údaje musím nastavit dodatečně až po vytvoření bugu. Obecně je potřeba rozlišovat mezi bugzillou jako takovou a tím, jak je nakonfigurovaná a upravená konkrétní instance.

[sid]

suhlas. Vid napr. Netbeans. Chapem, ze pre autorov to delenie dava zmysel, ale pre bezneho uzivatela ktory neskuma detaily ako je IDE vnutorne urobene a nepouziva ani Netbeans RPC je to absolutne zbytocne zlozite. Simple search vam vrati zbytocne vela a advanced search zase pre zmenu niekedy nic ked netusite co presne mate trafit.

[FrostyX]

Obecně je potřeba rozlišovat mezi bugzillou jako takovou a tím, jak je nakonfigurovaná a upravená konkrétní instance.

Souhlasím. Něco jsem hlásil na bugs.gentoo.org a něco na http://bugzilla.redhat.com/ a Gentoo tam těch políček má skutečně méně. Nicméně zbytečně hodně mi jich přijde v obou případech.

[pavlix]

Hodnotit bugzillu (software) podle bugzilla.redhat.com (instance odvozeného software) je nesmysl. Ale chápu, že používání stejného jména je do značné míry matoucí.

[Michal Kubeček]

Komentáře nepodporují formátování, což je v případě bug trackeru, kde se do spousty příspěvků vkládají kusy kódů, nebo výstupů, docela k pláči.

Nechápu. Vy víte o nějaké instanci bugzilly, kde by se příspěvky zobrazovaly proporcionálním fontem nebo se mršily mezery? To mi spíš vadí, že jediný způsob, jak potlačit automatické zalamování řádků, je označit text jako citaci.

Buď jsem úplně slepý, nebo se komentáře nedají editovat.

Nedají a IMHO je to dobře; představa, že někdo může úplně změnit komentář, na který už mezitím někdo jiný reagoval, se mi ani trochu nelíbí.

Soubory se nedají vložit současně s příspěvkem, dají se vkládat pouze po jednom a ještě k tomu musím přejít na jinou stránku.

To bude asi problém konkrétní instance, v naší je přidání attachmentu naopak vždy svázáno s komentářem (ale může být prázdný, takže se tam pak zobrazí jen automatické "XY added attachment N".

[FrostyX]

Nechápu. Vy víte o nějaké instanci bugzilly, kde by se příspěvky zobrazovaly proporcionálním fontem nebo se mršily mezery?

Myslím třeba Markdown, nebo alespoň html, aby človek mohl říct, "tohle je kód", "tohle je "zvýrazněný text", ... V bugzille se očekává podrobný popis problému, takže se píše spousta textu, do toho se vkládá spousta výstupů a kódů. Nepřijde mi moc přehledné, když to všechno vypadá úplně stejně.

Nedají a IMHO je to dobře; představa, že někdo může úplně změnit komentář, na který už mezitím někdo jiný reagoval, se mi ani trochu nelíbí.

To mě taky ne, ale pokud si sekundu po postnutí komentáře všimnu, že v něm mám chybu, nebo jsem na něco zapoměl, je k vzteku, že už s tím nemůžu nic dělat. A psát druhý komentář, abych opravil překlep, tak jsem ještě za většího vola, než když bych ho tam nechal.

[pavlix]

Myslím třeba Markdown, nebo alespoň html

Aneb jak to běžnému uživateli hned ze začátku zkomplikovat.

aby človek mohl říct, "tohle je kód", "tohle je "zvýrazněný text", ...

Vývojáři kód většinou od zbytku textu poznají. Zvýraznit něco v plaintextu je *triviální*.

V bugzille se očekává podrobný popis problému, takže se píše spousta textu, do toho se vkládá spousta výstupů a kódů.

Zase až tolik toho textu to většinou není a když, tak vývojář nepotřebuje mít od uživatele kód barevně orámovaný, navíc se tu mluvilo o tom, že je bugzilla příliš složitá a ty bys ještě přidával další komplikace, které by se dotkly především nových uživatelů.

Pak se bugzilla často používá jako zdroj textu pro jiné systémy nebo naopak se do ní kopírují celé bugreporty odjinud a čistý text dobře splňuje požadavky na kompatibilitu. V jednoduchosti je síla. Hlášení bugů pomocí omalovánek by jenom zdržovalo a rušilo, toť můj názor na věc.

[Bystroushaak]

Aneb jak to běžnému uživateli hned ze začátku zkomplikovat.

Komplikace by byla, kdyby bylo použití markdownu povinné. Pokud není, tak je to feature, která dělá život lidem jednodušší, ne naopak.

[pavlix]

Vzpomenu si na tebe, až zase přijdu do restaurace s příliš bohatým jídelním lístkem.

[kralyk z abclinuxu]

+1, Bugzilla je naprosto příšerná pro skoro kohokoli, kdo na ni není roky zvyklej.

Nikdy jsem neměl možnost použít něco jiného, než Bugzillu a GitHub issues, takže neznám ty o dost horší systémy. Musí to být asi docela tragédie.

Třeba Arch používá Flyspray, který ale není oproti Bugzille to není o moc lepší. Pak mě napadají Google Code Issues, které jsou takové dost primitivní, ale alespoň to uživatele nemate tisíci položkami jako Bugzilla.

Jina ty GitHub Issues (ditto BitBucket, Gitlab,...) jsou imho opravdu dobrá cesta, jejich síla spočívá zejména v jednoduchosti pro reportera, v možnosti formátovat bug/komentáře tak, že se dají číst, používat crossrefs (tj. extrémně pohodlně referencovat bugy, lidi, pull requesty, commity nebo i jednotlivé řádky kódu jakéhokoli repozitáře, atd.) a v neposlední řadě jsou celkem dobře pořešeny labels (ie. tagy).

[Josef Kufner]

Jo, GitLab/GitHub issues jsou asi to nejlepší, co jsem zatím potkal. Jednoduché, ale přitom to má vše důležité.

Právě v odkazech na cokoliv a provázanosti s Gitem je veliká síla. Hodně políček z bugzilly lze nahradit tagy (např. komponenta, které se bug týká). A formátování pomáhá udržet kompilované reporty čitelné. Když chci přiložit screenshot, tak ho prostě vložím rovnou do textu. Při poslání pull requestu lze komentovat jednolitvé řádky kódu a opět se to celé prováže s odpovídajícím bugem.

Bugzilla, Flyspray a podobné nástroje jsou právě ukázkou toho, jak GUI nemá vypadat. Programátoři to po chvilce pochopí, protože vidí pod povrch a tuší, jak takový systém uvnitř pracuje. Běžný smrtelník však vidí jen kopec políček a podivné GUI, ve kterém se ztratí.

Na doplnění technických detailů do reportu je nejlepší otevřít bug report rovnou z aplikace. Ta pak má příležitost doplnit technické detaily sama a uživatel jen napíše popis. Takto to dělá například Debian s pomocí nástroje reportbug. Uživatel zadá název balíku, kterého se to týká, z balíčkovacího systému se vytáhne, co má nainstalováno, zda to je aktuální, případně se přiloží i konfigurační soubory. Pak zadá titulek/shrnutí bugu, při tom to hledá podobné bugy, a pak má to políčko pro popis bugu. Nakonec zadá svůj e-mail, kam mu přijde kopie a pak případné upřesňující dotazy a další diskuse nad bugem. Vlastně ani nevím, jaké to má webové rozhraní.

Pokud by takový reportovací nástroj byl navázán na GitLab issues a vhodně integrován v aplikaci, asi by to bylo to nejlepší, co je dnes k dispozici.

[Mirek Suchý]

GitLab/GitHub issues jsou asi to nejlepší, co jsem zatím potkal. Jednoduché, ale přitom to má vše důležité.

To platí pro malé projekty, co mají současně otevřených tak 10 issues. S tagama (které jsou relativně nové) tak max. 100 otevřených issues. Projekt s tisícovkami bug reportů si na GitHub Issues nedokážu představit - jako autor, který by ty reporty měl zpracovávat. Pro uživatele to samozřejmě pohodlné je, ale to pak může posílat své reporty do /dev/null a bude to mít ještě pohodlnější.

[kralyk z abclinuxu]

Projekt s tisícovkami bug reportů si na GitHub Issues nedokážu představit

Viz třeba rust, vývoj probíhá přes celkem klasický GitHub workflow + rust-rfcs.

[Fluttershy, yay!]

Nejen to. Já dodnes ve většině bugzill nechápu, jak (bez několika pokusů a omylů) přehledně vypsat všechny existující reporty, které mě zajímají, nebo přidat soubory (někdy si myslím, že je přidávám, ale ve skutečnosti se tak neděje). Výchozí konfigurace navíc vypadá tak odporně a zmateně, že pochybuju, že autoři (a) někdy slyšeli o teorii kolem návrhu uživatelských rozhraní nebo použitelnosti, (b) neudělali bugzillu jako odstrašující příklad, nebo (c) neměli jinou agendu než usnadnit hlášení chyb.

Jediná instance Bugzilly, ze které se mi nechce okamžitě vyhledat toaletu (nebo aspoň křoví), je v KDE.

[FrostyX]

Já dodnes ve většině bugzill nechápu, jak (bez několika pokusů a omylů) přehledně vypsat všechny existující reporty, které mě zajímají

To jsem do včerejška taky nevěděl, tak jsem poklikal na všechno co se dalo a konečně jsem ten výpis našel . Např u toho KDE, člověk vcelku logicky klikne na "Browse" a vidí seznam projektů přes které se dokliká až k bugům. Ovšem nejvíc jsem použil asi RedHatí bugzillu a tam když člověk klikne na "Browse" tak se dostane na úplně něco jiného. Místo toho je potřeba kliknout vcelku nesmyslně na "Front page" (což opravdu není úvodní stránka).

[pavlix]

První věc kterou vidím, když si zobrazím existující bug, je 31 inputů, které mě absolutně nezajímají.

To já teda nevidím.

Komentáře nepodporují formátování

To vnímám jako zásadní úsporu času.

kde se do spousty příspěvků vkládají kusy kódů, nebo výstupů

Vkládání kusů kódu nebo výstupů mi nedělá nejmenší problém.

Buď jsem úplně slepý, nebo se komentáře nedají editovat.

Ještě to tak. To abych se pak hrabal v historii, abych věděl, kdo co původně napsal a proč na to kdo tak divně reaguje.

Soubory se nedají vložit současně s příspěvkem

Příspěvky se dají vložit současně se soubory. Při prvním pokusu o vložení souboru to člověk zjistí.

Už první pohled na úvodní stránku, případně na nějaký bug, musí odradit značnou část lidí od nahlášení chyby, protože jim to složitostí bude připadat jako raketová věda.

Otázkou je, proč je to odradí, a zda by takoví lidé byli přínosem projektu. Pokud člověk nedokáže relativně jednoduchou věc jako ustát úvodní stránku bugzilly a vyplnit jeden formulář, jak pak má zvládnout tak složitou věc jako dostatečně jasně popsat problém a následně spolupracovat s vývojáři na jeho analýze.

Vidět jednoduchý přehled svých bugů, přehled projektů do kterých můžu nějaký bug nahlásit a při vkládání chci vidět maximálně tolik políček, kolik je nezbytně nutné. Což jsou asi úplně jiné věci, než potřebují správci těch projektů. Ti ať vidí co potřebují, do toho jim kecat nechci.

Prostor ke zlepšení je vždycky. Jestli je k tomu potřeba rozdělit uživatelské rozhraní na plné a debilizované, to nevím. Osobně to ale vídám v opačné formě. Tedy pro nové uživatele je formulář co nejbohatší, aby jim každé políčko připomnělo nějakou věc, kterou můžou vyplnit, zatímco vývojáři to povětšinou chápou nebo alespoň reagují na dotazy. Někteří to řeší tím, že do toho velkého textového pole vloží šablonu.

[Bystroushaak]

To já teda nevidím.

To asi nikdo, kdo tam nemá account.

To vnímám jako zásadní úsporu času.

Zvláštní je, že tady na abclinuxu formátování v klidu používáš.

Pokud člověk nedokáže relativně jednoduchou věc jako ustát úvodní stránku bugzilly a vyplnit jeden formulář, jak pak má zvládnout tak složitou věc jako dostatečně jasně popsat problém a následně spolupracovat s vývojáři na jeho analýze.

Tohle imho není vůbec o to jestli dokáže / nedokáže, ale jaký počet frustrátů to vyžaduje. Když půl dne bojuju s hledáním nějakého posraného bugu a pak mám ještě strávit půl dne registrací a vyplňováním formuláře, který si ve složitosti a počtu požadavků nezadá s českou úřední byrokracií, tak to může velmi jednoduše skončit tak, že celkový počet frustrátů je už moc velký.

Osobně to ale vídám v opačné formě. Tedy pro nové uživatele je formulář co nejbohatší, aby jim každé políčko připomnělo nějakou věc, kterou můžou vyplnit, zatímco vývojáři to povětšinou chápou nebo alespoň reagují na dotazy.

No jo. A ještě políčko, kde můžou složit haiku, či nějakou jinou vhodnou báseň.

Bugem zasažen,
umírám poražen,
před branou bugzilly.

[pavlix]

Souhlasím s tím, že vyplnit ta dvě textová pole je velmi složité a vybrat produkt, komponentu a verzy je taky pro uživatele hrozná komplikace, ale pro vývojáře jsou to zásadní informace.

[Já]

Myslím, že příčetný bug tracker by neměl mít ve zvyku posílat maily, že se někdo přidal do cc:, u pár let starýho bugu. Co jsem navíc ani nehlásil já, ale jen abrt.

[Michal Kubeček]

Zatímco svéprávný diskutující by neměl mít ve zvyku za chybu bugtrackeru označovat to, co si může snadno vypnout ve svých preferencích.

[já]

Já taky neříkám, že je to nezbytně chyba, jen hodně stupidní výchozí nastavení. Co o tom bugtrackeru ovšem něco vypovídá, což?

[já]

A já bych to nakonec i překousl, si to holt odkliknu, no. Ale co mám odkliknout aby i jednoduché queries běžně netrvaly desítky sekund*? Please stand by. Please stand by. Please stand by. Netuším jak je na tom se škálovatelností a rychlostí ten phabricator, ale je slušná šance, že by to nemuselo bejt tak špatný.

* U opravdu velkých databází jako RH bugzilla. Menší projekty to mají tendence stíhat v řádu sekund, ale i to je zas...ně moc.

[pavlix]

Rychlost je u RH bugzilly problém, ale nelze takhle jednoznačně říct, že když uděláš větší databázi, tak to bude pomalé. Za tím může být sto dalších důvodů a většina se bude týkat spíše provozu než množství uskladněných dat. Jestli by byl Phabricator řešením pro RH, to musí pousoudit jiní. Ale ani o té škálovatelnosti a srovnání rychlosti jsem nenašel moc informací. Člověk nemůže posuzovat software podle nějakých jeho instancí, kde jedna může být na levném virtuálu, druhá na slušném železe apod.

[Já]

Tak já nevím kolik má RH bugzilla zastoupení mezi veřejně dostupnými bugtrackery, ale čekal bych, že to bude požehnaně. Ale není ta samozřejmě jen ona. I na gnome bugzille (další objemné db, co potřebuju) jsou dotazy minimálně na sekundy. Když nic jinýho, jsou to "high-profile" deploymenty z homepage bugzilly, myslím, že určitý obrázek si z nich udělat můžu.

Sám bugzillu neprovozuju, takže samozřejmě moc neposoudím jaká to je nebo není výzva, viděl (a někdy i musel udržovat) jsem různé menší/jednodušší systémy, které na tom i s mnohem menší databází (nejvyšší číslo ticketu ~20.000) nebyly taky vůbec dobře a nakolik můžu posoudit, tak spíš proto, že byly opravdu pomalé, než blbě nastavené. Tak asi ani neuvadím lepší variantu bugzilly, ale můj názor na její použitelnost je prostě špatný, protože často se do ní ptát je přesně to, co s ní chci dělat...

[pavlix]

Zastoupení RH bugzilly je v kontextu posuzování upstreamového projektu irelevantní. Co jsou menší/jednodušší systémy? Bugzilla vypadá jako velice jednoduchý systém, co do funkcionality. Mně osobně na bugzille vyhovuje právě ta jednoduchost, a absence markupu a tudíž nejradši používám buď bugzillu nebo podobně jednoduchý systém. Markdown mě sice do značné míry zdržuje, ale toleruju ho, jsem na něj zvyklý ze stack exchange a podobných. Když je systém pomalý, tak mi to samozřejmě vadí, ale zpravidla s tím nemůžu nic udělat, neb nejsem ani jeho provozovatelem.

[Já]

Co pak relevantní je? Vždycky když narazím na bugzillu, tak mě čeká pomalé a neohrabané ovládání. Pro maintainera nebo support, co to denně používá, má v hlavě představu, co se zrovna děje a ví co zrovna za issues "frčí", to je asi v pohodě. Ale pokud já jako uživatel potřebuju řešit proč mi něco v distribuci padá, je to špatný.

A bavit se o bugzille na individuálních projektech podle mě nemá cenu, protože jako upstream vývojář jednoho projektu bych asi dnes už nechtěl issue tracker, co nemá vůbec žádné propojení s SCM. Tak musím vzít něco existujícího a to jsou ty bugzilly uvedené na bugzilla.org jako high-profile příklady použití. Které jsou pomalé.

[pavlix]

Co pak relevantní je?

Třeba posuzovat software v jeho původní podobě?

Ale pokud já jako uživatel potřebuju řešit proč mi něco v distribuci padá, je to špatný.

To bych viděl spíše jako nutné zlo než jako problém konkrétního software. Bugzilla je relativně efektivní nástroj na správu bugů a feature requestů, který je zpravidla otevřený široké veřejnosti, takže se můžou na vývoji takto účastnit. Jejím hlavním účelem ovšem není support tool (ale to platí i pro Phabricator a další), a nepředpokládá, že bude mít projekt najaté (nebo dobrovolné) supporťáky.

A bavit se o bugzille na individuálních projektech podle mě nemá cenu

Stačí se bavit o Bugzille a ne RH Bugzille.

protože jako upstream vývojář jednoho projektu bych asi dnes už nechtěl issue tracker, co nemá vůbec žádné propojení s SCM

Propojení s SCM je stejně užitečné v upstreamu jako v distribuci. Jsem zvyklý fungovat bez toho, ale uznávám, že je to super vlastnost a ideální by byla podpora pro patchsety ve formě větví namísto textových diffů.

Tak musím vzít něco existujícího a to jsou ty bugzilly uvedené na bugzilla.org jako high-profile příklady použití. Které jsou pomalé.

Ale to je normální a není to nic specifického pro bugzillu. Pokud provozuju nějaký tool pro hodně lidí, tak bych mu měl poskytnout odpovídající výkon. A to zpravidla stojí peníze, které nemám vždy k dispozici.

[Já]

Je trochu obtížné se bavit o bugzille obecně, když nevím jak zevnitř vypadá a jestli tam je šance, aby byla rychlá nebo ne. Přepodkládám, že tady to ví málokdo. Ovšem co se dá vědět celkem snadno je, že velké bugzilly, které jsou přímo uvedené na bugzilla.org, jsou prostě k posr...ní pomalé. Z toho usuzuju, že "software v původní podobě" má zásadní problémy fungovat přijatelně rychle, protože ho tak zřejmě nikdo nedokáže provozovat. Mohlo by to samozřejmě být tím, že to někdo používá na neadekvátním hardwaru, ovšem pak to opět zřejmě dělají všichni, což by mohlo vést na podezření, že ten adekvátní hw by byl neadekvátně drahý. Přitom se naopak domnívám, že by mělo jít hledat i relativně velké databázi ticketů aspoň o řád rychleji a utratit za to jen nějaké snesitelné množství peněz.

Propojení s SCM by u velkého množství různých projektů v distribuci by bylo myslím docela obtížné. Mohlo by samozřejmě sledovat jen nějaký repozitář distribučních změn a ne upstream, ale to mi zase nepřipadá až tak šíleně užitečné.

[pavlix]

Je trochu obtížné se bavit o bugzille obecně

O tom nepochybuju.

Přepodkládám, že tady to ví málokdo.

Minimálně za sebe můžu říct, že to nevím.

Z toho usuzuju, že "software v původní podobě" má zásadní problémy fungovat přijatelně rychle, protože ho tak zřejmě nikdo nedokáže provozovat.

Já z toho pro jistotu neusuzuju vůbec. Pokud někdo přijde s bug trackerem, který mi bude alespoň tak příjemný jako bugzilla, prosadí ho mezi důležitými hráči a výkonnostní problémy se neprojeví, tak mi bude ctí mu osobně poděkovat. Jenže to považuju za nepravděpodobné, to už spíš přijde někdo s nějakou šílenou ptákovinou a pár buzzwordy.

Propojení s SCM by u velkého množství různých projektů v distribuci by bylo myslím docela obtížné.

Měl jsem namysli především jeden hlavní projekt v distribuci, a je správa distribučních balíků. Těch pár projektů okolo jako webovky, dokumentace a další z toho můžou těžit taky, ale ty jsem až tak namysli neměl. Ani tím nemám namysly zaštiťující projekty pro malé upstreamové projekty jako je fedorahosted.org.

Mohlo by samozřejmě sledovat jen nějaký repozitář distribučních změn a ne upstream,

Tady si vůbec nerozumíme. Mezi distribucí a upstreamem je povětšinou jasná dělící čára. Upstreamové projekty si volí své nástroje samy a distribuce to nemá jak ovlivnit, takže asi těžko můžu mít namysli upstream. Osobně se angažuju jen ve dvou komunitních distribucích (viz patička), takže se rád nechám poučit, že to někdo dělá jinak. V jedné z nich se používá jediný verzovaný strom pro všechny balíky, druhá používá samostatný verzovaný strom pro každý jednotlivý balík, ale v důsledku to funguje dost podobně.

ale to mi zase nepřipadá až tak šíleně užitečné.

Mně osobně to přijde snad ještě užitečnější než u upstreamu, vzhledem k tomu, že se trackuje to, co uživatel už přímo používá.

[ja]

Vykonostni problemy se asi projevi vsude, na druhou stranu prvni co se proti tomu da delat, je obetovat hledani proti aktualnimu stavu databaze a delat vsemozne indexy a cache. To by mi nevadilo. Rychly dotaz proti stavu db pred 30 minutama je pro me lepsi nez zoufale pomaly proti aktualnimu.

Ja myslim, ze si rozumime. Potiz je v tom, ze zadnou distribuci neudrzuju, takze mi zmeny ve strome se specfily nebo necim podobnym prijdou desne nezajimave. Zajimaji me hlavne patche a patche chci videt proti kodu upstreamu, takze pokud mluvim o propojeni s SCM, myslim samozrejme s SCM upstreamu. (Ktery samozrejme ma asi svoje vlastni nastroje, nicmene to jeste neznamena, ze by distribucni bugzilla nemohla aspon teoreticky videt jejich SCM.) Coz pripoustim, ze je velmi obtizne, tak nedavam bugzille za vinu, ze to neumi. Nejbliz je tomu asi launchpad, ale to je ve vysledku taky hodne crap, protoze bzr a fasismus.

[pavlix]

Launchpad je ve výsledku jedna velká prasárna, i když jako inspirace by posloužit mohl.

[pavlix]

Nevím, jaké je výchozí nastavení v upstreamu, ale tohle skutečně není o bugzille, ale o bugzilla.redhat.com, která se od upstreamové bugzilly zásadně liší. Navíc pokud vím bugzilla jako taková nikde nedeklaruje, že má výchozí nastavení uzpůsobené používání ABRT, takže by to nastavení ani v jejím kontextu nebylo stupidní. Podle mě zkušenost s bugzilla.redhat.com o bugtrackeru jménem bugzilla nevypovídá téměř vůbec nic a tato konkrétní zkušenost podle mě může vypovídat maximálně o ABRT a jeho integraci s bugzillou.

[Já]

Tak to (abrt) je samozřejmě taky dáreček... o tom žádná.

[pavlix]

Tak já osobně mám z abrt pozitivní dojem. Co vím, tak je to relativně mladý projekt a spousta věcí by se dala ještě vychytat, ale už teď to dokáže pro uživatele v případě nějakého zjevného problému v podstatě napsat celý bug report a vývojář ho tak může rovnou řešit. U některých problémů tak jde zkrátit dobu do vyřešení třeba z měsíců na hodiny.

[Michal Kubeček]

Jste si opravdu jistý, že je to výchozí nastavení bugzilly, ne jen konkrétní instance? Já třeba s (jednou konkrétní) bugzillou pracuji téměř denně a přesto netuším, jaké je defaultní nastavení bugzilly jako takové (a vlastně už ani jaké je současné defaultní nastavení té naší).

Mimochodem, já třeba informace o změnách v Cc považuji za užitečné a kdyby byl default opačně, přišlo by to nepraktické zase mně. Ale místo toho, abych to po diskusích vydával za chybu bugzilly, bych si to prostě přenastavil.

[pavlix]

Mimochodem, já třeba informace o změnách v Cc považuji za užitečné a kdyby byl default opačně, přišlo by to nepraktické zase mně.

+1

Ale místo toho, abych to po diskusích vydával za chybu bugzilly, bych si to prostě přenastavil.

+1

Na druhou stranu je mnohem lepší notifikace posílat než neposílat, protože ta potřeba přenastavení se uživateli sama připomíná. Pokud je default opravdu takový, jak se anonym domnívá, tak mi přijde nejenom subjektivně, ale i objektivně lepší.

[Marián Kyral]

Potkal jsem pár komerčních řešení - zlatá Bugzilla.

[Karel N.]

Pokud ti stačí gitlab, je zbytečné vůbec používat phabricator. Phabricator není konkurence pro gitlab. Phabricator poskytuje lepší správu velkého množství ticketů pro obrovské týmy, dá se tam lépe zadrátovat interní procesy pro schvalování, zařazování a priotizování. Má lepší evidenci zdrojů (lidi, času) atd.

To je program úplně k něčemu jinému, pokud s tím někdo nahrazuje gitlab, už se ani nedivím, proč na něj tak nadávají :)

[pavlix]

Pobavilo.

[Jindřich Makovička]

Tohle mi vypadlo z Googlu na dotaz Phabricator scalability.. tak nevím. https://secure.phabricator.com/T4369

[pavlix]

Phabricator je hrozná věc. Já jsem se s tím seznámil kvůli Enlightenment a působí to, jako kdyby to vytvářel nějaký neznámý indiánský kmen. Ten software je hrozně komplikovaný a nesrozumitelný, na to, co to dělá. Jenom tak triviální věc, jako dostat se k ticketům nebo projektům byl fakt oříšek.

[David Heidelberg]

Možná je to o zvyku. Mě to na první pohled přislo přesně jak popisuješ (Enlightenment).

Na druhou stranu když jsem poprvé viděl bugzillu, myslím, že se mi chtělo plakat.