Stable branches, including frameworks for Kubuntu LTS

[Neal Gompa]

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.

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.

> Note that a rather key difference here is that a commercial vendor, not the community, is the one maintaining this.
>

Right, and that is the main reason I don't think those branches should
be in the community repositories. If they are forks in their own
namespace, even on Invent, it's much clearer that it's not for
everyone.


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