[Sugar-devel] Introducing sugar-build

[Daniel Narvaez]

Hi Bernie,

thanks for your feedback. This gives me a chance to explain where the idea
of sugar-build came from and where I see it going in the longer term.

I actually started to look into the issue from Marco's sugar-core. I think
in an ideal world that's what we would want to have right now. And I think
that should be the medium/long term goal.

Though I don't think we can get there in a single step.

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

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.

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

Here is how I see sugar-build differ from sugar-core.

* We are building a few external dependencies. I think this the worst of
the problems but there is nothing we can about it at the moment. Other then
trying to limit damage as much as possible,  as I explained in the
rationale.
* We are pulling modules from separatare sugar-* repository rather than
from an omnibus one. As I said I hope we can actually merge everyhing in a
single repository at some point, it will be easier and cleaner. Though, in
terms of reliability I don't really think this will make much of a
difference. They are pulled from the same server anyway.

I think we need to accept these two limitations in the short time and focus
on other pieces that will be necessary for the full sugar-core "vision".
Complete base system dependencies checking and build automation in first
place. Without those sugar-core is not going to accomplish much anyway.

Thanks,
Daniel

On 15 June 2012 04:20, Bernie Innocenti <bernie at sugarlabs.org> wrote:

> On Thu, 2012-06-14 at 12:06 +0200, Daniel Narvaez wrote:
> > * I think these tools are used by few people because they don't work
> > well. I know despite having a lot of experience with GNOME and linux
> > builds I was highly frustrated by sugar-jhbuild complexity and
> > unreliability. I'm sure a lot of people have been in that situation
> > and gave up. This is not to pick on sugar-jhbuild, as I said in
> > rationale it's a very difficult issue to solve. Mine is another
> > try.and I agree with who said competition is good here.
>
> This is also my experience, and I saw several developers at deployments
> who were struggling to build Sugar from source in jhbuild.
>
> I used to believe jhbuild could be improved in incremental steps, by
> shaving off dependencies and removing complexity here and there, but
> after several years it's still very fragile.
>
> The hardest issue seems to be finding consensus among the developers on
> one of the solutions. My preference would be towards merging all the
> glucose modules into a single repository that could be built with the
> familiar sequence of commands "configure && make && make install".
>
> This is basically what sugar-core [1] already did 2 years ago. It was
> created by Marco Pesenti Gritti based upon an earlier proposal of
> Michael Stone [2].
>
> Both of them had had enough of fighting jhbuild and wanted something
> simple and clean by merging the repositories. Michael's proposal was
> more radical because it also replaced the autoconf build system with a
> hand-made configure script and a hand-made Makefile, both very short.
> I'm not sure I'd go that far, but it was a tempting idea.
>
>
> [1] http://sugar.marcopg.org/intro.html#build-from-source-code
> [2] http://dev.laptop.org/git/users/mstone/sugar/
>
>
> > * Maintenance of these tools has an high cost but losing talented
> > contributors because they are unable to get the thing to build is a
> > much much higher one. Also, many of the design choices in sugar-build
> > intends to reduce maintenance cost (which I think in turn will favor
> > reliability).
>
> I couldn't agree more on your motives, but I think that jhbuild simply
> deserves to die. Wrapping it with something easier to use can be a
> temporary solution, but it can't eliminate all the underlaying
> complexity of repeated network operations to fetch code from disparate
> repositories.
>
> --
> Bernie Innocenti
> Sugar Labs Infrastructure Team
> http://wiki.sugarlabs.org/go/Infrastructure_Team
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20120615/9686a47f/attachment-0001.html>