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