Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Bug Programming Software

Ask Slashdot: How Do You Track Bugs For Personal Software Projects? 221

Posted by timothy
from the when-bugzilla-is-a-monster dept.
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?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: How Do You Track Bugs For Personal Software Projects?

Comments Filter:
  • Mantis (Score:5, Informative)

    by Anonymous Coward on Thursday July 12, 2012 @11:38AM (#40629163)

    Been using Mantis for years, easy to install, easy to setup, easy to manage.

  • Lighthouse (Score:5, Informative)

    by Literaphile (927079) on Thursday July 12, 2012 @11:38AM (#40629175)
    They have a free plan - http://lighthouseapp.com/ [lighthouseapp.com]
    • I tried out Lighthouse when looking for a new bug tracking system and was pretty underwhelmed... IMO, it was functional, but lacked polish. We also tried using Trajectory for a while, but settled on DoneDone.
      • I've been a user (through work and also for personal projects) for about 5 years now - they do bring in improvements. It's got its deficiencies, like any system, but it's pretty good overall.
  • bugs.txt (Score:5, Insightful)

    by Anonymous Coward on Thursday July 12, 2012 @11:39AM (#40629185)

    check it in with your code, add and remove bugs as needed. 5 seconds of setup. Search and has a history.

    • Re:bugs.txt (Score:5, Interesting)

      by Rob Kaper (5960) on Thursday July 12, 2012 @12:02PM (#40629473) Homepage

      I wrote find-issues.sh, a script that extracts comments of a certain type within the code and then groups them by file. Downside: your code files change when you register a bug. Upside: when done right, your bug description is next to the code that needs fixing.

      Obviously won't work for distributed development, but for single-coder projects, it's really been useful to me.
      Note some assumptions and grep magic to exclude third-party files and other non-code files.

      #!/bin/sh

      LASTFILE=""
      egrep -ri "(WARNING|HACK|FIXME|TODO|BUG)" . | egrep -vi "(\.git|debug|/third-party|/locale|/prettify|doc/|/jquery-|lib/s3.php|/jwysiwyg/|^./(.*)\.(txt|conf|xml):(.*))" | while read LINE ; do
              FILE=`echo "${LINE}" | cut -d":" -f1`
              DATA=`echo "${LINE}" | cut -d":" -f2- | cut -d"/" -f3-`
              LEVEL=`echo "${DATA}" | cut -d":" -f1`
              COMMENT=`echo "${DATA}" | cut -d":" -f2-`

              if [ "x${LASTFILE}" != "x${FILE}" ]; then
                      if [ "x${LASTFILE}" != "x1" ]; then
                              echo
                      fi
                      printf "%s:\n" "${FILE}"
                      LASTFILE=${FILE}
              fi
              printf "%5s:%s\n" "${LEVEL}" "${COMMENT}"
      done

    • 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.

      • Re:todo.txt (Score:5, Funny)

        by NevarMore (248971) on Thursday July 12, 2012 @12:59PM (#40630189) Homepage Journal

        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.

        So you never release?

        • 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.

          So you never release?

          Or he's bad at finding bugs...

        • by gman003 (1693318)

          While it has been nearly a year since I released, that's mostly because I haven't touched the project in over eight months.

          Before that, I did actually manage a few releases. The "zero bugs" was never an issue - between the small size of the project, and the smaller size of the testing corps, there just weren't that many known but unresolved bugs.

          I should probably start working on that thing again...

        • Do you find that surprising?

          I think most hobby programmers never release the stuff they develop and even those that do only release ~ 20% at best

      • devtodo [swapoff.org] would be a natural improvement for this kind of setup.
      • //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!

    • by dgatwood (11270)

      I pretty much do the same thing, but the file is called TODO and does not live in the repository. It gets backed up when my machine gets backed up, which is good enough. I don't want to air my dirty laundry in the source tree. Especially with all the swearing about browser bugs.

    • by arkhan_jg (618674)

      Or clone your repo up to github and use the bug tracker there if you want a bit more structure. Free for open repositories.

  • Try Trello (Score:5, Interesting)

    by Anonymous Coward on Thursday July 12, 2012 @11:40AM (#40629199)

    Try Trello, it is simple enough to use, free and cloud based.

    https://trello.com/

  • by jellomizer (103300) on Thursday July 12, 2012 @11:43AM (#40629223)

    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.

    • by admdrew (782761)
      Exactly. s/bug/feature/g
    • Sounds like the Apple school of management. After years of screaming at them, MS just ignores people and release their Tuesday patches occasionally. Google is the search engine, so they can just hide complaints. That leaves Apple, who (and I could be wrong but it) appears to me to be one of the most litigious consumer electronics companies ever... at least in terms of going after their own customers and contributors.
    • by dgatwood (11270)

      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.

      Ah. So you work for a three-letter agency, then?

  • A text file (Score:4, Insightful)

    by holophrastic (221104) on Thursday July 12, 2012 @11:43AM (#40629227)

    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.

    • How do you triage your bugs?

  • by TheCycoONE (913189) on Thursday July 12, 2012 @11:43AM (#40629233)

    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.

  • Use unfuddle.com (Score:5, Informative)

    by Drake42 (4074) * on Thursday July 12, 2012 @11:44AM (#40629237) Homepage

    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.

  • JIRA (Score:3, Informative)

    by rveldpau (1765928) on Thursday July 12, 2012 @11:49AM (#40629287)
    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 [atlassian.com]
  • by LodCrappo (705968) on Thursday July 12, 2012 @11:51AM (#40629321) Homepage

    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).

    • Re: (Score:3, Informative)

      This isn't true at all.

      What happens when you have more bugs than you have time to fix? How do you choose which to work on first? How do you remember which ones lead to data loss, and which ones have a workaround? How do you remember how to reproduce each bug? How do you manage patches? How do you remember which patches are compatible with other patches? How do you track the number of reported occurrences of a bug so you can prioritize your fixes more intelligently?

      These things may be pointless in a small pr

      • by LodCrappo (705968) on Thursday July 12, 2012 @12:16PM (#40629637) Homepage

        > What happens when you have more bugs than you have time to fix?

        You put a quick note in with a TODO tag

        > How do you choose which to work on first?

        You switch to a view that shows all your TODO tags and take your pick

        > How do you remember which ones lead to data loss, and which ones have a workaround?

        You type those details into the TODO tag

        > How do you remember how to reproduce each bug?

        See above

        > How do you manage patches?

        diff on commit = patch. no big deal.

        > How do you remember which patches are compatible with other patches?

        whatever man, you are really reaching here. make all patches compatible with all others, or pay the price. this is a personal project.

        > How do you track the number of reported occurrences of a bug so you can prioritize your fixes more intelligently?

        again, simply add this type of detail to your TODO tag

        • Seconded. Though I'd prefer the tag "FIXME" instead of "TODO". TODO is more for things like 'some functionality is still missing here' (button xyz does not do anything yet when pushed) while FIXME indicates 'something is wrong here' (things that might look okay and be overlooked if the tag wasn't there).

          Another possibility:
          On a former personal project of mine, a compiler, I used a small self-written regression test framework. It consisted of a bunch of sourcefiles to be fed to the compiler with comments ins

  • 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 tacklin
  • Redmine (Score:5, Informative)

    by Roadmaster (96317) <<roadmr> <at> <tomechangosubanana.com>> on Thursday July 12, 2012 @11:53AM (#40629337) Homepage Journal

    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 [redmine.org]

    • We use Redmine as well, but it has some fairly severe problems. The biggest is the lack of a search function. There's no way to make a query like "find all open bugs assigned to category 'X' where the description contains 'keyword'".

      If you make use of subprojects, then the fact that categories aren't shared can be a huge PITA.

  • Use SourceForce.net (Score:2, Interesting)

    by ckthorp (1255134)
    Just create a dummy SourceForce project. You don't actually have to attached any source files to use the bug tracker or other features.
  • by Noryungi (70322) on Thursday July 12, 2012 @11:53AM (#40629341) Homepage Journal

    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.

  • Fog Bugz (Score:3, Informative)

    by mgreider (900058) on Thursday July 12, 2012 @11:54AM (#40629359) Homepage
    We use https://www.fogbugz.com/ [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.
    • I use the free FogBugz plan along with Tickets [manicwave.com], which is a native Mac client for accessing FogBugz. It has a nice Mail.app-like interface with smart folders, easy sorting, attachment handling, multiple accounts, etc. It has a few bugs, but overall it works very well for me.
    • by asylumx (881307)
      I don't have any mod points, but just want to second the parent. Fogbugz works great for one or two people and it's free until you get bigger than that. It's nice having something hosted and free without being forced to open-source your project.
  • by MyLongNickName (822545) on Thursday July 12, 2012 @11:56AM (#40629389) Journal

    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.

  • by JustAnotherIdiot (1980292) on Thursday July 12, 2012 @11:58AM (#40629429)
    ...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.
  • I wanted a simple system that does not need server setup and extra database setup, and can run under Mac OS X

    How about Stickies? [wikipedia.org]

  • 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.

  • 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 [taskwarrior.org] 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.

  • by kid_wonder (21480) <{public} {at} {kscottklein.com}> on Thursday July 12, 2012 @12:09PM (#40629565) Homepage

    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.

  • SVN (Score:2, Informative)

    by c0d3r (156687)

    TortoiseSVN is easy enough to setup to run without a server locally and works great.

  • Turnkey Redmine (Score:5, Informative)

    by PatDev (1344467) on Thursday July 12, 2012 @12:15PM (#40629633)
    http://www.turnkeylinux.org/redmine [turnkeylinux.org] 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.
  • Git + Unit Tests (Score:4, Insightful)

    by Kergan (780543) on Thursday July 12, 2012 @12:35PM (#40629857)

    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.

    • by msclrhd (1211086)

      Unit tests are hugely important. Getting the code under test early is a lot easier than retrofitting it to existing code.

      I will also stress that a good test library/framework/harness should provide you with as much information as possible when a test case fails -- this should help quickly identify the problematic code.

      Also, get into the practice of writing test cases for bugs -- especially if you can do that before fixing the bug. This will help avoiding regressions in the future when doing things like refa

    • WRITE THOSE F*CKING UNIT TESTS!

      Here we design for testability but only test critical stuff and wrote test case when something break down as our metrics told us that our unit test were worthless as they did not exercise code that broke or when the broken code was executed, the test was as broken as the code. Not that the code or the test were generally bad it's just that our bugs are usually at the multisystems interaction level, especially so when the mainframe is involved... Mocking up everything is not an option as experience thought m

  • I don't let enough bugs build up that writing them down would make sense. Although my personal projects are generally small.

  • by chundo (587998) <jeremy.jongsma@org> on Thursday July 12, 2012 @12:54PM (#40630107)

    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.
  • http://www.tfspreview.com/ [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/ [tfspreview.com]

  • 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.

  • It seems that your first project should have been to develop a bug tracker.
  • org-mode in emacs (Score:4, Informative)

    by hardaker (32597) on Thursday July 12, 2012 @01:26PM (#40630473) Homepage
    Emac's org-mode [orgmode.org] 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!
  • 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.

    • by vovin (12759)

      I use trac and subversion for personal projects and for work. I use my own setup to enforce my process rules.

      If you don't want/need basic processes support for yourself (or small teams) there are a few SVN/trac hosting sites for really cheap.

  • Low cost, easy to setup, will never crash.
  • I have used, in the past, Teamatic (http://www.teamatic.com) and http://www.elementool.com/ [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 [stackoverflow.com]

  • by allo (1728082)

    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.

    • by LesFerg (452838)

      Yes, use SourceForge. I put my open source project up on there and my users have BOTH posted a bug report on the project. Easy to find whenever I need to think about maybe checking it out to fix it.

  • 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.

  • by tommeke100 (755660) on Thursday July 12, 2012 @03:43PM (#40631983)
    Chuck Norris doesn't need to debug, he stares down the source code until it confesses.
  • 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

I am not now, nor have I ever been, a member of the demigodic party. -- Dennis Ritchie

Working...