On Mon, Jun 18, 2018 at 09:09:05PM +0200, Jason A. Donenfeld wrote:
> As such, dkg suggested closing this bug to enact the following:
>
> - Migration of package into testing, on a rolling basis.
> - Backporting of package into stable-backports, on a rolling basis.
>
> The long term plan, once testing becomes stable, will be to:
>
> - Maintain oldstable-backports, on a rolling basis.
> - Maintain stable-{backports,security}, on a rolling basis, depending
> on dkg's security judgement. [*]
> - Maintain unstable, on a rolling basis.
>
> The short term plan is:
>
> - Maintain unstable, on a rolling basis.
> - Maintain stable-backports, on a rolling basis.Since this was discussed, Wireguard was actually proposed for mainline, as described here: https://lwn.net/Articles/761939/ It seems to me more likely that Wireguard will stabilize in a Linux kernel release shipped with Buster than outside. What are the plans for wireguard *outside* of mainline once it's merged, actually? That could shape how we handle the packaging on our side... What's the status on that inclusion? From what I understand, it requires fairly deep changes to the kernel's crypto subsystems, so it might take time. But then again buster is not about to be released so maybe it's reasonable to just wait for mainline inclusion instead of relying on dkms packages... On the other hand, that won't give stretch users access to the code either. So once the code is mainlined (or before?) maybe it would make sense to have a 1.0-like release of some sort that we could ship in buster, regardless of the situation in the kernel, and then backport to stretch... Does that make sense? Thanks! -- The world is a dangerous place, not because of those who do evil, but because of those who look on and do nothing. - Albert Einstein
signature.asc
Description: PGP signature
