How do you handle multiple (overlapping) projects in trac?

Question

We are using trac and are really satisfied with it. However, out of the box, trac is best suited for single-project environments only. I'd be interested to hear about the various approaches people take to make it work with multiple projects nevertheless and their experiences with them. Are there any plugins to recommend? Any patches, tweaks or whatnots? Are you maybe even using an entirely different bug-tracking system that offers all of trac's functionality plus multi-project support?

We recently started managing a second project ourselves which generally works okay but also has some drawbacks, especially where the two projects overlap because of common library code we wrote that is used in both projects. How do you handle this?

(I'll attach our own current approach as an answer to this post.)

Answer 1

The approach we took is to create another trac environment for each new project and set up InterTrac links for simpler cross-referencing between the two. We also use a common base Trac.ini file via the [inherit] directive.

Besides the ambiguity issues with shared code mentioned in the question, this has a couple of drawbacks that may or may not affect you, depending on the nature of your projects and your workflow:

• creating new projects is not an easy process; it can not be done via the browser interface
• ticket numbers are not unified: each new project environment starts fresh from #1 - at least with InterTrac aliases you can easily disambiguate them
• you have to take extra care when installing and configuring plugins so they will be installed and configured for all environments

Answer 2

An alternative we have followed is to configure different projects as components.

We share the SVN repository and the home wiki page, but we are not using the milestone features. If the project is big enough to have different modules (just one of them in our case) we configure each module as a component instead of the project.

Answer 3

Same feeling here, Trac is really nice once configured properly. And it's easily hackable without touching any code. I only wish the wiki syntax were something more common, like markdown.

We took the approach of using one Trac instance. We didn't need/want to use tight ACL and it has the benefit to keep all activity of developers in one place.

For separating projects, we're essentially assigning bugs to various milestones. Every project has a short-term and long-term milestone. The short-term is used for fixing actual bugs and the long-term for major releases.

Most of the other "new ticket" fields have been pruned, keeping the "type" and "severity" fields, which are the same on every project anyways.

Reports are essentially limited to "My tickets", and the "Show Report" button has been tweaked to directly access your tickets.

Workflow has also been adapted to add an intermediate "testing" status, so that QA can guarantee the fixing.

Email configuration has been tweaked to not flood the mailboxes, so that developers actually read their assignments.

With that in place, we have a pretty efficient tool. It took some time to get it right, but it is easy to change things if you know how to hack around and lookup things on google.