Názory k článku Zahoďte Bugzillu a nasaďte Flyspray

No tady by stalo za to rict nekolik zasadnich rozdilu:

* Team Concert neni urcen primarne pro bugtracking (na to je jiny nastroj z Jazzu; pro ty, kteri se s tim jeste nesetkali, RTC ma v sobe i VCS)
* Team Concert ma zasadne vyssi pozadavky na HW

Nez se do me nekdo pusti, tak bych rad rekl, ze jsem zodpovedny za nasazovani Rational Team Concertu do prostredi mezinarodni korporace.

Zajímavé. Nechtěl byste napsat blogpost?

No nejdrive to musime nasadit, pak teprve muzu neco napsat.
RTC neni spatny system, ale rekl bych, ze v Open-Source svete jsou reseni lepsi. Navic pro realnou praci musite pouzivat RTC clienta, coz je Eclipse-based software (coz opet klade docela vysoke naroky na HW, tentokrat u uzivatele).
Co se tyka serverovych naroku, trvam stale na svem … chce to hodne (ale mozna jsem zaspal dobu, moje programy se stale spokoji s MB, nepotrebuji GB).

opensource != free as a beer

To přece nemusí být ve zdrojáku, stačí, když si to autor dá jako podmínku legálního využívání. Podmínky OSI jsou zcela splněny, je možní upravovat a je možné šířit za stejných podmínek (že „je nutno šířit za stejných podmínek“ není v rozporu s ničím).

Tiez mozno stoji za zvazenie

Jo, Redmine (ruby) vypada dobre a je docela aktivne vyvijena, narozdil od Tracu (python), ktery je masivne rozsireny, moc se nevyviji a proste funguje.

Zajimava sluzba je http://sourcerepo.com, ktera poskytuje git/svn/hg repozitar spojeny s Redmine i Tracem. Ceny jsou podobne vstricny jako u githubu: 4$/mo ~ 1 repozitar ~ neomezene uzivatelu ~ 0.5GB, 7$/mo ~ neomezene repozitaru ~ neomezene uzivatelu ~ 1GB, ..

Hlavním problémem zřejmě všech těchto systémů je velmi nízká míra nastavení. Společnost (či komunita) se tak musí adaptovat na to, jak daný systém funguje. Napříkad Bugzilla má předem daný workflow, který lze jen velmi málo (a nebo těžko) upravovat.

V praxi (zejména v korporátní sféře) se proto používají jiné (obvykle komerční) řešení, které se nastavují dle přání zákazníka. Dvě taková nasazení mohou být diametrálně odlišná co se týče workflow, ale také ukládanými informacemi a reportingem.

Doporučil bych se podívat také na tyto systémy:

http://www.jetbrains.com/youtrack/index.html
http://www.atlassian.com/software/jira/

JIRA neee. to je tak nenergonomicky software ze tezko budete hledat neco horsiho – i kdyz mantis ten asi horsi nez jira bude.

Nic proti, ale Jira se da velice jednoduse vytunit (v jedne korporaci sem se na takovym tuneni podilel) a potom je to velice slusnej SW – srovnavam teda s Bugzilou, Raidem nebo jak se to menovalo (interni MS tracker), cimsi internim od Symantecu a par mensima systemama jako Trac (vse aktivni uzivatel/spravce).

a co konkretne vam tak strasne vadi na ergnomii JIRA?
co treba tip na nejaky _lepsi_ ekvivalent? (ve srovnatelne cenove hladine)

