Hello,

I was wondering if the Debian KDE team will release subsequent versions of Plasma on the backports branch instead of using the experimental branch. I
know about the Nolbert's repo, but in my opinion it could be more suitable uploading its work to backports.

Thanks for reading me,
Jose A.

<div dir="ltr"><div>Hello,</div><div><br></div><div>I was wondering if the Debian KDE team will release subsequent versions of Plasma on the backports branch instead of using the experimental branch. I know about the Nolbert&#39;s repo, but in my opinion
it could be more suitable uploading its work to backports.</div><div><span class="gmail-VIiyi" lang="en"><span class="gmail-JLqJ4b gmail-ChMk0b"><span><br></span></span></span></div><div><span class="gmail-VIiyi" lang="en"><span class="gmail-JLqJ4b gmail-
ChMk0b"><span>Thanks for reading me,<br></span></span></span></div><div><span class="gmail-VIiyi" lang="en"><span class="gmail-JLqJ4b gmail-ChMk0b"><span>Jose A.<br></span></span></span></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi

I was wondering if the Debian KDE team will release subsequent versions of Plasma on the backports branch instead of using the experimental branch. I

After the release of Bullseye, normal uploads to unstable and follow-up transition to testing will resume, so the current use for experimental
will stop.

Whether we have the time and energy to care for backports is a different question, but volunteers are greatly welcome to take over backports
management.

Best

Norbert

--
PREINING Norbert https://www.preining.info
Fujitsu Research + IFMGA Guide + TU Wien + TeX Live + Debian Dev
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Jose! (Norbert, please skip to the end)

Reply follows inline:

Jose Angel Pastrana <japp.debian@gmail.com> writes:

Hello,

I was wondering if the Debian KDE team will release subsequent versions of Plasma on the backports branch instead of using the experimental branch. I know about the Nolbert's repo, but in my opinion it could be more suitable uploading its work to backports.

Thanks for reading me,
Jose A.

