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.