Mailman 3 Final chance to express opinion on history rewrite for issue #s - core-workflow

Final chance to express opinion on history rewrite for issue #s

older
Choosing a prefix/label for issue...

Brett Cannon

9 Feb 2017 9 Feb '17

12:37 p.m.

+1: Nick, Senthil, Chris +0: ... -0: Martin, Brett -1: Naoki, Berker (Maciej was positive but didn't say +1 or +0; Martin said -0.5 which isn't a valid vote, so I rounded up for him; I'm personally on the fence so voting conservatively now but can switch that view) If you have an opinion please express them now so Senthil has a chance to test this today before we do the official move tomorrow. Otherwise Senthil and I will make the final decision ourselves.

Attachments:

attachment.html (text/html — 580 bytes)

Show replies by date

Zachary Ware

9 Feb 9 Feb

12:42 p.m.

On Thu, Feb 9, 2017 at 11:37 AM, Brett Cannon wrote:

...

+1: Nick, Senthil, Chris +0: ... -0: Martin, Brett -1: Naoki, Berker

Since we don't get clickable links any way about it, -1 on rewriting commit messages. Too easy to accidentally mess things up for no real benefit. -- Zach

Nick Coghlan

12:52 p.m.

On 9 February 2017 at 18:42, Zachary Ware wrote:

...

On Thu, Feb 9, 2017 at 11:37 AM, Brett Cannon wrote:

...
+1: Nick, Senthil, Chris +0: ... -0: Martin, Brett -1: Naoki, Berker

Since we don't get clickable links any way about it, -1 on rewriting commit messages. Too easy to accidentally mess things up for no real benefit.

Rewriting the history means we *do* get clickable links for anyone that wants them, as a distinctive string like "bpo-12345" is amenable to automated conversion into a hyperlink via a client side script in GreaseMonkey or similar. You can't readily do that with "#12345" or even "Issue #12345" because they're too generic. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Zachary Ware

12:59 p.m.

On Thu, Feb 9, 2017 at 11:52 AM, Nick Coghlan wrote:

...

On 9 February 2017 at 18:42, Zachary Ware wrote:

...
On Thu, Feb 9, 2017 at 11:37 AM, Brett Cannon wrote:

...
+1: Nick, Senthil, Chris +0: ... -0: Martin, Brett -1: Naoki, Berker

Since we don't get clickable links any way about it, -1 on rewriting commit messages. Too easy to accidentally mess things up for no real benefit.

Rewriting the history means we *do* get clickable links for anyone that wants them, as a distinctive string like "bpo-12345" is amenable to automated conversion into a hyperlink via a client side script in GreaseMonkey or similar.

You can't readily do that with "#12345" or even "Issue #12345" because they're too generic.

I don't see how we can say they're too generic for a GreaseMonkey script to match, but not for rewriting history. An option that I would be less against would be to, instead of rewriting the actual message, tack '\n\n[bpo-12345]' onto the end of the message. At least that way any misfires would be non-destructive. -- Zach

Nick Coghlan

1:14 p.m.

On 9 February 2017 at 18:59, Zachary Ware wrote:

...

On Thu, Feb 9, 2017 at 11:52 AM, Nick Coghlan wrote:

...
You can't readily do that with "#12345" or even "Issue #12345" because they're too generic.

I don't see how we can say they're too generic for a GreaseMonkey script to match, but not for rewriting history.

Rewriting the history has a lot more context: Senthil *knows* that his script is reading CPython commit messages. Without the more specific prefix, a GreasemonkeyScript would need to be configured to only run on relevant URLs, which is definitely possible, but would be pretty annoying to set up.

...

An option that I would be less against would be to, instead of rewriting the actual message, tack '\n\n[bpo-12345]' onto the end of the message. At least that way any misfires would be non-destructive.

That's actually the way hg.python.org injects the links now: https://hg.python.org/cpython/rev/b07d454e45a2 So +1 from me for appending the references to the old messages rather than modifying them in place. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Brett Cannon

1:35 p.m.

On Thu, 9 Feb 2017 at 10:15 Nick Coghlan wrote:

...

On 9 February 2017 at 18:59, Zachary Ware wrote:

...
On Thu, Feb 9, 2017 at 11:52 AM, Nick Coghlan wrote:

...
You can't readily do that with "#12345" or even "Issue #12345" because they're too generic.

I don't see how we can say they're too generic for a GreaseMonkey script to match, but not for rewriting history.

Rewriting the history has a lot more context: Senthil *knows* that his script is reading CPython commit messages.

Without the more specific prefix, a GreasemonkeyScript would need to be configured to only run on relevant URLs, which is definitely possible, but would be pretty annoying to set up.

...
An option that I would be less against would be to, instead of rewriting the actual message, tack '\n\n[bpo-12345]' onto the end of the message. At least that way any misfires would be non-destructive.

That's actually the way hg.python.org injects the links now: https://hg.python.org/cpython/rev/b07d454e45a2

So +1 from me for appending the references to the old messages rather than modifying them in place.

What if we only did it for the beginning of the first line of the commit message and not the whole body? Senthil had a list in one of his emails of all the possible formats and if they were all anchored with "^" in the regex then the chance of a false-positive is essentially 0. That would give us the equivalent of what we have on hg.python.org but in-place and alleviates any worry of GitHub changing how they do things in the future (at least in terms of the line you see in log output). If people don't like that idea the appending works for me if it isn't difficult for Senthil.

Nick Coghlan

1:43 p.m.

On 9 February 2017 at 19:35, Brett Cannon wrote:

...

On Thu, 9 Feb 2017 at 10:15 Nick Coghlan wrote:

...
That's actually the way hg.python.org injects the links now: https://hg.python.org/cpython/rev/b07d454e45a2

So +1 from me for appending the references to the old messages rather than modifying them in place.

What if we only did it for the beginning of the first line of the commit message and not the whole body? Senthil had a list in one of his emails of all the possible formats and if they were all anchored with "^" in the regex then the chance of a false-positive is essentially 0. That would give us the equivalent of what we have on hg.python.org but in-place and alleviates any worry of GitHub changing how they do things in the future (at least in terms of the line you see in log output).

Oh, nice idea. +1 for that approach from me, since it gives the hyperlinkable version even in the commit summary

...

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. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Senthil Kumaran

2:51 p.m.

On Thu, Feb 9, 2017 at 10:43 AM, Nick Coghlan 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. -- Senthil

Brett Cannon

3:12 p.m.

On Thu, 9 Feb 2017 at 11:51 Senthil Kumaran wrote:

...

On Thu, Feb 9, 2017 at 10:43 AM, Nick Coghlan 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"). 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.

Ezio Melotti

4:12 p.m.

On Thu, Feb 9, 2017 at 10:12 PM, Brett Cannon wrote:

...

On Thu, 9 Feb 2017 at 11:51 Senthil Kumaran wrote:

...
On Thu, Feb 9, 2017 at 10:43 AM, Nick Coghlan 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.

Eric Snow

4:29 p.m.

On Thu, Feb 9, 2017 at 1:12 PM, Brett Cannon wrote:

...

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

I'm +1 to this approach. The key thing for me is that we can't go back and do this later, so it's better to play it safe and do the rewrite to bpo-##### as described. I can *imagine* scenarios where we would wish we had re-written the commit messages, but at the point where we will be confident it's a good idea it will already be too later. -eric

Zachary Ware

5:20 p.m.

On Thu, Feb 9, 2017 at 2:12 PM, Brett Cannon wrote:

...

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

Note that matching only the beginning of the message will miss several recent commits like: https://hg.python.org/cpython/rev/7b8df4a5d81d https://hg.python.org/cpython/rev/31342913fb1e https://hg.python.org/cpython/rev/37705f89c72b There is also the issue of multiple issue numbers in a message: https://hg.python.org/cpython/rev/a5538734cc87 https://hg.python.org/cpython/rev/ffc0840762e4 -- Zach

Brett Cannon

5:45 p.m.

On Thu, 9 Feb 2017 at 14:20 Zachary Ware wrote:

...

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

On Thu, Feb 9, 2017 at 2:12 PM, Brett Cannon wrote: list

...
of possible formats so we get "bpo-NNNN" and not "Issue bpo-NNNN"). 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.

