Add README/LICENSE/GitHub metadata files.

.github/ISSUE_TEMPLATE.md

@@ -0,0 +1,35 @@
+<!--- Provide a general summary of the issue in the Title above -->
+
+## Expected Behavior
+<!--- If you're describing a bug, tell us what should happen -->
+<!--- If you're suggesting a change/improvement, tell us how it should work -->
+
+## Current Behavior
+<!--- If describing a bug, tell us what happens instead of the expected behavior -->
+<!--- If suggesting a change/improvement, explain the difference from current behavior -->
+
+## Possible Solution
+<!--- Not obligatory, but suggest a fix/reason/workaround for the bug, -->
+<!--- or ideas how to implement the addition or change -->
+
+## Steps to Reproduce (for bugs)
+<!--- Provide a link to a live example, or an unambiguous set of steps to -->
+<!--- reproduce this bug. Include code to reproduce, if relevant -->
+1.
+2.
+3.
+4.
+
+## Context
+<!--- How has this issue affected you? What are you trying to accomplish? -->
+<!--- Providing context helps us come up with a solution that is most useful in the real world -->
+
+## Your Environment
+<!--- Include as many relevant details about the environment you experienced the bug in -->
+* Typha version (if using Typha binary directly `calico-typha --version`):
+* And/Or, `calico/typha` container version (if running Typha in a container):
+* Which orchestrator are you using (e.g. Kubernetes, OpenStack, Docker, Mesos):
+* Orchestrator version (if used):
+* Etcd version (if using etcd datastore driver):
+* Operating System and version:
+* Link to your project (optional):

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,13 @@
+## Description
+A few sentences describing the overall goals of the pull request's commits. 
+Please include 
+- the type of fix - (e.g. bug fix, new feature, documentation)
+- some details on _why_ this PR should be merged
+- the details of the testing you've done on it (both manual and automated)
+- which components are affected by this PR
+
+## Todos
+- [ ] Unit tests (full coverage)
+- [ ] Integration tests (delete as appropriate) In plan/Not needed/Done
+- [ ] Documentation
+- [ ] Backport

CONTRIBUTING.md

