Consider subproject organization of the Gromacs project
Currently, there are two subprojects, "Source code reorganization" and "Next-generation analysis tools", under the main Gromacs project. When these were created when Redmine was taken into use, I don't think there was any serious consideration on whether that would be the best thing to do. They have served relatively well for organizing issues under these categories. But they add to the management burden (e.g., the list of developers for the different subprojects needs to be managed separately from the main Gromacs project), and then there are issues like #646... Also, there is some overlap between the two, and if/when development of the main Gromacs project moves towards 5.0, it will start to overlap more and more with these subprojects.
I think it would be worth to consider whether these subprojects could be merged to the main project. This might require tuning issue fields such that there would be natural categories for the issues that are currently in these subprojects, but that could be worth doing anyway.
#2 Updated by Teemu Murtola almost 7 years ago
Since there has been no activity, here are some additional thoughts.I would suggest that we add a few new issue categories to the main Gromacs project:
- selections for anything related to the core selection functionality
- core library for things that are shared between all the code
- unit tests for general issues related to unit testing
- analysis library for things shared between analysis tools (stuff can also go under the existing analysis tools)
With these added, I think it would be possible to find a new home for the issues that are currently under the two mentioned subprojects, and then just delete the subprojects. There are currently about 40 issues in total in these subprojects, so the transfer could even be done one-by-one by hand if necessary.
In general, it would also be useful to consider (and document somewhere) what the subproject pages are really meant for. For development that is taking place in the main repository, they seem to create more trouble than they are worth.
#3 Updated by Teemu Murtola almost 6 years ago
- Priority changed from Normal to Low
The upgrade to a newer redmine version alleviates the most serious problems: duplicate commit linking seems to be gone, and it is possible to inherit members for a subproject from the main project. It could still be worth to move the issues under the main project for clarity (it is not always clear where an issue belongs), but that is less important, so changed the priority to low.
#6 Updated by Teemu Murtola almost 5 years ago
- Status changed from New to Resolved
I now moved all the issues, actually putting some thought into what category each item should go to to make it actually possible to later find the issues... I closed the projects; not sure if there is a more permanent way, but probably I do not have the rights.
The extra categories have been there forever now (much earlier than Rossen's post here), and there were default assignees for all of them. But apparently someone though this a bad idea, since all the default assignees are now gone... But that's a separate discussion that I think is not going to lead anywhere, since no one appears to have time to actually use redmine, except to clean up obsolete issues before each major release,c so it doesn't really matter what happens in between...