[future] bug/ticket tracking - Gitorious

Message from discussion [future] bug/ticket tracking

Johan Sørensen

More options Mar 10, 9:19 am

From: "Johan Sørensen" <jo...@johansorensen.com>

Date: Mon, 10 Mar 2008 14:19:49 +0100

Local: Mon, Mar 10 2008 9:19 am

Subject: Re: [gitorious] Re: [future] bug/ticket tracking

  Reply to author
  |
  Forward
  | Print
  | View thread
  | Show original
  | Report this message
  | Find messages by this author
  

On Thu, Mar 6, 2008 at 9:44 AM, aslak hellesoy <aslak.helle...@gmail.com> wrote:
> With that done it was time to tackle the next challenge. History. I
> needed to keep track of where each card had been at what time in order
> to derive these wonderful burndowns and other metrics. Long story
> short, I've rewritten this 4-5 times, using acts-as-versioned,
> acts-as-versioned-with-relations (or something), subversion (I think
> you saw that Johan) and a File DB. I have failed every time.

> Storing stories and tasks in Subversion actually came closest, I had
> mostly technical problems here. I haven't done much about this in a
> while. ThoughtWorks has released Mingle, which is really cool, but it
> doesn't tie in with your SCM as Johan describes.

> I definitely think the SCM is the way to go. That's where bugs, RFEs,
> stories, tasks etc should live. I think a Wiki-style format with some
> structure is the way to go here.

I'm not so sure it really needs to actually _be_ in the SCM anymore.
As long as I could edit it with my $EDITOR I think I'll be happy.

I began on a prototype implementation yesterday using Yurii's StrokeDB
(http://gitorious.org/projects/strokedb). The reason I went for that
rather than directly in git, is so that I can dictate the structure a
bit more and gear it towards tickets, instead of just content in
general. It'll also mean we can potentially implement our own merge
strategies. It's also in pure ruby (at least for now) and I know
Yurii's goals for it fits in pefectly with ours. And unlike CouchDB,
it's easily embedable, meaning a console interface, web interface and
a rubycocoa interface is very feasible without requiring special
daemons to be running.

So basically, the goal of the prototype is to implement a generic
structure for tickets and whatever data thats associated with them,
along with a commandline interface. And hopefully also
syncing/replication between ticket databases.

So the idea is to have it in the git repository dir, but .gitignore'd
and controlled with a separate binary, autoclosing/commenting in
commit messages would be done via a git hook. And by having the
"ticket database" in the git dir allows us to query the git-repository
from the ticket system, rather than the other way around.

> I would try to keep it decoupled (but interoperable) from Gitorius if
> possible. And possibly from Git too. An SCM based issue tracker is a
> novel idea, and if we can make something that would work in many SCMs
> it could potentially attract a lot of contributors and become a really
> nice product.

It would be fairly decoupled by default, since it wouldn't base its
storage mechanism on any SCM features. However, my biggest concern is
that this distributed ticketing system would end up being too exotic
for most people, but then again, so where things like Git for most
people not long ago (though I'd argue it still is for the masses ;)).
But I think a good webinterface that acts almost like they're used to
in other systems will go a long way, along with a powerful
distribution model for those who want/need it.

And I've looked at DITrack, DisTract and BugsEveryone, but the most
common problem is that they're either too closely tied with a SCM I
don't use, or the fail to give me the overview a bugtracker should be
able to give me. But most importantly, I'm interested in exploring
this topic fully myself (and anyone wanting to join in), and with
gitorious.org in mind.

> I am definitely interested in contributing to this.

Still interested? ;)

> Aslak

Cheers,
JS

Reply to author Forward