Commit messages

Ralf Corsepius ralf.corsepius at
Wed Feb 22 09:58:07 UTC 2012

On 02/21/2012 09:06 PM, Gedare Bloom wrote:
> On Tue, Feb 21, 2012 at 1:11 PM, Ralf Corsepius
> <ralf.corsepius at>  wrote:
>> 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.
> Unless I'm mistaken the "official" tarballs are just the release
> versions right?
No, ... users may be importing the sources into different VCSes.

> So I don't see a need to have any redundant versioning
> information. Maybe I missed something.

a) A product's sources must be self contained. It must not have any 
dependency on any vendor infrastructure (such as git), because you can 
not force users to using your infrastructure.

b) This information is only redundant insofar, as it decouples the 
sources from a vendors' infrastructure. This is helpful in longer terms, 
e.g. when this infrastructure gets lost (e.g. when git gets corrupted).

>>>> + 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.
> If we do then we should have some good way to update ChangeLog files
> atomically when pushing changes in order to avoid the potential mess
> of merging branches--especially long-running development
> branches--that contain commits that touch ChangeLog files.

The fundamental problem is whether to use generated ChangeLogs or not.

Like I tried to express before, I am strongly opposed to using generated 
ones, for reasons I am seeming unable to communicate.

>>> 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).
> I think it makes sense to rename/archive them as a natural phase of
> the change to git.
Again, there is nothing natural in what you say.

The rationales to keep Changelogs are independent of the VCS being used. 
It's just that the common git-hype victim fails to understand the reasons.

> For users trying to find what changed during the
> 4.11 release cycle, however, it will complicate matters.
I fail to understand this.

We could continue like we did before.

>>>>     - 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.
> I think it is a nice idea to consider more arguments than
> autotool-dependent subpackages: what if autotools goes away, then what
> is the reasoning behind our placement of ChangeLogs?
Now you are being violent :()

The way the autotools are being used is just a reflection of the nature 
the source tree is structurized.

In an ideal world ...
rm -rf c/src/lib/libbsp/<target>/<bsp>
... and the whole BSP is gone without requiring any changes elsewhere, 
esp. without ChangeLogs entries referring to removed code.

We are very close to this.

> Do we really need
> ChangeLogs in (just to pick one) ./doc/tools/bmenu/?
Yes. This is an independent package, which actually has nothing to do 
with RTEMS. It is only bundled with RTEMS because nobody but RTEMS uses it.


More information about the devel mailing list