From c7aece61ac6c9dd57f7c0b38fdc4f39cffe8f151 Mon Sep 17 00:00:00 2001 From: Chris Lalancette Date: Mon, 6 Feb 2023 12:45:08 -0500 Subject: [PATCH] Updates to the review guidelines. (#36034) 1. Remove the section about changing maintainers. That actually doesn't happen in this repository, but instead happens over at https://github.com/ros2-gbp/ros2-gbp-github-org/ . 2. Add a note about package names having to conform to REP-144. 3. Add a note about rosdep keys preferring to use native packages, and preferring to use the Ubuntu package name as the key name. Signed-off-by: Chris Lalancette --- REVIEW_GUIDELINES.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/REVIEW_GUIDELINES.md b/REVIEW_GUIDELINES.md index 42b10fb77a301..5033cc02dfbce 100644 --- 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 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. Once the above criteria are satisfied, and the ROS distribution isn't in a "sync freeze", then the PR will be merged. @@ -50,6 +51,8 @@ There are a few different types of pull requests that are opened against this re 1. A new rosdep key. An example of this kind of PR is [25995](https://github.com/ros/rosdistro/pull/25995). These pull requests should conform to the standards documented at [CONTRIBUTING.md#rosdep-rules-contributions](CONTRIBUTING.md#rosdep-rules-contributions). Some rules in addition to contributing guidelines: * A pull request to update rosdep should never change the name of existing keys. * When adding a new key, Ubuntu and Debian are required, Fedora, Gentoo, and openSUSE are encouraged if the package also exists on those Linux distributions. + * Native packages are strongly preferred. If a native package exists for the key in question, then that should always be used over e.g. a pip key. + * If a native package is available, the key name should match the name of the package in Ubuntu. * If a package was added to e.g. Ubuntu Focal but isn’t available in Bionic or Xenial, the key should look like: ``` mykey: @@ -66,6 +69,4 @@ There are a few different types of pull requests that are opened against this re 1. Changes to the rosdistro code. These pull requests change any of the scripts or tests that are housed in the rosdistro repositories. They will be reviewed as any other code change in the ROS ecosystem. -1. Maintainership changes. In an open source ecosystem it is necessary to change maintainership of packages from time to time. In optimal situations the current maintainer can designate their successor and officially hand off maintainership. If the maintainer is no longer able to do the necessary work a request can be made of the rosdistro release manager to take over maintenance. The manager will review each request on a case by case basis. If you see a change of maintainership please hold it for review by the release manager. - 1. Miscellaneous. Any other pull requests adding or modifying documentation, or anything else will be reviewed as any other code change in the ROS ecosystem.