[core-workflow] Choosing a prefix/label for issue numbers

[Maciej Szulik]

On Thu, Feb 2, 2017 at 2:13 AM, Alexander Belopolsky <
alexander.belopolsky at gmail.com> wrote:

>
> On Wed, Feb 1, 2017 at 7:51 PM, Brett Cannon <brett at python.org> wrote:
>
>> as the match should be probably s/issue #(\d+)/bpo-\1/ and it shows how
>> easy it is to miss edge cases.
>
>
> No, I deliberately omitted the "issue" part because AFAIK things like
> "Closes #NNNN" are valid references.  I don't mind seeing "issue bpo-NNNN",
> but wouldn't want to complicate the logic by worrying about "issue" vs.
> "Issue" and other possible variants.
>

Issue vs issues is not a problem since we're ignoring case in most of the
code dealing with those, already.


Personally I'd vote to bpo, but I'm biased about it, since it's the one
coming from gh migration ;)

> How hard would it be to s/#(\d+)/bpo-\1/ the commit messages during hg to
git conversion?  I did something like that in the past when I converted an
svn-based project to git.

> That's a question for Senthil, but I would be a little worried about
editing the history as the match should be probably s/issue #(\d+)/bpo-\1/
and it shows how easy it is to miss edge cases.

Hmm... for all the #NNN in commits we'll get quite a few false links in
github, so maybe removing the # would
be valuable, or replacing it with issue/bpo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20170202/dfaaf4dd/attachment.html>