trac and setups..
Sunday, 24. August 2008, 09:24:18
Hello all! Im back from vacation. 4 weeks of pure rain and clouds, yay.. well.. atleast 3weeks of that, since we went to Greece the last week which provided us with lots of sun, bathing and beers!
Anyway... just to let you know how things works at work now when Im back from vacation..
We now have 'trac' up and running on a nice little exlusive server setup only for my QA dept =).
I installed vmWare server on it and then setup a nice little VM running 'Ubuntu server ed' on it which inreturn hosts the trac server through apache2 and mod_python. Yeah, I know.. maybe some of you dont know jack shit of what Im rambling about there, but here are some links to the things which I used to setup our ticketing system for my new workplace, if you are curious and want to know more, have a look at the links below.
Trac can be read about here:
vmWare server can be read about here:
Mod_python can be read about here: and how to set it up with trac here:
So, currently, I have setup trac in a somewhat un-ortodox way I belive, but I think that the way I have made it creates the least overhead and is a good foundation to get trac to the least intrusive when developing software...
Traditionally, you created on trac setup per project each with different adresses/sqlite db's/modules/plugins running on the same server. This meas that you can have 4 bugs called bug 1000 if you have 4 projects(ofcourse on different adresses, but still...) I dont like that idea if being able to have 4 bug numbers with the same 'name' so I hade to work around that.
The solution was to have one 'meta-project' which covered each product, which fortuantly was possible thanks to some nice help on the trac irc chat but also through the excellent wikis on how to setup trac and such.
We now have a very good startpage when logging into trac. Here you can see a good overview of the current number of open bugs for each product, current unassigned bugs per project and also assigned bugs per project. Since trac also is a completel WIKI solution, anyway with access rights to create wiki pages, can go in and edit any page(even the startpag) and therefor also create new 'filters' to show results/content etc which they find usefull for there projects. One of these filters I made was a ticket filter which shows how many bugs is assigned to 'QA verification'.
When a bug is send to QA, that means that the developer have submitted the bug for QA'ing or 'Verification' to verify that the fix he/she have made actually adresses the reported problem/enhancement which is described in the ticket. This is brilliant, because QA get's directly send a note(mail/rss) when anyone sets a ticket to 'Submit to QA'
Ohwell.. enough rambling about QA and trac and setup's etc.. current status is that Im very pleased with the performance of trac, the stability of trac and how easy an trac admin can change/adapt and create new 'functions' by simply tweaking trac to suite a products needs. =)
So, if you are thinking about setting up a ticketing system of somesort, please, please consider to have a look at trac, because it's simply outstanding! =)
Anyway... just to let you know how things works at work now when Im back from vacation..
We now have 'trac' up and running on a nice little exlusive server setup only for my QA dept =).
I installed vmWare server on it and then setup a nice little VM running 'Ubuntu server ed' on it which inreturn hosts the trac server through apache2 and mod_python. Yeah, I know.. maybe some of you dont know jack shit of what Im rambling about there, but here are some links to the things which I used to setup our ticketing system for my new workplace, if you are curious and want to know more, have a look at the links below.
Trac can be read about here:
vmWare server can be read about here:
Mod_python can be read about here: and how to set it up with trac here:
So, currently, I have setup trac in a somewhat un-ortodox way I belive, but I think that the way I have made it creates the least overhead and is a good foundation to get trac to the least intrusive when developing software...
Traditionally, you created on trac setup per project each with different adresses/sqlite db's/modules/plugins running on the same server. This meas that you can have 4 bugs called bug 1000 if you have 4 projects(ofcourse on different adresses, but still...) I dont like that idea if being able to have 4 bug numbers with the same 'name' so I hade to work around that.
The solution was to have one 'meta-project' which covered each product, which fortuantly was possible thanks to some nice help on the trac irc chat but also through the excellent wikis on how to setup trac and such.
We now have a very good startpage when logging into trac. Here you can see a good overview of the current number of open bugs for each product, current unassigned bugs per project and also assigned bugs per project. Since trac also is a completel WIKI solution, anyway with access rights to create wiki pages, can go in and edit any page(even the startpag) and therefor also create new 'filters' to show results/content etc which they find usefull for there projects. One of these filters I made was a ticket filter which shows how many bugs is assigned to 'QA verification'.
When a bug is send to QA, that means that the developer have submitted the bug for QA'ing or 'Verification' to verify that the fix he/she have made actually adresses the reported problem/enhancement which is described in the ticket. This is brilliant, because QA get's directly send a note(mail/rss) when anyone sets a ticket to 'Submit to QA'
Ohwell.. enough rambling about QA and trac and setup's etc.. current status is that Im very pleased with the performance of trac, the stability of trac and how easy an trac admin can change/adapt and create new 'functions' by simply tweaking trac to suite a products needs. =)
So, if you are thinking about setting up a ticketing system of somesort, please, please consider to have a look at trac, because it's simply outstanding! =)
WIDGETIZE