Note that matching only the beginning of the message will miss several recent commits like:

https://hg.python.org/cpython/rev/7b8df4a5d81d https://hg.python.org/cpython/rev/31342913fb1e https://hg.python.org/cpython/rev/37705f89c72b

Beginning of line would catch these, so using re.MULTILINE would cover those.

...

There is also the issue of multiple issue numbers in a message:

https://hg.python.org/cpython/rev/a5538734cc87 https://hg.python.org/cpython/rev/ffc0840762e4

Yep, this will never be perfect, hence it's either best-effort or we simply don't do it.

Ezio Melotti

5:49 p.m.

On Fri, Feb 10, 2017 at 12:45 AM, Brett Cannon wrote:

...

On Thu, 9 Feb 2017 at 14:20 Zachary Ware wrote:

...
On Thu, Feb 9, 2017 at 2:12 PM, Brett Cannon wrote:

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

Note that matching only the beginning of the message will miss several recent commits like:

https://hg.python.org/cpython/rev/7b8df4a5d81d https://hg.python.org/cpython/rev/31342913fb1e https://hg.python.org/cpython/rev/37705f89c72b

Beginning of line would catch these, so using re.MULTILINE would cover those.

...
There is also the issue of multiple issue numbers in a message:

https://hg.python.org/cpython/rev/a5538734cc87 https://hg.python.org/cpython/rev/ffc0840762e4

