Redmine

Hi Brenton

Not sure if this will help, but I might have something similar. I have one root project named 'Product'. For this project, we have 3 different sub projects: 'Web service', 'UI 1' and 'UI 2'

The advantage of doing this is that you can add issues to the root project and the root project will also see all the activities from the child projects. I.e. if I create an issue at Web services it will show in the root.

In your case, you could probably have a root project named 'Product', then a Facebook sub project and in the Facebook project you would have the other sub projects such as IPhone and android apps.

But I do understand your idea of shared it would facilitate the management of tasks across multiple projects.

Another suggestion to improve Redmine in the same line is to allow adding sub tasks relating to different projects (or maybe a link task option). E.g. one parent task in the parent project and different sub tasks that belongs to child projects. This way you could link one main task to various tasks in different projects.

Cheers
Douglas

Douglas.. thanks for the feedback! Unfortunately, subprojecting like you suggest only works when there is only one "meta-project". For instance, Marketing will call that we add geolocation services to the mobile apps at the same time as we are color rebranding all three applications. In this case, I would need two "meta-projects" that share into my others.

On your last point.. I maybe the "related issues" feature in Redmine would meet your requirements?

Cheers

I'd like to introduce a second use for "shared issues". We have a code framework that is used in two of our products. Any changes in this framework affects the other two products. It would be amazing if we could share the issues and versions from the framework product into the other dependent products. This way I could see that Product A Ver. 1.0 is to compiled with version X of the framework and Product B Ver. 1.0 is to be compiled with version Y of the framework product. I could also see the minimum release date for Product B, since it is dependent on issues/versions of the Framework product.

etc. etc. etc.

I'm willing to pay a developer to implement something like this with a plugin. Anyone interested, say AY.

+1 for this.

We have several "library" projects, and several applications ("top-level projects") depending on the libraries. For example:

- "Library projects":
    - Driver for device 1
    - Driver for device 2
    - Data saving mechanism
    - Data calculation library
    - Yet another library
  - Applications, which depend on most or all of the libraries:
    - Application 1
    - Application 2
    - Application 3

What can happen is that an issue gets reported on Application 1. Closer investigation shows that the bug is actually in the "Data saving mechanism" library. Ok, let's raise an issue in that library and fix it. But also Application 2 depends on the "Data saving mechanism" library, so the fixed issue should be seen also from there.

Any ideas how to set up Redmine to work nicely with this kind of "dependency tree"? Granted, this is messy, but that's why we would need some kind of formal issue management in the first place.

Best Regards,
Joonas

Another way to solve this (somehow, at least) would be to extend the current concept of "Subproject". Currently, a project can be a subproject of at most one project. If a project could be a subproject of an arbitrary number of other projects, then all kind of dependency trees could be built.

Would this make any sense?

I'm exploring the share functionality for Versions. It is helping. But I would still like to see a way to configure "Project A Ver. 1" depends on "Project C Ver. 3".

This is a great idea, especially allowing projects to be a subproject of an arbitrary number of other projects.

The problem I have been looking to solve with a tool like Redmine is as follows. We are mostly a C/C++ shop and have numerous components. From time to time we have certain customer driven "Programs" which we must put through our process and use a number of the Components. Therefore, we might get:

Program A uses

Component A

Component B

Component C

Program B uses

Component A

Component B

Component Z

We have on-going projects for all the components, and those resources are usually concentrating just on those. But we also have Program resources concentrating on the projects that integrate the components together.

So if Program A finds a bug in component B, we should be able to file it in Program A and assign it to component B. Then, it should show up as an issue when looking at Program A's issues as well as when looking at component A's issues. It should not show up in Program B's issues, as that Program can have its own issues registered with component A.

The nesting depth should not be limited to 1, any component might also refer to other shared components. The actual assignment of issues could be limited to 1, where each parent can only assigned to the next level down. Then, when the team at the next level down reviews the issue, they can optionally assign it down the next level of dependencies until it is at the proper place.

This seems like it could be achievable with multiple parents for each project. Maybe the relation would only be from top down, a subproject probably doesn't need to know that there are so many parents other than one possible functional parent, as supported today.

I hope this makes sense!

See Feature #5283 for details on improvements on the workflows and problems described above.

This is how I handle the problem described above: * 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).

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.

Hi,

Reading above, I would like to share my thoughts:

I think that parent-child relations may be used for creating hierarchical structure of projects. This structure is convenient par example when the project has different works to be done: software, hardware, mechanics etc.

The mentioned above components are separated from and not dependent on the project that uses them. So, I think, they cannot be put in the hierarchical structure of the project. Instead, a new relation could be created - "related projects" or "library projects" or "component projects". So what about this scenario:

1. Create component projects - as many as we need and develop them independently.
2. Create application project and its hierarchy.
3. Add related projects to this project (1:many relation)

• the issues from related project may be shown or not shown in the issues list of the main projects.
• when changing issue in component project, these changes are immediately seen in the main projects.
• while working on a main project, if an issue arises in a component then users could select a related project for such an issue (Of course, someone may go to the related project and create the issue there and the result should be same.).

I think that more options and scenarios could be thought up.