Patches are always more then 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 known as 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’ve already done in this branch and what we still need to do). Prepare 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 Phabricator task first. Once there is an entry in Phabricator, 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 Phabricator 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: https://git-scm.com/book/ch5-2.html 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 Phabricator 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. Limits: We only accept bugfixes in packages other than https://github.com/vyos/vyos-1x as no new functionality should use the old style templates (node.def and Perl/BASH code. Use the new style XML/Python interface instead. Please submit your patches using the well-known GitHub pull-request against our repositories found in the VyOS GitHub organisation at https://github.com/vyos Determinine source package Suppose you want to make a change in the webproxy script but yet you do not know which of the many VyOS packages ship this file. You can determine the VyOS package name in question by using Debian’s dpkg -S command of your running VyOS installation. vyos@vyos:~ dpkg -S /opt/vyatta/sbin/vyatta-update-webproxy.pl vyatta-webproxy: /opt/vyatta/sbin/vyatta-update-webproxy.pl This means the file in question (/opt/vyatta/sbin/vyatta-update-webproxy.pl) is located in the vyatta-webproxy package which can be found here: https://github.com/vyos/vyatta-webproxy Fork Repository and submit Patch Forking the repository and submitting a GitHub pull-request is the preferred way of submitting your changes to VyOS. You can fork any VyOS repository to your very own GitHub account by just appending /fork to any repository’s URL on GitHub. To e.g. fork the vyos-1x repository, open the following URL in your favourite browser: https://github.com/vyos/vyos-1x/fork You then can proceed with cloning your fork or add a new remote to your local repository: Clone: git clone https://github.com/<user>/vyos-1x.git Fork: git remote add myfork https://github.com/<user>/vyos-1x.git In order to record you as the author of the fix please identify yourself to Git by setting up your name and email. This can be done local for this one and only repository git config or globally using git config --global. git config --global user.name "J. Random Hacker" git config --global user.email "[email protected]" Make your changes and save them. Do the following for all changes files to record them in your created Git commit: Add file to Git index using git add myfile, or for a whole directory: git add somedir/* Commit the changes by calling git commit. Please use a meaningful commit headline (read above) and don’t forget to reference the Phabricator ID. Submit the patch git push and create the GitHub pull-request. Attach patch to Phabricator task Follow the above steps on how to “Fork repository to submit a Patch”. Instead of uploading “pushing” your changes to GitHub you can export the patches/ commits and send it to [email protected] or attach it directly to the bug (preferred over email) Export last commit to patch file: git format-patch or export the last two commits into its appropriate patch files: git format-patch -2

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 known as [[ https://phabricator.vyosnet.net | 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’ve already done in this branch and what we still need to do). * Prepare 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 [[ https://phabricator.vyosnet.net | Phabricator ]] task first. Once there is an entry in [[ https://phabricator.vyosnet.net | Phabricator ]], 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 [[ https://phabricator.vyosnet.net | Phabricator ]] 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: [[ https://git-scm.com/book/ch5-2.html | https://git-scm.com/book/ch5-2.html]] * 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 [[ https://phabricator.vyosnet.net | Phabricator ]] 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. Limits: * We only accept bugfixes in packages other than [[ https://github.com/vyos/vyos-1x | https://github.com/vyos/vyos-1x ]] as no new functionality should use the old style templates (`node.def` and Perl/BASH code). Use the new style XML/Python interface instead. Please submit your patches using the well-known GitHub pull-request against our repositories found in the VyOS GitHub organisation at [[ https://github.com/vyos | https://github.com/vyos ]] ### Determine source package Suppose you want to make a change in the webproxy script but yet you do not know which of the many VyOS packages ship this file. You can determine the VyOS package name in question by using Debian’s `dpkg -S` command of your running VyOS installation. ``` vyos@vyos:~ dpkg -S /opt/vyatta/sbin/vyatta-update-webproxy.pl vyatta-webproxy: /opt/vyatta/sbin/vyatta-update-webproxy.pl ``` This means the file in question (`/opt/vyatta/sbin/vyatta-update-webproxy.pl`) is located in the `vyatta-webproxy` package which can be found here: [[ https://github.com/vyos/vyatta-webproxy | https://github.com/vyos/vyatta-webproxy ]] ### Fork Repository and submit Patch Forking the repository and submitting a GitHub pull-request is the preferred way of submitting your changes to VyOS. You can fork any VyOS repository to your very own GitHub account by just appending `/fork` to any repository’s URL on GitHub. To e.g. fork the `vyos-1x` repository, open the following URL in your favourite browser: [[ https://github.com/vyos/vyos-1x/fork | https://github.com/vyos/vyos-1x/fork ]] You then can proceed with cloning your fork or add a new remote to your local repository: Clone: ``` git clone https://github.com/<user>/vyos-1x.git ``` Fork: ``` git remote add myfork https://github.com/<user>/vyos-1x.git ``` In order to record you as the author of the fix please identify yourself to Git by setting up your name and email. This can be done local for this one and only repository `git config` or globally using `git config --global`. ``` git config --global user.name "J. Random Hacker" git config --global user.email "[email protected]" ``` Make your changes and save them. Do the following for all changes files to record them in your created Git commit: * Add file to Git index using `git add myfile`, or for a whole directory: `git add somedir/*` * Commit the changes by calling `git commit`. Please use a meaningful commit headline (read above) and don’t forget to reference the [[ https://phabricator.vyosnet.net | Phabricator ]] ID. * Submit the patch `git push` and create the GitHub pull-request. ### Attach patch to Phabricator task Follow the above steps on how to “Fork repository to submit a Patch”. Instead of uploading “pushing” your changes to GitHub you can export the patches/ commits and send it to [[mailto:// | [email protected]]] or attach it directly to the bug (preferred over email) * Export last commit to patch file: `git format-patch` or export the last two commits into its appropriate patch files: `git format-patch -2`

Patches are always more thethan 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 known as [[ https://phabricator.vyosnet.net | 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’ve already done in this branch and what we still need to do). * Prepare 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 Phabricator task first. Once there is an entry in Phabricator, 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 To make this approach work, every change must be associated with a task number (prefixed with **T**) and a component. If there is no Phabricator reference in the commits of your pull requestbug report/feature request for the changes you are going to make, you have to create a [[ https://phabricator.vyosnet.net | Phabricator ]] task first. Once there is an entry in [[ https://phabricator.vyosnet.net | Phabricator ]], we have to ask you to amend theyou should reference its id in your commit message., Otherwise we will have to reject it.as shown below: **Writing good commit messages* `ddclient: T1030: auto create runtime directories` **The format should be and is inspired by: https://git-scm.com/book/ch5-2.html* `Jenkins: add current Git commit ID to build description` A singleIf there is no [[ https://phabricator.vyosnet.net | Phabricator ]] reference in the commits of your pull request, short,we have to ask you to amend the commit message. summary of the commit (recommended 50 characters or less, not exceeding 80 characters) containing a prefix of the changed component and the corresponding Phabricator reference e.g. snmp: T1111: or ethernet: T2222: - multiple components could be concatenated as in snmp: ethernet: T3333Otherwise we will have to reject it. #### Writing good commit messages The format should be and is inspired by: [[ https://git-scm.com/book/ch5-2.html | https://git-scm.com/book/ch5-2.html]] In some contexts* A single, short, the first line is treated assummary of the subject of an email and the rest of the text as the body.commit (recommended 50 characters or less, The blank line separating the summary from the body is critical (unless you omit the body entirely);not exceeding 80 characters) containing a prefix of the changed component and the corresponding [[ https://phabricator.vyosnet.net | Phabricator ]] reference e.g. tools like rebase can get confused if you run the two tog`snmp: T1111:` or `ethernet: T2222:` - multiple components could be concatenated as in `snmp: ether.net: T3333` Followed by a message which describes all the details like:* 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. What/why/how something has been changed, makes everyone’s life easier when working with git bisect* Followed by a message which describes all the details like: 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)** What/why/how something has been changed, makes everyone’s life easier when working with// git bisect// 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** 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) Always use the -x option to the git cherry-pick command when back or forward porting an individual commit.** 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, This automatically appends the line: (cherry picked from commit <ID>) to the original authors commit message making it easier when bisecting problems.throwing the following exception: ABCDEF` Every change set must be consistent (self containing)! Do not fix multiple bugs in a single* Always use the `-x` option to the `git cherry-pick` command when back or forward porting an individual 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 commitThis 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. Limits: * We only accept bugfixes in packages other than [[ https://github.com/vyos/vyos-1x | https://github.com/vyos/vyos-1x ]] as no new functionality should use the old style templates (`node.def` and Perl/BASH code). Use the new style XML/Python interface instead. Please submit your patches using the well-known GitHub pull-request against our repositories found in the VyOS GitHub organisation at https://github.com/vyos Determinine source package Suppose you want to make a change in the webproxy script but yet you do not know which of the many VyOS packages ship this file. You can determine the VyOS package name in question by using Debian’s dpkg -S command of your running VyOS installation.Please submit your patches using the well-known GitHub pull-request against our repositories found in the VyOS GitHub organisation at [[ https://github.com/vyos | https://github.com/vyos ]] ### Determine source package Suppose you want to make a change in the webproxy script but yet you do not know which of the many VyOS packages ship this file. You can determine the VyOS package name in question by using Debian’s `dpkg -S` command of your running VyOS installation. ``` vyos@vyos:~ dpkg -S /opt/vyatta/sbin/vyatta-update-webproxy.pl vyatta-webproxy: /opt/vyatta/sbin/vyatta-update-webproxy.pl This means the file in question (/opt/vyatta/sbin/vyatta-update-webproxy.pl) is located in the vyatta-webproxy package which can be found here: https://github.com/vyos/vyatta-webproxy Fork Repository and submit Patch``` Forking the repository and submitting a GitHub pull-request is the preferred way of submitting your changes to VyOS. You can fork any VyOS repository to your very own GitHub account by just appending /fork to any repository’s URL on GitHub. To e.g. fork the vyos-1x repository, open the following URL in your favourite browser: https://github.com/vyos/vyos-1x/forkThis means the file in question (`/opt/vyatta/sbin/vyatta-update-webproxy.pl`) is located in the `vyatta-webproxy` package which can be found here: [[ https://github.com/vyos/vyatta-webproxy | https://github.com/vyos/vyatta-webproxy ]] ### Fork Repository and submit Patch Forking the repository and submitting a GitHub pull-request is the preferred way of submitting your changes to VyOS. You can fork any VyOS repository to your very own GitHub account by just appending `/fork` to any repository’s URL on GitHub. To e.g. fork the `vyos-1x` repository, open the following URL in your favourite browser: [[ https://github.com/vyos/vyos-1x/fork | https://github.com/vyos/vyos-1x/fork ]] You then can proceed with cloning your fork or add a new remote to your local repository: Clone: git clone https://github.com/<user>/vyos-1x.git ``` Fork: git remote add myforkclone https://github.com/<user>/vyos-1x.git ``` Fork: ``` git remote add myfork https://github.com/<user>/vyos-1x.git ``` In order to record you as the author of the fix please identify yourself to Git by setting up your name and email. This can be done local for this one and only repository `git config` or globally using `git config --global. `. ``` git config --global user.name "J. Random Hacker" git config --global user.email "[email protected]" ``` Make your changes and save them. Do the following for all changes files to record them in your created Git commit: * Add file to Git index using `git add myfile`, or for a whole directory: `git add somedir/*` * Commit the changes by calling `git commit`. Please use a meaningful commit headline (read above) and don’t forget to reference the [[ https://phabricator.vyosnet.net | Phabricator ID]] ID. Submit the patch git push and create the GitHub pull-request. Attach patch to Phabricator task Follow the above steps on how to “Fork repository to submit a Patch”. Instead of uploading “pushing” your changes to GitHub you can export the patches/ commits and send it to [email protected] or attach it directly to the bug (preferred over email)* Submit the patch `git push` and create the GitHub pull-request. ### Attach patch to Phabricator task Follow the above steps on how to “Fork repository to submit a Patch”. Instead of uploading “pushing” your changes to GitHub you can export the patches/ commits and send it to [[mailto:// | [email protected]]] or attach it directly to the bug (preferred over email) * Export last commit to patch file: `git format-patch` or export the last two commits into its appropriate patch files: `git format-patch -2`