Révision 047725bc
README: whitespace adjustments
| README.md | ||
|---|---|---|
| 24 | 24 |
* don't copy the whole template |
| 25 | 25 |
* directly edit files in this directory |
| 26 | 26 |
|
| 27 |
|
|
| 27 | 28 |
# contrib/tools/ - 3rd-party tools |
| 28 | 29 |
|
| 29 |
Here, you can put just any kind of tool. Please use this directory instead of a random place on the internet.
|
|
| 30 |
Here, you can put just any kind of tool. Please use this directory instead of a random place on the internet. |
|
| 30 | 31 |
It makes things way more easy to search for others. |
| 31 | 32 |
|
| 32 | 33 |
And, it serves as an incubator of SVN `trunk/contrib` :-) |
| ... | ... | |
| 35 | 36 |
|
| 36 | 37 |
This serves as a repository for examples of various configs. You know, the ''learn by example'' way of doing things. |
| 37 | 38 |
|
| 39 |
|
|
| 38 | 40 |
## Notes to contributors |
| 39 | 41 |
|
| 40 | 42 |
### Commits, Comments & Pull requests |
| 41 | 43 |
|
| 42 |
We like to have _elementary_ commits as it is much easier to manage for reviewing and debugging.
|
|
| 44 |
We like to have _elementary_ commits as it is much easier to manage for reviewing and debugging. |
|
| 43 | 45 |
So please **don't** be afraid to make **as many** commits as needed. Merging many commits is as easy |
| 44 | 46 |
as merging one, if not easier. |
| 45 | 47 |
|
| 46 |
A good rationale is that each commit shall have a one-liner commit comment as its first line.
|
|
| 48 |
A good rationale is that each commit shall have a one-liner commit comment as its first line. |
|
| 47 | 49 |
Ideally that first line has a prefix that shows the part the commit is about. It makes it very |
| 48 | 50 |
easy to see grouped changes, and it enable avoiding to look at the `--stat`. To know the prefix you should |
| 49 | 51 |
use, you can have a look at already existing commits. Next lines are optional and should only |
| 50 |
explain the _why_ it is done this particular way.
|
|
| 52 |
explain the _why_ it is done this particular way. |
|
| 51 | 53 |
|
| 52 | 54 |
On the other side, pull requests can regroup many commits at once. |
| 53 | 55 |
Just try to explain in the pull comment the ''why'' we should merge it (if it's not obvious). |
| 54 | 56 |
|
| 55 | 57 |
Tim Pope wrote a [very nice tuto](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html) on making good commit comments. |
| 56 | 58 |
|
| 59 |
|
|
| 57 | 60 |
### Licenses |
| 58 | 61 |
|
| 59 | 62 |
All the code here is licensed with the same terms as munin itself (GPLv2), unless specified otherwise inside a file. |
| 60 | 63 |
In all cases the code shall have an OSI-compatible license. Asking for a pull implies that you agree with that fact. |
| 61 | 64 |
|
| 62 |
This change was made on Jun 1st 2012. If you wrote some code earlier and you do not agree to the new licensing default, you can :
|
|
| 65 |
This change was made on Jun 1st 2012. If you wrote some code earlier and you do not agree to the new licensing default, you can: |
|
| 63 | 66 |
- submit a licensing change pull |
| 64 |
- submit a removal pull |
|
| 67 |
- submit a removal pull |
|
| 68 |
|
|
| 65 | 69 |
|
| 66 | 70 |
# Building status |
| 67 | 71 |
|
Formats disponibles : Unified diff