test: Drop test for propagating flag changes from one file to another

[notmuch] / RELEASING

diff --git a/RELEASING b/RELEASING
index d314a6c68a3f63c87a8c1e3a488910618eb0a561..6c714f8e48a691ab8ae32fd7ecd22c3e71f52439 100644 (file)
--- a/RELEASING
+++ b/RELEASING
@@ -48,18 +48,18 @@ repository. From here, there are just a few steps to release:
        as "1.1" or "1.2").
 
        Finally, releases that do not change "features" but are merely
        as "1.1" or "1.2").
 
        Finally, releases that do not change "features" but are merely

-       bug fixes either add increase the micro number or add it
-       (starting at ".1" if not present). So a bug-fix release from
-       "1.0" would be "1.0.1" and a subsequent bug-fix release would
-       be "1.0.2" etc.
+       bug fixes either increase the micro number or add it (starting
+       at ".1" if not present). So a bug-fix release from "1.0" would
+       be "1.0.1" and a subsequent bug-fix release would be "1.0.2"
+       etc.

 
        Commit this change.
 
 4) Create an entry for the new release in debian/changelog
 
        The syntax of this file is tightly restricted, but the
 
        Commit this change.
 
 4) Create an entry for the new release in debian/changelog
 
        The syntax of this file is tightly restricted, but the

-       available emacs mode (see the dpkg-dev-el package helps).  The
-       entries here will be the Debian-relevant single-line
+       available emacs mode (see the dpkg-dev-el package) helps.
+       The entries here will be the Debian-relevant single-line

        description of changes from the NEWS entry. And the version
        must match the version in the next step.
 
        description of changes from the NEWS entry. And the version
        must match the version in the next step.