[core-workflow] the Misc/NEWS problem

[Brett Cannon]

On Thu, Aug 6, 2015 at 7:17 PM Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 7 August 2015 at 05:46, R. David Murray <rdmurray at bitdance.com> wrote:
> > On Thu, 06 Aug 2015 18:16:53 -0000, Brett Cannon <bcannon at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20150807/6e452e76/attachment.html>