zkousel jste treba TaskPool? (http://www.taskpool.net) tomu rikam opravdu neergonomicky kus sw, vedle nej i mantisbt je 4prouda dalnice :-D

Ano, mantis je opravdu hrůza, používaá ho nevímproč scribus.

Asi je to otázka vkusu, ale nové verse JIRA opravdu nevypadají špatně a ve spojení s GreenHopper-em (nadstavba pro agile) je to skutečně velmi efektivní. Drag&drop tabule pro kanban fakt funguje.
Zkoušeli jsme řadu nástrojů, ale JIRA vyhrála. Filozofie pokud se ti něco nelíbí, tak to přenastav, v extrému klidně i přepiš, odpovídá OSS (zdrojáky jsou v ceně), ale support Atlassian je na úrovni a zvedá aplikaci na vyšší úroveň. Pokud je to pro tebe zajímavé, tak info v češtině je na http://myjira.cz

S Flysprayem mám několikaletou dobrou zkušenost i přes to, že jsem si spolu s jeho vývojáři „užil“ pár dětských nemocí. Vyzdvihl bych jeho přehlednost a uživatelskou přívětivost, která přispívá k vyšší produktivitě. Na své současné pozici jsem ale zvolil Atlassian JIRA kvůli napojení na další nástroje (Eclipse) a systémy (wiki, continuous integration server).

Už mě to fuckt nebaví, to se pořád musíte navážet do různých projektů. Nejdřív vymývání mozgů Git-ovými sektářskými fanatiky, teď toto?!?! Jděte s tím do řiti!!!

A ty sam se pritom navazis do konfrontacnich clanku – napsal jsi konfrontacni prispevek!

Jdi si tam sam. Ja se rad dozvim o ruznych alternativach k tomu, co uz znam.

A clanek postaveny na tom, proc je nova alternativa lepsi a v cem oproti stavajicimu reseni vynika je presne to, co se mi hodi. Nepotrebuju dlouhy uvod do problematiky, pokud clanek zacina necim jako „je to v podstate stejne jako bugzilla, ale lepsi“ nebo „Resi stejne problemy jako Subversion, ale umi to i mnohem vic“ … protoze Bugzillu i Subversion znam, tak si usetrim spoustu odstavcu o dulezitosti a metodach hlaseni chyb pripadne verzovani.
Ze je to v necem lepsi/jine nez stavajici rozsirene reseni je jasne, protoze proc by to jinak nekdo delal, dulezite je v cem se to od nej lisi a zda jde o vlastnosti, ktere ja potrebuju a ktere mi pomuzou v necem, co mi zatim delalo problemy, nebo jsem ani netusil, ze to jde, natoz tak snadno. Zaroven se ovsem slusi i dodat, v cem pripadne nove reseni zaostava, nebo co vubec neresi – nekdy i toto muze byt duvodem k prechodu, protoze casto jde o mene dulezite zalezitosti, ktere naopak v originale praci pridelavaji ci prekazi … a nebo naopak duvod k zustani, pokud jde o neco pro me klicoveho. Tak ci tak je mnohem rychlejsi ukazat v cem se to LISI, nez popisovat vsechno co to umi, protoze v tom mnozstvi se prave ty dulezite odlisnosti ztrati.

Git me napriklad zaujal prave tim, co uvedli jako prednosti proti SVN, protoze jsem zjistil, ze to jde delat „az takhle snadno“ a ze me uz dlouhou dobu prave tyto veci v SVN vadily, aniz bych o tom vedel a umel to pojmenovat. Takze ted mam Git nainstalovany a vyvijim prevazne v nem, zatimco Subversion pouzivam pro spolupraci s okolim a vsemi na ni navazanymi procesy – misto spousty commitu s ruznou hodnotou tak commituju pouze uz „hotove a odladene“ veci, cimz se historie SVN pekne procisti, procesy vsechno zprocesujou jak je zvykem a doma si pod Gitem muzu delat divociny podle sve chuti (a pomalu uz se mi vratil cas venovany uceni Gitu).

Naopak tady jsem se o Flyspray dozvedel jen malo a z toho spoustu veci, ktere me neoslovuji – AJAX sam o sobe se mi nezda prinosem, s konfiguraci nasi Bugzilly jsem v ramci moznosti spokojeny (mozna kdyby tu nekdo rozvedl, v cem je Flyspray konfigurace lepsi, tak bych nazor zmenil, ale kdyz me nenapada kde me bugzilla omezuje zbytecne, tak nevidim duvod zkouset FS jen protoze je jiny).

Pokud te takove clanky nebavi, tak je proste bud necti, nebo napis sam lepsi a nabidni ho redakci. Pokud bude vazne lepsi, tak se vynasnazim abych byl prvni, kdo te za nej bude chvalit. Jestli znas zpusob jak predstavit moznosti noveho projektu bez „navazeni se“ do stareho, tak sem s tim, budu ti drzet palce a rad se priucim.

(To ze ja neco neznam, nebo si neumim ted predstavit vubec neznamena, ze to neexistuje – viz muj nedavny objev Gitu, ktery mi ukazal, co me v Subverzi vlastne vadilo a prekazelo a ze neni nezbytne nutne aby to tak bylo, protoze to jde i jinak a lip – dokud jsem o Gitu nevedel, tak byla Subverze muj nejoblibenejsi verzovaci system).

Pripadne zkus napsat, v cem jsou stavajici systemy lepsi nez ty, ktere se do nich „navazeji“ – to ze tu byly driv nikdo nezpochybnuje, ale to samo o sobe neni jeste kvalita a zaruka jedine spravne cesty jak jednou provzdy dany problem resit.

velmi dobra skusenost s: http://trac.edgewall.org/
integruje wiki, issue tracker, repository browser… je mozne prepojit s eclipse mylyn

Pripajam sa k Tracu. Pouzivam ho uz dlhsi cas a som s nim spokojny. Lahko konfigurovatelny, prehladny.

Ja znam trac jen z pohledu bug-reportujiciho uzivatele u OSS projektu, ale bugzilla podle me ma vyrazne navrch. Trac mi prijde neintuitivni a tezko se v nem hleda to co chci. Jeste ze dneska vetsina projektu se kterymi prijdu do styku pouziva bugzillu.

Je pravda ze treba Red Hat a Fedora ma bugzillu dost upravenou proti jinym projektum (nezkoumal jsem jestli je to jen nastavenim nebo jestli tam neco doprogramovavali). Ale i „normalni“ bugzilla jako ji ma GNOME nebo fd.o je o tridu lepsi nez Trac nebo ta vec co ma SourceForge.

Mozna je pohled ze strany vyvojare nebo spravce bug-tracking systemu jiny, tezko rict.

-Yenya, http://www.fi.muni.cz/~kas/blog/

To sme sa toho ale dozvedeli, hned mi je jasne, v com je ta BugZilla tak zla a nepouzitelna a com tento Flyspray tak vynika (sorry, ake argument „ma menej features a je v php takze dobre vyzera“ ma moc neberie). Naozaj by sa hodilo nejake hlbsie porovnanie, v com presne zvysuje produktivitu, ako sa da vsimnut ta prehladnost a prinos UI v php, dalsie klady, zapory, moznost rozsiritelnosti, porovnanie s inymi systemamy (aspon s tymi najznamejsimi ako napr. JIRA).

Toto mohla byt kludne spravicka v style „vysiel novy Flyspray, ktory som si osobne oblubil pre jeho pekne GUI a jednoduchost, dovi dopo.“

… prestal jsem cist u zminky ze tahle vec je napsana v PHP. (A nadavam si, ze jsem vubec klikal na clanek s takto jedovatym titulkem).

-Yenya, http://www.fi.muni.cz/~kas/blog/

Nevim jestli chci pouzivat produkt ktery jiz rok nevydal zadnou verzi.
Nedavno jsem to resil a zvolil jsem mantisbt. Byt muze byt na prvni pohled neprehledny, tak pouzitelny je, a aspon se vyviji.

Nasazovat flyspray pro mensi projekty mi stale (podobne jako bugzilla) prijde jako kanon na vrabce. Pokud potrebujete jednoduchy bug tracking system jen pro jeden projekt, pak nejjednodussi na praci mi prijde Trac.

+1

Velmi trefne vystihnute. Mam pocit, ze ked clovek chce nejako monitorovat bugy, to uz aby rozbehol giganticky projekt, lebo inak nasadenie Bugzilly alebo Fylspray-u nestoji za tie nervy. Naco pouzivat flatfile ked to mozeme robit cez databazu? Zacarovany kruh.

Aj ked Trac pouziva (standardne) SQLite, som s nim spokojny. Je ho mozne pekne integrovat cez fcgi interface s webserverom alebo spustit stand alone. Jedine co mi vadi a co brani nasadeniu na hostingoch je, ze je to Python.

Nezloběj se, ale v kontextu „…lepší systém jsem neviděl..“ by bylo fér uvést, co všechno viděl..

Assembla.. hezký, ale nemohu se zbavit dojmu „vyzobaná JIRA“ :)

