[python-committers] Re: How can I ignore email notifications on commits mentioning my GitHub handle on CPython forks?

[Guido van Rossum]

Steve Dower's workflow is to use git merge origin/master, and he did that
earlier today, causing the most recent flurry. His repo is a fork of
cpython but its master branch is 1000s of commits behind, so probably
there's some bug in GitHub where the commits being merged are seen as new.

Mariatta, maybe this info helps the GitHub folks figure out how to fix this.

On Tue, Apr 6, 2021 at 10:02 AM Guido van Rossum  wrote:

> I don't have much to add (this occurs to me too and I just bulk-delete the
> messages) but I wonder if the problem might be caused by a situation where
> GitHub doesn't realize that a repo is a fork of cpython? I suppose that
> could happen if someone creates a fresh repo and pushes a local clone of
> cpython to it. I'll ask Zooba what he did.
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/OXAX3IRZMNUSVIZ4EAGKH2CRQN7SL6N4/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: How can I ignore email notifications on commits mentioning my GitHub handle on CPython forks?

[Victor Stinner]

On Tue, Apr 6, 2021 at 6:41 PM Pablo Galindo Salgado
 wrote:
> I think this is a good motivation to use 
> https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/automatically-merging-a-pull-request
>  instead as you can write your own commit message there and schedule the 
> merge.

By the way, currently when you merge a PR (manually), if you modify
the commit title/message *and* the merge fails, DON'T CLICK on "try
again", or the PR is merged with the old commit title/message without
your changes :-( IMO it's a bug in the GitHub UI.

Victor
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/SXCKZK3PS3AGMX6WAHSJ4ZIODVPYDL4F/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: How can I ignore email notifications on commits mentioning my GitHub handle on CPython forks?

[Guido van Rossum]

I don't have much to add (this occurs to me too and I just bulk-delete the
messages) but I wonder if the problem might be caused by a situation where
GitHub doesn't realize that a repo is a fork of cpython? I suppose that
could happen if someone creates a fresh repo and pushes a local clone of
cpython to it. I'll ask Zooba what he did.
-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/IT6UC5GFD3CAN6HF35ZHRZG6CSDF5YJI/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: How can I ignore email notifications on commits mentioning my GitHub handle on CPython forks?

[Pablo Galindo Salgado]

> This is one of the several reasons that I don't like using the PR
description as the commit message when using auto-merge :).

I think this is a good motivation to use
https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/automatically-merging-a-pull-request
instead as you can write your own commit message there and schedule the
merge.


On Tue, 6 Apr 2021 at 16:52, Zachary Ware  wrote:

