Bug#1033811: unblock: mariadb/1:10.11.2-2
> I hope you realize that you're stretching it:
> 68 files changed, 11039 insertions(+), 404 deletions(-)
Yes, there are a lot of fixes. There was an extensive push to test and
polish everything from Feb to mid-March, resulting in 39 git commits.
However everything is purely about bug fixes, improved logging to help
future bugfixes, NEWS, translations etc. Everything is documented in
debian/changelog for users and even more detailed in git commit log
for package developers at
https://salsa.debian.org/mariadb-team/mariadb-server/-/commits/debian/latest
> Several of these changes are not really appropriate and should have been
> done before the hard freeze. The idea of the freeze schedule is to
> stabilize the archive, particularly key packages. mariadb is a key package.
Let's review each change now. I am happy to provide additional explanations.
> One of the changes I'm not please with is that you are renaming
> variables. Really, now?
This is about commit
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/09be495b1ca7811e1c6200215e20de38f26834ec,
right?
The variables were renamed upstream in commit
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/952af4a1794ea640213c9c3b3931c84349493a9b
that affects branches 10.5+ and was done in December 2022. Not ideal
to do in a stable release, agree, but from Debian packager point of
view this change had been in a mariadb.org release already, proven
stable, and minimizing delta to upstream Debian packaging is best for
the long-term maintenance of the package in Debian.
> Why now change from /usr/bin/mysql to /usr/bin/mariadb when the former
> is a symlink to the latter. Seems like unnecessary risks. (You even seem
> to have missed usr/bin/mysqladmin in mariadb-server.postrm, or is it in
> postrm better to have the link?)
I synced contents by carefully reviewing the full directories of
upstream and downstream in Meld Merge, and I did not miss anything,
the full upstream change is included.
Upstream 10.11 branch has the same MYADMIN="/usr/bin/mysqladmin in
https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/d84a2826290d9676faebba0849d1b9fb7f5efcd8/debian/mariadb-server.postrm#L9
as we have now in Debian.
> Renaming patches (why and why now?) also doesn't help with a review;
> it's difficult to see if they are the same.
To facilitate contributions I prefer to accept occasionally even
sub-par contributions, and then fix them up myself. The case you refer
to is debian/patches/{2477.patch =>
2477-rocksdb-atomic-riscv64.patch}. I did not want to carry a patch
that is just a number from
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/34,
so I renamed it to have a sensible title, and added proper metadata in
the patch.
Git renders this rename nicely both on command-line and in e.g.
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/fe0701c4455a6e9f32f9495f286a093ab22c6a26
but I guess you are reviewing just overall patch attached in this bug
report.
> You drop the Hurd patch, but I couldn't find it documented. (Hurd has
> been failing since the first unversioned mariadb, so I can guess, but
> the point of unblock requests is that I shouldn't need to).
https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/fe0701c4455a6e9f32f9495f286a093ab22c6a26
> Drop 2006-kfreebsd-amd64.patch which had already been applied upstream and
> was wrongly being re-applied in Debian.
You are right, I should have included this in the debian/changelog. In
my current workflow I do full documentation in commits (that are
stored permanently on Debian Salsa) and then summarize them in the
debian/changelog to avoid the changelog being too verbose. This one I
should have been more verbose on.
> During my review several days ago I got to the
> 2464-log-missing-upgrade.patch. I might continue the review later but
> for now I'm out of spoons.
This patch adds logging - essentially it makes the server start
nagging if mariadb-upgrade has not been run. Missing the upgrade due
to bugs in maintainer scripts etc occasionally happens, and it is
really hard to get bug submitters to research this themselves or to
provide reproducible steps on what they did. Having the ability for
submitters to copy-paste this message from logs helps tremendously.
I am amazed that you review in detail the full diff attached to the
unblock request. I did not know release managers are that dedicated to
quality, that is great for Debian users!
It awes and humbles me that you are so diligent. At the same time I am
a bit worried will it scale? I sent several emails to co-maintainers,
pkg-mysql-maint list, debian-devel list and tried to rally people to
review MRs at https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests
before these commits when in, but few responded. It is too much work
even for people to do in their spare time. The expectation that one
release manager reads all changes in all unblock requests seems
unrealistic.
Would it be OK if I try to get somebody from the LTS team or somebody
else who is considered a senior DD to review the rest of
https://salsa.debian.org/mariadb-team/mariadb-server/-/commits/debian/latest
between tags debian/1%10.11.1-5 and debian/1%10.11.2-1 so you don't
have to do everything? Would you be happy with the rest of the review
being delegated to somebody else?
- Otto
Reply to: