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
Attachment:
signature.asc
Description: PGP signature