> What I expect to be realistic is including e.g. 0.20.0 shortly before > freeze of bullseye, have it included when bullseye becomes stable 3-6 > months later, and then when 0.20.1 comes out cherry-pick > security-related patches from that (or possibly use upstream release > directly if it _only_ contains conservative minimal security-related > changes) and push that the stable, and repeat for each minor release of > 0.20 branch, and finally when upstream drops support for 0.20 branch > either let it bitrot until a severe flaw is discovered that noone > contributes a patch for, or proactively kick it out of stable/unstable.
I expect bullseye to be around until at least 2026, which would coincide with the release of Bitcoin Core 32 or so. We don't have the resources to maintain ten major versions of Bitcoin Core, so we'd have to provide LTS versions of Bitcoin Core. However, with the code base changing rapidly, security backports become non-trivial not only in cherry-picking them, but also in evaluating their impact and interactions with the code base at the time in the past. Given that the Debian Bitcoin Core package replaced our subtree dependencies with system dependencies, doesn't help in that regard. See also slightly related https://twitter.com/videolan/status/1153976062361178112 The alternative to kick the package out after it is considered no longer secure and removing it from users without replacement doesn't seem too convincing either. Finally, I wonder what the quality assurance process for the Debian Bitcoin Core package looks like. Given that the package is heavily modified (e.g. subtree dependencies), it does not fully benefit from the upstream release process testing. -- Marco
