[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#988611: unblock: kodi/2:19.1+dfsg2-1



Package: release.debian.org
Followup-For: Bug #988611
X-Debbugs-Cc: daveblake@kodi.tv, phunkyfish@kodi.tv

Hi Sebastian,

>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.

Sorry for ponging this late! Let me answer the question as per bullseye FAQ ([1]),
mentioned in the #debian-multimedia channel.

1. Is this a targeted bug fix release, and how does that show?

Yes, it is a bug fix release that addresses various bugs reported to Kodi
upstream and backported from current development branch (master) to stable
release (Matrix). As per Kodi's release policy, only changes tagged with
'Type: Backport' get merged into stable branches.

The 19.1 bugfix release features 89 commits and 80 PRs are closed in
'19.1-Matrix' milestone [2]:

$ git log --oneline --no-merges 19.0-Matrix..19.1-Matrix | wc -l
89

The total number of commits in the PRs counted by script below is 90:

# ===
#!/bin/sh
TOTAL_COUNT=0
while read _1
do
	COMMIT_COUNT=$(gh api "repos/xbmc/xbmc/pulls/$_1/commits" | jq length)
	TOTAL_COUNT=$(( TOTAL_COUNT + COMMIT_COUNT ))
	#echo "$_1: $COMMIT_COUNT"
	gh api "repos/xbmc/xbmc/pulls/$_1/commits" | jq ".[].commit.message" | sed 's/\\n.*"$/"/' | while read _2
	do
		echo "- $_2"
	done
done <<.p
$(gh pr list \
	--limit 100 \
	--search 'milestone:"Matrix 19.1"' \
	--state merged -R xbmc/xbmc \
	--json number |
	jq -r '.[].number')
.p

echo "-------"
echo "Total commit count = $TOTAL_COUNT"
# ===

The missing commit is:

"[Subtitles][Plugins] Do not browse plugin directory when browsing for subtitles"

which has not been merged due to reasons unknown to me. This proves there are
only bug and code quality fixes in the point release.

2. What are the risks of the changes for the quality of the Debian release?

Given that every upstream change must pass the CI pipeline for every supported
architecture to be merged, and the changes were tested by bug reporters and
Kodi users on the forums, I see no significant risks for Debian release quality.

3. Is there a policy that describes what upstream considers acceptable for this
   upstream release?

Yes, see the Kodi official wiki page [3]. Also, there are unwritten rules that
are considered the rule of thumb in merging the fixes.

4. Does that policy align with our bug severity important or higher?

The perception of bugs cab be clearly mapped from Debian to Kodi and vice versa.

For example, the 18.9 point release (the last bugfix release of now old-stable
18.x "Leia" branch) was caused by Cloudflare's decision to break Kodi's SSL
over HTTP/2 implementation. Such a bug would get an RC status in Debian if reported.

5. Does upstream test thoroughly?

Yes. First of all, the fix must build at the committer's machine (see [3]). Then.
code owners and other members of Kodi team review the changes and make sure the
fix does not introduce new regressions. Then, the bug reporters download the
build artifacts produced by Jenkins and confirm the issue is resolved. Finally,
once the PR is approved, the final run of Jenkins builds ensures all architectures
pass the build smoothly and the change gets merged into master. Another build run
is done for stable backports.

6. Has this package seen new upstream version uploads to stable in the past to
   facilitate security support?

Yes, 17.5 fixed two CVEs and was uploaded into stretch, if my memory still serves
me.

7. Look at the diff. If it's long, you probably need a targeted fix.
8. Look at the diff. If there's a number of changes not relevant for Debian,
   you probably need a targeted fix.
9. Look at the diff. If there something in there that is difficult to explain,
   but not directly related to the (RC or important) bugs you are fixing,
   you probably need a targeted fix.

The most controversial change here is removal of 'CStaticLoggerBase' class.
The reasoning behind the change is explained at [4]:

"Yes please do, we will be working with log files from Matrix for some time
to come so may as well have any benifits." (c) Dave Blake. I am adding Dave
to the converation in case the question arises whether it is OK to discard
changes approved by upstream.

The rest of changes are targeted fixes that I already tested manually and
via Podman container with (sort of) autopkgtest. This work is done by me to
ensure release quality at Debian, apart from Kodi team's own efforts to keep
the high standards of coding.

Cheers,
Vasyl

---

[1] https://release.debian.org/bullseye/FAQ.html
[2] https://github.com/xbmc/xbmc/milestone/141?closed=1
[3] https://kodi.wiki/view/Merge_window
[4] https://github.com/xbmc/xbmc/pull/19363


Reply to: