Newer
Older
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
# Questions
Want to hack on Nanocloud? This page contains information about reporting issues and contributing code.
# Issues
Think you've found a bug or have a new feature to suggest? Let us know!
1. Update to the most recent master release if possible. We may have already
fixed your bug.
2. Search for similar issues. It's possible somebody has encountered
this bug already.
3. Your issue will be verified. Please provide as much information as possible to reproduce the issue.
5. Keep up to date with feedback from the Nanocloud team on your ticket. Your
ticket may be closed if it becomes stale.
The more information you provide, the easier it is for us to validate that
there is a bug and the faster we'll be able to take action.
# Pull Requests
We love pull requests. Here's a quick guide:
1. Fork the repo.
2. Run the tests. We only take pull requests with passing tests, and it's great
to know that you have a clean slate: `make tests`.
3. Add a test for your change. Only refactoring and documentation changes
require no new tests. If you are adding functionality or fixing a bug, we need
a test!
4. Make the test pass.
5. Push to your fork and submit a pull request. Please provide us with some
explanation of why you made the changes you made. For new features make sure to
explain a standard use case to us.
Olivier Berthonneau
committed
Before you make a pull request, squash your commits into logical units of work using `git rebase -i` and `git push -f`. A logical unit of work is a consistent set of patches that should be reviewed together: for example, upgrading the version of a vendored dependency and taking advantage of its now available new feature constitute two separate units of work. Implementing a new function and calling it in another file constitute a single logical unit of work.
Syntax:
* Two spaces, no tabs.
* No trailing whitespace. Blank lines should not have any space.
* a = b and not a=b.
* Follow the conventions you see used in the source already.
* Run `test-linter` to validate your code syntax
# Travis CI Tests
We use **Travis CI** to test each PR before it is merged.
When you submit your PR (or later change that code), a Travis build will automatically be kicked off. A note will be added to the PR, and will indicate the current status of the build.