Bug#971515: Request for security team input on kubernetes TC bug

[Florian Weimer <fw@deneb.enyo.de>]

* Moritz Mühlenhoff:

> * Follow a scheme similar to Firefox ESR where in case of a security
>   the update either happens to the latest minor release of
>   the current branch or if that has stopped, happens to the next
>   major release. To map this to specific k8s releases: Let's assume bullseye
>   were already stable and would ship 19.3. In three months a security issue
>   arises which is severe enough to warrant an update and we ship 19.5
>   in a DSA. Fast forward 6 months and 19.x is EOLed, but some severe
>   security issue needs to be fixed; then the bullseye update would move
>   to 20.1 or so. That sounds unusual for a Debian release, but it's
>   the status quo for _any_ Kubernetes user after all (whether deployed
>   on premises or at some "cloud vendor").

Another thing to consider: Kubernetes rebases will likely require Go
rebases, if I read this table correctly:

<https://github.com/kubernetes/community/blob/master/contributors/devel/development.md#go>

Since Go has a bit of spotty history in terms of kernel backwards
compatibility, this could cause further challenges.