Re: Improving the way we build nightly apps
- From: Michael Catanzaro <mcatanzaro gnome org>
- To: Christian Hergert <christian hergert me>, desktop-devel-list gnome org
- Subject: Re: Improving the way we build nightly apps
- Date: Wed, 01 Mar 2017 07:16:31 -0600
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
to
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 youtube.com 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
module.
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.
Michael
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]