Wednesday, October 21, 2009

Announcing the Commencement of Bit Vizier Development

I was going to announce this about two weeks ago, but work suddenly kicked into high gear, and left me wishing for time to work on anything.

Considering this previous post of mine, seeing me announce something brand new has to seem more than slightly wrong. After all, why make a new item, rather than extend an existing one? How can I justify making Bit Vizier (AKA yet another issue tracker) when I just condemned making yet another framework?

In this case, I have two reasons for doing so. The first is that the other issue trackers out there fall broadly into two categories:
  1. Code I do not wish to extend. I'm a Python developer, so tools like Request Tracker and Redmine do not appeal to me due to their language choice. The products may well be wonderful, but if I hate working in the codebase, I'll never do anything with it.
  2. Systems that I would have to nearly reinvent anyway. Trac is a marvelous tool. But for me to carry my issue tracker to completion (as I see it), I would have to alter so much of the core of Trac that it would no longer be Trac.
Trac in particular makes for a useful comparison. I've heard from a friend who spoke with one of the Trac developers about some of the same ideas I'm putting into Bit Vizier. On hearing those ideas, he was told that it was very unlikely to happen for the following reasons:
  1. The ideas would require significant modification to the Trac core components.
  2. Making those modifications, and getting them accepted, would basically mean you would have to become a member of the core Trac team.
  3. Becoming a member of that team is extremely difficult.
  4. These ideas go against what the Trac team wants to do, and are not likely to be implemented by them any time soon.
I am being deliberately vague about who said what and when because I don't want to cast aspersions, and it's possible I misunderstood what was said to me. In any case, as much as I like Trac, I do not feel that my ideas will be well received by the Trac community as a part of Trac.

On the other hand, the ideas standing on their own have merit. I've at least set up a website for the project (yes, I'm using Trac until this is self-hosting. I believe I mentioned that Trac is excellent, didn't I? They just won't like my ideas), along with a Mercurial VCS that can be cloned. With any luck, I'll even be doing a talk on it at Pycon in Atlanta, GA.

As a very quick overview of my plans: I'm looking to make a shared issue tracker, built on top of TurboGears. The ultimate goal for it will see me able to integrate with a variety of tools, and even use Bit Vizier as the basis for other tools I've been thinking of for a few years. The pieces are finally coming together for me.

For now, take a look at the site, and tell me what you think.

3 comments:

jnowl said...

fwiw, http://pitz.tplus1.com/main-idea.html

jnowl said...

pitz isn't mine, just thought might be of interest.
See also: http://zesty.ca/roundup.html

I'm not intentionally taking issue with 'yet another issue tracker', but you haven't convinced me shared vs. distributed is different enough. Of course it's your itch to scratch.

Michael Pedersen said...

My apologies. I thought you were pointing me to your project. I've updated that post accordingly.

For me, the fundamental difference is how connected the pieces are. I took a long time describing it in my post on "What's the difference?", but it boils down to this:

Distributed issue tracking systems expressly allow for taking issues offline, working them offline, and then uploading them back to a central storage place.

Shared issue tracking is about having the tracking systems talk to each other directly, allowing the user to deal with one site, but sharing the information as needed to get the issues resolved both in his projects, and any upstream projects.

For an example of where such a tool could be amazingly useful, take a look at Debian. Extreme diligence is required in order to maintain coordination between Debian and all the other upstream issue trackers. If a tool were written which could allow Debian to automatically gather this data from the upstream trackers and attach to Debian's own issues, how much easier would the lives of the Debian maintainers be?