├── .gitignore ├── CONTRIBUTING.md ├── DCO ├── LICENSE ├── README.md ├── assets └── images │ ├── agg.png │ ├── app_coarse.png │ ├── app_fine.png │ └── thyme.png ├── cmd └── thyme │ └── main.go ├── darwin.go ├── data.go ├── linux.go ├── list.go ├── release.sh ├── show.go └── windows.go /.gitignore: -------------------------------------------------------------------------------- 1 | *~ 2 | .bin 3 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # How to Contribute 2 | 3 | This Sourcegraph project is [MIT licensed](LICENSE) and accepts 4 | contributions via GitHub pull requests. This document outlines some of 5 | the conventions on development workflow, commit message formatting, 6 | contact points and other resources to make it easier to get your 7 | contribution accepted. 8 | 9 | # Certificate of Origin 10 | 11 | By contributing to this project you agree to the Developer Certificate of Origin 12 | (DCO). This document was created by the Linux Kernel community and is a simple 13 | statement that you, as a contributor, have the legal right to make the 14 | contribution. See the [DCO](DCO) file for details. 15 | 16 | ## Getting Started 17 | 18 | - Fork the repository on GitHub 19 | - Read the [README](README.md) for build and test instructions 20 | - Play with the project, submit bugs, submit patches! 21 | 22 | ## Contribution Flow 23 | 24 | This is a rough outline of what a contributor's workflow looks like: 25 | 26 | - Create a topic branch from where you want to base your work (usually master). 27 | - Make commits of logical units. 28 | - Make sure your commit messages are in the proper format (see below). 29 | - Push your changes to a topic branch in your fork of the repository. 30 | - Make sure the tests pass, and add any new tests as appropriate. 31 | - Submit a pull request to the original repository. 32 | 33 | Thanks for your contributions! 34 | 35 | ### Format of the Commit Message 36 | 37 | We follow a rough convention for commit messages that is designed to answer two 38 | questions: what changed and why. The subject line should feature the what and 39 | the body of the commit should describe the why. 40 | 41 | ``` 42 | scripts: add the test-cluster command 43 | 44 | this uses tmux to setup a test cluster that you can easily kill and 45 | start for debugging. 46 | 47 | Fixes #38 48 | ``` 49 | 50 | The format can be described more formally as follows: 51 | 52 | ``` 53 | : 54 | 55 | 56 | 57 |