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 <div class="gmail_quote">On 15 June 2012 04:20, Bernie Innocenti <<a href="mailto:bernie@sugarlabs.org" target="_blank">bernie@sugarlabs.org</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im">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. </div>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] <a href="http://sugar.marcopg.org/intro.html#build-from-source-code" target="_blank">http://sugar.marcopg.org/intro.html#build-from-source-code</a> [2] <a href="http://dev.laptop.org/git/users/mstone/sugar/" target="_blank">http://dev.laptop.org/git/users/mstone/sugar/</a> <div class="im"> > * 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). </div>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 <a href="http://wiki.sugarlabs.org/go/Infrastructure_Team" target="_blank">http://wiki.sugarlabs.org/go/Infrastructure_Team</a> </blockquote></div>