RFC: Rename existing ChangeLogs

Ralf Corsepius ralf.corsepius at rtems.org
Fri Feb 24 04:02:55 UTC 2012


On 02/20/2012 06:47 PM, Gedare Bloom wrote:
> On Fri, Feb 17, 2012 at 11:58 AM, Ralf Corsepius
> <ralf.corsepius at rtems.org>  wrote:
>> On 02/17/2012 05:39 PM, Joel Sherrill wrote:
>>>
>>> Hi,
>>>
>>> Now that ChangeLogs are not being updated,
>>
>> .. a fact I consider to be a serious regression, which needs to be reverted.
>>
>> ... ATM, you do not see what has changed without digging deeply into git.
>>
>>
> I re-read the conversation we previously had [1] on this topic. I
> guess the issue is not settled. I'm not clear about who will actually
> use ChangeLog that would not be able to use git to find out "what
> changed?".  To me, the ChangeLog files seem to be artifacts that we
> should put in a museum.
>
> [1] http://www.rtems.org/pipermail/rtems-devel/2012-January/000123.html
>
>>> leaving them
>>> in place is potentially confusing.
>>
>> That's an utter understatement. The current state is unusable.
>>
>>
>>> I have already had one user
>>> ask privately why a change wasn't listed in it.
>>
>>
>>
>>> I propose we rename them. Possible destination names:
>>>
>>> ChangeLog-pregit
>>> ChangeLog-cvs
>>> ChangeLog-pre2012
>>>
>>> Comments?
>>>
>> I propose to resume the old conventions of manually writing ChangeLogs.
>>
> As long we abandon ChangeLogs entirely then I'm in favor of renaming
> the existing ones to ChangeLog-cvs.
Why? I don't see any reason to do so.
There is no connection between the VCS having been used nor is there a 
connection to the way they have been generated (manually, scripted or 
automatically).

> Would it be possible to name them
> .ChangeLog-cvs so they hide?
Why? These files are still valid and document RTEMS history.

> :) The -cvs appendage properly captures
> the point of cutting them off. Using dates is not a good idea
> (imprecision).
Why? If your intention is to cut them off to add automatically generated 
ones documenting change since git was introduced, you could do so by 
using git-hashes (or dates).

> If we decide to keep ChangeLogs then we need to figure
> out how to merge new entries into the existing ChangeLog files.
Why? Choose a cut-off git-hash and write a script (Unfortunately there 
is no "git-import/cvs-cutoff tag" in RTEMS git - Somebody will have to 
dig it out).

> If anyone feels strongly about maintaining ChangeLogs they should make
> a cogent argument more than just "because it is GNU style and we have
> always done it this way".
Sure, this is also is an (weak) argument. GCS mandates changelogs 
because the FSF has reasons for mandating them.

#1 reason: Source-(tar)balls need to be selfcontained. This means 
forcing users to dig out change history from VCSs is prohibited, because 
a VCS a project is using might not be available to them.

Ralf



More information about the devel mailing list