Whats the actual upstream, and what do you want users to have
available in terms of Debian packages?
Ok, I think I have worked out it now, however will just summarize more details here.
Lets say I maintain a project called "karaage"[1].
To try and be flexible, lets say I split up some parts of Karaage into plugins[2]; I split them up into separate git source, hence separate distributable and packages. This is because some plugins are not needed by some installations, and require large dependencies (e.g. matplotlib), of which some don't have Python 3 packages in wheezy (and not easy to fix this due to old Python 3 in wheezy).
ie. karaage contains the karaage python package, karaage-applications contains the kgapplications python package, etc.
This worked well, it was possible to install only the plugins you needed, and you can manually change the configuration to enable or disable them.
Then, one of the hypothetical users of this hypothetical project subcontracted a hypothetical development company to do hypothetical development of the project in a direction that suited their hypothetical business needs. This is fine, it is open source software, I am perfectly happy with this. At the time they promised that they were going to work with me to make sure I was happy with the changes, and all users would eventually benefit. They created their own fork to do this development[3].
However this development team made the decision, without consulting me, to combine all the plugins into one git repository. They made the argument that is was easier to test having all the packages exist in the CWD. eg. karaage now contains ./karaage, ./karaage-applications, etc.
However, unfortunately, they seem to have neglected to deal some issues, like not having to install the dependencies for these plugins (especially for Debian package), or being able to disable a plugin (since they also coded autodetection of installed plugins[4]), or being able to automatically test the base package with and without the plugins installed.
Since then, the user that was funding the development seems to have misjudged availability of funds, and funding for this development has dried up. As a result, it appears, I have lost contact with these developers too. So as the "official maintainer", I was trying to decide if it is worth persisting with this new combined source code.
I am inclined to keep the structure as unchanged from how I have it - separate git repositories for the different plugins - I think that is the simplest approach - it also means I can use their autodetection code[4] (still trying to decide if that actually is a good idea or not). Sure, there are other solutions, I currently think this is the simplest one.
I hope this helps explain the situation, without getting too far off-topic for this mailing list.
I think the concept of plugins might be relevant to other projects, not just this one.
Notes [1] not to be confused with the delicious Japanese meal available from the restaurant around the corner, or with https://github.com/karaage-cluster/karaage/ which is a project I maintain.