Yep, this will never be perfect, hence it's either best-effort or we simply don't do it.

I'm working with Senthil on it. We don't think it's necessary to limit it to the beginning of the line. Thanks for test cases Zach!

INADA Naoki

7:04 p.m.

On Fri, Feb 10, 2017 at 2:59 AM, Zachary Ware wrote:

...

On Thu, Feb 9, 2017 at 11:52 AM, Nick Coghlan wrote:

...
On 9 February 2017 at 18:42, Zachary Ware wrote:

...
On Thu, Feb 9, 2017 at 11:37 AM, Brett Cannon wrote:

...
+1: Nick, Senthil, Chris +0: ... -0: Martin, Brett -1: Naoki, Berker

...

An option that I would be less against would be to, instead of rewriting the actual message, tack '\n\n[bpo-12345]' onto the end of the message. At least that way any misfires would be non-destructive.

While I was -1 on rewriting, -0 for this approach.

Senthil Kumaran

1:03 p.m.

On Thu, Feb 9, 2017 at 9:42 AM, Zachary Ware wrote:

...

Too easy to accidentally mess things up for no real benefit.

Not to sway Zachary's vote. To address the above concern for everyone, the change is restricted only to commit messages and should not effect anything else: https://bitbucket.org/orsenthil/hg-git/commits/75408e7efdbc73a4da435080f23fb... * The worst you can get is few false positives. * There are advantages in rewriting the commit message content to suit our new VCS, and that's reason for this discussion. * Finally, we have already tested this once and gathered feedback. We should be testing our final plan one more time before we go for real.

M.-A. Lemburg

1:09 p.m.

On 09.02.2017 18:42, Zachary Ware wrote:

...

On Thu, Feb 9, 2017 at 11:37 AM, Brett Cannon wrote:

...
+1: Nick, Senthil, Chris +0: ... -0: Martin, Brett -1: Naoki, Berker

Since we don't get clickable links any way about it, -1 on rewriting commit messages. Too easy to accidentally mess things up for no real benefit.

Agreed. -1 as well. Github may support configuring link REs at some point, so we may then configure things to suit our needs as necessary in the future. Without working links, the rewrite isn't all that useful. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Feb 09 2017)

...

...
...
Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/

::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/

Alexander Belopolsky

1:19 p.m.

On Thu, Feb 9, 2017 at 12:42 PM, Zachary Ware wrote:

...

Since we don't get clickable links any way about it, -1 on rewriting commit messages.

While the default github web interface will not give you clickable links right away, there are plenty of tools that that will. For example, PyCharm allows one to specify an arbitrary regular expression to transform issue labels to tracker links. I would not be surprised that given enough demand github will implement a similar feature.

Alexander Belopolsky

1:14 p.m.

On Thu, Feb 9, 2017 at 12:37 PM, Brett Cannon wrote:

...

