Nick Coghlan added the comment: 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. ---------- _______________________________________ 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
