diff options
Diffstat (limited to 'doc/developer')
| -rw-r--r-- | doc/developer/building-frr-for-alpine.rst | 2 | ||||
| -rw-r--r-- | doc/developer/topotests.rst | 9 | ||||
| -rw-r--r-- | doc/developer/workflow.rst | 12 |
3 files changed, 21 insertions, 2 deletions
diff --git a/doc/developer/building-frr-for-alpine.rst b/doc/developer/building-frr-for-alpine.rst index f88fc7bfdc..68e58c9d76 100644 --- a/doc/developer/building-frr-for-alpine.rst +++ b/doc/developer/building-frr-for-alpine.rst @@ -85,8 +85,6 @@ startup. To configure by hand: docker exec -it frr /bin/sh vi /etc/frr/daemons - cp /etc/frr/zebra.conf.sample /etc/frr/zebra.conf - vi /etc/frr/zebra.conf /etc/init.d/frr start Or, to configure the daemons using /etc/frr from a host volume, put the diff --git a/doc/developer/topotests.rst b/doc/developer/topotests.rst index 2a6d2dda34..a86566dbb0 100644 --- a/doc/developer/topotests.rst +++ b/doc/developer/topotests.rst @@ -480,6 +480,15 @@ Some things to keep in mind: - Avoid including unstable data in your test: don't rely on link-local addresses or ifindex values, for example, because these can change from run to run. +- Using sleep is almost never appropriate to wait for some convergence + event as the sole item done. As an example: if the test resets the peers + in BGP, the test should look for the peers reconverging instead of just + sleeping an arbitrary amount of time and continuing on. It is ok to + use sleep in a tight loop with appropriate show commands to ensure that + the protocol reaches the desired state. This should be bounded by + appropriate timeouts for the protocol in question though. See + verify_bgp_convergence as a good example of this. If you are having + troubles figuring out what to look for, please do not be afraid to ask. Topotest File Hierarchy diff --git a/doc/developer/workflow.rst b/doc/developer/workflow.rst index abdbea5a9c..b4ddec10c9 100644 --- a/doc/developer/workflow.rst +++ b/doc/developer/workflow.rst @@ -500,10 +500,22 @@ made. For example, a change in :file:`bgpd/rfapi` would be formatted as:: The first line should be no longer than 50 characters. Subsequent lines should be wrapped to 72 characters. +The purpose of commit messages is to briefly summarize what the commit is +changing. Therefore, the extended summary portion should be in the form of an +English paragraph. Brief examples of program output are acceptable but if +present should be short (on the order of 10 lines) and clearly demonstrate what +has changed. The goal should be that someone with only passing familiarity with +the code in question can understand what is being changed. + +Commit messages consisting entirely of program output are *unacceptable*. These +do not describe the behavior changed. For example, putting VTYSH output or the +result of test runs as the sole content of commit messages is unacceptable. + You must also sign off on your commit. .. seealso:: :ref:`signing-off` + Source File Header ------------------ |