() Joseph Myers <[email protected]> () Wed, 9 May 2018 12:37:37 +0000
I just don't think it actually helps the community to have
such a program, or that people would want to use it.
That could be said (truthfully, even) of any tool. I think the
way to move this discussion forward is to look at things as a
simple Venn diagram:
;; ┌───────────────┐
;; │ │
;; │ A ┌───────┼──┐
;; │ │ │ │
;; │ │ B │ │
;; │ │ │ │
;; └───────┼───────┘ │
;; │ │
;; │ C │
;; │ │
;; └──────────┘
Area A is what Git provides, and what those preferring Git as
their Powertool-of-Choice turn to, for all things related to the
history of source code.
Area C is what the ChangeLog format "requires" (informally, and
mostly by unenforced convention), comprising 0*title; 0*paras;
1+"changed-entities". The latter is the historical core; the
first two components are additive evolution to reflect
contemporary practice.
Area B is what Git provides that fulfills the ChangeLog format
"requirements": 0*title; 0*paras; possibility of a heuristic
approximation of "changed-entities" (requires manual futzing).
Some people wish the ChangeLog format to evolve further, by
dropping 1+"changed-entities". In that case, C is the same as
B, and so A, being a proper superset of B, satisfies C, too.
My understanding is that RMS is open to evolution of the
ChangeLog format, but only if it is non-subtractive. (FWIW,
this is my personal stance, too, so i may be projecting here.)
IOW, 1+"changed-entities" SHOULD NOT be dropped. He suggests
writing a tool to refine the crude heuristic approximation, so
that the changed-entities that the ChangeLog format "requires"
can be completely automagically generated.
This tool need not be Git-specific, although seeing how the
preponderance of hackers these days groove w/ Git, i'm pretty
sure it would start w/ strong Git support.
Once such a tool is written, the people who want to drop
1+"changed-entities" might do so anyway, or they might use
the tool (since it's completely automagic) in their script
to generate ChangeLog files at release time. Still their
choice, but if it's a simple matter, and makes GNU happy,
why not?
Anyway, that's the way i see it. ISTM the resolution is clear:
find a hacker who will write and maintain this tool. I think
most involved in this discussion are capable, but understand how
IRL concerns may deter volunteering.
Perhaps someone who is not so sure about capability, but w/
time, energy, and willingness to try anyway, w/ a bit of help,
will step forward. I think the tool has great merit, when i
think of non-programmers gazing out from the swamp of ignorance
that mires them.
--
Thien-Thi Nguyen -----------------------------------------------
(defun responsep (query)
(pcase (context query)
(`(technical ,ml) (correctp ml))
...)) 748E A0E8 1CB8 A748 9BFA
--------------------------------------- 6CE4 6703 2224 4C80 7502
signature.asc
Description: PGP signature
