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