CI Flatpak Builds

[Volker Krause]

On Samstag, 25. Januar 2025 08:41:53 Mitteleuropäische Normalzeit Ben Cooksley 
wrote:
> On Sat, Jan 25, 2025 at 10:46 AM Ingo Klöcker <kloecker at kde.org> wrote:
> > On Freitag, 24. Januar 2025 18:57:43 Mitteleuropäische Normalzeit Ben
> > Cooksley
> > 
> > wrote:
> > > I had been thinking that having a separate file that would be used
> > 
> > instead
> > 
> > > of .flatpak-manifest.yml if present when doing a build on a stable
> > > branch
> > > would be a good solution.
> > > Under this you would have a .flatpak-manifest.yml and a
> > > .flatpak-manifest-stable.yml file
> > > 
> > > When building on master the .flatpak-manifest.yml file would be used,
> > > but
> > > when on a release branch / tag the .flatpak-manifest-stable.yml file
> > 
> > would
> > 
> > > be used instead (if present).
> > > 
> > > That would eliminate needing the release manager / developer to update
> > > .flatpak-manifest.yml on branching a new stable release branch.
> > 
> > Doesn't that mean that the .flatpak-manifest-stable.yml file would be
> > completely
> > untested until the branching happens? We all know what happens if things
> > are
> > not tested on a regular basis.
> 
> Yes, unfortunately this is one of those issues where we are going to lose
> either way.
> You can either ensure your builds are reproducible and able to be
> replicated in the future by someone, or decide to chase upstream to ensure
> they haven't broken things and pulled the rug out from underneath you.
> 
> Both approaches have their pros and cons however we should understand that
> if we opt to chase upstream then our ability to produce CD builds that are
> suitable for end user distribution will be impaired.
> 
> In this instance we need to make a decision as to whether the Flatpak build
> is intended to be a CD build suitable for end-user distribution, or are we
> actually using it as another form of CI.
> When it was introduced it was intended as a form of CD build.

I don't necessarily see those two as mutually exclusive:
* CD builds in the stable branch should be in a state suitable for end-user 
distribution. What we are still missing there is a way to mark the actual 
released package (what we currently ship e.g. in the app stores isn't always 
exactly the build of the Gear release tag, but can also be later build that 
has received additional fixes/backports somewhere in the stack).
* CD builds on master should be in a working state as well of course, but I'd 
see their users as contributors, ie. daily driving master CD builds is a form 
of QA contribution. So it's in a project's best interest to keep those working 
well enough, otherwise you lose a big part of your QA team. What exactly is in 
those builds however depends on where the specific risks lie for a particular 
application I'd say, so using bleeding edge dependencies when necessary/useful 
is fine IMHO.

> I'll note that we should probably also tighten up how we handle our
> relationships with upstreams that break things too often and (strongly)
> encourage them to not break things.

For all dependencies mentioned above we have very strong relationships with 
upstream, and probably at least half of the changes there that broke things 
recently were even done by our own people. There are of course things we can 
improve to limit the impact (see e.g. my earlier suggestions for versioning), 
but much of this is somewhat unavoidable I fear.

Something with the size and complexity of Qt will always cause regressions 
somewhere in our extensive use of it, no matter how hard people try to avoid 
that. And something like libQuotient might have to change API if Matrix 
changes the underlying protocol, if it doesn't it's practically useless for 
us.

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20250125/e277b41e/attachment.sig>