[WireGuard] The Distro Package Maintainers Thread

[Baptiste Jonglez]

On Thu, Jun 30, 2016 at 02:52:04PM +0200, Jason A. Donenfeld wrote:
> === 1. Package Names ===
> Probably for the purposes of consistency and ease of use, we should
> standardize our package names. So what about restricting naming to
> either of these two naming options:
> 
> Option a) monolithic:
>     Package name: wireguard
> 
> Option b) split:
>     Tools package name: wireguard-tools
>     Module package name: wireguard _or_ wireguard-${SUFFIX},
>        where SUFFIX is modules, or dkms, or whatever the convention in
> your OS is

On OpenWRT, the packages are necessarily split, and the kernel package is
called kmod-wireguard.  For now I have named the tools package "wireguard",
but there's no problem changing that to "wireguard-tools".

> === 2. Experimental Status ===
> 
> WireGuard isn't meant for prime time. It's still under development,
> and there won't be CVEs or responsible announcements made for various
> issues. The purpose of this phase now is to get it out to interested
> testers and experimenters for working out various issues. Debian is
> very well suited for this configuration, with its experimental tree,
> which is where the package will live until we release the first "0.1"
> or "1.0" version that we stand behind. Arch has a similar place. I
> think OpenWRT has a good slot for this too?

All third-party OpenWRT packages go to https://github.com/openwrt/packages.
There is no notion of "experimental" repositories as this is third-party
anyway.  There are also special branches for stable releases, where
package versions are mostly "frozen":

  https://github.com/openwrt/packages/blob/master/CONTRIBUTING.md#release-branches

> === 3. Versioning ===
> 
> As mentioned prior, we're not at 1.0 or even 0.1. Many packagers can
> deal with building straight from the git master with a live checkout.
> But other packagers can't, and this isn't very nice for testing users
> anyway, since they don't get version bumps for updating. So, it seems
> wise for us to formalize a snapshot versioning scheme. First, there
> are two ways of doing this:
> 
> a) I can tag snapshot releases.
> b) You can select snapshot commit IDs.
> 
> I think between these two options (a) is clearly superior, since then
> I can be sure to tag commits that at least build.

Agreed, you are the most suited person.  It's tedious to have to guess
when upstream changes are either significant or likely to break things.

> With the actual version numbers itself, I think at least it should be
> based on the big endian date stamp:
> 
>     0.0.20160701
> 
> Zero dot zero. But it'd be nice to further specify that these are
> pre-release or experimental:
> 
>     0.0.20160701_pre
>     0.0.20160701_experimental
>     0.0.20160701_killskittens
> 
> Any preference on pre vs experimental vs killskittens vs something
> else? I'm open to anything here.
> 
> The _suffix notation works well with how Gentoo does package versions.
> What about the rest of you? For example, I think this might pose
> problems:
> 
>     0.0.20160701.pre
>     0.0.20160701.experimental
>     0.0.20160701.killskittens
> 
> Or, if anyone has another idea for injecting a label like this into
> the snapshot revision, speak up.
> 
> Overall, at the moment I'm leaning toward  0.0.20160701_experimental.
> But I'll wait for responses before deciding anything.

There does not seem to be any restriction for OpenWRT regarding allowed
characters.  Personally, I'd like to keep the label short for readability
("exp", "pre", "alpha"...).

> Have I left anything out? How does that all sound to you guys?

How often do you plan to tag new snapshot releases?  For OpenWRT, I don't
plan to update the package more often than once every few weeks anyway.

Also, do you plan to have an infrastructure producing a tarball every time
you tag a release?

Baptiste
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20160630/8b80cb79/attachment-0001.asc>