+1: Nick, Senthil, Chris +0: ... -0: Martin, Brett -1: Naoki, Berker

+1 BTW, not directly related to the issue at hand, but # is a really bad choice for the issue markup because messages with lines that start with # cannot be edited by the standard git tools that remove such lines.

Yury Selivanov

5:53 p.m.

If it's not too late my opinion is `-1`. I agree with MAL. Yury On 2017-02-09 12:37 PM, Brett Cannon wrote:

...

+1: Nick, Senthil, Chris +0: ... -0: Martin, Brett -1: Naoki, Berker

(Maciej was positive but didn't say +1 or +0; Martin said -0.5 which isn't a valid vote, so I rounded up for him; I'm personally on the fence so voting conservatively now but can switch that view)

If you have an opinion please express them now so Senthil has a chance to test this today before we do the official move tomorrow. Otherwise Senthil and I will make the final decision ourselves.

_______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct

Brett Cannon

6:46 p.m.

As of right now Senthil is (I'm assuming) generating another test repo right now to see the results. If we're happy with the output then we will go with it, else we will skip the rewrite. So you're not too late as in a final decision has been made, but then you could argue you're too early based on how this test goes. :) On Thu, 9 Feb 2017 at 15:00 Yury Selivanov wrote:

...

If it's not too late my opinion is `-1`. I agree with MAL.

Yury

On 2017-02-09 12:37 PM, Brett Cannon wrote:

...
+1: Nick, Senthil, Chris +0: ... -0: Martin, Brett -1: Naoki, Berker

(Maciej was positive but didn't say +1 or +0; Martin said -0.5 which isn't a valid vote, so I rounded up for him; I'm personally on the fence so voting conservatively now but can switch that view)

If you have an opinion please express them now so Senthil has a chance to test this today before we do the official move tomorrow. Otherwise Senthil and I will make the final decision ourselves.

_______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct

_______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct

Ezio Melotti

7:28 p.m.

On Fri, Feb 10, 2017 at 1:46 AM, Brett Cannon wrote:

...

As of right now Senthil is (I'm assuming) generating another test repo right now to see the results. If we're happy with the output then we will go with it, else we will skip the rewrite. So you're not too late as in a final decision has been made, but then you could argue you're too early based on how this test goes. :)

No need to wait, I put together a script that shows the result of the rewriting :) The script checks against roundup, so invalid ids are not converted. I'm currently tweaking it as I find issues, so it's still a bit messy, but this should give you a good idea. Drop the attached script in the root of your cpython clone and run it with: python convcm.py (to see 100 random converted commit messages) python convcm.py csid1 csid2 (to see the specified changeset ids) The script will create an output.html file that shows the before/after. It will also cache the valid ids in a valid_ids.json files. There are still a few ambiguous cases, in particular: * I left "SF", so "SF issue #12345" becomes "SF bpo-12345"; * I left "patch", so "Apply patch #12345" becomes "Apply patch bpo-12345"; Senthil is also testing the conversion using this regex. Best Regards, Ezio Melotti

Senthil Kumaran

8:36 p.m.

On Thu, Feb 9, 2017 at 4:28 PM, Ezio Melotti wrote:

...

No need to wait, I put together a script that shows the result of the rewriting :)

Thank you, Ezio! I and Ezio were working on this today afternoon and agreed that if we do rewrite of various formats issue NNNN to bpo-NNNN then doing it over entire commit message gives much better experience than doing it over the first line. We can judge this by looking at the actual output (from the script that Ezio shared). http://orsenthil.github.io/cpython-hg-to-git/ This picked up 1000 random revisions and added some tricky corner cases that we identified and did the re-write. Please view the output of commit logs converted here http://orsenthil.github.io/cpython-hg-to-git/ and see if it looks better than the status quo. The final decision on this should be Brett's to take. Thank you, Senthil

Berker Peksağ

10 Feb 10 Feb

12:41 a.m.

On Fri, Feb 10, 2017 at 4:36 AM, Senthil Kumaran wrote:

...

On Thu, Feb 9, 2017 at 4:28 PM, Ezio Melotti wrote:

...
No need to wait, I put together a script that shows the result of the rewriting :)

Thank you, Ezio!

