On Thu, Jun 26, 2014 at 11:04 AM, Gustavo Niemeyer <gust...@niemeyer.net> wrote: > Hey Eric, > > Some comments below, offering a slightly different perspective to be > used as a data point in your quest.
That was totally helpful. And with the further discussion (thanks everyone!), I'm still hopeful that something good will come of this (besides the benefit to my understanding). :) In the end I'd argue that anything we can do (within reason) to make the code easier to understand is a win. That benefits not only newcomers to the code like myself, but the project as a whole; if done thoughtfully the code often ends up with better boundaries between components and between internal-/external-facing roles. Regarding understandability, I can't speak to what effort has gone into a complex system like juju (though I suspect it has been significant), but my experience thus far has been that the code (specifically the API code) in its current state hasn't been the easiest to follow. I expect the complexity of the system has a lot to do with that. From the discussion so far it sounds like there are things we can do about it, which is great! > For 3, splitting it off not only seems to needlessly increase the > maintenance burden, but also feels incorrect from the orthogonality > standpoint: state/api maps state into a public API, and is a critical > dependency for juju to work at all. Yeah, as William pointed out, splitting the API client out into its own repo would only make sense after distilling it down to the actual public-facing part. Anyway, thanks again for the insight! Everyone's been really helpful as I've been spinning up. -eric -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
