Changes between Version 15 and Version 16 of TracDev/Proposals/MultipleProject
- Timestamp:
- Mar 6, 2023, 11:25:02 AM (14 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TracDev/Proposals/MultipleProject
v15 v16 1 = Multi-Project Support for Trac =1 = Multi-Project Support for Trac 2 2 3 3 The current design of Trac associates one project to one environment. 4 4 5 More often than not, software projects tend to split themselves in separate sub-projects, sharing common libraries and components. In enterprise setups, it is practical to consolidate the development knowledge base in one Wiki, yet to be able manage the different products or family of products independently. Moreover developers are often working on different products at once, and would like to be able to have an overview of the different projects they're involved in. At other times, the same developers would like to have the ability to fully focus on a single project. Widening the scope and looking at a whole family of products or even at the entire set of projects is also useful when one wants to get an overview or doesn't know where to start searching for aninformation.5 Typically software projects tend to split themselves in separate sub-projects, sharing common libraries and components. In enterprise setups, it is practical to consolidate the development knowledge base in one Wiki, yet to be able manage the different products or family of products independently. Moreover developers are often working on multiple products at once, and would like to be able to have an overview of the projects they're involved in. At other times, the same developers would like to have the ability to fully focus on a single project. Widening the scope and looking at a whole family of products or even at the entire set of projects is also useful when one wants to get an overview or doesn't know where to start searching for information. 6 6 7 Trac has to be adaptable to these different views. The current approach of setting up different Trac environments only allows to get a fixed view on one project. By using InterTrac links, it is possible to relate resources one to another across Tracs, but the interaction and sharing of information couldn't go beyond linking: no common search or ticket queries, no shared timeline, no possibility to conveniently move resources from one project to the next while retaining the full history, etc. 7 8 8 Trac has to be adaptable to these different views. The current approach of setting up different Trac environments only allows to get a fixed view on one project. By using InterTrac links, it has been possible to relate resources one to another across Tracs, but the interaction and sharing of information couldn't go beyond linking: no common search or ticket queries, no shared timeline, no possibility to conveniently move resources from one project to the next while retaining the full history, etc. 9 10 In addition, for some database back-ends, the single project per environment design impose practical limits to the number of projects that can be run concurrently, due to connection sharing concerns (#8058). 9 In addition, for some database back-ends, the single project per environment design impose practical limits to the number of projects that can be run concurrently due to connection sharing concerns (#8058). 11 10 12 11 The next step is therefore to provide the ability to create multiple Trac projects and sub-projects inside a single environment and to offer some convenient ways to form "views" on which projects should be active for a given request. 13 12 14 In our usual tradition of backward compatibility, when an environment only contains the top-level project everything should continue to work like it always did. This will allow alternate implementations of multiple project setups to continue working unmodified (see the various TracMultipleProjects sub-pages, esp. TracMultipleProjects/SingleEnvironment which contains a proposal quite similar to this: adding a project field and a Projects table). 15 13 In our usual tradition of backward compatibility, when an environment only contains the top-level project everything should continue to work like it always did. This will allow alternate implementations of multiple project setups to continue working unmodified. See the various TracMultipleProjects sub-pages, esp. TracMultipleProjects/SingleEnvironment which contains a proposal quite similar to this: adding a project field and a Projects table. 16 14 17 15 == The Project Tree == #ProjectTree 18 16 19 17 A very natural way to group projects and sub-projects is to use a ''hierarchy'' of projects. 20 The top-level project contains all the other projects, the leaf projects can focus on some appropriate subset of the development activity (e.g. a given library) and the intermediate project nodes in this theproject tree are used to group related sub-projects together.18 The top-level project contains all the other projects, the leaf projects can focus on some appropriate subset of the development activity (e.g. a given library) and the intermediate project nodes in this project tree are used to group related sub-projects together. 21 19 22 20 This approach accommodates with the simplest case of the top-level project being the only project, supports quite well the situation of having many independent projects by creating all projects as sub-projects of the top-level project, but also scales to more complex development environments, e.g. where there are different families of products and possibly customer specific sub-projects for each of the products. … … 82 80 83 81 === Focal project 82 84 83 However the hierarchy can help to intuitively select a **meaningful subset** of the existing projects. 85 84 86 To complement the project selector user interface shown above, we could also have a simpler interface (a selection) which would allow the user to pick a project which becomes the **center of interest**. This means selecting not only that project, but also its ancestor projects and sub-projects .85 To complement the project selector user interface shown above, we could also have a simpler interface (a selection) which would allow the user to pick a project which becomes the **center of interest**. This means selecting not only that project, but also its ancestor projects and sub-projects: 87 86 88 87 {{{#!html … … 103 102 For example, if that center of interest is set to "//Family B//", then the selected projects will be the top-level one, "//Family B//" itself, "//product c//" and "//product d//", but not the siblings of "//Family B//", i.e. what has been hand-picked in the Project Selector example above. 104 103 105 Such a selection is meaningful because it usually makes sense to work at a given level and be interested in all what's happening in sub-projects but also to be aware of issues happening at higher level which may impact the current project and sub-projects as well. 104 Such a selection is meaningful because it usually makes sense to work at a given level and be interested in all what's happening in sub-projects but also to be aware of issues happening at higher level which may impact the current project and sub-projects as well. 106 105 107 106 In practice and for this example, this means that when looking for tickets, one would see all the tickets associated with sub-projects ("//products c//" and "//project d//"), but also tickets directly associated with the "//Family B//" project (e.g. installer issues), and tickets directly associated with the top-level project (e.g. bugs in the web site shared by all projects). 108 107 109 In the end, this is mainly a matter of user interface, and picking up any other subset of projects should be easilypossible as well by just toggling a few checkboxes. Among other things, it should be possible to select ''only'' "//Family B//" without selecting its ancestor projects or sub-projects, to consider only tickets directly associated with this level.108 In the end, this is mainly a matter of user interface, and picking up any other subset of projects should be possible as well by just toggling a few checkboxes. Among other things, it should be possible to select ''only'' "//Family B//" without selecting its ancestor projects or sub-projects, to consider only tickets directly associated with this level. 110 109 111 110 === Projects and milestones, versions, ... 111 112 112 On a different level, the hierarchy can also be used to organize resource sharing between projects. For example, in the Ticket system we could imagine that milestones belonging to ancestor projects are also visible in their sub-projects. In our hierarchy example above, imagine setting up a milestone for a "//B-1//" release in the "//Family B//" project. In sub-projects "//product c//" and "//product d//", no redundant milestone setup needs to be created, "//product c//" issues could be directly targeted to this "//B-1//" milestone. 113 113 114 114 In the typical center-of-interest setup, looking at the roadmap when "//Family B/product_c//" is the center of interest, the "//B-1//" milestone will show up and the tickets for "//Family B/product_c//", "//Family B//" and top-level "/////" will be shown. The tickets for "//Family B/product_d//" on the other hand won't be visible in that view. 115 115 116 Conversely, when "//Family B//" is the center of interest, the "//B-1//" milestone will show the tickets for "//Family B/product_c//" and "//Family B/product_d//" (all the sub-projects), "//Family B//" itself and the top-level ones associated to this milestone. One can see that this could involve the possibility of having multiple target milestones for a ticket (e.g. a top-level ticket needed for milestone "//B-1//" and "//A-1//").116 Conversely, when "//Family B//" is the center of interest, the "//B-1//" milestone will show the tickets for "//Family B/product_c//" and "//Family B/product_d//" (all the sub-projects), "//Family B//" itself and the top-level ones associated to this milestone. One can see that this could involve the possibility of having multiple target milestones for a ticket, for example a top-level ticket needed for milestone "//B-1//" and "//A-1//". 117 117 118 118 In case the project selection is restricted to "//Family B//" alone (no ancestors, no sub-projects), then the "//B-1//" milestone will naturally only show the tickets belonging to the "//Family B//" project. … … 122 122 With the "focal project" model, the users will also have a clear guideline for selecting which project should be associated with their resource (be it a ticket, wiki page, milestone, version, component, etc.): the project level at which the given resource is relevant for that project and //all the sub-projects of that project//. Or put differently, you could start with a leaf project and go up until the item is no longer relevant to all the sibling projects of the last level considered. 123 123 124 At this early stage of the proposal, this organization seems to be at the same time simple, intuitive yet very powerful. 125 124 At this early stage of the proposal, this organization seems to be simple and intuitive, yet very powerful. 126 125 127 126 == The Data Model == #DataModel 128 127 129 The main idea is to associate a resource to one or several projects. 130 131 This can be achieved by using an extra project association table for each resource. 128 The main idea is to associate a resource to one or several projects. This can be achieved by using an extra project association table for each resource. 132 129 133 130 Some resources might be only indirectly related to a project, like the Changeset and Source which belong to a given repository (see MultiRepos). The repository object itself might be related to some projects. … … 140 137 141 138 ||||||||||||||||||= Project || 142 ||= field || uid || id || Parent || summary || description || Creator || created || status || 139 ||= field || uid || id || Parent || summary || description || Creator || created || status || 143 140 ||= DB type || int || text || int || text || text || int || int64 || text || 144 141 ||= subtype || key || plain || references Project || wiki || wiki || references User || usecs || plain? || … … 149 146 On the API side, the multi-project nature will be mostly transparent except when instantiating and manipulating resources. Legacy resources and legacy code not taking the project into account will simply fallback to accessing resources at the global level. 150 147 151 152 == Web User Interface Changes == 148 == Web User Interface Changes 153 149 154 150 There should a standard way to change the current list of active projects: typically that would be a pull-down menu as described in [#Focalproject] above, somewhere near the top-left corner, for Mantis refugees. Next to this simple selector should be a (+) link to open a more advanced project selector ([#ProjectTree]) showing the projects "pre-selected" by the choice of the focal project, but in which additional projects could be opted in or others could be deselected. … … 158 154 An admin module can be used to create new projects (eventually copying settings from another one), renaming projects and deleting them. 159 155 160 Existing modules should progressively be made project aware and will filter their content according to the current selection of projects, perhaps highlighting specially the resources pertaining to the focal project.156 Existing modules should progressively be made project aware and will filter their content according to the current selection of projects, perhaps highlighting the resources pertaining to the focal project. 161 157 162 == Utilities ==158 == Utilities 163 159 164 160 Scripts for importing and exporting projects between environments should be provided. 165 161 This can be useful for archiving a project before deleting it, for merging multiple single environment Tracs into one, etc. 166 162 167 == URL space for different projects ==163 == URL space for different projects 168 164 169 165 Several kinds of mappings can be defined for mapping URLs to projects, before normal request dispatching takes place. 170 166 The two default ones are: 171 167 - '''host mapping''': the name of the (virtual) host used to access the Trac environment is taken to be the name of the project. A given ''host'' can be configured to be an alias for the default, top-level project. 172 - 168 - '''prefix mapping''': if the PATH_INFO starts with the name of a project, this will be taken to be the name of a project. If none such project is detected, then the request is targeted at the top-level project. 173 169 174 170 In addition to a single project specification, there can sometimes also be multi-project specifications in a given URL. The request parameter 'project' can contain more than one project, and if the request processor can take advantage of this, the scope of the request will cover those projects. The special value '*' can be used to cover ''all'' the projects and more generally can be used in a glob pattern to cover different projects at once, and a '!' prefix for a project name or pattern can be used to exclude those projects. Typical users of multi-project specifications are the Timeline, the Search, the Custom Query... 175 171 176 177 == Data Sharing == 172 == Data Sharing 178 173 179 174 As briefly mentioned above, some data structure will be accessible globally and are shared between project. … … 186 181 === Workflow 187 182 188 The question came up whether workflow should be per-project, or per-project group ...and how to reuse them (ticket:130#comment:157 and follow-up).183 The question came up whether workflow should be per-project, or per-project group and how to reuse them (ticket:130#comment:157 and follow-up). 189 184 190 185 Having one workflow per project could quickly make the maintenance of workflows quite complex. To balance this complexity, in hierarchical setups, one could define a workflow at the upper level, and have sub-projects use the workflow defined closest in the hierarchy. For example, one could define a workflow on the root project, and every other project uses this. If one exception has to be defined for a given project, that project can define its own. 191 186 192 Alternatively (ticket:130#comment:159), workflows could be defined as independent entities, and a project will have to be associated to a given workflow (a bit like repositories will be associated to projects). Having workflows as separate entities would allow 187 Alternatively (ticket:130#comment:159), workflows could be defined as independent entities, and a project will have to be associated to a given workflow (a bit like repositories will be associated to projects). Having workflows as separate entities would allow: 193 188 - sharing the same workflow between different projects, but still having the possibility to set another workflow for some specific projects; 194 - (might) allow (the user?) to specify explicit ely how to manage moving a ticket from one installed workflow to another installed workflow - whatever the project;195 - ease sharing workflows between users: having workflows encapsulated encourages implementation of several generic workflow solutions (that can be easily tweaked for specific use) that could be worked and provided by default or in a file repository - that would even ease to choose the starting workflow of a new T RACuser because he could easily choose a base workflow instead of having to hack the default one, simply adding modifications each time it seems required;189 - (might) allow (the user?) to specify explicitly how to manage moving a ticket from one installed workflow to another installed workflow - whatever the project; 190 - ease sharing workflows between users: having workflows encapsulated encourages implementation of several generic workflow solutions (that can be easily tweaked for specific use) that could be worked and provided by default or in a file repository - that would even ease to choose the starting workflow of a new Trac user because he could easily choose a base workflow instead of having to hack the default one, simply adding modifications each time it seems required; 196 191 197 192 Another option is a combination of both alternatives: 198 - Workflows are independent entities, that can be associated to projects, resource-realms, resource-types, and maybe even specific resources (I'm using "resources" instead of "tickets" in order to strive towards GenericTrac :-)).193 - Workflows are independent entities, that can be associated to projects, resource-realms, resource-types, and maybe even specific resources (I'm using "resources" instead of "tickets" in order to strive towards GenericTrac). 199 194 - When a workflow is needed for a specific resource, the workflow used is chosen to be the workflow entity that is the closest to the resource in the hierarchy.