On Tue, 20 May 2014, David Cheney wrote: > > A possible plan is as follow: > > > > 1) Migrate juju-core/thirdparty to juju/thirdparty (Github). > > Since there are no dependencies here, this seems to be a good first > > candidate. > > nac, these are out horrors. The code we forked should either be pushed > back upstream, and/or captured by godeps. I think the whole thirdparty > thing happened before we had godeps.
Good to know, we can investigate. > > 4) Migrate juju-core/charm. This has some pre-requisites. Basically IIUC > > charm defines config and meta and those definitions are tangled with the > > underlaying Mongo documents. William suggested to decouple that, > > implementing separate data structures to be used to (de)serialize data. > > This way, changes to charm database structure can be detected earlier and > > core developers are able to react accordingly. Soon this could also involve > > actions data. > > I don't see the value in splitting off this repo unless you need it > for the store. I think we'll want it as we'll be doing validation and such. This one will take the most care and investigation as what a charm is to the store should match what core expects from the charm. Thanks for the feedback. -- Rick Harding -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
