Merge branch 'master' into ng/master

This merge breaks few tests.  They will be adjusted by follow-up patches.

* master: (26 commits)
  tests: remove most uses of the AM_PROG_CC_C_O obsolete macro
  coverage: obsolete macro AM_PROG_CC_C_O should cause no warning nor errors
  INSTALL: update copyright years
  ithreads: use runtime (not configure time) detection of perl threads
  copyright: add few missing copyright notices
  maint: files in PLANS are to be exempted from copyright notice
  maint: consistently honor the UPDATE_COPYRIGHT_YEAR environment variable
  copyright: update some copyright years
  compile: use 'compile' script when "-c -o" is used with losing compilers
  HACKING: suggest more checks before releasing
  tests: can fake a compiler not grasping "-c -o" -- globally in all tests
  sync: update files from upstream with "make fetch"
  typofix: in comments in GNUmakefile
  Rename 'maint/' -> 'maintainer/', for Git's sake
  HACKING: minor typofix
  HACKING: bug-tracker, the PLANS directory, and how to plan "big" changes
  HACKING: rewindable branches should live in the 'experimental/*' namespace
  HACKING: fixlets about git branch rewinding policy
  HACKING: commit messages are not to follow GCS ChangeLog rules too strongly
  HACKING: "detailed explanation" in commit messages is almost mandatory
  ...

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

1 files changed, 36 insertions, 18 deletions

diff --git a/HACKING b/HACKING
index c0306125d..1d92fb836 100644
--- a/HACKING
+++ b/HACKING
@@ -14,7 +14,7 @@
 * If you incorporate a change from somebody on the net:
   First, if it is a large change, you must make sure they have signed the
   appropriate paperwork.
-  Second, be sure to add their name and email address to THANKS
+  Second, be sure to add their name and email address to THANKS.
 
 * If a change fixes a test, mention the test in the commit message.
   If a change fixes a bug registered in the Automake debbugs tracker,
@@ -38,6 +38,16 @@
 * Changes other than bug fixes must be mentioned in NEWS.  Important
   bug fixes should be mentioned in NEWS, too.
 
+* 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
 
@@ -107,7 +117,7 @@
 * There may be a number of longer-lived feature branches for new
   developments.  They should be based off of a common ancestor of all
   active branches to which the feature should or might be merged later.
-  in the future, we might introduce a special branch named 'next' that
+  In the future, we might introduce a special branch named 'next' that
   may serve as common ground for feature merging and testing, should
   they not yet be ready for master.
 
@@ -121,15 +131,17 @@
   the active branches descending from the buggy commit.  This offers a
   simple way to fix the bug consistently and effectively.
 
-* For merges from branches other than maint, prefer 'git merge --log' over
-  plain 'git merge', so that a later 'git log' gives an indication of which
-  actual patches were merged even when they don't appear early in the list.
+* When merging, prefer 'git merge --log' over plain 'git merge', so that
+  a later 'git log' gives an indication of which actual patches were
+  merged even when they don't appear early in the list.
 
-* master and release branches should not be rewound, i.e., should always
-  fast-forward, except maybe for privacy issues.  The maint branch should not
-  be rewound except maybe after retiring a release branch or a new stable
-  release.  For next, and for feature branches, the announcement for the
-  branch should document rewinding policy.
+* 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
+  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
@@ -143,8 +155,9 @@
       <reference to relevant bugs, if any>
 
       Here goes a more detailed explanation of why the commit is needed,
-      and a general overview of what it does, and how.  This section is
-      optional, but you are expected to provide it more often than not.
+      and a general overview of what it does, and how.  This section
+      should almost always be provided, possibly only with the expection
+      of obvious fixes or very trivial changes.
 
       And if the detailed explanation is quite long or detailed, you can
       want to break it in more paragraphs.
@@ -161,10 +174,10 @@
 
       <detailed list of touched files>
 
-* The <detailed list of touched files> is mandatory but for the most
-  trivial changes, and should follows the GNU guidelines for ChangeLog
-  entries (described explicitly in the GNU Coding Standards); it might
-  be something of this sort:
+* The <detailed list of touched files> should usually be provided (but
+  for short or trivial changes), and should follow the GNU guidelines
+  for ChangeLog entries (described explicitly in the GNU Coding
+  Standards); it might be something of this sort:
 
     * some/file (func1): Improved frobnication.
     (func2): Adjusted accordingly.
@@ -230,9 +243,14 @@
   The repository will always have its own "odd" number so we can easily
   distinguish net and repo versions.)
 
-* Run this:
+* Run these commands, in this order:
 
-    make bootstrap && make check && make distcheck
+    make bootstrap
+    make check keep_testdirs=yes
+    make maintainer-check
+    make distcheck
+    make check-no-trailing-backslash-in-recipes
+    make check-cc-no-c-o
 
   It is also advised to run "git clean -fdx" before invoking the
   bootstrap, to ensure a really clean rebuild.  However, it must