Zope Issue Trackers
Overview
| | A couple of months ago, the small company I came back to Salt Lake to work for went through some splits, which ultimately left me being an independant contractor, but basically working with the same people. Before the split, we had tried a few different task management systems, but they ultimately ended up with stale data (a very common case), and the Big Solution I was working on was never completed.
|
| | After the split, I continued to track most of my work on the excellent OmniOutliner, until a couple of recent realizations got me to start working with bug and issue trackers again.
|
| | While wrapping up a project with a very aggressive timeline, all of the parties involved converged on the last day (a 21 hour day), and it was time to test. That morning, before I came in, I installed Roundup 0.4.2 and we used it during the day and well into the night for the testers to report bugs and for me to close them. It went quickly, and worked fine for those purposes. But we rapidly outgrew Roundup for various reasons to be documented later in this document.
|
| | The other realization was that these other parties who were giving me work cared more about what I was doing than I cared about what they were doing. I decided that the email-focused issue trackers were a better way of doing progress reports than self-composing emails at random.
|
| | So, I'm still looking at various solutions. Right now, the tried but true Tracker is being used. But it's old software with many of its own warts. This document will be a living outline, documenting pros and cons of various solutions that work with Zope, and hopefully I can patch together a nice list of requirements so I can finally see what it is I am really looking for.
|
Tracker
| | Tracker is the work of Ken Manheimer, an employee of Zope Corporation (at the time of this writing). One of the first tasks Ken was given upon joining ZC was to build a replacement for the aging Classic Collector (after the move to the current Zope 2 based Zope.org website, the old site remained active to the classic collector's dependency on some Zope 1 specific code). Working on Tracker opened up a lot of general issues - creation of generic workflow frameworks, usage of ZClasses, Local Roles, etc.
|
| | Ken is a very thorough developer and Tracker is a heavy beast, but it is generally very solid. Since it harkens back to early Zope 2 releases and early Catalog designs, its lifetime is very limited as architectural improvements and changes have been making their way into these parts of Zope.
|
| | Tracker is generally very solid in its user experience.
|
| | Relations between issues and items are fairly well tracked. Tracker's have their own internal URI scheme, (issue)[item]. Thus, one can refer to other issues in a Tracker by this sort of badge - (472)[] means Issue 472, (472)[3] refers to item (a post, workflow change, etc) 3 inside Issue 472. A really nice status change is diversion. Diverting an issue can roll up duplicate issues nicely into a single issue, or divert work from one issue into a new one if required.
|
| | Nice Emails. It was always hoped that there would be mail-in support for Tracker, but it never materialized (as Zope itself would have to understand mail-ins). But thanks to clear formatting and well placed URL's to issues/items and well formatted titles, it's easy to see, view, and respond to tracker issues that come in email.
|
| | Has built in support contract support. You can set up a Tracker for a support contract and give customers the ability to enter only a certain number of issues.
|
| | It's no longer supported, and I've heard mention that Tracker does not work on Zope 2.6.0. The code is tricky and ongoing maintenance is difficult, even for its author.
|
| | It's slow. There are a lot of Catalog queries being done and a lot of fancy work being done in DTML to get the user interface to be what it is. It's definitely not as snappy as some of the other issue trackers being discussed, even with a small number of issues.
|
| | I've experienced some authentication oddities recently using it with Chimera (Gecko based browser for Mac OS X).
|
CMF Collector
| | CMF Collector is almost a direct descendant of Tracker, but written for Zope's CMF (Content Management Framework). I have never installed it, but want to write up my quick thoughts about it. Note that I'll be referring to a lot of CMF terms here.
|
| | By the time the CMF Collector came about, the CMF was able to provide a fairly flexible workflow engine. It was also able to integrate better with other content by turning Issues into content items, and use the default CMF Catalog indexes.
|
| | Integrates better with other CMF Content, allowing project sites to be built that include other searchable artifacts.
|
| | The default user interface is customizable, courtesy of CMF Skins.
|
| | Likewise, I believe that the workflow is customizable, courtesy of the web configurable DCWorkflow CMF plug-in.
|
| | Still has the pretty URL's of Tracker.
|
| | Requires CMF setup, which is not an easy task. The CMF is a fairly open framework, but the default behavior is seldom usable. In my opinion. Setting up a new collector is easy once you have a good CMF site going, I'm sure.
|
| | No real release policy. CMF Collector, like Tracker, exists primarily in Zope's CVS.
|
| | Doesn't feel as solid as other issue trackers.
|
| | The day that I wrote this, a german only CMFCollectorNG was released in a 0.10.0 version. It looks like it brings back some of the cool Tracker things, like references to other issues and enhanced web configuration.
|
Roundup
| | Roundup (http://roundup.sourceforge.net/) was an entry in the Software Carpentry Contest, along with Tracker. Roundup won. It's base design is by Ka-Ping Yee. The version that I used was 0.4.2. As of this writing, I believe the current release is 0.5.2. The issues I mention here reflect only my experiences with 0.4.2, but I'll mention known improvements where I know they exist.
|
| | There is one primary reason that our time with Roundup was short - it's not Zope based. There is a ZRoundup front end, but it's really a pass-through object that passes control to the normal Roundup CGI handler, allowing Zope to be used as a web server. As such, it doesn't integrate with the other content that I wanted it to, nor could it take on the navigation bars in the Zope templates we use on our very banal project site. I don't fault them for not being a full fledged Zope product - that's a heavy thing to be. I do hope, however, that Zope 3 may make it easier to make some real Roundup Components that use Roundup's back end system but interface nicely with other Zope 3 content.
|
| | Furthermore, I'm not familiar with unix administration of the variety where you make new Users to reflect certain applications (like Apache or Zope). In order to really deploy Roundup properly, this seems like the path to go. I'm much more comfortable with Zope user management, and as such is why I tend to look for Zope based issue trackers. But I did have some very good success with Roundup initially, which is why I mention it. And I think it has a bright future. It's light, fast, and flexible, and while I may whine about its configuration setup, it certainly seems much easier to administer than Bugzilla and Gnats.
|
| | It's fast, relatively simple to use, yet contains a decent feature set, including file uploading and some basic inter-issue linking.
|
| | Its Nosy List is good for notifying different people involved in a project about particular issue progress.
|
|
Navigation
|
