[Python-Dev] Split Misc/NEWS into individual files

Barry Warsaw barry at python.org
Sat Feb 25 17:40:18 EST 2017

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

* 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.


More information about the Python-Dev mailing list