[Sugar-devel] Introducing sugar-build

[Bernie Innocenti]

On Fri, 2012-06-15 at 14:16 +0200, Daniel Narvaez wrote:

> * We are still in the middle of the gobject-introspection/gtk3
> transition. Adding another bunch of invasive changes to the source
> repository would likely slow that work down and introduce more
> instability. We don't have enough resources to do both at the same
> time.

Agreed, this is probably not the best time. Still, soon or later we'll
have to agree that this is the direction we want to take and make a
coordinated effort to make it happen.


> * The reduction of the number of modules is happening somewhat
> naturally. sugar-base and sugar-presence-service are deprecated and at
> some point they will disappear. Merging gradually, while also
> refactoring where necessary, is likely to produce an higher quality
> outcome than just taking the code as is and dumping it all in a single
> repository.

Good point, but i feel that someone needs to take ownership of
completing the removal of sugar-presence-service and merging sugar-base
into sugar.

I've observed GCC being engulfed for years by incomplete transitions
which leave behind lots of deprecated code that can't be removed because
some obscure target still depends on it.


> * The port of the shell to gobject-introspection will require
> developers to build master of a few GNOME repositories. Even worst,
> the Sugar touch work will require to build gtk+ code which has yet to
> be written

Ouch. I hope any weird dependencies we have to add for touch support
will be at least optional.


> I also have a longer term concerns about the sugar-core approach.
> 
> * Are we actually going to get to a point where every external
> dependency we need for a certain development cycle will be available
> in a packaged form for the start of that cycle? I think the only
> realistic way to always ensure that's the case is to do developement
> that requires bleeding edge dependencies in separate branches and only
> merge them as soon those dependencies are packaged in the latest
> distributions. Though I think this kind of branching willl be too
> costy until the number of people hacking core sugar modules grow
> considerably. So we have a bit of a chicken and egg problem here.

True. I just hope that we continue to work closely with distributions to
get any new dependencies packaged quickly. At the same time, we should
resist the temptation of adding new dependencies to esoteric things that
nobody else uses.


> Anyway I consider sugar-build a pragmatic compromise between
> sugar-core and sugar-jhbuild. It's certainly not a wrapper around
> jhbuild. Think of jhbuild more like a tool that we use internally to
> pull and build modules (it can do that work fine and it's less code to
> write and maintain).

But we already forked jhbuild and wrapped it with something called
sjhbuild. The result isn't particularly pretty, but perhaps you could
fork sugar-jhbuild and implement your ideas directly there.

What I'm trying to avoid here is a solution that adds yet another layer
of indirection between the developer and the code being built.

> [...]

I've omitted the rest because I basically agree.

-- 
Bernie Innocenti
Sugar Labs Infrastructure Team
http://wiki.sugarlabs.org/go/Infrastructure_Team