The purpose of experimental is fundamentally different than backports. Experimental is used to stage "transitions" (https://wiki.debian.org/Teams/ReleaseTeam/Transitions), to gather data
about how an upload of new packages will affect the rest of the Debian
archive (eg: how much will break?), to debug potential dependency
issues, etc.

I. The normal flow of packages (outside of the freeze) is:
1. Upload to unstable
2. Packages migrates to testing if no release critical bugs are
found
3. The packages in testing eventually become the next stable release

II. The flow of packages for backports is:
a. Upload to unstable
b. Packages migrates to testing if no release critical bugs are
found
c. Package is backported from testing to stable

III. And experimental is something else:
i. Upload to experimental
ii. Package does not migrate anywhere
* During the freeze, new upstream versions are uploaded to
experimental for this reason.
iii. DebCI builds packages in unstable with dependencies from
experimental to test for build-time regressions, and also, when
possible, to use autopkgtests to test for regressions.

Outside of the freeze, doing work in experimental prevents regressions
in unstable, which also has the side-effect of keeping packages in
testing more current, because the absence of regressions and RC bugs
allows testing to remain more up-to-date.

Doing work in backports enables access to newer packages on stable.

In other words, experimental is like a temporary head for package
development, and backports is a tail. Also, backports are only feasible
when they don't require a rebuild of tangential parts of the archive in
stable. For example, if a backports of a package requires a newer
version of Qt than stable has, then the backport is not feasible,
because a Qt backport would be required, and this would require
backports to provide a rebuild of all Qt-using packages from stable.

Norbert, of course it's too early to say for sure, but what is your
feeling about what KDE Plasma will require during the Bookworm dev
cycle? Do you think it's more likely to go smoothly or to end up in the situation where backports can no longer proceed due to something like an insufficiently new version of Qt in Bullseye? If it's feasible, then
this is something I may be interested in post-buster release :-) Also,
do we yet have a solution for providing QtWebEngine with security fixes
to users of stable? Last I heard Falkon was still non-viable for
general web browsing on Debian stable for this reason :-( (IIRC because
we don't have access to LTS security fixes for Qt?)

Regards,
Nicholas

-----BEGIN PGP SIGNATURE-----

iQJHBAEBCgAxFiEE4qYmHjkArtfNxmcIWogwR199EGEFAmCm1pATHG5zdGVldmVz QGdtYWlsLmNvbQAKCRBaiDBHX30QYfCfD/9EuhLKvEULmm5qz9AJNsB1VZ1S3zIJ hEFFmaBfxkI7eJ2lN9calkt9w5F7Awj9pvjZnjAaLn0oS02M1x3GoxSykL/icQ7t VmyJEbiLYUaeb9UiZARVnQ0Em/qVXppQDaKMNnBUw9G37UrFeawt+KX0CbXbB+PR EYJZLBXbdovN+agjFItM+BVc8QiZ2XuHClohE4h5csEjizATCXoC3h0dYeff3s6g /ZseiNAYkLVQhw+EnB9DKDzLoTRzwwJot65Tj+18K3vxJWTrtXYoRrQHufTE1OBw LNsnfksQaMsKFutL1IcF2eE1Wrj3Mbm7hwjCI4aI29HI5/QegdQehoUc7oUxWrko 8sTHJfzzhupTsy5SIqBnV2VTdYB1RzDfoebE6/OvkXDcBiZlevJds1+FdpWEidT7 9GS0cmhGWmxk8mJ4M8VR6NMaVKiBwiV9YiuCQqNGeu5MiQMeFhQrb10Qc3SwV8rm JWARY+ppFtPxbMa8yYe+suIUHJ36628WiZ4pL6YYfohK6DLJiFIp1fwNVLrDQXF/ 25FLuZXCHDO3s+HHDfcfyfzkI3OmjE/267EDSGDIM9X0/z2iYvDq1xel+YVj0gqE k5kSFV3FdRyRiIH29U0ecTjJcmZ+iZSI0AGnaYqFyyP9s6AD02FiEhScSGYYzbbG Mp7gONhBOclh9w==
=GpvT
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Nick,

Norbert, of course it's too early to say for sure, but what is your
feeling about what KDE Plasma will require during the Bookworm dev

My guess is that:
- Qt6 based releases (frameworks6 and Gears something) will come out
- we will have a hard time getting Qt6 into Debian
- we might end up with the last Qt5 based stack in bookworm

Under these circumstances, backporting seems possible.

It all hangs on whether we get Qt6 packaged. Here is the biggest lack of
man power and knowledge.

Best

Norbert

--
PREINING Norbert https://www.preining.info
Fujitsu Research + IFMGA Guide + TU Wien + TeX Live + Debian Dev
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi!

On Thu, 20 May 2021 at 19:50, Norbert Preining <norbert@preining.info> wrote:

Hi Nick,

Norbert, of course it's too early to say for sure, but what is your
feeling about what KDE Plasma will require during the Bookworm dev

My guess is that:
- Qt6 based releases (frameworks6 and Gears something) will come out
- we will have a hard time getting Qt6 into Debian
- we might end up with the last Qt5 based stack in bookworm

Under these circumstances, backporting seems possible.

Qt can not be backported if the private API changes, as binNMUs are
not allowed in backports.

So as long as no Qt backport is required, yes, it might be doable.

It all hangs on whether we get Qt6 packaged. Here is the biggest lack of
man power and knowledge.

Man power mostly. Dmitry and I, as much as we can do, will be happy to help/guide whoever wants to take the **really big** job of maintaining
Qt.

In other words: do not expect Qt 6 soon.

--
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Lisandro,

Qt can not be backported if the private API changes, as binNMUs are
not allowed in backports.

So as long as no Qt backport is required, yes, it might be doable.

Indeed!
Considering that development has mostly moved on to Qt6, I don't expect
any breakage of APIs in the Qt5 version.

Man power mostly. Dmitry and I, as much as we can do, will be happy to help/guide whoever wants to take the **really big** job of maintaining
Qt.

Well, someone has to step forward ...

In other words: do not expect Qt 6 soon.

I fear so.

Best

Norbert

--
PREINING Norbert https://www.preining.info
Fujitsu Research + IFMGA Guide + TU Wien + TeX Live + Debian Dev
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)