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

[Thomas Doerfler]

Ralf,

help me out: Your are using some linux derivatives as primary platform
for the RTEMS tool builds. As far as I can see, the Linux kernel
publishs git-generated changelogs, which is exactly what we discussed
for RTEMS releases.

According to your previous email, this would mark the linux kernel a
non-serious project.

How can you select a non-serious platform as a base for the RTEMS tool
builds?

Thomas.

Am 08.03.2013 23:41, schrieb Ralf Corsepius:
> On 03/07/2013 01:43 AM, Peter Dufault wrote:
>>
>>
>> I'm baffled by this conversation, so help me out.
> 
> I am baffled by Joel's and Gedare's rudities.
> 
>>   I respect Ralf.  His sand-paper presentations on the list have
>> pissed me off more than once,
> Thanks, but ... my feelings on RTEMS currently are not positive. I feel
> the RTEMS project has developed from a serious project into a kids' circus.
> 
>>   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.
> The ChangeLogs have been abandoned since the introduction of git,
> because some people around here believe git has obsoleted the need for
> ChangeLogs.
> These people are wrong - Whether ChangeLogs are considered to be useful
> is a matter of conventions and is independent of VCS.
> 
>>    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,
> The switch to git was not complete - Information was lost.
> 
>> 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?
> Again, the fact any VCS is in use, is completely without important, when
> it comes to releases (tarballs).
> 
> But provided the attitude I am currently experiencing here, we will
> never see any release, because "the sources are in git".
> 
> 
>> I think you should clarify your concerns, because I'm not sure they
>> are addressed by an infrequently updated "Changelog".
> Correct. ChangeLogs need to be updated "in time". That's what most
> serious projects do (e.g. GCC, binutils, gdb, newlib).
> 
> 
>>    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".
> 
> Thanks to the fact the trigger has now pulled, any further discussion
> has become moot.
> 
> *I consider this step to be a serious mistake and to be a serious
> management mistake *
> 
> Therefore, my final last words on this matter:
> * IMO, any project which wants to be taken seriously need to provide
> accurate ChangeLogs. Projects, which don't, can't be taken serious.
> * IMO, persons who claim ChangeLogs are not necessary and are covered by
> VCSes, are trying to hide away their personal lazyness and sloppiness.
> 
> Ralf
> 
> 
> 
> 
> 
> 
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel


-- 
!!!Neue Adresse !!! New address !!!
--------------------------------------------
embedded brains GmbH
Thomas Doerfler
Dornierstr. 4
D-82178 Puchheim
Germany
email: Thomas.Doerfler at embedded-brains.de
Phone: +49-89-18 94 741-12
Fax:   +49-89-18 94 741-09
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.