Re: Stable branches, including frameworks for Kubuntu LTS

On Wed, May 13, 2026 at 6:56=E2=80=AFAM Ben Cooksley <[email protected]> wr=
ote:
>
> On Wed, May 13, 2026 at 10:26=E2=80=AFPM Neal Gompa <[email protected]> =
wrote:
>>
>> On Wed, May 13, 2026 at 4:12=E2=80=AFAM Ben Cooksley <[email protected]>=
 wrote:
>> >
>> > On Wed, 13 May 2026, 3:45=E2=80=AFpm Neal Gompa, <[email protected]> =
wrote:
>> >>
>> >> On Tue, May 12, 2026 at 4:53=E2=80=AFPM Nicolas Fella <nicolas.fella@=
gmx.de> wrote:
>> >> >
>> >> > On 5/12/26 10:45 PM, 2Albert Astals Cid wrote:
>> >> > > El dimarts, 12 de maig del 2026, a les 20:13:01 (Hora d=E2=80=99e=
stiu d=E2=80=99Europa
>> >> > > central), Marco Martin va escriure:
>> >> > >> On Tue, May 12, 2026, 18:15 Marco Martin <[email protected]> wro=
te:
>> >> > >>> We (as in Techpaladin) pledge to take up the maintenance of suc=
h branch as
>> >> > >>> long as it's supported, managing backports, testing and release=
s, as well
>> >> > >>> as keeping the new CI nodes green
>> >> > >> What do you think about it? Is something that looks sensible on =
the
>> >> > >> upstream/community point of view?
>> >> > > Apologies if the next question sounds a bit blunt I didn't figure=
 out how word
>> >> > > it in a somewhat better way.
>> >> > >
>> >> > > Is this something we want to pretend the community is doing?
>> >> > >
>> >> > > That is, do we want to try to make this "a KDE thing" or is it cl=
early
>> >> > > structured as a Techpaladin/Kubuntu Focus thing?
>> >> > >
>> >> > > For me the second option makes it "simpler".
>> >> > >
>> >> > > Then my suggestion would be to just create "vendor" branches like=
 the ones
>> >> > > that we have for example in kleopatra/mimetreeparser/friends
>> >> > >
>> >> > >    gpg4win/23.10
>> >> > >    gpg4win/24.05
>> >> > >    gpg4win/gpd-5.0
>> >> > >    gpg4win/gpd-5.1
>> >> > >
>> >> > > So create something like kubuntufocus/26.04
>> >> > >
>> >> > > Maybe it would even make sense to create such branches for KDE Pl=
asma 6.6
>> >> > > (after final 6.6.6 is released) and KDE Gear 25.12?
>> >> >
>> >> > I assume this would be shipped in *upstream* Kubuntu 26.04, not som=
e
>> >> > derived version of that?
>> >> >
>> >> > If that's indeed the case then I'm okay with a more neutral name li=
ke
>> >> > Frameworks/6.24. Doesn't matter that much who is doing it.
>> >> >
>> >>
>> >> I am skeptical of the viability of this. Back in the days when we had
>> >> them, Kubuntu didn't ship the point releases anyway because the
>> >> updates policy for Kubuntu didn't make it easy for them to do it. And
>> >> I have seen no indication from *Kubuntu* that this would change
>> >> anytime soon.
>> >>
>> >> Otherwise, I would rather *not* see these branches at all, not as
>> >> vendor branches either. It's just a bad idea all around because it
>> >> creates confusion for everyone. Even the gpg4win ones create problems=
.
>> >
>> >
>> > Can you explain please how vendor specific branches (like the enterpri=
se/* ones many years ago, or the gpg4win/* branches today) create issues?
>> >
>>
>> Branch names aren't really enough to indicate policy and it also gets
>> weird when fixes show up only in those branches. I'm not saying that
>> it is going to happen in this case, but it's happened before. And it's
>> hard for it to be clear that they aren't for everyone if the branches
>> aren't in their repo fork in their own namespace.
>
>
> Happened before in KDE?
>
>>
>>
>> Ultimately, that's what I would prefer.
>>
>> > I would not expect people to look at branches with vendor specific nam=
ing unless they had a reason to do so.
>> >
>> >>
>> >> And as mentioned earlier, this would be a mess if we start having two
>> >> separate client requests for long-term KDE stack maintenance because
>> >> they're stopping on different points.
>> >
>> >
>> > By separate clients, you mean different distros I assume?
>> >
>>
>> No. It could be two different companies for the same distro even. I
>> was being deliberately ambiguous.
>>
>> For example, Kubuntu *today* has a blessed PPA where they attempt to
>> offer updated Plasma on the Ubuntu base. This is somewhat derived from
>> the KDE neon work. At this time, I am aware of at least two companies
>> commercially shipping Kubuntu(ish) stuff derived from this. There are
>> probably more.
>>
>> It is entirely possible that Techpaladin (representing KFocus) and
>> another company (e.g. Tuxedo) would do the same thing for different
>> points on the same Kubuntu base. And sure, there could also be others
>> on other distro bases (like KDE on AlmaLinux/RHEL or whatnot). In my
>> opinion, this is just going to be really complicated.
>
>
> I think you may have misunderstood what they intend to do.
>
> If another group turned up wanting to do LTS for the same version that so=
meone else already was doing, my expectation would be that they would colla=
borate on that together.
> (ie. a second group for Plasma 6.6 would be expected to work with Techpal=
adin/KFocus).
>

I said the same distro, I didn't say the same KDE stack versions. The
thing is, there are multiple Ubuntu-derived KDE distributions with
different versions of Plasma on the same base Ubuntu version. You have
Kubuntu at 6.6 right now, but Neon will move forward, and Tuxedo
follows Neon. But all three are on Ubuntu 26.04.



--=20
=E7=9C=9F=E5=AE=9F=E3=81=AF=E3=81=84=E3=81=A4=E3=82=82=E4=B8=80=E3=81=A4=EF=
=BC=81/ Always, there's only one truth!