Delete ChangeLog files Was :Re: ChangeLog change to .ChangeLog
Rempel, Cynthia
cynt6007 at vandals.uidaho.edu
Sun Mar 10 02:25:17 UTC 2013
Hi,
It really sounds to me like Dr. Sherrill doesn't want ChangeLogs to be a barrier to committing to RTEMS...
I'm not a lawyer either, but Dr. Sherrill made it clear RTEMS stand on ChangeLogs... RTEMS does belong to OAR, so what OAR wants is what RTEMS should get legally... incidentally, Dr. Sherrill did indicate that quite a few developers agreed with him.
For my own edification I took a quick look at: http://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html
It seemed to indicate that version control was an invaluable legal asset for identifying changes, as well as how commits should be done to meet legal requirements. I'm not advocating either way, but It did mention that ChangeLogs were handy for indexing "significant" commits "should an audit ever be necessary".
I know that some of the students during Google Code-In seemed very interested in licensing/legality, it might be possible to tag which "significant" commits were made, and have the students add to the ChangeLog as a task (or small open project?)... that way developers don't have as many hurdles to jump though and we have a only moderately outdated ChangeLog for indexing purposes.
If this is acceptable/interesting to OAR/RTEMS development community, someone who feels strongly about keeping ChangeLogs could write up the Google Code-In task (or small open project?).
Hope this helps,
Cynthia Rempel
________________________________________
From: rtems-devel-bounces at rtems.org [rtems-devel-bounces at rtems.org] on behalf of Thomas Doerfler [Thomas.Doerfler at embedded-brains.de]
Sent: Saturday, March 09, 2013 12:06 AM
To: rtems-devel at rtems.org
Subject: Re: Delete ChangeLog files Was :Re: ChangeLog change to .ChangeLog
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.
_______________________________________________
rtems-devel mailing list
rtems-devel at rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
More information about the devel
mailing list