diff --git a/doc/developer/bgpd.rst b/doc/developer/bgpd.rst index a35fa614f459..f5263ff31daf 100644 --- a/doc/developer/bgpd.rst +++ b/doc/developer/bgpd.rst @@ -9,3 +9,4 @@ BGPD next-hop-tracking bgp-typecodes + bmp diff --git a/doc/developer/mgmtd-dev.rst b/doc/developer/mgmtd-dev.rst index b979af06fa0d..4c56cadb2869 100644 --- a/doc/developer/mgmtd-dev.rst +++ b/doc/developer/mgmtd-dev.rst @@ -147,7 +147,7 @@ Front-End Interface: - change route_map_init() to route_map_init_new(false) and remove from VTYSH_ROUTE_MAP_CONFIG (leave in VTYSH_ROUTE_MAP_SHOW). - remove vrf_cmd_init(NULL) => remove from VTYSH_INTERFACE_SUBSET - ... + Back-End Interface: diff --git a/doc/developer/northbound/yang-tools.rst b/doc/developer/northbound/yang-tools.rst index fb5a2872457b..91a767dce77d 100644 --- a/doc/developer/northbound/yang-tools.rst +++ b/doc/developer/northbound/yang-tools.rst @@ -87,7 +87,7 @@ Generate skeleton instance data: * XML: - .. code:: sh +.. code:: sh $ pyang -p \ -f sample-xml-skeleton --sample-xml-skeleton-defaults \ @@ -95,7 +95,7 @@ Generate skeleton instance data: * JSON: - .. code:: sh +.. code:: sh $ pyang -p \ -f jsonxsl module.yang -o module.xsl diff --git a/doc/developer/topotests.rst b/doc/developer/topotests.rst index 4f9c94ca03ce..620974963687 100644 --- a/doc/developer/topotests.rst +++ b/doc/developer/topotests.rst @@ -731,8 +731,8 @@ packages. Code coverage can automatically be gathered for any topotest run. To support this FRR must first be compiled with the ``--enable-gcov`` configure option. -This will cause *.gnco files to be created during the build. When topotests are -run the statistics are generated and stored in *.gcda files. Topotest +This will cause \*.gnco files to be created during the build. When topotests are +run the statistics are generated and stored in \*.gcda files. Topotest infrastructure will gather these files, capture the information into a ``coverage.info`` ``lcov`` file and also report the coverage summary. @@ -741,7 +741,7 @@ If you build your FRR in a directory outside of the FRR source directory you will also need to pass the ``--cov-frr-build-dir`` argument specifying the build directory location. -During the topotest run the *.gcda files are generated into a ``gcda`` +During the topotest run the \*.gcda files are generated into a ``gcda`` sub-directory of the top-level run directory (i.e., normally ``/tmp/topotests/gcda``). These files will then be copied at the end of the topotest run into the FRR build directory where the ``gcov`` and ``lcov`` @@ -756,7 +756,7 @@ The ``coverage.info`` file can then be used to generate coverage reports or file markup (e.g., using the ``genhtml`` utility) or enable markup within your IDE/editor if supported (e.g., the emacs ``cov-mode`` package) -NOTE: the *.gcda files in ``/tmp/topotests/gcda`` are cumulative so if you do +NOTE: the \*.gcda files in ``/tmp/topotests/gcda`` are cumulative so if you do not remove them they will aggregate data across multiple topotest runs. How to reproduce failed Tests diff --git a/doc/developer/workflow.rst b/doc/developer/workflow.rst index 50bcb2976e16..5e22c4cb72b5 100644 --- a/doc/developer/workflow.rst +++ b/doc/developer/workflow.rst @@ -6,9 +6,10 @@ Process & Workflow .. highlight:: none -FRR is a large project developed by many different groups. This section -documents standards for code style & quality, commit messages, pull requests -and best practices that all contributors are asked to follow. +FRR is a large project developed by many different groups. This +section documents standards for code style & quality, commit messages, +pull requests (PRs) and best practices that all contributors are asked +to follow. This chapter is "descriptive/post-factual" in that it documents pratices that are in use; it is not "definitive/pre-factual" in prescribing practices. This @@ -241,7 +242,7 @@ discontinued. The LTS branch duties are the following ones: - organise meetings on a (bi-)weekly or monthly basis, the handling of issues - and pull requested relative to that branch. When time permits, this may be done + and pull requests relative to that branch. When time permits, this may be done during the regularly scheduled FRR meeting. - ensure the stability of the branch, by using and eventually adapting the @@ -324,11 +325,17 @@ relevant to your work. Submitting Patches and Enhancements =================================== -FRR accepts patches using GitHub pull requests. - -The base branch for new contributions and non-critical bug fixes should be -``master``. Please ensure your pull request is based on this branch when you -submit it. +FRR accepts patches using GitHub pull requests (PRs). The typical FRR +developer will maintain a fork of the FRR project in GitHub; see the +GitHub documentation for help setting up an account and creating a +fork repository. Keep the ``master`` branch of your fork up-to-date +with the FRR version. Create a dev branch in your fork and commit your +work there. When ready, create a pull-request between your dev branch +in your fork and the main FRR repository in GitHub. + +The base branch for new contributions and non-critical bug fixes +should be ``master``. Please ensure your pull request targets this +branch when you submit it. Code submitted by pull request will be automatically tested by one or more CI systems. Once the automated tests succeed, other developers will review your