H. Peter Anvin
f2c2a12b99
gnu tools: include autoconf/automake sources
|
1 year ago | |
|---|---|---|
| .. | ||
| obsolete-removed | 1 year ago | |
| texi | 1 year ago | |
| README | 1 year ago | |
| rm-f-without-args.txt | 1 year ago | |
| subdir-objects.txt | 1 year ago | |
README
"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.
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.