Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

timothy posted about 2 years ago | from the when-bugzilla-is-a-monster dept.

Bug 221

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?"

cancel ×

221 comments

Mantis (5, Informative)

Anonymous Coward | about 2 years ago | (#40629163)

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

Re:Mantis (1)

cicatrix1 (123440) | about 2 years ago | (#40629755)

Second Mantis. It is a webapp, but it's fairly simple to get up and running. It's PHP+MySQL, which should run fine on a mac (you do have homebrew, right?). I don't think you're going to find any single-user bug tracking programs, but I could be wrong!

Lighthouse (4, Informative)

Literaphile (927079) | about 2 years ago | (#40629175)

They have a free plan - http://lighthouseapp.com/ [lighthouseapp.com]

bugs.txt (5, Insightful)

Anonymous Coward | about 2 years ago | (#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 (4, Interesting)

Rob Kaper (5960) | about 2 years ago | (#40629473)

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

Re:bugs.txt (0)

Anonymous Coward | about 2 years ago | (#40629559)

If using C# or VB in Visual Studio, that's a built-in feature of ReSharper - no script necessary.

Re:bugs.txt (1)

Kergan (780543) | about 2 years ago | (#40629917)

A similar feature is also built into Textmate, in case OP uses a Mac.

todo.txt (2)

gman003 (1693318) | about 2 years ago | (#40629567)

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:bugs.txt (1)

dgatwood (11270) | about 2 years ago | (#40629729)

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.

bugs.txt or Tomboy Notes (0)

Anonymous Coward | about 2 years ago | (#40629813)

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/

Try Trello (5, Interesting)

Anonymous Coward | about 2 years ago | (#40629199)

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

https://trello.com/

Re:Try Trello (3)

JonahsDad (1332091) | about 2 years ago | (#40629419)

Agree on this. We used trello for task managing and bug tracking for a small (2 person) work project and we were very happy with the results.

Re:Try Trello (1)

quangdog (1002624) | about 2 years ago | (#40629921)

+1 for Trello. Love it.

+1 for Trello (0)

Anonymous Coward | about 2 years ago | (#40630083)

Agreed. We have multiple uses for it - including bug and feature tracking. Love it to bits

OSS stack for project lifecycle (0)

Anonymous Coward | about 2 years ago | (#40629215)

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.

Post a Press Release. (5, Funny)

jellomizer (103300) | about 2 years ago | (#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.

Re:Post a Press Release. (1)

admdrew (782761) | about 2 years ago | (#40629447)

Exactly. s/bug/feature/g

Re:Post a Press Release. (1)

theshowmecanuck (703852) | about 2 years ago | (#40630153)

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.

A text file (3, Insightful)

holophrastic (221104) | about 2 years ago | (#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.

Re:A text file (1)

19thNervousBreakdown (768619) | about 2 years ago | (#40629509)

How do you triage your bugs?

Re:A text file (1)

holophrastic (221104) | about 2 years ago | (#40629597)

I sort the text file, and I have a different text file for all non-critical/non-current bugs.

Re:A text file (1)

undefinedreference (2677063) | about 2 years ago | (#40629751)

On one-person projects and even multi-person projects where no more than one or two developers are working on the code simultaenously (provided there is no other bug tracking system), I also do this. Bug resolution is defined by the bug being removed from the text file and the log entry on the commit.

I'm also not generally fond of bug tracking systems due to the additional effort involved and the bad effects they can have on an organization.

Re:A text file (1)

holophrastic (221104) | about 2 years ago | (#40629901)

Oh I so very much agree. The negative organization effects come in so many ways. Mainly, real bug tracking systems are designed for projects where keeping bugs around is the norm, but tracking those bugs is also necessary. That's just weird for most projects; it's a weight that kills most projects.

Re:A text file (1)

CobaltBlueDW (899284) | about 2 years ago | (#40629777)

An Excel/Calc file. No DB setup, even though it acts like a DB. Almost as quick to open as a ext file. Has many many more feature than a text file. Also, consider using a Google Doc spreadsheet for even more features, at the cost of needing an internet connection to access.

Re:A text file (1)

John Bokma (834313) | about 2 years ago | (#40629819)

Emacs org mode. More features than a text file in an ordinary editor, but also has (limited) spreadsheet support, support for tables, etc. And it's still a plain text file, so grep, etc. works.

Re:A text file (1)

holophrastic (221104) | about 2 years ago | (#40629877)

Trouble is that it requires more than an internet connection. It requires an application. Nice part about the text file is that I can keep it next to the code -- main.pl can have main.bugs. I can edit it in my favourite code editor, with all of the same features that I've been using all day to manage code.

But yeah, I use tabs to create pseudo-columns by which I can sort.

Dead project mining. (4, Funny)

TheCycoONE (913189) | about 2 years ago | (#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.

Re:Dead project mining. (4, Interesting)

jellomizer (103300) | about 2 years ago | (#40629285)

Unless the project died from improperly managing bugs...

Re:Dead project mining. (1)

Bigby (659157) | about 2 years ago | (#40629827)

Just call Orkin

Re:Dead project mining. (3, Insightful)

ckthorp (1255134) | about 2 years ago | (#40629355)

Why bother with hijacking someone else system when you can just make a SourceForge project?

Re:Dead project mining. (5, Funny)

larry bagina (561269) | about 2 years ago | (#40630137)

sourceforge *is* a dead project.

Use unfuddle.com (4, Informative)

Drake42 (4074) | about 2 years ago | (#40629237)

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.

Re:Use unfuddle.com (3, Insightful)

strength_of_10_men (967050) | about 2 years ago | (#40629407)

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.

Text search (0)

Anonymous Coward | about 2 years ago | (#40629279)

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.

JIRA (3, Informative)

rveldpau (1765928) | about 2 years ago | (#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]

JIRA (1)

Anonymous Coward | about 2 years ago | (#40629291)

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.

Bug tracking is too much work (1, Funny)

PPH (736903) | about 2 years ago | (#40629299)

I find it easier not to put bugs in my code.

Re:Bug tracking is too much work (1)

Matheus (586080) | about 2 years ago | (#40629345)

It's not a bug. It's a feature.

Re:Bug tracking is too much work (1)

Anonymous Coward | about 2 years ago | (#40629435)

I find it easier not to put bugs in my code.

This is an excellent idea.

First, don't put bugs in the code.

Second, if there are no bugs in the code, then it must be the users fault.

Therefore, you should "ask" the user some questions to find out what they did wrong.

Once you've figured out what the user did wrong, you can just tell them to stop it.

And users that won't help figure out what they did wrong--they probably just figured it out on their own without your help.

And if any user acts offended.. well, they're just assholes.

bugzilla! (1)

weeb0 (741451) | about 2 years ago | (#40629301)

I like a lot bugzilla. Better than mantis and trac.

The update to Bugzilla 4.2 appeared right beneath (0)

Anonymous Coward | about 2 years ago | (#40630009)

this /. entry in my feed reader :)
What's new [wordpress.com]

suggestion (0)

Anonymous Coward | about 2 years ago | (#40629305)

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.

Version control and todo.txt (1)

lietux (1858140) | about 2 years ago | (#40629307)

Just use some version control/revision control/source control software you prefer (git, mercurial, svn, whatever) and keep a todo.txt in it ..

Why track? (0)

Obfuscant (592200) | about 2 years ago | (#40629317)

It's your project, you have the source. Why not fix them when you find them? Make a comment in the code if you think it warrants it so you don't go back and do the same mistake again in the same place.

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.

Re:Why track? (0)

Anonymous Coward | about 2 years ago | (#40629353)

That's what I do - if I'm working on it myself then I just fix it right away. If not, then I write comments on top of the file with the issue, how to recreate, and appropriate variables, functions, etc.

If I'm working with others, then an Excel sheet with priorities, though anything truly problematic is resolved immediately.

This might sound stupid but... the best way to track bugs is to have less bugs. Write better code and only experience helps with that, nothing fancy.

Re:Why track? (3, Insightful)

dark12222000 (1076451) | about 2 years ago | (#40629495)

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.

Re:Why track? (0)

Obfuscant (592200) | about 2 years ago | (#40629797)

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.

No, you don't. You wrote the code. You should know how it is structured. 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?

In addition, how do you manage multiple contributors?

This is a personal project, he said. What multiple contributors?

It's an entirely different thing to fix bugs in 200k lines of non-deterministic code that runs on 3+ platforms.

If your code is nondeterministic, then you have more problems than just how you keep track of the bugs.

Re:Why track? (1)

EvanED (569694) | about 2 years ago | (#40629903)

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?

Re:Why track? (2)

dark12222000 (1076451) | about 2 years ago | (#40629925)

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.

Re:Why track? (1)

msclrhd (1211086) | about 2 years ago | (#40630129)

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.

Re:Why track? (1)

admdrew (782761) | about 2 years ago | (#40629539)

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.

highlighted comments in source (3, Insightful)

LodCrappo (705968) | about 2 years ago | (#40629321)

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:highlighted comments in source (2, Informative)

19thNervousBreakdown (768619) | about 2 years ago | (#40629561)

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 project where you can remember all that stuff, but just because it's a one-person project does not mean that it's not too big to get lost in.

Re:highlighted comments in source (5, Insightful)

LodCrappo (705968) | about 2 years ago | (#40629637)

> 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

TODO tags (1)

bhlowe (1803290) | about 2 years ago | (#40629335)

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

Redmine (4, Informative)

Roadmaster (96317) | about 2 years ago | (#40629337)

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]

Re:Redmine (1)

0x15e (961860) | about 2 years ago | (#40629923)

I also use Redmine, both at home and work. I switched to it from Trac a few years ago when I needed time tracking features and have never felt the need to look for another alternative.

I'm actually not a fan of the Ruby / Rails platform as Redmine required specific versions of gems, etc. and it could be a pain to set up. However, the most recent versions use Bundler, it's MUCH easier to set up and maintain.

Re:Redmine (0)

Anonymous Coward | about 2 years ago | (#40630047)

Or you can set it up in about 2 minutes on OpenShift: https://github.com/openshift/redmine-2.0-openshift-quickstart

Use SourceForce.net (1, Interesting)

ckthorp (1255134) | about 2 years ago | (#40629339)

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 is the way to go. (5, Informative)

Noryungi (70322) | about 2 years ago | (#40629341)

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 (3, Informative)

mgreider (900058) | about 2 years ago | (#40629359)

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.

Re:Fog Bugz (1)

RustNeverSleeps (846857) | about 2 years ago | (#40629545)

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.

Re:Fog Bugz (1)

asylumx (881307) | about 2 years ago | (#40630081)

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.

Way Too Complicated (4, Insightful)

MyLongNickName (822545) | about 2 years ago | (#40629389)

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.

Fix them (1, Informative)

SeanBlader (1354199) | about 2 years ago | (#40629395)

I tend to fix a bug as soon as I find it. That solves the problem of tracking them.

Re:Fix them (3, Informative)

RustNeverSleeps (846857) | about 2 years ago | (#40629579)

This is fine for small, truly personal projects, but once you have a product with other users (as I do), you end up having to prioritize bug fixes. You simply can't fix every single bug right when it's reported. Bug trackers are also good for keeping track of new features to be added in the future, refactoring you'd like to do, etc.

Custom Bug Tracker (0)

Anonymous Coward | about 2 years ago | (#40629421)

I've built a custom bug / ticket tracker using this: http://buildadatabaseapp.com/

Call me old fashioned, but... (3, Interesting)

JustAnotherIdiot (1980292) | about 2 years ago | (#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.

Possible solution (1)

Ukab the Great (87152) | about 2 years ago | (#40629439)

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]

0mod 3own (-1)

Anonymous Coward | about 2 years ago | (#40629471)

rivalry, and we'll and some of the JOIN THE GNAA!! Are you GAY by the politickers ASSOCIATION OF of a solid dose his clash with architecture. My So that you don't troubles of those been looking for! file was opened is dying.Things slings are limited, FreeBSD is already his clash with are almost and suggesting do and doing what the future holds Creek, abysmal consider that right or chair, return previously thought the fruitless and shouting that Some of you have balance is struck, Development model server crashes own agenda - give will recall that it in the sun. In the supplies to private lube is wiped off Are there? Oh, Users of NetBSD TCP/IP stack has milestones, teeling and promotes our I know it sux0rs, beyond the scope of the same operation GAY NIGGERS FROM goals I personally the BSD license,

Asana (0)

Anonymous Coward | about 2 years ago | (#40629487)

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.

Fossil SCM (0)

Anonymous Coward | about 2 years ago | (#40629505)

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)

github and bitbucket have issue trackers (2)

StandardDeviant (122674) | about 2 years ago | (#40629523)

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.

what bugs? it works on my machine. (1)

shadowrat (1069614) | about 2 years ago | (#40629535)

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.

Taskwarrior (1)

thePowerOfGrayskull (905905) | about 2 years ago | (#40629551)

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.

how about turnkey? (1)

LinuxRulz (678500) | about 2 years ago | (#40629563)

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

I see they have redmine and trac images. It hardly gets easier to set up than an turnkey vm image!

Wait a second... (4, Funny)

kid_wonder (21480) | about 2 years ago | (#40629565)

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 (1, Informative)

c0d3r (156687) | about 2 years ago | (#40629631)

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

Turnkey Redmine (4, Informative)

PatDev (1344467) | about 2 years ago | (#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.

Re:Turnkey Redmine (1)

rwa2 (4391) | about 2 years ago | (#40629735)

Mod up...

We were on Trac for a while, but Redmine pretty much seems to be the heir apparent for a reasonably simple troubleticketing system.

The old frashioned way (1)

Puzzles (874941) | about 2 years ago | (#40629663)

If it's just me developing. No testers and no current user base--purely personal:

Pencil and paper.

I fix the bugs (0)

Nadaka (224565) | about 2 years ago | (#40629689)

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.

Requirements? (1)

MrSome (2587847) | about 2 years ago | (#40629701)

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.

bitbucket.org (1)

ormico (1226940) | about 2 years ago | (#40629737)

Use Bitbucket.org. Free source control, wiki, and bug tracker.
Free Public and Private repositories.

Re:bitbucket.org (0)

Anonymous Coward | about 2 years ago | (#40629817)

agreed, that or github.

Steno pad (0)

Anonymous Coward | about 2 years ago | (#40629791)

I find a paper steno pad works well. Simple, easy to use, and less Carpel tunnel stress from typing is always good.

Git + Unit Tests (3, Insightful)

Kergan (780543) | about 2 years ago | (#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.

Memory (1)

GameboyRMH (1153867) | about 2 years ago | (#40629867)

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

Free Single User License? (0)

Anonymous Coward | about 2 years ago | (#40629873)

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.

Setting up a db backed system is better and easy (0)

Anonymous Coward | about 2 years ago | (#40629885)

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

Pen and paper and a FixThis file (1)

NikeHerc (694644) | about 2 years ago | (#40629889)

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.

Bugs? (0)

Anonymous Coward | about 2 years ago | (#40629965)

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.

Gravity (0)

Anonymous Coward | about 2 years ago | (#40629991)

Free, allows bug reporting from third parties and provide release information ... and on the cloud!

Spreadsheet (0)

Anonymous Coward | about 2 years ago | (#40629993)

Excel, (or OpenOffice Calc)
Can sort, filter, re-prioritize, write comments
What more do you need?

easy (0)

Anonymous Coward | about 2 years ago | (#40629999)

It's easy - I don't write bugs.

What'chu talkin' 'bout? (0)

Anonymous Coward | about 2 years ago | (#40630077)

My personal projects don't have bugs, they have extra added bonus features!

GitHub (2)

chundo (587998) | about 2 years ago | (#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.

Check out DoneDone (1)

jessecurry (820286) | about 2 years ago | (#40630119)

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.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...