Stable branches, including frameworks for Kubuntu LTS

[Ben Cooksley]

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?

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?

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


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

Cheers,
Ben

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20260513/9d920dd9/attachment.htm>