Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Brett Cannon]

On Thu, 25 Jan 2018 at 17:33 Eric V. Smith  wrote:

> On 1/25/2018 8:13 PM, Terry Reedy wrote:
> > On 1/25/2018 7:47 PM, Mariatta Wijaya wrote:
> >> I think we're starting to deviate from the original topic here which
> >> is: please replace # with GH- when you click Squash & Merge button.
> >
> > I will try to remember to do this, although it seems pointless if most
> > people do not.
>

Just because people are forgetting doesn't mean we shouldn't try to change
people's habits for the better. If it continues to be an issue then we can
talk about not caring, but for now we should try and spare us future pain
like we have had with e.g. issue numbers across various issue trackers
where you don't know which tracker a number is pointing you towards.

And since you have brought it up a couple of times, Terry, we can't
automate this reformatting if you press the Merge button, hence the
suggestion of a bot to do the final commit.


>
> I sometimes forget, too.
>
> Since changing this in the github workflow seems hard, how about sending
> an email to the committer after the commit if this mistake is detected?
> I know that in my case, if I were reminded a few times, I would be
> better at doing it correctly in the future.
>

https://github.com/python/bedevere/issues/14

Patches welcome :)

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] inconsistency in annotated assigned targets

[Joe Jevnik via Python-Dev]

Thank you for the clarification! I should have looked through the PEPs
first.

On Thu, Jan 25, 2018 at 10:14 PM, Guido van Rossum  wrote:

> PEP 526 has this in the "Rejected/Postponed Proposals" section:
>
> - **Allow annotations in** ``with`` **and** ``for`` **statement:**
>   This was rejected because in ``for`` it would make it hard to spot the
> actual
>   iterable, and in ``with`` it would confuse the CPython's LL(1) parser.
>
>
> On Thu, Jan 25, 2018 at 3:17 PM, Jelle Zijlstra 
> wrote:
>
>>
>>
>> 2018-01-25 15:00 GMT-08:00 Joe Jevnik via Python-Dev <
>> python-dev@python.org>:
>>
>>> Currently there are many ways to introduce variables in Python; however,
>>> only a few allow annotations. I was working on a toy language and chose to
>>> base my syntax on Python's when I noticed that I could not annotate a loop
>>> iteration variable. For example:
>>>
>>> for x: int in range(5):
>>> ...
>>>
>>> This led me to search for other places where new variables are
>>> introduced and I noticed that the `as` target of a context manager cannot
>>> have an annotation. In the case of a context manager, it would probably
>>> need parenthesis to avoid ambiguity with a single-line with statement, for
>>> example:
>>>
>>> with ctx as (variable: annotation): body
>>>
>>> Finally, you cannot annotate individual members of a destructuring
>>> assignment like:
>>>
>>> a: int, b: int, c: int = 1, 2, 3
>>>
>>> Looking at the grammar, these appear to be `expr` or `exprlist` targets.
>>> One change may be to allow arbitrary expressions to have an annotation .
>>> This would be a small change to the grammar but would potentially have a
>>> large effect on the language or static analysis tools.
>>>
>>> I am posting on the mailing list to see if this is a real problem, and
>>> if so, is it worth investing any time to address it. I would be happy to
>>> attempt to fix this, but I don't want to start if people don't want the
>>> change. Also, I apologize if this should have gone to python-idea; this
>>> feels somewhere between a bug report and implementation question more than
>>> a new feature so I wasn't sure which list would be more appropriate.
>>>
>> I have written a fair amount of code with variable annotations, and I
>> don't remember ever wanting to add annotations in any of the three contexts
>> you mention. In practice, variable annotations are usually needed for
>> class/instance variables and for variables whose type the type checker
>> can't infer. The types of loop iteration variables and context manager
>> assignment targets can almost always be inferred trivially.
>>
>>
>>>
>>> ___
>>> Python-Dev mailing list
>>> Python-Dev@python.org
>>> https://mail.python.org/mailman/listinfo/python-dev
>>> Unsubscribe: https://mail.python.org/mailma
>>> n/options/python-dev/jelle.zijlstra%40gmail.com
>>>
>>>
>>
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%
>> 40python.org
>>
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] inconsistency in annotated assigned targets

[Guido van Rossum]

PEP 526 has this in the "Rejected/Postponed Proposals" section:

- **Allow annotations in** ``with`` **and** ``for`` **statement:**
  This was rejected because in ``for`` it would make it hard to spot the
actual
  iterable, and in ``with`` it would confuse the CPython's LL(1) parser.


On Thu, Jan 25, 2018 at 3:17 PM, Jelle Zijlstra 
wrote:

