Post #211,474
6/16/05 6:53:35 PM
|
Favorite Open-source bug tracking tools?
I've got Subversion and TortoiseSVN setup at work for version control, and like that combo.
Now I want to link in a bug tracker type of tool that can handle tracking bugs and feature requests, and maybe more. Right now, I'm learning towards Trac ([link|http://projects.edgewall.com/trac/|http://projects.edgewall.com/trac/]) because I like its Wiki and project management features, but I'll have to get it working with Python 2.4.
Requirements:
-- Free, free and open source preferred (I have no budget)
-- Runs on Windows XP (work requirement)
-- Must interface with Subversion
-- Decent documentation
Preferences:
-- Web interface using Apache (already running Apache for Subversion)
-- Can handle multiple projects
-- Simple to setup and use
-- Can also run on Linux (might be good in the future)
Tony
ex-juror
|
Post #211,477
6/16/05 8:00:38 PM
|
bugzilla?
|
Post #211,485
6/16/05 8:30:31 PM
8/21/07 12:39:27 PM
|
We're using bugzilla for a few things
seems ok - its lack of expected completion date tracking shows its open source roots and is a little annoying.
"Whenever you find you are on the side of the majority, it is time to pause and reflect" --Mark Twain
"The significant problems we face cannot be solved at the same level of thinking we were at when we created them." --Albert Einstein
"This is still a dangerous world. It's a world of madmen and uncertainty and potential mental losses." --George W. Bush
|
Post #211,486
6/16/05 8:41:01 PM
|
Bug/Feature management and Project management not....
....necessarily synonomous. Guess you could ask for a tool that integrated the two, but the two really require a different interface. One assigns tasks and priorioties. The other just acts as a repository for all reported bugs and feature requests. Managing those requests is very much different - you have to pick and choose your battles.
(Not to mention estimated completion dates are generally fantasies).
|
Post #211,551
6/17/05 12:26:45 PM
8/21/07 12:41:36 PM
|
Re: Bug/Feature management and Project management not....
"Not to mention estimated completion dates are generally fantasies"
Not true here. The main trouble ticket system that runs everything is remedy. If you want anything you file a ticket. If you see something wrong, you file a ticket. Tickets have service level agreements and must be completed within a certain time (different priorities have different SLAs). We do use tickets to manage feature requests and it tends to make sure stuff gets done in a timely manner.
Its not good for coordinating large scale project management, but for lots of isolated items its OK.
Excel is the best tool I've found for managing projects so far. I am working on a better mac based tool for my own use though.
"Whenever you find you are on the side of the majority, it is time to pause and reflect" --Mark Twain
"The significant problems we face cannot be solved at the same level of thinking we were at when we created them." --Albert Einstein
"This is still a dangerous world. It's a world of madmen and uncertainty and potential mental losses." --George W. Bush
|
Post #211,573
6/17/05 3:04:16 PM
6/17/05 4:23:00 PM
|
There is a reason that Excel is good for managing projects
[link|http://www.joelonsoftware.com/articles/fog0000000245.html|One of the reasons that Excel is such a great product for working on software schedules is that the only thing most Excel programmers use Excel for is maintaining their software schedules!]
Cheers,
Ben
I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
Edited by ben_tilly
June 17, 2005, 04:23:00 PM EDT
|
Post #211,580
6/17/05 3:20:40 PM
6/17/05 4:59:50 PM
|
...
|
Post #211,489
6/16/05 9:49:29 PM
|
I'd used Request Tracker for a while.
[link|http://unix.freshmeat.net/projects/requesttracker/|http://unix.freshmea...s/requesttracker/]
It's written in Perl and you can customise it to an insane degree, depending on your Perl skills :-). Notably, it's very well-structured code so even I could do things to it. Apparantly, it can be a bugger to install, though.
One thing: we noticed that a trouble-ticket system and a feature-request system can sometimes have different and conflicting needs. For a while we left bugs in RT and ran a white-board for feature requests, but over time we found we could put tasks in RT, too, and that worked quite well.
Wade.
Save Fintlewoodlewix
|
Post #211,511
6/17/05 9:35:28 AM
6/17/05 9:39:36 AM
|
We're having that discussion at work
Or more accurately we've already had it, but a few people haven't fully come around to the obvious rightness of my conclusion yet. Bottom line is I don't draw a distinction between bugs and feature requests. As far as the user is concerned, the application doesn't do what he wants it to do. We need to know that. All that's left is to decide if we're ever going to make it do what the user wants, and when that's going to happen.
Once you've bought into this idea, having different systems for tracking
bugs and feature requests seems really counter-productive.
As for estimated completion dates, I take the view that you estimate how long it will take to do, then you schedule a completion date. If the developer misses it, he learns to estimate better.
[edit]
Caveat: This assumes you have some control over who is allowed to submit bugs to the system. If you're talking about open submission from an audience of potentially hundreds of users, then yes, you need something separate like Bugzilla. And someone whose job it is to pore through that list and filter out the duplicates.
===
Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
Edited by drewk
June 17, 2005, 09:39:36 AM EDT
|
Post #211,526
6/17/05 10:43:43 AM
|
ICLRPD (new thread)
Created as new thread #211525 titled [link|/forums/render/content/show?contentid=211525|ICLRPD]
--
Steve
|
Post #211,722
6/20/05 2:17:04 AM
6/20/05 2:21:27 AM
|
Generalization, Abstraction, Taxonomy, Perspective, Opinions
Well, bugs and features have a lot a common.
Like dogs and men.
Bugs are trackable, Feautures are trackable
Dogs have legs , men have legs
Bugs are introduced into software by programmers, Feautures are introduced into software by programmers
Dogs have teeth, men have teeth
Anyway, you got my point ...
A bug is a behavior that you want to remove, a feature is behavior you want added
but from many perspective what you can do with them is the same
We can track bugs and features the same way, and yes a smart programmer would use hard learned object oriented concepts like absraction and polymorphism to write a piece of software that would track -trackable work related to software products- and offer extensions that support specialized -trackable work related to software products
But, I also think it is not always practical to generalize every problem you try to solve, or better said not too far generalize, else you can always end up with a general purpose programming language! or Perl 6.
A good bug tracking system is one that is crafter for the special requirement of bugs even if they are minorly different from features.
A good programming environment or framework, will allow you to share code between similar systems, and extend/specialize where neccessary
Edited by systems
June 20, 2005, 02:21:27 AM EDT
|
Post #211,744
6/20/05 12:16:32 PM
|
Feature requests are classified as requests to add bugs
Since adding new features will generally introduce more bugs into the software. :-)
Bugs are stuff that should be addressed as the software does not meet the specification. Features are attempts to change the specification. Bugs should be immediately addressed. Features have to be pruned because, as a general rule, the end users want the software to do everything possible (and many things that are not computably possible).
|
Post #211,753
6/20/05 12:35:08 PM
|
Problem is, the users know that
Which is why they will work as hard as possible to classify everything they bring up as a bug. "It doesn't work right." But it does exactly what you asked for. "But it doesn't work right ... and it's affecting our productivity." Right, so you should have asked for the right thing to start with. "But it doesn't work right ... [cc: CEO, CFO] ... and it's having an immediate negative impact on profitability." Oh, you mean it doesn't work right? I'll get right on that.
===
Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
|
Post #211,755
6/20/05 12:45:09 PM
|
Customers will call on every person in the company...
...until they get the answer they want to hear.
|
Post #211,773
6/20/05 2:18:25 PM
|
Like I do for Comcast?
--
[link|mailto:greg@gregfolkert.net|greg],
[link|http://www.iwethey.org/ed_curry|REMEMBER ED CURRY!] @ iwethey
[image|http://www.danasoft.com/vipersig.jpg||||]
|
Post #211,831
6/20/05 9:30:36 PM
|
That's when you hold up the spec doc.
And say "That's not what you asked for. What you're asking for is additional development and subject to normal scheduling concerns." :-) Of course, when they start imploding, you can gently remind them that they are free to prioritise any development they want in before any amount of bugs they have submitted.
Back at the place we were using RT, we did that once or twice. Taught them to check what they asked for before saying 'it doesn't work right'.
Wade.
Save Fintlewoodlewix
|
Post #211,856
6/20/05 10:37:53 PM
|
The what doc?
There are some process problems that can't be solved with better tools. I'd say most of them, actually.
===
Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
|
Post #211,528
6/17/05 10:45:47 AM
|
Years and years ago...
...back in 2001, I used Double-Choco-Latte at a job. Free, integrates with multiple databases on the back-end. On Debian, it's as simple as apt-get install dcl. Back in the day, it was written in PHP. No idea what it's doing these days. It was über-configurable as well, provided you had some skill with PHP (and it also had an admin section whereby you could do some basic and even intermediate configuration without knowing PHP.)
-YendorMike
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
- Benjamin Franklin, 1759 Historical Review of Pennsylvania
|
Post #211,725
6/20/05 3:00:40 AM
|
Trac is working quite well for CherryPy
How "open" does it need to be? I also find FogBugz to be O.K. for internal projects.
|
Post #211,728
6/20/05 4:50:30 AM
|
Re: Trac is working quite well for CherryPy
I like their issue abstraction [link|http://projects.edgewall.com/trac|http://projects.edgewall.com/trac]
|
Post #211,740
6/20/05 11:31:42 AM
|
Working on Trac install now
Well, between other tasks, I'm slowly working on it. FogBugz looks interesting, but I can't justify $129/seat. There are things I like better about Trac, including open source Python, integration with Subversion, and built-in Wiki.
The problem right now is getting it to work with Python 2.4; apparently, the Subversion 2.4 Python bindings haven't been done yet, so I'll have to compile them myself. I won't go back to Python 2.3.
Tony
|
Post #211,893
6/21/05 9:22:56 AM
|
Box of Notecards
(1) Write bug/feature on card.
(2) Add estimate of effort to implement or fix.
(3) Sort in priority order (collaborate with the user here)
(4) Take card off the top and work on it. When complete, remove it from the stack.
There are some compatibility issues.
I like the 4x6 size cards. My friend says that you can write too much on a 4x6 card and prefers the 3x5 size. I sometimes work with a guy who likes the really big 5x7 cards ... but that's just wrong.
--
-- Jim Weirich jim@weirichhouse.org [link|http://onestepback.org|http://onestepback.org]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #211,905
6/21/05 10:41:17 AM
|
3x5 rule[dz]! :-)
|
Post #211,921
6/21/05 11:28:26 AM
|
That's close enough to what I do now
but I'm interested in keeping a history, so we can see when a problem was fixed (so link to SCM is good) long after our short term memory has faded.
If a problem is solved by procedure, I'd like to note that somewhere shared for everyone, because too many times I've come across "Someone had that problem a couple of years ago. Now what did we do to fix it?"
Tony
|
Post #211,957
6/21/05 3:38:20 PM
|
History-keeping tools: Hole punch and ring binders. HTH! :-)
|
Post #211,941
6/21/05 1:22:47 PM
|
I use the 8x10s.
But not for notes. For Airplanes, they work really well if done right, to use a rubber band to launch them. Pretty acurate.
--
[link|mailto:greg@gregfolkert.net|greg],
[link|http://www.iwethey.org/ed_curry|REMEMBER ED CURRY!] @ iwethey
[image|http://www.danasoft.com/vipersig.jpg||||]
|
