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?"
Been using Mantis for years, easy to install, easy to setup, easy to manage.
They have a free plan - http://lighthouseapp.com/
check it in with your code, add and remove bugs as needed. 5 seconds of setup. Search and has a history.
Try Trello, it is simple enough to use, free and cloud based.
https://trello.com/
After every bug in my project you post a press release, discrediting the person who found the bug as some subversive agent, and explaining its uses of the bug in a positive light.
After the press release is done, I like to go into a dark room with a rocking chair, plug my ears and go LA LA LA really loudly until someone else says there is an other bug.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
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.
Find a dead project online, and hijack their bug tracker. Just as long as it's one where you can register without authorization and close your own bugs it should work brilliantly.
I am not associated with them, nor employed by them. But I've used them for many projects now and been generally happy with the result.
How about JIRA? Used by Enterprises all over the place. You can get it OnDemand from Atlassian for $10 (which is actually just a donation to Room to Read). Check out http://www.atlassian.com/software/jira/overview
JIRA: http://www.atlassian.com/software/jira/overview
$10/yr to setup your own or $10/month for hosted. I run it in an Ubuntu Server Virtual Machine. Since 5.x, setup is simple running the installer script as root. Getting PostgreSQL going was probably no more then a dozen commands that could be followed straight from their site.
github: https://github.com/features/projects/issues
They have an issue tracker that I image you could use without actually uploading any code. It is free if you don't mind your issues being public, or $7/mo for up to 5 private repositories.
I find it easier not to put bugs in my code.
Have gnu, will travel.
I like a lot bugzilla. Better than mantis and trac.
Just use some version control/revision control/source control software you prefer (git, mercurial, svn, whatever) and keep a todo.txt in it ..
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
If they are actual bugs, just fix them as soon as you can... Add some TODO flags where you think they are happening, add more asserts and unit tests.. set breakpoints, recreate, fix, comment and test.. Avoid putting something into another todo list if it can be fixed right away. Most bugs I run into are simple NPE's, copy and paste bugs (where similar code is copied but incorrectly modified).. and logic bugs... Few bugs are so complicated I need to write out a long description of the problem before tackling it..
More consideration should go into adding features...
When I need to set up a self-hosted project and bug tracker, I normally use Redmine, which is very easy to use. It's written with Ruby on Rails, and so should be relatively easy to get a local SQLite-backed copy running on Mac OS using Rails' built-in mini web server.
This post is overly complicated but some of its information may be useful:
http://www.redmine.org/boards/2/topics/2768
Just create a dummy SourceForce project. You don't actually have to attached any source files to use the bug tracker or other features.
Fossil (http://www.fossil-scm.org) is just great: it allows you to manage your code, documentation (wiki) and tickets (bugs).
It's really small and lightweight, offers its own web interface and can be made to run on a central server with a CGI script. Oh, and it's free and open-source.
It also scales very well: for instance the entire NetBSD code base has fossil repositories.
I am currently re-starting some personal projects and I will be using fossil almost exclusively for these. It's simply fantastic.
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
We use https://www.fogbugz.com/ and have been happy with it. It has more features than you'll need to a small project. They have free versions for single users.
-- Best Greetings Cards Ever
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
I tend to fix a bug as soon as I find it. That solves the problem of tracking them.
...I prefer to list out stuff like that in a journal using pen/paper.
I get a great personal satisfaction drawing a line through fixed bugs over just deleting a line of text or checking a box.
What do I know, I'm just an idiot, right?
How about Stickies?
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.
For what it's worth, there are issue trackers offered alongside even the free levels of both github and bitbucket.org (which lets you use both git and hg). Bitbucket's free tier even lets you have a private repo if your source needs to be private (issue tracking and wiki instantiation are configurable via admin there, and should be offered as part of project repo creation). This way you get source control for your personal work as well as an issue tracker. ;)
I vaguely recall that Sourceforge also has some sort of bug tracker as well, if you'd rather use cvs/svn. (It's been a long time since I looked in that level of detail at SF though, so ymmv.)
All of these are "cloud" (blech) solutions that don't require any server setup on your part. If you aren't familiar with source control, that's kind of another matter, but there are quality GUI clients for OSX for most of the common protocols and cvs, svn, git, and hg all have reasonably good documentation publicly available in various forms.
News for Geeks in Austin, TX
There are no bugs in personal software projects. If something doesn't work, it gets fixed. you don't need anything to remind you that something you want to work doesn't. It's only the other people who try to use my software that find bugs, if you are making software for other people, it isn't really a personal project anymore, it's a product.
Effective bug tracking is a useful and valuable skill to have, and for a small/personal project it's pretty good practice because of the relatively low complexity and time commitment needed.
Plus, big projects can start as small ones, and even a personal project can someday include other users as they expand.
LegendMUD
As some of my personal projects have gotten bigger, the standard TODO file became cumbersome to manage. I've recently been working with Taskwarrior an open source command line task management tool that can act as a simple todo manager, but also includes advanced features like projects, tags, filter-able queries -- all from the command line.
For public free software projects, there are plenty of cloud based VCS and issue tracker; google code, github, indefero and bitbucket come to mind.
Otherwise, for private projects you may wish to have a look at the turnkey linux images for project tracking
http://www.turnkeylinux.org/project-management
I see they have redmine and trac images. It hardly gets easier to set up than an turnkey vm image!
I'm confused. You actually keep track of problems with your personal projects in the hopes of completing them one day?
I must be doing it wrong because I start a project and as soon as i get to the first major design issue, or meal time, i quit.
so i don't really ever have any bugs, per se. but i do have an svn with a sh*tload of half ass projects that i can let you have real cheap.
"Oh, you hate your job? There's a support group for that, it's called everyone, they meet at the bar."
I file mine in my todo.txt, which also includes missing features. Since I don't do a release if there are *any* known outstanding bugs, "bugs" and "incomplete features" are essentially the same for me.
I also log every bug fixed into changelog.txt, which gives a nice history.
TortoiseSVN is easy enough to setup to run without a server locally and works great.
http://www.turnkeylinux.org/redmine Seriously. I had an issue tracker running in 5 minutes. By 15 minutes I had the settings the way I wanted it. They ship you a virtual machine image. You load it into VirtualBox and click start. The VM loads to a little screen that tells you what IP address the redmine is running at. It also has git i installed, and it was super quick to migrate my git repo into it. Since I use redmine with git, it's really handy because they are already integrated - when I put "refs #32" in my git commit message, it appears on ticket #32.
If it's just me developing. No testers and no current user base--purely personal:
Pencil and paper.
"So don't get programmed by anybody but yourself" --Bill S. Preston, Esquire
I've always just use a spreadsheet to track my personal projects. (Excel, Google Docs, OpenOffice).
But since you didn't list much for requirements, I'm not sure if something like that would work for you.
If you need reporting tools, and the ability to allow users to enter in their own tickets... then obviously a spreadsheet would be next to useless.
Use Bitbucket.org. Free source control, wiki, and bug tracker.
Free Public and Private repositories.
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.
I don't let enough bugs build up that writing them down would make sense. Although my personal projects are generally small.
"When information is power, privacy is freedom" - Jah-Wren Ryel
My project isn't huge (less than 9,000 lines of C). When I find bugs, I jot down a short summary of the issue, then when time permits, I append enough text (mostly copying and pasting) to a "FixThis" file so I can reproduce the problem later.
When I fix a problem, I *always* document the fix at the top of the appropriate source code file.
All of the above are simple, clean, and efficient and have worked well for me.
Circle the wagons and fire inward. Entropy increases without bounds.
You're going to have to fix the bug anyway, why not just do it when it is fresh in your mind and keeping you from using the code anyway?
What if those things aren't true? What if you're using your program, discover some edge case with a bug, and don't have time or it's not worth it to fix right away?
Knowing how code is structured doesn't automatically mean you know where bugs are. In addition, non-deterministic code occurs on a regular basis in several fields (bioinformatics, MLAs, NLP, so on).
Having a personal project doesn't mean you don't have contributors - It means that you are the only main contributor. You may still receive translations or patches from users or enthusiasts occasionally. In addition, having a public bug tracker helps your users know what to expect when they use your product.
Depends where your code is. If it's hosted on GitHub, they have a simple but decent issue tracker that integrates really well with code commits.
Take a look at DoneDone (http://www.getdonedone.com/), they offer a free plan with 3 active users, unlimited projects, and 1GB of storage. I use it professionally and love it.
Those who know, do not speak. Those who speak, do not know. ~Lao Tzu
For my projects, I will typically fix things I find as I find them. Where I use a bug/issue tracker is for bigger things like tracking planned features for a roadmap -- things that will take longer to develop.
You could also have a problem near a release that is not critical, but you need to remember to fix it later on, or a defect that can only be fixed with an architectural change.
A bug tracking system is also useful for other people to report issues or feature requests they find to you/the developers -- things you are not necessarily aware of. This could also be extended to handle support issues for the application that are not necessarily bugs.
For other things -- like document format standard support -- I track them by using CSV files in the codebase that enumerate the sections in the standard and include the release in which they are implemented. Different versions of the standard get their own CSV file, with a high-level implementation CSV file for the standard across versions. I then use those to generate HTML implementation status pages.
http://www.tfspreview.com/
Been using it in beta for a lil while now (granted from the PC)... and they say that even after it leaves the preview stage, there will be a free version: http://tfspreview.com/en-us/pricing/information/
Help Brendan pay off his student loans
I wrote a tool for my school capstone project called eLogger, its a C based program which plugs into a GTK interface and you can log what ever you need to through it. On the backend is a wiki style page that has all the log files sorted and captures by date to the second. It's searchable, extendible and connects nicely with mysql. I've been using it for 8 months now and it's worked out great. If the school will let me I will send it to you, but you could also write your own, this one took me two weeks to write.
For personal projects (involving just me):
if it is fixable immediately and simply, I fix immediately.
Otherwise it goes to pencil & paper, any leftovers at the end of the coding session go to TODO.txt.
Does one even care if its cloud based or not? Thoughts anyone?
It seems that your first project should have been to develop a bug tracker.
Emac's org-mode system is fantastic for things like this. It has TODO tracking with scheduling, etc, and you can put one file in each project or one global file for just you, or ... Your choice!
The next site to slashdot will be ready soon, but subscribers can beat the rush and start slashdotting it early!
The best and easiest way to deal with bugs is to not have them in the first place. Build quality in. This means you need to read two books at a minimum: "Refactoring" by Martin Fowler and "Test Driven Development by Example" by Kent Beck. If you properly understand and apply the techniques in those books your defect rates should quickly drop to manageable levels: less than one new bug per month and an average fix time for bugs of far faster than that (e.g. 2 hours). Most programming languages/platforms have appropriate test frameworks. Here's a good list of unit testing frameworks that are compatible with the techniques in these books: http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks.
Helping with organizational effectiveness is our job.
Now, ask me how I track unintended features for personal software projects.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
What if you're using your program, discover some edge case with a bug, and don't have time or it's not worth it to fix right away?
Then document it as a known issue in the program, and if a user is affected, tough. CronoCloud keeps telling me that some edge cases are not worth serving.
It may sound flip, but don't write bugs into your code. And why waste time tracking bugs when you could be spending that time fixing bugs.
Bugs in the bug tracking system. Oy. Fire these programmers immediately.
You should have a fast write / compile / test cycle. Three functions. Three screens.
Write a chunk, test a chunk. Write a chunk test a chunk. Every 20 - 40 minutes you should have another chunk complete and tested. Your program should always run and build. Turn on maximum warnings on the compilers. Compile on multiple platforms with multiple compilers. Test on a second platform at least once every couple of days. Mozilla, IE and Opera. It should always run on all of them.
After you finish coding a chunk, proof read it from top to bottom. If you can go a whole day without a single compiler error or warning, you are in the zone. You are a master of the universe. It can be done.
Don't write tricky code. The code should be neat, clean, simple. Well spaced, brightly light, with the floor swept. Hazardous areas marked, and appropriate safety gear nearby with all staff recently trained in it's use.
Every function that throws an error must be checked for an error and print a big fat message as to where the error occurred and what the important values are and errno and strerror(errno). No exceptions. Ever. Not even for you.
When you test, all code paths must be tested. Otherwise, you are not done. You are a slacker not a God.
If you cannot understand the code after 4 beers, with a cold and no sleep, it is too complicated. Rewrite.
If you cannot test the code thoroughly and easily, rewrite it. Don't be clever.
Test all inputs, even if inputs are editted before being passed in. And print out massive error messages if the input is not correct. Later when you do mods and upgrades, you will find errors immediately, rather than go WTF and spend half a day.
Don't leave shit for 'later' or 'somebody else' or 'the community'. You wrote the bomb so you put in the safety gear, now.
if (debug) {} is your friend. Build it in from the start, if you know that the chunk is going to be nasty to get running.
At the end of every day, your code should compile, your product should run.
Shit happens and it might be a week before you get back to it. By that time your working memory will be gone. That shit you left for later will be forgotten.
Just don't write bugs. You can be that good. Aspire to that.
Not hard to setup a trac server on top of svn (or several other source control systems). I have done this in the past at home.
I have also used a .txt file, comments in main.h, and/or TODO:s in the code.
Low cost, easy to setup, will never crash.
Undetectable Steganography? Yep, there's an app fo
I have used, in the past, Teamatic (http://www.teamatic.com) and http://www.elementool.com/ - their offering may have changed in the last few years so check exactly what you can do for "free".
Also: http://stackoverflow.com/questions/966404/does-anyone-know-of-a-decent-free-online-bug-tracker-for-web-development-purpose
(sound of crickets chirping)
Sounds like M$ Office.
Why is it that most of the people that I encounter seem to have been shat from the Sphincter of Mediocrity?
if you like commandline-tools and the git workflow, try ditz. It does not need git or a VCS, but it can profit from it, when working with a (small) team.
Depending on which IDE you're using, you may already have that functionality. Netbeans, for example, has a "Tasks" tab which will show you all your commented notes that start with "TODO:" or "FIXME:" within your code. It obviates the need for a formal bug tracking system if your objective is to make simple notes about what doesn't work, and to keep those notes attached to the broken code.
There are many open source project management projects out there with various solutions. Check them out.
Custom electronics and digital signage for your business: www.evcircuits.com
But in my case "bugs" usually are just desired features. The couple users I have internally at work just will say "yeah but I really think it should be this way". Basically it goes into the email cloud. If it is easy and gets done before it gets buried by other email than it gets done. If not unless I hear about it again or have nothing better to do I assume it isn't important and don't bother with it. Basically it is prioritization by liberal use of the squeaky wheel method.
Chuck Norris doesn't need to debug, he stares down the source code until it confesses.
Knowing how code is structured doesn't automatically mean you know where bugs are.
Didn't say it did. Nothing is automatic. But it does mean you should know the coding style and how the program is organized. You should know the data flow and the processing steps. If you see something wrong, you should have a better idea of where to look than anyone else does.
Having a personal project doesn't mean you don't have contributors - It means that you are the only main contributor.
Oh, sorry. That's a different meaning for the word "personal" than we use on planet Earth.
In addition, having a public bug tracker helps your users know what to expect when they use your product.
Which means it isn't a personal project anymore. Perhaps you're thinking of "hobby"? You can program a publicly usable project as a hobby in your personal time, but that's different than a personal project. You can turn a personal project into a public one, but then it's not a personal project anymore.
Simple to setup, easy to learn, like Markdown it can be treated as a simple text file, and is really useful:
http://orgmode.org/
TiddlyWiki and unit tests.
For plain bugs such as "seg fault when doing x" I just write a test exposing the bug. This way, I won't forget about a bug even if I don't touch the program in six months. It will appear again as soon as I run the full test suite.
For more complex bugs such as design flaws, bugs from user interaction etc I keep them in my to do list in a TiddlyWiki.
TiddlyWiki is the perfect documentation/note taking tool for projects with a single developer since the entire wiki is in a single self contained html file. Therefore, it requires no installation of any software (except a browser) and you can just keep it with your sources and commit it to your repository for safe keeping.
I keep all notes related to the project, ideas, design notes, to do lists, bugs etc in it. I prefer it to plain text because it's so much easier to keep it neat and somewhat structured without being a pain to use. The ToDo list is the most important item since I never know if I will continue programming tomorrow or in six months and need to be reminded of what should be done. Bugs end up in the ToDo list since they are things that should be done just like "Redesign the crappy back end". When one item (feature/bug/whatever) gets too long, I move it to a separate tiddler (like RedesignCrappyBackEnd) and just link to it which keeps the main ToDo list clean.
When I'm finished with a bug or feature, I move it from the todo list to a "Done" list. In this way, I can keep a simple log of bugs, features and what's been done recently. This can be very handy if you suddenly remember you had a similar problem before but can't remember what it was or how you solved it.
The main drawback is that you can't/shouldn't use it for projects with 2+ developers since it handles simultaneous edits just as bad or worse than a plain text file.
I think it provides the most bang for the buck being almost as simple as a text file but much more structured. I have tried some more sofisticated tools but always come back to TiddlyWiki because of its plain simplicity.
(Actually, I use the MPTW clone which has better tagging)
//TODO -- fix fix this
grep TODO *.c
This is enough for the cathedral, which doesn't even have source control. Anything sold in the bazaar should have source control and some kind of bug tracking. Just pick whatever integrates well with the repository. Free sites will probably have a "most popular" bug tracking or integrated tracking. Just use it. A company will impose something. Use that, duh!
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
I for myself do use Kissspm ( http://94.23.17.120/projects/kissspm ).
I generally think of mantis to be a less clunky bugzilla.
Thanks for the tip! I want to improve my vim skills so that basically it doesn't matter to me which one (vim or emacs) I use. Now, I use vim mainly for quick edits on server(s) and emacs for coding.
Perl Programmer for hire
You could abuse them a bit, start a project and use the bugtracker. If you don't want to share the code - don't commit it there.
Seriously. For my latest project, I've been using 3x5 index cards, and I'm OK with it. Sure, it's not web-based, but it seems to be working OK.
My evolution of personal bug tracking: first, I used a text file. What I didn't like about that was that I couldn't sort it. So, I moved to a spreadsheet. I really liked that. But, it's probably my CVS background, but I'm still uncomfortable checking in non-text documents into a version control system. I guess I could save it as a CSV to get around that uncomfortableness. But, now I've started using 3x5 index cards.
Index cards are nice and small, easy to transport (if you don't have too many bugs), and easy to sort. When I find a bug or think up a new feature, I just write out an index card and stick it in the appropriate place in the pile. I keep mine sorted by priority, and they are very easy to re-arrange. And for version control, I just keep around the cards that I've completed in a separate pile.
I would NOT want to do this for a large project, but for a personal project, it's working great so far.
You could take a look at some of the options: http://www.thegeekstuff.com/2010/08/bug-tracking-system/ source: google
What's the point of using a VM?
So you want to backup your git repo along with the rest of your homedir. Now you have to backup a huge binary file that contains stuff that never needs to be backed up?
So you want to access your git repo. You have to wait for a VM to start?
So you upgrade your kernel and some module like a VirtualBox one doesn't get rebuilt right by DKMS. You can't access your repo because your VM won't start?
What is the point? Why use a VM for the sake of using a VM? Why don't you run every app in a VM?
"Those who consume the bulk of goods are those who make them. We must never forget this secret of our prosperity."
What's with the IP address?
"Those who consume the bulk of goods are those who make them. We must never forget this secret of our prosperity."