Bug#989257: unblock: kodi/2:19.1+dfsg2-1
Control: tag -1 -moreinfo On Mon, Jun 07, 2021 at 09:50:07AM +0200, Sebastian Ramacher wrote: > please go ahead. Remove the moreinfo tag once the new version is > available in unstable. Uploaded. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#989257: unblock: kodi/2:19.1+dfsg2-1
Control: tags -1 moreinfo confirmed On 2021-05-30 17:02:11, Mattia Rizzolo wrote: > Package: release.debian.org > User: release.debian@packages.debian.org > Usertags: unblock > X-Debbugs-Cc: Vasyl Gello > Control: submitter -1 Vasyl Gello > > Following #988611, I'm opening a new unblock bug to discuss the proposed > update of src:kodi to the 19.1 point release. > > Here, I'm forwarding the message that Vasyl already sent to the > previous bug. > > > I also prepared (but have not uploaded to Salsa yet) the 2:19.1+dfsg2-1 > > that uses > > the same embedded copies that were used in 2:19.0+dfsg1-1 that is currently > > in > > bullseye. > > > > Filtered diff from 2:19.0+dfsg1-2 to 2:19.1+dfsg2-1 is attached with the > > following > > filtrdiff options: > > > > filterdiff kodi_19.0+dfsg1-2_19.1+dfsg2-1.diff \ > > -x "*/addons/*.xml" \ > > -x "*/cmake/scripts/windows/*" \ > > -x "*/docs/*" \ > > -x "*/Changelog" \ > > -x "*/Makefile.in" \ > > -x "*/*.m4" \ > > -x "*/configure" \ > > -x "*/msvc/*" \ > > -x "*/media/*" \ > > -x "*/system/*" \ > > -x "*/tools/buildsteps/windows/*" \ > > -x "*/xbmc/cores/VideoPlayer/VideoRenderers/windows/*" \ > > -x "*/xbmc/windowing/win10/*" \ > > -x "*/xbmc/windowing/windows/*" \ > > 1>kodi_19.0+dfsg1-2_19.1+dfsg2-1.filtered.diff > > > Also, two other messages to give some context: > > On 2021-05-30 16:10:02 +0200, Sebastian Ramacher wrote: > > On 2021-05-30 09:25:27 +, Vasyl Gello wrote: > > > As I wrote in the private message to you earlier this week, I don't want > > > to take > > > responsibility from the Kodi upstream and cherry-pick only some bugfixes > > > that might > > > be considered "important" from my PoV. This creates an inconsistent user > > > experience > > > across vanilla Kodi and Kodi from Debian, plus requires me to spend even > > > more time > > > carefully testing each combination of cherry-picked commits in addition > > > to all the > > > time I already spent fixing a lot of stuff upstream and in Debian. > > > > > > The Kodi upstream has an estabilished testing and backport culture, and > > > it is not that > > > easy to slip a risky change into a stable branch (which 19.x currently > > > is). Plus all > > > upstream changes must pass CI before getting merged. > > > > > > If it is not possible to have 19.x point (bugfix) releases in bullseye, I > > > think > > > I will upload next point releases to experimental during the bullseye > > > freeze, > > > then to bullseye-backports after bookworm development cycle starts. And > > > for stable > > > branch I will port only CVE fixes and bug fixes reported to Debian. > > > > I don't think my previous answer implied that the 19.x bugfix release > > is unfit for bullseye. It was an attempt to get some important fixes > > into the release as -2 first, and to then have a look at the > > other changes. > > > > Unfortunately your descriptions of the changes in kodi (and all the > > plugins) are very terse and only highlight changes that sound like they > > would fit the freeze policy. The other changes -- like the > > reimplementation of kodi's logging which is a few hundred lines if not > > more or newly added features -- are swept under the rug. We do not have > > the time to dig into upstream's decision to include those changes and the > > associated risks. If you as maintainer think that it's worth having > > these changes in bullseye, please help us reviewing the changes by > > explaining why the changes are needed and the potential regressions > > they could introduce. With the discussion now present in the old unblock bug (#988611), please go ahead. Remove the moreinfo tag once the new version is available in unstable. Cheers -- Sebastian Ramacher
Bug#989257: unblock: kodi/2:19.1+dfsg2-1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: Vasyl Gello Control: submitter -1 Vasyl Gello Following #988611, I'm opening a new unblock bug to discuss the proposed update of src:kodi to the 19.1 point release. Here, I'm forwarding the message that Vasyl already sent to the previous bug. > I also prepared (but have not uploaded to Salsa yet) the 2:19.1+dfsg2-1 that > uses > the same embedded copies that were used in 2:19.0+dfsg1-1 that is currently in > bullseye. > > Filtered diff from 2:19.0+dfsg1-2 to 2:19.1+dfsg2-1 is attached with the > following > filtrdiff options: > > filterdiff kodi_19.0+dfsg1-2_19.1+dfsg2-1.diff \ > -x "*/addons/*.xml" \ > -x "*/cmake/scripts/windows/*" \ > -x "*/docs/*" \ > -x "*/Changelog" \ > -x "*/Makefile.in" \ > -x "*/*.m4" \ > -x "*/configure" \ > -x "*/msvc/*" \ > -x "*/media/*" \ > -x "*/system/*" \ > -x "*/tools/buildsteps/windows/*" \ > -x "*/xbmc/cores/VideoPlayer/VideoRenderers/windows/*" \ > -x "*/xbmc/windowing/win10/*" \ > -x "*/xbmc/windowing/windows/*" \ > 1>kodi_19.0+dfsg1-2_19.1+dfsg2-1.filtered.diff Also, two other messages to give some context: On 2021-05-30 16:10:02 +0200, Sebastian Ramacher wrote: > On 2021-05-30 09:25:27 +, Vasyl Gello wrote: > > As I wrote in the private message to you earlier this week, I don't want to > > take > > responsibility from the Kodi upstream and cherry-pick only some bugfixes > > that might > > be considered "important" from my PoV. This creates an inconsistent user > > experience > > across vanilla Kodi and Kodi from Debian, plus requires me to spend even > > more time > > carefully testing each combination of cherry-picked commits in addition to > > all the > > time I already spent fixing a lot of stuff upstream and in Debian. > > > > The Kodi upstream has an estabilished testing and backport culture, and it > > is not that > > easy to slip a risky change into a stable branch (which 19.x currently is). > > Plus all > > upstream changes must pass CI before getting merged. > > > > If it is not possible to have 19.x point (bugfix) releases in bullseye, I > > think > > I will upload next point releases to experimental during the bullseye > > freeze, > > then to bullseye-backports after bookworm development cycle starts. And for > > stable > > branch I will port only CVE fixes and bug fixes reported to Debian. > > I don't think my previous answer implied that the 19.x bugfix release > is unfit for bullseye. It was an attempt to get some important fixes > into the release as -2 first, and to then have a look at the > other changes. > > Unfortunately your descriptions of the changes in kodi (and all the > plugins) are very terse and only highlight changes that sound like they > would fit the freeze policy. The other changes -- like the > reimplementation of kodi's logging which is a few hundred lines if not > more or newly added features -- are swept under the rug. We do not have > the time to dig into upstream's decision to include those changes and the > associated risks. If you as maintainer think that it's worth having > these changes in bullseye, please help us reviewing the changes by > explaining why the changes are needed and the potential regressions > they could introduce. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- kodi_19.0+dfsg1-2_19.1+dfsg2-1.filtered.diff.gz Description: application/gzip signature.asc Description: PGP signature
