On Thu, Aug 6, 2015 at 7:17 PM Nick Coghlan <ncogh...@gmail.com> wrote:
> 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. > 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.
_______________________________________________ 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
