[Python-Dev] Re: Roundup to GitHub Issues migration

2021-06-22 Thread Tiziano Zito 

Hi,

On Mon 21 Jun, 13:48 +0200, Victor Stinner  wrote:

The requirement for a GitHub account was well known when PEP 581 was
accepted. The PEP was approved. It's now time to move on!


I think it is important to notice that GitHub actively blocks user registration 
and activity from countries that are sanctioned by the US government. At least 
in 2019 GitHub was blocking users from IPs located in Cuba, North Corea, Syria, 
Crimea, Iran, etc (see for example [1]). They block, of course, users of any 
nationality, if they happen to be traveling or living in those countries.

I could not find any clear official statement from GitHub, but I think this is 
something to consider nonetheless, especially now that the Python community is 
making great efforts to become more welcoming and diverse. The fact of 
excluding a significant part of the potential contributors based on a random 
list by a random government over which the Python community as a whole has no 
influence whatsoever seems a move in the wrong direction.

My 2c,
Tiziano

[1] https://techcrunch.com/2019/07/29/github-ban-sanctioned-countries/

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/ZIDV6T2UB7J2WPPSBVSA77TD62JMV3HK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Making PY_SSIZE_T_CLEAN not mandatory.

2021-06-22 Thread Petr Viktorin 

On 21. 06. 21 20:20, Guido van Rossum wrote:
Okay, I think your evidence can then be discounted. Really, any app that 
relies on the publicly installed Python runs a serious risk of breaking 
when that Python gets updated, regardless of whether the ABI changes or not.


Unfortunately, this includes scripts for any extensible software 
(Mayavi, GIMP, etc) -- even if Python is bundled with that software, 
upgrading the software risks breaking the scripts.



On Mon, Jun 21, 2021 at 2:46 AM Baptiste Carvello 
> wrote:


Hi,

Le 18/06/2021 à 21:00, Guido van Rossum a écrit :
 > Can you elaborate on that use case? Which two applications are you
 > thinking of, and what was your goal in driving them? This sounds
 > interesting but I haven’t encountered this myself.

Well, I'm not sure the case I was thinking of is still relevant to
anything: that was plotting 3D crystal models using crystallography
library CCTBX [1] and visualization application Mayavi [2], some 15-20
years ago. BTW, I misremembered a bit: only CCTBX insisted on using a
vendored python ("libtbx.python"), Mayavi used the system python.
Anyway, it was more pain to make Mayavi use libtbx.python, than to make
CCTBX work with the system python.

Also, I must admit that even applications embedding the system python
can have some limitations. For example, GIMP and GDB can execute python
scripts, but their API can't be "imported" from the outside. Which means
no arguments passed to the script over the command line ("sys.argv"), no
venvs, no REPL. But at least you can install additional packages (pip /
distro package manager) and limitations can be more or less hacked
around. For a sophisticated example, the debugger extension Voltron [3]
provides REPL access to GDB objects over a client-server connexion.

Cheers,
Baptiste

[1] https://cci.lbl.gov/docs/cctbx/ 
[2] https://docs.enthought.com/mayavi/mayavi/

[3] https://github.com/snare/voltron 

 > On Fri, Jun 18, 2021 at 09:44 Baptiste Carvello
 > mailto:[email protected]>
 > >> wrote:
 >
 >     Le 18/06/2021 à 08:50, Paul Moore a écrit :
 >     >
 >     > IMO it doesn't. However for certain applications (the sort
of thing I
 >     > was referring to) - where the user is writing their own
scripts and
 >     > the embedding API is used merely to expose an interface to
the Python
 >     > language, dynamically linking to whatever version of Python
the user
 >     > has installed can be precisely the right thing to do - the
user gets
 >     > access to the version of the language they expect, the
installed
 >     > packages they expect to see, etc.
 >
 >     As a user, I second this. When trying to drive applications
from the
 >     outside (as opposed to extending them through plugins), it is
annoying
 >     when two applications won't work together because each one
insists on
 >     using its own vendored python.
 >
 >     Of course, there are often real blockers, such as
incompatible event
 >     loops. But not always…
 >
 >     Cheers,
 >     Baptiste
 >     ___
 >     Python-Dev mailing list -- [email protected]

 >     >
 >     To unsubscribe send an email to [email protected]

 >     >
 > https://mail.python.org/mailman3/lists/python-dev.python.org/

 >     Message archived at
 >

