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/
signature.asc
Description: PGP signature
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel