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:
Hockeypuck is composed of several small Go packages, each of which attempt to do one thing well.
The Hockeypuck server at github.com/hockeypuck/server integrates the above packages with a server configuration model, logging, server and maintenance utility binaries.
github.com/hockeypuck/webroot is a fork of Matt Rude's pgpkeyserver-lite front end. It's included in the Hockeypuck release for convenience.
github.com/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.
github.com/hockeypuck/hockeypuck used to be the entire Hockeypuck source tree, but since splitting up into separate package projects, it is used primarily for project documentation.
github.com/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.
gopkg.in is used to version Hockeypuck APIs. This is a distinct concern from dependency revision management. Versioned APIs provide certain guarantees with regard to compatibility.
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.
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.
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: