Using gnuify-changelog.pl ... or re-think how ChangeLog should be maintained.

[Peter]

The current Changelog format is a pain to update for the Release Manager. Shall we use the guify-changelog.pl instead and parse the changelog from the repository (svn log). In that way it could be automatically done within make dist.

In short, the ChangeLog is very tedious to keep up-to date. Change format or updating procedure.

[Peter]

I tried the script again and the size of the output is 116kB. Although that is not tremendously large I think it is waste to increase the dist with 116kB. I simply don't see the use of the file anymore. Just like with the TODO file it is not useful because when you need the information you'll go to trac. Or in the log case you will likely issue svn log if you are in a svn wc. This, of course, assumes that you have access to the web and I think that is pretty much true for most people for most of the time.

Therefore I think the Changelog should change to something that looks more like the TODO file. Something static that doesn't cause headache for the RM and simply direct the reader to the trac site.

[Peter]

A suggestion:

See the yat trac environment for log information:

http://dev.thep.lu.se/yat/log

[Peter]

An alternative could be to keep it more similar to current style, but avoid referring to revisions and rather refer to tags. For instance:

http://dev.thep.lu.se/yat/log/tags/0.4.2?mode=follow_copy

[Peter]

(In [1798]) refs #408

Changing pointers in ChangeLog? so they are easier to maintain.

[Peter]

I hope the change in r1798 is OK with everyone.

Left is to decide is how ChangeLog should look in the release tarball. I see three alternatives:

1. Use the perl-script as suggested above to create a ChangeLog at release time. This is how GNU CoreUtils does it this way with a dist-hook (see ​Makefile.am).

2. Keep the distributed ChangeLog the same as the one in the repository. It is good to keep the repository and distributed tarball as similar as possible.

3. At release time use a dist-hook that generates ChangeLog with pointers to the specific release. See source:trunk/ChangeLog​ and it is a trivial exercise to print that file with the specific <VERSION> since version info is available in make variable $(VERSION)

[Jari Häkkinen]

Replying to peter:

I hope the change in r1798 is OK with everyone.

Perfect ... I think. One thing (there is always one), the output is very verbose. Is it possible to generate a log without all changed files specified?

I begin to rethink my perfect statement above. The changes are not grouped to releases, all 0.4 logs are a part of the 0.4.1 log. Of course, they are but one would like to highlight the difference between 0.4.1 and 0.4. Now you may say that this information should go into NEWS, and as always, you are right. I am back at Perfect!

Left is to decide is how ChangeLog should look in the release tarball. I see three alternatives:

1. Use the perl-script as suggested above to create a ChangeLog at release time. This is how GNU CoreUtils does it this way with a dist-hook (see ​Makefile.am).

2. Keep the distributed ChangeLog the same as the one in the repository. It is good to keep the repository and distributed tarball as similar as possible.

3. At release time use a dist-hook that generates ChangeLog with pointers to the specific release. See source:trunk/ChangeLog​ and it is a trivial exercise to print that file with the specific <VERSION> since version info is available in make variable $(VERSION)

I think I prefer 2 with an amendment. The changelog could have specific version link to that release:

http://dev.thep.lu.se/yat/log/tags/0.4?format=changelog?mode=follow_copy for a 0.4 release http://dev.thep.lu.se/yat/log/tags/0.4.2?format=changelog?mode=follow_copy for a patch release.

In the trunk this link is naturally

http://dev.thep.lu.se/yat/log/trunk?format=changelog?mode=follow_copy for trunk

and it becomes a part of the release procedure to change this specific line.

[Peter]

Replying to jari:

Replying to peter:

Left is to decide is how ChangeLog should look in the release tarball. I see three alternatives:

1. Use the perl-script as suggested above to create a ChangeLog at release time. This is how GNU CoreUtils does it this way with a dist-hook (see ​Makefile.am).

2. Keep the distributed ChangeLog the same as the one in the repository. It is good to keep the repository and distributed tarball as similar as possible.

3. At release time use a dist-hook that generates ChangeLog with pointers to the specific release. See source:trunk/ChangeLog​ and it is a trivial exercise to print that file with the specific <VERSION> since version info is available in make variable $(VERSION)

I think I prefer 2 with an amendment. The changelog could have specific version link to that release:

http://dev.thep.lu.se/yat/log/tags/0.4?format=changelog?mode=follow_copy for a 0.4 release http://dev.thep.lu.se/yat/log/tags/0.4.2?format=changelog?mode=follow_copy for a patch release.

In the trunk this link is naturally

http://dev.thep.lu.se/yat/log/trunk?format=changelog?mode=follow_copy for trunk

and it becomes a part of the release procedure to change this specific line.

OK. you want tags to be identical to tarballs; makes sense. Would you mind amend as you desire?

[Peter]

Replying to peter:

Replying to jari:

Replying to peter:

I think I prefer 2 with an amendment. The changelog could have specific version link to that release:

http://dev.thep.lu.se/yat/log/tags/0.4?format=changelog?mode=follow_copy for a 0.4 release http://dev.thep.lu.se/yat/log/tags/0.4.2?format=changelog?mode=follow_copy for a patch release.

In the trunk this link is naturally

http://dev.thep.lu.se/yat/log/trunk?format=changelog?mode=follow_copy for trunk

and it becomes a part of the release procedure to change this specific line.

OK. you want tags to be identical to tarballs; makes sense. Would you mind amend as you desire?

Second thoughts. One of the reasons behind this ticket was to avoid merge conflicts. If the file should have different versions in /tags and in /trunk it will automatically lead to conflicts. I am not happy about that because it implies extra work for the Merge Master.

[Jari Häkkinen]

Replying to peter:

Replying to peter:

Replying to jari:

Replying to peter:

I think I prefer 2 with an amendment. The changelog could have specific version link to that release:

http://dev.thep.lu.se/yat/log/tags/0.4?format=changelog?mode=follow_copy for a 0.4 release http://dev.thep.lu.se/yat/log/tags/0.4.2?format=changelog?mode=follow_copy for a patch release.

In the trunk this link is naturally

http://dev.thep.lu.se/yat/log/trunk?format=changelog?mode=follow_copy for trunk

and it becomes a part of the release procedure to change this specific line.

OK. you want tags to be identical to tarballs; makes sense. Would you mind amend as you desire?

Second thoughts. One of the reasons behind this ticket was to avoid merge conflicts. If the file should have different versions in /tags and in /trunk it will automatically lead to conflicts. I am not happy about that because it implies extra work for the Merge Master.

I still vote for 2, even without changes suggested by me.

[Peter]

OK, then we are done here.