The standard way and historically the only way is to submit your patch via our erlang-patches Mailing List.
Make sure you subscribe to The mailing list
The recommended way of sending patches is described on this page. First, you push your changes to a git repository and send us an email with a reference to your public git repository and branch. If mailing is not your cup of tea, you may send us a Pull Request via GitHub.
If you follow the instructions, you should receive a response within one workday.
By following the instructions, you help the Erlang/OTP team to be more productive, ultimately benefiting all Erlang/OTP users.
If you submit a patch in a way other than what is described here, it implies more work for the Erlang/OTP team. In that case we cannot guarantee anything. It is up to the maintainer for that part of OTP to decide whether (s)he will pick up the patch.
If the patch corrects a bug considered severe by the Erlang/OTP team we will take care of it regardless of how it was submitted. This includes bugs related to system startup, corrupt data and bugs causing VM crashes. We never apply patches without verification, and may implement the patch in a way we find better than the original patch.
Pull requests are now handled on a daily basis and your changes will go through essential tests before it will be handled and reviewed by the OTP Team.
If you are not used to GitHub Pull Requests, please have a look at Using Pull Requests to familiarize yourself with the concept.
Before you send your patch to us, take a deep thought about your contribution, whether it is a bug-fix or if it is a new feature. If it is a new feature, you will need to provide us further information and the process is slightly longer.
If your patch is not a new feature you can stop reading now and skip to next point.
If you patch is a new feature you need to make a EEPLight in about 200 words and put this in the mail that you will send to us. The time-estimation for receiving an answer of interest in this new feature is approximately one month.
Please have git setup with consistent user information before sending a patch. Preferably with your real name and a
working email address (the one you use on the
erlang-patches mailing list, for example).
For quick reference, here are the relevant git commands:
git config --global user.name "Your Name Comes Here" git config --global user.email email@example.com
To ease our daily testings, we want all patches based on the
maint branch. After review, you may get questioned to rebase your patch on master if we think that your new feature will end up in that branch.
So, create a new branch starting from
maint (the maintenance branch for the current major release).
You can do this via the following instructions (assuming you already have a github account and you are signed in):
git clone firstname.lastname@example.org:your_username/otp.git
git remote add upstream git://github.com/erlang/otp.git
git push origin origin:refs/heads/new_feature_name
git checkout --track -b new_feature_name origin/new_feature_name
maintbranch on the otp remote into your new branch:
git pull upstream master
masterthan you branched from, rebase your branch on
master. After checking out your branch:
git fetch upstream… And fix any merge conflicts. Do not merge from
git rebase upstream/master
mastersince we want a straight chain of commits based on a fairly recent
Each branch should contain conceptually related commits (for example the implementation of a single feature), not a mixed set of random changes.
See forking tips on GitHub, for managing the OTP team branches as the upstreams.
git bisectcommand, make sure that each commit can be compiled and that it works.
git diff --check.
The following steps are not necessary if you only want feedback on a proposed change, but are ultimately necessary if you want it to be included in OTP.
(setq c-basic-offset 4)to
.emacsto get C code correctly indented.)
Send an email to
email@example.com with a reference to your github repository and name of the branch to pull from (and the EEPLight document if it is a new feature). To make it really easy for us to fetch the patch, please include the entire git command. For example:
git fetch git://github.com/bjorng/otp.git my-cool-updates
my-cool-updates is the name of the branch.
Additionally include the following two links for viewing the changes:
And last but not least create a pull request for the patch.
All this will make sure that we can handle your patch as fast as possible, by getting some automatic building/testing on the patch before we take a look ourselves.
where BASE should be the base branch,
For the diff to be correct you need to make sure that the default branch configured on github is set to
master (which is the case when you fork) and is up-to-date (same as upstream/BRANCH).
(We also accept inline patches compatible with format generated by
git format-patch, but please make sure your email client has not garbled the message.)
Irrespective if your patch is a new feature or a bug-fix, you will get a confirmation mail within 1-3 working days.
If your patch is a new feature, this is what is going to happen:
If your patch is a bug-fix, this is what is going to happen:
You should not base any branches on a
pu branch, as it will frequently be rebuilt from scratch on top of the current development branch.
We run automatic tests and builds of the
If a branch included in
pu causes a build problem, that branch will be dropped. We will reinstate the branch if/when we receive a correction.
We might also drop a branch if it causes test cases to fail.
We might also drop a branch if we want to address the issue in a different way.
Patches will “cook” in the
pu branch until they graduate or are dropped.
The following may happen to a patch (one or more times):
pu, it may be removed from
puuntil the problems have been corrected.
Usually a patch will graduate to the
master branch when it passes the criteria for being OTP-compliant. Application-maintainer in question will decide when a patch will graduate. For larger patches and for patches on the borderline of breaking backward compatibility, several people in the OTP group will be involved in the graduation process.
Last edited by David N. Welton,