Delete ChangeLog files Was :Re: ChangeLog change to .ChangeLog

Peter Dufault dufault at
Thu Mar 7 00:43:45 UTC 2013

On Mar 6, 2013, at 14:50 , Chris Johns <chrisj at> wrote:

> Ralf Corsepius wrote:
>> On 03/06/2013 06:44 PM, Thomas Doerfler wrote:
>>> Ralf,
>>> Am 06.03.2013 18:34, schrieb Ralf Corsepius:
>>>> On 03/06/2013 04:20 PM, Gedare Bloom wrote:
>>>>> If the ChangeLog entry text is by and large replicated already in the
>>>>> git log, then I see no reason to keep the files hanging around
>>>>> bit-rotting.
>>>> Again, ... the git-logs are a temporary internal implementation detail,
>>>> the ChangeLog files are legal documents.
>>> Can you elaborate this more clearly?
>> Whatever data is stored in whatever VCS is being used at a certain point
>> in time is completely irrelevant.
> Really. Do you keep "paper" copies of all diffs and reference them ? I 
> doubt it.
> I find it funny you now argue the VCS is irrelevant yet you battled the 
> change to git like it was also the end of the world. The only real 
> pattern repeating here is your behavior.
>>> I can't see any legal character in
>>> the changelogs or any RTEMS project files (except the copyright headers
>>> and License statements). Nobody sells RTEMS,
>> Again, simply accept that ChangeLogs are documents and are legally
>> relevant.
> You only fooling yourself with statements like this.
>>> nobody assures the features
>>> of RTEMS based on the Changelogs or the git logs. So what exactly do you
>>> mean the "legal"?
>> Time stamps, authorship, copyrights etc.
> The diff in the VCS is the only accurate definition. The time stamp on 
> the diff is the only valid time stamp. The check in author is wrong on a 
> number of cases, how-ever the check comments hint at the originator.
>>>> Git is like your employer carrying your working contract's data in their
>>>> internal database - The only document that counts is the version you
>>>> have printed.
>>> Right. But there is no RTEMS contract.
>> There is a product called RTEMS. The ChangeLogs are part of its legally
>> relevant documentation.
> There is none, never is and never will be. RTEMS is free and open.
>> Just wait 10 years, when "Gready business" sues you, because they got to
>> know that your business has sold an RTEMS-based application/product in
>> 2006, which as they claim, contains code which as they claim _you stole_
>> from their works.
> This statement is irrelevant to the discussion. If _you_ truly believe 
> this statement then the "you" includes you and that contradiction is 
> something you will need to consider.
> Chris
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at

I'm baffled by this conversation, so help me out.  I respect Ralf.  His sand-paper presentations on the list have pissed me off more than once, but I also know I've agreed with him when his rough presentation wasn't convincing anyone else.  So -

1. The Changelogs we're discussing are currently under git control, and so the current state can be retrieved in a provably, traceable manner in the future, though they disappear from view for the casual viewer.

2. The Changelogs aren't currently and sometimes haven't been updated.  I think this is because the overlap between adding an entry to a Changelog and also describing changes during a version control system commit is redundant, and so the Changelogs have suffered.

3. Any version control system that RTEMS switches to in the future will be at least as information-preserving as the switch to git, and so the Changelogs as they stand now will be traceably recoverable forever.

4. It's impossible to get people to start updating Changelogs in a way that would ever have some legal implications beyond what's implied by the public commits on a distributed VCS that has traceable history.

5. Changelogs provide a convenient form of release summary, but this can be provided by somebody who knows "git" well writing "changelog" script.

Which of the above statements are wrong?  Ralf, what kind of legal traceability is provided by visible and updated Changelogs beyond what is present and will be preserved in a conversion to yet another version control system?

I think you should clarify your concerns, because I'm not sure they are addressed by an infrequently updated "Changelog".   Then the entries required to address those concerns need to go into a git controlled document that is carefully reviewed at release snapshots.  I don't think the right name for that document would be "Changelog".

Peter Dufault
HD Associates, Inc.      Software and System Engineering

More information about the devel mailing list