> On Tue, Apr 6, 2021 at 9:36 AM Victor Stinner  wrote:
> > I'm getting more and more email notifications when a commit contains
> > my GitHub handle ("@vstinner"). For example: "Automerge-Triggered-By:
> > @vstinner".
>
> Yes, this is a pretty substantial failing of GitHub for popular projects :(
>
> > But the problem is that the "automerge" labels uses
> > "Automerge-Triggered-By: @vstinner" syntax. Maybe a small enhancement
> > would be to use ""Automerge-Triggered-By: vstinner" syntax instead
> > (avoid the @).
>
> This is already done; see
>
> https://github.com/python/miss-islington/commit/334c817cecf6c5c7f074ec7dbbad89d491b42f1a
> (we now use `GH:vstinner` to keep it clear that it's a GitHub handle
> without triggering GitHub's automatic linking/mentioning).
>
> > Some developers put my handle in a commit message since it becomes the
> > PR descriptor and sends ping me by email. But then my handle lands
> > into the merged commit message, like:
> > ...
> > I'm not asking you to stop mentioning me. I'm just asking for help how
> > to filter these notifications?
>
> This is one of the several reasons that I don't like using the PR
> description as the commit message when using auto-merge :).  I still
> think we ought to require a new comment with a special marker to
> contain the commit message.  I haven't found time or motivation to
> actually try to make this change, though.
>
> That change wouldn't help with existing messy commits, though, and
> those keep popping up when someone does something weird with their
> fork, like rebasing one stable branch on another.  I'm afraid I don't
> have a good solution for that that doesn't risk masking the messages
> you might actually want to see :(
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-committers@python.org/message/WDPQ5I6NBT6IRDKA4WQPVEWHQIUTPHJ7/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/ZDKEB6CORVOJ4NWUFQDAXWKSV7VSO5LS/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: How can I ignore email notifications on commits mentioning my GitHub handle on CPython forks?

[Mariatta]

> P.S. If anyone with communications channels to Github is planning to lobby
> for changes, I'd prefer a way to say, "Never notify me of @ messages in
> commit messages" followed by a special CC: address for easy filtering,
> followed by "Please don't notify me a second time when an identical commit
> shows up in a fork of a project I've already been notified for" (though all
> three of these would be good improvements with or without the others).


I'm a member of GitHub OS Maintainers feedback group. I can share this
issue with them later today.
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/YH7TPHRMELEYUJ3FBSO6JHMILRFRNFPH/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: How can I ignore email notifications on commits mentioning my GitHub handle on CPython forks?

[Paul Ganssle]

I think the real solution to this should come from Github if we can
convince them that it's worth their time to have a separate notification
category for these things. One short-term solution for this might be to
modify the commit messages that automerge uses. The simplest version of
this would be something like injecting a zero-width space after every @
that is followed by something that could plausibly be a GH username,
e.g. `re.sub("@(?=[a-zA-Z0-9])", "@\u200b", commit_message)`. It would
read the same way but I think wouldn't trigger a mention.

We could presumably also make this a bit more targeted by actually
trying to extract the mentioned user and checking if it's an actual GH
user, and inject the ZWS only then.

We could also use something other than a ZWS. A ZWS is nice because it
won't visually mangle the commit message at all, but it's bad because if
someone copy-pastes something from the commit message they probably
won't know that they have invisible formatting characters in it, and
that might be immensely frustrating. "Only inject a ZWS in the event
that it's a real user" won't necessarily help if people are including
code snippets containing @classmethod 
in them.

Best,
Paul

P.S. If anyone with communications channels to Github is planning to
lobby for changes, I'd prefer a way to say, "Never notify me of @
messages in commit messages" followed by a special CC: address for easy
filtering, followed by "Please don't notify me a second time when an
identical commit shows up in a fork of a project I've already been
notified for" (though all three of these would be good improvements with
or without the others).

