From 6057203e5bc1dc22f95dfef513fdb23950db8326 Mon Sep 17 00:00:00 2001 From: Dylan Taylor Date: Sat, 15 May 2021 12:59:38 -0400 Subject: More formatting fixes --- CONTRIBUTING.md | 80 ++++++++++++++++++++++++++++++++++++--------------------- 1 file changed, 51 insertions(+), 29 deletions(-) (limited to 'CONTRIBUTING.md') diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index a72704bb..cc443fbd 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,57 +1,79 @@ # Contributing to archinstall -Any contributions through pull requests are welcome as this project aims to be a community based project to ease some Arch Linux installation steps. Bear in mind that in the future this repo might be transferred to the official [GitLab repo under Arch Linux](http://gitlab.archlinux.org/archlinux/) *(if GitLab becomes open to the general public)*. +Any contributions through pull requests are welcome as this project aims to be a community based project to ease some +Arch Linux installation steps. Bear in mind that in the future this repo might be transferred to the +official [GitLab repo under Arch Linux](http://gitlab.archlinux.org/archlinux/) *(if GitLab becomes open to the general +public)*. -Therefore guidelines and style changes to the code might come into affect as well as guidelines surrounding bug reporting and discussions. +Therefore guidelines and style changes to the code might come into affect as well as guidelines surrounding bug +reporting and discussions. ## Branches -`master` is currently the default branch, and that's where all future feature work is being done, this means that `master` is a living entity and will most likely never be in a fully stable state. For stable releases, please see the tagged commits. +`master` is currently the default branch, and that's where all future feature work is being done, this means +that `master` is a living entity and will most likely never be in a fully stable state. For stable releases, please see +the tagged commits. -Patch releases will be done against their own branches, branched from stable tagged releases and will be named according to the version it will become on release *(Patches to `v2.1.4` will be done on branch `v2.1.5` for instance)*. +Patch releases will be done against their own branches, branched from stable tagged releases and will be named according +to the version it will become on release *(Patches to `v2.1.4` will be done on branch `v2.1.5` for instance)*. ## Discussions -Currently, questions, bugs and suggestions should be reported through [GitHub issue tracker](https://github.com/archlinux/archinstall/issues).
+Currently, questions, bugs and suggestions should be reported +through [GitHub issue tracker](https://github.com/archlinux/archinstall/issues).
For less formal discussions there are also a [archinstall Discord server](https://discord.gg/cqXU88y). ## Coding convention -Archinstall's goal is to follow [PEP8](https://www.python.org/dev/peps/pep-0008/) as best as it can with some minor exceptions.
+Archinstall's goal is to follow [PEP8](https://www.python.org/dev/peps/pep-0008/) as best as it can with some minor +exceptions.
The exceptions to PEP8 are: - * Archinstall uses [tabs instead of spaces](https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces) simply to make it easier for non-IDE developers to navigate the code *(Tab display-width should be equal to 4 spaces)*. Exception to the rule are comments that need fine-tuned indentation for documentation purposes. - * [Line length](https://www.python.org/dev/peps/pep-0008/#maximum-line-length) should aim for no more than 100 characters, but not strictly enforced. - * [Line breaks before/after binary operator](https://www.python.org/dev/peps/pep-0008/#should-a-line-break-before-or-after-a-binary-operator) is not enforced, as long as the style of line breaks are consistent within the same code block. - * Archinstall should always be saved with **Unix-formatted line endings** and no other platform-specific formats. - * [Blank lines](https://www.python.org/dev/peps/pep-0008/#blank-lines) before/after imports and functions are not followed and discouraged. One space is commonly used in archinstall. - * Multiple [Imports](https://www.python.org/dev/peps/pep-0008/#imports) on the same line is allowed, but more than five imports should be avoided on any given line. This simply saves up some space at the top of the file *(for non-IDE developers)* and will not be enforced. - * [String quotes](https://www.python.org/dev/peps/pep-0008/#string-quotes) follow PEP8, the exception being when creating formatted strings, double-quoted strings are *preferred* but not required on the outer edges *(Example: `f"Welcome {name}"` rather than `f'Welcome {name}'`)*. +* Archinstall uses [tabs instead of spaces](https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces) simply to make it + easier for non-IDE developers to navigate the code *(Tab display-width should be equal to 4 spaces)*. Exception to the + rule are comments that need fine-tuned indentation for documentation purposes. +* [Line length](https://www.python.org/dev/peps/pep-0008/#maximum-line-length) should aim for no more than 100 + characters, but not strictly enforced. +* [Line breaks before/after binary operator](https://www.python.org/dev/peps/pep-0008/#should-a-line-break-before-or-after-a-binary-operator) + is not enforced, as long as the style of line breaks are consistent within the same code block. +* Archinstall should always be saved with **Unix-formatted line endings** and no other platform-specific formats. +* [Blank lines](https://www.python.org/dev/peps/pep-0008/#blank-lines) before/after imports and functions are not + followed and discouraged. One space is commonly used in archinstall. +* Multiple [Imports](https://www.python.org/dev/peps/pep-0008/#imports) on the same line is allowed, but more than five + imports should be avoided on any given line. This simply saves up some space at the top of the file *(for non-IDE + developers)* and will not be enforced. +* [String quotes](https://www.python.org/dev/peps/pep-0008/#string-quotes) follow PEP8, the exception being when + creating formatted strings, double-quoted strings are *preferred* but not required on the outer edges *( + Example: `f"Welcome {name}"` rather than `f'Welcome {name}'`)*. Most of these style guidelines have been put into place after the fact *(in an attempt to clean up the code)*.
There might therefore be older code which does not follow the coding convention and the code is subject to change. ## Submitting Changes -Archinstall uses Github's pull-request workflow and all contributions in terms of code should be done through pull requests.
+Archinstall uses Github's pull-request workflow and all contributions in terms of code should be done through pull +requests.
-Anyone interested in archinstall may review your code. One of the core developers will merge your pull request when they think it is ready. -For every pull request, we aim to promptly either merge it or say why it is not yet ready; if you go a few days without a reply, please feel free to ping the thread by adding a new comment. +Anyone interested in archinstall may review your code. One of the core developers will merge your pull request when they +think it is ready. For every pull request, we aim to promptly either merge it or say why it is not yet ready; if you go +a few days without a reply, please feel free to ping the thread by adding a new comment. -To get your pull request merged sooner, you should explain why you are making the change. For example, you can point to a code sample that is outdated in terms of Arch Linux command lines. -It is also helpful to add links to online documentation or to the implementation of the code you are changing. +To get your pull request merged sooner, you should explain why you are making the change. For example, you can point to +a code sample that is outdated in terms of Arch Linux command lines. It is also helpful to add links to online +documentation or to the implementation of the code you are changing. -Also, do not squash your commits after you have submitted a pull request, as this erases context during review. We will squash commits when the pull request is merged. +Also, do not squash your commits after you have submitted a pull request, as this erases context during review. We will +squash commits when the pull request is merged. At present the current contributors are (alphabetically): - * Anton Hvornum ([@Torxed](https://github.com/Torxed)) - * Borislav Kosharov ([@nikibobi](https://github.com/nikibobi)) - * demostanis ([@demostanis](https://github.com/demostanis)) - * Giancarlo Razzolini (@[grazzolini](https://github.com/grazzolini)) - * j-james ([@j-james](https://github.com/j-james)) - * Jerker Bengtsson ([@jaybent](https://github.com/jaybent)) - * Ninchester ([@ninchester](https://github.com/ninchester)) - * Philipp Schaffrath ([@phisch](https://github.com/phisch)) - * Varun Madiath ([@vamega](https://github.com/vamega)) - * nullrequest ([@advaithm](https://github.com/advaithm)) +* Anton Hvornum ([@Torxed](https://github.com/Torxed)) +* Borislav Kosharov ([@nikibobi](https://github.com/nikibobi)) +* demostanis ([@demostanis](https://github.com/demostanis)) +* Giancarlo Razzolini (@[grazzolini](https://github.com/grazzolini)) +* j-james ([@j-james](https://github.com/j-james)) +* Jerker Bengtsson ([@jaybent](https://github.com/jaybent)) +* Ninchester ([@ninchester](https://github.com/ninchester)) +* Philipp Schaffrath ([@phisch](https://github.com/phisch)) +* Varun Madiath ([@vamega](https://github.com/vamega)) +* nullrequest ([@advaithm](https://github.com/advaithm)) -- cgit v1.2.3-70-g09d2 From 254706d57d886b2ab8f5de15aa62c009fd8ab984 Mon Sep 17 00:00:00 2001 From: Dylan Taylor Date: Sat, 15 May 2021 13:01:17 -0400 Subject: Add my name to contributors (how was this not done already?) --- CONTRIBUTING.md | 1 + 1 file changed, 1 insertion(+) (limited to 'CONTRIBUTING.md') diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index cc443fbd..514035bc 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -70,6 +70,7 @@ At present the current contributors are (alphabetically): * Anton Hvornum ([@Torxed](https://github.com/Torxed)) * Borislav Kosharov ([@nikibobi](https://github.com/nikibobi)) * demostanis ([@demostanis](https://github.com/demostanis)) +* Dylan Taylor ([@dylanmtaylor](https://github.com/dylanmtaylor)) * Giancarlo Razzolini (@[grazzolini](https://github.com/grazzolini)) * j-james ([@j-james](https://github.com/j-james)) * Jerker Bengtsson ([@jaybent](https://github.com/jaybent)) -- cgit v1.2.3-70-g09d2 From 340048db672b4d1a7fb4bec89ce26825a614ebee Mon Sep 17 00:00:00 2001 From: Dylan Taylor Date: Sat, 15 May 2021 13:06:12 -0400 Subject: Update CONTRIBUTING.md to remove deviations we no longer have. --- CONTRIBUTING.md | 5 ----- 1 file changed, 5 deletions(-) (limited to 'CONTRIBUTING.md') diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 514035bc..1d490a44 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -37,11 +37,6 @@ The exceptions to PEP8 are: * [Line breaks before/after binary operator](https://www.python.org/dev/peps/pep-0008/#should-a-line-break-before-or-after-a-binary-operator) is not enforced, as long as the style of line breaks are consistent within the same code block. * Archinstall should always be saved with **Unix-formatted line endings** and no other platform-specific formats. -* [Blank lines](https://www.python.org/dev/peps/pep-0008/#blank-lines) before/after imports and functions are not - followed and discouraged. One space is commonly used in archinstall. -* Multiple [Imports](https://www.python.org/dev/peps/pep-0008/#imports) on the same line is allowed, but more than five - imports should be avoided on any given line. This simply saves up some space at the top of the file *(for non-IDE - developers)* and will not be enforced. * [String quotes](https://www.python.org/dev/peps/pep-0008/#string-quotes) follow PEP8, the exception being when creating formatted strings, double-quoted strings are *preferred* but not required on the outer edges *( Example: `f"Welcome {name}"` rather than `f'Welcome {name}'`)*. -- cgit v1.2.3-70-g09d2 From 55931a98fbd98f77addff7ebf9476a2e0c459ea5 Mon Sep 17 00:00:00 2001 From: Dylan Taylor Date: Sat, 15 May 2021 13:09:30 -0400 Subject: Replace
in markdown with new line --- CONTRIBUTING.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) (limited to 'CONTRIBUTING.md') diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 1d490a44..953ac2cb 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -20,13 +20,15 @@ to the version it will become on release *(Patches to `v2.1.4` will be done on b ## Discussions Currently, questions, bugs and suggestions should be reported -through [GitHub issue tracker](https://github.com/archlinux/archinstall/issues).
+through [GitHub issue tracker](https://github.com/archlinux/archinstall/issues). + For less formal discussions there are also a [archinstall Discord server](https://discord.gg/cqXU88y). ## Coding convention Archinstall's goal is to follow [PEP8](https://www.python.org/dev/peps/pep-0008/) as best as it can with some minor -exceptions.
+exceptions. + The exceptions to PEP8 are: * Archinstall uses [tabs instead of spaces](https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces) simply to make it @@ -41,13 +43,15 @@ The exceptions to PEP8 are: creating formatted strings, double-quoted strings are *preferred* but not required on the outer edges *( Example: `f"Welcome {name}"` rather than `f'Welcome {name}'`)*. -Most of these style guidelines have been put into place after the fact *(in an attempt to clean up the code)*.
+Most of these style guidelines have been put into place after the fact *(in an attempt to clean up the code)*. + There might therefore be older code which does not follow the coding convention and the code is subject to change. ## Submitting Changes Archinstall uses Github's pull-request workflow and all contributions in terms of code should be done through pull -requests.
+requests. + Anyone interested in archinstall may review your code. One of the core developers will merge your pull request when they think it is ready. For every pull request, we aim to promptly either merge it or say why it is not yet ready; if you go -- cgit v1.2.3-70-g09d2 From dd340b9cbae197ca4f4c41c3006c4ec2858727fa Mon Sep 17 00:00:00 2001 From: Dylan Taylor Date: Sat, 15 May 2021 13:09:30 -0400 Subject: Revert "Replace
in markdown with new line" This reverts commit 55931a98fbd98f77addff7ebf9476a2e0c459ea5. --- CONTRIBUTING.md | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) (limited to 'CONTRIBUTING.md') diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 953ac2cb..1d490a44 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -20,15 +20,13 @@ to the version it will become on release *(Patches to `v2.1.4` will be done on b ## Discussions Currently, questions, bugs and suggestions should be reported -through [GitHub issue tracker](https://github.com/archlinux/archinstall/issues). - +through [GitHub issue tracker](https://github.com/archlinux/archinstall/issues).
For less formal discussions there are also a [archinstall Discord server](https://discord.gg/cqXU88y). ## Coding convention Archinstall's goal is to follow [PEP8](https://www.python.org/dev/peps/pep-0008/) as best as it can with some minor -exceptions. - +exceptions.
The exceptions to PEP8 are: * Archinstall uses [tabs instead of spaces](https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces) simply to make it @@ -43,15 +41,13 @@ The exceptions to PEP8 are: creating formatted strings, double-quoted strings are *preferred* but not required on the outer edges *( Example: `f"Welcome {name}"` rather than `f'Welcome {name}'`)*. -Most of these style guidelines have been put into place after the fact *(in an attempt to clean up the code)*. - +Most of these style guidelines have been put into place after the fact *(in an attempt to clean up the code)*.
There might therefore be older code which does not follow the coding convention and the code is subject to change. ## Submitting Changes Archinstall uses Github's pull-request workflow and all contributions in terms of code should be done through pull -requests. - +requests.
Anyone interested in archinstall may review your code. One of the core developers will merge your pull request when they think it is ready. For every pull request, we aim to promptly either merge it or say why it is not yet ready; if you go -- cgit v1.2.3-70-g09d2