|Title:||Scope of REP Process, REP Stacks|
This REP defines the scope of the REP process defined in . It provides a list of REP Stacks that are considered to be within the scope of the REP process. It also defines the process of including or removing stacks from this list.
At the time of this writing, there are over 1000 ROS packages contributed by over 30 institutions. It would be onerous, encumbering and unenforceable to apply the REP process to all existing ROS-based software. Conversely, if we limit the scope of the REP process to ROS itself, i.e. the packaging, build, and communication libraries, we miss the opportunity to engage the community in designing robot-specific capabilities.
In order to seek a balance between these two, we designate a list of ROS stacks that are open to the REP process, and we provide a lightweight mechanism by which new stacks can easily be added to this list.
We enumerate here the list of stacks considered to be within the scope of the REP process.
Many ROS stacks include externally developed, or third-party, code. Enhancements to third-party code are out of the scope of a REP and should be requested directly to the third-party developers. REPs can propose changes to the way that third-party code is integrated (e.g., updating the version of a third-party library that is pulled in).
Stacks may be added to or removed from the list above by sending an email to email@example.com with "REP 2" in the Subject line. If the voting process  shows clear favor the list can be quickly updated. Otherwise, acceptance follows a similar process to those for accepting PEPs . The Stack Maintainer has final veto power over inclusion on this list.
The REP Stacks generally match those installed in the "base" variant of the ROS turtle distributions (e.g. boxturtle-base, cturtle-base). We do not use the name "base" here because we do not wish to conflate the distribution of a stack with the process by which a stack is reviewed.
We define this process at the stack level as that is the unit of distribution for ROS software. Although a package-specific approach would provide more fine-grained control over this process, ROS users generally only interact with packages as a stack unit and thus experience these libraries collectively.
We do not define the process for stacks not included on this list. Institutions and individuals are free to follow their own development practices for the design and development of new capabilities.
There are many reasons why the REP process may not be appropriate for a library. For example, we encourage the release of code to accompany research papers, and we do not wish to discourage this by placing research code within the scope of the REP process.
Similarly, many of the current ROS libraries have gone through multiple stages of prototyping and use to improve their design. Often, the best way of understanding the design flaws of software is through experimention and use, rather than e-mail dicussions.
As an example alternate process for REPs, Willow Garage follows an internal review process that allows for multiple iterations of "API review" followed by a "Documentation review". These reviews are announced on the ros-review mailing list and are open to participants, but they are not required to circulate REPs.
|||(1, 2) REP 1, REP Purpose and Guidelines (http://ros.org/reps/rep-0001.html)|
|||REP 10, Voting Guidelines (http://ros.org/reps/rep-0010.html)|
This document has been placed in the public domain.