ralf.corsepius at rtems.org
Tue Feb 21 18:11:04 UTC 2012
On 02/21/2012 05:35 PM, Thomas Doerfler wrote:
> 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.
More information about the devel