* mail/rmail.el (rmail-show-message-1): When displaying a mime message,

       indicate start and finish in the echo area.

       * mail/rmail.el (rmail-epa-decrypt): Disregard <pre> before armor.
       Ignore more kinds of whitespace in mime headers.
       Modify the decrypted mime part's mime type so it will be displayed
       by default when visiting this message again.

       * net/browse-url.el (browse-url-firefox-program): Prefer IceCat, doc.
       (browse-url-firefox-arguments)
       (browse-url-firefox-startup-arguments): Doc fix.

1 files changed, 21 insertions, 0 deletions

diff --git a/admin/notes/repo b/admin/notes/repo
index 2d4cc2a55cf..4f9dc59eb0f 100644
--- a/admin/notes/repo
+++ b/admin/notes/repo
@@ -7,6 +7,27 @@ package archive (elpa.gnu.org).  See admin/notes/elpa for further
 explanation, and the README file in the branch for usage
 instructions.
 
+* Install changes only on one branch, let them get merged elsewhere if needed.
+
+In particular, install bug-fixes only on the release branch (if there
+is one) and let them get synced to the trunk; do not install them by
+hand on the trunk as well.  E.g. if there is an active "emacs-24" branch
+and you have a bug-fix appropriate for the next emacs-24.x release,
+install it only on the emacs-24 branch, not on the trunk as well.
+
+Installing things manually into more than one branch makes merges more
+difficult.
+
+http://lists.gnu.org/archive/html/emacs-devel/2010-03/msg01124.html
+
+The exception is, if you know that the change will be difficult to
+merge to the trunk (eg because the trunk code has changed a lot).
+In that case, it's helpful if you can apply the change to both trunk
+and branch yourself (when committing the branch change, indicate
+in the commit log that it should not be merged to the trunk, by
+including the phrase "Not to be merged to master", or any other phrase
+that matches "merge").
+
 * Installing changes from your personal branches.
 
 If your branch has only a single commit, or many different real