[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Auto-Generating ChangeLog and AUTHORS for projects in a version trac
Arne Babenhauserheide (IMK)
Re: Auto-Generating ChangeLog and AUTHORS for projects in a version tracking system?
Thu, 30 Oct 2014 07:45:30 +0100
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
Am 30.10.2014 00:43, schrieb Diego Elio Pettenò:
> All good and well, but then I may have misunderstood Arne's original
> point. If he's trying to get the GNU style to be "good enough"
That means I did not make my point clear enough. Second try:
I don’t want to change the GNU style. I want to have an easier way to
*adhere to* the existing GNU style by providing default tool support for
creating the ChangeLog and AUTHORS file from versiontracking systems.
Having NEWS, README, ChangeLog and AUTHORS in a release tarball makes a
lot of sense, and having NEWS and README also makes a lot of sense in a
version tracking system (I see that every time I try to use a project
which does not have them).
It’s just that when using a version tracking system, the ChangeLog and
AUTHORS file mostly duplicate information which is already in the
version tracking system.
This isn’t true for all projects. With complicated history a generated
ChangeLog can become useless and when committing patches from others and
forgetting to change the user, an autogenerated AUTHORS file can simply
be wrong. But for most projects they should be valid.
Additional motivation for this: If I want to teach someone to switch
from a simple Makefile to autotools, I have to talk about
- configure.ac (this is mostly copy-paste, adjusting name and version)
- Makefile.am (copy-paste from a similar project or adapt a Makefile)
- autoreconf -i; ./configure; make (“copy this into the README”)
- NEWS (“put the newest version at the top”)
- README (“describe how to use the project and how to contribute”)
- AUTHORS (“name all people who contributed”)
- ChangeLog (describe the changes in GNU style. This means:
- first line: date and author:
- changes indented.
- Start each changed file with a star (* file).
- optionally name the function.
- (a few special cases).
- Description after a colon and in following lines, also indented.
- empty line between independent changes?
As you can see, how to write a conforming ChangeLog takes roughly as
much explanation as writing the configure.ac. And every new contributor
will have to learn how to do that (while the other topics are only
needed for the initial setup or for the maintainer).
PS: I consider make distcheck as the gold standard for distributing
projects. I did not yet find a tool which gets close to matching that.
Tel.: +49 721 608-22885
Karlsruher Institut für Technologie
Postfach 36 40
Description: OpenPGP digital signature