diff options
Diffstat (limited to 'CONTRIBUTING.md')
| -rw-r--r-- | CONTRIBUTING.md | 165 |
1 files changed, 165 insertions, 0 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..48cdbd5 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,165 @@ +# Contributing to VyOS + +You wan't to help us improve VyOS? This is awesome! + +We accept any kind of Pull Requests on GitHub. In order to get your changes into +the main repository as smooth as possible please take yourself some time and +review this contribution guideline. + +The following paragraphs are an excerpt from our Documentation. + +## Submit a Patch + +Patches are always more than welcome. To have a clean and easy to maintain +repository we have some guidelines when working with Git. A clean repository +eases the automatic generation of a changelog file. + +A good approach for writing commit messages is actually to have a look at the +file(s) history by invoking git log path/to/file.txt. + +### Prepare patch/commit + +In a big system, such as VyOS, that is comprised of multiple components, it’s +impossible to keep track of all the changes and bugs/feature requests in one’s +head. We use a bugtracker named Phorge (formerly known Phabricator) for it (“issue tracker” would +be a better term, but this one stuck). + +The information is used in three ways: + +* Keep track of the progress (what we have already done in this branch and + what we still need to do). +* Prepare automatic release notes for upcoming releases +* Help future maintainers of VyOS (it could be you!) to find out why certain + things have been changed in the codebase or why certain features have been + added + +To make this approach work, every change must be associated with a task number +(prefixed with **T**) and a component. If there is no bug report/feature +request for the changes you are going to make, you have to create a development portal +task first. Once there is an entry in the development portal, you should reference its id +in your commit message, as shown below: + +* `ddclient: T1030: auto create runtime directories` +* `Jenkins: add current Git commit ID to build description` + +If there is no [development portal](https://vyos.dev) reference in the +commits of your pull request, we have to ask you to amend the commit message. +Otherwise we will have to reject it. + +## Writing good commit messages + +The format should be and is inspired by this very good and detailed +[Git documentation](https://git-scm.com/book/ch5-2.html), it is also worth +reading https://chris.beams.io/posts/git-commit/. + +This is nothing VyOS specific - it is more a general topic for distributed +development environments. + +* A single, short, summary of the commit (recommended 50 characters or less, + not exceeding 80 characters) containing a prefix of the changed component + and the corresponding development portal reference e.g. `snmp: T1111:` or + `ethernet: T2222:` - multiple components could be concatenated as in `snmp: + ethernet: T3333` +* In some contexts, the first line is treated as the subject of an email and + the rest of the text as the body. The blank line separating the summary from + the body is critical (unless you omit the body entirely); tools like rebase + can get confused if you run the two together. +* Followed by a message which describes all the details like: + * What/why/how something has been changed, makes everyone’s life easier when + working with `git bisect` + * All text of the commit message should be wrapped at 72 characters if + possible which makes reading commit logs easier with git log on a standard + terminal (which happens to be 80x25) + * If applicable a reference to a previous commit should be made linking those + commits nicely when browsing the history: `After commit abcd12ef ("snmp: + this is a headline") a Python import statement is missing, throwing the + following exception: ABCDEF` +* Always use the `-x` option to the `git cherry-pick` command when back or + forward porting an individual commit. This automatically appends the line: + `(cherry picked from commit <ID>)` to the original authors commit message + making it easier when bisecting problems. +* Every change set must be consistent (self containing)! Do not fix multiple + bugs in a single commit. If you already worked on multiple fixes in the same + file use git add –patch to only add the parts related to the one issue into + your upcoming commit. + +## Bug Report/Issue +Issues or bugs are found in any software project. VyOS is not an exception. + +All issues should be reported to the developers. This lets the developers know +what is not working properly. Without this sort of feedback every developer +will believe that everything is working correctly. + +### I have found a bug, what should I do? + +When you believe you have found a bug, it is always a good idea to verify the +issue prior to opening a bug request. + +* Consult our [Documentation](https://docs.vyos.io) to ensure that you have + configured your system correctly +* Get community support via [Slack](https://slack.vyos.io) or our online + [Forum](https://forum.vyos.io) + +#### Ensure the problem is reproducible + +When you are able to verify that it is actually a bug, spend some time to +document how to reproduce the issue. This documentation can be invaluable. + +When you wish to have a developer fix a bug that you found, helping them +reproduce the issue is beneficial to everyone. Be sure to include information +about the hardware you are using, commands that you were running, any other +activities that you may have been doing at the time. This additional +information can be very useful. + +* What were you attempting to achieve? +* What was the configuration prior to the change? +* What commands did you use? Use e.g. ``show configuration commands`` + +#### Include output + +The output you get when you find a bug can provide lots of information. If you +get an error message on the screen, copy it exactly. Having the exact message +can provide detail that the developers can use. Like wise if you have any log +messages that also are from the time of the issue, include those. They may +also contain information that is helpful for the development team. + +### Reporting + +In order to open up a bug-report/feature request you need to create yourself +an account in the [development portal](https://vyos.dev). On the left +side of the specific project (VyOS 1.2 or VyOS 1.3) you will find quick-links +for opening a bug-report/feature request. + +* Provide as much information as you can +* Which version of VyOS are you using? Use operational level command: + ``show version`` +* How can we reproduce this Bug? Please include a CLI configuration, you can + use ``show configuration command | strip-private`` to remove sensitive + information before publishing. + +## Feature Request + +You have an idea of how to make VyOS better or you are in need of a specific +feature which all users of VyOS would benefit from? To send a feature request +please search the [development portal](https://vyos.dev) if there is already a +request pending. You can enhance it or if you don't find one, create a new one +by use the quick link in the left side under the specific project. + +## Code Contribution + +For contributing code to VyOS please take a short moment and review the guideline +outlined in our Documentation at +https://docs.vyos.io/en/latest/contributing/development.html#submit-a-patch + +### Coding Guidelines + +We have some small coding guidelines which are defined in a separate section of +at https://docs.vyos.io/en/latest/contributing/development.html#coding-guidelines. +The guidelines cover how to create the necessary XML structure for new features +and also how to read in the code from the CLI into the Python based scripting +backend. + +Thank you for taking the time reading this guide. + +It might also worth browsing our [Blog](https://blog.vyos.io) for additional +info and updates. |