[rtems commit] 2011-03-02 Ralf Cors épius <ralf.corsepius at rtems.org>

[Ralf Corsepius]

On 03/02/2012 08:51 PM, Thomas Doerfler wrote:
> Am 02.03.2012 19:12, schrieb Ralf Corsepius:
>> On 03/02/2012 06:22 PM, Gedare Bloom wrote:
>>> Please provide useful shortlog messages so that your commits do not
>>> all look the same when viewed through the vc-list or git log and
>>> related tools.
>> Again, fix your crappy script!
>>
>>> If you feel compelled to include a ChangeLog in your
>>> commit message that is fine as long as a useful shortlog appears
>>> first.
>>
>> I do not intend to diverge a mu from what is established practice in
>> GCC, binutils, newlib and what has been extabished practice in RTEMS for
>> ca. 15 year.
>>
>> No regards,
>>      Ralf
>
> Ralf,
>
> RTEMS is a ather slow moving project.
Well, I don't see this. It's moving at the usual speed of "non-toy 
projects".

> Anyway if we stay in a tool
> environment and a colaboration model that has been define d15 years ago,
> we will be frozen and nonfuctional soon.
WTH does a tool which generates "shortlogs", which some people consider 
to be unreadable, to do with a project's progress?

The "Deluxe Loginfo"-generated "shortlogs" from CVS were plain dates".
...
change log for rtems (2011-12-09)
change log for rtems (2011-12-10)
...
Was this better readable? No, they weren't!


git's shotlogs are simply the first line of a changelog text block.
...
[rtems commit] Use alternative API
[rtems commit] Remove (Obsolete).
...
Are these better readable than the deluxe-loginfo shortlogs?
No, they aren't and never will be!

> There had been many changes in the past, some of them requiring a
> different way to use RTEMS and interact with the community.  Therefore I
> don't understand your attitude to simply ignore the changes that the
> majority of the RTEMS community appreciates.

Because I feel "this majority" is making noise about nothing ... these 
shortlogs do not cause any malfunctions and are not better readable.

Conversely, these shortlogs are just a symptom of me keeping the VCS's 
internal changelog entries in consistent and readable form.

That said, I consider people having commited changes to RTEMS without 
ChangeLog-file changes to be sloppy quality of works. Openly said, if I 
had to decide, I would insist on them being reverted and resubmitted, 
because these changes are causing massive usabilty regressions.

> I remember situations where patches coming from me or my colleagues have
> been rejected by you, because they did not conform to the formalites ad
> requirements defined by the community.
Yes, and the problem is? It's in the nature of reviews of also 
occasionally having to reject some things.
It's the difference between "one-man show/toy-projects" and real-projects.

> Can you please explain why you now take the right to commit
> non-conforming patches and instead insult other people?
I do not see I insulted Gedare. I feel his remarks originate from 
inexperience of lack of understanding of the importance of 
ChangeLog-files and of a VCS's internal ChangeLogs.

Ralf