Re: Improving the way we build nightly apps

On Tue, 2017-02-28 at 15:50 -0800, Christian Hergert wrote:
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
take at face value)?

Well indeed, nothing's decided yet. We're still in early stages here;
that public discussion needs to take place, for starters, and we need
working code that actually builds Flatpaks via BuildStream. But I'm
very, very interested in any technology that can replace JHBuild and
also the Continuous manifest and flatpak-builder JSON all at the same
time (presuming it provides a pleasant development environment
equivalent or superior to JHBuild's). Having our build definitions
fragmented in three different places is the most serious problem
release team is dealing with right now. Currently, we only maintain the
JHBuild modulesets, and that's not great because it's not what users
actually use.

I'm also not really opposed to moving the flatpak-builder JSON into
application repositories. That will help solve a big problem, which is
that it's not very well-maintained right now, because release team does
not have the resources to maintain a second set of build metadata and
flatpak-builder metadata is obviously not suitable for replacing
JHBuild. Really, I checked the stable Epiphany flatpak recently, it's
version 3.22.0 (which is vulnerable to a major security issue) and
can't display at all for some reason. I seriously hope
nobody is using that. In contrast, application maintainers should
surely be able to maintain their own build definition for their one

I guess I was just... thinking out loud about the situation. But now
seems like a good time to point out that there is serious interest in
relpacing flatpak-builder (not generally, but for building the official
GNOME Flatpaks).

Of course, we also need to make sure that BuildStream meets the needs
of other GNOME consumers, like Builder.


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