On Feb 24, 2017, at 11:40 PM, Larry Hastings wrote:
I'm for it too. Fixing up Misc/NEWS is probably the trickiest and most error-prone part of cutting a release.
Not to mention cherry picking for older releases.
While I'm sure we can learn a lot by examining "reno", my suspicion is we'll want our own custom tool. I don't think the hard part is writing the tool--the hard part is figuring out what we want and how it should be integrated into our workflow. Actually writing such a tool is easy and fun, and I'm sure our community would fall all over themselves to write it if asked. In fact, I'll kind of pre-volunteer to write it right now, as long as I can write it in Python 3 ;-)
What else would you write it in?! :) Let's start with a simple question: do we like the general layout of the existing Misc/NEWS file? I do, and I *really* like it containing issue numbers, because that makes it relatively easy to search to see if a particular bug was fixed in a particular version (which is also why I wish all pull requests were tied to a bug). Other things I like about the file: * It's easy to search for a particular Python release, just by searching for "What's New". * I like having a release date easily visible with the Python version heading. * I like the bullet list format of the file, and I like the alphabetized category headings. What I don't like: * Lines that are too long ;) * All the inherent conflicts in editing a single file. * Misc/NEWS (on master) doesn't go back farther than 2 Python versions and 2 years, so it's harder to search for earlier changes. * It's in Misc/ not Doc/ Can we agree then that Misc/NEWS is the target output format for this tool? Maybe it's not the *only* target output format? Now, what's the input? The other thing is that I'm not sure design-by-committee is going to work so well here. There are several competing interests here. Release managers, non-core devs (drive-by contributors needing sponsorship), core devs (back porting/cherry picking changes), downstream consumers. Cheers, -Barry