Time for a new Issue Tracker, Isn't It?

CIT (CPAN Issue Tracker) is an idea I had/have for a modern Issue/Bug Tracker for the CPAN. RT is great and has served us well throughout the years but I feel we can do better now.

CIT is a single package that bundles the CLI, API and Data Model. I've started tossing around ideas in my Git repo but I'm open to collaboration. Actually, I am probably not going to get very far without an influx of collaborators.

The API and CLI will allow users and developers to install the package and quickly begin reporting and contributing to bugs, features, etc. Using a NoSQL datastore will support an easily distributed (preferably master-to-master) data model.

Contact me for a more in-depth brain-dump.

-Al

CLI Ideas: http://prepan.org/module/3Yz7PYrBPU
Toy Repo: https://github.com/alnewkirk/CIT

8 Comments

I suggest that the days of needing a single centralized bug tracker are behind us. Yes, RT is getting long in the tooth, but the alternatives are already out there, and I don't think we need a centralized replacement.

Here's something I wrote three years ago on the subject, and it's even more applicable today.

http://perlbuzz.com/2008/05/perl-decentralize-diversify-colonize.html

I don't think you need to "go NoSQL" just to be distributed. Fossil uses SQLite and it's a DVCS. And speaking of Fossil, it does have integrated (and distributed) ticket/bug tracking and wiki. Since Git is more popular, perhaps a bug tracker system built on top of it (or any VCS) can be considered.

Have you looked at SD (Simple Defects), also by the guys at Best Practical?

You may find it a foregone conclusion, but for the rest of us, can you summarise what is wrong with rt.cpan.org? I mean I have a tiny gripe about its autocomplete="off" behaviour in the password field, but asides that I can't think of anything that bothers me about it.

Here's a few things I've noticed with RT. I'm not an expert by any means, most of my experience has been basic interaction with rt.cpan.org via email/web:


  • Hit 'Log in', you're then happily informed that you've been logged out, by the time you manage to log in you've lost the original page

  • The button to report a new bug within the current distribution isn't very intuitive - 'Create New Ticket' next to the text input box has more prominence imho

  • Editing a field typically requires clicking on the section title rather than everything happening inline

  • No source code integration - can't add commentary to specific source code lines, for example

  • No VCS integration - can't create an issue/mark a bug as fixed via commit message, although this perhaps better handled on the VCS side since there are so many of them and no guarantee that they're internet-accessible

  • No .t / cpantesters integration - linking to reports/cpantesters summary pages, showing a summary of current pass/fail/unknown stats on the queue page for each distribution

  • Limited reporting - bug timeline would be nice, for example

  • Every action requires a page load, which wouldn't be so bad if they loaded a bit quicker - typically >3s for each page for me, even with everything cached


It's more a list of "things that could be a little smoother or provide some more information in places" rather than anything that's wrong with RT per se. After all, the important thing is that you can raise and close bugs with it, and that part works just fine!

As to the project idea, it sounds interesting. Could tie in nicely with metacpan's shiny new API, for example. I started something similar as an example project for an ORM - it ended up being useful enough to continue using as my main issue tracking/CI system for personal projects.

I have been beating the drum for GitHub issues for a while now. Though admittedly I need to be better about including it in the metadata of my modules.

RT is mail-oriented software that happens to have a web-interface. It's pretty good at that, but that's no longer fashionable.

Leave a comment

About Al Newkirk

user-pic ... proud Perl hacker, ask me anything!