[core-workflow] the Misc/NEWS problem

[Nick Coghlan]

On 8 August 2015 at 08:25, Brett Cannon <bcannon at gmail.com> wrote:
> On Thu, Aug 6, 2015 at 7:17 PM Nick Coghlan <ncoghlan at gmail.com> wrote:
>> 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.

Yep, exactly. Longer term, once we have a repo hosting solution that
*also* has a REST API, then the UX could be updated to better
integrate the two (e.g. displaying the summary line from the commit in
the Roundup UI, display the titles of all linked issues in the repo
hosting UI), but the simplest possible way to get started is with a
free text comma separated field (akin to the nosy list, dependency and
superceder fields) that we can audit with an offline script and set
from the existing Roundup notification commit hook.

>> 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.

I was more thinking in terms of listing the branches against the
displayed commits, but yeah, marking up the versions field might be a
nice way to go, too.

In my "Can I have a pony?" moments, I start wondering how we might be
able to work https://taiga.io/ into the mix to help coordinate more
complex activities (like the release process, or some of our
infrastructure updates). Fedora now have an instance of that up at
http://taiga.cloud.fedoraproject.org/ (that instance requires a Fedora
account to log in, but those are freely available:
https://admin.fedoraproject.org/accounts/user/new).

Baby steps, though, baby steps... :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia