Multi-project support

[Christian Boos]

This is a fresh start for #130, which grew too big… While long delayed, implementing multi-project support in Trac is still seen as a valuable goal.

To quote the original ticket:

Support multiple projects with different sets of components, version numbers, and milestones in the ticketing system, and different repositories in the browser.

This is different from TracMultipleProjects because to provide e.g. a merged Timeline and Roadmap, the different projects would need to be in the same database

Related proposals:

• MultiProject

Alternative solutions, as Trac plugins:

• ​​TH:wiki:SimpleMultiProjectPlugin…
• ​https://projects.developer.nokia.com/multiproject

Alternative solutions (… or source of inspiration!):

• RedMine, ChiliProject, …
• GitHub, BitBucket, …

[fbrettschneider@…]

Replying to cboos:

This is a fresh start for #130, which grew too big…

Today I got to #130 from SeaChange/WhatUsersWant. I suppose all those wiki pages must be updated to #11025 now.

[Christian Boos]

Good suggestion, I just did so. I think that #31 and #886 could also benefit from the same procedure ;-)

[fbrettschneider@…]

Basically, I wonder whether people actually really need TracMultipleProjects/MultipleEnvironments or if this is just a subsequent effect, the need because of the current situation that they created more than one Trac instance, because there was no support of TracMultipleProjects/SingleEnvironment. Unfortunately, SeaChange/WhatUsersWant doesn't separate both solutions in its poll. Though I reckon 90% would be satisfied with the single environment solution.

As strategy I recommend to implement SE first, since sooner or later ME would need to consider it sits on top of several SE instances anyway.

[lkraav <leho@…>]

I myself am primarily interested in bridging separate envs in a sensible way for security, privacy, isolation concerncs mostly.

[anonymous]

is this not milestone:topic-multiproject?

[Christian Boos]

Sure. Note however that this topic milestone was originally meant to track progress on an independent development branch dedicated to implementing the MultiProject proposal, but this branch hasn't materialized, so far. We can also see that milestone as being a the counterpart of this "master" ticket, given the fact that we also don't have SubTickets for now.

[Christian Boos]

Replying to lkraav <leho@…>:

I myself am primarily interested in bridging separate envs in a sensible way for security, privacy, isolation concerncs mostly.

This sounds a lot like the PortalTrac proposal, i.e. #10217.

Here we'll focus on the MultiProject in a single environment approach.

[jholg@…]

As I'm sure you know ​Apache Bloodhound claims to have multi-project support now. No idea how usable their ideas or code might be for "Trac proper", though. Too sad there's kind of a "schism" now.

Myself, I'm using multiple envs under a modified ​th:TracForgePlugin master project in a corporate environment. Works, but surely not optimal. Has some merits wrt to the permissions system, though, as you can have arbitrary separate permissions for the different Trac instances, if need be.

[anonymous]

Replying to jholg@…:

As I'm sure you know ​Apache Bloodhound claims to have multi-project support now. No idea how usable their ideas or code might be for "Trac proper", though.

They have multiple product support, meaning they use a single trac and associate most of the existing entities with the product directly. By most, I mean that that they do not directly reference the product from the repository. As such, all repositories are visible from the main project's page, which IMO is kind of weird as I would rather see them only from within the product's own realm.

Besides that, Bloodhound is also WIP and far from complete.

As for the schism, I think that the original trac can incorporate some ideas and improve on them, for example true multiple project support by which I mean that each project has its own set of repositories. Apart from that, multi product support per project would be nice as in product being an uber-component that features one or multiple components.

[falkb@…]

Replying to anonymous:

… by which I mean that each project has its own set of repositories.

This is already a special case for you. See, some people may use multiple projects on a single source repository, where they may use different branches or use #defines in .cpp files or something like that. Though you may be right limiting the project view to a set of pathes in one or more repositories may be a good idea.

Apart from that, multi product support per project would be nice as in product being an uber-component that features one or multiple components.

Look at ​TH:SimpleMultiProjectPlugin which uses 'projects' and allows to map certain components to the projects.

I don't like the term 'product' used in Bloodhound since a product is the result of a project, and a project describes the way to one or more products, and one can have one project resulting in multiple products. The term 'project' describes the process, and milestones and versions are just dated steps in that life cycle. And nothing stands in the way for creating several projects for single product in case one shares the effort on several teams.

[Olemis Lang <olemis+trac@…>]

Replying to anonymous:

Replying to jholg@…:

As I'm sure you know ​Apache Bloodhound claims to have multi-project support now. No idea how usable their ideas or code might be for "Trac proper", though.

They have multiple product support, meaning they use a single trac and associate most of the existing entities with the product directly. By most, I mean that that they do not directly reference the product from the repository.

In Bloodhound a repository may be linked to multiple products . They are all owned by the global environment .

As such, all repositories are visible from the main project's page, which IMO is kind of weird as I would rather see them only from within the product's own realm.

It'd be nice if you could start a discussion thread on this subject via dev@bloodhound.apache.org ML

Besides that, Bloodhound is also WIP and far from complete.

As for the schism, I think that the original trac can incorporate some ideas and improve on them, for example true multiple project support by which I mean that each project has its own set of repositories.