>
>
> 2018-01-25 15:00 GMT-08:00 Joe Jevnik via Python-Dev <
> python-dev@python.org>:
>
>> Currently there are many ways to introduce variables in Python; however,
>> only a few allow annotations. I was working on a toy language and chose to
>> base my syntax on Python's when I noticed that I could not annotate a loop
>> iteration variable. For example:
>>
>> for x: int in range(5):
>> ...
>>
>> This led me to search for other places where new variables are introduced
>> and I noticed that the `as` target of a context manager cannot have an
>> annotation. In the case of a context manager, it would probably need
>> parenthesis to avoid ambiguity with a single-line with statement, for
>> example:
>>
>> with ctx as (variable: annotation): body
>>
>> Finally, you cannot annotate individual members of a destructuring
>> assignment like:
>>
>> a: int, b: int, c: int = 1, 2, 3
>>
>> Looking at the grammar, these appear to be `expr` or `exprlist` targets.
>> One change may be to allow arbitrary expressions to have an annotation .
>> This would be a small change to the grammar but would potentially have a
>> large effect on the language or static analysis tools.
>>
>> I am posting on the mailing list to see if this is a real problem, and if
>> so, is it worth investing any time to address it. I would be happy to
>> attempt to fix this, but I don't want to start if people don't want the
>> change. Also, I apologize if this should have gone to python-idea; this
>> feels somewhere between a bug report and implementation question more than
>> a new feature so I wasn't sure which list would be more appropriate.
>>
> I have written a fair amount of code with variable annotations, and I
> don't remember ever wanting to add annotations in any of the three contexts
> you mention. In practice, variable annotations are usually needed for
> class/instance variables and for variables whose type the type checker
> can't infer. The types of loop iteration variables and context manager
> assignment targets can almost always be inferred trivially.
>
>
>>
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/jelle.
>> zijlstra%40gmail.com
>>
>>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Eric V. Smith]

On 1/25/2018 8:13 PM, Terry Reedy wrote:

On 1/25/2018 7:47 PM, Mariatta Wijaya wrote:
I think we're starting to deviate from the original topic here which 
is: please replace # with GH- when you click Squash & Merge button.


I will try to remember to do this, although it seems pointless if most 
people do not.


I sometimes forget, too.

Since changing this in the github workflow seems hard, how about sending 
an email to the committer after the commit if this mistake is detected? 
I know that in my case, if I were reminded a few times, I would be 
better at doing it correctly in the future.


Eric.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Terry Reedy]

On 1/25/2018 7:47 PM, Mariatta Wijaya wrote:
I think we're starting to deviate from the original topic here which is: 
please replace # with GH- when you click Squash & Merge button.


I will try to remember to do this, although it seems pointless if most 
people do not.


The idea of the mergebot (by issuing a command) was brought up for a 
different purpose: to automate the merging of a PR after all CI passes 
(which can take time) and an approval by a core dev.


I still like that idea, if we can figure out a way to supply a commit 
message we really want, before the bot merges the PR.


For backports, the squashed merge commit message is already written, and 
usually already has the cherry-pick addition.  So I suggest starting 
with backports first.  Once a backport mergebot is working and tested, 
we can work on the original merge message problem.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Terry Reedy]

On 1/25/2018 4:34 PM, Berker Peksağ wrote:

On Fri, Jan 26, 2018 at 12:09 AM, Terry Reedy  wrote:

On 1/25/2018 1:53 PM, Brett Cannon wrote:


I would assume it would just go into miss-islington, but before we get
ahead of ourselves and design this we need to get consensus that people like
the overall idea of using a bot to do a main commits as well.



I strongly dislike any idea of making me do more error-prone work when
merging.


The whole point of writing a bot is to automatize the steps listed at
https://devguide.python.org/gitbootcamp/#accepting-and-merging-a-pull-request


The point is to automate

"2. Replace the reference to GitHub pull request # with GH-."

which in itself is trivial (and would be welcome).  (I am not sure that 
I ever read this ;-). But is would be harder to automate the next sentence.


"If the title is too long, the pull request number can be added to the 
message body."


and impossible to properly automate

"3. Adjust and clean up the commit message."

Looking at the example, a bot cannot turn this 'bad' message

"""
* Improve the spam module
* merge from master
* adjust code based on review comment
* rebased
"""

into this 'good' message.

"""
* Add method A to the spam module
* Update the documentation of the spam module
"""

Actually, I think this would be even better with the '* 's deleted and 
the missing '.'s added.  But good message style is another issue.



and https://devguide.python.org/gitbootcamp/#backporting-merged-changes


Miss Islington already handles these bad-good differences.


so you won't have to do bunch of manual edits before pressing the
"Confirm squash and merge" button.


Human intelligence is required to write a good commit message, which I 
try to do.  I am aware that some people just commit the concatenated 
commit messages, as in the bad example above, but I think the best a bot 
could do is to refuse to merge.


An alternate approach would be to ask people to edit the initial commit 
message into the final version before merging, but I don't think this 
would be a good idea.


--
Terry Jan Reedy


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Mariatta Wijaya]

I think we're starting to deviate from the original topic here which is:
please replace # with GH- when you click Squash & Merge button.

