proxmox-mirrors/mirror_frr
1
0
Fork 0
mirror of https://git.proxmox.com/git/mirror_frr synced 2025-05-29 13:51:53 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

doc: Update workflow.rst for release management

Browse Source 
Some release management updates

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This commit is contained in:
Donald Sharp 2021-09-16 14:36:17 -04:00
parent 1a8a7016a6
commit add70bc315
1 changed files with 7 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
doc/developer/workflow.rst
View File

@ -163,15 +163,18 @@ For reference, the expected release schedule according to the above is:
+---------+------------+------------+------------+------------+------------+ +---------+------------+------------+------------+------------+------------+
Each release is managed by one or more volunteer release managers from the FRR Each release is managed by one or more volunteer release managers from the FRR
community. To spread and distribute this workload, this should be rotated for community. These release managers are expected to handle the branch for a period
of one year. To spread and distribute this workload, this should be rotated for
subsequent releases. The release managers are currently assumed/expected to subsequent releases. The release managers are currently assumed/expected to
run a release management meeting during the weeks listed above. Barring other run a release management meeting during the weeks listed above. Barring other
constraints, this would be scheduled before the regular weekly FRR community constraints, this would be scheduled before the regular weekly FRR community
call such that important items can be carried over into that call. call such that important items can be carried over into that call.
Bugfixes are applied to the two most recent releases. However, backporting of bug Bugfixes are applied to the two most recent releases. It is expected that
fixes to older than the two most recent releases will not be prevented, if acked each bugfix backported should include some reasoning for its inclusion
under the classical development workflow applying for a pull request. as well as receiving approval by the release managers for that release before
accepted into the release branch. This does not necessarily preclude backporting of
bug fixes to older than the two most recent releases.
Security fixes are backported to all releases less than or equal to at least one Security fixes are backported to all releases less than or equal to at least one
year old. Security fixes may also be backported to older releases depending on year old. Security fixes may also be backported to older releases depending on