Bug#1107305: Acknowledgement (unblock: mariadb/1:11.8.2-1)
> We are already in the territory of granting a very significant freeze
> exception here. But if you are dropping a diff with "2718 files changed,
> 264039 insertions(+), 84505 deletions(-)" on us, we expect that you
Diff with thousands of files is because there is a new minor upstream
release 11.8.2 included. New minor upstream releases also ship to
stable and oldstable and all Ubuntu releases due to the nature of the
package. It is a big package yes, but if you look at the track record
of these stable updates in past 10 years there have been nearly zero
packaging related regressions. The package has extensive autopkgtests
and probably one of the most extensive Salsa CI pipelines in Debian,
see e.g. https://salsa.debian.org/mariadb-team/mariadb-server/-/pipelines/876280
Also, as you see at
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/?sort=updated_desc&state=merged&first_page_size=20
all changes have had at least one additional person review and approve
them.
Additionally, I wanted to avoid bothering the release team with two
unblock requests in succession, so this includes both 1:11.8.1-5 and
1:11.8.2-1. As we are in a freeze there are more people testing and we
get more bugfixes, see e.g. how
https://qa.debian.org/data/bts/graphs/m/mariadb.png went down
drastically. As the maintainer I have made sure all fixes and tweaks
in past months have been specifically designed to be included in
Trixie and are very well tested. The 1:11.8.1-5 has been in unstable
since 2025-05-26 with zero bugs reported. There are some bug reports
about requested future changes (e.g. "libxm 2.14.x from experimental")
and some bug reports about issues that applied equally to the version
in Debian a year ago, but testing has been very thorough with CI that
all Debian related issues have been caught prior to uploads.
I understand the Release Team wants to maximize stability by
minimizing changes. For this large package I ask you to emphasize the
QA work done inside the team more than the principle of freezing
changes.
Reply to: