From: Luis Machado <luis.machado@linaro.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: simon.marchi@polymtl.ca, gdb@sourceware.org, vapier@gentoo.org
Subject: Re: sim: replacing ChangeLog files with online git logs
Date: Wed, 17 Mar 2021 17:53:12 -0300 [thread overview]
Message-ID: <1f8b7494-0c23-14ed-0096-ad0768663f1a@linaro.org> (raw)
In-Reply-To: <83ft0td5ve.fsf@gnu.org>
On 3/17/21 2:53 PM, Eli Zaretskii wrote:
>> Cc: gdb@sourceware.org, Mike Frysinger <vapier@gentoo.org>
>> From: Luis Machado <luis.machado@linaro.org>
>> 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.
next prev parent reply other threads:[~2021-03-17 20:53 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-13 2:53 Mike Frysinger
2021-03-13 7:30 ` Eli Zaretskii
2021-03-13 15:12 ` Mike Frysinger
2021-03-13 16:02 ` Eli Zaretskii
2021-03-13 16:26 ` Mike Frysinger
2021-03-13 16:38 ` Eli Zaretskii
2021-03-13 18:21 ` Mike Frysinger
2021-03-13 18:32 ` Eli Zaretskii
2021-03-17 6:07 ` Mike Frysinger
2021-03-17 13:14 ` Eli Zaretskii
2021-03-17 14:31 ` Luis Machado
2021-03-17 14:47 ` Eli Zaretskii
2021-03-17 14:52 ` Luis Machado
2021-03-17 15:09 ` Eli Zaretskii
2021-03-17 15:22 ` Luis Machado
2021-03-17 15:40 ` Eli Zaretskii
2021-03-17 15:52 ` Simon Marchi
2021-03-17 16:09 ` Eli Zaretskii
2021-03-17 17:24 ` Luis Machado
2021-03-17 17:53 ` Eli Zaretskii
2021-03-17 20:53 ` Luis Machado [this message]
2021-03-18 9:31 ` Andrew Burgess
2021-03-18 9:48 ` Eli Zaretskii
2021-03-22 2:19 ` Maciej W. Rozycki
2021-03-22 3:38 ` Eli Zaretskii
2021-03-23 4:57 ` Mike Frysinger
2021-03-23 5:05 ` Mike Frysinger
2021-03-23 11:06 ` Andrew Burgess
2021-03-24 3:45 ` Mike Frysinger
2021-03-24 16:46 ` Eli Zaretskii
2021-03-24 16:59 ` Andrew Burgess
2021-03-24 17:39 ` Eli Zaretskii
2021-03-24 18:44 ` Mike Frysinger
2021-03-31 2:27 ` Mike Frysinger
2021-03-31 3:27 ` Joel Brobecker
2021-03-31 11:35 ` Luis Machado
2021-03-31 15:29 ` Joel Brobecker
2021-04-01 3:41 ` Mike Frysinger
2021-04-19 0:52 ` Mike Frysinger
2021-04-19 2:32 ` Joel Brobecker
2021-04-19 4:31 ` Mike Frysinger
2021-04-19 5:00 ` Joel Brobecker
2021-05-23 3:26 ` Mike Frysinger
2021-06-10 12:11 ` Luis Machado
2021-03-13 18:34 ` Paul Smith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1f8b7494-0c23-14ed-0096-ad0768663f1a@linaro.org \
--to=luis.machado@linaro.org \
--cc=eliz@gnu.org \
--cc=gdb@sourceware.org \
--cc=simon.marchi@polymtl.ca \
--cc=vapier@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).