Re: How do you hack on GNOME? How can we do better?

[Alberto Ruiz <aruiz gnome org>]

Hello Michael,

Another problem I didn't mention which is that sometime the checkout dir makes "make" go bonkers at some point even with jhbuild build -fac. It is quite often that I update my jhbuild setup after ages of not touching it and I have to basically "rm -rf * && git reset --hard" and configure again to get the build going again. Given how long it takes to jhbuild everything this is another extremely annoying point that we can't ensure won't hit people. You can't leave the thing building and go make a coffee, you have to work for the automation system instead of the other way around. It is really a disaster if you ask me that we enforce this on every GSoC student :/

Anyhow, why is it such a problem to resort to the latest buildable snapshot to work on a very specific modules? So say this libgit2 problem for instance: something broke in one module, I work on... say gedit. That depends on it. What are the chances of my modifications having a dependency on the stuff that was introduced while that module broke? the master/HEAD of any given module should most of the time just build fine with any latest buildable snapshot of the whole moduleset. There was a time at which I used GARNOME (a script that grabbed all the latest tarballs) and only CVS/SVN on the module I cared about because that was the most reliable way to get everything to build without issues and just focus on my module.

I guess the bit I don't understand is, why do we have to think in terms of "making jhbuild more like Continuous"? What's missing from Continuous to cover all the jhbuild usecases?

2015-07-21 2:23 GMT+01:00 Michael Catanzaro <mcatanzaro gnome org>:

On Tue, 2015-07-21 at 02:04 +0100, Alberto Ruiz wrote:
> Relying on jhbuild from my point of view is a waste of everybody's
> time, we've got all these developers building the same version of the > same module in the same architecture again and again and again, to > reach more or less the same state, all the people who give up on > writing a patch or testing master everytime a module breaks (like the > latest libgit2-glib issues for example) is a precious resource we're > wasting for not having the right infrastructure. Up to the point of > glib or gtk+ is kinda handy but beyond that is almost impractical.

The problem is that we have no way to make sure our modules are always
in a buildable state. It's not impractical and it wouldn't even be
particularly difficult, the result would look awfully like GNOME
Continuous, building each jhbuild module in containers a few important
distros; it's just a challenge nobody has had time to attempt yet. I
was hoping GNOME Continuous would help with this, but the problem is
that Continuous is completely separate from jhbuild so they can have
different build issues; when an issue is detected in Continuous, it
isn't fixed in jhbuild; and Continuous isn't a jhbuild replacement. I
think our need is Continuous for jhbuild.

In the meantime, all it takes to avoid the libgit2-glib situation is
for someone to take a few minutes to roll back the module to an older
version [1][2][3]. My bad for not doing this immediately when I noticed
the problem; I wanted to give the developers some time to fix the
issue, but in hindsight that was wrong; these issues must be addressed
immediately since they block contributors from working on GNOME.

The other issue with jhbuild right now is a circular dependency problem
between, erm, g-i, vala, and... something else, I forget, which causes
everything to fail for new users but work fine for existing users. This
sucks. To avoid this, we need a dependency that says "build this module
eventually after building me" or "build me eventually after building
this other module," which we don't currently have. (I thought it was
"after" but that's something else.)

[1] https://git.gnome.org/browse/jhbuild/commit/?id=baa893595c98900e069
8dab2286953e0a5d723db
[2] https://git.gnome.org/browse/jhbuild/commit/?id=661878b5ca0a1a97fed
1f5f61ecaa5991bf870d5
[3] https://git.gnome.org/browse/jhbuild/commit/?id=b651a03d8f1f7b7e2c3
ccd56de25ea42c2b2b9f6

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

--

Cheers,
Alberto Ruiz