I and Ezio were working on this today afternoon and agreed that if we do rewrite of various formats issue NNNN to bpo-NNNN then doing it over entire commit message gives much better experience than doing it over the first line.

We can judge this by looking at the actual output (from the script that Ezio shared).

http://orsenthil.github.io/cpython-hg-to-git/

This picked up 1000 random revisions and added some tricky corner cases that we identified and did the re-write.

Please view the output of commit logs converted here http://orsenthil.github.io/cpython-hg-to-git/ and see if it looks better than the status quo.

Thanks, Senthil and Ezio! Looks pretty good to me. I noticed some edge cases: * -46692:46918 merged from branch aimacintyre-sf1454481 +46692:46918 merged from branch aimacintyre-bpo-1454481 * -SF bug #1012315: weakref.WeakValueDictionary should override .has_key() +SF bpo-1012315: weakref.WeakValueDictionary should override .has_key() -Backport checkin: Fix typo (from SF bug #1086127). +Backport checkin: Fix typo (from SF bpo-1086127). - used on BTree databases. [SF bug id 788421] + used on BTree databases. [SF bpo-788421] Is it possible to replace 'SF bug #NNNN' with 'bpo-NNNN'? * -SF 798269: bug fix for doctest (sf bug id: 798254 +bpo-798269: bug fix for doctest (sf bug id: 798254 'bug id NNNN' matches but not 'bug id: NNNN'. * -Resolves SF bugs 697989, 697988, 697986. +Resolves SF bpo-697989, 697988, 697986. This doesn't look like a common case and we can just ignore it :) --Berker

Mariatta Wijaya

12:55 a.m.

Overall looks good :) Thanks, Senthil and Ezio. This seems like another edge case: [*4bcfb9dc57e0*]: bug #133283, #477728, #483789, #490573 [*4bcfb9dc57e0*]: bug #133283, *bpo-477728*, *bpo-483789*, *bpo-490573* Mariatta Wijaya

Senthil Kumaran

1:12 a.m.

On Thu, Feb 9, 2017 at 9:55 PM, Mariatta Wijaya wrote:

...

This seems like another edge case:

[4bcfb9dc57e0]: bug #133283, #477728, #483789, #490573

[4bcfb9dc57e0]: bug #133283, bpo-477728, bpo-483789, bpo-490573

It did! The first one is not a valid b.p.o id.

Ezio Melotti

1:37 a.m.

Attached an updated version of the script with inline unified diffs, and update regex. If you run the script and find other problems, send me the cs id and I'll look into it before the conversion. On Fri, Feb 10, 2017 at 7:41 AM, Berker Peksağ wrote:

...

On Fri, Feb 10, 2017 at 4:36 AM, Senthil Kumaran wrote:

...
On Thu, Feb 9, 2017 at 4:28 PM, Ezio Melotti wrote:

...
No need to wait, I put together a script that shows the result of the rewriting :)

Thank you, Ezio!

I and Ezio were working on this today afternoon and agreed that if we do rewrite of various formats issue NNNN to bpo-NNNN then doing it over entire commit message gives much better experience than doing it over the first line.

We can judge this by looking at the actual output (from the script that Ezio shared).

http://orsenthil.github.io/cpython-hg-to-git/

This picked up 1000 random revisions and added some tricky corner cases that we identified and did the re-write.

Please view the output of commit logs converted here http://orsenthil.github.io/cpython-hg-to-git/ and see if it looks better than the status quo.

Thanks, Senthil and Ezio! Looks pretty good to me. I noticed some edge cases:

* -46692:46918 merged from branch aimacintyre-sf1454481 +46692:46918 merged from branch aimacintyre-bpo-1454481

It's a branch name, so it shouldn't be changed, but it actually refers to a valid issue id. This is now fixed.

...

* -SF bug #1012315: weakref.WeakValueDictionary should override .has_key() +SF bpo-1012315: weakref.WeakValueDictionary should override .has_key()