https://mail.python.org/archives/list/[email protected]/message/PPKL7466BIG6DPCUIJURLE5ZGFNHBNSM/


 >     Code of Conduct: http://python.org/psf/codeofconduct/

 >
 > --
 > --Guido (mobile)
 >

___
Python-Dev mailing list -- [email protected]

To unsubscribe send an email to [email protected]

https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived at

https://mail.python.org/archives/list/[email protected]/message/KP3SE6UWSV3VDCJOWCXUZIBPDWFJHRLU/

[Python-Dev] Re: Making PY_SSIZE_T_CLEAN not mandatory.

2021-06-22 Thread Henk-Jaap Wagenaar 
On Tue, 22 Jun 2021 at 10:06, Petr Viktorin  wrote:

> On 21. 06. 21 20:20, Guido van Rossum wrote:
> > Okay, I think your evidence can then be discounted. Really, any app that
> > relies on the publicly installed Python runs a serious risk of breaking
> > when that Python gets updated, regardless of whether the ABI changes or
> not.
>
> Unfortunately, this includes scripts for any extensible software
> (Mayavi, GIMP, etc) -- even if Python is bundled with that software,
> upgrading the software risks breaking the scripts.
>
>
I'm confused by what you mean by this, or why it is a problem?

If I upgrade GIMP (and it vendors some version/variant of Python), it is
not unreasonable that this would break a script that I have written in
GIMPython? (GIMP should probably mention that it has changed its Python and
how in the changelog/release notes)

If I upgrade my OS, and I use the system Python, scripts I have written
might break too.

