Commit messages

Ralf Corsepius ralf.corsepius at
Tue Feb 21 18:11:04 UTC 2012

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
> seems artifical to me either.

Again, no. Each 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.


More information about the devel mailing list