On Wed, Feb 05, 2014 at 11:17:25AM -0500, Mark H Weaver wrote: ludo@gnu.org (Ludovic Court??s) writes: > John Darrington skribis: > >> In my opinion the changelog conventions are achronistic, unintuitive, >> and bring benefit neither to developers nor users. > > Well, opinions may vary. > > It benefits me when I review other people???s patches, because it helps me > understand the structure of the change. And it benefits me before I > commit something, because it forces me to review all of my patch, make > sure it???s consistent, make sure there???s no leftover, and giving me an > opportunity to add comments to code that appears non-obvious in > hindsight. I also find them very useful when digging through (possibly ancient) commit history. Although all the information is in the actual patch, when looking through many commits it is much more convenient to read a summary of the changes. One summary line is not enough detail. Of course, it's extra work to write these summaries, but IMO it's worthwhile. I don't object to the spending time of writing changelogs. I just think the information that the GCS suggests is not helpful. It is not usefull to say changed file foo.scm, because using git show that is obvious. There is even a perl script out in the wild somewhere to generate exactly that. Typing it in is redundant. What would be useful (but in general) we don't put in the changelogs is WHY a developer changed foo.scm Put yourself in the shoes of a person investigating a problem in 3 years' time. He can see that developer fred did X. He doesn't need fred to tell him that. What he needs is fred to explain his reasoning for doing X not a statement that he has done it. That way he can make an informed decision about which way to take the code now. J' -- PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://sks-keyservers.net or any PGP keyserver for public key.