Package: release.debian.org
Severity: normal
X-Debbugs-Cc: re...@packages.debian.org
Control: affects -1 + src:redis
User: release.debian....@packages.debian.org
Usertags: unblock
Please unblock redis for trixie.
The recent Redis 8 licensing change came really late in Debian's
release cycle, but I believe we should ship Redis 8 in trixie.
Otherwise we are shipping a rather old version of the server (7.0.15)
that upstream will have absolutely no interest in supporting over the
lifetime that we want to support it, and it will make the inevitable
security backports arduous for us as well.
A new way of managing the client's state within the server's codebase
exacerbates this problem, making fairly trivial changes to the code
difficult to reason about at times. (In fact, I'm actually already
encountering this issue: a new CVE landed a few hours ago, and I can
already sense that backporting it to the 7.0.15 version will be a pain.)
Indeed, I think that the advantages of migrating Redis 8 to trixie,
even at this stage of the freeze, outweigh the disadvantages of
shipping 7.0.15 in trixie — or, perhaps even worse, not shipping Redis
at all.
Not that it is determinative, but I've spent a good amount of time in
the past two weeks running around trying to get the other parts of the
Redis into shape in order to make this unblock.
For example, python-redis (6.1.0-1, 6.1.0-2), python-fakeredis
(2.29.0-1 through 2.29.0-4), and fixes for libtest-redisserver-perl
and python-hypothesis (they reverse-depend on Redis in its tests).
At the time of writing, britney is reporting "Too young, only 17 of 20
days old", but I thought I would start this conversation now given
freeze_policy.html's request to ask the RT if maintainers are unsure.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org 🍥 chris-lamb.co.uk
`-
