[Sugar-devel] Patch review, combining/splitting modules (was: Re: Patch review)

[Marco Pesenti Gritti]

On 2 Sep 2010, at 21:21, Sascha Silbe <sascha-ml-reply-to-2010-2 at silbe.org> wrote:
> BTW, I've recently changed my mind on the repo-combining: We should work
> on splitting up our code, not combine it in a single repo. Our modules
> are too tightly coupled; sometimes even "from foo import bar" doesn't
> work (cyclic dependencies?). Let's factor out stuff like
> 
> - "Sugarised" / "improved" widgets (most of sugar.graphics?)
> - API wrappers (e.g. sugar.datastore.datastore)
> - Activity framework
> 
> and make them as self-contained as possible, with a layering approach.
> E.g. the activity framework would use the API wrappers, but the API
> wrappers would not depend (w.r.t. code) on anything else. The widgets
> also wouldn't depend on anything else; the Object Chooser widget
> should be in the Journal and the code to invoke it (currently
> sugar.graphics.objectchooser) should be in the API wrappers package.

Splitting in different packages can be helpful to mark more strongly the separation between components, but it's neither necessary nor sufficient to ensure proper modularity and decoupling. Our codebase is so tiny... Dependencies can be expressed just fine by the directories structure, without having to pay the maintenance and complexity costs of a gazillions of small packages.  

> As I gather from recent threads on sugar-devel Gnome will force some
> incompatibilities on us for Sugar 0.92 anyway, so now is a good time
> to do this split (as it will break API).

It's definitely a very good time to cleanup our API. Improving modularity would be awesome but I disagree it requires splitting packages even more.

> My hope is that having a separate list might lower the barrier of
> posting to it. People might feel more comfortable about posting
> unfinished / hacky stuff if there's a dedicated list for it instead of
> getting "exposed" on the main list. I don't know if it actually is a
> problem currently, but it's worth a try.

I would make damn sure we have a problem before considering to complicate processes and create new mailing lists because of it.

Cheers,
Marco