I'll quit whining, just wanted to give my +1 for removing the changelog.
I don't consider you whining. I am listening to the arguments. I am not convinced yet, though.
Well in that case, I'll chime in again:)
I still don't grasp what the common use of looking at U-Boot's entire changelog is. What are some common tasks that require grepping U-Boot's entire changelog? Are these tasks performed frequently enough that the extra <1 second 'git log' requires is bothersome?
I'm trying to maintain some awareness of open patches. For example, when I receive a pull request I mark all included patches as processed; sometimes this includes tracking down older versions of the patches, or commit messages that have been changed on the way. And yes, the <1 second delay is bothersome when doing this frequently enough.
I see, makes sense. This seems like a problem that is unique to you, as well as potentially a few other maintainers. I imagine the vast majority of developers rarely use the CHANGELOG file though. Would having maintainers create their own CHANGELOG files and/or use something like patchwork be acceptable?
-> wget -O u-boot.tgz 'http://git.denx.de/?p=u-boot.git;a=snapshot;sf=tgz'
For snapshots, the CHANGELOG file is going to be out of date though. It'll only list the changes that occurred up to the previous release. This seems worse than not having a CHANGELOG at all as its actively misleading people as to what changes their source code has.
I disagree here. I find myself quite frequently in the situation that I have to identify the exact version some source tree has been derived from. Companies who maintain out-of-tree ports usually don't include any SCM information either. To me, the CHANGELOG is an extremely useful resource in such cases.
The CHANGELOG in a company's source tree won't provide any more information than the VERSION, PATCHLEVEL, and EXTRAVERSION in the Makefile though, right? Ie the CHANGELOG is only updated when the VERSION, PATCHLEVEL, and EXTRAVERSION are updated. Either way, it seems like an inexact method to determine the revision of the source code, and there should be a better solution so that you don't have to be a detective every time you get another vendor's source tree.
It seems bad to have an inaccurate CHANGELOG. For example if someone got a snapshot tarball a week before the last release, their CHANGELOG would be missing over 500 changes. In this case the CHANGELOG clearly isn't serving its intended purpose and could actually mislead someone, eg "I know commit XYZ introduces a bug, but the changelog says I don't have commit XYZ in my tree, so I'm bug free!". In reality there have been 500 commits the user is unaware of, including potentially commit XYZ they were trying to avoid.
OK, its a stretch, but I don't get the purpose of an inaccurate CHANGELOG in any case. Other than when the 1 commit that correlates to a tagged release is the the top-of-tree, the CHANGELOG is *never* up to date. It can only be believed if someone downloads an officially released tarball - otherwise it is most likely wrong.
Best, Peter