Movatterモバイル変換
[0]ホーム
This is the mail archive of thelibc-alpha@sourceware.orgmailing list for theglibc project.
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 ChangeLogfile be populated if all that information is in the VCS? That wouldstill be needed for normal tarballs and the like when VCS is out thewindow.""History has a really bad memory, just because one uses a VCS todaydoesn't mean that this will be available in 10, 20, 30 years in anyusable format, or it might vanish completley.I've saved a few projects that used some sort of VCS, but was lost fordifferent reasons, and having had ChangeLog files would have saved manymany hours of headaches. Now all that is left is a tarball, with noinformation about who, when, or what was changed.""If you put ChangeLog entries in the commit message, then yes thisinformation will be available. But if you discard ChangeLog entriescompletley, I do not see how it can be available. ... The informationalso becomes totally lost as soon as you discard the VCS (i.e. whendoing releases).""It also makes a strong assumption on tools, and history has shown thattools 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 beingable 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 athow things changed -- and only way to do that is with a ChangeLog entry."""annotate", "diff" don't provide a human readable and searchable meansto 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 sothat a /consistent/ history of changes exists -- even if it isn't aspowerful as something like `git log' or `git bisect' -- is a compellingenough argument that I don't have an immediate rebuttal.Even in glibc, the project has used multiple VCS, but the ChangeLogremains, throughout all the messy, un-bisectable, batch-committedhistory, 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
[8]ページ先頭