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

[Sascha Silbe]

Excerpts from Tomeu Vizoso's message of Thu Sep 02 18:33:51 +0200 2010:

[repo to push to after review, for maintainers to choose from]
> > We could rebase after each release, like (at least some of) the Linux
> > folks are doing. Either on the master branch, or by creating a new
> > branch for each release (like the OLPC kernel repo).
> 
> Sounds good.

OK, to get this started, I cloned the repositories of sugar-artwork,
sugar-base, sugar-datastore, sugar-toolkit and sugar. For lack of a
better name, I chose "next". Let's start with the rebasing approach
(i.e. use the "master" branch); we can switch to the branch model if it
turns out that rebasing causes too much of a headache.

Will go through Patchwork and check for any patches of mine that have
enough Reviewed-By to push them.

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.

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

Obviously the catch is that somebody will have to do the work of
analysing the source code, deciding on good split points (i.e. new
packages) and implement it...

> I for one liked having patch submission and reviews in the same
> channel as we discuss other development stuff. But will subscribe to
> another mailing list if needed.

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.

Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20100902/3b62c3e3/attachment.pgp