Re: [core-workflow] the Misc/NEWS problem

On 8 August 2015 at 08:25, Brett Cannon wrote:

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