aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorEli Zaretskii2016-10-04 08:59:37 +0300
committerEli Zaretskii2016-10-04 08:59:37 +0300
commitec6e4b9d1e5a215d9dfe1026730dbb23f1935615 (patch)
tree38e60063a78637f13491bc89fc6364bf269a9af2
parente1b2918c7cdecdde093390adc2fa26713554da02 (diff)
downloademacs-ec6e4b9d1e5a215d9dfe1026730dbb23f1935615.tar.gz
emacs-ec6e4b9d1e5a215d9dfe1026730dbb23f1935615.zip
; Minor addition to CONTRIBUTE
* CONTRIBUTE (http): Mention that doc fixes should always go to the release branch.
-rw-r--r--CONTRIBUTE4
1 files changed, 4 insertions, 0 deletions
diff --git a/CONTRIBUTE b/CONTRIBUTE
index a70682f29ab..a02acadc73f 100644
--- a/CONTRIBUTE
+++ b/CONTRIBUTE
@@ -189,6 +189,10 @@ If you are fixing a bug that exists in the current release, be sure to
189commit it to the release branch; it will be merged to the master 189commit it to the release branch; it will be merged to the master
190branch later by the gitmerge function. 190branch later by the gitmerge function.
191 191
192Documentation fixes (in doc strings, in manuals, and in comments)
193should always go to the release branch, if the documentation to be
194fixed exists and is relevant to the release-branch codebase.
195
192However, if you know that the change will be difficult to merge to the 196However, if you know that the change will be difficult to merge to the
193master (e.g., because the code on master has changed a lot), you can 197master (e.g., because the code on master has changed a lot), you can
194apply the change to both master and branch yourself. It could also 198apply the change to both master and branch yourself. It could also