Edgewall Software
Modify

Opened 2 years ago

Last modified 10 months ago

#11025 new enhancement

Multi-project support

Reported by: cboos Owned by:
Priority: normal Milestone: topic-multiproject
Component: general Version:
Severity: critical Keywords: multiproject
Cc: leho@…, fbrettschneider@…, alex@…, avolf@…, itamarost@…, mpauli@…, deb.aelwyn@…, slav0nic0@…, olemis+trac@…
Release Notes:
API Changes:

Description

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:

Alternative solutions, as Trac plugins:

Alternative solutions (… or source of inspiration!):

Attachments (0)

Change History (29)

comment:1 Changed 2 years ago by lkraav <leho@…>

  • Cc leho@… added

comment:2 in reply to: ↑ description Changed 2 years ago by fbrettschneider@…

  • Cc fbrettschneider@… added

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.

comment:3 Changed 2 years ago by cboos

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

comment:4 Changed 2 years ago by 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.

comment:5 follow-up: Changed 2 years ago by lkraav <leho@…>

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

comment:6 Changed 2 years ago by alex@…

  • Cc alex@… added

comment:7 Changed 2 years ago by Ryan J Ollos <ryan.j.ollos@…>

  • Cc ryan.j.ollos@… added

comment:8 Changed 2 years ago by avolf@…

  • Cc avolf@… added

comment:9 Changed 23 months ago by itamaro

  • Cc itamarost@… added

comment:10 Changed 23 months ago by anonymous

comment:11 Changed 23 months ago by mpauli@…

  • Cc mpauli@… added

comment:12 Changed 23 months ago by mpauli@…

  • Cc mpauli@… added

comment:13 Changed 23 months ago by cboos

  • Milestone changed from next-major-releases to topic-multiproject

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.

comment:14 in reply to: ↑ 5 Changed 23 months ago by cboos

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.

comment:15 Changed 23 months ago by deb.aelwyn@…

  • Cc deb.aelwyn@… added

comment:16 Changed 22 months ago by slav0nic0@…

  • Cc slav0nic0@… added

comment:17 Changed 15 months ago by jonathan@…

  • Cc jonathan@… added

comment:18 follow-up: Changed 14 months ago by 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.

comment:19 in reply to: ↑ 18 ; follow-ups: Changed 10 months ago by 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.

comment:20 Changed 10 months ago by rjollos

  • Cc ryan.j.ollos@… removed

comment:21 in reply to: ↑ 19 ; follow-up: Changed 10 months ago by 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.

comment:22 in reply to: ↑ 19 Changed 10 months ago by 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 .

comment:23 in reply to: ↑ 21 ; follow-up: Changed 10 months ago by 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

[…]

comment:24 Changed 10 months ago by Olemis Lang <olemis+trac@…>

  • Cc olemis+trac@… added

comment:25 in reply to: ↑ 23 ; follow-up: Changed 10 months ago by 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).

comment:26 Changed 10 months ago by jonathan@…

  • Cc jonathan@… removed

comment:27 in reply to: ↑ 25 ; follow-up: Changed 10 months ago by 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 ?

comment:28 in reply to: ↑ 27 ; follow-up: Changed 10 months ago by 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.

comment:29 in reply to: ↑ 28 Changed 10 months ago by 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 .

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.