So the `hg commit -l` bit is going to run afoul of the same group of people who didn't like my commit message reuse idea unless you explicitly try to make it very clear that e.g. the first line is for Misc/NEWS and the latter is for the commit. Otherwise we have typically not include the "thanks" bit of a commit in Misc/NEWS which would also water down the `-l` usage. I know it's not critical for this, but I just wouldn't worry about it as a big selling point (unless you get really fancy and let the entries vary and instead of using the file as the input to the commit you write to a temp file or pipe in stdout and use the script to generate both the file and execute the commit with the more thorough message as a separate thing).

BUT if people like the "one entry, one file" approach and seriously using the output for both Misc/NEWS and the commit message then I see the script for generating the entry asking the following questions (which could even use Tkinter =):

* Issue #s
* Did someone else help out with this; allows making sure they were not accidentally left out of Misc/ACKS and add them if necessary or at least that they are mentioned in the commit message
* One line explanation for NEWS
* Optional extra bits to go into the commit message
* Should this go into What's New (e.g. new feature, backwards-compatible breakage); can add a `WN` or `WhatsNew` to the file name or something so that if someone like David tries to update the What's New doc they can tell by the file name that it may be important to cover (and maybe even only add the marker if What's New is NOT edited to know it's more like a TODO item)

Another side-effect of marking entries as worthy of being in What's New is that it should be easy to tell what should potentially be added as an addendum to What's New and to highlight at the end of the doc so that every micro release people can notice what was added. Heck, the logical conclusion is to split up What's New into individual files with a placeholder of the issue that was marked as worthy of inclusion and then edit it before release and auto-generate What's New (but one thing at a time =).

Anyway, ignoring all of this unstructured brain dump of mine, I'm can support doing a separate file approach.