From 1f948db685a582154bcdcc8cd49ebe4c4e0d4c2b Mon Sep 17 00:00:00 2001 From: "Ignas Anikevicius (gns_ank)" Date: Sat, 24 May 2014 21:13:42 +0100 Subject: [PATCH] Docs: merge PATCHES, STYLE, BUGS into CONTRIBUTING.md Signed-off-by: Ignas Anikevicius (gns_ank) --- BUGS | 1 - CONTRIBUTING.md | 74 +++++++++++++++++++++++++++++++++++++++++++++++++ PATCHES | 29 ------------------- STYLE | 31 --------------------- 4 files changed, 74 insertions(+), 61 deletions(-) delete mode 100644 BUGS create mode 100644 CONTRIBUTING.md delete mode 100644 PATCHES delete mode 100644 STYLE diff --git a/BUGS b/BUGS deleted file mode 100644 index 496f27625..000000000 --- a/BUGS +++ /dev/null @@ -1 +0,0 @@ -Please look at https://github.com/awesomeWM/awesome/issues. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 000000000..9948f717d --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,74 @@ +Bugs +=== + +Please look at http://awesome.naquadah.org/bugs/ + +Style +=== + +If you intend to patch and contribute to awesome, please respect the +following guidelines. + +Imitate the existing code style. For concrete rules: + + - Use 4 spaces indentation, do not use tabulator characters; + + - Place braces alone on new lines, and do not place braces for single + line statement where it is not needed, i.e no: + + if(bla) { + x = 1; + } + + - Do not put a space after if, for, while or function call statements; + + - The preferred line length is 80 characters; + + - Use `/* */` for comments; + + - Use the API: there's a list of `a_*()` function you should use instead + of the standard libc ones. There is also common API for linked list, + tabulars, etc; + + - Be *clear* in what you do; + + - Prefix your function name with the module they are enhancing, + i.e. if you add a function to manipulate a tag prefix it with `tag_`. + + - Write documentation for any new functions, options, whatever. + +A vim modeline is set in each file to respect this. + +Patches +=== + +If you plan to submit patches, you should follow the following guidelines. + +Commits +--- + +- make commits of logical units; +- do not modify piece of code not related to your commit; +- do not try to fix style of code you are not writing, + it's just adding noise for no gain; +- check for unnecessary whitespace with `git diff --check` before commiting; +- do not check in commented out code or unneeded files; +- provide a meaningful commit message; +- the first line of the commit message should be a short; + description and should skip the full stop; +- if you want your work included, add a + `Signed-off-by: Your Name ` line to the + commit message (or just use the option `-s` when commiting); +- make sure that you have tests for the bug you are fixing. + +Patches +--- + +- use `git format-patch -M` to create the patch; +- do *not* PGP sign your patch; +- be *careful* doing cut & paste into your mailer, not to corrupt whitespaces; +- if you change, add or remove the user API, the associated documentation + should be updated as well; +- send the patch to the list (`awesome-devel@naquadah.org`) if (and only if) + the patch is ready for inclusion. If you use git-send-email(1), please + *test* it first by sending email to yourself. diff --git a/PATCHES b/PATCHES deleted file mode 100644 index 9116a0477..000000000 --- a/PATCHES +++ /dev/null @@ -1,29 +0,0 @@ -If you plan to submit patches, here's a checklist: - - Commits: - -- make commits of logical units; -- do not modify piece of code not related to your commit; -- do not try to fix style of code you are not writing, - it's just adding noise for no gain; -- check for unnecessary whitespace with "git diff --check" before commiting; -- do not check in commented out code or unneeded files; -- provide a meaningful commit message; -- the first line of the commit message should be a short; - description and should skip the full stop; -- if you want your work included, add a - "Signed-off-by: Your Name " line to the - commit message (or just use the option "-s" when commiting); -- make sure that you have tests for the bug you are fixing. -- if possible, add a unit test to the test suite under spec/. - - Patch: - -- use "git format-patch -M" to create the patch; -- do not PGP sign your patch; -- be careful doing cut & paste into your mailer, not to corrupt whitespaces; -- if you change, add or remove the user API, the associated documentation - should be updated as well; -- send the patch to the list (awesome-devel@naquadah.org) if (and only if) - the patch is ready for inclusion. If you use git-send-email(1), please - test it first by sending email to yourself. diff --git a/STYLE b/STYLE deleted file mode 100644 index dae80937a..000000000 --- a/STYLE +++ /dev/null @@ -1,31 +0,0 @@ -If you intend to patch and contribute to awesome, please respect the -following guidelines. - -Imitate the existing code style. For concrete rules: - - - Use 4 spaces indentation, do not use tabulator characters; - - - Place braces alone on new lines, and do not place braces for single - line statement where it is not needed, i.e no: - if(bla) { - x = 1; - } - - - Do not put a space after if, for, while or function call statements; - - - The preferred line length is 80 characters; - - - Use /* */ for comments; - - - Use the API: there's a list of a_*() function you should use instead - of the standard libc ones. There is also common API for linked list, - tabulars, etc; - - - Be clear in what you do; - - - Prefix your function name with the module they are enhancing, - i.e. if you add a function to manipulate a tag prefix it with tag_. - - - Write documentation for any new functions, options, whatever. - -A vim modeline is set in each file to respect this.