[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: KDE Gear projects with failing CI (master) (9 April 2024)
From:       Ingo =?ISO-8859-1?Q?Kl=F6cker?= <kloecker () kde ! org>
Date:       2024-04-10 14:32:54
Message-ID: 1891440.CQOukoFCf9 () daneel
[Download RAW message or body]


On Mittwoch, 10. April 2024 14:54:26 CEST Friedrich W. H. Kossebau wrote:
> Am Mittwoch, 10. April 2024, 14:29:37 CEST schrieb Ingo Klöcker:
> > On Mittwoch, 10. April 2024 13:33:46 CEST Friedrich W. H. Kossebau wrote:
> > > Am Mittwoch, 10. April 2024, 13:04:47 CEST schrieb Ingo Klöcker:
> > > > On Mittwoch, 10. April 2024 09:21:34 CEST Ben Cooksley wrote:
> > > > > On Wed, Apr 10, 2024 at 9:51 AM Ingo Klöcker <kloecker@kde.org> 
wrote:
> > > > > > On Dienstag, 9. April 2024 23:26:32 CEST Albert Astals Cid wrote:
> > > > > > > ktrip - NEW
> > > > > > > 
> > > > > > >  * https://invent.kde.org/utilities/ktrip/-/pipelines/657661
> > > > > > >  
> > > > > > >   * craft_android builds fail
> > > > > > 
> > > > > > *sigh* Why does kirigami master depend on the not yet released ECM
> > > > > > 6.1.0?
> > > > > 
> > > > > Likely as Kirigami itself is a Framework - that being said, it seems
> > > > > a
> > > > > bit
> > > > > weird for the version bumps to be pushed to Frameworks before the
> > > > > release
> > > > > has been made public (because Craft cannot use them until they're
> > > > > public...)
> > > > 
> > > > I learned that this is the usual procedure for Frameworks. But it
> > > > highlights why it's a bad idea for applications to depend on the
> > > > master
> > > > versions of Frameworks.
> > > 
> > > In (software) development it seems usually fine to have development
> > > branches of separate components depend on each other's latest state.
> > > They
> > > call it Continuous Integration. One of the purposes is to get
> > > early-as-possible feedback, not only post-release when certain things
> > > can
> > > no longer be changed. In the case of KF libraries that would be e.g.
> > > feasibility of new API as well as the state of the implementation. Which
> > > is usually considered a good idea, both for the libraries as well as the
> > > applications as the consumers of the libraries.
> > > 
> > > It is a bad idea only from the POV of Craft users, as the tool seems not
> > > yet capable to deal with development branches of all dependencies?
> > 
> > It does support this but it will kill our CI/CD system if every Craft CD
> > job builds all Frameworks from scratch. In any case, what you talk about
> > is covered by the CI (Continuous Integration!) jobs.
> > 
> > The Craft CD (Continuous Delivery/Deployment) jobs are meant to be used
> > for
> > building releases. When we stop doing fixed point releases and start doing
> > continuous releases of Frameworks then we can talk about doing CD from
> > master.
> 
> Hm, not sure if we talk along the same lines. Let's summarize what I saw
> here:
> 
> 1. craft-tool based job on master branch of app fails
> 2. reason: master branch of app expects master branch of library, job though
> only supplies released version of that library

I'd say this statement is wrong, but that depends on what you mean by 
"expects". The master branch of KTrip doesn't require (as in CMake's 
find_package()) the master branch of Kirigami. And the job did actually (try 
to) supply the master branch of Kirigami. But that failed because the master 
branch of Kirigami requires ECM 6.1 which the job didn't supply.

> 3. claim: "highlights why it's a bad idea for applications to depend on the
> master versions of Frameworks"

Because one cannot use the master versions of a few selected Frameworks for a 
build. One needs to use the master versions of all of Frameworks. And that's 
expensive.

> 4. "Craft CD jobs are meant to be used for building releases"
> 
> So why are there Craft CD jobs on master branches of apps?

Some apps do actually do Continuous Delivery, e.g. Itinerary. But that's only 
possible because Itinerary doesn't depend on unreleased Frameworks. (Well, it 
would be possible otherwise but it would cost/waste much more CI/CD 
resources.)

Some projects want users to be able to check out the bleeding edge AppImage or 
Flatpak of their app. Same for Windows builds. This is certainly useful for 
example to check if bugs in some release still occur in the development 
version.

The problem isn't "Craft CD jobs on master branches of apps". The problem is 
"Craft CD jobs on master branches of apps" which require unreleased 
Frameworks.

> Or what kind of Craft jobs are those?

All of them.

> My point is: it is not a bad idea for applications to depend on master
> versions of Frameworks, for the reasons given in my response.

I agree that it's not a bad idea in general if the devs of the app have good 
reasons to do so. They have to take into account that long running CD jobs 
waste energy and the time of people waiting for the jobs to finish. In general, 
it's better to avoid depending on unreleased Frameworks.

I would likely not contribute to a project which forces me to build Frameworks 
myself. I'm a happy user of the KF development packages provided by 
Tumbleweed.

Regards,
Ingo
["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]