(#14491) Docs: split up reviewing into new file sections

* cleanup patches from #14377

* subfolder dont exist with new generators

* styling is not enforced

* move attribute to new home + fix FAQ spelling

* delete out date CMake docs from older generators

* move test package docs

* delete empty file :)

* fix links

* wording + remove duplicated sections

* improve mention of future work

* [docs] Regenerate tables of contents

Co-authored-by: prince-chrismc <prince-chrismc@users.noreply.github.com>

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: prince-chrismc <prince-chrismc@users.noreply.github.com>

docs/adding_packages/README.md

@@ -18,7 +18,7 @@ You can follow the three steps (:one: :two: :three:) described below! :tada:
     * [`config.yml`](#configyml)
     * [`conandata.yml`](#conandatayml)
     * [The _recipe folder_: `conanfile.py`](#the-_recipe-folder_-conanfilepy)
-    * [The test package folders: `test_package` and `test_<something>`](#the-test-package-folders-test_package-and-test_something)
+    * [Test Folders](#test-folders)
   * [How to provide a good recipe](#how-to-provide-a-good-recipe)
     * [Header Only](#header-only)
     * [CMake](#cmake)
@@ -48,7 +48,6 @@ on a weekly basis.
 
 When submitting a pull request for the first time, you will be prompted to sign the [CLA](../CONTRIBUTOR_LICENSE_AGREEMENT.md) for your code contributions. You can view your signed CLA's by going to <https://cla-assistant.io/> and signing in.
 
-
 ## Inactivity and user removal
 
 For security reasons related to the CI, when a user no longer contributes for a long period, it will be considered inactive and removed from the authorized user's list.
@@ -99,6 +98,8 @@ This is the canonical structure of one of these folders, where the same `conanfi
 |       +-- all/
 |           +-- conanfile.py
 |           +-- conandata.yml
+|           +-- patches/
+|               +-- add-missing-string-header-2.0.0.patch
 |           +-- test_package/
 |               +-- conanfile.py
 |               +-- CMakeLists.txt
@@ -152,8 +153,6 @@ def build(self):
     [...]
 ```
 
-More details can be found in the [reviewing preference](reviewing.md) documentation
-
 ### The _recipe folder_: `conanfile.py`
 
 The main files in this repository are the `conanfile.py` ones that contain the logic to build the libraries from sources for all the configurations,
@@ -166,50 +165,13 @@ Together with the recipe, there can be other files that are needed to build the
 
 Also, **every `conanfile.py` should be accompanied by one or several folder to test the generated packages** as we will see below.
 
-### The test package folders: `test_package` and `test_<something>`
+### Test Folders
 
-All the packages in this repository need to be tested before they join ConanCenter. A `test_package` folder with its corresponding `conanfile.py` and
+All the packages in this repository need to be tested before they join ConanCenter. A `test_package/` folder with its corresponding `conanfile.py` and
 a minimal project to test the package is strictly required. You can read about it in the
 [Conan documentation](https://docs.conan.io/en/latest/creating_packages/getting_started.html).
 
-
-Sometimes it is useful to test the package using different build systems (CMake, Autotools,...). Instead of adding complex logic to one
-`test_package/conanfile.py` file, it is better to add another `test_<something>/conanfile.py` file with a minimal example for that build system. That
-way the examples will be short and easy to understand and maintain. In some other situations it could be useful to test different Conan generators
-(`cmake_find_package`, `CMakeDeps`,...) using different folders and `conanfile.py` files
-([see example](https://github.com/conan-io/conan-center-index/tree/master/recipes/fmt/all)).
-
-When using more than one `test_<something>` folder, create a different project for each of them to keep the content of the `conanfile.py` and the
-project files as simple as possible, without the need of extra logic to handle different scenarios.
-
-```
-.
-+-- recipes
-|   +-- library_name/
-|       +-- config.yml
-|       +-- all/
-|           +-- conanfile.py
-|           +-- conandata.yml
-|           +-- test_package/
-|               +-- conanfile.py
-|               +-- CMakeLists.txt
-|               +-- main.cpp
-|           +-- test_cmakedeps/
-|               +-- conanfile.py
-|               +-- CMakeLists.txt
-|               +-- conanfile.py
-```
-
-The CI will explore all the folders and run the tests for the ones matching `test_*/conanfile.py` pattern. You can find the output of all
-of them together in the testing logs.
-
-> **Note**: If, for any reason, it is useful to write a test that should only be checked using Conan v1, you can do so by using the pattern
-> `test_v1_*/conanfile.py` for the folder. Please, have a look to [linter notes](../v2_linter.md) to know how to prevent the linter from
-> checking these files.
-
-> Remember that the `test_<package>` recipes should **test the package configuration that has just been generated** for the _host_ context, otherwise
-> it will fail in cross-building scenarios.
-
+Learn more about the ConanCenterIndex requirements in the [test packages](test_packages.md) document.
 
 ## How to provide a good recipe
 

docs/adding_packages/conanfile_attributes.md

@@ -6,12 +6,37 @@ or are known by ConanCenter's build service and have special meaning.
 <!-- toc -->
 ## Contents
 
+  * [Order of methods and attributes](#order-of-methods-and-attributes)
+  * [License Attribute](#license-attribute)
   * [Settings](#settings)
   * [Options](#options)
     * [Recommended Names](#recommended-names)
     * [Predefined Options and Known Defaults](#predefined-options-and-known-defaults)
     * [Options to Avoid](#options-to-avoid)<!-- endToc -->
 
+## Order of methods and attributes
+
+Prefer the following order of documented methods in python code (`conanfile.py`, `test_package/conanfile.py`):
+
+For `conan create` the order is listed [here](https://docs.conan.io/en/latest/reference/commands/creator/create.html#methods-execution-order)
+test packages recipes should append the following methods:
+
+- deploy
+- test
+
+the order above resembles the execution order of methods on CI. therefore, for instance, `build` is always executed before `package` method, so `build` should appear before the
+`package` in `conanfile.py`.
+
+## License Attribute
+
+The mandatory license attribute of each recipe **should** be a [SPDX license](https://spdx.org/licenses/) [short Identifiers](https://spdx.dev/ids/) when applicable.
+
+Where the SPDX guidelines do not apply, packages should do the following:
+
+- When no license is provided or it's under the ["public domain"](https://fairuse.stanford.edu/overview/public-domain/welcome/) - these are not a license by itself. Thus, we have [equivalent licenses](https://en.wikipedia.org/wiki/Public-domain-equivalent_license) that should be used instead. If a project fall under these criteria it should be identified as the [Unlicense](https://spdx.org/licenses/Unlicense) license.
+- When a custom (e.g. project specific) license is given, the value should be set to `LicenseRef-` as a prefix, followed by the name of the file which contains the custom license. See [this example](https://github.com/conan-io/conan-center-index/blob/e604534bbe0ef56bdb1f8513b83404eff02aebc8/recipes/fft/all/conanfile.py#L8). For more details, [read this conversation](https://github.com/conan-io/conan-center-index/pull/4928/files#r596216206).
+
+
 ## Settings
 
 All recipes should list the four settings `os`, `arch`, `compiler` and `build_type` so Conan will compute a different package ID

docs/adding_packages/sources_and_patches.md

@@ -73,10 +73,9 @@ associated to the recipe revision used to build them.
 ### Adding old versions
 
 We love to hear why in the opening description of the pull requests you need this exact version.
-We usually don't add old versions unless there is a specific request for it.
+We usually don't add old versions unless there is a specific request for it. Adding versions that are not used by author of the pull request reduces overall resources and time from [the build services](README.md#the-build-service).
 
-Take into account that the version might be removed in future pull requests according to the guidelines above.
-Adding versions that are not used by author of the pull request reduces overall resources and time from [the build services](README.md#the-build-service).
+Take into account that the version might be removed in future pull requests according to the [guidelines above](#removing-old-versions).
 
 ## Policy about patching