Re: Stable branches, including frameworks for Kubuntu LTS
Ben Cooksley <[email protected]> Wed, 13 May 2026 22:55:44 +1200
| Newsgroups | gmane.comp.kde.devel.core,gmane.comp.kde.devel.frameworks |
|---|---|
| Message-ID | <CA+XidOGYOroPL-sOFHwTMg4A4SCAzhsG89J1-JrByj7YG8s9Pg@mail.gmail.com> |
--0000000000007f27d40651b0d385 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 13, 2026 at 10:26=E2=80=AFPM Neal Gompa <[email protected]> wr= ote: > 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]> w= rote: > >> > >> On Tue, May 12, 2026 at 4:53=E2=80=AFPM Nicolas Fella <nicolas.fella@g= mx.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=99es= tiu > d=E2=80=99Europa > >> > > central), Marco Martin va escriure: > >> > >> On Tue, May 12, 2026, 18:15 Marco Martin <[email protected]> > 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 t= he > >> > >> 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 lik= e > >> > 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). > > > 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. > Not sure why we would do that, it is not like the longer term support branches are specific to any one distro - they're specific to a given KDE release version. There wouldn't be anything to stop another distribution that shares the same release cadence picking up those same branches. > > -- > =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! > Cheers, Ben --0000000000007f27d40651b0d385 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr">On Wed, May 13, 2026 at 10:26=E2=80=AFPM = Neal Gompa <<a href=3D"mailto:[email protected]">[email protected]</a>= > wrote:</div><div class=3D"gmail_quote gmail_quote_container"><blockquo= te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px = solid rgb(204,204,204);padding-left:1ex">On Wed, May 13, 2026 at 4:12=E2=80= =AFAM Ben Cooksley <<a href=3D"mailto:[email protected]" target=3D"_blan= k">[email protected]</a>> wrote:<br> ><br> > On Wed, 13 May 2026, 3:45=E2=80=AFpm Neal Gompa, <<a href=3D"mailto= :[email protected]" target=3D"_blank">[email protected]</a>> wrote:<br= > >><br> >> On Tue, May 12, 2026 at 4:53=E2=80=AFPM Nicolas Fella <<a href= =3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>= > wrote:<br> >> ><br> >> > On 5/12/26 10:45 PM, 2Albert Astals Cid wrote:<br> >> > > El dimarts, 12 de maig del 2026, a les 20:13:01 (Hora d= =E2=80=99estiu d=E2=80=99Europa<br> >> > > central), Marco Martin va escriure:<br> >> > >> On Tue, May 12, 2026, 18:15 Marco Martin <<a href= =3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>> w= rote:<br> >> > >>> We (as in Techpaladin) pledge to take up the mai= ntenance of such branch as<br> >> > >>> long as it's supported, managing backports, = testing and releases, as well<br> >> > >>> as keeping the new CI nodes green<br> >> > >> What do you think about it? Is something that looks = sensible on the<br> >> > >> upstream/community point of view?<br> >> > > Apologies if the next question sounds a bit blunt I didn= 't figure out how word<br> >> > > it in a somewhat better way.<br> >> > ><br> >> > > Is this something we want to pretend the community is do= ing?<br> >> > ><br> >> > > That is, do we want to try to make this "a KDE thin= g" or is it clearly<br> >> > > structured as a Techpaladin/Kubuntu Focus thing?<br> >> > ><br> >> > > For me the second option makes it "simpler".<b= r> >> > ><br> >> > > Then my suggestion would be to just create "vendor&= quot; branches like the ones<br> >> > > that we have for example in kleopatra/mimetreeparser/fri= ends<br> >> > ><br> >> > >=C2=A0 =C2=A0 gpg4win/23.10<br> >> > >=C2=A0 =C2=A0 gpg4win/24.05<br> >> > >=C2=A0 =C2=A0 gpg4win/gpd-5.0<br> >> > >=C2=A0 =C2=A0 gpg4win/gpd-5.1<br> >> > ><br> >> > > So create something like kubuntufocus/26.04<br> >> > ><br> >> > > Maybe it would even make sense to create such branches f= or KDE Plasma 6.6<br> >> > > (after final 6.6.6 is released) and KDE Gear 25.12?<br> >> ><br> >> > I assume this would be shipped in *upstream* Kubuntu 26.04, n= ot some<br> >> > derived version of that?<br> >> ><br> >> > If that's indeed the case then I'm okay with a more n= eutral name like<br> >> > Frameworks/6.24. Doesn't matter that much who is doing it= .<br> >> ><br> >><br> >> I am skeptical of the viability of this. Back in the days when we = had<br> >> them, Kubuntu didn't ship the point releases anyway because th= e<br> >> updates policy for Kubuntu didn't make it easy for them to do = it. And<br> >> I have seen no indication from *Kubuntu* that this would change<br= > >> anytime soon.<br> >><br> >> Otherwise, I would rather *not* see these branches at all, not as<= br> >> vendor branches either. It's just a bad idea all around becaus= e it<br> >> creates confusion for everyone. Even the gpg4win ones create probl= ems.<br> ><br> ><br> > Can you explain please how vendor specific branches (like the enterpri= se/* ones many years ago, or the gpg4win/* branches today) create issues?<b= r> ><br> <br> Branch names aren't really enough to indicate policy and it also gets<b= r> weird when fixes show up only in those branches. I'm not saying that<br= > it is going to happen in this case, but it's happened before. And it= 9;s<br> hard for it to be clear that they aren't for everyone if the branches<b= r> aren't in their repo fork in their own namespace.<br></blockquote><div>= <br></div><div>Happened before in KDE?</div><div>=C2=A0</div><blockquote cl= ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid= rgb(204,204,204);padding-left:1ex"> <br> Ultimately, that's what I would prefer.<br> <br> > I would not expect people to look at branches with vendor specific nam= ing unless they had a reason to do so.<br> ><br> >><br> >> And as mentioned earlier, this would be a mess if we start having = two<br> >> separate client requests for long-term KDE stack maintenance becau= se<br> >> they're stopping on different points.<br> ><br> ><br> > By separate clients, you mean different distros I assume?<br> ><br> <br> No. It could be two different companies for the same distro even. I<br> was being deliberately ambiguous.<br> <br> For example, Kubuntu *today* has a blessed PPA where they attempt to<br> offer updated Plasma on the Ubuntu base. This is somewhat derived from<br> the KDE neon work. At this time, I am aware of at least two companies<br> commercially shipping Kubuntu(ish) stuff derived from this. There are<br> probably more.<br> <br> It is entirely possible that Techpaladin (representing KFocus) and<br> another company (e.g. Tuxedo) would do the same thing for different<br> points on the same Kubuntu base. And sure, there could also be others<br> on other distro bases (like KDE on AlmaLinux/RHEL or whatnot). In my<br> opinion, this is just going to be really complicated.<br></blockquote><div>= <br></div><div>I think you may have misunderstood what they intend to do.</= div><div><br></div><div>If another group turned up wanting to do LTS for th= e same version that someone else already was doing, my expectation would be= that they would collaborate on that together.</div><div>(ie. a second grou= p for Plasma 6.6 would be expected to work with Techpaladin/KFocus).</div><= div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0= px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> > Note that a rather key difference here is that a commercial vendor, no= t the community, is the one maintaining this.<br> ><br> <br> Right, and that is the main reason I don't think those branches should<= br> be in the community repositories. If they are forks in their own<br> namespace, even on Invent, it's much clearer that it's not for<br> everyone.<br></blockquote><div><br></div><div>Not sure why we would do that= , it is not like the longer term support branches are specific to any one d= istro - they're specific to a given KDE release version.</div><div>Ther= e wouldn't be anything to stop another distribution that shares the sam= e release cadence picking up those same branches.</div><div><br></div><bloc= kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:= 1px solid rgb(204,204,204);padding-left:1ex"> <br> <br> -- <br> =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!<br></blockquote><div><br></div>= <div>Cheers,</div><div>Ben=C2=A0</div></div></div> --0000000000007f27d40651b0d385--