() Joseph Myers <jos...@codesourcery.com> () 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