Bloodhound aims at providing support for both isolation and sharing . Depending on the type of resource one of them prevails over the other . Repositories are owned by the global environment mainly for efficient changeset synchronization and m..n product-repository relationships.

Most other resources are isolated inside a product environment . Indeed another type of resource that has tricky shared vs isolated semantics is milestones , but n ot limited to that . Should you have any concrete proposal to improve current support , we'd definitely like to hear about that .

Apart from that, multi product support per project would be nice as in product being an uber-component that features one or multiple components.

Using Bloodhound it is possible to setup multiple environments , each having a number of products .

[Olemis Lang <olemis+trac@…>]

Replying to falkb@…:

Replying to anonymous:

[…]

I don't like the term 'product' used in Bloodhound since a product is the result of a project

Just a name … the important thing is the meaning behind it .

[…]

The term 'project' describes the process

… indeed that depends on the vocabulary

[…]

[falkb@…]

Replying to Olemis Lang <olemis+trac@…>:

Replying to falkb@…:

I don't like the term 'product' used in Bloodhound since a product is the result of a project

Just a name … the important thing is the meaning behind it .

I've learned the name is one of the first most important steps for acceptance. I already have always big trouble to explain Trac's 'milestone' as just a common name for a (possibly dated) group of tickets since a milestone actually is something more special for most people here (see ISO9001).

[Olemis Lang <olemis+trac@…>]

Replying to falkb@…:

Replying to Olemis Lang <olemis+trac@…>:

Replying to falkb@…:

I don't like the term 'product' used in Bloodhound since a product is the result of a project

Just a name … the important thing is the meaning behind it .

I've learned the name is one of the first most important steps for acceptance. I already have always big trouble to explain Trac's 'milestone' as just a common name for a (possibly dated) group of tickets since a milestone actually is something more special for most people here (see ISO9001).

You make a good point . I've felt the same in a national committee when translating ISO 9001 std into Spanish language as well .

JFTR , the decision for product as a name is documented in BH incubator ML archives , and project was not a suitable name , afaicr . I'm just curious , if project is not an option what would be your suggestion preferred over product ?

[falkb@…]

Replying to Olemis Lang <olemis+trac@…>:

I'm just curious , if project is not an option what would be your suggestion preferred over product ?

Find synonyms ​here but there's nothing which hits the nail on the head. IMHO one needs to find a term that describes a process, but people must be used to it.

I slightly wonder why project isn't an option if the main topic is multi-project support. Maybe you wanted to distinguish from Trac instance which is often mixed up with project, although a single Trac instance has just been equipollent to a single project because it lacks multi-project support.

[Olemis Lang <olemis+trac@…>]

Replying to falkb@…:

Replying to Olemis Lang <olemis+trac@…>:

I'm just curious , if project is not an option what would be your suggestion preferred over product ?

Find synonyms ​here but there's nothing which hits the nail on the head. IMHO one needs to find a term that describes a process, but people must be used to it.

I slightly wonder why project isn't an option if the main topic is multi-project support. Maybe you wanted to distinguish from Trac instance which is often mixed up with project, although a single Trac instance has just been equipollent to a single project because it lacks multi-project support.

I was just making a comment abouot BH decision . Related conversations are documented in BH incubator mailing list archive .

[figaro]

Downgrading severity as there are workarounds available:

• ​https://trac-hacks.org/tags/multi-projects?wiki=on
• TracMultipleProjects

[anonymous]

Considering that #130 was opened 13 years ago and this is still not in trac is kinda sad :-(

Has 64 Votes….: https://trac.edgewall.org/wiki/SeaChange/WhatUsersWant

Please make this happen

[anonymous]

In #13024 there are patches for adding a project table, project admin, and project columns for the ticket, version and milestone tables.

[anonymous]

Replying to Ryan J Ollos:

You could raise the topic on the trac-dev MailingList, but in general I don't favor adding little pieces of multi-project without a definite plan for implementing the whole feature. The feature will be a huge amount of work and there are many design decisions to be made, which is why it hasn't been done yet.

If you want to make some contributions to Trac there are many things you could work on that have a more reasonable scope. Let me know if you want suggestions.

Thank you for the reply. What's the required scope for the multi-project feature in your opinion? I thought it is not a very large amount of work at all. As outlined in #13024 the entire plan is just 5 steps:

1. Add a project table.
2. Add a project column to the ticket table.
3. Add admin panel and admin commands to manage the projects.
4. Add milestone.project and version.project columns.
5. Filter milestones and versions by the ticket's current project.

Everything else smells of feature creep and analysis paralysis.

I prefer to discuss here if possible, and work on high impact features not inconsequential details. But it is of course your choice if you accept it. Please explain your absolute minimal requirements for multi-project topic, thanks.

[anonymous]

I think you guys want to implement what ​SimpleMultiProjectPlugin of trac-hacks does, and that is a very good plan!

[Kurt.Schultze@…]

Do you have screenshots of the changes the patches do?

[Kurt.Schultze@…]

Looks very good. How does the project filter box of milestones look like? Do you also have implemented the timeline filter as well?

[anonymous]

Updated patches in #13024.

I currently do not plan to add a timeline or roadmap filter.