Handling Multiple Deliverables

We have been looking very closely at Trac and how we would use it in a multi project environment. Our conclusions are a little different to any of the proposals made so far. The Trac philosophy is to keep things as simple as possible while preserving flexibility and that is what we are trying to do.

We have a large code base. Much of that code is shared among a large number of products. There is also a complex relationship between projects and products. For example, a project may change common code and result in several product releases. In other cases there is a one to one product/project mapping.

What the above means is that the relationship between a project, products, timeline etc. can get quite complex. The issue is how to deal with that while providing a clean and understandable system which normal people can cope with. Neither of the other proposals for handling this (TracMultipleProjects/MultipleEnvironments and TracMultipleProjects/SingleEnvironment) deal with this complexity. We believe that TracMultipleProjects/MultipleEnvironments is a non-starter for this. There are some good ideas in TracMultipleProjects/SingleEnvironment which are extended by this proposal.

We are going to define some terms so as to minimise confusion:

• Product: An item which is shipped to customers
• Project: A body of work which goes into products

We need to support multiple products and multiple projects. It is our view that projects map onto milestones which is very convenient as multiple milestones are already in Trac. This is the first big difference between this proposal and TracMultipleProjects/SingleEnvironment - the main selector is a product and not a project (I understand that this could be controversial so it would be a good idea to allow this to be configurable between product and project).

Requests like the one in #1048 and #586 are too simplistic as they only address multiple products which have nothing in common.

The bit which is harder is how to support multiple products. We believe that the following is required:

Ticket Changes

• A product field drop down list.
• A product version field drop down list which depends on the product field (i.e., each product has it's own set of versions). The current version field would become this field.
• The existing component field has to be dependent on the product. Each product will have it's own set of components.
• The milestone field also has to be dependent on the product (selecting a product would only show milestones which are relevant to that product)

Somehow milestones have to be associated with products (maybe more than one product). Adding a milestone would entail selecting a list of products affected by that milestone.

Timeline

We don't believe that there is a simple relationship between a product and a timeline. We think that instead of switching the timeline based on the selection of a product that there should be query support added to the timeline page. These queries should allow the user to select a number of paths into the subversion repository to select repository checkins, a product choice to select tickets and milestones, and a Wiki path (or number of Wiki paths) to select Wiki pages (see Wiki section below). These queries should also be saved so project teams can build reports which are useful for their project. Using these queries most users requirements should be covered. Maybe the queries should be saved by product or milestone - that would be good but not strictly necessary.

Roadmap

This is rather simpler than for the timeline. Given that there needs to be a defined relationship between products and milestones selecting a product should be all that is needed.

Browse Source

No need to change anything here as it is and should remain a view of the entire repository content.

Wiki

I think that by using the subpages or whatever it is you call pages which have a path (like TracDev/…) with the project name at the top level would neatly support multiple project documentation. The query for the timeline would use this path name to select product documentation changes.

Tickets Affecting Multiple Products

Ticket #130 talks about assigning one ticket to multiple products. I believe that this would be complex and prone to error. It is very difficult to know which products a piece of common code will affect. It would be very useful to be able to have tickets depend on other tickets (see ticket #31) so that as problems are found on different products which are caused by common code they can be linked to a single ticket.