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.