[future] bug/ticket tracking
Johan Sørensen
Ever since I started using a DSCM I've been annoyed with how bad
traditional bug/issue/task/ticket/whatever tracking fits into the
picture, the biggest one being how there's only one path, not much
unlike SVN.
I really want to add a tracker to Gitorious.org, not only because I'm
starting to need one myself (and thus I'm guessing it'll be useful for
others), but also because I think we have the opportunity to build
something that fits better into the world of DSCMs like git. So in the
spirit of keeping things open, here's a braindump of my current ideas.
The most basic requirement I have is that I should be able to track
tickets across clones and projects. It's a sweet way to collaborate
because a bug in "clone-a" could be marked as fixed in "clone-b" (by
another user), so instead of messing around with patch files I could
just pull in his changes and have the bug fixed. This is pretty much
exactly the way we all use git today, it's just not tied in properly
with bug reports.
It should also tie into the growing ecosystem of gitorious itself,
lets say I have a failing testcase and someone files a ticket on it,
but after looking at it it turns out it's a bug in rspec, the testing
framework, and I could just "move" that ticket to the rspec project.
But still have it tracked in my project, so that whenever it's fixed
in rspec, the bug would be marked as "fixed upstream" or something.
It would also be really neat if the tracker itself was distributed, so
I at least could bring it along on the train/bus/airplane and resync
when I'm back online. It may turn out to be a pipe dream, but I'm
looking at a couple of document databases with replication features
that I think would be a good possible solution.
To be honest, it kinda makes the most sense to store the bugs directly
in the repository, with a nice web UI on top for those into that,
since it would make it easier to track them across clones and
branches, but that might be a tad intruding for some projects?
While it potentially increases the complexity of gitorious a bit, I
really do think it'll be a nice feature for the projects that wishes
to use it (eg opt-in). Mostly because it's a good aid in helping to
build a community around the given project; new people can easily pick
out something to work on their clone, and regular contributors gets
all the usual benefits of a bug tracker.
But what do you guys/girls think? I'm thinking that at least the first
one of the above is a killer, and something I'd love to have on my
internal/company projects...
Cheers,
JS
Tim Harper
been thinking it'd be sweet to have a distributed ticketing system as
well since I started using Git :)
I agree - the easiest way to implement this would be just to put the
tickets in text files, which are versioned by git.
Git handles symlinks, so all the tickets could be placed in a
"tickets" folder, then all of the statuses could symlink to the ticket.
Tim
Yurii Rashkovskii
Definitely "must have" feature :)
On Mar 6, 2008, at 12:25 AM, Johan Sørensen wrote:
>
> Greetings,
>
...
Nolan Darilek
>
> It would also be really neat if the tracker itself was distributed, so
> I at least could bring it along on the train/bus/airplane and resync
> when I'm back online. It may turn out to be a pipe dream, but I'm
> looking at a couple of document databases with replication features
> that I think would be a good possible solution.
> To be honest, it kinda makes the most sense to store the bugs directly
> in the repository, with a nice web UI on top for those into that,
> since it would make it easier to track them across clones and
> branches, but that might be a tad intruding for some projects?
> Have you seen Bugs Everywhere? (http://bugseverywhere.org) It
> currently offers git support, stores bugs in the repository, etc. I
> would guess that integrating it with Gitorious would be relatively
> straight-forward--either parse the files in the .be directory
> directly, or snarf them into models post-commit, saving changes made
> in the web interface and pushing those changes into the repository.
> This might even support your "move a bug" scenario by dumping the
> bug into the target repository via BE.
But I could see how that might be intrusive. Maybe moving a bug is
just like a pull request? Tell me that you've created a bug in your
project that might be a bug in mine, but give me the opportunity to
review the bug before it gets moved and committed automatically.
aslak hellesoy
What a coincidence! I have been thinking about a very similar thing
lately. Let me elaborate.
A couple of years ago, while I was working in ThoughtWorks, I learned
all the voodoo of XP and Scrum - especially how useful burndown/burnup
charts and tracking velocity is. TW uses it on all their projects, and
we do the same in BEKK. The most important tool here is a big
whiteboard with index cards. Each index card is a story or a task, and
it moves from left to right as it travels from the states
unprioritised, prioritised, in progress, ready for qa and finally to
done done done (the states vary from project to project). Burndown and
Velocity is measured by looking at how much gets done in a fixed
amount of time (usually a week or two). Burndown and Velocity are then
used throughout the project to provide better and better predictions
of how much can be done by what time.
Okay.
Using a wall, paper and excel for the burndown works great in most
cases. But for distributed (open source) or big projects there is
often a need for a tool. With a tool you often lose the tangible
visibility there is on a wall, but still - we're not always in the
same room.
With all the existing tools for Agile project tracking being too heavy
and expensive, I sat down and hacked together my first version of
Kipling (my first Rails app). This was my first Rails app, it was
before Scriptaculous, so I stole Google's javascripts for their portal
thingie. I managed to get something running that resembled a reall
wall of cards, where you could drag the cards around and have them
written to a database.
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. Example:
h2. Make the socket close automatically
The socket should be closed automatically after 3 seconds.
It doesn't do so currently because bla bla bla.
---
tags: @sockets @in_progress @iteration_4
point_estimate: 5
This is a little inspired from Taskpaper - a plain text based GTD
tool. I actually set up a new Gitorious repo for my umpteenth attempt
to get this right: http://gitorious.org/projects/kipling (nothing here
yet though)
> While it potentially increases the complexity of gitorious a bit, I
> really do think it'll be a nice feature for the projects that wishes
> to use it (eg opt-in). Mostly because it's a good aid in helping to
> build a community around the given project; new people can easily pick
> out something to work on their clone, and regular contributors gets
> all the usual benefits of a bug tracker.
>
> But what do you guys/girls think? I'm thinking that at least the first
> one of the above is a killer, and something I'd love to have on my
> internal/company projects...
>
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.
I am definitely interested in contributing to this.
Aslak
> Cheers,
> JS
>
> >
>
Dane Jensen
> But what do you guys/girls think? I'm thinking that at least the first
> one of the above is a killer, and something I'd love to have on my
> internal/company projects...
wondering just how such a thing would work.
This just popped up on the Git list again in fact:
http://thread.gmane.org/gmane.comp.version-control.git/76411
and seems to have come up before:
http://thread.gmane.org/gmane.comp.version-control.git/48981/
-Dane
Johan Sørensen
> 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
aslak hellesoy
I have started to hack on my own thing (Kipling - just haven't pushed
yet). I'll see where it leads and keep an eye on your work. I think we
may have somewhat different goals. But we'll see.
Aslak
>
>
> >
> > Aslak
> >
>
> Cheers,
> JS
>
> >
>