Add in some language about releasing forks. (ros#42810)

* Add in some language about releasing forks. Signed-off-by: Chris Lalancette <[email protected]> Co-authored-by: Steven! Ragnarök <[email protected]>
ahcorde · Sep 30, 2024 · b31b57a · b31b57a
1 parent b30c925
commit b31b57a
Showing 1 changed file with 1 addition and 0 deletions.
diff --git a/REVIEW_GUIDELINES.md b/REVIEW_GUIDELINES.md
@@ -43,6 +43,7 @@ There are a few different types of pull requests that are opened against this re
         * The license must be reflected in the package.xml file of all sub-packages in the repository.
         * The source repository must be publicly accessible.
         * The source repository should contain one or more ROS packages (meaning they have a `package.xml` in the source repository). Packages that are not ROS packages can be accepted, but they are rare and require special handling in the release repository.
+        * The source repository should generally *not* be a fork of an existing ROS package. If it is a fork, then the reviewer should inquire why the fork was made, and what efforts have been made to contact the upstream. The submitter should have at least opened an issue on the upstream asking for a release, then waited for a response. If there is no response after 4 weeks, then the reviewer can allow the fork. Note that these rules are general guidelines, rather than hard-and-fast rules; each of these situations is different and may require some different handling.
         * The name of the repository and the packages within it must comply with the guidelines in [REP-144](https://www.ros.org/reps/rep-0144.html).
     1. The best practices for Rolling releases is to use a release repository in the https://github.com/ros2-gbp organization. That way this package can be automatically released from Rolling into the next stable ROS distribution.  There are instructions in https://github.com/ros2-gbp/ros2-gbp-github-org/blob/latest/CONTRIBUTING.md describing how to create one.