Merge branch 'micro' into maint

* micro:
  post-release: micro version bump (1.13.2a)
  release: stable micro release 1.13.2
  vala tests: skip in a cross compiler setup
  HACKING: miscellaneous fixes, updates and enhancements
  NEWS: minor improvements to wording (about new versioning scheme)

Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>

diff --cc HACKING
index b526600896ac1a7ad76f91eb69bbb0aca4fb4c17,cebcb7246ba3a36ad11278eaf655abeb66ab7530..435eb77773bed89ce829789558e3ab406f39d2f6
--- 1/HACKING
--- 2/HACKING
+++ b/HACKING
@@@ -35,19 -35,8 +35,18 @@@
    which should be updated by hand whenever the GPL gets updated (which
    shouldn't happen that often anyway :-)
  
- * Changes other than bug fixes must be mentioned in NEWS.  Important
-   bug fixes should be mentioned in NEWS, too.
+ * Changes other than *trivial* bug fixes must be mentioned in NEWS.
  
 +* Changes which are potentially controversial, require a non-trivial
 +  plan, or must be implemented gradually with a roadmap spanning several
 +  releases (either minor or major) should be discussed on the list,
 +  and have a proper entry in the PLANS directory.  This entry should be
 +  always committed in the "maint" branch, even if the change it deals
 +  with is only for the master branch, or a topic branch.  Usually, in
 +  addition to this, it is useful to open a "wishlist" report on the
 +  Automake debbugs tracker, to keep the idea more visible, and have the
 +  discussions surrounding it easily archived in a central place.
 +
  ============================================================================
  = Naming
  
@@@ -200,13 -191,12 +201,13 @@@
    a later 'git log' gives an indication of which actual patches were
    merged even when they don't appear early in the list.
  
- * The 'master' and 'maint' branches should not be rewound, i.e., should
-   always fast-forward, except maybe for privacy issues.  For 'next'
-   (if that will ever be implemented), and for feature branches, the
-   announcement for the branch should document rewinding policy.  If a
-   topic branch is expected to be rewound, it is good practice to put
+ * The 'master', 'maint' and 'micro' branches should not be rewound, i.e.,
+   should always fast-forward, except maybe for privacy issues.  For
+   feature branches, the announcement for the branch should document
 -  the rewinding policy.  It is usually a good idea to keep rewindable
 -  branches in the 'experimental/*' "namespace"; i.e., give them names
 -  like 'experimental/testsuite-work' or 'experimental/djgpp-for-WinNT'.
++  the rewinding policy.
++  If a topic branch is expected to be rewound, it is good practice to put
 +  it in the 'experimental/*' namespace; for example, a rewindable branch
 +  dealing with Vala support could be named like "experimental/vala-work".
  
  ============================================================================
  = Writing a good commit message

diff --cc NEWS
Simple merge

diff --cc t/ax/am-test-lib.sh
Simple merge