[core-workflow] Final chance to express opinion on history rewrite for issue #s

[Ezio Melotti]

On Thu, Feb 9, 2017 at 10:12 PM, Brett Cannon <brett at python.org> wrote:
>
>
> On Thu, 9 Feb 2017 at 11:51 Senthil Kumaran <senthil at uthcode.com> wrote:
>>
>> On Thu, Feb 9, 2017 at 10:43 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> >> If people don't like that idea the appending works for me if it isn't
>> >> difficult for Senthil.
>> >
>> > but I'd still prefer this to not having the modified version at all.
>>
>> It's not difficult and I am open to these suggestions.  I hope we can
>> settle upon something that will serve us well in utility value.
>>
>> If many folks are still apprehensive, not changing is fine with me.
>> It's will be a slight inconvenience with historical commit messages.
>
>
> OK, executive decision: let's test a rewrite but only for things that match
> the regex at the beginning of the commit message (using Senthil's long list
> of possible formats so we get "bpo-NNNN" and not "Issue bpo-NNNN").

If you only match at the beginning, the regex should also includes
keywords like "(fix|clos)(e[sd]).
FWIW the bpo issues are currently in range 1000-29515 (the upper bound
changes as new issues are created) and the old SF issues are in range
207608-1779871.  Both ranges are inclusive, meaning that anything with
 id <1000 or 29515 < id < 207608 or id > 1779871 is not a valid
bpo-issue, anything within those ranges /should/ be a valid bpo issue
(there are a few holes in the bpo range and several in the SF range).

It probably doesn't matter, but the link added at end of HG commits on
hg.p.o was there due to technical problems (trying to linkify the
issue id directly was breaking the HTML formatting in some cases).

I'm +1 on rewriting (in place or at the end are both fine).

@Senthil
Ping me on IRC if you need help putting together a regex that includes
as many cases as possible without including false positives.

> That
> won't have any false-positives and still gets us consistent issue naming for
> the whole repo (at least in the commit summary line, but that will also act
> as a scope to the commit that any ambiguous "#NNNN" numbers apply to bpo).
> If this test doesn't lead to people being happy we will abandon the idea of
> any history rewriting for tomorrow.
>