proxmox-mirrors/mirror_frr
1
0
Fork 0
mirror of https://git.proxmox.com/git/mirror_frr synced 2025-08-16 02:30:52 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

COMMUNITY.md: s/PROJECT/FRRouting

Browse Source 
Also:
* Make headers consistently capitalized
* Some extra backticks where needed

Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
This commit is contained in:
Quentin Young 2017-07-21 12:12:52 -04:00
parent 6058ea8cb1
commit c545559d4a
1 changed files with 53 additions and 52 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

105
COMMUNITY.md
View File

@ -1,4 +1,4 @@
# Developing for PROJECT (DRAFT) # Developing for FRRouting
[TOC] [TOC]
@ -14,8 +14,8 @@ it's the document that needs to be updated, not reality.
## Git Structure ## Git Structure
The master Git for PROJECT resides on Github at The master Git for FRRouting resides on Github at
[https://github.com/PROJECT/XXX](https://github.com/PROJECT/XXX) [https://github.com/frrouting/frr](https://github.com/FRRouting/XXX)
![git branches continually merging to the left from 3 lanes; float-right](doc/git_branches.svg ![git branches continually merging to the left from 3 lanes; float-right](doc/git_branches.svg
"git branch mechanics") "git branch mechanics")
@ -38,23 +38,24 @@ is still here, this document obviously wasn't updated.
## Programming language, Tools and Libraries ## Programming language, Tools and Libraries
The core of PROJECT is written in C (gcc or clang supported). A few The core of FRRouting is written in C (gcc or clang supported) and makes use of
non-essential scripts are implemented in Perl and Python. PROJECT requires GNU compiler extensions. A few non-essential scripts are implemented in Perl
the following tools to build distribution packages: automake, autoconf, and Python. FRRouting requires the following tools to build distribution
texinfo, libtool and gawk and various libraries (i.e. libpam and libjson-c). packages: automake, autoconf, texinfo, libtool and gawk and various libraries
(i.e. libpam and libjson-c).
If your contribution requires a new library or other tool, then please If your contribution requires a new library or other tool, then please
highlight this in your description of the change. Also make sure it’s highlight this in your description of the change. Also make sure it’s supported
supported by all PROJECT platform OSes or provide a way to build without the by all FRRouting platform OSes or provide a way to build without the library
library (potentially without the new feature) on the other platforms. (potentially without the new feature) on the other platforms.
Documentation should be written in Tex (.texi) or Markdown (.md) format with Documentation should be written in Tex (.texi) or Markdown (.md) format with
preference on Markdown. a preference for Markdown.
## Before Submitting your changes ## Before Submitting your changes
* Format code (see [Code Styling requirements](#code-styling-requirements)) * Format code (see [Code style requirements](#code-styling-requirements))
* Verify and acknowledge license (see [License for contributions](#license-for-contributions)) * Verify and acknowledge license (see [License for contributions](#license-for-contributions))
* Test building with various configurations: * Test building with various configurations:
* `buildtest.sh` * `buildtest.sh`
@ -77,13 +78,13 @@ for the release notes.
### License for contributions ### License for contributions
PROJECT is under a “GPLv2 or later” license. Any code submitted must be FRRouting is under a “GPLv2 or later” license. Any code submitted must be
released under the same license (preferred) or any license which allows released under the same license (preferred) or any license which allows
redistribution under this GPLv2 license (eg MIT License). redistribution under this GPLv2 license (eg MIT License).
### Signed-off required ### Signed-off required
Submissions to PROJECT require a “Signed-off” in the patch or git commit. Submissions to FRRouting require a “Signed-off” in the patch or git commit.
We follow the same standard as the Linux Kernel Development. We follow the same standard as the Linux Kernel Development.
> Developer's Certificate of Origin 1.1 > Developer's Certificate of Origin 1.1
@ -143,7 +144,7 @@ the question of a maintainer.
Preferred submission of code is by using a Github Pull Request against the Preferred submission of code is by using a Github Pull Request against the
Develop branch. Code submitted by Pull Request will have an email generated to Develop branch. Code submitted by Pull Request will have an email generated to
the PROJECT-devel mailing list for review and the submission will be the FRRouting-devel mailing list for review and the submission will be
automatically tested by one or more CI systems. Only after this test succeeds automatically tested by one or more CI systems. Only after this test succeeds
(and the submission is based on the head of the develop branch), then it will (and the submission is based on the head of the develop branch), then it will
be automatically merged into the develop branch. In case of failed tests, it is be automatically merged into the develop branch. In case of failed tests, it is
@ -154,9 +155,9 @@ Further (manual) code review and discussion happens after the merge into the
develop branch. develop branch.
### Code submission - Mailing Patch to PROJECT-Devel list ### Code submission - Mailing Patch to FRRouting-Devel list
As an alternative submission, a patch can be mailed to the PROJECT-Devel As an alternative submission, a patch can be mailed to the FRRouting-Devel
mailing list. Preferred way to send the patch is using git send-mail. Patches mailing list. Preferred way to send the patch is using git send-mail. Patches
received on the mailing list will be picked up by Patchwork and tested against received on the mailing list will be picked up by Patchwork and tested against
the latest develop branch. After a further ACK by someone on the mailing list, the latest develop branch. After a further ACK by someone on the mailing list,
@ -194,9 +195,9 @@ and will allow your changes to merge faster
less than 2 hrs of the submission. If you don’t get the email, then check less than 2 hrs of the submission. If you don’t get the email, then check
status on the github pull request (if submitted by pull request) or on status on the github pull request (if submitted by pull request) or on
Patchwork at Patchwork at
[https://patchwork.PROJECT.org](https://patchwork.PROJECT.org) (if [https://patchwork.FRRouting.org](https://patchwork.PROJECT.org) (if
submitted as patch to mailing list). submitted as patch to mailing list).
* Please notify PROJECT-Devel mailing list if you think something doesn’t * Please notify FRRouting-Devel mailing list if you think something doesn’t
work work
* If the tests failed: * If the tests failed:
* In general, expect the community to ignore the submission until the tests * In general, expect the community to ignore the submission until the tests
@ -206,23 +207,23 @@ and will allow your changes to merge faster
changes broke or changed them. changes broke or changed them.
* It also includes fixing distribution packages for the failing * It also includes fixing distribution packages for the failing
platforms (ie if new libraries are required) platforms (ie if new libraries are required)
* Feel free to ask for help on PROJECT-Devel list * Feel free to ask for help on FRRouting-Devel list
* Go back to the submission process and repeat until the tests pass. * Go back to the submission process and repeat until the tests pass.
* If the tests pass: * If the tests pass:
* If the changes are done as a pull request, then they should be * If the changes are done as a pull request, then they should be
automatically merged to the develop branch. automatically merged to the develop branch.
* Changes sent to mailing list require a manual ACK to be merged and should * Changes sent to mailing list require a manual ACK to be merged and should
be merged within 2 weeks. If you don’t see the merge or any be merged within 2 weeks. If you don’t see the merge or any
reason/discussion on PROJECT-Devel, then please ask. reason/discussion on FRRouting-Devel, then please ask.
* Watch out for questions on the mailing list. At this time there will be a * Watch out for questions on the mailing list. At this time there will be a
manual code review and further (longer) tests by various community members. manual code review and further (longer) tests by various community members.
* Your submission is done once it is merged to the master branch. (which should * Your submission is done once it is merged to the master branch. (which should
happen every few weeks from the develop branch) happen every few weeks from the develop branch)
## Code Styling requirements ## Code style requirements
### File header required for new files added ### Source file header
New files need to have a Copyright header (see [License for New files need to have a Copyright header (see [License for
contributions](#license-for-contributions) above) added to the file. Preferred contributions](#license-for-contributions) above) added to the file. Preferred
@ -251,7 +252,7 @@ form of the header is as follows:
#include <zebra.h> #include <zebra.h>
``` ```
### Adding Copyright claims to already existing file ### Adding copyright claims to existing files
When adding copyright claims for modifications to an existing file, please When adding copyright claims for modifications to an existing file, please
preface the claim with "Portions: " on a line before it and indent the preface the claim with "Portions: " on a line before it and indent the
@ -264,7 +265,7 @@ Portions:
Copyright (C) 2016 Your name [optional brief change description] Copyright (C) 2016 Your name [optional brief change description]
``` ```
### Code style / format ### Code formatting
FRR uses Linux kernel style except where noted below. FRR uses Linux kernel style except where noted below.
@ -294,13 +295,13 @@ indent -nut -nfc1 file_for_submission.c
#### Exceptions #### Exceptions
FRR project code comes from a variety of sources, so there are some stylistic FRR project code comes from a variety of sources, so there are some stylistic
exceptions in place. Here they are, by branch. exceptions in place. They are organized here by branch.
**For `master`:** **For `master`:**
BSD coding style applies to: BSD coding style applies to:
* ldpd/ * `ldpd/`
`babeld` uses, approximately, the following style: `babeld` uses, approximately, the following style:
@ -313,46 +314,46 @@ BSD coding style applies to:
GNU coding style apply to the following parts: GNU coding style apply to the following parts:
* lib/ * `lib/`
* zebra/ * `zebra/`
* bgpd/ * `bgpd/`
* ospfd/ * `ospfd/`
* ospf6d/ * `ospf6d/`
* isisd/ * `isisd/`
* ripd/ * `ripd/`
* ripngd/ * `ripngd/`
* vtysh/ * `vtysh/`
BSD coding style applies to: BSD coding style applies to:
* ldpd/ * `ldpd/`
#### Policy #### Policy
The above standards relate to code formatting. For other stylistic choices e.g. The above standards relate to code formatting. For other stylistic choices,
use of `typedef`, variable naming, etc. refer to the Linux kernel style such as use of `typedef`, variable naming, etc. refer to the Linux kernel style
documentation. documentation.
### Compile-Time conditional code ### Compile-time conditional code
Many users access PROJECT via binary packages from 3rd party sources; Many users access FRR via binary packages from 3rd party sources;
compile-time code puts inclusion/exclusion in the hands of the package compile-time code puts inclusion/exclusion in the hands of the package
maintainer. Please think very carefully before making code conditional at maintainer. Please think very carefully before making code conditional at
compile time, as it increases regression testing, maintenance burdens, and user compile time, as it increases regression testing, maintenance burdens, and user
confusion. In particular, please avoid gratuitous --enable-… switches to the confusion. In particular, please avoid gratuitous `--enable-…` switches to the
configure script - typically code should be good enough to be in PROJECT, or it configure script - in general, code should be of high quality and in working
shouldn’t be there at all. condition, or it shouldn’t be in FRR at all.
When code must be compile-time conditional, try have the compiler make it When code must be compile-time conditional, try have the compiler make it
conditional rather than the C pre-processor - so that it will still be checked conditional rather than the C pre-processor so that it will still be checked by
by the compiler, even if disabled. I.e. this: the compiler, even if disabled. For example,
``` ```
if (SOME_SYMBOL) if (SOME_SYMBOL)
frobnicate(); frobnicate();
``` ```
rather than is preferred to
``` ```
#ifdef SOME_SYMBOL #ifdef SOME_SYMBOL
@ -363,18 +364,18 @@ frobnicate ();
Note that the former approach requires ensuring that `SOME_SYMBOL` will be Note that the former approach requires ensuring that `SOME_SYMBOL` will be
defined (watch your `AC_DEFINE`s). defined (watch your `AC_DEFINE`s).
### Debug-Guards in code ### Debug-guards in code
Debugs are an important methodology to allow developers to fix issues Debugging statements are an important methodology to allow developers to fix issues
found in the code after it has been released. The caveat here is found in the code after it has been released. The caveat here is
that the developer must remember that people will be using the code that the developer must remember that people will be using the code
at scale and in ways that can be unexpected for the original implementor. at scale and in ways that can be unexpected for the original implementor.
As such debugs MUST be guarded in such a way that they can be turned off. As such debugs **MUST** be guarded in such a way that they can be turned off.
This PROJECT has the ability to turn on/off debugs from the CLI and it is FRR has the ability to turn on/off debugs from the CLI and it is
expected that the developer will use this convention to allow control expected that the developer will use this convention to allow control
of their debugs. of their debugs.
### CLI-Changes ### CLI changes
CLI's are a complicated ugly beast. Additions or changes to the CLI CLI's are a complicated ugly beast. Additions or changes to the CLI
should use a DEFUN to encapsulate one setting as much as is possible. should use a DEFUN to encapsulate one setting as much as is possible.