proxmox-mirrors/mirror_frr
1
0
Fork 0
mirror of https://git.proxmox.com/git/mirror_frr synced 2025-08-05 01:11:42 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge pull request #16789 from mjstapp/doc_dev_update

Browse Source 
doc: add some text about using git forks
This commit is contained in:
Jafar Al-Gharaibeh 2024-09-11 12:52:50 -04:00 committed by GitHub
commit a76a7d1b12
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
5 changed files with 23 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
doc/developer/bgpd.rst
View File

@ -9,3 +9,4 @@ BGPD
next-hop-tracking
bgp-typecodes
bmp

2
doc/developer/mgmtd-dev.rst
View File

@ -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:

4
doc/developer/northbound/yang-tools.rst
View File

@ -87,7 +87,7 @@ Generate skeleton instance data:
* XML:
.. code:: sh
.. code:: sh
$ pyang -p <yang-search-path> \
-f sample-xml-skeleton --sample-xml-skeleton-defaults \
@ -95,7 +95,7 @@ Generate skeleton instance data:
* JSON:
.. code:: sh
.. code:: sh
$ pyang -p <yang-search-path> \
-f jsonxsl module.yang -o module.xsl

8
doc/developer/topotests.rst
View File

@ -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

23
doc/developer/workflow.rst
View File

@ -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.
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 is based on this branch when you
submit it.
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