(Of course, GIMP is a placeholder here, I do not actually know what it does
in terms of Python (vendoring), if at all.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/FPTXDP3BLIPJH3WTFPTORTC5HDBJC2L5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Making PY_SSIZE_T_CLEAN not mandatory.

2021-06-22 Thread Petr Viktorin 


On June 22, 2021 11:18:46 AM GMT+02:00, Henk-Jaap Wagenaar 
 wrote:
>On Tue, 22 Jun 2021 at 10:06, Petr Viktorin  wrote:
>
>> On 21. 06. 21 20:20, Guido van Rossum wrote:
>> > Okay, I think your evidence can then be discounted. Really, any app
>that
>> > relies on the publicly installed Python runs a serious risk of
>breaking
>> > when that Python gets updated, regardless of whether the ABI
>changes or
>> not.
>>
>> Unfortunately, this includes scripts for any extensible software
>> (Mayavi, GIMP, etc) -- even if Python is bundled with that software,
>> upgrading the software risks breaking the scripts.
>>
>>
>I'm confused by what you mean by this, or why it is a problem?

Not necessarily a problem, I just want to point out that there are situations 
where you need to depend on Python managed by someone else.

>If I upgrade GIMP (and it vendors some version/variant of Python), it
>is
>not unreasonable that this would break a script that I have written in
>GIMPython? (GIMP should probably mention that it has changed its Python
>and
>how in the changelog/release notes)
>
>If I upgrade my OS, and I use the system Python, scripts I have written
>might break too.
>
>(Of course, GIMP is a placeholder here, I do not actually know what it
>does
>in terms of Python (vendoring), if at all.

GIMP itself doesn't, but it's sometimes distributed in flatpak/appimage with 
its own bundled/pinned Python. (AFAIK it's usually Python 2.7, for a few 
reasons; one of them being that upgrading would break scripts)

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/ABK447E74NUXN6JUSKH6Y7WIQNWHQPTS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Roundup to GitHub Issues migration

2021-06-22 Thread Sebastian Rittau 

Am 22.06.21 um 10:00 schrieb Tiziano Zito:
I think it is important to notice that GitHub actively blocks user 
registration and activity from countries that are sanctioned by the US 
government. At least in 2019 GitHub was blocking users from IPs 
located in Cuba, North Corea, Syria, Crimea, Iran, etc (see for 
example [1]). They block, of course, users of any nationality, if they 
happen to be traveling or living in those countries.


I could not find any clear official statement from GitHub, but I think 
this is something to consider nonetheless, especially now that the 
Python community is making great efforts to become more welcoming and 
diverse. The fact of excluding a significant part of the potential 
contributors based on a random list by a random government over which 
the Python community as a whole has no influence whatsoever seems a 
move in the wrong direction. 


I was overall in favor of moving Python issues over to GitHub, for 
convenience, easier access, and a more usable interface. But I think the 
issue above is a showstopper. This problem of course already exists for 
pull requests, but discriminating against users based on their place of 
residence is absolutely unacceptable to me. In fact, it is directly in 
violation to the PSF's mission statement that says in part: "... to 
support and facilitate the growth of a diverse and international 
community of Python programmers." This issue hasn't been addresses in 
PEP 581, so I believe it wasn't considered when accepting the PEP. But 
it's serious enough that I would like to ask the steering council to 
reconsider their decision to accept PEP 581.


 - Sebastian

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/JWNL7FSDK6727ED73EKSQGELITP3F4I2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Roundup to GitHub Issues migration

2021-06-22 Thread Nathaniel Smith 
On Tue, Jun 22, 2021 at 4:42 AM Sebastian Rittau  wrote:
>
> Am 22.06.21 um 10:00 schrieb Tiziano Zito:
> > I think it is important to notice that GitHub actively blocks user
> > registration and activity from countries that are sanctioned by the US
> > government. At least in 2019 GitHub was blocking users from IPs
> > located in Cuba, North Corea, Syria, Crimea, Iran, etc (see for
> > example [1]). They block, of course, users of any nationality, if they
> > happen to be traveling or living in those countries.
> >
> > I could not find any clear official statement from GitHub, but I think
> > this is something to consider nonetheless, especially now that the
> > Python community is making great efforts to become more welcoming and
> > diverse. The fact of excluding a significant part of the potential
> > contributors based on a random list by a random government over which
> > the Python community as a whole has no influence whatsoever seems a
> > move in the wrong direction.
>
> I was overall in favor of moving Python issues over to GitHub, for
> convenience, easier access, and a more usable interface. But I think the
> issue above is a showstopper. This problem of course already exists for
> pull requests, but discriminating against users based on their place of
> residence is absolutely unacceptable to me. In fact, it is directly in
> violation to the PSF's mission statement that says in part: "... to
> support and facilitate the growth of a diverse and international
> community of Python programmers." This issue hasn't been addresses in
> PEP 581, so I believe it wasn't considered when accepting the PEP. But
> it's serious enough that I would like to ask the steering council to
> reconsider their decision to accept PEP 581.

As much as we might wish otherwise, the PSF is also a US entity and
has to comply with US laws. GitHub's official policy at

   https://docs.github.com/en/github/site-policy/github-and-trade-controls

gives the impression that they're reading the law as narrowly as
possible, and allowing access to every person that they legally can.
In particular, that policy page claims that there are no restrictions
on users from Cuba or Iran, and that users from Syria and Crimea are
allowed to participate in OSS projects, just not give GitHub money.
(They do disallow use by North Koreans and "Specially Designated
Nationals".)

It is even possible for the PSF to do better without breaking the law?
I'm not an expert in this area at all, so happy to be educated if
so...

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/JLTR2LD73ZRS6UQJQVKF2XOP467RTK2U/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Roundup to GitHub Issues migration

2021-06-22 Thread Antoine Pitrou 
On Tue, 22 Jun 2021 05:01:17 -0700
Nathaniel Smith  wrote:
> 
> As much as we might wish otherwise, the PSF is also a US entity and
> has to comply with US laws. GitHub's official policy at
> 
>https://docs.github.com/en/github/site-policy/github-and-trade-controls
> 
> gives the impression that they're reading the law as narrowly as
> possible, and allowing access to every person that they legally can.
> In particular, that policy page claims that there are no restrictions
> on users from Cuba or Iran, and that users from Syria and Crimea are
> allowed to participate in OSS projects, just not give GitHub money.

This would be worth checking if possible.

If individuals of any country (mostly? except North Korea?) are able to
participate as volunteers, then it may be fine, otherwise it is very
worrying.
But the question is also whether Github might change its policy in the
future.

> It is even possible for the PSF to do better without breaking the law?

Who knows, the PSF might be breaking the law already (or not). The
question is whether authorities would be interested in going after a
smallish community of individuals (compared to the Github user base,
python-dev is negligible).

Also, the python-dev community may always contemplate a move under a
different umbrella if necessary. Github won't change its umbrella to
just to make things easier for us.

Regards

Antoine.


___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/HIOQQFWWJY6BYH23ESQ4SHUEJF2KJEEU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Roundup to GitHub Issues migration

2021-06-22 Thread Sebastian Rittau 
(For some weird reason, I didn't get this mail via the list, only the 
private copy, so I might break threading by replying via my private copy.)


Am 22.06.21 um 14:01 schrieb Nathaniel Smith:


As much as we might wish otherwise, the PSF is also a US entity and
has to comply with US laws. GitHub's official policy at

https://docs.github.com/en/github/site-policy/github-and-trade-controls

gives the impression that they're reading the law as narrowly as
possible, and allowing access to every person that they legally can.
In particular, that policy page claims that there are no restrictions
on users from Cuba or Iran, and that users from Syria and Crimea are
allowed to participate in OSS projects, just not give GitHub money.
(They do disallow use by North Koreans and "Specially Designated
Nationals".)

It is even possible for the PSF to do better without breaking the law?
I'm not an expert in this area at all, so happy to be educated if
so...

-n

I'm not much interested in theory. Are people currently blocked from 
participating in Python issues due to their country of residence? Will 
people be blocked after the move to GitHub? If the answer to the second 
question is "yes", the move would violate one of the core principles of 
the PSF. If the answer to the first question is "yes", we need to 
consider transferring the bug tracker to an organization in a country 
whose laws better align with the goals of the PSF.


 - Sebastian

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/NG4OCTORMKAKXC5SSUC4TAJEOZN5ZAWF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Roundup to GitHub Issues migration

2021-06-22 Thread Baptiste Carvello 
Hi,

Le 21/06/2021 à 23:31, Christopher Barker a écrit :
> 
>   >  [...] Github is a
>   >  developers' social network, "mere" users are much less likely to want to
>   >  be part of it. [...]
> 
> 
> But you don’t need to be “part of it” in any meaningful way. One only
> needs to create an account, which could be quite anonymous, and even
> temporary.

I don't believe you can actually use temporary accounts. Github only
allows one account per physical person, and if I delete my account, then
later open a new one from the same IP and/or with a related e-mail
address, I would expect them to either blocklist me, or resurrect the
old account and copy the data to the new one. If anyone really tried,
please correct me.

> [...]
> Also: cPython is a large, complex, and mature project. I don't think
> many non-developers can even identify a true bug, much less write a
> helpful big report. [...]

There is a genuine question here: bluntly said, are bug reports still
welcome? In the tradition of the Free Software movement, reporting bugs
is considered an act of good citizenship. If the scarcity of developer
time makes it no longer be the case for cPython, it'd rather be broadly
communicated to users.

> [...] I don’t mind needing an account to
> contribute to a conversation.

I do, if a single company becomes the gatekeeper of most conversations
in a whole field of endeavor. Alas, I have to admit being in the
minority, so let this part of the discussion rest.

Cheers,
Baptiste
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/J356YY7BI3IFPRZ44PHKIV2MNDIXSUQZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Making PY_SSIZE_T_CLEAN not mandatory.

2021-06-22 Thread Baptiste Carvello 
Hi,

I'm afraid we are talking past each other. In my case, the applications
are either part of my Python-based work setup, which needs to be rebuilt
anyway in the very infrequent occurrence of a major Python upgrade (I
could get away with using the system python for that on a "stable" distro).

Or they are installed using my distro's package manager, which takes
care of upgrading dependent packages together. This is the classical
"DLL hell" problem, right? Or is there some Python specificity that I
don't get?

Cheers,
Baptiste

Le 21/06/2021 à 20:20, Guido van Rossum a écrit :
> Okay, I think your evidence can then be discounted. Really, any app that
> relies on the publicly installed Python runs a serious risk of breaking
> when that Python gets updated, regardless of whether the ABI changes or not.
> 
> On Mon, Jun 21, 2021 at 2:46 AM Baptiste Carvello
>  > wrote:
> 
> Hi,
> 
> Le 18/06/2021 à 21:00, Guido van Rossum a écrit :
> > Can you elaborate on that use case? Which two applications are you
> > thinking of, and what was your goal in driving them? This sounds
> > interesting but I haven’t encountered this myself.
> 
> Well, I'm not sure the case I was thinking of is still relevant to
> anything: that was plotting 3D crystal models using crystallography
> library CCTBX [1] and visualization application Mayavi [2], some 15-20
> years ago. BTW, I misremembered a bit: only CCTBX insisted on using a
> vendored python ("libtbx.python"), Mayavi used the system python.
> Anyway, it was more pain to make Mayavi use libtbx.python, than to make
> CCTBX work with the system python.
> 
> Also, I must admit that even applications embedding the system python
> can have some limitations. For example, GIMP and GDB can execute python
> scripts, but their API can't be "imported" from the outside. Which means
> no arguments passed to the script over the command line ("sys.argv"), no
> venvs, no REPL. But at least you can install additional packages (pip /
> distro package manager) and limitations can be more or less hacked
> around. For a sophisticated example, the debugger extension Voltron [3]
> provides REPL access to GDB objects over a client-server connexion.
> 
> Cheers,
> Baptiste
> 
> [1] https://cci.lbl.gov/docs/cctbx/
> [2] https://docs.enthought.com/mayavi/mayavi/
> [3] https://github.com/snare/voltron
> 
> > On Fri, Jun 18, 2021 at 09:44 Baptiste Carvello
> >  
> >  >> wrote:
> >
> >     Le 18/06/2021 à 08:50, Paul Moore a écrit :
> >     >
> >     > IMO it doesn't. However for certain applications (the sort
> of thing I
> >     > was referring to) - where the user is writing their own
> scripts and
> >     > the embedding API is used merely to expose an interface to
> the Python
> >     > language, dynamically linking to whatever version of Python
> the user
> >     > has installed can be precisely the right thing to do - the
> user gets
> >     > access to the version of the language they expect, the installed
> >     > packages they expect to see, etc.
> >
> >     As a user, I second this. When trying to drive applications
> from the
> >     outside (as opposed to extending them through plugins), it is
> annoying
> >     when two applications won't work together because each one
> insists on
> >     using its own vendored python.
> >
> >     Of course, there are often real blockers, such as incompatible
> event
> >     loops. But not always…
> >
> >     Cheers,
> >     Baptiste
> >     ___
> >     Python-Dev mailing list -- [email protected]
> 
> >     >
> >     To unsubscribe send an email to [email protected]
> 
> >      >
> >     https://mail.python.org/mailman3/lists/python-dev.python.org/
> >     Message archived at
> >   
>  
> https://mail.python.org/archives/list/[email protected]/message/PPKL7466BIG6DPCUIJURLE5ZGFNHBNSM/
> >     Code of Conduct: http://python.org/psf/codeofconduct/
> >
> > --
> > --Guido (mobile)
> >
> 
> ___
> Python-Dev mailing list -- [email protected]
> 
> To unsubscribe send an email to [email protected]
> 
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> 
> https:/

[Python-Dev] Re: Roundup to GitHub Issues migration

2021-06-22 Thread Terry Reedy 

On 6/22/2021 4:00 AM, Tiziano Zito wrote:

Hi,

On Mon 21 Jun, 13:48 +0200, Victor Stinner  wrote:

The requirement for a GitHub account was well known when PEP 581 was
accepted. The PEP was approved. It's now time to move on!


I think it is important to notice that GitHub actively blocks user 
registration and activity from countries that are sanctioned by the US 
government. At least in 2019 GitHub was blocking users from IPs located 
in Cuba, North Corea, Syria, Crimea, Iran, etc (see for example [1]). 
They block, of course, users of any nationality, if they happen to be 
traveling or living in those countries.



[1] https://techcrunch.com/2019/07/29/github-ban-sanctioned-countries/


It says that this applied to private repositories and paid organization 
repositories but not public, open source repositories.  I don't know if 
the forks of python needed to submit PRs are affected, but I belive 
these are both free and public.


https://docs.github.com/en/github/site-policy/github-and-trade-controls

Says that Github has an explicit license to serve Iran and most services 
are available in Cuba.


--
Terry Jan Reedy

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/TTAZO263HP2GCHE2KRTWLI2FDTC2AG4C/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Roundup to GitHub Issues migration

2021-06-22 Thread Terry Reedy 

On 6/22/2021 4:40 AM, Baptiste Carvello wrote:


Le 21/06/2021 à 23:31, Christopher Barker a écrit :

Also: cPython is a large, complex, and mature project. I don't think
many non-developers can even identify a true bug, much less write a
helpful big report. [...]



There is a genuine question here: bluntly said, are bug reports still
welcome? 


The above is one person's viewpoint.  Since he is not a CPython core 
developer, I am not sure what he means by 'developer'.  Anyone who 
programs in Python 'developes' the programs they write.


It is true that students and beginners tend to make less useful reports. 
 But yes, bug reports are still welcome.



In the tradition of the Free Software movement, reporting bugs
is considered an act of good citizenship. If the scarcity of developer
time makes it no longer be the case for cPython, it'd rather be broadly
communicated to users.


What we need is for people to be less shy about helping with *other* 
people's reports.


--
Terry Jan Reedy


___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/GPGYOVA5FXPWQBDZWGBU4BVNFMKBDGOZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Roundup to GitHub Issues migration

2021-06-22 Thread David Mertz 
This is perhaps a different issue, but perhaps not. PSF grants are also
subject to absurd and convoluted (and difficult to interpret) "export
control" rules. Also rules subject to change at any moment at the whims of
the latest US government grandstanding.

USA incorporation definitely has drawbacks, as well as advantages.

On Tue, Jun 22, 2021, 7:46 AM Sebastian Rittau  wrote:

> Am 22.06.21 um 10:00 schrieb Tiziano Zito:
> > I think it is important to notice that GitHub actively blocks user
> > registration and activity from countries that are sanctioned by the US
> > government. At least in 2019 GitHub was blocking users from IPs
> > located in Cuba, North Corea, Syria, Crimea, Iran, etc (see for
> > example [1]). They block, of course, users of any nationality, if they
> > happen to be traveling or living in those countries.
> >
> > I could not find any clear official statement from GitHub, but I think
> > this is something to consider nonetheless, especially now that the
> > Python community is making great efforts to become more welcoming and
> > diverse. The fact of excluding a significant part of the potential
> > contributors based on a random list by a random government over which
> > the Python community as a whole has no influence whatsoever seems a
> > move in the wrong direction.
>
> I was overall in favor of moving Python issues over to GitHub, for
> convenience, easier access, and a more usable interface. But I think the
> issue above is a showstopper. This problem of course already exists for
> pull requests, but discriminating against users based on their place of
> residence is absolutely unacceptable to me. In fact, it is directly in
> violation to the PSF's mission statement that says in part: "... to
> support and facilitate the growth of a diverse and international
> community of Python programmers." This issue hasn't been addresses in
> PEP 581, so I believe it wasn't considered when accepting the PEP. But
> it's serious enough that I would like to ask the steering council to
> reconsider their decision to accept PEP 581.
>
>   - Sebastian
>
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/JWNL7FSDK6727ED73EKSQGELITP3F4I2/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/6RKRCKGUCCBQIH6JVWQSXDZV6GVISMSL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Roundup to GitHub Issues migration

2021-06-22 Thread Brett Cannon 
On Mon, Jun 21, 2021 at 4:09 PM Glenn Linderman 
wrote:

> On 6/21/2021 2:31 PM, Christopher Barker wrote:
>
>
> By contrast, requiring a github account for reporting bugs also makes
>> python an unwelcoming place for non-developers in general. Github is a
>> developers' social network, "mere" users are much less likely to want to
>> be part of it. Many will just silently abandon their bug report.
>
>
> But you don’t need to be “part of it” in any meaningful way. One only
> needs to create an account, which could be quite anonymous, and even
> temporary.
>
> And is no harder, and probably easier, than creating an account on a
> Python-specific site.
>
> Also: cPython is a large, complex, and mature project. I don't think many
> non-developers can even identify a true bug, much less write a helpful big
> report. There are many other ways to be involved in and contribute to the
> Python community that don't require a gitHub (or any) account.
>
> I understand the issue here — I feel that way about businesses that use
> Facebook for their website. But in that case, I can’t even read it without
> a Facebook account. I don’t mind needing an account to contribute to a
> conversation.
>
> And while GitHub  has become the dominant player in Open Source
> development— it has not (yet?) reached out to control much else.
>
> -CHB
>
>
> With all due respect to Microsoft, who has contributed significantly to
> Python development, and continues to do, some people don't care for some of
> Microsoft's policy and actions, and Microsoft owns GitHub, so your last
> paragraph is somewhat naive, at best.
>
> So what is the difference between a GitHub account, and Microsoft account?
>

They are entirely different and separate; there's no relation there at all.

One thing I will remind people is I personally have led the work to move
this project from:

   1. SourceForge to our own infrastructure
   2. Mercurial to git
   3. Our own infrastructure to GitHub for code management

So if GitHub were to do something we don't like we can always move
platforms again.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/7BKMC5OUXXFXZAKD5HOZ7KZO5YTTDEB7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Roundup to GitHub Issues migration

2021-06-22 Thread Glenn Linderman 

On 6/22/2021 12:52 PM, Brett Cannon wrote:



On Mon, Jun 21, 2021 at 4:09 PM Glenn Linderman > wrote:


On 6/21/2021 2:31 PM, Christopher Barker wrote:


By contrast, requiring a github account for reporting bugs
also makes
python an unwelcoming place for non-developers in general.
Github is a
developers' social network, "mere" users are much less likely
to want to
be part of it. Many will just silently abandon their bug report.


But you don’t need to be “part of it” in any meaningful way. One
only needs to create an account, which could be quite anonymous,
and even temporary.

And is no harder, and probably easier, than creating an account
on a Python-specific site.

Also: cPython is a large, complex, and mature project. I don't
think many non-developers can even identify a true bug, much less
write a helpful big report. There are many other ways to be
involved in and contribute to the Python community that don't
require a gitHub (or any) account.

I understand the issue here — I feel that way about businesses
that use Facebook for their website. But in that case, I can’t
even read it without a Facebook account. I don’t mind needing an
account to contribute to a conversation.

And while GitHub  has become the dominant player in Open Source
development— it has not (yet?) reached out to control much else.

-CHB


With all due respect to Microsoft, who has contributed
significantly to Python development, and continues to do, some
people don't care for some of Microsoft's policy and actions, and
Microsoft owns GitHub, so your last paragraph is somewhat naive,
at best.

So what is the difference between a GitHub account, and Microsoft
account?


They are entirely different and separate; there's no relation there at 
all.


Good, but given the Skype experience, it is questionable how long they 
will stay that way.


One thing I will remind people is I personally have led the work to 
move this project from:


 1. SourceForge to our own infrastructure
 2. Mercurial to git
 3. Our own infrastructure to GitHub for code management

So if GitHub were to do something we don't like we can always move 
platforms again.


Indeed, but platform churn slows contributions, too.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/5ST6GPPTTCXSRE26COVMH4A4KQH2CVHM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Roundup to GitHub Issues migration

2021-06-22 Thread Terry Reedy 

On 6/22/2021 3:52 PM, Brett Cannon wrote:

One thing I will remind people is I personally have led the work to move 
this project from:


 1. SourceForge to our own infrastructure
 2. Mercurial to git
 3. Our own infrastructure to GitHub for code management


At this point, I (once a skeptic) agree that the migration is an overall 
improvement, with CI being the roughest.


As for issue migration: github PRs are much 'richer' in info than 
Rietveld reviews, and there is now duplication of information with bpo 
issues.  (Where synchonization is not automated, this can be a nuisance.)


This means to me that the github issue metadata can be simplified. 
After making the migration easier, this will mean less bad metadata to 
be corrected by triagers.


With 2.x gone and a backport flow, essentially all issues are for main, 
so leave version tags off the issue (and eliminate the need to update 
them!).  [3.x] in PR titles and backport labels are enough.  Backport 
labels imply 'behavior' versus 'enhancement.


Stage info is also on the PR.

--
Terry Jan Reedy

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/RM2ETTE2TNSC6W7QCG2HZHW4D72IWUGU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Roundup to GitHub Issues migration

2021-06-22 Thread Irit Katriel via Python-Dev 
On Tue, Jun 22, 2021 at 11:22 PM Terry Reedy  wrote:

>
> With 2.x gone and a backport flow, essentially all issues are for main,
> so leave version tags off the issue (and eliminate the need to update
> them!).


For enhancement requests I agree we probably don't need to keep updating
the version (though it might be useful to know which version the user was
looking at when coming up with the suggestion).

But I think for a bug report it's useful to know the most recent version on
which the bug was reproduced.
A large part of triage work is to check whether a bug report is still
relevant. If you see "version 3.5" then it makes sense to check on a
current version and either update the issue or close it.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/2UWBN6METJ3WRJJF2ZCQDCHTGOPNQC7V/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Roundup to GitHub Issues migration

2021-06-22 Thread Ned Deily 
On Jun 22, 2021, at 18:35, Irit Katriel via Python-Dev  
wrote:
> On Tue, Jun 22, 2021 at 11:22 PM Terry Reedy  wrote:
>> With 2.x gone and a backport flow, essentially all issues are for main, 
>> so leave version tags off the issue (and eliminate the need to update 
>> them!).
> For enhancement requests I agree we probably don't need to keep updating the 
> version (though it might be useful to know which version the user was looking 
> at when coming up with the suggestion).
> 
> But I think for a bug report it's useful to know the most recent version on 
> which the bug was reproduced.
> A large part of triage work is to check whether a bug report is still 
> relevant. If you see "version 3.5" then it makes sense to check on a current 
> version and either update the issue or close it.  

I think this points out a problem with our current bug system and one that it 
would be good to try to resolve in migrating to a new system: that is, the 
ambiguity of the "version" metadata in an issue. Today, that list of versions 
is used in at least three different ways: 1. to document in what Python 
versions the issue is present; 2. to document in what Python versions the issue 
should be fixed, 3. to document in what versions the issue was fixed. In many, 
probably most, cases, the "version" field of a particular issue is used in both 
ways. When the issue is opened, the version is often set to the versions 
affected. Then at various stages in its lifecycle, the issue's version field 
will generally be changed to (possibly) reflect the candidate versions for 
potential fixes (based on current policy) and later (possibly) to the versions 
for which a fix was actually merged. The various sets  of versions are useful 
information for different purposes. It would be good to try to find a way 
 to retain both, i.e. something like "affected versions", "targeted versions", 
and "fixed versions". In any case, resolving the current ambiguity would be 
good and could also save triage and housekeeping work.

--
  Ned Deily
  [email protected] -- []

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/YXDKYWE7IPXSPOV7EY2RCAPSHE27CE4I/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Roundup to GitHub Issues migration

2021-06-22 Thread Brett Cannon 
On Tue., Jun. 22, 2021, 14:50 Glenn Linderman, 
wrote:

> On 6/22/2021 12:52 PM, Brett Cannon wrote:
>
>
>
> On Mon, Jun 21, 2021 at 4:09 PM Glenn Linderman 
> wrote:
>
>> On 6/21/2021 2:31 PM, Christopher Barker wrote:
>>
>>
>> By contrast, requiring a github account for reporting bugs also makes
>>> python an unwelcoming place for non-developers in general. Github is a
>>> developers' social network, "mere" users are much less likely to want to
>>> be part of it. Many will just silently abandon their bug report.
>>
>>
>> But you don’t need to be “part of it” in any meaningful way. One only
>> needs to create an account, which could be quite anonymous, and even
>> temporary.
>>
>> And is no harder, and probably easier, than creating an account on a
>> Python-specific site.
>>
>> Also: cPython is a large, complex, and mature project. I don't think many
>> non-developers can even identify a true bug, much less write a helpful big
>> report. There are many other ways to be involved in and contribute to the
>> Python community that don't require a gitHub (or any) account.
>>
>> I understand the issue here — I feel that way about businesses that use
>> Facebook for their website. But in that case, I can’t even read it without
>> a Facebook account. I don’t mind needing an account to contribute to a
>> conversation.
>>
>> And while GitHub  has become the dominant player in Open Source
>> development— it has not (yet?) reached out to control much else.
>>
>> -CHB
>>
>>
>> With all due respect to Microsoft, who has contributed significantly to
>> Python development, and continues to do, some people don't care for some of
>> Microsoft's policy and actions, and Microsoft owns GitHub, so your last
>> paragraph is somewhat naive, at best.
>>
>> So what is the difference between a GitHub account, and Microsoft account?
>>
>
> They are entirely different and separate; there's no relation there at all.
>
>
> Good, but given the Skype experience, it is questionable how long they
> will stay that way.
>

You can choose to view that as a one-off or indicative of a pattern. I'm
choosing the former (you can use the LinkedIn acquisition as support for my
view).


> One thing I will remind people is I personally have led the work to move
> this project from:
>
>1. SourceForge to our own infrastructure
>2. Mercurial to git
>3. Our own infrastructure to GitHub for code management
>
> So if GitHub were to do something we don't like we can always move
> platforms again.
>
>
> Indeed, but platform churn slows contributions, too.
>

Sure, but I don't think anyone is about to argue we should have stayed on
SF. Nor are there plans to switch off of GitHub.

Regardless, there are no plans to halt what was decided when we accepted
PEP 581. Most of the concerns which have been brought up in this thread
were already expressed back then (the account merge one I didn't remember,
hence why I replied).

>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/IL6TJJXAIZODIQ5CNSIVV2LN4R43ZJKP/
Code of Conduct: http://python.org/psf/codeofconduct/