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.)

Stuffing

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

Stuffing

Answer 2

About one year ago SimpleMultiProjectPlugin (support of multiple projects in one Trac instance) was implemented. It runs with >= Trac 0.12. It add a new ticket field 'project', extends the timeline and roadmap page with filters for multiple projects and its maps versions, components and milestones to projects.

Havstad

Answer 3

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.

Swop

That's what I do. I use components like this: "Project: Component" – Breann

OK, so how do you handle milestones and versions in that setup - i.e. how do you associate them with the projects(/components)? do you use a naming convention or something like that? – Stuffing

also, do you also handle sub-components? – Stuffing

Answer 4

The Apache Bloodhound project was started specifically to bring support for multiple projects to Trac (amongst other things). It is essentially a collection of plugins on top of Trac.

Bloodhound remains compatible with most popular Trac-Hacks and follows any changes to Trac itself. You can try the demo instance too.

Mafaldamafeking

I played around on your Test site, and could it be that milestones are not yet considered by those products? I missed something like a roadmap of a product where its milestones are listed. Though good work and interesting, at least since I discovered Bitnami also hosts a Bloodhound Trac stack although it's not clear if that also contains SVN. – Havstad

@falkb: The roadmap is still work in progress, but I believe it will be re-introduced in our next release this week. I haven't worked on that feature so it's best if you ask on our mailing list if you've got more questions around that. – Mafaldamafeking

Answer 5

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.

Chambless