[U-Boot] [PATCH 2/2] remove main CHANGELOG file

[Peter Tyser <ptyser@xes-inc.com>]

> > 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