Commit messages

[Ralf Corsepius]

On 02/21/2012 05:35 PM, Thomas Doerfler wrote:
> Hi,
>
> just to throw in my two (euro)cents:
>
> Am 21.02.2012 16:53, schrieb Joel Sherrill:
>>
>> But.. we haven't cleaned up from CVS yet.  We are in limbo
>> right now on ChangeLog's and $Id$'s and we need to settle that.
>>
>> + Do we remove $Id$'s?
Well, does git have something comparable? CVS's $Id$'s are helpful when 
people are referring to files from tarballs, e.g. in bug reports.

>> + We haven't decided what to do about the ChangeLog files yet. :)
>>     - Do they continue to be maintained or not?
>
> I would vote YES, but possibly in a different format, if this is
> suitable for the VCS in use.
I would vote manually written ChangeLogs in exactly the format we had used.

> Having a detailed history of changes is
> useful in many maintenance cases and we should provide that information
> even for those users working with tarballs instead of direkt GIT access.
Exactly. You can not expect users to have git access.

>>     - If not, then they need to be renamed. It is confusing to users.
>
> Archiving the CVS-based Changelogs in place with a suitable name (like
> "Changelog.pre2012") makes sense IMHO.
IMO, it does not make sense. We should continue to provide them as 
before, may-be splitting some overly large ones into ChangeLog.<year> or 
similar (This is what GCC does).

>>     - If we don't manually maintain them but want to keep them, then an
>>       automated update needs to occur on every commit. Given the ChangeLog's
>>       are scattered through the tree, if we do this, the script will have
>> to update
>>       the appropriate ChangeLogs.
>
> The current location of ChangeLog files seems quite artifical to me.
It isn't artificial.

Each of these ChangeLogs corresponds to a _subpackage_, which can be 
relocated to a different location with fairly small amounts of works.

> Ralf's explanation, that they are at the same nodes as the configure.ac
> seems artifical to me either.

Again, no. Each configure.ac makes them a _subpackage_ auto*tool-wise.

Think about BSPs. Your users will really want a per-BSP ChangeLog and 
not a monolytic toplevel ChangeLog containing all changes of everything.

Ralf