Re: Stable branches, including frameworks for Kubuntu LTS

--00000000000080bb8d0651c9b9fa
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

not sure if this is clear:  you'll fix the bugs in the master branches and
backport those fixes to the current release branch and to the LTS branch?
and you won't add new features as this is only about fixing bugs?


On Thu, May 14, 2026 at 10:26=E2=80=AFAM Martin Fl=C3=B6ser <mgraesslin@kde=
.org> wrote:

> Am Dienstag, 12. Mai 2026, 18:15:44 Mitteleurop=C3=A4ische Sommerzeit sch=
rieb
> Marco
> Martin:
> > Hi all,
> > I'm speaking with my Techpaladin hat here. We have a client (Kubuntu
> Focus,
> > which they are KDE patrons as well) which is interested in long
> commercial
> > support for Plasma 6.6, alongside accompanying Gear applications and
> > frameworks.
> > This is for Kubuntu 26.04 LTS, which means:
> > * Plasma 6.6
> > * Frameworks 6.24
> > * Gear 25.12 (unfortunately not 26.4)
>
> Let me congratulate and thank both Kubuntu Focus and Techpaladin for doin=
g
> this important work and wanting to do it upstream!
>
> I find this effort so awesome that I thought I have to answer on it :-)
> >
> > We would continue to backport and test the relevant bugfixes for the ti=
me
> > being,
> > point releases would continue to be made out of such backports.
> >
> > They will also sponsor to the eV the necessary CI nodes to continue CI
> for
> > those branches, as long they are supported.
> >
> > Now the delicate part is frameworks, which as of today it doesn't have =
a
> > stable branch, but since Kubuntu can't upgrade frameworks in its LTS,
> such
> > a stable maintenance branch would need to be created, which would be a
> > first.
> >
> > We (as in Techpaladin) pledge to take up the maintenance of such branch
> as
> > long as it's supported, managing backports, testing and releases, as we=
ll
> > as keeping the new CI nodes green
>
> I think there is no problem using the normal branch names without any
> Kubuntu
> or Enterprise branch naming. The only important thing is that the
> communication is clear:
>
>  * no expectation that there will be another LTS branch in future
>  * corporate backing, no community effort
>  * no promises from community
>  * no expectations that bugs get backported
>  * community members should not be pushed into backporting
>
> The last point might also require that we prepare some text templates for
> social media and bug reports when users demand that a bug fix gets
> backported.
>
> Cheers
> Martin
>
>
>

--00000000000080bb8d0651c9b9fa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>not sure if this is clear:=C2=A0 you&#39;ll fix the b=
ugs in the master branches and backport those fixes to the current release =
branch and to the LTS branch?</div><div>and you won&#39;t add new features =
as this is only about fixing bugs?</div><div><br></div></div><br><div class=
=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr=
">On Thu, May 14, 2026 at 10:26=E2=80=AFAM Martin Fl=C3=B6ser &lt;<a href=
=3D"mailto:[email protected]">[email protected]</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">Am Dienstag, 12. Mai 2026,=
 18:15:44 Mitteleurop=C3=A4ische Sommerzeit schrieb Marco <br>
Martin:<br>
&gt; Hi all,<br>
&gt; I&#39;m speaking with my Techpaladin hat here. We have a client (Kubun=
tu Focus,<br>
&gt; which they are KDE patrons as well) which is interested in long commer=
cial<br>
&gt; support for Plasma 6.6, alongside accompanying Gear applications and<b=
r>
&gt; frameworks.<br>
&gt; This is for Kubuntu 26.04 LTS, which means:<br>
&gt; * Plasma 6.6<br>
&gt; * Frameworks 6.24<br>
&gt; * Gear 25.12 (unfortunately not 26.4)<br>
<br>
Let me congratulate and thank both Kubuntu Focus and Techpaladin for doing =
<br>
this important work and wanting to do it upstream!<br>
<br>
I find this effort so awesome that I thought I have to answer on it :-)<br>
&gt; <br>
&gt; We would continue to backport and test the relevant bugfixes for the t=
ime<br>
&gt; being,<br>
&gt; point releases would continue to be made out of such backports.<br>
&gt; <br>
&gt; They will also sponsor to the eV the necessary CI nodes to continue CI=
 for<br>
&gt; those branches, as long they are supported.<br>
&gt; <br>
&gt; Now the delicate part is frameworks, which as of today it doesn&#39;t =
have a<br>
&gt; stable branch, but since Kubuntu can&#39;t upgrade frameworks in its L=
TS, such<br>
&gt; a stable maintenance branch would need to be created, which would be a=
<br>
&gt; first.<br>
&gt; <br>
&gt; We (as in Techpaladin) pledge to take up the maintenance of such branc=
h as<br>
&gt; long as it&#39;s supported, managing backports, testing and releases, =
as well<br>
&gt; as keeping the new CI nodes green<br>
<br>
I think there is no problem using the normal branch names without any Kubun=
tu <br>
or Enterprise branch naming. The only important thing is that the <br>
communication is clear:<br>
<br>
=C2=A0* no expectation that there will be another LTS branch in future<br>
=C2=A0* corporate backing, no community effort<br>
=C2=A0* no promises from community<br>
=C2=A0* no expectations that bugs get backported<br>
=C2=A0* community members should not be pushed into backporting<br>
<br>
The last point might also require that we prepare some text templates for <=
br>
social media and bug reports when users demand that a bug fix gets backport=
ed.<br>
<br>
Cheers<br>
Martin<br>
<br>
<br>
</blockquote></div>

--00000000000080bb8d0651c9b9fa--