We have all been there: you fix something in some maintenance branch, do your hg pull into the default branch, and everything *but* Misc/NEWS merges cleanly. You typically revert Misc/NEWS, commit your forward-ported change to default, and then move on with your life. It would be much easier if Misc/NEWS was never an issue.

In preparation for choosing a workflow that allows us to do patch/PR merging through the browser, we have been thinking about this Misc/NEWS "problem". The solution we came up with was to put the changelog message in Roundup. The idea is that Roundup grows a changelog field to enter a changelog messge and a comma-separated list of commit revisions pertaining to the issue. We continue to do commit messages as we do, but when Roundup adds the commit message to the issue it will also append the revision number to the revision(s) field. Any relevant changelog entry for an issue will be added to the issue itself -- by hand to start, we can talk about automation later -- and not a file that could have merge conflicts. When it comes time to cut a release we will have a tool that will go through Roundup, collect all the relevant issues for the release, and create the changelog file based on what is in Roundup.

This will buy us several things. One is no more merge conflicts for Misc/NEWS since it won't exist as-is (we might have the release manager check in a generated file per version, but that can be discussed later). Two is no more extra commits to add a missing changelog entry in Misc/NEWS since you just need to update the issue in Roundup instead. Three is it should lead to a more rich changelog as we will have the issue # and all related commits tied to the changelog message itself, so they can contain whatever backlinks we want in the changelog.

The only potential downside is any change warranting a changelog entry will now also require an issue. Now I personally think -- and others on the core-workflow list seem to agree -- this is actually a good thing to help track changes that are made and tie all relevant information together from across the issue tracker and code repo. Basically if something is important enough to be listed in the changelog it should be important enough to have an issue tracking it (we could even require the changelog entry be filled in before you're allowed to set an issue to "fixed").

The whole point of this email is to let everyone know that this is the plan and should be coming in a couple of months (I'm also hoping to make a decision about a new overall workflow by 2016, but I need to hear back from Donald first about whether the proposed timeline for a test instance will work for him). If you hate this idea so much that it will cause you to stop contributing to Python then let me know, otherwise I'm going to assume people are either happy with this approach or will begrudgingly accept it.