<div dir="ltr"><div dir="ltr"><div dir="ltr">On Fri, Jan 10, 2025 at 5:26 AM Nicolas Fella <<a href="mailto:nicolas.fella@gmx.de" target="_blank">nicolas.fella@gmx.de</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Am 09.01.25 um 17:20 schrieb Volker Krause:<br>
> On Donnerstag, 9. Januar 2025 11:12:09 Mitteleuropäische Normalzeit David<br>
> Redondo wrote:<br>
>> Am Mittwoch, 8. Januar 2025, 17:18 schrieb Nicolas Fella:<br>
>>> Am 08.01.25 um 10:57 schrieb David Redondo:<br>
>>>> Hi,<br>
>>>><br>
>>>> the original plan for Plasma 6.3 was to require Qt 6.8 (as the wiki<br>
>>>> currently notes). However FreeBSD so far didn't gain Qt 6.7 and we<br>
>>>> never bumped it. The first Beta is tomorrow. So I think we just go with<br>
>>>> 6.7?<br>
>>>><br>
>>>> David<br>
>>> I am rather annoyed that this is the second (at least) time we find<br>
>>> ourselves in this situation. Can we somehow handle this better in the<br>
>>> future?<br>
>> I agree we had the same situation with Plasma 6.1 where we wanted<br>
>> 6.7 but were stuck on 6.6 leading to the<br>
>> "6.6 (6.7 strongly recommended) " minimum.<br>
>><br>
>> Maybe we did not communicate appropriately with sysadmin about this and<br>
>> our wish was not known? Or is there something else holding it back?<br></blockquote><div><br></div><div>I haven't received any specific request for Qt 6.8 no, however for Qt version bumps normally we would have completed the bump long before now so that isn't really the issue there.</div><div>CI doesn't tend to wait too long once packaging has been completed (SUSE for Linux, Craft for Windows/Android, etc) - however that is where FreeBSD becomes problematic.</div><div><br></div><div><div>FreeBSD is a very unfortunate situation at the moment - as our images depend on a custom FreeBSD repository (hosted at <a href="https://cdn.kde.org/freebsd/">https://cdn.kde.org/freebsd/</a>) which is maintained by a single FreeBSD packager.</div><div>I've not heard from them in a while now and have a couple of other merge requests in sysadmin/ci-images waiting so this was always going to need resolving.</div></div><div><br></div><div>I can't recall entirely why we have a custom repository but I believe it relates to getting us updates (or even entirely new packages) sooner than is possible with conventional FreeBSD repos.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Independent of this specific case, I don't think expecting sysadmin (ie<br>
> practically just Ben as far as CI is concerned) to deal with dependency<br>
> updates on the CI is going to scale, we need to see that as our all<br>
> responsibility. And since the move away from Jenkins a lot of that work can be<br>
> done without special sysadmin powers:<br>
> * Figure out if upstream has the new version already, and if not figure out<br>
> what's blocking that (and outside of Linux/FreeBSD upstream is also us, via<br>
> Craft).<br>
> * Submit MRs for the CI pieces that need updating (container images, Gitlab<br>
> template).<br>
> * And probably most importantly: help with dealing with the potential fallout<br>
> form the updates.<br></blockquote><div><br></div><div>Volker is correct - the bulk of CI maintenance work for all our platforms lives in sysadmin/ci-images, sysadmin/ci-utilities, sysadmin/ci-management.</div><div><br></div><div>Note: Qt version bumps do need a package repository setup under teams/ci-artifacts/ so not as simple as just bumping everything all at once.</div><div>We stagger it by creating a new Docker image first, then we do the seed builds in sysadmin/ci-management, and finally once all of that is happy we actually transition the jobs that run in our repos over by bumping sysadmin/ci-utilities.</div><div><br></div><div>This is done like this to minimize disruption as it can take a number of hours to build all of the projects in Frameworks / Plasma / Apps that other things depend on and if you bumped sysadmin/ci-utilities immediately then the dependencies for your builds wouldn't be available and CI would die until the seed jobs had gotten far enough through to satisfy your project and it's requirements.</div><div><br></div><div>FreeBSD is unfortunately still much fiddlier than I'd like, as it depends on a custom FreeBSD repository being updated first, the subsequent package name changes that seem to accompany that being merged, and then the image being built.</div><div>We don't have a CI approach to building images yet - mostly as Podman on FreeBSD is still fairly new - so it relies on someone (me) logging into a builder and manually building an image (thankfully just two commands, one to build and one to upload)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
><br>
> Regards,<br>
> Volker<br>
<br>
I think this particular case is mostly a FreeBSD issue, which happens to<br>
be where contributing to our CI setup is the least approachable for<br>
people on the outside.<br></blockquote><div><br></div><div>Thanks,</div><div>Ben</div></div></div>
</div>