The idea of the mergebot (by issuing a command) was brought up for a
different purpose: to automate the merging of a PR after all CI passes
(which can take time) and an approval by a core dev.
I still like that idea, if we can figure out a way to supply a commit
message we really want, before the bot merges the PR. It might be a
separate discussion for core-workflow or python-committers?

In my mind, even if we have such mergebot implemented, core devs can still
merge using the UI if they want to.
(Remember to replace the # with GH-)


Mariatta Wijaya
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Terry Reedy]

On 1/25/2018 4:22 PM, Berker Peksağ wrote:

On Thu, Jan 25, 2018 at 11:50 PM, Terry Reedy  wrote:

On 1/25/2018 1:03 PM, Mariatta Wijaya wrote:


One idea is maybe have a bot to do the squash commit, for example by
commenting on GitHub:
@merge-bot merge  



So core devs can do the above instead of pressing the commit button. Any
thoughts on this?


I can hardly believe that you are seriously proposing that I should replace
a click with a 16 char prefix and then retype the title and message.  Did I
misunderstand?


If I understand Mariatta correctly, you can just left a "@merge-bot
merge" comment if you're happy with the commit message.


There is no 'the commit message' until one presses the merge button.  GH 
then cobbles together a proposed squashed merge commit message from the 
various commit messages. But I am usually not happy with the result.  I 
nearly always usually do a rewriting that a bot cannot do.  This is 
usually easier that starting from scratch.



Then the bot itself can replace # with GH-,


in the title.  As I said elsewhere, I think we should try to find other 
ways to do this independent of the commit message.



clean the body of the commit message from commits like "* fix typo",


A bot cannot tell which should be deleted and which should be 
incorporated into the message and if so, how.  For instance, the initial 
PR has no test.  Someone adds some, with 'Add tests', resulting in a 
line '* Add tests'.  I typically merge that into a version of the 
initial commit message as part of producing the final merge message.



squash commits, and merge.


As done now.

--
Terry Jan Reedy


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] inconsistency in annotated assigned targets

[Jelle Zijlstra]

2018-01-25 15:00 GMT-08:00 Joe Jevnik via Python-Dev 
:

> Currently there are many ways to introduce variables in Python; however,
> only a few allow annotations. I was working on a toy language and chose to
> base my syntax on Python's when I noticed that I could not annotate a loop
> iteration variable. For example:
>
> for x: int in range(5):
> ...
>
> This led me to search for other places where new variables are introduced
> and I noticed that the `as` target of a context manager cannot have an
> annotation. In the case of a context manager, it would probably need
> parenthesis to avoid ambiguity with a single-line with statement, for
> example:
>
> with ctx as (variable: annotation): body
>
> Finally, you cannot annotate individual members of a destructuring
> assignment like:
>
> a: int, b: int, c: int = 1, 2, 3
>
> Looking at the grammar, these appear to be `expr` or `exprlist` targets.
> One change may be to allow arbitrary expressions to have an annotation .
> This would be a small change to the grammar but would potentially have a
> large effect on the language or static analysis tools.
>
> I am posting on the mailing list to see if this is a real problem, and if
> so, is it worth investing any time to address it. I would be happy to
> attempt to fix this, but I don't want to start if people don't want the
> change. Also, I apologize if this should have gone to python-idea; this
> feels somewhere between a bug report and implementation question more than
> a new feature so I wasn't sure which list would be more appropriate.
>
I have written a fair amount of code with variable annotations, and I don't
remember ever wanting to add annotations in any of the three contexts you
mention. In practice, variable annotations are usually needed for
class/instance variables and for variables whose type the type checker
can't infer. The types of loop iteration variables and context manager
assignment targets can almost always be inferred trivially.


>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> jelle.zijlstra%40gmail.com
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] inconsistency in annotated assigned targets

[Joe Jevnik via Python-Dev]

Currently there are many ways to introduce variables in Python; however,
only a few allow annotations. I was working on a toy language and chose to
base my syntax on Python's when I noticed that I could not annotate a loop
iteration variable. For example:

for x: int in range(5):
...

This led me to search for other places where new variables are introduced
and I noticed that the `as` target of a context manager cannot have an
annotation. In the case of a context manager, it would probably need
parenthesis to avoid ambiguity with a single-line with statement, for
example:

with ctx as (variable: annotation): body

Finally, you cannot annotate individual members of a destructuring
assignment like:

a: int, b: int, c: int = 1, 2, 3

Looking at the grammar, these appear to be `expr` or `exprlist` targets.
One change may be to allow arbitrary expressions to have an annotation .
This would be a small change to the grammar but would potentially have a
large effect on the language or static analysis tools.

I am posting on the mailing list to see if this is a real problem, and if
so, is it worth investing any time to address it. I would be happy to
attempt to fix this, but I don't want to start if people don't want the
change. Also, I apologize if this should have gone to python-idea; this
feels somewhere between a bug report and implementation question more than
a new feature so I wasn't sure which list would be more appropriate.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Nathaniel Smith]

