[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is it time to drop ChangeLogs?
From: |
Ted Zlatanov |
Subject: |
Re: Is it time to drop ChangeLogs? |
Date: |
Sat, 09 Jul 2016 18:55:52 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) |
On Sat, 09 Jul 2016 12:54:48 -0400 Richard Stallman <address@hidden> wrote:
>> This can easily be encoded in a database table so it's searchable,
>> indexed by symbol name or file name (to build a history), etc. as part
>> of the pull request system. It can be semi-automatic: the system figures
>> out the file and symbol changes, then the developer adds the rest (and
>> the review doesn't end until this is done).
RS> Given a program that can determine which function or entity name
RS> to associate with each line, it would not be hard to make a list of
RS> which entities are changed in a given patch.
RS> Do we have such a program? I don't know that we do.
RS> However, determining what kind of change was made to a certain entity
RS> in a certain patch is much harder. Consider this:
RS> * file.c (create_swimming_pool): New function
RS> (modernize_building): Call it.
RS> How would a program decide whether "Call it." is enough to say about
RS> the change in modernize_building, or whether it is necessary to say
RS> more?
You're right, of course. But I wasn't saying the program would do the
entire job. It will know *what* has changed and provide a place to enter
the *why* messages. Then the code reviewer will require those messages
before approving the merge. That's essentially what ChangeLogs do, but
this will be in a structured format so it's easier to index and analyze
the data.
A good first iteration of this would be a mechanism to generate the
structured data from a patch/diff, which would then hook into the
current mechanism to generate ChangeLog-style entries in the commit
message. (Currently this is a mostly manual process, I believe.)
That would benefit everyone right away by speeding up the ChangeLog
format generation, and can then be used for the more elaborate system
when and if we decide.
Ted
- Re: Is it time to drop ChangeLogs?, (continued)
- Re: Is it time to drop ChangeLogs?, Ted Zlatanov, 2016/07/08
- Re: Is it time to drop ChangeLogs?, Eli Zaretskii, 2016/07/08
- Re: Is it time to drop ChangeLogs?, Ted Zlatanov, 2016/07/08
- Re: Is it time to drop ChangeLogs?, Eli Zaretskii, 2016/07/08
- Re: Is it time to drop ChangeLogs?, Ted Zlatanov, 2016/07/08
- Re: Is it time to drop ChangeLogs?, Óscar Fuentes, 2016/07/08
- Re: Is it time to drop ChangeLogs?, Óscar Fuentes, 2016/07/08
- Re: Is it time to drop ChangeLogs?, Eli Zaretskii, 2016/07/08
- Re: Is it time to drop ChangeLogs?, Richard Stallman, 2016/07/09
- Re: Is it time to drop ChangeLogs?, Eli Zaretskii, 2016/07/09
- Re: Is it time to drop ChangeLogs?,
Ted Zlatanov <=
- Re: Is it time to drop ChangeLogs?, Richard Stallman, 2016/07/10
- auto-generating skeleton ChangeLogs (was: Is it time to drop ChangeLogs?), Ted Zlatanov, 2016/07/11
- Re: auto-generating skeleton ChangeLogs, Ted Zlatanov, 2016/07/12
- Re: auto-generating skeleton ChangeLogs, Stefan Monnier, 2016/07/12
- Re: Is it time to drop ChangeLogs?, Phillip Lord, 2016/07/11
- Re: Is it time to drop ChangeLogs?, Richard Stallman, 2016/07/12
- debbugs tracker builds character (was: Is it time to drop ChangeLogs?), Ted Zlatanov, 2016/07/20
- Re: debbugs tracker builds character, Lars Ingebrigtsen, 2016/07/20
- Re: debbugs tracker builds character, Dmitry Gutov, 2016/07/20
- Re: debbugs tracker builds character, Michael Albinus, 2016/07/20