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 <[email protected]>: > 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 > [email protected] > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > -- Cheers, Alberto Ruiz
_______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
