taskGNU Astronomy Utilities - Tasks: task #13779, Drop ChangeLog

 
 

You are not allowed to post comments on this tracker with your current authentication level.

task #13779: Drop ChangeLog

Submitter:  Mosè Giordano <giordano>
Submitted:  Fri 16 Oct 2015 02:44:28 PM UTC
   
 
Should Start On:  Thu 15 Oct 2015 10:00:00 PM UTC Should be Finished on:  Thu 15 Oct 2015 10:00:00 PM UTC
Category:  None Priority:  5 - Normal
Item Group:  None Status:  Postponed
Privacy:  Public Percent Complete:  100%
Assigned to:  makhlaghi Open/Closed:  Closed
Effort:  0.00

Jump to the original submission

Fri 27 May 2016 04:37:57 AM UTC, comment #6: 

An explanation was added to the ChangeLog (so if someone opens the existing ChangeLog they know that it is no longer being updated) to finish this task. It has been merged into master and thus this task is now complete.

Two new tasks were defined following the completion of this task: task #14007 (to automatically generate the ChangeLog from the version controlled history) and task #14008 (to discuss if it is good to adopt the ChangeLog formatting in the commit messages).

Mohammad Akhlaghi <makhlaghi>
Group administrator
Sat 30 Apr 2016 08:14:41 AM UTC, comment #5: 

At the start of the bootsrap script (from Gnulib). It suggests: "consider installing git-merge-changelog from gnulib". After searching for "changelog" in gnulib, I saw there is also another script: "gitlog-to-changelog". These might also be interesting alternatives, besides the emacs solution. Since they are in Gnulib, it might be easier to use in Gnuastro. But it would be interesting to do a nice comparison and see how they all work and make the best choice.

Mohammad Akhlaghi <makhlaghi>
Group administrator
Sat 07 Nov 2015 06:29:32 PM UTC, comment #4: 

I'd suggest to completely drop the ChangeLog like GSL, but of course continuing to describe as much as possible the changeset in the commit message.  git blame is a wonderful tool to inspect the history of a region of code.

Emacs' developers can use ChangeLog-like commit messages because Emacs itself makes it supereasy to write a ChangeLog entry for a change and copy it to the commit message, but we can't force other contributors to use Emacs, even if I'd like to ;-)

Mosè Giordano <giordano>
Group Member
Sat 07 Nov 2015 03:13:54 AM UTC, comment #3: 

Thanks for the link. From now on, we can stop adding to the ChangeLog. I have just added a "For v0.1:" to the title to explicitly mark this task as something that should be done before the release of version 0.1. In this way, a simple search in the open tasks will highlight anything we haven't done yet.

In the meantime we can think if we want to stop updating the ChangeLog like GSL or use a script like the Emacs example and generate it prior to each release automatically.

I have marked the completion to 10% since at least we have decided to not update ChangeLog any more. Once we decide how to implement it from the two options above, we can make it 100% and mark it as closed.

Maybe we can follow this way of putting a "For vN.N:" prior to the titles of each task that is agreed upon to do prior to any release but doesn't need immediate attention.

Mohammad Akhlaghi <makhlaghi>
Group administrator
Wed 04 Nov 2015 10:55:01 AM UTC, comment #2: 

ChangeLog file can be auto-generated from VCS log, this is what Emacs does (http://git.savannah.gnu.org/gitweb/?p=emacs.git;a=blob;f=build-aux/gitlog-to-changelog;hb=HEAD).  Instead, GSL completely dropped ChangeLog three years ago.

I completely agree something like a NEWS file should be given anyway.  I, as a user, always want to know what changed between two versions of a program.

Mosè Giordano <giordano>
Group Member
Wed 04 Nov 2015 08:22:04 AM UTC, comment #1: 

This is a completely reasonable argument and I agree. Until now I would only keep the changes (as opposed to additions) in the ChangeLog and try to explain both in the commit messages.

Git commit messages and the corresponding changes have all the information we might need and the problem with merge conflicts you mentioned are completely true.

I am just thinking about a good way to deploy it (remove the ChangeLog) while also satisfying the GNU Coding Standards. I think the NEWS file is probably enough for the users who only download Gnuastro's released tar.gz file, the ChangeLog is too detailed for them.

Mohammad Akhlaghi <makhlaghi>
Group administrator
Fri 16 Oct 2015 02:44:28 PM UTC, original submission:  

ChangeLog files used to make sense whit old VCSs, but modern VCSs, like git, have good commit messages and writing both the commit message and the ChangeLog is a duplicate effort.  Working with other people results often in high probability of having merge conflicts on ChangeLog, which are a pain to fix.  I suggest, but this is open to discussion, to drop the ChangeLog and continue to have informative commit messages instead.

Mosè Giordano <giordano>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by makhlaghi (Posted a comment)
  • -email is unavailable- added by giordano (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-05-27 makhlaghi Percent Complete10% 100%
        Open/ClosedOpen Closed
        SummaryFor v0.1: drop ChangeLog Drop ChangeLog
    2015-11-07 makhlaghi Percent Complete0% 10%
        Assigned toNone makhlaghi
        SummaryDrop ChangeLog? For v0.1: drop ChangeLog

    Back to the top

    Powered by Savane 3.12