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
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:
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.
Hey guys, thanks for all the feedback. I hope you guys are checking back and this comment doesn't fall on deaf ears.
It was commented on my post on PrePan that App::SD is the embodiment of what we've all been looking for, so why have I never heard of it and why isn't it being touted?
I have no desire to reinvent the wheel. As previously stated in another comment, RT could use a few UI and API improvements. I personally feel that a fresh approach integrating new practices is warranted.
RT is mail-oriented software that happens to have a web-interface. It's pretty good at that, but that's no longer fashionable.