Paul Hammant wrote
Leo Simons wrote:b) absorbing of containerkit into Phoenix (giving it x.x.phoenix packages).
Given the speed the "common ground" discussions are taking I think this is the best compromise. I am a bit concerned about later backwards compatibility (if the final "common meta setup" we agree upon deviates a lot from the one currently used in containerkit/info/phoenix, it'll be a lot of work to get phoenix to support both).We're gong for a scrap current (meta-model) design right for uber right?
As far the meta subject is concerned I look at it as a process of evolving based on experience, requirements and concensus. I'm confident the what will come out of the process will leverage a lot of we already have and I'm also confident that the result will be different to what we have now - more of an evolutionary step forward. I also see this closely related to how the the containement architecture unfolds (keeping in mind that the meta is a small but intrinsically important part of a container solution).
<snip>
I'd also like to see some notice in the phoenix documentation that although the meta materials are stable codewise (and supported as such), we're not too sure about some aspects yet and thus that there may be big changes in future versions (as we already know this, users should know too :D).
I don't see why Phonix has to carry adverts for meta (which it does not use). Meta is in sandbox right?
I think the reference to "meta" (lowercase) above is in the context of "meta-model" development in general (i.e. its not referring to the Meta package).
Cheers, Steve.
--
Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
