Re: Using VC for change descriptions

[Thien-Thi Nguyen]

() Joseph Myers <address@hidden>
() 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