Proposed Workflow

[Daniel Vainsencher]

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...