[Automake-commit] [SCM] GNU Automake branch, maint, updated. v1.13.1-29-gfa0fc1b

[Stefano Lattarini]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU Automake".

http://git.sv.gnu.org/gitweb/?p=automake.git;a=commitdiff;h=fa0fc1bf55b423a401c98dff0cc0dcdb83136b8e

The branch, maint has been updated
       via  fa0fc1bf55b423a401c98dff0cc0dcdb83136b8e (commit)
       via  5fdf75877fd22aed951678d92b291b3b7ca1926f (commit)
      from  5df23a7accb0e82109898f02818c2f65a0bb7b91 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit fa0fc1bf55b423a401c98dff0cc0dcdb83136b8e
Merge: 5df23a7 5fdf758
Author: Stefano Lattarini <address@hidden>
Date:   Fri Jan 4 10:23:36 2013 +0100

    Merge branch 'plans' into maint
    
    * plans:
      plans: add the "PLANS" directory
    
    Signed-off-by: Stefano Lattarini <address@hidden>
    
    Conflicts:
        Makefile.am

commit 5fdf75877fd22aed951678d92b291b3b7ca1926f
Author: Stefano Lattarini <address@hidden>
Date:   Thu Jan 3 12:03:37 2013 +0100

    plans: add the "PLANS" directory
    
    Individual files or sub-directories about future and on-going
    development plans in Automake will be added in follow-up commits.
    
    This new set of documents is meant to help ensure a more controlled
    and smooth development and evolution for Automake, in several ways.
    
     - Having the plans clearly spelled out should will avoid messy
       roadmaps with no clear way forward or with muddy or ill-defined
       aims or purposes; a trap this is too easy to fall into.
    
     - Keeping planned changes cooking and re-hashed for a while should
       ensure rough edges are smoothed up, transitions are planned in a
       proper way (hopefully avoiding debacles like the AM_MKDIR_PROG_P
       deprecation and the AM_CONFIG_HEADER too-abrupt removal), and
       "power users" have more chances of getting informed in due time,
       thus having all the time to prepare for the changes or raise
       objections against them.
    
     - Having the plans clearly stated and registered in a "centralized"
       location should make it more difficult to them to slip through
       the cracks, getting forgotten or (worse) only half-implemented.
    
     - Even for discussions and plans registered on the Bug Tracker
       as well, a corresponding entry in the PLANS directory can help
       in keeping main ideas summarized, and consensus and/or objections
       registered and easily compared.
    
    Motivation:
    <http://blog.flameeyes.eu/2013/01/autotools-mythbuster-automake-pains>
    Not a flatting picture for us (and maybe a little too harsh), but
    basically true and even spot-on in some regards.
    
    * PLANS/README: New.
    * Makefile.am (EXTRA_DIST): Distribute the whole PLANS directory.
    
    Signed-off-by: Stefano Lattarini <address@hidden>

-----------------------------------------------------------------------

Summary of changes:
 Makefile.am  |    3 ++-
 PLANS/README |   25 +++++++++++++++++++++++++
 2 files changed, 27 insertions(+), 1 deletions(-)
 create mode 100644 PLANS/README

diff --git a/Makefile.am b/Makefile.am
index d868501..3c40f27 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -69,7 +69,8 @@ EXTRA_DIST += \
   $(AUTOMAKESOURCES) \
   bootstrap.sh \
   GNUmakefile \
-  HACKING
+  HACKING \
+  PLANS
 
 # Make versioned links.  We only run the transform on the root name;
 # then we make a versioned link with the transformed base name.  This
diff --git a/PLANS/README b/PLANS/README
new file mode 100644
index 0000000..87cb8dc
--- /dev/null
+++ b/PLANS/README
@@ -0,0 +1,25 @@
+"Plans" for future or on-going Automake development.
+
+The contents is meant to help ensure a more controlled and smooth
+development and evolution for Automake, in several ways.
+
+ - Having the plans clearly spelled out should will avoid messy
+   roadmaps with no clear way forward or with muddy or ill-defined
+   aims or purposes; a trap this is too easy to fall into.
+
+ - Keeping planned changes cooking and re-hashed for a while should
+   ensure rough edges are smoothed up, transitions are planned in a
+   proper way (hopefully avoiding debacles like the AM_MKDIR_PROG_P
+   deprecation and the AM_CONFIG_HEADER too-abrupt removal), and
+   "power users" have more chances of getting informed in due time,
+   thus having all the time to prepare for the changes or raise
+   objections against them.
+
+ - Having the plans clearly stated and registered in a "centralized"
+   location should make it more difficult to them to slip through
+   the cracks, getting forgotten or (worse) only half-implemented.
+
+ - Even for discussions and plans registered on the Bug Tracker
+   as well, a corresponding entry in the PLANS directory can help
+   in keeping main ideas summarized, and consensus and/or objections
+   registered and easily compared.


hooks/post-receive
-- 
GNU Automake