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/
I found that I wanted to use a lifecycle for developing my OSS side projects similar to what I used for my job. It's a pain to setup but I use a stack of bugzilla for tracking, hudson for continuous integration, maven for the project management, sonar for static code analysis and mercurial to not only control revisions but to move projects and artifacts around. Bugzilla is, unfortunately, far and away the clunkiest piece of the puzzle, but I haven't seen anything capable that was easier to work with (and the fact that it's got plugins for all of the other pieces makes integration of the stack pretty easy.
I hope others post good ideas here, I'll be keeping an eye out, but for me right now Bugzilla is the tool of choice.
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.
If I am aware of a bug as I am writing my code that I do not resolve immediately, I place a comment in the code with a searchable string such as /* ***BUG*** ... and a full description of the problem and why I chose to come back to it rather than fix it on the spot. Then before I make any release builds, the search string must not appear in any files in the project.
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.
There are lots of project hosting websites such as github and indefero which privite bug trackers, among other things. Public projects are usually free, but private ones will usually cost you a monthly fee.
Just use some version control/revision control/source control software you prefer (git, mercurial, svn, whatever) and keep a todo.txt in it ..
If this was something where other people were telling you at arbitrary times that "I found a bug" and you didn't want to bother with it until later, that's one thing. If you're using your own code and it isn't working, you can either fix it now and use it now, or write down there was a bug and not be able to use your own code.
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've built a custom bug / ticket tracker using this: http://buildadatabaseapp.com/
...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?
I like Asana. We have been using it some small work projects and it meets our needs. Simple, free, and basic. I have used it for a couple of small personal projects as well.
Go to http://www.fossil-scm.org/. It's a distributed version control system, bug tracker and wiki (and does Julian Fries...) Not good for large (many user) projects but great for your personal stuff. See http://www.fossil-scm.org/schimpf-book/index for a book about it. Nice part it's a single executable and the repository is a single file. Started by D.Richard Hipp (Squilte)
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.
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 fix the bugs, then I don't have to remember them.
Alternatively I have heard of this marvelous invention called a text editor that can create and edit files containing text.
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.
I find a paper steno pad works well. Simple, easy to use, and less Carpel tunnel stress from typing is always good.
Bugs.txt is great, or alternatively give Tomboy (or any other post-it note software) a shot. There's Windows and Mac builds of Tomboy available too:
http://projects.gnome.org/tomboy/
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
Check out the same products you use for commercial projects; these days they often include a free single user license - perfect for the @Home projects.
Personally I have a MySQL db running on my home server. It allows me to have both bugzilla and mediawiki for my projects.
Bugzilla integrates effortlessly with Eclipse and other IDEs.
If you want this for OSX in an easy way:
1. Install VirtualBox
2. Setup a Ubuntu LTS server as a VM
3. Install mediawiki (it will install and setup mysql for you)
4. Install bugzilla (it will ask for db credentials as far as I remember)
5. If you like, install git, subversion, mercurial etc.
I used to have those todo.txt files together with the source code but it really can not compete with a proper setup.
If you go for the VM solution, you can also do backup of the whole dev server.
AC
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.
I have created some decently sized projects before (hundreds of thousands of lines of code) and have never had so many bugs that I couldn't remember them. Like everyone I do get bugs occasionally but never so many that I can't fix them right away.
Most people just don't know how to write good software so they end up with hundreds or thousands of bugs that take forever to go through. That is poorly written software right there.
Free, allows bug reporting from third parties and provide release information ... and on the cloud!
Excel, (or OpenOffice Calc)
Can sort, filter, re-prioritize, write comments
What more do you need?
It's easy - I don't write bugs.
this /. entry in my feed reader :)
What's new
My personal projects don't have bugs, they have extra added bonus features!
Agreed. We have multiple uses for it - including bug and feature tracking. Love it to bits
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
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.
I'm not running a zoo. I don't track 'em, I kill 'em.
http://www.componentsoftware.com/Products/RCS/index.htm
The Basic Edition is Still free for a single Developer
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.
use a simple database with form builder. Using Bento for the iPad, I created a single database with 5 fields:
date (entry date)
status (wishlist, active bug, resolved bug, rejected bug)
picture ( an image of the bug happening)
description (free form text field)
note (free form text field)
No server, no web setup, no hosted solution. Perfect for my personal projects. And if I ever need the data out of it, its a database with export.
A bug tracker is a specialized database with a GUI front end. For personal or even small teams, a simple database application with form builder can solve the problem for you.
EDIT: YES I had to pay for the Bento database, but I use it for other database needs as well.
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!
http://bitnami.org/stack/redmine/
I've been using it for a couple of years, and am happy with it.
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.
All you need is a way to take notes really quickly.
* todo.sh
* spreadsheet
* redmine server
* trac
* github
Seriously, most online code repos provide a bug tracking facility.
Or you could just start with a better design effort and prevent the bugs BEFORE they become code errors.
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.
Have a notebook stack for the project, under that have notebooks
Completed Tasks, Bugs, Enhancements...
drag and drop from completed to enhancements
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
What version control system do you use?
1. No version control. Then I recommend using a text file or an online spreadsheet (e.g. Google Docs or ZOHO) to track your bugs, feature requests, etc.
2. Subversion.
a. If possible, move your project to Google Code hosting, which includes a very useful bug tracking system, nicely integrated with the version control - and you can keep using your Subversion tools on your development machine.
b. Alternatively, move your project to Trak.
3. Perforce. Well, then you already have the built-in "Jobs" system for tracking "defects". Works pretty well, and if you need more, it will integrate with external bug tracking systems.
List of bug and feature tracking solutions I'd recommend:
A. Text file.
B. Online spreadsheet (Google Docs, ZOHO). If you want, you can create a web form with defined fields for adding new issues, and if at some point you have other users or developers, they can use that form to report bugs.
C. Google Code for version control and bug tracking.
D. Trak, for version control and bug tracking.
E. Perforce for version control and (lightweight) bug tracking.
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)
Just move the software development to Soviet Russia, and bugs will track you!
Use unfuddle or github. If you don't want that, use a text file or sqlite from the command line.
You could get really advanced and write a shell script using dialog or something.
I used Flyspray http://flyspray.org on our last game with a team of a dozen, and it worked well. Free, web based (hosted on your own server), most traditional functionality you want in a bug tracker.
I track project development in a spreadsheet, so when I'm doing solo development I just track bugs in that same spreadsheet. The bug tracker is only really necessary if you're communicating with other developers/testers.
JetBrains YouTrack is really nice. Free for individuals/small teams. Very feature rich. Very keyboard friendly.
Given there's an error in that script, it seems rather unlikely that that's the one you use.
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.
Simple to setup, easy to learn, like Markdown it can be treated as a simple text file, and is really useful:
http://orgmode.org/
Excel file (or any other spreadsheet) or, for really simple and small projects, a piece of paper.
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)
It does not always work but it is called Feature Tracker.
//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 ).
/me grumbles about invisible characters copied and pasted
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
I have found the easiest solution is simply to not write any bugs in the first place. After all you do control the source code so why include the bugs? Problem solved.
I've been using Atlassian JIRA for all my personal projects for a short while now and it's awesome. Before it I tried Trac and Redmine but they didn't quite cut it. Besides JIRA is also used in my workplace so I'm pretty familiar with it (after using it for more than a year at workplace). It's also pretty cheap for personal use ($10) and cost free if you're doing FOSS development.
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.
If you happen to be using hg, maybe one of these:
b - http://www.digitalgemstones.com/projects/b/
bugs everywhere - http://bugseverywhere.org/
The best way, is to comment in the code itself what the bugs are and what to rectify, but that doesn't work for all bugs (especially long term things that you may or may not get around to).
Next to that, keep the bugs listed in local text documents, but these can build up pretty quickly.
After that (and this is against what you were looking for, but will suggest regardless as it's very easy to setup) you can setup something like Trac, which is an extremely easy to setup and use bug tracking system, that you can also use to collaborate with other people (it also has an inbuilt Wiki, which is very handy for documentation and other dev notes).
The only additional point, is to make sure to include all of your bug tracking with your regular backup routine, along with your source (even better if you automate the backup to run once a day).
I am wary of cloud based services, where you may unexpectedly lose access due to downtimes etc. which can totally screw up your workflow; from my point of you, you really want full personal control of your bug tracking and source control systems.
And for the love of god not Jira.
200 comments and no one has mentioned Best Practical Request Tracker 3?
http://bestpractical.com/rt/
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."