Redmine

+1 this would be very useful for projects that are being worked on by different organizations

Michael Koch wrote:

+1 this would be very useful for projects that are being worked on by different organizations

+1

+1

+1: exceptionally useful when working with sub-systems / components. For example:

• embedded-firewall: Embedded firewall project
  • sh3-bootloader: Generic bootloader for Renesas SH3 hardware platform
  • linux: linux kernel (Also used in remote-logger)
  • busybox: linux utilities (Also used in remote-logger)
  • apache2: Apache 2 web-server

• remote-logger: Remote event-logger project
  • arm-bootloader: Generic bootloader for the ARM9 hardware platform
  • linux: linux kernel (Also used in embedded-firewall)
  • busybox: linux utilities (Also used in embedded-firewall)

+ 1

On the user end, this could just look as it does, with the 'parent project' select box, except with an 'add more...' link below it to add multiple parent projects.

+1

+1

+1

We are currently considering redmine as a replacement for SharePoint.

As a company we have internal products that are shared amongst other products (such as libraries, utilities, etc.).
After much discussion it seems that the only thing holding us back from switching over is the ability to associate an existing (sub)project with a new (sub)project.

Pieter Smith gave a great example above of this.

I think this might (unfortunately) be a duplicate issue:
http://www.redmine.org/issues/298

As an afterthought, specifically it would be beneficial for us if projects were represented as:

Projects this project depends on:
1.
2.
3.

Projects that depend on this project:
1.
2.
3.

Obviously, both lists should be dynamic such that if a project was top level, it would not depend on anything; likewise, if a project was bottom level, it would not have any projects that depend on it.

Curious what it takes to get movement on an item like this. Not trying to be rude but this seems like it would be a great feature and we would really like to use it.

This has been explained as a many-to-many relationship between parent projects and subprojects. A concern was raised as to inherited attributes. Could it be that the project could inherit from the natural parent but not the adopted parent. Or, the subproject would be a super-set of the parent projects.

Rick Hunnicutt wrote:

Curious what it takes to get movement on an item like this. Not trying to be rude but this seems like it would be a great feature and we would really like to use it.

These weeks we're less than half a dozen people working actively on Redmine, and it's just a hobby for most of us. If you want it to be implemented, you can propose a patch (with tests), that's how open-source works ;-) There are so many great ideas here and so little time to implement them..

Moreover, duplicate #298 is marked as "Won't fix", and I must admit I agree : I don't really understand why it would be so interesting. For the moment there's not much inheritance implemented between parent and children projects, so it's just about a display thing ? If so you can simply make your plugin to customize what you want.

• create a category for the shared component in each project that uses the shared component
• create one top-level project for each shared component
• during release planning, bulk copy all issues of a particular category from the top-level project into the shared component project
• create a relation ('blocked by') from the original issue in the top-level project to the issue in the shared component project
• work occurs through the issue in the shared component project

When the shared component releases the copied issue, the top-level project has a new release that incorporates the new release of the shared component. In this release, the original issue in the top-level project is closed (to indicate that it was picked up by using the new release of the shared component).

• defect1 is filed under category 'busybox' in project 'embedded-firewall'
• defect2 is created by copying defect1 to the 'busybox' shared component project
• a relation is created: 'defect1 is blocked by defect2'
• work occurs in the 'busybox' repostory to fix defect1
• a fix for defect1 is implemented and it is released in 'busybox' version 2
• 'embedded-firewall' creates an issue, task1, to bring in 'busybox' version 2
• the parent of defect1 is set to task1
• when task1 is completed, defect1 is completed

This allows proper control and release of versions of shared components and works well for large software groups with complex dependencies. Yes, it's more effort to do this than some other workflows, but this work is necessary to properly manage and control shared components so that things do not get out of hand.

Note that we maintain a top level project called 'Shared Components'. Inside this top level project is a subproject for each shared component that is used in multiple projects. This helps keep the number of projects on the project page to a reasonable level.

One thing that helped us reduce the amount of effort for this workflow was to allow categories and relations to be automatically created when copying issues. This allows us to do bulk-copies that automatically create the desired relations (what would have been the most expensive effort for this workflow). See patch #7447 for this implementation.

Brian,

What you say makes sense. My question is, how do you handle this now from the remote logger project? Do you create a task under the next release of remote logger that has all the defects from the busy box release 2 as subtasks? Or, possibly just a link to the version?

