Trac[1] and JIRA[2] seem to be likely candidates whenever software development projects need issue tracking, revision control, and wiki-esque functionality all integrated nicely. Trac is itself open source, and JIRA, while not open, is at least free for open source projects to use[3].
For a while now, myself and others have attempted to cobble together "native" drupal solutions that reimplement this kind of functionality (e.g. project.module + cvs.module/svn.module + mailhandler, OG, etc). OG in particular is an area where i think Drupal opens lots of cool possibilities not normally available via Trac or JIRA alone (based on my highly limited exposure to their demos/marketing material, i've never actually interacted with either one). However, even http://cvs.drupal.org exists, since there's nothing like ViewCVS natively for Drupal (and no one wants to re-implement it, for good reason). To be perfectly honest, in spite of their strengths, both project and casetracker are full of problems in their own ways...
One of my co-workers (where i've already got a few Drupal sites deployed, and am planing a major Drupal site to run the entire project) has been pushing us to forget about Drupal, and just install CVSTrac[4] for all our issue tracking + CVS integration. I've been trying to fight this, and convince him that CVSTrac doesn't do everything we need (which is true, though it does cover 80% much better than Drupal can right now) and that 1 unified system with a consistent appearance, UI, etc, is better than 2 incompatible systems that handle different parts of what we need, even if 1 of those systems is currently more slick than the Drupal solution.
However, I've had a bolt of inspiration... Instead of trying to re implement the functionality of Trac or JIRA, we should just integrate with either system so you can have them seamlessly united with the rest of your Drupal site.
Suggestions for possible integration:
- Provide good ways to import/export existing Drupal project issues into/from these other systems. so, if you already are using Drupal, and want to switch to Trac for the issue tracking, you can easily slurp in all your current/past issues. Exporting from either of these systems into project issues might not be worth worrying about. However, if it was easy to go in both directions, that'd be nice.
- Maybe there should be some kind of Drupal node for each issue in the other systems? These nodes could then use any of Drupal's power (OG, views, tracker, whatever) so you could do custom stuff on the Drupal site, but the 'view' option in hook_nodeapi would just know how to slurp the content out of the other system and display it to you how you wanted?
- Make it easy to have the main JIRA or Trac content region show up in the main content of your Drupal pages. Basically, make it trivial to wrap Drupal theme, blocks, headers, footers, whatever around whatever view of your issues/source JIRA or Trac wants to provide you.
- Integrating searching issues with the Drupal site (either via the above nodes, and/or making a tab on the [site]/search page to search "Trac issues" or something, which just brings you to Trac's issue searching interface...).
The existing project module could be majorly refactored (and simplified):
- All issue tracking stuff can be moved out into a separate contrib module, so if you just wanted native drupal issue tracking, you'd have 2 options (project_issues and casetracker), or you could just use the JIRA or Trac integration.
- All the tarball download management stuff is all that's left of the project.module (e.g. project nodes and project releases (which should probably just be their own nodes, the more i think of it).
I was already planning to spend a bunch of effort on Drupal customizations for my day job's site (e.g. to try to get the native Drupal modules in shape well enough to make a reasonable alternative to Trac), so instead, I could just work on integrating Trac with Drupal and leave most of the hacking on the existing cvs.module and project.module behind. ;) Moreover, Trac has its own large development and user community, specifically focused on software dev. tools and issue tracking. Why not just automatically benefit from all of their work (and contribute towards that), instead of continuing to hack the "native" Drupal solutions and "compete"?
Given that: both the software at my day job (Condor[5]) and Drupal still use CVS, my co-worker is so keen on CVSTrac, that CVSTrac + Trac are both open source themselves, and that once we have Druapl + CVSTrac, I'm sure Drupal + Trac itself will be trivial (if not already done), I'm inclined to start with CVSTrac integration.
If this works as planned, I could totally see drupal.org switching over to something like this for our contributions repository, instead of ViewCVS + our current project issue queues. I'd like to be done by the end of August, so my timeframe is weeks, not months...
[1] http://trac.edgewall.org/
[2] http://www.atlassian.com/software/jira/
[3] http://www.atlassian.com/software/views/opensource-license-request.jsp
[4] http://cvstrac.org/
[5] http://www.cs.wisc.edu/condor
Comments
a few details on Trac and CVSTrac to consider...
ok, i've already started getting questions/input in IRC about this: a few details to consider:
yet more details and options
CVSTrac doesn't use a real DB... it just uses SQLite and a single file. probably no way we could get CVSTrac to scale to the size of the drupal.org issue queue. not even sure it'll scale to the size we'd need for Condor, for that matter. so, perhaps i should instead focus on Trac integration and either look into finishing the CVS plugin for Trac, or just work on switching both of the projects I care about to SVN. however, there are very good reasons neither one has switched, yet, so i'm not too thrilled about this. :( might make JIRA more appealing, just since it at least talks to CVS, which is what i'm already using in 2 places, even if it isn't open source. :(
Trac works with PostgreSQL, SQLite, and "experimentally" with MySQL
JIRA fully supports MySQL and PostgreSQL.
Eventum (http://dev.mysql.com/downloads/other/eventum) is another possible contender in this space, though it only works with MySQL, no hope of pgsql support. It's all php (probably much easier to integrate with drupal, therefore), and supports CVS "out of the box". It's not clear from reading the (fairly skeletal) docs if it's easy to move Eventum issues from 1 project to another.
In fact, i'm not sure how easy moving issues from 1 project to another is with any of these tools, and it's one of the few things Drupal's project issues get right... any info on this from people more familitar with any of these tools would be much appreciated.
eventum and more
i briefly used eventum as an admin and user and i was pretty impressed with the features. the ui can be a bit clutterred, but software developers will grok it quickly.
There is Viewcvs works on svn repositories and even our own svn.module does a decent job of this, fyi.
You have not mentioned user authentication integration, which is usually the most important integration point. For this, Drupal can be the master or the slave. I've done it both ways. You might use SQLAuth or webserver_auth or the native 'external auth server' feature of 4.8
Trac!
I just did a big Trac installation for a larger project. We use it extensively, and are pretty happy with it (it also "sucks less").
There are many plugins, and the very fact that there is a plugin architecture means it can be extended. For example, there is an OpenID plugin, so if we had an OpenID module for Drupal, it could be integrated that way.
There are roles/groups (sort of) which could map to roles in Drupal.
All of the functionality is actually available through the commandline, so you could make a "wrapper" module in Drupal to drive it from the web interface.
The big downsides as I see it are:
If it is lightweight integration (which I would recommend), then I would skip nodes.
Of course...transitioning from the current project/issues system to Trac is going to be a major education process...
Don't like JIRA
I've used JIRA when doing civicrm integration, and I don't really like it. It is also not free, so no reason to use it.
Yes.
I'm glad you've had an epiphany on this Derek, your work improving project module has been great but I always felt it was the wrong direction to go. Drupal is a web development framework, not a software bug/issue tracking tool, and hard as you try you're never going to excel in the way a dedicated tool would. This is one place I think 'eating our own dog food' doesn't make all that much sense, and even hampers the project.
I'm personally using svk now, and want to find the time to check out bzr, but really for drupal.org I think moving to Subversion is the best option, in the sense of providing useful new features with a minimum of change. And that means Trac is also a good match. We've been over why we should move off cvs several times already, so I'll not start on that...
I think if you're serious about moving away from project and onto integration of a dedicated tool you ought to make the move to a better versioning system too. CVS has had it's day, it's on the descendent, it doesn't make a lot of sense to spend time and effort on new integration projects (even if cvstrac acts as a middle man). Go for svn+trac :)
Bear in mind that:
1. you can import any existing cvs repositories
2. you don't have to remove existing cvs repositories, just close them to new commits
I think you're absolutely right that expending resources on project.module is not the best option, and that we'd be better served by using dedicted and specialized tools.
Integration? Trac, maybe...
Jira I know nothing about. Trac I use internally and like a lot. Trac can be kind of a pain in the arse when it comes to perms and administration, but one its setup for a particular project you're good.
How do you see the integration going? I'd rather see trac modified to use drupal for authentication. Although I don't have too many problems with project module. It seems like it would be hard to integrate trac as cleanly with the rest of drupal.
on 2nd thought...
the more i think about this proposal, the less i like it. ;) i'm still on the fence, so i haven't completely made up my mind, yet, but i'm definitely leaning away from trying to do a Trac + Drupal integration module for the following reasons:
basically, if i continue to make drupal's native issue tracking better (and i get some more help with that), even in the short run, drupal + viewcvs is going to be way better than CVSTrac, way cheaper than JIRA, more flexible (cvs vs. svn, mysql vs. postgres, etc) than Trac, etc. there are really only a handful of features that Trac/JIRA seem to have now that drupal doesn't (e.g. better ability to link issues together, "milestones", etc), but those will be pretty easy to add to the drupal versions (especially once follow-ups are comments).
and, of course, if you can do everything your site needs by only learning a single admin interface, having a unified UI for everything, etc, it's going to be a lot easier to deal with.
we should definitely consider putting together a "software development site" install profile (project, project_issue, cvs, svn, support forums, handbooks, etc, etc)... i should probably bump this last idea into a whole other post. ;)
anyway, those are my current thoughts on this. i'd still love to get more input, feedback, etc.
thanks,
-derek
indeed
i have to agree, derek. drupal modules are so quick to build that we can get real close to trac on our own ... drupal's wiki capabilities need a lot more work. i hope to lead a discussion on this at drupalcon brussels. ideas welcome.
Not to sidetrack...
But liquid wiki is for an RC of Drupal and just needs a few minor form function updates...
+1
I also think that a solution that is native to Drupal should be built, especially considering Derek's point #8. I'm very interested in getting issue tracking and related tools working within an OG scenario --- to let spontaneous working groups be started, each with issue tracking (project.module/casetracker.module) and a source code repository (subversion.module) and more. Doing it within Drupal means integrating with some of the other modules and developments more easily. It's my view anyways that Drupal is poised to become a full-on distributed development system (http://www.wovenlabs.com/workspace).
--
http://www.woven.org
http://www.davidnotik.com
A simple Trac Module
We started with Bugzilla, and then trac at CivicActions before the project module issue tracking stuff ever existed, and I think that trac is here to stay for us. The problem is that each client is installed in a separate trac instance (i.e., database) and querying issue status across projects (i.e., databases) is impossible with the native trac UI.
Some simple poking around and I've discovered that it's relatively easy to query the sqlite3 database as long as you have php compiled properly. That said, we need an interface that allows us to query these trac databases and sort tickets by user, priority, client, date, etc. Drupal seems perfect for the display and UI of this application. So I am very seriously considering writing a Drupal trac module that integrates initially only for the query and display of tickets. I'm not sure if I'm going to node-ify the trac tickets and expose views filters, or merely expose query and results pages. a few blocks, and an rss feed.
Before I start work on this, please feel to give me your feedback. I think that something simple is going to develop. The question is how far do we go? Your thoughts?
Doug Green
904-583-3342
www.douggreenconsulting.com
www.civicactions.com
Doug Green
www.douggreenconsulting.com
www.dougjgreen.com
go for it
i use trac for clients too. this is a pretty interesting experiment. go for it.
+1 for a solution to integrate Trac + Drupal
This would also open doorways to utilize Eclipse + Mylyn (formerly known as Mylar) with Drupal for automated/integrated/repository task management.
For example, we've been using Casetracker a lot, and I wrote a contrib module for bot.module that announces new cases and new case changes + comments in the IRC channel. I also wrote one that announces SVN commits in the channel. I want to switch to Mylyn without losing this functionality, and that's when I came to the same conclusion:
+1 for a solution to integrate Trac + Drupal. I'll even help you build it.
Hi! Can you link to that
Hi!
Can you link to that Case Tracker bot module?
By the way, improvements to Case Tracker recently, cleaner OG integration for one... get involved! :)
Best,
--D
--
http://www.wovenlabs.com
--
http://www.woven.org
http://www.davidnotik.com
Maybe an option!
Has anyone used or considered http://dotproject.net?
It is php/MySQL open source. I have not worked with it much yet, just installed it for a small project and was quickly entering project information and beginning to setup tasks.
I have worked with trac and find dotProject more intuitive. It has trouble tickets (email based ticketsmith), etc., but no RCS integration.
Maybe a starting point, or re-usable code.
Ron D.
NOOOOO!!!!
I've used it and it is SLOOOOOOOOOOOW. For anything more than 4 simultaneous users (I kid you not), the performance makes it nearly unusable.
And whatever you do, don't look at the source code. It will make your eyes bleed. They filter the content just before its saved to the db and when its displayed. So every time you edit something it gets RE-filtered (& becomes & becomes &…).
- John (JohnAlbin)
- John (JohnAlbin)
I am waiting on
I am waiting on it the modules too
Pivotal Tracker
As much as i dislike trac, i like pivotal tracker. Too bad it isn't os. They're throwing it out for free so guess they plan to box you in horribly.
With pivotal tracker i can focus on planning the workload and communicating progress instead of focusing on rewriting tickets. Tickets and milestones are fun when you set up your planning but they are not very useful when you are doing the work. You need an agenda and a good interface for time registration.
If ticket handling is somehow connected on a sublevel for keeping track of progress, that's a bonus. It should never be your primary interface when you're working on your projects, though. Perhaps for the manager, but not for the dever/themer.
hmm ic
hmm it can be integrated with jira software sir?
Hi Folks, Did anything ever
Hi Folks,
Did anything ever happen with the Drupal/Trac integration concept?
I'm in a toolsmith role for large teleco and have already implemented Trac/SVN as the basis for the CM process. I'm now keen to wrap this all up inside Drupal, replacing the existing Confluence installation. (ok, getting Drupal in by the back door, but what the heck!).
I'm going to have resource available to develop any required module(s) so anyone interested in getting involved?
Cheers
Andy
SVN/TRAC
Hello Andy,
The SCM Drupal choices are all to work under this umbrella: http://drupal.org/project/versioncontrol
Here is more such info: http://3281d.com/projects/version-control-api
Since we are talking project management (TRAC), then what more do you have in mind?
ie, what do you use TRAC for, bug tracking, issue tracking, etc?
Regards,
Jeremy Donson
New York City
Jeremy Donson
Database and Systems Engineer
New York City
SVN/Trac
Hey Jeremy,
Thanks, I'll take a look at versioncontrol.
In terms of Trac, we use it for bug/issue tracking, but essentially the key is the tight integration with SVN. Our less technical users see SVN/Trac as the same thing which IMO is a good thing.
Not convinced there's the maturity in any existing Drupal mods that I can use to build out a replacement for Trac, especially as we integrate with Bitten (CI builder) too, which is why I've started sniffing around a new module.
Modules that seem relevant to your last entry...
drupal.org/project/project
http://drupal.org/project/project_issue
http://drupal.org/project/subversion
http://groups.drupal.org/new-release-system
Jeremy Donson
Database and Systems Engineer
New York City
trac is more than just an svn client
We're also heavy Trac users. It works great, it has many plugins, we love the wiki/ticket/source-code integration, and its free.. ;)
We'd also like to have a single sign-on integration with our main Drupal website. This would really help us I think.
Note that Jeremy's last post suggests he hasn't really used Trac (no offense Jeremy) - Trac is a very powerful system and its integrated nature sum-of-parts value is much more than the Drupal modules he's highlighted here.
hmm yap
I have to try to makes module can be tracked issue in jira, and it can , but now the trouble is how to create issue, create comment so it can show in jira, how to do that?????
Trac != SCM
FYI: I like trac, but I do not like its wiki very much. I also prefer php to python for web dev.
The general need for SCM was the topic. Hudson and Drupal's version control API seem the best options for all to mingle at the same repo.
Jeremy Donson
Database and Systems Engineer
New York City