From kde-devel Wed Apr 10 14:32:54 2024 From: Ingo =?ISO-8859-1?Q?Kl=F6cker?= Date: Wed, 10 Apr 2024 14:32:54 +0000 To: kde-devel Subject: Re: KDE Gear projects with failing CI (master) (9 April 2024) Message-Id: <1891440.CQOukoFCf9 () daneel> X-MARC-Message: https://marc.info/?l=kde-devel&m=171275942127299 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart23469676.6Emhk5qWAg" --nextPart23469676.6Emhk5qWAg Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8"; protected-headers="v1" From: Ingo =?ISO-8859-1?Q?Kl=F6cker?= To: kde-devel@kde.org Subject: Re: KDE Gear projects with failing CI (master) (9 April 2024) Date: Wed, 10 Apr 2024 16:32:54 +0200 Message-ID: <1891440.CQOukoFCf9@daneel> In-Reply-To: <2212930.h6RI2rZIcs@klux> MIME-Version: 1.0 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=C3=B6cker: > > On Mittwoch, 10. April 2024 13:33:46 CEST Friedrich W. H. Kossebau wrot= e: > > > Am Mittwoch, 10. April 2024, 13:04:47 CEST schrieb Ingo Kl=C3=B6cker: > > > > On Mittwoch, 10. April 2024 09:21:34 CEST Ben Cooksley wrote: > > > > > On Wed, Apr 10, 2024 at 9:51=E2=80=AFAM Ingo Kl=C3=B6cker =20 wrote: > > > > > > On Dienstag, 9. April 2024 23:26:32 CEST Albert Astals Cid wrot= e: > > > > > > > ktrip - NEW > > > > > > >=20 > > > > > > > * https://invent.kde.org/utilities/ktrip/-/pipelines/657661 > > > > > > > =20 > > > > > > > * craft_android builds fail > > > > > >=20 > > > > > > *sigh* Why does kirigami master depend on the not yet released = ECM > > > > > > 6.1.0? > > > > >=20 > > > > > Likely as Kirigami itself is a Framework - that being said, it se= ems > > > > > 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...) > > > >=20 > > > > 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. > > >=20 > > > 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. Wh= ich > > > is usually considered a good idea, both for the libraries as well as = the > > > applications as the consumers of the libraries. > > >=20 > > > 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? > >=20 > > 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. > >=20 > > The Craft CD (Continuous Delivery/Deployment) jobs are meant to be used > > for > > building releases. When we stop doing fixed point releases and start do= ing > > continuous releases of Frameworks then we can talk about doing CD from > > master. >=20 > Hm, not sure if we talk along the same lines. Let's summarize what I saw > here: >=20 > 1. craft-tool based job on master branch of app fails > 2. reason: master branch of app expects master branch of library, job tho= ugh > only supplies released version of that library I'd say this statement is wrong, but that depends on what you mean by=20 "expects". The master branch of KTrip doesn't require (as in CMake's=20 find_package()) the master branch of Kirigami. And the job did actually (tr= y=20 to) supply the master branch of Kirigami. But that failed because the maste= r=20 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 t= he > master versions of Frameworks" Because one cannot use the master versions of a few selected Frameworks for= a=20 build. One needs to use the master versions of all of Frameworks. And that'= s=20 expensive. > 4. "Craft CD jobs are meant to be used for building releases" >=20 > 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 on= ly=20 possible because Itinerary doesn't depend on unreleased Frameworks. (Well, = it=20 would be possible otherwise but it would cost/waste much more CI/CD=20 resources.) Some projects want users to be able to check out the bleeding edge AppImage= or=20 =46latpak of their app. Same for Windows builds. This is certainly useful f= or=20 example to check if bugs in some release still occur in the development=20 version. The problem isn't "Craft CD jobs on master branches of apps". The problem i= s=20 "Craft CD jobs on master branches of apps" which require unreleased=20 =46rameworks. > 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 goo= d=20 reasons to do so. They have to take into account that long running CD jobs= =20 waste energy and the time of people waiting for the jobs to finish. In gene= ral,=20 it's better to avoid depending on unreleased Frameworks. I would likely not contribute to a project which forces me to build Framewo= rks=20 myself. I'm a happy user of the KF development packages provided by=20 Tumbleweed. Regards, Ingo --nextPart23469676.6Emhk5qWAg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQTbjgIOMowwlCBgvyGxb1mVFkdKugUCZhajFgAKCRCxb1mVFkdK ugYtAQDWDB4zjWEbLgMd9k7nu/QqKQ9y7s1ssD0ajtkR7FRz6QEA76QsAXrfZ0FW 6kNEiBo8B4UPlZqTRiaOBc5bKNI0Xgg= =wZDb -----END PGP SIGNATURE----- --nextPart23469676.6Emhk5qWAg--