This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients brett.cannon, dstufft, ezio.melotti, georg.brandl, larry, lemburg, ncoghlan, pitrou, r.david.murray, sbt, terry.reedy, tshepang, zach.ware
Date 2015-09-26.23:36:01
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Just noting a potential practical benefit of the "NEWS entry first" approach that David suggests: I believe it will help encourage the creation of a succinct answer to "Why are we making this change?" as part of the patch review process.

That's then useful both during the patch review itself (since there's a shared understanding between reviewers and implementors of the goal to be achieved), as well as when the change is released (since there's hopefully a user centric explanation of *why* something changed, rather than merely *what* changed)

However, the key trap I'd like us to avoid falling into is letting the fact a particular approach falls short of our ideal approach deter the introduction of interim improvements. We're going to need the checked in filesystem database anyway to backfill historical NEWS entries after switching to a generated NEWS file, so it seems harmless to me to switch to it early and then incrementally add to it until a tracker based solution is available.
Date User Action Args
2015-09-26 23:36:02ncoghlansetrecipients: + ncoghlan, lemburg, brett.cannon, georg.brandl, terry.reedy, pitrou, larry, ezio.melotti, r.david.murray, tshepang, sbt, zach.ware, dstufft
2015-09-26 23:36:02ncoghlansetmessageid: <>
2015-09-26 23:36:02ncoghlanlinkissue18967 messages
2015-09-26 23:36:01ncoghlancreate