Re: Release team now using gnome-build-meta repository, not JHBuild

[mcatanzaro gnome org]

On Mon, Jan 22, 2018 at 12:56 PM, Carlos Soriano <csoriano gnome org> 
wrote:
> What's the workflow for those before a proper solution is done? Or 
> are the developers of those modules expected to maintain JHbuild on 
> the meantime?

Thanks Carlos; this is an important question. Let me provide a bit more 
context for our decision to stop maintaining JHBuild now, even though 
BuildStream is not yet be usable for running some modules.

I'll use one specific anecdote. On October 30, the Autotools build 
files were removed from at-spi2-core. The accompanying JHBuild 
moduleset update switching it to use meson was pushed by Philip 
Withnall (thanks!) on December 1. So at-spi2-core was obviously not 
buildable with JHBuild during November. at-spi2-core is, of course, a 
dependency of gtk+-3 (via at-spi2-atk), which is a dependency of every 
GNOME app. That means either (a) nobody tried to 'jhbuild build' any 
app during the entire month of November, or (b) nobody bothered to 
report that building everything was broken during this time.

So I assumed that demand to continue maintaining the JHBuild modulesets 
was really, really, *really* low.

This is just one particularly-egregious case... maintaining JHBuild is 
a constant fight against this sort of breakage; it seems to almost 
always be broken, and it's just not sustainable. (Big thanks to Alberts 
Muktupāvels, Javier Jardón, Ting-Wei Lan, and everyone else who's 
helped to maintain JHBuild during the past few years.) Now that release 
team is no longer using JHBuild, we simply don't want to deal with it 
anymore.

But I'm only speaking for the release team here, not the entire 
community. This conversation has made clear that, due to BuildStream's 
current limitations, there is still desire to continue using JHBuild 
that we failed to anticipate. Even I'll admit that, when it does work, 
JHBuild is actually easier and more convenient to use for development. 
So I would say: please do feel free to maintain the modulesets to the 
degree that you require for your own development. We have no plans to 
delete them. Ensuring that the modules you're personally interested in 
are building fine should be much easier for you than it was for us to 
try to ensure that everything always builds.

But with BuildStream, we now know for sure that our software always at 
least builds, because there is CI to enforce it, and a well-defined 
base system which is unaffected by host dependencies. That's step one. 
We've never had that before. I'm hopeful that the GNOME community can 
continue to improve the situation from here, to help make BuildStream 
more powerful and easier to use. No doubt Tristan will be here tomorrow 
with a comment on his plans for this. :)

I know that answer doesn't actually solve the problem, but hopefully 
that explains our thinking.

Michael

P.S. Unimportant: the dependency of gtk+-3 on at-spi2-atk is actually 
illegal, since gtk+-3 is in core-deps, and at-spi2-atk is in core, and 
core-deps is not supposed to depend on core. I just now noticed this. 
We of course have no tools to detect it. ;)