On Thu, Jan 25, 2018 at 1:46 PM, Barry Warsaw  wrote:
> On Jan 25, 2018, at 13:38, Mariatta Wijaya  wrote:
>>
>> +1 for the mergebot! :)
>
> Yes, +1 from me too.  As you know, GitLab has the option to “merge when CI 
> completes successfully” and it’s a great workflow.  Once I’ve reviewed and 
> approved the branch, I can hit this button and… we’re done!  Assuming of 
> course that no additional commits get pushed (that’s actually configurable I 
> think), and that CI doesn’t fail.  I’d be very happy to see how close we can 
> get to that with GitHub and a mergebot.

You should definitely check out bors-ng: https://bors.tech/

It's designed to support the workflow that projects like Rust and
Servo use: you tell the bot that a PR is good to merge, and then it
takes over and manages the CI process so as to guarantee that the head
of the master branch has always passed all its tests (the "not rocket
science rule": https://graydon2.dreamwidth.org/1597.html).

So not only does this give you the ability to mark a PR as good before
the CI has finished for that PR, like in GitLab, it also gives you a
few more things:

- one problem with the normal way of using Travis is that the tests on
a PR branch can get stale: the PR worked when it was submitted, but in
the mean time something else got merged to master that breaks it, but
no-one notices until after it's merged. With bors-ng, the bot always
tests exactly the snapshot that will become the new master, so it
catches cases like this before they're merged.

- currently, IIUC, the two times we run automatic tests are when a PR
is submitted, and after it's merged. And since we can't run
non-sandboxed tests like the buildbots automatically on submit, this
means we have to run them after merge, which is suboptimal. This adds
a new test step between approval and merging, so it gives the option
of turning buildbots into a pre-merge check. (Whether this is a good
idea or not I don't know, but it seems like a nice option to have?)

- if PRs are coming in faster than the CI system can keep up, then it
automatically batches up changes to test together, and if the batch
fails it uses binary search to automatically figure out which PR or
PRs are responsible. So if appveyor gets clogged up, or you enable
some slow buildbots, it should still be able to keep things moving.

Anyway, I don't know if it's exactly what cpython wants, but it's at
the least got some really interesting ideas.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Merging the implementation of PEP 563

[Yury Selivanov]

I looked at the PR and I think the code is fine.

Yury

On Thu, Jan 25, 2018 at 4:39 PM, Victor Stinner
 wrote:
> Hi,
>
> If nobody is available to review your PR, I suggest to push it anyway,
> to get it merged before the feature freeze. The code can be reviewed
> later. Merging it sooner gives more time to test it and spot bugs. It
> also gives more time to fix bugs ;-) Well, at the end, it's up to you.
>
> Victor
>
> 2018-01-25 22:07 GMT+01:00 Lukasz Langa :
>> Hi all,
>> Serhiy looks busy these days. I'd appreciate somebody looking at and
>> hopefully merging https://github.com/python/cpython/pull/4390. Everything
>> there was reviewed by Serhiy except for the latest commit.
>>
>> This should be ready to merge and maybe tweak in the beta stage. I'd like to
>> avoid merging it myself but I'd really hate missing the deadline.
>>
>> - Ł
>>
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com
>>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/yselivanov.ml%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Victor Stinner]

2018-01-25 22:55 GMT+01:00 Mariatta Wijaya :
> My problem has been that I almost always still need to rewrite the commit
> message.
> Especially when someone wrote "fix a typo" or "fix several typos".

That's the main drawback of GitHub compared to Gerrit. On Gerrit, the
commit message is at the same level than other changes. We can comment
the commit message as we comment the change.

Note: On Gerrit, it's even possible to edit the commit message online
(using the web browser).

> If it automatically merges, then there's no opportunity to adjust the commit
> message.

Maybe we need a tool to preview the future commit message, and let the
developer modify it.

For example, a merge request would add a comment to the PR with the
future commit message and then asks to validate the commit message, or
let the developer to override (modify) it.

Example:
---
Comment 4, dev: "Merge"

Comment 5, bot: "bpo-123: Cool fix"

Comment 6, dev: "Confirm merge"

Comment 7, GitHub: "PR merged, commit xxx"
---

> So I suggest the option to provide the proper commit message to the
> mergebot.

Sometimes, the commit message is just fine and can be used unchanged ;-)

> If not provided, I guess we'll use the GitHub PR title and description.

Sometimes, I see a typo in the commit message after I push a change.
In this case, I quickly amend my commit and push my commit again. But
the PR description keeps my original commit message with the typo. So
the PR description is not reliable. It doesn't seem to be used by
GitHub to generate the commit message, GitHub combines commit messages
of the PR commits.

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Victor Stinner]

2018-01-25 22:46 GMT+01:00 Barry Warsaw :
> Why not just auto merge if the PR is approved, CI is all green, and no 
> additional commits have been pushed?

Merging a PR and approving it should be two different actions.
Sometimes, you prefer to wait for 2 approvals before merging.
Sometimes, you want to wait until another change is merged. There are
many cases.