Podla mna daleko najlepsi bug tracking je FogBugz ale zial dost draha … ale pri vacsich projektoch sa asi oplati.

BugZilla mi prisla nic moc :(

Je moc od veci spomenúť opensource aplikáciu pre Win na priraďovanie úloh? Dáta to ukladá do XML súboru, takže nič pre veľké tímy, ale pre jednotlivcov a menšie tímy to môže byť dostatočné, mne to úplne stačí :)
http://www.codeproject.com/KB/applications/todolist2.aspx

Takze Bugzilla se nema pouzivat, protoze je 12 let stara a je oskliva? To je skutecne zasadni problem. A vyhoda Flyspray je naopak v tom, ze je v PHP? :) Velice vtipne.

Muze se prihlasit nekdo, kdo rika vsem bugtracking systemum bugzilla? Nikdy jsem to neslysel, prijde mi to jako blbost. Rika se tomu bugtracker, ne?

ten anglickej vyraz se pouziva hlavne proto, ze je to jedno slovo.

Vzhledem k integraci s dalšími nástroji (IDE, build servery) je Bugzilla pořád zlato oproti Flyspray. Mantis a Redmine či i komerční JIRA též bodují. Flyspray je podobně jako třeba JTrac v tomhle ohledu osamoceným ostrůvkem.

Chvilku jsme pouzivali Flyspray, ale pak jsme presli na Redmine. Duvody? Redmine toho nabizi vic, je konfigurovatel­nejsi, aktivnejsi komunita, je na to rada rozsirujicich pluginu a byl pristupnejsi pro ne-programatory v tymu. Na druhou stranu je Redmine uz pomerne velka aplikace napsane v Ruby On Rails, rozchodit na to serveru byla proti Flyspray mnohem vetsi prace.