This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Removing ChangeLog [Was Re: 2.26 hard freeze status]


On 08/03/2017 02:23 AM, Siddhesh Poyarekar wrote:
> On Thursday 03 August 2017 11:49 AM, Rical Jasan wrote:
>> I've been (re-)reading some of the arguments for it on bug-standards, to
>> try and appreciate the viewpoint, and it seems to be a feeling that the
>> ChangeLog is a consistent -- and persistent, when distributed with
>> release tarballs (which may be even more to the point) -- record, unlike
>> the VCS du jour.  Joseph may be able to provide better insight, though;
>> I'm not sure I've fully grasped all the subtleties of every concerned
>> party's arguments.  Only a handful have weighed in on the discussion
>> thus far.
> 
> I personally don't see the consistency, persistence of the ChangeLog
> format over the combination of plain English and code whose language I
> am more familiar with than the ChangeLog format.

What struck me was the repeated sense of loss of history, in [1]:

"How would the information that is normally available in a ChangeLog
file be populated if all that information is in the VCS?  That would
still be needed for normal tarballs and the like when VCS is out the
window."

"History has a really bad memory, just because one uses a VCS today
doesn't mean that this will be available in 10, 20, 30 years in any
usable format, or it might vanish completley.

I've saved a few projects that used some sort of VCS, but was lost for
different reasons, and having had ChangeLog files would have saved many
many hours of headaches.  Now all that is left is a tarball, with no
information about who, when, or what was changed."

"If you put ChangeLog entries in the commit message, then yes this
information will be available.  But if you discard ChangeLog entries
completley, I do not see how it can be available.  ...  The information
also becomes totally lost as soon as you discard the VCS (i.e. when
doing releases)."

"It also makes a strong assumption on tools, and history has shown that
tools come and go but text files stay."


while I was trying to reconcile this comment, in [2]:

"People who keep suggesting git as a solution miss the point of being
able to extract this information in a archivable format."


[1] contains several other arguments I personally don't feel are valid;
e.g. (not all-inclusive):

"to be able to understand how something came to be one needs to look at
how things changed -- and only way to do that is with a ChangeLog entry."

""annotate", "diff" don't provide a human readable and searchable means
to go through history."

"the point of the ChangeLog files is to be able to undo changes."


but even though the ChangeLog isn't necessarily useful to me with a VCS,
the requirement that there has always been one and will always be one so
that a /consistent/ history of changes exists -- even if it isn't as
powerful as something like `git log' or `git bisect' -- is a compelling
enough argument that I don't have an immediate rebuttal.

Even in glibc, the project has used multiple VCS, but the ChangeLog
remains, throughout all the messy, un-bisectable, batch-committed
history, which is what I was alluding to by /persistent/.


> I guess it really boils down to a personal preference, so deciding on
> this is going to be quite difficult in a consensus driven community like
> ours.

Agreed.

Rical

[1] https://lists.gnu.org/archive/html/bug-standards/2017-07/msg00001.html
[2] https://lists.gnu.org/archive/html/bug-standards/2017-08/msg00001.html


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]