On Gerrit (ex: review.openstack.org), votes and workflow are two
different fields.

Vote: -2, -1, 0, +1, +2. -2 and +2 votes are reserved to core
reviewers. Voting +2 means approving a change.
Workflow: -1, 0, +1. -1 means that the change is a work-in-progress.
+1 asks to merge the change, once tests pass.

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Barry Warsaw]

On Jan 25, 2018, at 16:55, Mariatta Wijaya  wrote:

> My problem has been that I almost always still need to rewrite the commit 
> message.
> Especially when someone wrote "fix a typo" or "fix several typos".
> 
> If it automatically merges, then there's no opportunity to adjust the commit 
> message.

Right, that’s the bit that’s different here than the GitLab workflow.  In the 
latter, you can set the commit message when you click on “merge when CI 
succeeds”.

> So I suggest the option to provide the proper commit message to the mergebot.
> If not provided, I guess we'll use the GitHub PR title and description.

I think that’d be fine actually.  When I merge things I almost always just 
delete most of the default commit message anyway.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Mariatta Wijaya]

>
> Why not just auto merge if the PR is approved, CI is all green, and no
> additional commits have been pushed?


My problem has been that I almost always still need to rewrite the commit
message.
Especially when someone wrote "fix a typo" or "fix several typos".

If it automatically merges, then there's no opportunity to adjust the
commit message.
So I suggest the option to provide the proper commit message to the
mergebot.
If not provided, I guess we'll use the GitHub PR title and description.

Mariatta Wijaya
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Barry Warsaw]

On Jan 25, 2018, at 13:38, Mariatta Wijaya  wrote:
> 
> +1 for the mergebot! :)

Yes, +1 from me too.  As you know, GitLab has the option to “merge when CI 
completes successfully” and it’s a great workflow.  Once I’ve reviewed and 
approved the branch, I can hit this button and… we’re done!  Assuming of course 
that no additional commits get pushed (that’s actually configurable I think), 
and that CI doesn’t fail.  I’d be very happy to see how close we can get to 
that with GitHub and a mergebot.

I don’t know that we need a @mergebot mention though.  Why not just auto merge 
if the PR is approved, CI is all green, and no additional commits have been 
pushed?  I suppose the reason would be because in GH, you can’t modify the 
commit message any other way pre-merge.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Merging the implementation of PEP 563

[Victor Stinner]

Hi,

If nobody is available to review your PR, I suggest to push it anyway,
to get it merged before the feature freeze. The code can be reviewed
later. Merging it sooner gives more time to test it and spot bugs. It
also gives more time to fix bugs ;-) Well, at the end, it's up to you.

Victor

2018-01-25 22:07 GMT+01:00 Lukasz Langa :
> Hi all,
> Serhiy looks busy these days. I'd appreciate somebody looking at and
> hopefully merging https://github.com/python/cpython/pull/4390. Everything
> there was reviewed by Serhiy except for the latest commit.
>
> This should be ready to merge and maybe tweak in the beta stage. I'd like to
> avoid merging it myself but I'd really hate missing the deadline.
>
> - Ł
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Berker Peksağ]

On Fri, Jan 26, 2018 at 12:09 AM, Terry Reedy  wrote:
> On 1/25/2018 1:53 PM, Brett Cannon wrote:
>
>> I would assume it would just go into miss-islington, but before we get
>> ahead of ourselves and design this we need to get consensus that people like
>> the overall idea of using a bot to do a main commits as well.
>
>
> I strongly dislike any idea of making me do more error-prone work when
> merging.

The whole point of writing a bot is to automatize the steps listed at
https://devguide.python.org/gitbootcamp/#accepting-and-merging-a-pull-request
and https://devguide.python.org/gitbootcamp/#backporting-merged-changes
so you won't have to do bunch of manual edits before pressing the
"Confirm squash and merge" button.

--Berker
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Ethan Furman]

On 01/25/2018 10:53 AM, Brett Cannon wrote:


[...] before we get ahead of ourselves and design this we need to get
consensus that people like the overall idea of using a bot to do a main

> commits as well.

-1 on using comments for the main commit.

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Berker Peksağ]

On Thu, Jan 25, 2018 at 11:50 PM, Terry Reedy  wrote:
> On 1/25/2018 1:03 PM, Mariatta Wijaya wrote:
>
>> One idea is maybe have a bot to do the squash commit, for example by
>> commenting on GitHub:
>> @merge-bot merge  
>
>
>> So core devs can do the above instead of pressing the commit button. Any
>> thoughts on this?
>
>
> I can hardly believe that you are seriously proposing that I should replace
> a click with a 16 char prefix and then retype the title and message.  Did I
> misunderstand?

If I understand Mariatta correctly, you can just left a "@merge-bot
merge" comment if you're happy with the commit message. Then the bot
itself can replace # with GH-, clean the body of the commit
message from commits like "* fix typo", squash commits, and merge.

--Berker
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Terry Reedy]

