Hi Jose! (Norbert, please skip to the end) Reply follows inline:
Jose Angel Pastrana <japp.deb...@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
signature.asc
Description: PGP signature