On 4/6/21 11:52 AM, Zachary Ware wrote:
> On Tue, Apr 6, 2021 at 9:36 AM Victor Stinner  wrote:
>> I'm getting more and more email notifications when a commit contains
>> my GitHub handle ("@vstinner"). For example: "Automerge-Triggered-By:
>> @vstinner".
> Yes, this is a pretty substantial failing of GitHub for popular projects :(
>
>> But the problem is that the "automerge" labels uses
>> "Automerge-Triggered-By: @vstinner" syntax. Maybe a small enhancement
>> would be to use ""Automerge-Triggered-By: vstinner" syntax instead
>> (avoid the @).
> This is already done; see
> https://github.com/python/miss-islington/commit/334c817cecf6c5c7f074ec7dbbad89d491b42f1a
> (we now use `GH:vstinner` to keep it clear that it's a GitHub handle
> without triggering GitHub's automatic linking/mentioning).
>
>> Some developers put my handle in a commit message since it becomes the
>> PR descriptor and sends ping me by email. But then my handle lands
>> into the merged commit message, like:
>> ...
>> I'm not asking you to stop mentioning me. I'm just asking for help how
>> to filter these notifications?
> This is one of the several reasons that I don't like using the PR
> description as the commit message when using auto-merge :).  I still
> think we ought to require a new comment with a special marker to
> contain the commit message.  I haven't found time or motivation to
> actually try to make this change, though.
>
> That change wouldn't help with existing messy commits, though, and
> those keep popping up when someone does something weird with their
> fork, like rebasing one stable branch on another.  I'm afraid I don't
> have a good solution for that that doesn't risk masking the messages
> you might actually want to see :(
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-committers@python.org/message/WDPQ5I6NBT6IRDKA4WQPVEWHQIUTPHJ7/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/VCMZ52M74XV46CWOSQ4NH5MFQAZW722W/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: How can I ignore email notifications on commits mentioning my GitHub handle on CPython forks?

[Zachary Ware]

On Tue, Apr 6, 2021 at 9:36 AM Victor Stinner  wrote:
> I'm getting more and more email notifications when a commit contains
> my GitHub handle ("@vstinner"). For example: "Automerge-Triggered-By:
> @vstinner".

Yes, this is a pretty substantial failing of GitHub for popular projects :(

> But the problem is that the "automerge" labels uses
> "Automerge-Triggered-By: @vstinner" syntax. Maybe a small enhancement
> would be to use ""Automerge-Triggered-By: vstinner" syntax instead
> (avoid the @).

This is already done; see
https://github.com/python/miss-islington/commit/334c817cecf6c5c7f074ec7dbbad89d491b42f1a
(we now use `GH:vstinner` to keep it clear that it's a GitHub handle
without triggering GitHub's automatic linking/mentioning).

> Some developers put my handle in a commit message since it becomes the
> PR descriptor and sends ping me by email. But then my handle lands
> into the merged commit message, like:
> ...
> I'm not asking you to stop mentioning me. I'm just asking for help how
> to filter these notifications?

This is one of the several reasons that I don't like using the PR
description as the commit message when using auto-merge :).  I still
think we ought to require a new comment with a special marker to
contain the commit message.  I haven't found time or motivation to
actually try to make this change, though.

That change wouldn't help with existing messy commits, though, and
those keep popping up when someone does something weird with their
fork, like rebasing one stable branch on another.  I'm afraid I don't
have a good solution for that that doesn't risk masking the messages
you might actually want to see :(
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/WDPQ5I6NBT6IRDKA4WQPVEWHQIUTPHJ7/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] How can I ignore email notifications on commits mentioning my GitHub handle on CPython forks?

[Victor Stinner]

Hi,

I'm getting more and more email notifications when a commit contains
my GitHub handle ("@vstinner"). For example: "Automerge-Triggered-By:
@vstinner".

The issue is that it's not only commits from the python/cpython GitHub
project, but also on all forks of the python project. Example:
https://github.com/zooba/cpython/commit/9a5e643483578c3a944ceb5aa511d6c24280aedc

"You are receiving this because you were mentioned."

Some email headers:
-
From: Anthony Sottile 
To: "zooba/cpython" 
Cc: Victor Stinner , Mention 
Reply-To: "zooba/cpython"


List-ID: zooba/cpython 
List-Unsubscribe:
,


X-GitHub-Sender: asottile
X-GitHub-Recipient: vstinner
X-GitHub-Reason: mention
-

I can unsubscribe from each python project fork, but more and more
people are forking Python, it doesn't scale :-(

In GitHub > Settings > Emails, I only see the email address used to
"Receives notifications".

In GitHub > Settings > Notifications, I only see a global
"Notifications for all repositories, teams, or conversations you’re
watching." option ("[x] Email [x] Web and Mobile"). There is no
granularity to filter where I'm mentioned (PR review, issue, commit,
etc.).


It seems like Paul Ganssle has the same issue than me:
https://twitter.com/pganssle/status/1379161385863643155


But the problem is that the "automerge" labels uses
"Automerge-Triggered-By: @vstinner" syntax. Maybe a small enhancement
would be to use ""Automerge-Triggered-By: vstinner" syntax instead
(avoid the @).


Some developers put my handle in a commit message since it becomes the
PR descriptor and sends ping me by email. But then my handle lands
into the merged commit message, like:

" @vstinner [noticed on
python-dev](https://mail.python.org/archives/list/python-...@python.org/thread/O3T7SK3BGMFWMLCQXDODZJSBL42AUWTR/)
that there is no what's new or porting entry for removal of asyncio
``loop`` parameter. "

" @vstinner / @corona10, would you mind reviewing this? "

" The changes in this commit are all related to @vstinner's original
review comments of the initial PEP 617 implementation PR. "

" * Added @vstinner News "

" Motivation for this PR (comment from @vstinner in bpo issue): "


I'm not asking you to stop mentioning me. I'm just asking for help how
to filter these notifications?


Note: I'm using Gmail which only supports some filters, it doesn't
support filtering on any email header.

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/OCVQ6IYOVTVYW7ADDNOHKR7JDRBYLM3T/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: NOTE: Python 3.9.3 contains an unintentional ABI incompatibility leading to crashes on 32-bit systems

[Victor Stinner]

Hi,

About this very specific ABI issue, one long term solution would be to
exclude the PyThreadState structure from the C API, to not rely on it
the ABI level.

I started to add getter functions in Python 3.9:
PyThreadState_GetInterpreter(), PyThreadState_GetFrame() and
PyThreadState_GetID(). I'm working on updating C extensions to use
these getter functions, rather than accessing directly PyThreadState
members. I wrote a new pythoncapi_compat.h header file (in an exteral
project, pythoncapi_compat) to provide getter functions to Python
2.7-3.8. Cython gives me most of the work, since it gets and sets many
PyThreadState members.

You can follow the progress at: https://bugs.python.org/issue39947

Victor

On Sat, Apr 3, 2021 at 9:45 PM Łukasz Langa  wrote:
>
> The memory layout of PyThreadState was unintentionally changed in the recent 
> 3.9.3 bugfix release. This leads to crashes on 32-bit systems when importing 
> binary extensions compiled for Python 3.9.0 - 3.9.2. This is a regression.
>
> We will be releasing a hotfix 3.9.4 around 24 hours from now to address this 
> issue and restore ABI compatibility with C extensions built for Python 3.9.0 
> - 3.9.2.
>
> Details:
> https://bugs.python.org/issue43710
>
>
> - Ł
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-committers@python.org/message/OUCNKMFBNGFK2AI4B7S7MF5O6UVLBSMB/
> Code of Conduct: https://www.python.org/psf/codeofconduct/



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/BOEUCEILH5TWMZIY3DIHTLX3S7O2XKIF/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] [RELEASE] The last Python 3.10 alpha (3.10.0a7) is available - Prepare for beta freeze

[Pablo Galindo Salgado]

Br. do you feel that? That's the chill of *beta freeze* coming
closer. Meanwhile, your friendly CPython release team doesn’t
rest even on holidays and we have prepared a shiny new release for you:
Python 3.10.0a7.


Dear fellow core developer:
This alpha is the last release before feature freeze (2021-05-03), so make
sure that all new features and PEPs are landed in the master branch before
we
release the first beta. Please, be specially mindfully to check the CI and
the buildbots, maybe even using the test-with-buildbots label in GitHub
before
merging so the release team don’t need to fix a bunch of reference leaks or
platform-specific problems on the first beta release.



*Go get the new alpha here:*
https://www.python.org/downloads/release/python-3100a7/


*Python 3.10.0a7*Release Date: April 5, 2021

This is an early developer preview of Python 3.10

*Major new features of the 3.10 series, compared to 3.9*

Python 3.10 is still in development. This release, 3.10.0a7 is the last of
seven planned alpha releases. Alpha releases are intended to make it easier
to test the current state of new features and bug fixes and to test the
release process. During the alpha phase, features may be added up until the
start of the beta phase (2021-05-03) and, if necessary, may be modified or
deleted up until the release candidate phase (2021-10-04). Please keep in
mind that this is a preview release and its use is not recommended for
production environments.

Many new features for Python 3.10 are still being planned and written.
Among the new major new features and changes so far:

PEP 623 – Deprecate and prepare for the removal of the wstr member in
PyUnicodeObject.
PEP 604 – Allow writing union types as X | Y
PEP 612 – Parameter Specification Variables
PEP 626 – Precise line numbers for debugging and other tools.
bpo-38605: from __future__ import annotations (PEP 563) is now the default.
PEP 618 – Add Optional Length-Checking To zip.
bpo-12782: Parenthesized context managers are now officially allowed.
PEP 632 – Deprecate distutils module.
PEP 613 – Explicit Type Aliases
PEP 634 – Structural Pattern Matching: Specification
PEP 635 – Structural Pattern Matching: Motivation and Rationale
PEP 636 – Structural Pattern Matching: Tutorial
PEP 644 – Require OpenSSL 1.1.1 or newer
PEP 624 – Remove Py_UNICODE encoder APIs
PEP 597 – Add optional EncodingWarning
(Hey, fellow core developer, if a feature you find important is missing
from this list, let Pablo know.)
The next pre-release of Python 3.10 will be 3.10.0b1 ( the first beta
release and feature freeze ), currently scheduled for Monday, 2021-05-03.

*And now for something completely different*

In physics, the twin paradox is a thought experiment in special relativity
involving identical twins, one of whom makes a journey into space in a
high-speed rocket and returns home to find that the twin who remained on
Earth has aged more. This result appears puzzling because each twin sees
the other twin as moving, and so, as a consequence of an incorrect and
naive application of time dilation and the principle of relativity, each
should paradoxically find the other to have aged less. However, this
scenario can be resolved by realising that the travelling twin is
undergoing acceleration, which makes him a non-inertial observer. In both
views, there is no symmetry between the spacetime paths of the twins.
Therefore, the twin paradox is not a paradox in the sense of a logical
contradiction.

Your friendly release team,
Pablo Galindo Salgado @pablogsal
Ned Deily @nad
Steve Dower @steve.dower
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/G2J3SBJ4EOW6MQZZJQNTXKHRWTAVBMKP/
Code of Conduct: https://www.python.org/psf/codeofconduct/