On 7 August 2015 at 05:46, R. David Murray <rdmur...@bitdance.com> wrote: > On Thu, 06 Aug 2015 18:16:53 -0000, Brett Cannon <bcan...@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. 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). 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. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
