So from a quick look at MCConfigBrowser, I gather that Impara uses it to define, enlarge, and occasionally tweak the load order of the packages in its configuration.
Do you guys have one overall configuration, or multiple disjoint configurations, or some other combination?
I'm thinking about the desired workflow.
So when someone wants to submit a change that crosses package boundaries, we want them to upload the relevant package versions somewhere public, then create a configuration (using MCC browser) including only those relevant packages versions (*), then upload the configuration to a public repository, maybe the inbox one.
Then anyone wanting to integrate that change (for example, Harvesters) should be able to: 1. Load that configuration into his image, 2. Copy just the versions in the configuration into his repository (to add them to what people get implicitly when upgrading from that repository), and 3. Add the configuration as an update, to make it an explicit upgrade. This would handle the case where two or more configurations are sent as a bootstrap. Should at this point the configuration be expanded to include all the current versions of relevant packages? I'm not sure.
Does this sound like a sane way to manage an image?
Daniel (*) another option is for them to create a configuration including many other packages, but that seems to require remembering what packages are parts of what distributions, which seems wrong to me...