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

[Wolfgang Denk]

Dear Peter Tyser,

In message <1273095808.2451.4674.camel at localhost.localdomain> you wrote:
>
> 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?

As far as the patch processing is concerned, a dynamically generated
file is perfectly good enough for me. If we can keep the "CHANGELOG"
make target I have all I need here.

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

Thats's not quite right. I used to update CHANGELOG more frequently in
the past.

> 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

Agreed. It was never perfect, but the best we (well, I) had.

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

Right. Well, Kim's pointer to gitattributes is probably the solution
to this issue. Please allow me for some time to let this sink in.

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
He is truly wise who gains wisdom from another's mishap.