On 1/25/2018 1:53 PM, Brett Cannon wrote:

I would assume it would just go into miss-islington, but before we get 
ahead of ourselves and design this we need to get consensus that people 
like the overall idea of using a bot to do a main commits as well.


I strongly dislike any idea of making me do more error-prone work when 
merging.


Also, pressing the big green button is a distinct action from anything 
else one does on the page.  I am sure this is intentional from a UI 
design viewpoint, to minimize the possibility of merging by accident.


I am personally not so concerned about changing '#' to 'GH-'.  The bpo 
number is already distinguished by the 'bpo-' prefix.  But since you are:


Supposes when a PR is created, a bot appended '(GH-)' to the title. 
Would github's bot still append '(#)'?  What is it appended '(GH#)'?


Can titles be edited by a bot after a merge?  (You might want this 
anyway to 'correct' existing merges.)


Can we ask GH to make the number prefix a configuration option?

--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Merging the implementation of PEP 563

[Lukasz Langa]

Hi all,
Serhiy looks busy these days. I'd appreciate somebody looking at and hopefully 
merging https://github.com/python/cpython/pull/4390 
. Everything there was reviewed by 
Serhiy except for the latest commit.

This should be ready to merge and maybe tweak in the beta stage. I'd like to 
avoid merging it myself but I'd really hate missing the deadline.

- Ł


signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Terry Reedy]

On 1/25/2018 1:03 PM, Mariatta Wijaya wrote:

One idea is maybe have a bot to do the squash commit, for example by 
commenting on GitHub:

@merge-bot merge  


So core devs can do the above instead of pressing the commit button. Any 
thoughts on this?


I can hardly believe that you are seriously proposing that I should 
replace a click with a 16 char prefix and then retype the title and 
message.  Did I misunderstand?


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] CLion IDE

[Stephane Wirtel via Python-Dev]

On 01/24, Steve Holden wrote:

I've just start using CLion from JetBrains, and I wondered if anyone on the
list is using this product in CPython development. Links to any guidance
would be useful.

regards
Steve Holden


Hi Steve,

I tried to use it for CPython, but it uses CMake and not the autotools.
I have found a this repo 
https://github.com/python-cmake-buildsystem/python-cmake-buildsystem but not 
yet tested

Stephane


--
Stéphane Wirtel - http://wirtel.be - @matrixise
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Steve Dower]

-1 on using magic words in comments rather than the normal UI.

Perhaps one of the bots could post a reminder at a time when it makes sense? 
All checks passed, maybe?

Top-posted from my Windows phone

From: Brett Cannon
Sent: Friday, January 26, 2018 6:01
To: Berker Peksağ
Cc: Python Dev
Subject: Re: [Python-Dev] GH- vs # in merge commit


On Thu, 25 Jan 2018 at 10:51 Berker Peksağ  wrote:
On Thu, Jan 25, 2018 at 9:38 PM, Mariatta Wijaya
 wrote:
>> That would be best solution (I think it would solve
>> https://github.com/python/miss-islington/issues/16 too) but it's more
>> complicated than the extension idea :) I have some time work on it if
>> you'd like to implement the mergebot idea.
>
>
> +1 for the mergebot! :)
>
> New bot or miss-islington's new job?
>
> Still +1 either way, as long as other core devs are fine with it too :)

I'm not familiar with miss-islington's codebase. Can we reuse some
parts of miss-islington in the new bot? If we can, let's implement it
in miss-islington (perhaps as a new mode?)

I would assume it would just go into miss-islington, but before we get ahead of 
ourselves and design this we need to get consensus that people like the overall 
idea of using a bot to do a main commits as well. 

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Brett Cannon]

On Thu, 25 Jan 2018 at 10:51 Berker Peksağ  wrote:

> On Thu, Jan 25, 2018 at 9:38 PM, Mariatta Wijaya
>  wrote:
> >> That would be best solution (I think it would solve
> >> https://github.com/python/miss-islington/issues/16 too) but it's more
> >> complicated than the extension idea :) I have some time work on it if
> >> you'd like to implement the mergebot idea.
> >
> >
> > +1 for the mergebot! :)
> >
> > New bot or miss-islington's new job?
> >
> > Still +1 either way, as long as other core devs are fine with it too :)
>
> I'm not familiar with miss-islington's codebase. Can we reuse some
> parts of miss-islington in the new bot? If we can, let's implement it
> in miss-islington (perhaps as a new mode?)
>

I would assume it would just go into miss-islington, but before we get
ahead of ourselves and design this we need to get consensus that people
like the overall idea of using a bot to do a main commits as well.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Berker Peksağ]

On Thu, Jan 25, 2018 at 9:38 PM, Mariatta Wijaya
 wrote:
>> That would be best solution (I think it would solve
>> https://github.com/python/miss-islington/issues/16 too) but it's more
>> complicated than the extension idea :) I have some time work on it if
>> you'd like to implement the mergebot idea.
>
>
> +1 for the mergebot! :)
>
> New bot or miss-islington's new job?
>
> Still +1 either way, as long as other core devs are fine with it too :)

