From d2924de2b6a2634a40d2b57c0fdeed255f0d2acd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lo=C3=AFc=20Hoguin?= Date: Thu, 23 Jul 2015 22:46:19 +0200 Subject: Fix .app module list cowboy_stream_h isn't in the repository yet. --- CONTRIBUTING.asciidoc | 173 ++++++++++++++++++++++++++++++++++++++++++++++++++ CONTRIBUTING.md | 173 -------------------------------------------------- ebin/cowboy.app | 2 +- 3 files changed, 174 insertions(+), 174 deletions(-) create mode 100644 CONTRIBUTING.asciidoc delete mode 100644 CONTRIBUTING.md diff --git a/CONTRIBUTING.asciidoc b/CONTRIBUTING.asciidoc new file mode 100644 index 0000000..7bc005b --- /dev/null +++ b/CONTRIBUTING.asciidoc @@ -0,0 +1,173 @@ +Contributing +============ + +Introduction +------------ + +This document describes the usages and rules to follow when contributing +to this project. + +It uses the uppercase keywords SHOULD for optional but highly recommended +conditions and MUST for required conditions. + +`git` is a distributed source code versioning system. This document refers +to three different repositories hosting the source code of the project. +`Your local copy` refers to the copy of the repository that you have on +your computer. The remote repository `origin` refers to your fork of the +project's repository that you can find in your GitHub account. The remote +repository `upstream` refers to the official repository for this project. + +Following this document will ensure prompt merging of your work in the +`master` branch of the project. + +Reporting bugs +-------------- + +Upon identifying a bug or a DoS vulnerability, you SHOULD submit a ticket, +regardless of your plans for fixing it. If you plan to fix the bug, you +SHOULD discuss your plans to avoid having your work rejected. + +Upon identifying a security vulnerability in Erlang/OTP that leaves Cowboy +vulnerable to attack, you SHOULD consult privately with the Erlang/OTP team +to get the issue resolved. + +Upon identifying a security vulnerability in Cowboy's `cowboy_static` module, +you SHOULD submit a ticket, regardless of your plans for fixing it. Please +ensure that all necessary details to reproduce are listed. You then SHOULD +inform users on the mailing list about the issue, advising that they use +another means for sending static files until the issue is resolved. + +Upon identifying a security vulnerability in any other part of Cowboy, you +SHOULD contact us directly by email. Please ensure that all necessary details +to reproduce are listed. + +Before implementing a new feature, you SHOULD submit a ticket for discussion +on your plans. The feature might have been rejected already, or the +implementation might already be decided. + +Cloning +------- + +You MUST fork the project's repository to your GitHub account by clicking +on the `Fork` button. + +Then, from your fork's page, copy the `Git Read-Only` URL to your clipboard. +You MUST perform the following commands in the folder you choose, replacing +`$URL` by the URL you just copied, `$UPSTREAM_URL` by the `Git Read-Only` +project of the official repository, and `$PROJECT` by the name of this project. + +``` bash +$ git clone "$URL" +$ cd $PROJECT +$ git remote add upstream $UPSTREAM_URL +``` + +Branching +--------- + +Before starting working on the code, you MUST update to `upstream`. The +project is always evolving, and as such you SHOULD always strive to keep +up to date when submitting patches to make sure they can be merged without +conflicts. + +To update the current branch to `upstream`, you can use the following commands. + +``` bash +$ git fetch upstream +$ git rebase upstream/master +``` + +It may ask you to stash your changes, in which case you stash with: + +``` bash +$ git stash +``` + +And put your changes back in with: + +``` bash +$ git stash pop +``` + +You SHOULD use these commands both before working on your patch and before +submitting the pull request. If conflicts arise it is your responsability +to deal with them. + +You MUST create a new branch for your work. First, ensure you are on `master`. +You MUST update `master` to `upstream` before doing anything. Then create a +new branch `$BRANCH` and switch to it. + +``` bash +$ git checkout -b $BRANCH +``` + +You MUST use a an insightful branch name. + +If you later need to switch back to an existing branch `$BRANCH`, you can use: + +``` bash +$ git checkout $BRANCH +``` + +Source editing +-------------- + +The following rules MUST be followed: + * Indentation uses horizontal tabs (1 tab = 4 columns) + * Do NOT align code; only indentation is allowed + * Lines MUST NOT span more than 80 columns + +The following rules SHOULD be followed: + * Write small functions whenever possible + * Avoid having too many clauses containing clauses containing clauses + +Committing +---------- + +You MUST ensure that all commits pass all tests and do not have extra +Dialyzer warnings. + +Running tests is fairly straightforward. Note that you need at least +Erlang/OTP R16B01 for the SSL tests to run. + +``` bash +make tests +``` + +Running Dialyzer requires some initial setup. You need to build the PLT +file that Dialyzer will use for its analysis. This is a one-time operation. +Dialyzer will take care of updating that file when needed. + +``` bash +make build-plt +``` + +Once that is done, you can run Dialyzer. + +``` bash +make dialyze +``` + +You MUST put all the related work in a single commit. Fixing a bug is one +commit, adding a feature is one commit, adding two features is two commits. + +You MUST write a proper commit title and message. The commit title MUST be +at most 72 characters; it is the first line of the commit text. The second +line of the commit text MUST be left blank. The third line and beyond is the +commit message. You SHOULD write a commit message. If you do, you MUST make +all lines smaller than 80 characters. You SHOULD explain what the commit +does, what references you used and any other information that helps +understanding your work. + +Submitting the pull request +--------------------------- + +You MUST push your branch `$BRANCH` to GitHub, using the following command: + +``` bash +$ git push origin $BRANCH +``` + +You MUST then submit the pull request by using the GitHub interface. +You SHOULD provide an explanatory message and refer to any previous ticket +related to this patch. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md deleted file mode 100644 index 7bc005b..0000000 --- a/CONTRIBUTING.md +++ /dev/null @@ -1,173 +0,0 @@ -Contributing -============ - -Introduction ------------- - -This document describes the usages and rules to follow when contributing -to this project. - -It uses the uppercase keywords SHOULD for optional but highly recommended -conditions and MUST for required conditions. - -`git` is a distributed source code versioning system. This document refers -to three different repositories hosting the source code of the project. -`Your local copy` refers to the copy of the repository that you have on -your computer. The remote repository `origin` refers to your fork of the -project's repository that you can find in your GitHub account. The remote -repository `upstream` refers to the official repository for this project. - -Following this document will ensure prompt merging of your work in the -`master` branch of the project. - -Reporting bugs --------------- - -Upon identifying a bug or a DoS vulnerability, you SHOULD submit a ticket, -regardless of your plans for fixing it. If you plan to fix the bug, you -SHOULD discuss your plans to avoid having your work rejected. - -Upon identifying a security vulnerability in Erlang/OTP that leaves Cowboy -vulnerable to attack, you SHOULD consult privately with the Erlang/OTP team -to get the issue resolved. - -Upon identifying a security vulnerability in Cowboy's `cowboy_static` module, -you SHOULD submit a ticket, regardless of your plans for fixing it. Please -ensure that all necessary details to reproduce are listed. You then SHOULD -inform users on the mailing list about the issue, advising that they use -another means for sending static files until the issue is resolved. - -Upon identifying a security vulnerability in any other part of Cowboy, you -SHOULD contact us directly by email. Please ensure that all necessary details -to reproduce are listed. - -Before implementing a new feature, you SHOULD submit a ticket for discussion -on your plans. The feature might have been rejected already, or the -implementation might already be decided. - -Cloning -------- - -You MUST fork the project's repository to your GitHub account by clicking -on the `Fork` button. - -Then, from your fork's page, copy the `Git Read-Only` URL to your clipboard. -You MUST perform the following commands in the folder you choose, replacing -`$URL` by the URL you just copied, `$UPSTREAM_URL` by the `Git Read-Only` -project of the official repository, and `$PROJECT` by the name of this project. - -``` bash -$ git clone "$URL" -$ cd $PROJECT -$ git remote add upstream $UPSTREAM_URL -``` - -Branching ---------- - -Before starting working on the code, you MUST update to `upstream`. The -project is always evolving, and as such you SHOULD always strive to keep -up to date when submitting patches to make sure they can be merged without -conflicts. - -To update the current branch to `upstream`, you can use the following commands. - -``` bash -$ git fetch upstream -$ git rebase upstream/master -``` - -It may ask you to stash your changes, in which case you stash with: - -``` bash -$ git stash -``` - -And put your changes back in with: - -``` bash -$ git stash pop -``` - -You SHOULD use these commands both before working on your patch and before -submitting the pull request. If conflicts arise it is your responsability -to deal with them. - -You MUST create a new branch for your work. First, ensure you are on `master`. -You MUST update `master` to `upstream` before doing anything. Then create a -new branch `$BRANCH` and switch to it. - -``` bash -$ git checkout -b $BRANCH -``` - -You MUST use a an insightful branch name. - -If you later need to switch back to an existing branch `$BRANCH`, you can use: - -``` bash -$ git checkout $BRANCH -``` - -Source editing --------------- - -The following rules MUST be followed: - * Indentation uses horizontal tabs (1 tab = 4 columns) - * Do NOT align code; only indentation is allowed - * Lines MUST NOT span more than 80 columns - -The following rules SHOULD be followed: - * Write small functions whenever possible - * Avoid having too many clauses containing clauses containing clauses - -Committing ----------- - -You MUST ensure that all commits pass all tests and do not have extra -Dialyzer warnings. - -Running tests is fairly straightforward. Note that you need at least -Erlang/OTP R16B01 for the SSL tests to run. - -``` bash -make tests -``` - -Running Dialyzer requires some initial setup. You need to build the PLT -file that Dialyzer will use for its analysis. This is a one-time operation. -Dialyzer will take care of updating that file when needed. - -``` bash -make build-plt -``` - -Once that is done, you can run Dialyzer. - -``` bash -make dialyze -``` - -You MUST put all the related work in a single commit. Fixing a bug is one -commit, adding a feature is one commit, adding two features is two commits. - -You MUST write a proper commit title and message. The commit title MUST be -at most 72 characters; it is the first line of the commit text. The second -line of the commit text MUST be left blank. The third line and beyond is the -commit message. You SHOULD write a commit message. If you do, you MUST make -all lines smaller than 80 characters. You SHOULD explain what the commit -does, what references you used and any other information that helps -understanding your work. - -Submitting the pull request ---------------------------- - -You MUST push your branch `$BRANCH` to GitHub, using the following command: - -``` bash -$ git push origin $BRANCH -``` - -You MUST then submit the pull request by using the GitHub interface. -You SHOULD provide an explanatory message and refer to any previous ticket -related to this patch. diff --git a/ebin/cowboy.app b/ebin/cowboy.app index 2db5efc..529374f 100644 --- a/ebin/cowboy.app +++ b/ebin/cowboy.app @@ -1 +1 @@ -{application, cowboy, [ {description, "Small, fast, modular HTTP server."}, {vsn, "2.0.0-pre.2"}, {id, "2.0.0-pre.2-10-g93d1e0c-dirty"}, {modules, [cowboy,cowboy_app,cowboy_bstr,cowboy_clock,cowboy_constraints,cowboy_handler,cowboy_http2,cowboy_loop,cowboy_middleware,cowboy_protocol,cowboy_req,cowboy_rest,cowboy_router,cowboy_spdy,cowboy_static,cowboy_stream,cowboy_stream_h,cowboy_sub_protocol,cowboy_sup,cowboy_tls,cowboy_websocket]}, {registered, [cowboy_sup,cowboy_clock]}, {applications, [kernel,stdlib,crypto,cowlib,ranch]}, {mod, {cowboy_app, []}}]}. +{application, cowboy, [ {description, "Small, fast, modular HTTP server."}, {vsn, "2.0.0-pre.2"}, {id, "2.0.0-pre.2-13-g20456b8-dirty"}, {modules, [cowboy,cowboy_app,cowboy_bstr,cowboy_clock,cowboy_constraints,cowboy_handler,cowboy_http2,cowboy_loop,cowboy_middleware,cowboy_protocol,cowboy_req,cowboy_rest,cowboy_router,cowboy_spdy,cowboy_static,cowboy_stream,cowboy_sub_protocol,cowboy_sup,cowboy_tls,cowboy_websocket]}, {registered, [cowboy_sup,cowboy_clock]}, {applications, [kernel,stdlib,crypto,cowlib,ranch]}, {mod, {cowboy_app, []}}]}. -- cgit v1.2.3