Thanks!

Rick,

We would create a task to bring in 'busybox' version 2 into 'remote-logger'. Listing all the defects in 'busybox' version 2 as subtasks gives little benefit compared to the effort involved. Linking to version 2 would work, but not everyone would be able to follow the link. You would need visibility into the 'busybox' project.

Continuing with the names used in Pieter's example:

Generally speaking, we've found it to be rare when an issue in a 'busybox' that was discovered in 'embedded-firewall' needs to be visible from within the 'remote-logger' project. On occasion, a 'busybox' issue, say defect3, will be important enough that the owner of 'busybox' will broadcast the existence of defect3 to both 'remote-logger' and 'embedded-firewall'. Upon receipt of the broadcast, the owner of 'remote-logger' can choose to copy defect3 from 'busybox' if he or she wishes. The owner of 'remote-logger' can also choose to pro-actively sniff issues from 'busybox'. Generally, our software teams have full visibility to shared components, so visibility is not an issue for us.

Also, there's a typo in my original note: * defect1 is filed under category 'busybox' in project 'embedded-firewall' * defect2 is created by copying defect1 to the 'busybox' shared component project * a relation is created: 'defect1 is blocked by defect2' * work occurs in the 'busybox' repostory to fix defect2 * a fix for defect2 is implemented and it is released in 'busybox' version 2 * 'embedded-firewall' creates an issue, task1, to bring in 'busybox' version 2 * the parent of defect1 is set to task1 * when task1 is completed, defect1 is completed

• defect1 is filed under category 'busybox' in project 'embedded-firewall'
• defect2 is created by copying defect1 to the 'busybox' shared component project
• a relation is created: 'defect1 is blocked by defect2'
• work occurs in the 'busybox' repostory to fix defect2
• a fix for defect2 is implemented and it is released in 'busybox' version 2
• 'embedded-firewall' creates an issue, task1, to bring in 'busybox' version 2
• the parent of defect1 is set to task1
• when task1 is completed, defect1 is completed

Brian Lindahl's workflow doesn't solve my biggest concern: Redmine cannot natively model project dependencies when using shared components/sub-systems. Implementing this feature would solve the following concerns:

1. I cannot get a reliable overview of all components/sub-systems that a main project depends on in (At least not if a component is used by more than one main project).
2. I cannot get a reliable overview of all main projects that make use of a particular component/sub-system.
3. I cannot get an overview of all activities that are- or could be affecting a main project (E.g. using the activity tab).

I agree that Brian Lindahl's workflow offers a reasonable solution to release planning/management if that is of primary concern.

+1!

This feature would be interesting on my work environment.

I would also like to see this implemented. Here is a real case example:
We have two products P1 and P2, each with a dedicated team and a product manager.
We have a new customer, C, so a new project, with a project manager.
For this new project, we need to develop a new module for each product (M1 and M2).

I'd like to be able to create this as a sub project of P1 and P2. So the product maanger can see at a glance, for their product, what they have to do, including the M1 and M2.

Then, I'd lilke to be able to create a logical link between M1 and M2 and project C. So that the project manager of C can see, at a glance, what is related to his project (including M1 and M2).

How to configure:
- In a project settings, add an option "link to", where you can add new projects. (hre : go to C, add M1 and M2 as "virtual subproject"

How to use :
- When going to P1 project, you can see M1 as sub project (normal, M1 is a real subproject)
- When goign to C project, you can also see M1 (as as "virtual subproject").

Stephane David.. YES! Exactly what is needed. BUT.. it would be great (critical) to extend this functionality to Issues. We want to see the same issue as part of multiple Projects.

+1

+1

+1

+1
I am working for a company in the electronics development department and we are searching for a suitable solution to manage new projects.
I think redmine has the capability to fulfill our needs exept the part with the multiple parent projects for subprojects. We develop new pcbs for several customer projects and it would be a nice feature to see the progress of one pcb in all related projects to automatic calculate the resultant delay.

Can you please realize this feature to get redmine more suitable to the industrial needs?

Thank you in advance

+1. But what i really need is to put one issue in multiple projects:

For example: i have a customer-project and a product-project. If the customer has a problem with a product it's unclear where to put the issue, and it may very well be missed since those that use the customer-project may not use the product-project and vice versa.

+1!