-Backport checkin: Fix typo (from SF bug #1086127). +Backport checkin: Fix typo (from SF bpo-1086127).

- used on BTree databases. [SF bug id 788421] + used on BTree databases. [SF bpo-788421]

Is it possible to replace 'SF bug #NNNN' with 'bpo-NNNN'?

I had intentionally left it for these cases, but thinking about it, removing SF might actually be a good idea, since it might be confusing and it's already possible to distinguish them from the id. This is now fixed.

...

* -SF 798269: bug fix for doctest (sf bug id: 798254 +bpo-798269: bug fix for doctest (sf bug id: 798254

'bug id NNNN' matches but not 'bug id: NNNN'.

There are a few commit messages with this structure. I thought the id was the same but at least in this case they are different (and both valid). Regardless, it was an easy fix, so I updated the regex.

...

* -Resolves SF bugs 697989, 697988, 697986. +Resolves SF bpo-697989, 697988, 697986.

This doesn't look like a common case and we can just ignore it :)

Yes, I didn't bother fixing this, also because it's not as trivial as the other fixes.

...

--Berker

Senthil Kumaran

9 a.m.

On Thu, Feb 9, 2017 at 5:36 PM, Senthil Kumaran wrote:

...

Please view the output of commit logs converted here http://orsenthil.github.io/cpython-hg-to-git/ and see if it looks better than the status quo.

In addition to the random sampling of the commit logs, here is the complete repo converted while the commit message re-write: https://github.com/orsenthil/cpython-migration-test3 Both commit log samples and the repo conversion looks good to me And I am in favor of going ahead with this approach. +1 as it was previously too. Since seeing the commit log conversion yesterday, I suspect more people would be +1 one. If any of you were -1 yesterday and you changed your mind after seeing the results, please take chance to explicitly toggle your vote. -- Senthil

Berker Peksağ

9:12 a.m.

On Fri, Feb 10, 2017 at 5:00 PM, Senthil Kumaran wrote:

...

If any of you were -1 yesterday and you changed your mind after seeing the results, please take chance to explicitly toggle your vote.

Count me as +1. --Berker

Mariatta Wijaya

10:07 a.m.

+1 On Feb 10, 2017 6:00 AM, "Senthil Kumaran" wrote:

...

On Thu, Feb 9, 2017 at 5:36 PM, Senthil Kumaran wrote:

...
Please view the output of commit logs converted here http://orsenthil.github.io/cpython-hg-to-git/ and see if it looks better than the status quo.

In addition to the random sampling of the commit logs, here is the complete repo converted while the commit message re-write:

https://github.com/orsenthil/cpython-migration-test3

Both commit log samples and the repo conversion looks good to me And I am in favor of going ahead with this approach. +1 as it was previously too.

Since seeing the commit log conversion yesterday, I suspect more people would be +1 one.

If any of you were -1 yesterday and you changed your mind after seeing the results, please take chance to explicitly toggle your vote. -- Senthil _______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct

INADA Naoki

10:08 a.m.

...

If any of you were -1 yesterday and you changed your mind after seeing the results, please take chance to explicitly toggle your vote.

+1 for go ahead, not stop migration.

Stephane Wirtel

10:11 a.m.

+1 On 10 Feb 2017, at 16:08, INADA Naoki wrote:

...

...
If any of you were -1 yesterday and you changed your mind after seeing the results, please take chance to explicitly toggle your vote.

+1 for go ahead, not stop migration. _______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct

Barry Warsaw

9 Feb 9 Feb

6:51 p.m.

I'm generally -1 on rewriting history, but I guess in this case practicality beats purity. If it provides a better user experience, then I'm +0. Cheers, -Barry

Maciej Szulik

10 Feb 10 Feb

11:05 a.m.

On Thu, Feb 9, 2017 at 6:37 PM, Brett Cannon wrote:

...

(Maciej was positive but didn't say +1 or +0; Martin said -0.5 which isn't a valid vote, so I rounded up for him; I'm personally on the fence so voting conservatively now but can switch that view)

Count me as +1 on this one, I'll be more explicit next time :)

Brett Cannon

12:51 p.m.

In the end I decided *NOT* to do the history mutation/rewrite basically because I didn't discuss this with python-committers ahead of time (so it's entirely my fault this didn't go forward). The history of this repo -- along with the code -- is collectively owned by all of the people who have contributed to it. The idea of mutating the history like this was not discussed with the stakeholders/contributors of that history ahead of time and thus I don't feel it is my place to unilaterally muck with it without having a proper discussion ahead of time (I unfortunately didn't have this thought until this morning). While I realize I have been given the rights to change our workflow, none of these changes are permanent (as our regular changes to it show :) . But changing the history is permanent and thus a much heftier thing to do with the dictatorial powers I have for this migration. Had I thought to reach out ahead of time then it's possible I could have gotten the permission necessary. But since leaving this as-is doesn't hurt anything (thanks to GH doing the linking eagerly and thus not picking up any of the issue numbers that pre-exist), I felt it was better to err on the side of caution and not upset people by springing this on them. Obviously a huge thanks to Senthil and Ezio for giving this a go. The regex will be useful for anyone who wants to write a browser plug-in to add the automatic linking so I don't view the work as wasted. On Fri, 10 Feb 2017 at 08:06 Maciej Szulik wrote:

...

On Thu, Feb 9, 2017 at 6:37 PM, Brett Cannon wrote:

(Maciej was positive but didn't say +1 or +0; Martin said -0.5 which isn't a valid vote, so I rounded up for him; I'm personally on the fence so voting conservatively now but can switch that view)

Count me as +1 on this one, I'll be more explicit next time :)

_______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct

Berker Peksağ

1:08 p.m.

On Fri, Feb 10, 2017 at 8:51 PM, Brett Cannon wrote:

...

In the end I decided NOT to do the history mutation/rewrite basically because I didn't discuss this with python-committers ahead of time (so it's entirely my fault this didn't go forward). The history of this repo -- along with the code -- is collectively owned by all of the people who have contributed to it. The idea of mutating the history like this was not discussed with the stakeholders/contributors of that history ahead of time and thus I don't feel it is my place to unilaterally muck with it without having a proper discussion ahead of time (I unfortunately didn't have this thought until this morning). While I realize I have been given the rights to change our workflow, none of these changes are permanent (as our regular changes to it show :) . But changing the history is permanent and thus a much heftier thing to do with the dictatorial powers I have for this migration.

Had I thought to reach out ahead of time then it's possible I could have gotten the permission necessary. But since leaving this as-is doesn't hurt anything (thanks to GH doing the linking eagerly and thus not picking up any of the issue numbers that pre-exist), I felt it was better to err on the side of caution and not upset people by springing this on them.

Obviously a huge thanks to Senthil and Ezio for giving this a go. The regex will be useful for anyone who wants to write a browser plug-in to add the automatic linking so I don't view the work as wasted.

+1, I've already started to write an extension and I'm converting the regex to JS flavor now so thanks again Senthil and Ezio! --Berker

Berker Peksağ

11 Feb 11 Feb

7:03 a.m.

On Fri, Feb 10, 2017 at 9:08 PM, Berker Peksağ wrote:

...

+1, I've already started to write an extension and I'm converting the regex to JS flavor now so thanks again Senthil and Ezio!

Just an FYI, first version of the extension can be found at https://github.com/berkerpeksag/cpython-bpo-linkify It's not perfect, but it does its job for now :) Feel free send bug reports, suggestions and pull requests. --Berker

Nick Coghlan

7:39 a.m.

On 11 February 2017 at 13:03, Berker Peksağ wrote:

...

On Fri, Feb 10, 2017 at 9:08 PM, Berker Peksağ wrote:

...
+1, I've already started to write an extension and I'm converting the regex to JS flavor now so thanks again Senthil and Ezio!

Just an FYI, first version of the extension can be found at https://github.com/berkerpeksag/cpython-bpo-linkify It's not perfect, but it does its job for now :) Feel free send bug reports, suggestions and pull requests.

Nice! Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

2628

Age (days ago)

2630

Last active (days ago)

List overview

Download

37 comments

15 participants

participants (15)

Alexander Belopolsky
Barry Warsaw
Berker Peksağ
Brett Cannon
Eric Snow
Ezio Melotti
INADA Naoki
M.-A. Lemburg
Maciej Szulik
Mariatta Wijaya
Nick Coghlan
Senthil Kumaran
Stephane Wirtel
Yury Selivanov
Zachary Ware

Final chance to express opinion on history rewrite for issue #s

tags

participants (15)