Brett Cannon added the comment:

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.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18967>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to