Re: Improving the way we build nightly apps

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]