Slashdot Mirror
Ask Slashdot: How Do You Track Bugs For Personal Software Projects?
An anonymous reader writes "One of my personal software projects grows bigger than I thought and the bugs becomes too many to just remember. I looked around for an open source bugs tracking system but found no ideal solutions. Ideally I wanted a simple system that does not need server setup and extra database setup, and can run under Mac OS X. Another option is a cloud service if it's affordable enough. Any suggestions from Slashdot?"
check it in with your code, add and remove bugs as needed. 5 seconds of setup. Search and has a history.
I've got a few hundreds megs of perl code. I've got five text files of bugs / planned features / quirks.
Not sure what features of a bug tracking system you seek. I need the file name, the function name, and a description. Text files are great, and far more portable and accessible than a spreadsheet.
But I've never been one to like "proper" bug tracking systems. Of course, I'm not working with dozens of other developers.
You say explicitly this is a personal project. That is why bug trackers aren't going to fit very well. Bug trackers are for teams of people to coordinate their efforts. They are mostly pointless if you're working alone.
Just put your ideas, plans, comments, and bug notes right into the source. Most IDEs will let you easily flag sections so they stand out when desired, for instance Eclipse has the TODO: tag for exactly this purpose.
Now your notes are seen every time you work on that section of code, and they benefit from versioning right along with the rest of the code (assuming you are using some sort of source control).
-Lod
Why bother with hijacking someone else system when you can just make a SourceForge project?
Okay, first I'm not given a lot of info about what you are trying to do, so I am forced to make assumptions. First, you are doing this part-time. Second, you have a small amount of users. Third, I assume these users either email you or tell you about problems in person. Fourth, you don't have any need to formally update people on statuses.
I have a great solution for you. It is called a spreadsheet. The positive is that is it free, easy to use and modify to suit your needs. No, it isn't flashy, but I find that folks tend to use software as a replacement for their own brain and creativity. I've used spreadsheets for a lot of different utilities from project management, to bug tracking to help desk support in small environments. Once the user base sees limitations, they can begin to see what they truly need and it helps immensely in determinng what the desired solution really is versus what the Microsoft shill^h^h^h^h^h consultant tells them they need.
So, yes, use a spreadsheet. Heck, in your case it really sounds like a text editor would meet your needs.
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
Seconded. I use Unfuddle and am really satisfied. The basic/free service is great for personal or small team use and if your needs grow, you can upgrade to various paid levels.
That works great - when you only have a few hundred lines of simple code. However, when you have 200k lines, a couple hundred different files, and some very complex functionality, you need a more complex system.
In addition, how do you manage multiple contributors? How do you deal with letting your users know when bugs are fixed? How do you deal with issues that only occur in a very small amount of edge cases?
It's one thing to fix some code you fat fingered or to clean up some API calls. It's an entirely different thing to fix bugs in 200k lines of non-deterministic code that runs on 3+ platforms.
Host your project on github or BitBucket, whatever. They all offer a bug tracker. Using an SCM allows to know when a bug has been introduced after writing the proper test.
Speaking of which, and even more importantly: WRITE THOSE F*CKING UNIT TESTS!
I cannot stress the last point enough. If you're introducing bugs in your releases, either you're not writing unit tests, or not writing the ones that count (aka the higher level ones), and not using every tool at your disposal to avoid bugs in the first place (test coverage, static analyzer, etc.). You should always strive for 100% test coverage and zero trivial bugs when releasing.