Commit messages

[Gedare Bloom]

On Tue, Feb 21, 2012 at 1:11 PM, Ralf Corsepius
<ralf.corsepius at rtems.org> 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? So I don't see a need to have any redundant versioning
information. Maybe I missed something.

>>> + 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.

>> 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. For users trying to find what changed during the
4.11 release cycle, however, it will complicate matters.

>>>    - 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 configure.ac
>> seems artifical to me either.
>
>
> Again, no. Each configure.ac 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? Do we really need
ChangeLogs in (just to pick one) ./doc/tools/bmenu/?

You deleted what Thomas said about placing the ChangeLog files, which
includes per-BSP. Here I will reprint it and add a few more:
- rtems/
- rtems/c/src/lib/libbsp/
- rtems/c/src/lib/libbsp/<arch>/<bsp>/
- rtems/c/src/lib/libcpu/<arch>
- rtems/c/src/libchip/
- rtems/cpukit/
- rtems/testsuites/
AND
- rtems/cpukit/score/cpu/<arch>/
- rtems/c/src/lib/libcpu
- rtems/c/src/
- rtems/doc
- rtems/tools

> Ralf
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel