Hockeypuck OpenPGP Public Keyserver

1. Contributing

1.1. Where to contribute

Hockeypuck has been split into several Go package projects.

In general, all Hockeypuck projects are maintained under the hockeypuck organization, in the following Github projects:

1.1.1. Hockeypuck Packages

Hockeypuck is composed of several small Go packages, each of which attempt to do one thing well.

1.1.2. Hockeypuck Server

The Hockeypuck server at integrates the above packages with a server configuration model, logging, server and maintenance utility binaries.

1.1.3. Hockeypuck Front-End is a fork of Matt Rude's pgpkeyserver-lite front end. It's included in the Hockeypuck release for convenience.

1.1.4. Hockeypuck Packaging is a collection of release management scripts. These scripts fetch the above Hockeypuck source packages and all their dependencies at known compatible and working versions. Debian packaging as well as cross-compiled tarballs are supported for release distribution.

1.1.5. Hockeypuck documentation used to be the entire Hockeypuck source tree, but since splitting up into separate package projects, it is used primarily for project documentation.

1.1.6. Hockeypuck testing contains testdata used by some of the other projects, such as OpenPGP key material examples used in openpgp test cases. It also contains Ansible playbooks used to coordinate integration tests. These might be a useful starting point for an Ansible-based deployment of Hockeypuck.

1.2. Tools

1.2.1. gopkg is used to version Hockeypuck APIs. This is a distinct concern from dependency revision management. Versioned APIs provide certain guarantees with regard to compatibility.

1.2.2. godeps

The server releases use godeps for managing package dependencies. I've tried several other dependency management solutions for Go packages, and I find godeps to be simple, easy to work with and well-maintained.

1.2.3. Travis CI

Many of the Hockeypuck projects use Travis CI to build and test the projects on commit. I've found Travis to be more useful than not for small, simple projects with short tests. Which is really where you want to be. It's also nice to test on many versions of Go, which is something I would not bother to do on every commit otherwise.

1.3. Pull request guidelines

Github pull requests will be reviewed on merit of relevance to the project goals. Significant feature development should be discussed first on the mailing list.

In code reviews, I'll look & ask for:


Casey Marshall