Re: Improving the way we build nightly apps

[Christian Hergert <christian hergert me>]

On 02/28/2017 03:18 PM, Michael Catanzaro wrote:
> On the other hand, these manifests should hopefully be obsoleted soon
> by BuildStream. The goal of that effort is to remove the separate
> Continuous manifest, JHBuild moduleset, and flatpak nightlies repos. So
>  if we implement this now, we'd be going from centralized to
> decentralized and then back to centralized in the future. So I don't
> know if it makes sense to do this for all modules now. But it's a small
> amount of work and certainly doesn't hurt anything.

You make it sound like there is already unanimous support for this 
(considering I've seen no discussion on the topic, I find that hard to 
take at face value)?

Having configurations that are generated from meta-configurations makes 
IDE tooling a giant PITA. The .json files are our primary configuration 
format for Builder going forward.

The further we abstract from that, the more difficult we make our 
newcomer story. If they aren't in the projects git repository, this ends 
up being as bad as jhbuild today where we have to synchronize 
configuration changes between separate modules.

I really don't want to see a development workflow where after checking 
out a GNOME module we have to look up in an external system how to build 
the thing, just to have to push changes back to said system when the 
developer changes a project setting.

If we do end up with something (other than the flatpak json files) that 
end up in each projects module, then it is paramount that we have enough 
information to tie together how to configure the project, how to execute 
flatpak-builder, what build system to use, what runtime and sdk to wire 
up, and of course, without having a pre-processed .in file.

I don't see any reason the aforementioned project can't do that, but I 
expect some bike-shedding about where configurations live. I hope this 
serves as a major counter-point to the ultimately centralized choice.

I have some more thoughts, but this email is already too long. So I'll stop.

-- Christian