Stable branches, including frameworks for Kubuntu LTS

Neal Gompa ngompa13 at gmail.com
Wed May 13 11:58:57 BST 2026


On Wed, May 13, 2026 at 6:56 AM Ben Cooksley <bcooksley at kde.org> wrote:
>
> On Wed, May 13, 2026 at 10:26 PM Neal Gompa <ngompa13 at gmail.com> wrote:
>>
>> On Wed, May 13, 2026 at 4:12 AM Ben Cooksley <bcooksley at kde.org> wrote:
>> >
>> > On Wed, 13 May 2026, 3:45 pm Neal Gompa, <ngompa13 at gmail.com> wrote:
>> >>
>> >> On Tue, May 12, 2026 at 4:53 PM Nicolas Fella <nicolas.fella at 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’estiu d’Europa
>> >> > > central), Marco Martin va escriure:
>> >> > >> On Tue, May 12, 2026, 18:15 Marco Martin <notmart at gmail.com> wrote:
>> >> > >>> 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 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 clearly
>> >> > > 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 Plasma 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 some
>> >> > derived version of that?
>> >> >
>> >> > If that's indeed the case then I'm okay with a more neutral name like
>> >> > 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 enterprise/* 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 naming 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 someone else already was doing, my expectation would be that they would collaborate on that together.
> (ie. a second group for Plasma 6.6 would be expected to work with Techpaladin/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.



-- 
真実はいつも一つ!/ Always, there's only one truth!


More information about the kde-core-devel mailing list