
On Thu, Aug 6, 2015 at 7:17 PM Nick Coghlan <ncoghlan@gmail.com> wrote:
On 7 August 2015 at 05:46, R. David Murray <rdmurray@bitdance.com> wrote:
On Thu, 06 Aug 2015 18:16:53 -0000, Brett Cannon <bcannon@gmail.com> wrote:
However, having a commit log based generator offers a relatively decent way to deal with that: a Misc/NEWS.overrides directory, with filename prefixes based on the commit hashes to be overridden.
This is making me prefer MAL's #4 solution.
I'm liking this solution as well...there's programming work to be done regardless, and adding a tracker field isn't *that* hard.
However, the problem Nick points out above is really still an issue we ought to address at some point even if we don't take NEWS info from the commit messages, because it would be nice to be able to do some automated checks about the relationships between issues and commits, and to do that we have to have some way to "edit" the commit messages where we specify the wrong issue number.
One of the interesting aspects of Gerrit's workflow is that you get to review the commit message in addition to the change itself, and I think GitHub/BitBucket PRs allow that as well. This means that by the time a change is merged, the correct issue reference will almost always be there.
Yes, they both let you edit the commit message before accepting a PR.
For Beaker, that "the commit message is covered by the review process" aspect let us write https://git.beaker-project.org/cgit/beaker-administrivia/tree/checkbugs.py to audit the Gerrit review state against the corresponding Bugzilla state, and investigate any anomalies to see whether it was the BZ metadata or the Gerrit change proposal commit message that needed updating. (Side note: creating a cpython-administrivia repo for easier discoverability of workflow management utility scripts may not be a bad idea, especially as we start making use of the REST API support being added to Roundup)
In the Roundup+Mercurial case, I think we can deal with this more comprehensively by actually storing our canonical issue->commit reference in *Roundup*, and mentioning an issue number in a commit would just be a way of creating those associations automatically. That way, if we get it wrong at commit time (mentioning the wrong issue, not mentioning an issue at all, creating an issue after we've already done the work), then we can edit the commit associations on the affected issues *in Roundup* to ensure the appropriate change info is reported. If multiple commits were made referencing the same issue, then we'd still only get one news entry for that issue, and if one commit addresses multiple issues, then we'd get multiple news entries (one per issue).
So are you saying you want a field to paste in the commit numbers to do the tracking? I assume you would want commit messages listing an issue to automatically append to that field but have it editable to fix any typos in the commit message.
Since Mercurial associates commits with named branches, this would also mean we'd be able to use the issue->commit tracking to determine where a change had been applied, rather than the existing versions field, so we'd be free to keep using the latter to keep track of branches that still require updating.
Yes, and depending on how fancy we got, we could even decorate the Versions field with some marker to show when a commit had been applied to a branch.