diff options
| author | Donald Sharp <sharpd@cumulusnetworks.com> | 2019-10-16 17:24:21 +0200 |
|---|---|---|
| committer | Donald Sharp <sharpd@cumulusnetworks.com> | 2019-11-01 01:55:08 +0100 |
| commit | 16318c5cdc4adfbec135d3c920e9b9a8a9c84019 (patch) | |
| tree | 3b3fdf153de5ec707f0b8b3a15f8ad4208509e15 /doc | |
| parent | Merge pull request #5248 from opensourcerouting/bgp-sender-as-path-loop-detec... (diff) | |
| download | frr-16318c5cdc4adfbec135d3c920e9b9a8a9c84019.tar.xz frr-16318c5cdc4adfbec135d3c920e9b9a8a9c84019.zip | |
doc: Update documentation to talk about development branches
As per weekly meeting this is an attempt to document about
how we as a community will work together on development
branches.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/developer/workflow.rst | 28 |
1 files changed, 28 insertions, 0 deletions
diff --git a/doc/developer/workflow.rst b/doc/developer/workflow.rst index c2e3724df..6eef7532b 100644 --- a/doc/developer/workflow.rst +++ b/doc/developer/workflow.rst @@ -163,6 +163,34 @@ releases have support for this feature request. Moreover, introducing features requests may result in breaking the stability of the branch. LTS branches are first done to bring long term support for stability. +Development Branches +-------------------- + +Occassionally the community will desire the ability to work together +on a feature that is considered useful to FRR. In this case the +parties may ask the Maintainers for the creation of a development +branch in the main FRR repository. Requirements for this to happen +are: + +- A one paragraph description of the feature being implemented to + allow for the facilitation of discussion about the feature. This + might include pointers to relevant RFC's or presentations that + explain what is planned. This is intended to set a somewhat + low bar for organization. +- A branch maintainer must be named. This person is responsible for + keeping the branch up to date, and general communication about the + project with the other FRR Maintainers. Additionally this person + must already be a FRR Maintainer. +- Commits to this branch must follow the normal PR and commit process + as outlined in other areas of this document. The goal of this is + to prevent the current state where large features are submitted + and are so large they are difficult to review. + +After a development branch has completed the work together, a final +review can be made and the branch merged into master. If a development +branch is becomes un-maintained or not being actively worked on after +three months then the Maintainers can decide to remove the branch. + Changelog --------- The changelog will be the base for the release notes. A changelog entry for |