Re: sim: replacing ChangeLog files with online git logs

On 3/17/21 2:53 PM, Eli Zaretskii wrote:
>> Cc: [email protected], Mike Frysinger <[email protected]>
>> From: Luis Machado <[email protected]>
>> Date: Wed, 17 Mar 2021 14:24:27 -0300
>>
>>> Well, if that's what the majority here wants, then so be it.
>>
>> That's what we should assess. From chatting with other active GDB
>> developers, my feeling is that most of us want to drop the process of
>> having to write ChangeLog entries manually. But we tend to keep quiet
>> and carry on doing it.
> 
> I didn't start this discussion, mind you.
> 

I know. But this has been bothering contributors for a few years now.

I don't want to hijack the sim/ChangeLog thread, but it feels important 
to improve this situation in some way. Given sim/ is under GDB's 
umbrella, might as well consider the whole project in my opinion.

>>> (The importance of having the list of modified symbols in the log is
>>> that then one doesn't need advanced Git commands to find out which
>>> changes modified a given function and why.)
>>>
>>
>> I understand the concern about git. I used to find git a bit too cryptic
>> too, but using it daily has made that better.
>>
>> Now git log/git blame shows very useful information when I'm looking for
>> specific changes from a commit, and I rarely need to go through
>> ChangeLogs other than to find commits that touched a particular
>> function/variable.
> 
> IME "git log" and "git blame" have shortcomings when used for
> forensics, and having a ChangeLog-style list of changes helps overcome
> that in many important use cases.
> 

Right. That's true. Both have their pros and cons. But the git commands, 
IMO, demand no extra time from developers. ChangeLog's, on the other 
hand, do.

A contributor's time spent on the project is a limited and valuable 
resource. Making the best use of that resource is important.

>>>> I tried vcs-to-changelog, it gave horrible/useless results with our
>>>> codebase.  This is not an option.
>>>
>>> Too bad.  Maybe we should report this to the developer of the script,
>>> it could help fix those shortcomings in the future.
>>>
>>
>> Maybe. But looking into the future, parsing C++ to extract that kind of
>> information is really not trivial. So it may never work in a reasonable
>> way for GDB without some serious effort put into the script.
> 
> We don't need it to do a perfect job, only a reasonable one.  A 80%
> success is a very big step forward wrt not having the information at
> all.
> 

Sounds reasonable. But for contributors not seeing value in ChangeLog 
entries, it is hard to justify putting effort/time into such a script.

But I agree it would be nice to have improvements to a script/tool like 
that. It might make sense for someone who sees value in such data to 
invest some time improving its generation.