@@ -0,0 +1,38 @@
+# Contributing Guidelines
+
+Thanks for thinking about contributing to Project Calico! The success of an
+open source project is entirely down to the efforts of its contributors, so we
+do genuinely want to thank you for even thinking of contributing.
+
+This document contains some guidance and steps for contributing. Make sure you
+read it thoroughly, because if you miss some of these steps we will have to ask
+you to do them after you make your submission, and that slows down our ability
+to merge it.
+
+## Before Contributing: The Contributor License Agreement
+
+If you plan to contribute in the form of documentation or code, before we can
+accept your contribution we need you to sign our Contributor License Agreement.
+You will be prompted to do this as part of the PR process on Github.
+
+## Contributing: code and documentation
+
+For contributing code and documentation we follow the GitHub pull request
+model. This means you should fork our repository on GitHub, make your changes
+in your local repository, and then open a GitHub pull request. This pull
+request will then go through a review process by one or more of the core team.
+
+Code changes will additionally be tested by our continuous integration server.
+We will not accept changes that do not consistently pass our automated unit
+test suite. It is vital that our master branch be passing tests at all times:
+hence the restriction.
+
+The relevant tests are our unit tests: you can run them yourself by running 
+`make ut` from the root of the repository.
+
+Assuming your code review is finished and tests are passing, your change will
+then be merged as soon as possible! Occasionally we will sit on a change, for
+instance if we are planning to tag a release shortly, but this is only to
+ensure the stability of the branch. After the release we will merge your change
+promptly.
+[![Analytics](https://calico-ga-beacon.appspot.com/UA-52125893-3/calico/CONTRIBUTING.md?pixel)](https://github.com/igrigorik/ga-beacon)

README.md

@@ -0,0 +1,110 @@
+[![Slack Status](https://slack.projectcalico.org/badge.svg)](https://slack.projectcalico.org)
+[![IRC Channel](https://img.shields.io/badge/irc-%23calico-blue.svg)](https://kiwiirc.com/client/irc.freenode.net/#calico)
+# Project Calico
+
+<blockquote>
+Note that the documentation in this repo is targeted at Calico contributors.
+<h1>Documentation for Calico users is here:<br><a href="http://docs.projectcalico.org">http://docs.projectcalico.org</a></h1>
+</blockquote>
+
+This repository contains the source code for Project Calico's EXPRIMENTAL 
+Typha daemon, which provides sync offload for Felix.
+
+## How can I get support for contributing to Project Calico?
+
+The best place to ask a question or get help from the community is the
+[calico-users #slack](https://slack.projectcalico.org).  We also have
+[an IRC channel](https://kiwiirc.com/client/irc.freenode.net/#calico).
+
+## Who is behind Project Calico?
+
+[Tigera, Inc.](https://www.tigera.io/) is the company behind Project Calico
+and is responsible for the ongoing management of the project. However, it
+is open to any members of the community – individuals or organizations –
+to get involved and contribute code.
+
+## Contributing
+
+Thanks for thinking about contributing to Project Calico! The success of an
+open source project is entirely down to the efforts of its contributors, so we
+do genuinely want to thank you for even thinking of contributing.
+
+Before you do so, you should check out our contributing guidelines in the
+`CONTRIBUTING.md` file, to make sure it's as easy as possible for us to accept
+your contribution.
+
+## How do I build Typha?
+
+Typha mostly uses Docker for builds.  We develop on Ubuntu 16.04 but other
+Linux distributions should work (there are known Makefile that prevent building on OS X).  
+To build Typha, you will need:
+
+- A suitable linux box.
+- To check out the code into your GOPATH.
+- Docker >=1.12
+- GNU make.
+
+Then, as a one-off, run
+```
+make update-tools
+```
+which will install a couple more go tools that we haven't yet containerised.
+
+Then, to build the calico-typha binary:
+```
+make bin/calico-typha
+```
+or, the `calico/typha` docker image:
+```
+make calico/typha
+```
+
+## How can I run Typha's unit tests?
+
+To run all the UTs:
+```
+make ut
+```
+
+To start a `ginkgo watch`, which will re-run the relevant UTs as you update files:
+```
+make ut-watch
+```
+
+To get coverage stats:
+```
+make cover-report
+```
+or 
+```
+make cover-browser
+```
+
+## How can a subset of the go unit tests?
+
+If you want to be able to run unit tests for specific packages for more iterative
+development, you'll need to install
+
+- GNU make
+- go >=1.7
+
+then run `make update-tools` to install ginkgo, which is the test tool used to
+run Typha's unit tests.
+
+There are several ways to run ginkgo.  One option is to change directory to the
+package you want to test, then run `ginkgo`.  Another is to use ginkgo's
+watch feature to monitor files for changes:
+```
+cd go
+ginkgo watch -r
+```
+Ginkgo will re-run tests as files are modified and saved.
+
+## How do I build packages/run Typha?
+
+### Docker
+
+After building the docker image (see above), you can run Typha and log to screen 
+with, for example:
+`docker run --privileged --net=host -e TYPHA_LOGSEVERITYSCREEN=INFO calico/typha`
+

RELEASING.md

@@ -0,0 +1,44 @@
+# Typha release artifacts
+
+Running the main `make release` target, described below, guides you
+through creating and distributing the following artifacts:
+
+- A git tag for the release, annotated with the release note; ready to
+  push to Github.
+- File `bin/calico-typha`; the static binary relase, which we attach to 
+  the GitHub release.
+- Docker container images: `calico/typha:$VERSION` and
+  `quay.io/calico/typha:$VERSION` containing the Typha binaries.  These
+  are ready to push to Dockerhub and Quay.
+
+# Typha release process
+
+In a nutshell:
+
+- We make a Typha release by creating and pushing an annotated Git tag.  The
+  name of the tag is the Typha version for that release, and the tag content is
+  the release notes.
+
+- There are no hardcoded version numbers anywhere in the codebase (except in
+  packaging files, as described next).  Instead, build processes generate a
+  unique and monotonic Typha version number from the last Git tag and the
+  number of commits since that tag - equally whether they are processing
+  release code (i.e. there is a release tag on HEAD) or code in between
+  releases, or since the last release.
+
+So, to make a Typha release:
+
+- Consider whether you should update the libcalico-go pin in glide.yaml.
+  If you do so, you should run `make update-vendor` to update the
+  `glide.lock` file.  Be wary of any additional libraries that get
+  revved if they aren't being pulled in by the libcalico-go update. At
+  this late stage, it's safer to only update commit IDs that you're
+  explicitly expecting (i.e. undo any changes that `make update-vendor`
+  makes that you weren't expecting).  If in doubt consult a Typha/glide
+  expert!
+
+- Run `make release VERSION=<new version>` and follow the instructions.  This
+  creates the annotated release tag, builds the release artifacts, and tells
+  you what else you need to do to publish those.  The release script
+  expects a version number of the form "2.0.0", with optional suffixes
+  such as "-beta1-rc3".