I'm not familiar with miss-islington's codebase. Can we reuse some
parts of miss-islington in the new bot? If we can, let's implement it
in miss-islington (perhaps as a new mode?)

--Berker
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Brett Cannon]

On Thu, 25 Jan 2018 at 10:14 Zachary Ware 
wrote:

> On Thu, Jan 25, 2018 at 12:03 PM, Mariatta Wijaya
>  wrote:
> >> Of course, we would still need to convince people to install it :)
> >
> >
> > Right, that's the challenge :)
> > I personally use Chrome (!) and I've been using your Chrome extension, so
> > thank you!
> > However, I don't feel comfortable making this available only for a
> specific
> > browser user, feels exclusionary to me.
>

I personally use Firefox, so browser-specific, while better than nothing,
won't cover all cases.


> > Also, sometimes I merge from my phone where there's no chrome extension,
> > (maybe I really shouldn't be doing that?).
>
> A large part of Brett's push for moving to a PR workflow was to be
> able to merge patches from a tablet on the beach, so I see no reason
> not to merge from a phone if you can :)
>

There is https://github.com/python/bedevere/issues/14 which is tracking the
idea of leaving a follow-up comment if a commit occurs w/o changing the
`#-` prefix to `GH-`

We definitely don't want to leave `#-` prefixes because those are ambiguous
and Python will outlast GitHub and thus what `#-` means would have to
represent GitHub forever. So either we namespace the PR numbers w/ `GH-`
which GitHub will still automatically link to, or we drop them entirely and
rely on the issue number being the point of reference entirely. Those are
the two options I see for us going forward.

>
>
> > I think the solution should be something not webbrowser specific.
> >
> > One idea is maybe have a bot to do the squash commit, for example by
> > commenting on GitHub:
> > @merge-bot merge  
> >
> > So core devs can do the above instead of pressing the commit button. Any
> > thoughts on this?
> >
> > In the meantime, committers, please try to remember and change the # into
> > GH- :)
>
> +1 to everything here.
>

I'm fine with a bot handling the merge if people in general are okay with
the idea and someone is up for coding it up.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Mariatta Wijaya]

>
> That would be best solution (I think it would solve
> https://github.com/python/miss-islington/issues/16 too) but it's more
> complicated than the extension idea :) I have some time work on it if
> you'd like to implement the mergebot idea.


+1 for the mergebot! :)

New bot or miss-islington's new job?

Still +1 either way, as long as other core devs are fine with it too :)


Mariatta Wijaya
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Berker Peksağ]

On Thu, Jan 25, 2018 at 9:03 PM, Mariatta Wijaya
 wrote:
>> Of course, we would still need to convince people to install it :)
>
>
> Right, that's the challenge :)
> I personally use Chrome (!) and I've been using your Chrome extension, so
> thank you!
> However, I don't feel comfortable making this available only for a specific
> browser user, feels exclusionary to me.

Thanks to Milan Oberkirch, the version in the master branch uses
WebExtension API so it should be easy make it run on Firefox (I don't
know if it works on other browsers though)

> Also, sometimes I merge from my phone where there's no chrome extension,
> (maybe I really shouldn't be doing that?).
>
> I think the solution should be something not webbrowser specific.
>
> One idea is maybe have a bot to do the squash commit, for example by
> commenting on GitHub:
> @merge-bot merge  
>
> So core devs can do the above instead of pressing the commit button. Any
> thoughts on this?

That would be best solution (I think it would solve
https://github.com/python/miss-islington/issues/16 too) but it's more
complicated than the extension idea :) I have some time work on it if
you'd like to implement the mergebot idea.

--Berker
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Zachary Ware]

On Thu, Jan 25, 2018 at 12:03 PM, Mariatta Wijaya
 wrote:
>> Of course, we would still need to convince people to install it :)
>
>
> Right, that's the challenge :)
> I personally use Chrome (!) and I've been using your Chrome extension, so
> thank you!
> However, I don't feel comfortable making this available only for a specific
> browser user, feels exclusionary to me.
> Also, sometimes I merge from my phone where there's no chrome extension,
> (maybe I really shouldn't be doing that?).

A large part of Brett's push for moving to a PR workflow was to be
able to merge patches from a tablet on the beach, so I see no reason
not to merge from a phone if you can :)

> I think the solution should be something not webbrowser specific.
>
> One idea is maybe have a bot to do the squash commit, for example by
> commenting on GitHub:
> @merge-bot merge  
>
> So core devs can do the above instead of pressing the commit button. Any
> thoughts on this?
>
> In the meantime, committers, please try to remember and change the # into
> GH- :)

+1 to everything here.

-- 
Zach
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Mariatta Wijaya]

>
> Of course, we would still need to convince people to install it :)


