Life after Bug Tracking Systems
Avery Pennarun: The git developers don’t track bugs. If you find a bug, you can write about it on the mailing list. You might get flamed. And then probably someone will ask you to fix it yourself and send in a patch. This is unlike almost all other open source projects.
Sometimes ideas take time to percolate. When I first saw Avery’s post, it didn’t quite sink in.
When I started playing with hg, I noticed that I was applying a different style of development than I previously had done. One that I felt more comfortable with. And I thought again about Avery’s post.
And when I came across Chad Wooley’s comment: But using your SCM as a messaging platform? Come on, that’s taking the social networking thing too far... I pray that I never see the official Twitter channel for an open source project I care about, because I ain’t going there...; I once again thought about Avery’s post.
It now occurs to me that not all projects need bug tracking systems. In fact, for some projects, not having a bug tracking system may very well be a feature. In particular, if the bug tracking system on your project is the place where feedback goes to die, you might be better served not having one. But if you do decide to go this way, you would be well served to consider one of the various DVCS systems out there, like bzr, hg, and git.
[from rtomayko] Life after Bug Tracking Systems
Sam Ruby on how DVCS + mailing list has removed the need for bug tracking systems on some projects. I’m feeling a similar pull in my own work....Excerpt from del.icio.us/network/ek1.618 at
[from chl] sam ruby: life after bug tracking systems
[link]...Excerpt from del.icio.us/network/ek1.618 at
With DCVSes, you can also just keep track of bugs in the repository!
Make a file for each ticket, with filing in it’s own commit, and updates/closure committed along with the source code changes they correspond to.
There are a couple new projects out there trying to define a syntax + develop a web interface for this, but that’s just icing!
Posted by Fred Blasdel at"if the bug tracking system on your project is the place where feedback goes to die, you might be better served not having one"
[link] [comments]...Excerpt from programming: what's new online at
I guess it depends on how you ask the question.
Another way to approach the question: at what point after I make available something for free and asis do I become obligated to provide support?
A valid terminal state for many personal projects is “works for me, if it works for you — great, but if it breaks, you get to keep both halves”.
Posted by Sam Ruby atBzr Bookmarks
Bookmarked your page with keywords bzr!... [more]Trackback from Post Saver - Website voting and saving system at
How to tell when your bug reporting system is at its limits
How to tell when your bug reporting system is at its limits There reaches a certain point in the life of many projects, especially open source projects, when your bug reporting system just doesn’t work any more. By ‘doesn’t work’ I don’t mean that...Excerpt from Chris's Wiki :: blog at
github in fact is a social network based on git. I blog in code or code in the blog quote of the day via [link]...
Excerpt from Mariuz's Blog at
I disabled the bug tracking features of RubyForge for most of my projects. I’d rather have people use GitHub or email to provide patches and feedback. Bug tracking systems are where feedback goes to die on my projects. Especially because RubyForge is really weird about when it decides to send me an email about an issue. Many times I just don’t know that someone’s posted a bug.
Posted by Bob Aman at