
On Thu, Feb 9, 2017 at 10:12 PM, Brett Cannon <brett@python.org> wrote:
On Thu, 9 Feb 2017 at 11:51 Senthil Kumaran <senthil@uthcode.com> wrote:
On Thu, Feb 9, 2017 at 10:43 AM, Nick Coghlan <ncoghlan@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.