Re: Re: Decommissioning Qt 5 CI
Ben Cooksley <[email protected]> Wed, 29 Jul 2026 22:00:08 +1200
| Newsgroups | gmane.comp.kde.releases,gmane.comp.kde.devel.general,gmane.comp.kde.devel.core,gmane.comp.kde.devel.plasma |
|---|---|
| Message-ID | <CA+XidOEzOOOpZMknPJT_8992RTN=ip3rh6YKpGryjQ-oTaOHgw@mail.gmail.com> |
--000000000000f81b890657bd05d5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 29, 2026 at 7:31=E2=80=AFPM David Redondo <[email protected]= > wrote: > Am Dienstag, 28. Juli 2026, 23:36 schrieb Albert Astals Cid: > > El dimarts, 28 de juliol del 2026, a les 13:20:56 (Hora d=E2=80=99estiu= d=E2=80=99Europa > > central), Nicolas Fella va escriure: > > > On 28/07/2026 12:52, Ben Cooksley wrote: > > > > Hi all, > > > > > > > > For some time now Qt 5 has been in extended maintenance / support, > > > > which Iif my understanding is correct has now come to an end. > > > > > > > > Accordingly, given that all of our applications have now had a > > > > substantial amount of time to migrate, and plenty of notice that CI > > > > would be withdrawn eventually, i'd like to proceed with withdrawing > CI > > > > support for Qt 5. > > > > > > > > This will free up valuable space on the CI nodes and allow us to > > > > remove an image that is under very minimal, if any, maintenance. > > > > > > > > Please let me know if there are any objections. > > > > > > Hi, > > > > > > for applications I agree to drop Qt5 CI. The few usages that are left > > > either already have Qt6 CI, or are more or less dead projects. > > > > > > That said, we have a number of (Plasma) components that we still buil= d > > > for Qt5 for (external) application compatibility (breeze, > > > plasma-integration, etc). So far we have not made a decision to stop > > > doing that, and I'd rather not lose CI for those. That doesn't mean w= e > > > need Qt5 CI in the current form. Could we use a distribution image wi= th > > > Qt and the few necessary libraries/frameworks baked in? That would be= a > > > much smaller image and easier to maintain than the current suse-qt515 > > > image. > > > > Does the code of those repos change in qt5 related areas? > > > > Trying to understand what we want CI for here: > > * Potentially new qt5 code builds with old qt5/gcc distros? > > * Non changing qt5 code builds new gcc/stuff from distros? > > > > breeze, oxygen and plasma-integration is > * new qt5 code builds on current distros > it changes as the qt6 code changes. The goal is that qt5 and qt6 > applications > look and feel the same. > For breeze and oxygen the same code base is compiled twice, once with qt6 > and once with qt5. > plasma-integration has copies of the code for qt5 and qt6 because the > ifdef'ery became a bit too much. > > Non changing qt5 code that I can think of is kwayland-integration which i= s > an implementation detail of kf5/plasma5 > but we provide in plasma6 to keep kf5 apps working. Not a huge fan of the idea of keeping Qt 5 around in any form at all to be honest. Do the Plasma developers have a view as to when this support will be dropped given that distributions are rapidly dropping support for Qt 5? This feels like something that is going to require work to implement and will be dropped in 6 months or so given the speed distros are moving at, and if that is the case my preference would be to just move up the end of support and do it all now. Regards, Ben > > > Cheers, David > > > Cheers, > > Albert > > > > > > > > Cheers > > > > > > Nico > > > > > > > > > > > > > > > --000000000000f81b890657bd05d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><span style=3D"background-color:transpare= nt">On Wed, Jul 29, 2026 at 7:31=E2=80=AFPM David Redondo <<a href=3D"ma= ilto:[email protected]">[email protected]</a>> wrote:</span></div>= <div class=3D"gmail_quote gmail_quote_container"><blockquote class=3D"gmail= _quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204= ,204);padding-left:1ex">Am Dienstag, 28. Juli 2026, 23:36 schrieb Albert As= tals Cid:<br> > El dimarts, 28 de juliol del 2026, a les 13:20:56 (Hora d=E2=80=99esti= u d=E2=80=99Europa <br> > central), Nicolas Fella va escriure:<br> > > On 28/07/2026 12:52, Ben Cooksley wrote:<br> > > > Hi all,<br> > > > <br> > > > For some time now Qt 5 has been in extended maintenance / su= pport,<br> > > > which Iif my understanding is correct has now come to an end= .<br> > > > <br> > > > Accordingly, given that all of our applications have now had= a<br> > > > substantial amount of time to migrate, and plenty of notice = that CI<br> > > > would be withdrawn eventually, i'd like to proceed with = withdrawing CI<br> > > > support for Qt 5.<br> > > > <br> > > > This will free up valuable space on the CI nodes and allow u= s to<br> > > > remove an image that is under very minimal, if any, maintena= nce.<br> > > > <br> > > > Please let me know if there are any objections.<br> > > <br> > > Hi,<br> > > <br> > > for applications I agree to drop Qt5 CI. The few usages that are = left<br> > > either already have Qt6 CI, or are more or less dead projects.<br= > > > <br> > > That said, we have a number of (Plasma) components that we still = build<br> > > for Qt5 for (external) application compatibility (breeze,<br> > > plasma-integration, etc). So far we have not made a decision to s= top<br> > > doing that, and I'd rather not lose CI for those. That doesn&= #39;t mean we<br> > > need Qt5 CI in the current form. Could we use a distribution imag= e with<br> > > Qt and the few necessary libraries/frameworks baked in? That woul= d be a<br> > > much smaller image and easier to maintain than the current suse-q= t515<br> > > image.<br> > <br> > Does the code of those repos change in qt5 related areas?<br> > <br> > Trying to understand what we want CI for here:<br> >=C2=A0 * Potentially new qt5 code builds with old qt5/gcc distros?<br> >=C2=A0 * Non changing qt5 code builds new gcc/stuff from distros?<br> > <br> <br> breeze, oxygen and plasma-integration is<br> * new qt5 code builds on current distros<br> it changes as the qt6 code changes. The goal is that qt5 and qt6 applicatio= ns<br> look and feel the same.<br> For breeze and oxygen the same code base is compiled twice, once with qt6 a= nd once with qt5.<br> plasma-integration has copies of the code for qt5 and qt6 because the ifdef= 'ery became a bit too much.<br> <br> Non changing qt5 code that I can think of is kwayland-integration which is = an implementation detail of kf5/plasma5<br> but we provide in plasma6 to keep kf5 apps working.</blockquote><div><br></= div><div>Not a huge fan of the idea of keeping Qt 5 around in any form at a= ll to be honest.</div><div><br></div><div>Do the Plasma developers have a v= iew as to when this support will be dropped given that distributions are ra= pidly dropping support for Qt 5?</div><div><br></div><div><span style=3D"ba= ckground-color:transparent">This feels like something that is going to requ= ire work to implement and will be dropped in 6 months or so given the speed= distros are moving at, and if that is the case my preference would be to j= ust move up the end of support and do it all now.</span></div><div><br></di= v><div>Regards,</div><div>Ben</div><div><span style=3D"background-color:tra= nsparent">=C2=A0</span></div><blockquote class=3D"gmail_quote" style=3D"mar= gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1= ex"> <br> <br> Cheers, David<br> <br> > Cheers,<br> >=C2=A0 =C2=A0Albert<br> > <br> > > <br> > > Cheers<br> > > <br> > > Nico<br> > <br> > <br> > <br> > <br> > <br> <br> <br> <br> <br> </blockquote></div></div> --000000000000f81b890657bd05d5--