Right, that's the challenge :)
I personally use Chrome (!) and I've been using your Chrome extension, so
thank you!
However, I don't feel comfortable making this available only for a specific
browser user, feels exclusionary to me.
Also, sometimes I merge from my phone where there's no chrome extension,
(maybe I really shouldn't be doing that?).

I think the solution should be something not webbrowser specific.

One idea is maybe have a bot to do the squash commit, for example by
commenting on GitHub:
@merge-bot merge  

So core devs can do the above instead of pressing the commit button. Any
thoughts on this?

In the meantime, committers, please try to remember and change the # into
GH- :)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Berker Peksağ]

On Thu, Jan 25, 2018 at 4:58 PM, Mariatta Wijaya
 wrote:
> It has to be manually edited right before you commit/merge on GitHub.
> I don't think it can be automatically changed? Unless we have some kind of
> post commit hook to amend the commit message.

Perhaps it's possible to edit both title and body fields [1]
automatically before merging via a browser extension. I can try to add
it to https://github.com/berkerpeksag/cpython-bpo-linkify Of course,
we would still need to convince people to install it :)

--Berker

[1] 
https://www.dropbox.com/s/tbf7j8jm66t707r/Screenshot%20from%202018-01-25%2018%3A26%3A05.png?dl=0
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Mariatta Wijaya]

It has to be manually edited right before you commit/merge on GitHub.
I don't think it can be automatically changed? Unless we have some kind of
post commit hook to amend the commit message.

I've been changing it to GH- , so does miss-islington when she backports.

If you see the mixed GH- and # in the backports PR, it's because
miss-islington converted the first one.

On Jan 25, 2018 4:21 AM, "Berker Peksağ"  wrote:

> On Thu, Jan 25, 2018 at 1:42 PM, INADA Naoki 
> wrote:
> > Hi.
> >
> > Devguide says:
> >
> > """
> > Replace the reference to GitHub pull request # with GH-. If
> > the title is too long, the pull request number can be added to the
> > message body.
> > """
> >
> > https://devguide.python.org/gitbootcamp/#accepting-and-
> merging-a-pull-request
> >
> > But there are more # than GH- in commit log.
> > https://github.com/python/cpython/commits/master
> >
> > Where should we go?
> > Encourage GH-? or abandon it and use default #?
>
> I'd personally drop both GH- and # markers. The number of the
> PR is already linked to the commit on GitHub:
> https://www.dropbox.com/s/zzm9f56485pbl1v/Screenshot%
> 20from%202018-01-25%2015%3A14%3A28.png?dl=0
>
> You can even see both styles in the same commit (especially in backport
> PRs)
>
>  bpo-42: Fix spam eggs (GH-2341) (#2211)
>
> --Berker
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> mariatta.wijaya%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Berker Peksağ]

On Thu, Jan 25, 2018 at 1:42 PM, INADA Naoki  wrote:
> Hi.
>
> Devguide says:
>
> """
> Replace the reference to GitHub pull request # with GH-. If
> the title is too long, the pull request number can be added to the
> message body.
> """
>
> https://devguide.python.org/gitbootcamp/#accepting-and-merging-a-pull-request
>
> But there are more # than GH- in commit log.
> https://github.com/python/cpython/commits/master
>
> Where should we go?
> Encourage GH-? or abandon it and use default #?

I'd personally drop both GH- and # markers. The number of the
PR is already linked to the commit on GitHub:
https://www.dropbox.com/s/zzm9f56485pbl1v/Screenshot%20from%202018-01-25%2015%3A14%3A28.png?dl=0

You can even see both styles in the same commit (especially in backport PRs)

 bpo-42: Fix spam eggs (GH-2341) (#2211)

--Berker
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GH-NNNN vs #NNNN in merge commit

[Victor Stinner]

GH prefix avoids confusion between bugs.python.org and GitHub, but GitHub
generates #xxx in the generated commit message on Merge... Each commit
message has to be manually edited. It would be better to get GH
automatically.

Victor

Le 25 janv. 2018 11:44, "INADA Naoki"  a écrit :

> Hi.
>
> Devguide says:
>
> """
> Replace the reference to GitHub pull request # with GH-. If
> the title is too long, the pull request number can be added to the
> message body.
> """
>
> https://devguide.python.org/gitbootcamp/#accepting-and-
> merging-a-pull-request
>
> But there are more # than GH- in commit log.
> https://github.com/python/cpython/commits/master
>
> Where should we go?
> Encourage GH-? or abandon it and use default #?
>
> Regards,
> --
> INADA Naoki  
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> victor.stinner%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] GH-NNNN vs #NNNN in merge commit

[INADA Naoki]

Hi.

Devguide says:

"""
Replace the reference to GitHub pull request # with GH-. If
the title is too long, the pull request number can be added to the
message body.
"""

https://devguide.python.org/gitbootcamp/#accepting-and-merging-a-pull-request

But there are more # than GH- in commit log.
https://github.com/python/cpython/commits/master

Where should we go?
Encourage GH-? or abandon it and use default #?

Regards,
-- 
INADA Naoki  
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com