From vstinner at redhat.com  Wed May  2 05:49:36 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Wed, 2 May 2018 11:49:36 +0200
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
Message-ID: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>

Hi,

I would like to start a poll on Chris Angelico's PEP 572 "Assignment
Expressions", restricted to Python core developers, to prepare the
talk at the Language Summit:

   https://www.python.org/dev/peps/pep-0572/

The poll is on the *current* PEP. I propose 4 choices:

* +1: you like the PEP
* -1: you dislike the PEP
* 0: you are not sure if you like it or not, or you have no opinon
* don't reply to this poll :-)

Just reply to this email with "+1", "0", "-1". Please don't elaborate
here, it's just a quick poll, use python-dev if you want to talk :-)

The poll will end next Tuesday, May 8, the day before the Language Summit.

I propose a poll because I'm unable to track the opinion of each core
dev, too many emails have been sent to python-dev, and maybe some
people changed their mind during the long discussion (which started in
February) :-)

Note: Obviously, it's just a poll, not a vote. Guido van Rossum is the
one who will pronounce himself on the PEP, to accept to reject it, so
the only one allowed to vote ;-)

Victor

From vstinner at redhat.com  Wed May  2 05:50:27 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Wed, 2 May 2018 11:50:27 +0200
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
Message-ID: <CA+3bQGHMvVgQnLNC58XgTu-h5e5SCM3bjJariyMcKtixHO7yGw@mail.gmail.com>

-1: dislike

( my rationale:
https://mail.python.org/pipermail/python-dev/2018-April/152991.html )

Victor

From antoine at python.org  Wed May  2 05:55:34 2018
From: antoine at python.org (Antoine Pitrou)
Date: Wed, 2 May 2018 11:55:34 +0200
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
Message-ID: <39a0adfa-6042-40c4-0392-d0176672c1d2@python.org>


-1: dislike

Regards

Antoine.


Le 02/05/2018 ? 11:49, Victor Stinner a ?crit?:
> Hi,
> 
> I would like to start a poll on Chris Angelico's PEP 572 "Assignment
> Expressions", restricted to Python core developers, to prepare the
> talk at the Language Summit:
> 
>    https://www.python.org/dev/peps/pep-0572/
> 
> The poll is on the *current* PEP. I propose 4 choices:
> 
> * +1: you like the PEP
> * -1: you dislike the PEP
> * 0: you are not sure if you like it or not, or you have no opinon
> * don't reply to this poll :-)
> 
> Just reply to this email with "+1", "0", "-1". Please don't elaborate
> here, it's just a quick poll, use python-dev if you want to talk :-)
> 
> The poll will end next Tuesday, May 8, the day before the Language Summit.
> 
> I propose a poll because I'm unable to track the opinion of each core
> dev, too many emails have been sent to python-dev, and maybe some
> people changed their mind during the long discussion (which started in
> February) :-)
> 
> Note: Obviously, it's just a poll, not a vote. Guido van Rossum is the
> one who will pronounce himself on the PEP, to accept to reject it, so
> the only one allowed to vote ;-)
> 
> Victor
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
> 

From p.f.moore at gmail.com  Wed May  2 05:56:44 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 2 May 2018 10:56:44 +0100
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
Message-ID: <CACac1F-u0G+TzYajKxdagKGCyPqppCPYSEouY+vCpJoJ0Ys=FQ@mail.gmail.com>

On 2 May 2018 at 10:49, Victor Stinner <vstinner at redhat.com> wrote:
> I would like to start a poll on Chris Angelico's PEP 572 "Assignment
> Expressions", restricted to Python core developers, to prepare the
> talk at the Language Summit:

Do we really need this spilling over into yet another mailing list?
Paul

From vstinner at redhat.com  Wed May  2 06:13:21 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Wed, 2 May 2018 12:13:21 +0200
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CACac1F-u0G+TzYajKxdagKGCyPqppCPYSEouY+vCpJoJ0Ys=FQ@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
 <CACac1F-u0G+TzYajKxdagKGCyPqppCPYSEouY+vCpJoJ0Ys=FQ@mail.gmail.com>
Message-ID: <CA+3bQGGuhHWCM0JYd1W-mo5WW9OoBomtKGtfmiLoefwJnCtBdw@mail.gmail.com>

2018-05-02 11:56 GMT+02:00 Paul Moore <p.f.moore at gmail.com>:
> On 2 May 2018 at 10:49, Victor Stinner <vstinner at redhat.com> wrote:
>> I would like to start a poll on Chris Angelico's PEP 572 "Assignment
>> Expressions", restricted to Python core developers, to prepare the
>> talk at the Language Summit:
>
> Do we really need this spilling over into yet another mailing list?

I already saw polls on Twitter, but I don't know if I should trust
Twitter polls because of the filter bubble. Moreover, this poll is
restricted to core developers, so it's different.

There will be a session about the PEP 572 next week at the Language
Summit, but I'm afraid that the session may go in all directions since
I didn't see any explicit agenda nor moderator yet:

  https://mail.python.org/pipermail/python-dev/2018-April/153250.html

I would prefer to prepare the session to be more efficient. I also
care of other topics discussed the Language Summit.

The poll is also for the ones who will not be able to attend the
Language Summit.

By the way, the list of sessions is not available yet, Larry/Barry?

  https://us.pycon.org/2018/events/language-summit/

Victor

From songofacandy at gmail.com  Wed May  2 06:06:35 2018
From: songofacandy at gmail.com (INADA Naoki)
Date: Wed, 02 May 2018 10:06:35 +0000
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
Message-ID: <CAEfz+Twm-rjYsVWiqS-qTJHqqYXN6HtR+gNTF_T7WSULgqKejQ@mail.gmail.com>

0: I will use it if it's accepted, but I'm not sure it's merit is enough
for changing how Python code looks.

From levkivskyi at gmail.com  Wed May  2 06:43:58 2018
From: levkivskyi at gmail.com (Ivan Levkivskyi)
Date: Wed, 2 May 2018 11:43:58 +0100
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CAEfz+Twm-rjYsVWiqS-qTJHqqYXN6HtR+gNTF_T7WSULgqKejQ@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
 <CAEfz+Twm-rjYsVWiqS-qTJHqqYXN6HtR+gNTF_T7WSULgqKejQ@mail.gmail.com>
Message-ID: <CAOMjWkmBCZtiiH+GjWMgP1YETEafzyy1yEhN1uLKExi-QsBx2A@mail.gmail.com>

0: this might be a handy feature, but I am not sure the dangers it
introduces are adequate for the problem it solves.

--
Ivan



On 2 May 2018 at 11:06, INADA Naoki <songofacandy at gmail.com> wrote:

> 0: I will use it if it's accepted, but I'm not sure it's merit is enough
> for changing how Python code looks.
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180502/1ef2ea31/attachment.html>

From berker.peksag at gmail.com  Wed May  2 07:49:46 2018
From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=)
Date: Wed, 2 May 2018 14:49:46 +0300
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
Message-ID: <CAF4280++kt_U-TsroJW_brp1FF0ouV1Tj5Kbd1oR6rqYvAtyyg@mail.gmail.com>

On Wed, May 2, 2018 at 12:49 PM, Victor Stinner <vstinner at redhat.com> wrote:
> Hi,
>
> I would like to start a poll on Chris Angelico's PEP 572 "Assignment
> Expressions", restricted to Python core developers, to prepare the
> talk at the Language Summit:
>
>    https://www.python.org/dev/peps/pep-0572/
>
> The poll is on the *current* PEP. I propose 4 choices:
>
> * +1: you like the PEP
> * -1: you dislike the PEP
> * 0: you are not sure if you like it or not, or you have no opinon
> * don't reply to this poll :-)

-1 (I'd vote +1 if it was fully backwards-compatible.)

--Berker

From vstinner at redhat.com  Wed May  2 08:04:37 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Wed, 2 May 2018 14:04:37 +0200
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
Message-ID: <CA+3bQGFb-taLHfsb=Oh91VOLbntFGusJy3F=Frrv8frOa-X1-w@mail.gmail.com>

2018-05-02 11:49 GMT+02:00 Victor Stinner <vstinner at redhat.com>:
> Just reply to this email with "+1", "0", "-1". Please don't elaborate
> here, it's just a quick poll, use python-dev if you want to talk :-)

FYI if you want don't to spam python-committers list, you may reply to
me in private. I will publish poll results at the end of the poll.

Victor

From mal at egenix.com  Wed May  2 09:11:32 2018
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 2 May 2018 15:11:32 +0200
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
Message-ID: <7ad6ef71-59d7-77ee-1c81-27251bf8e220@egenix.com>

-1 in the current form, since an expression such as

    [y := f(x), x/y] ...

is confusing (I'd read this as [y := (f(x), x/y)]

Using explicit parens around it would resolve this issue:

    [(y := f(x)), x/y] ...

but even with that, I'm not excited about the additional
line noise this adds - there's a reason why we have for-loops
in the language after all, explicit is better than having to
look thrice, etc. etc. :-)

Cheers,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, May 02 2018)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...           http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...           http://zope.egenix.com/
________________________________________________________________________

::: We implement business ideas - efficiently in both time and costs :::

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


On 02.05.2018 11:49, Victor Stinner wrote:
> Hi,
> 
> I would like to start a poll on Chris Angelico's PEP 572 "Assignment
> Expressions", restricted to Python core developers, to prepare the
> talk at the Language Summit:
> 
>    https://www.python.org/dev/peps/pep-0572/
> 
> The poll is on the *current* PEP. I propose 4 choices:
> 
> * +1: you like the PEP
> * -1: you dislike the PEP
> * 0: you are not sure if you like it or not, or you have no opinon
> * don't reply to this poll :-)
> 
> Just reply to this email with "+1", "0", "-1". Please don't elaborate
> here, it's just a quick poll, use python-dev if you want to talk :-)
> 
> The poll will end next Tuesday, May 8, the day before the Language Summit.
> 
> I propose a poll because I'm unable to track the opinion of each core
> dev, too many emails have been sent to python-dev, and maybe some
> people changed their mind during the long discussion (which started in
> February) :-)
> 
> Note: Obviously, it's just a poll, not a vote. Guido van Rossum is the
> one who will pronounce himself on the PEP, to accept to reject it, so
> the only one allowed to vote ;-)
> 
> Victor
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
> 


From ncoghlan at gmail.com  Wed May  2 09:45:11 2018
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 2 May 2018 23:45:11 +1000
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
Message-ID: <CADiSq7dRhL_Q9FOxKRNnfx+U+L6auYaThi=bvJVH0ZGp8fAMGQ@mail.gmail.com>

On 2 May 2018 at 19:49, Victor Stinner <vstinner at redhat.com> wrote:

> Hi,
>
> I would like to start a poll on Chris Angelico's PEP 572 "Assignment
> Expressions", restricted to Python core developers, to prepare the
> talk at the Language Summit:
>
>    https://www.python.org/dev/peps/pep-0572/
>
> The poll is on the *current* PEP. I propose 4 choices:
>
> * +1: you like the PEP
> * -1: you dislike the PEP
> * 0: you are not sure if you like it or not, or you have no opinon
> * don't reply to this poll :-)
>

-1 from me (on "too much pain for not enough gain" grounds).

Regards,
Nick.

P.S. I quite liked the initial "expr as name" version with subscopes, but
those aspects were changed based on reasonable concerns raised on
python-ideas, and I think the discussion of the simplified proposal on
python-dev has also raised sufficient further concerns to push the whole
concept back into python-ideas territory. (I do think the discussions have
clarified the nature of the cases where the current lack of any form of
inline binding support can be genuinely irritating, though)

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180502/3d12d4c6/attachment-0001.html>

From p.f.moore at gmail.com  Wed May  2 10:00:51 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 2 May 2018 15:00:51 +0100
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CADiSq7dRhL_Q9FOxKRNnfx+U+L6auYaThi=bvJVH0ZGp8fAMGQ@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
 <CADiSq7dRhL_Q9FOxKRNnfx+U+L6auYaThi=bvJVH0ZGp8fAMGQ@mail.gmail.com>
Message-ID: <CACac1F-q_jPzmgDm6EOUv-cYdSJQjccS8xyYuqJth35=Kpi_yg@mail.gmail.com>

FWIW, -1 from me. At least with the PEP as it stands.
Paul

From ericsnowcurrently at gmail.com  Wed May  2 10:02:21 2018
From: ericsnowcurrently at gmail.com (Eric Snow)
Date: Wed, 2 May 2018 08:02:21 -0600
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
Message-ID: <CALFfu7CuK2=MebM3_QchtYytByXrzqau+XxDR0ZxMtAcyzNY7Q@mail.gmail.com>

On Wed, May 2, 2018 at 3:49 AM, Victor Stinner <vstinner at redhat.com> wrote:
> The poll is on the *current* PEP. I propose 4 choices:
>
> * +1: you like the PEP
> * -1: you dislike the PEP
> * 0: you are not sure if you like it or not, or you have no opinon
> * don't reply to this poll :-)
>
> Just reply to this email with "+1", "0", "-1". Please don't elaborate
> here, it's just a quick poll, use python-dev if you want to talk :-)

-1

...and thanks for specifically asking for no elaboration.  I was tempted. :)

-eric

From yselivanov.ml at gmail.com  Wed May  2 10:10:07 2018
From: yselivanov.ml at gmail.com (Yury Selivanov)
Date: Wed, 02 May 2018 14:10:07 +0000
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CALFfu7CuK2=MebM3_QchtYytByXrzqau+XxDR0ZxMtAcyzNY7Q@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
 <CALFfu7CuK2=MebM3_QchtYytByXrzqau+XxDR0ZxMtAcyzNY7Q@mail.gmail.com>
Message-ID: <CA+St6D3rb_QGKLdAi9P-f_3YfbDxjp8hRN0+P-q=4OnPYcp5eA@mail.gmail.com>

-1
On Wed, May 2, 2018 at 10:02 AM Eric Snow <ericsnowcurrently at gmail.com>
wrote:

> On Wed, May 2, 2018 at 3:49 AM, Victor Stinner <vstinner at redhat.com>
wrote:
> > The poll is on the *current* PEP. I propose 4 choices:
> >
> > * +1: you like the PEP
> > * -1: you dislike the PEP
> > * 0: you are not sure if you like it or not, or you have no opinon
> > * don't reply to this poll :-)
> >
> > Just reply to this email with "+1", "0", "-1". Please don't elaborate
> > here, it's just a quick poll, use python-dev if you want to talk :-)

> -1

> ...and thanks for specifically asking for no elaboration.  I was tempted.
:)

> -eric
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/



-- 
          Yury

From stefan at bytereef.org  Wed May  2 10:17:56 2018
From: stefan at bytereef.org (Stefan Krah)
Date: Wed, 2 May 2018 16:17:56 +0200
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CALFfu7CuK2=MebM3_QchtYytByXrzqau+XxDR0ZxMtAcyzNY7Q@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
 <CALFfu7CuK2=MebM3_QchtYytByXrzqau+XxDR0ZxMtAcyzNY7Q@mail.gmail.com>
Message-ID: <20180502141756.GA5188@bytereef.org>


+0.5


Stefan Krah


From tim.peters at gmail.com  Wed May  2 12:11:31 2018
From: tim.peters at gmail.com (Tim Peters)
Date: Wed, 2 May 2018 11:11:31 -0500
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
Message-ID: <CAExdVN=knC=GpJ5ZFzHU7_xOrC8pt1F6OqucHAJ_Z5ckjJMF=Q@mail.gmail.com>

> * +1: you like the PEP
> * -1: you dislike the PEP
> * 0: you are not sure if you like it or not, or you have no opinon
> * don't reply to this poll :-)

+1

From jaraco at jaraco.com  Wed May  2 12:32:30 2018
From: jaraco at jaraco.com (Jason R. Coombs)
Date: Wed, 2 May 2018 16:32:30 +0000
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
Message-ID: <F0F7A95A-2253-4F58-8D05-7A72A8510A97@jaraco.com>

+1

On 2 May, 2018, at 10:49, Victor Stinner <vstinner at redhat.com<mailto:vstinner at redhat.com>> wrote:

* +1: you like the PEP
* -1: you dislike the PEP
* 0: you are not sure if you like it or not, or you have no opinon
* don't reply to this poll :-)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180502/f3591929/attachment.html>

From alexander.belopolsky at gmail.com  Wed May  2 12:54:24 2018
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Wed, 2 May 2018 12:54:24 -0400
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
Message-ID: <CAP7h-xaJksRQYE57+roaChd34PZwO_zmCr56jQTO6KrsaN7HRw@mail.gmail.com>

-1

On Wed, May 2, 2018 at 5:49 AM, Victor Stinner <vstinner at redhat.com> wrote:
> Hi,
>
> I would like to start a poll on Chris Angelico's PEP 572 "Assignment
> Expressions", restricted to Python core developers, to prepare the
> talk at the Language Summit:
>
>    https://www.python.org/dev/peps/pep-0572/
>
> The poll is on the *current* PEP. I propose 4 choices:
>
> * +1: you like the PEP
> * -1: you dislike the PEP
> * 0: you are not sure if you like it or not, or you have no opinon
> * don't reply to this poll :-)
>
> Just reply to this email with "+1", "0", "-1". Please don't elaborate
> here, it's just a quick poll, use python-dev if you want to talk :-)
>
> The poll will end next Tuesday, May 8, the day before the Language Summit.
>
> I propose a poll because I'm unable to track the opinion of each core
> dev, too many emails have been sent to python-dev, and maybe some
> people changed their mind during the long discussion (which started in
> February) :-)
>
> Note: Obviously, it's just a poll, not a vote. Guido van Rossum is the
> one who will pronounce himself on the PEP, to accept to reject it, so
> the only one allowed to vote ;-)
>
> Victor
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/

From lukasz at langa.pl  Wed May  2 12:56:54 2018
From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=)
Date: Wed, 2 May 2018 09:56:54 -0700
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
Message-ID: <A4793AC4-FC0E-4CA4-9F6B-5B709353BF67@langa.pl>

-1

-- 
Best regards,
?ukasz Langa

> On May 2, 2018, at 2:49 AM, Victor Stinner <vstinner at redhat.com> wrote:
> 
> Hi,
> 
> I would like to start a poll on Chris Angelico's PEP 572 "Assignment
> Expressions", restricted to Python core developers, to prepare the
> talk at the Language Summit:
> 
>   https://www.python.org/dev/peps/pep-0572/
> 
> The poll is on the *current* PEP. I propose 4 choices:
> 
> * +1: you like the PEP
> * -1: you dislike the PEP
> * 0: you are not sure if you like it or not, or you have no opinon
> * don't reply to this poll :-)
> 
> Just reply to this email with "+1", "0", "-1". Please don't elaborate
> here, it's just a quick poll, use python-dev if you want to talk :-)
> 
> The poll will end next Tuesday, May 8, the day before the Language Summit.
> 
> I propose a poll because I'm unable to track the opinion of each core
> dev, too many emails have been sent to python-dev, and maybe some
> people changed their mind during the long discussion (which started in
> February) :-)
> 
> Note: Obviously, it's just a poll, not a vote. Guido van Rossum is the
> one who will pronounce himself on the PEP, to accept to reject it, so
> the only one allowed to vote ;-)
> 
> Victor
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/


From Stefan.Richthofer at gmx.de  Wed May  2 13:40:41 2018
From: Stefan.Richthofer at gmx.de (Stefan Richthofer)
Date: Wed, 2 May 2018 19:40:41 +0200
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <A4793AC4-FC0E-4CA4-9F6B-5B709353BF67@langa.pl>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
 <A4793AC4-FC0E-4CA4-9F6B-5B709353BF67@langa.pl>
Message-ID: <trinity-a6646b70-39c5-42a4-82a2-2cd98d3503a1-1525282841909@3c-app-gmx-bs38>

-1


-Stefan


> > On May 2, 2018, at 2:49 AM, Victor Stinner <vstinner at redhat.com> wrote:
> > 
> > Hi,
> > 
> > I would like to start a poll on Chris Angelico's PEP 572 "Assignment
> > Expressions", restricted to Python core developers, to prepare the
> > talk at the Language Summit:
> > 
> >   https://www.python.org/dev/peps/pep-0572/
> > 
> > The poll is on the *current* PEP. I propose 4 choices:
> > 
> > * +1: you like the PEP
> > * -1: you dislike the PEP
> > * 0: you are not sure if you like it or not, or you have no opinon
> > * don't reply to this poll :-)
> > 
> > Just reply to this email with "+1", "0", "-1". Please don't elaborate
> > here, it's just a quick poll, use python-dev if you want to talk :-)
> > 
> > The poll will end next Tuesday, May 8, the day before the Language Summit.
> > 
> > I propose a poll because I'm unable to track the opinion of each core
> > dev, too many emails have been sent to python-dev, and maybe some
> > people changed their mind during the long discussion (which started in
> > February) :-)
> > 
> > Note: Obviously, it's just a poll, not a vote. Guido van Rossum is the
> > one who will pronounce himself on the PEP, to accept to reject it, so
> > the only one allowed to vote ;-)
> > 
> > Victor
> > _______________________________________________
> > python-committers mailing list
> > python-committers at python.org
> > https://mail.python.org/mailman/listinfo/python-committers
> > Code of Conduct: https://www.python.org/psf/codeofconduct/
> 
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
> 

From julien at palard.fr  Wed May  2 15:33:44 2018
From: julien at palard.fr (Julien Palard)
Date: Wed, 02 May 2018 15:33:44 -0400
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
Message-ID: <YlxtXSQEbZaqXB3FeNxi1xQzrIyHwNueeOTiYQvQUapoxLlkuOOSSUhUORMyDhq1qxBO_GwYCqOA2dVvlM6D5Al-HNfp9tuoWkVvJDHPfWI=@palard.fr>

-1

?--?
Julien Palard
https://mdk.fr?


From storchaka at gmail.com  Wed May  2 16:27:47 2018
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Wed, 2 May 2018 23:27:47 +0300
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
Message-ID: <d4e4484d-857d-155f-3a97-3914811fa8dd@gmail.com>

02.05.18 12:49, Victor Stinner ????:

> The poll is on the *current* PEP. I propose 4 choices:
>
> * +1: you like the PEP
> * -1: you dislike the PEP
> * 0: you are not sure if you like it or not, or you have no opinon
> * don't reply to this poll :-)
>
> Just reply to this email with "+1", "0", "-1". Please don't elaborate
> here, it's just a quick poll, use python-dev if you want to talk :-)

-1: dislike

I will not use it if it's accepted, and likely will not make reviews of 
patches that use it.


From storchaka at gmail.com  Wed May  2 17:18:31 2018
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Thu, 3 May 2018 00:18:31 +0300
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <d4e4484d-857d-155f-3a97-3914811fa8dd@gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
 <d4e4484d-857d-155f-3a97-3914811fa8dd@gmail.com>
Message-ID: <0b95b46c-a421-1ff7-c127-35a33c6c23e4@gmail.com>

02.05.18 23:27, Serhiy Storchaka ????:
> I will not use it if it's accepted, and likely will not make reviews 
> of patches that use it.

I meant that this feature looks so bad to me, that it will be painful to 
me even to read a Python code that uses it.

From tjreedy at udel.edu  Wed May  2 19:03:39 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 2 May 2018 19:03:39 -0400
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
Message-ID: <1b5ebae9-ff46-5fd6-fd0a-f6a96b72cab7@udel.edu>

On 5/2/2018 5:49 AM, Victor Stinner wrote:

You asked two different questions, hence two answers.

1. The title asks "Do I like the PEP 572 Assignment Expressions"?
Yes, at least +.5, and if forced, I might well round up to 1.

> The poll is on the *current* PEP. I propose 4 choices:

2. However, the PEP itself also contains an only loosely related and 
inadequately discussed proposal to change comprehension scoping 
semantics (I presume before we are done with 2.7) and possibly break 
existing code without a deprecation period.  I think all 3 aspects of 
this are wrong.  Hence I am -1 on this part of the PEP and the PEP as a 
whole.

I think some, but not all, of other answers are influenced by which 
version of the question a person is answering.

TJR

From steve.dower at python.org  Wed May  2 20:04:52 2018
From: steve.dower at python.org (Steve Dower)
Date: Wed, 2 May 2018 17:04:52 -0700
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
Message-ID: <d96008af-eca8-ba96-d6d7-47cce8eedfa1@python.org>

On 02May2018 0249, Victor Stinner wrote:
> * +1: you like the PEP
> * -1: you dislike the PEP

I love the PEP, it's one of the better ones for sure. :) I just don't 
like the proposed change.

-1

Cheers,
Steve

From robertc at robertcollins.net  Wed May  2 20:28:57 2018
From: robertc at robertcollins.net (Robert Collins)
Date: Thu, 3 May 2018 12:28:57 +1200
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CA+3bQGGuhHWCM0JYd1W-mo5WW9OoBomtKGtfmiLoefwJnCtBdw@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
 <CACac1F-u0G+TzYajKxdagKGCyPqppCPYSEouY+vCpJoJ0Ys=FQ@mail.gmail.com>
 <CA+3bQGGuhHWCM0JYd1W-mo5WW9OoBomtKGtfmiLoefwJnCtBdw@mail.gmail.com>
Message-ID: <CAJ3HoZ29QFSZbU4LpRvbO1qG5zOn-QQn=qxFimBcXa10V-+pxA@mail.gmail.com>

I'd very much like the feature, but not sure that the proposed change
is a good fit today.

-Rob

On 2 May 2018 at 22:13, Victor Stinner <vstinner at redhat.com> wrote:
> 2018-05-02 11:56 GMT+02:00 Paul Moore <p.f.moore at gmail.com>:
>> On 2 May 2018 at 10:49, Victor Stinner <vstinner at redhat.com> wrote:
>>> I would like to start a poll on Chris Angelico's PEP 572 "Assignment
>>> Expressions", restricted to Python core developers, to prepare the
>>> talk at the Language Summit:
>>
>> Do we really need this spilling over into yet another mailing list?
>
> I already saw polls on Twitter, but I don't know if I should trust
> Twitter polls because of the filter bubble. Moreover, this poll is
> restricted to core developers, so it's different.
>
> There will be a session about the PEP 572 next week at the Language
> Summit, but I'm afraid that the session may go in all directions since
> I didn't see any explicit agenda nor moderator yet:
>
>   https://mail.python.org/pipermail/python-dev/2018-April/153250.html
>
> I would prefer to prepare the session to be more efficient. I also
> care of other topics discussed the Language Summit.
>
> The poll is also for the ones who will not be able to attend the
> Language Summit.
>
> By the way, the list of sessions is not available yet, Larry/Barry?
>
>   https://us.pycon.org/2018/events/language-summit/
>
> Victor
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/

From raymond.hettinger at gmail.com  Wed May  2 21:39:31 2018
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Wed, 2 May 2018 18:39:31 -0700
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
Message-ID: <E5FE96E6-8865-4570-A1DA-5D00B78C5275@gmail.com>

-1: dislike

> On May 2, 2018, at 2:49 AM, Victor Stinner <vstinner at redhat.com> wrote:
> 
> The poll is on the *current* PEP. I propose 4 choices:
> 
> * +1: you like the PEP
> * -1: you dislike the PEP
> * 0: you are not sure if you like it or not, or you have no opinon
> * don't reply to this poll :-)
> 
> Just reply to this email with "+1", "0", "-1". Please don't elaborate
> here, it's just a quick poll, use python-dev if you want to talk :-)


From christian at cheimes.de  Thu May  3 06:50:41 2018
From: christian at cheimes.de (Christian Heimes)
Date: Thu, 3 May 2018 12:50:41 +0200
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
Message-ID: <6c9a41a7-1a33-6af6-a1e9-1ac848c220b1@cheimes.de>

On 2018-05-02 11:49, Victor Stinner wrote:
> Hi,
> 
> I would like to start a poll on Chris Angelico's PEP 572 "Assignment
> Expressions", restricted to Python core developers, to prepare the
> talk at the Language Summit:
> 
>    https://www.python.org/dev/peps/pep-0572/
> 
> The poll is on the *current* PEP. I propose 4 choices:
> 
> * +1: you like the PEP
> * -1: you dislike the PEP
> * 0: you are not sure if you like it or not, or you have no opinon
> * don't reply to this poll :-)

-1

From nad at python.org  Wed May  2 20:16:25 2018
From: nad at python.org (Ned Deily)
Date: Wed, 2 May 2018 20:16:25 -0400
Subject: [python-committers] [RELEASE] Python 3.7.0b4, final 3.7 beta,
 now available for testing
Message-ID: <82F6CAB9-4144-4937-B73B-914AD6518173@python.org>

Python 3.7.0b4 is the final beta preview of Python 3.7, the next feature
release of Python. Beta releases are intended to give you the
opportunity to test new features and bug fixes and to prepare your
projects to support the new feature release. We strongly encourage you
to test your projects with 3.7 during the beta phase and report issues
found to bugs.python.org as soon as possible. While the release is
feature complete entering the beta phase, it is possible that features
may be modified or, in rare cases, deleted up until the start of the
release candidate phase. Please keep in mind that this is a preview
release and its use is not recommended for production environments.
Attention macOS users: there is now a new installer variant for macOS
10.9+ that includes a built-in version of Tcl/Tk 8.6. This variant is
expected to become the default version when 3.7.0 releases. Check it out!

The next preview release will be the release candidate and is planned
for 2018-05-21 followed by the official release of 3.7.0, planned for
2018-06-15. You can find Python 3.7.0b4 and more information here:

https://www.python.org/downloads/release/python-370b4/

--
  Ned Deily
  nad at python.org -- []


From greg at krypto.org  Thu May  3 14:25:12 2018
From: greg at krypto.org (Gregory P. Smith)
Date: Thu, 3 May 2018 11:25:12 -0700
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
Message-ID: <CAGE7PNL6DXN1VX435DT2uoRubp3x_uX-_9PaYkEWzRgF2ukzgw@mail.gmail.com>

On Wed, May 2, 2018 at 2:49 AM, Victor Stinner <vstinner at redhat.com> wrote:

> Hi,
>
> I would like to start a poll on Chris Angelico's PEP 572 "Assignment
> Expressions", restricted to Python core developers, to prepare the
> talk at the Language Summit:
>
>    https://www.python.org/dev/peps/pep-0572/
>
> The poll is on the *current* PEP. I propose 4 choices:
>
> * +1: you like the PEP
> * -1: you dislike the PEP
> * 0: you are not sure if you like it or not, or you have no opinon
> * don't reply to this poll :-)
>

-1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180503/d8df2047/attachment.html>

From dickinsm at gmail.com  Thu May  3 15:50:54 2018
From: dickinsm at gmail.com (Mark Dickinson)
Date: Thu, 3 May 2018 20:50:54 +0100
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
Message-ID: <CAAu3qLWRQL56xGwn-LdL+p9ZhycLXXgUXRo=TyQ=xRgdLqpprQ@mail.gmail.com>

On Wed, May 2, 2018 at 10:49 AM, Victor Stinner <vstinner at redhat.com> wrote:

> * +1: you like the PEP
> * -1: you dislike the PEP
> * 0: you are not sure if you like it or not, or you have no opinon
> * don't reply to this poll :-)
>

-1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180503/449fb2ed/attachment.html>

From njs at pobox.com  Thu May  3 22:37:58 2018
From: njs at pobox.com (Nathaniel Smith)
Date: Thu, 3 May 2018 19:37:58 -0700
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
Message-ID: <CAPJVwBk3Q8YzeY5_NptFTp3=21fZxomJPzODFuzefA+ftjcksw@mail.gmail.com>

-1, I think, though I'm frustrated that in the parts of the list
discussion I had energy to read, its proponents seemed to be saying
that the most compelling examples aren't actually in the PEP (and I
don't know what they are).

On Wed, May 2, 2018 at 2:49 AM, Victor Stinner <vstinner at redhat.com> wrote:
> Hi,
>
> I would like to start a poll on Chris Angelico's PEP 572 "Assignment
> Expressions", restricted to Python core developers, to prepare the
> talk at the Language Summit:
>
>    https://www.python.org/dev/peps/pep-0572/
>
> The poll is on the *current* PEP. I propose 4 choices:
>
> * +1: you like the PEP
> * -1: you dislike the PEP
> * 0: you are not sure if you like it or not, or you have no opinon
> * don't reply to this poll :-)
>
> Just reply to this email with "+1", "0", "-1". Please don't elaborate
> here, it's just a quick poll, use python-dev if you want to talk :-)
>
> The poll will end next Tuesday, May 8, the day before the Language Summit.
>
> I propose a poll because I'm unable to track the opinion of each core
> dev, too many emails have been sent to python-dev, and maybe some
> people changed their mind during the long discussion (which started in
> February) :-)
>
> Note: Obviously, it's just a poll, not a vote. Guido van Rossum is the
> one who will pronounce himself on the PEP, to accept to reject it, so
> the only one allowed to vote ;-)
>
> Victor
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/



-- 
Nathaniel J. Smith -- https://vorpus.org

From willingc at gmail.com  Fri May  4 01:16:41 2018
From: willingc at gmail.com (Carol Willing)
Date: Fri, 04 May 2018 05:16:41 +0000
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CAPJVwBk3Q8YzeY5_NptFTp3=21fZxomJPzODFuzefA+ftjcksw@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
 <CAPJVwBk3Q8YzeY5_NptFTp3=21fZxomJPzODFuzefA+ftjcksw@mail.gmail.com>
Message-ID: <CAM3VvhytZbYatMCCqVBRfTY27DZOqW9gi4QPOfiAaVwbAXnaiQ@mail.gmail.com>

-1 as currently proposed, +0 on Tim?s more bounded approach from the
mailing list

On Fri, May 4, 2018 at 4:38 AM Nathaniel Smith <njs at pobox.com> wrote:

> -1, I think, though I'm frustrated that in the parts of the list
> discussion I had energy to read, its proponents seemed to be saying
> that the most compelling examples aren't actually in the PEP (and I
> don't know what they are).
>
> On Wed, May 2, 2018 at 2:49 AM, Victor Stinner <vstinner at redhat.com>
> wrote:
> > Hi,
> >
> > I would like to start a poll on Chris Angelico's PEP 572 "Assignment
> > Expressions", restricted to Python core developers, to prepare the
> > talk at the Language Summit:
> >
> >    https://www.python.org/dev/peps/pep-0572/
> >
> > The poll is on the *current* PEP. I propose 4 choices:
> >
> > * +1: you like the PEP
> > * -1: you dislike the PEP
> > * 0: you are not sure if you like it or not, or you have no opinon
> > * don't reply to this poll :-)
> >
> > Just reply to this email with "+1", "0", "-1". Please don't elaborate
> > here, it's just a quick poll, use python-dev if you want to talk :-)
> >
> > The poll will end next Tuesday, May 8, the day before the Language
> Summit.
> >
> > I propose a poll because I'm unable to track the opinion of each core
> > dev, too many emails have been sent to python-dev, and maybe some
> > people changed their mind during the long discussion (which started in
> > February) :-)
> >
> > Note: Obviously, it's just a poll, not a vote. Guido van Rossum is the
> > one who will pronounce himself on the PEP, to accept to reject it, so
> > the only one allowed to vote ;-)
> >
> > Victor
> > _______________________________________________
> > python-committers mailing list
> > python-committers at python.org
> > https://mail.python.org/mailman/listinfo/python-committers
> > Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>
>
> --
> Nathaniel J. Smith -- https://vorpus.org
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-- 
*Carol Willing*

Research Software Engineer
Project Jupyter at Cal Poly SLO

cawillin at calpoly.edu

*Signature strengths*
*Empathy - Relator - Ideation - Strategic - Learner*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180504/7a584ded/attachment-0001.html>

From kushaldas at gmail.com  Fri May  4 02:21:31 2018
From: kushaldas at gmail.com (Kushal Das)
Date: Thu, 3 May 2018 23:21:31 -0700
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
Message-ID: <CAAzeMbw3YpAVkp=+PtQKOoAMt_-9mQts1jMvn+pzsS3xqOptvQ@mail.gmail.com>

On Wed, May 2, 2018 at 2:49 AM, Victor Stinner <vstinner at redhat.com> wrote:
> Hi,
>
> I would like to start a poll on Chris Angelico's PEP 572 "Assignment
> Expressions", restricted to Python core developers, to prepare the
> talk at the Language Summit:
>
>    https://www.python.org/dev/peps/pep-0572/
>
> The poll is on the *current* PEP. I propose 4 choices:
>
> * +1: you like the PEP
> * -1: you dislike the PEP
> * 0: you are not sure if you like it or not, or you have no opinon
> * don't reply to this poll :-)
-1

Kushal
-- 
Staff, Freedom of the Press Foundation
CPython Core Developer
Director, Python Software Foundation
https://kushaldas.in

From ericsnowcurrently at gmail.com  Fri May  4 11:29:49 2018
From: ericsnowcurrently at gmail.com (Eric Snow)
Date: Fri, 4 May 2018 09:29:49 -0600
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
Message-ID: <CALFfu7D88S=-NuLpxZLg-9hiuriZobjOSnZgWMTw6YcVDJ=LtA@mail.gmail.com>

On Wed, May 2, 2018 at 3:49 AM, Victor Stinner <vstinner at redhat.com> wrote:
> I propose a poll because I'm unable to track the opinion of each core
> dev, too many emails have been sent to python-dev, and maybe some
> people changed their mind during the long discussion (which started in
> February) :-)

FWIW, contrary to the many -1 responses, I don't think the actual
sentiment is all torches-and-pitchforks. :)  There are a variety of
well-reasoned opinions that mostly result in "meh" and "I don't like
the idea of it but don't know how it will actually work out" (or maybe
I'm just projecting myself onto everyone else).  This is the point
where I have a lot of respect for Guido's uncanny intuition as
reflected in Python's history.

-eric

From ericsnowcurrently at gmail.com  Fri May  4 11:41:31 2018
From: ericsnowcurrently at gmail.com (Eric Snow)
Date: Fri, 4 May 2018 09:41:31 -0600
Subject: [python-committers] My opinion about "binding expressions" (was
 Poll: Do you like the PEP 572 Assignment Expressions?)
Message-ID: <CALFfu7CYnH+mSoXGBP6Fpny287zCzU2ny5kb-ZLX2qZFmYR7qg@mail.gmail.com>

On Wed, May 2, 2018 at 3:49 AM, Victor Stinner <vstinner at redhat.com> wrote:
> I propose a poll because I'm unable to track the opinion of each core
> dev, too many emails have been sent to python-dev, and maybe some
> people changed their mind during the long discussion (which started in
> February) :-)

Victor said "Please don't elaborate here" so I've opened yet another*
thread for this topic. :)  My apologies to all for that.  However, I
didn't feel like the poll captured my opinion well.  In the interest
of not adding too much more noise to the discussion on this specific
topic, I'll provide a (relatively) brief opinion here and then bow
out.  (I don't feel like I have anything else to contribute on the
subject.)  If you feel similarly, feel free to do likewise (e.g. be
concise).  Please don't engage in discussion here.  There are plenty
of other threads for that.  If no one else registers their opinion
here that's fine with me too. :)

As to my actual opinion, ultimately I don't think "binding
expressions" are such a big deal either way.  I doubt abuse will be as
common or frustrating as that of list comprehensions and ternary
expressions; but either way code review will mitigate that risk (and I
doubt binding expressions will be a major distraction there).  Anyway,
I'll probably use them occasionally if we get them.

-eric

* Yeah, it's like when someone says "the problem is there are too many
file formats" so they write their own to render the rest irrelevant...
<wink>

From vstinner at redhat.com  Fri May  4 12:10:39 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Fri, 4 May 2018 18:10:39 +0200
Subject: [python-committers] PEP 572 at the Language Summit next week
Message-ID: <CA+3bQGEsSOfLD+7+WGMCc1tfVRzBuxXNp=0vi0+=y7A3byxaaA@mail.gmail.com>

Sorry, I choose to reply to python-committers rather than python-dev
because I have been annoyed by the PEP 572 traffic on python-dev.

2018-04-29 22:45 GMT+02:00 Larry Hastings <larry at hastings.org>:
> In case it helps, we're planning on presentations on / a discussion of PEP
> 572 at the 2018 Python Language Summit next Wednesday.  (I'm assuming it
> won't be pronounced upon before then--after all, what's the rush?)
> Naturally the discussion isn't going to escape the room until it gets
> reported on by Jake Edge, but delegates at the Summit will hopefully emerge
> well-informed and comfortable with the result of the discussion.

Who is going to lead this discussion? Will we have at least one
developer in favor of the PEP to give a summary of the advantages? I
would like to make sure that we can get a fair summary of the past PEP
discussion.

I'm not worried for the "dislike" part which may be correctly represented :-D

Note: I just got a notice of a strike at Air France next Tuesday, the
day I'm flighting to the US, and my 3rd and last flight of this trip
is cancelled. Oh oh.

Victor

From guido at python.org  Fri May  4 13:04:35 2018
From: guido at python.org (Guido van Rossum)
Date: Fri, 4 May 2018 10:04:35 -0700
Subject: [python-committers] PEP 572 at the Language Summit next week
In-Reply-To: <CA+3bQGEsSOfLD+7+WGMCc1tfVRzBuxXNp=0vi0+=y7A3byxaaA@mail.gmail.com>
References: <CA+3bQGEsSOfLD+7+WGMCc1tfVRzBuxXNp=0vi0+=y7A3byxaaA@mail.gmail.com>
Message-ID: <CAP7+vJK5AMoKAhU_bWrWC4tkE_c+DzgkPiZhf05TJ=nWgWk2Zw@mail.gmail.com>

It looks like I am going to try and present a balanced summary and then
open the floor for discussion. I also want to use the opportunity to start
brainstorming about a better way to make decisions.

On Fri, May 4, 2018 at 9:10 AM, Victor Stinner <vstinner at redhat.com> wrote:

> Sorry, I choose to reply to python-committers rather than python-dev
> because I have been annoyed by the PEP 572 traffic on python-dev.
>
> 2018-04-29 22:45 GMT+02:00 Larry Hastings <larry at hastings.org>:
> > In case it helps, we're planning on presentations on / a discussion of
> PEP
> > 572 at the 2018 Python Language Summit next Wednesday.  (I'm assuming it
> > won't be pronounced upon before then--after all, what's the rush?)
> > Naturally the discussion isn't going to escape the room until it gets
> > reported on by Jake Edge, but delegates at the Summit will hopefully
> emerge
> > well-informed and comfortable with the result of the discussion.
>
> Who is going to lead this discussion? Will we have at least one
> developer in favor of the PEP to give a summary of the advantages? I
> would like to make sure that we can get a fair summary of the past PEP
> discussion.
>
> I'm not worried for the "dislike" part which may be correctly represented
> :-D
>
> Note: I just got a notice of a strike at Air France next Tuesday, the
> day I'm flighting to the US, and my 3rd and last flight of this trip
> is cancelled. Oh oh.
>
> Victor
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180504/1074d386/attachment.html>

From vstinner at redhat.com  Fri May  4 17:29:14 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Fri, 4 May 2018 23:29:14 +0200
Subject: [python-committers] PEP 572 at the Language Summit next week
In-Reply-To: <CAP7+vJK5AMoKAhU_bWrWC4tkE_c+DzgkPiZhf05TJ=nWgWk2Zw@mail.gmail.com>
References: <CA+3bQGEsSOfLD+7+WGMCc1tfVRzBuxXNp=0vi0+=y7A3byxaaA@mail.gmail.com>
 <CAP7+vJK5AMoKAhU_bWrWC4tkE_c+DzgkPiZhf05TJ=nWgWk2Zw@mail.gmail.com>
Message-ID: <CA+3bQGGGf3O2dSu0Bs-1tkGX=pGvp2G+s5SUvuvweumScb_hcQ@mail.gmail.com>

2018-05-04 19:04 GMT+02:00 Guido van Rossum <guido at python.org>:
> It looks like I am going to try and present a balanced summary and then open
> the floor for discussion.

Oh ok, thanks!

I'm not sure that the discussion on python-dev was really efficient (I
didn't follow the discussion on python-ideas). It seems like many
people said the same thing. I'm not sure that arguments of the
supporters of the PEP have been heard. Likely lost in the high number
of emails...

Victor

From tim.peters at gmail.com  Fri May  4 19:31:00 2018
From: tim.peters at gmail.com (Tim Peters)
Date: Fri, 4 May 2018 18:31:00 -0500
Subject: [python-committers] PEP 572 at the Language Summit next week
In-Reply-To: <CA+3bQGGGf3O2dSu0Bs-1tkGX=pGvp2G+s5SUvuvweumScb_hcQ@mail.gmail.com>
References: <CA+3bQGEsSOfLD+7+WGMCc1tfVRzBuxXNp=0vi0+=y7A3byxaaA@mail.gmail.com>
 <CAP7+vJK5AMoKAhU_bWrWC4tkE_c+DzgkPiZhf05TJ=nWgWk2Zw@mail.gmail.com>
 <CA+3bQGGGf3O2dSu0Bs-1tkGX=pGvp2G+s5SUvuvweumScb_hcQ@mail.gmail.com>
Message-ID: <CAExdVNkcL_b0Jb=qnpX12tJQsX6xQvxRrV6oviZyQKOQmDGn1g@mail.gmail.com>

[Victor Stinner <vstinner at redhat.com>]
> I'm not sure that the discussion on python-dev was really efficient (I
> didn't follow the discussion on python-ideas). It seems like many
> people said the same thing.

Only hundreds of times ;-)


> I'm not sure that arguments of the supporters of the PEP have been
> heard. Likely lost in the high number of emails...

It's really the PEP's job to lay out the pros and cons - you shouldn't
have to read emails at all for that, unless you want to follow the
development in real time.  I think moving the PEP from python-ideas to
python-dev was premature, because even among proponents there wasn't
yet consensus that the then-current state of the PEP was sufficiently
focused.

The simpler the PEP has gotten, the more I've warmed to it.  My
current +1 isn't really about the PEP as it stands, but about what I
_assume_ Guido will be talking about (plain-name "binding expressions"
alone, and not also, e.g., about changing some corner case scope
behaviors, but also about tightening the language spec with respect to
guaranteeing a specific order-of-operation (OOO) in some currently
fuzzy cases - although, to be fair, both scope behaviors and OOO
guarantees are issues on their own quite independent of this PEP).

And, frankly, everyone else should be +1 too on whatever it is Guido
is privately thinking ;-)

From steve.dower at python.org  Fri May  4 19:40:41 2018
From: steve.dower at python.org (Steve Dower)
Date: Fri, 4 May 2018 16:40:41 -0700
Subject: [python-committers] PEP 572 at the Language Summit next week
In-Reply-To: <CAExdVNkcL_b0Jb=qnpX12tJQsX6xQvxRrV6oviZyQKOQmDGn1g@mail.gmail.com>
References: <CA+3bQGEsSOfLD+7+WGMCc1tfVRzBuxXNp=0vi0+=y7A3byxaaA@mail.gmail.com>
 <CAP7+vJK5AMoKAhU_bWrWC4tkE_c+DzgkPiZhf05TJ=nWgWk2Zw@mail.gmail.com>
 <CA+3bQGGGf3O2dSu0Bs-1tkGX=pGvp2G+s5SUvuvweumScb_hcQ@mail.gmail.com>
 <CAExdVNkcL_b0Jb=qnpX12tJQsX6xQvxRrV6oviZyQKOQmDGn1g@mail.gmail.com>
Message-ID: <e925ba67-8f45-15d5-6f38-e805d0fd81a1@python.org>

On 04May2018 1631, Tim Peters wrote:
> And, frankly, everyone else should be +1 too on whatever it is Guido
> is privately thinking ;-)

That wasn't what the poll was about :)

Cheers,
Steve

From larry at hastings.org  Fri May  4 20:52:02 2018
From: larry at hastings.org (Larry Hastings)
Date: Fri, 4 May 2018 17:52:02 -0700
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
Message-ID: <3cb08ab2-be85-a031-57dc-4b019e1c9974@hastings.org>


-1


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180504/2aae3f2a/attachment-0001.html>

From senthil at uthcode.com  Sun May  6 17:45:23 2018
From: senthil at uthcode.com (Senthil Kumaran)
Date: Sun, 6 May 2018 14:45:23 -0700
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <3cb08ab2-be85-a031-57dc-4b019e1c9974@hastings.org>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
 <3cb08ab2-be85-a031-57dc-4b019e1c9974@hastings.org>
Message-ID: <CAPOVWOSoBgMGY4QteptMvTfDXNLX4MuDyRTQbyeHQLrzERTF6A@mail.gmail.com>

-1.

Registering my vote. I studied only the PEP and didn't follow the
debate/discussion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180506/0bdacf8f/attachment.html>

From andrew.svetlov at gmail.com  Mon May  7 13:44:07 2018
From: andrew.svetlov at gmail.com (Andrew Svetlov)
Date: Mon, 07 May 2018 17:44:07 +0000
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CAPOVWOSoBgMGY4QteptMvTfDXNLX4MuDyRTQbyeHQLrzERTF6A@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
 <3cb08ab2-be85-a031-57dc-4b019e1c9974@hastings.org>
 <CAPOVWOSoBgMGY4QteptMvTfDXNLX4MuDyRTQbyeHQLrzERTF6A@mail.gmail.com>
Message-ID: <CAL3CFcV0Po9wCnReq8MepfUoiv3iUcJLq9V_hBw7JDqZt1MdXA@mail.gmail.com>

-1

On Mon, May 7, 2018 at 12:45 AM Senthil Kumaran <senthil at uthcode.com> wrote:

> -1.
>
> Registering my vote. I studied only the PEP and didn't follow the
> debate/discussion.
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-- 
Thanks,
Andrew Svetlov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180507/aa7ec813/attachment.html>

From steve at pearwood.info  Tue May  8 12:20:30 2018
From: steve at pearwood.info (Steven D'Aprano)
Date: Wed, 9 May 2018 02:20:30 +1000
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
Message-ID: <20180508162030.GE9562@ando.pearwood.info>

On Wed, May 02, 2018 at 11:49:36AM +0200, Victor Stinner wrote:
> Hi,
> 
> I would like to start a poll on Chris Angelico's PEP 572 "Assignment
> Expressions", restricted to Python core developers, to prepare the
> talk at the Language Summit:

With the changes suggested by Guido, +1

(I've track of where the PEP itself is, and whether or not it includes 
the new suggestions.)


-- 
Steve

From ethan at stoneleaf.us  Tue May  8 14:44:42 2018
From: ethan at stoneleaf.us (Ethan Furman)
Date: Tue, 08 May 2018 11:44:42 -0700
Subject: [python-committers] Poll: Do you like the PEP 572 Assignment
 Expressions?
In-Reply-To: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
References: <CA+3bQGHMKg67EeZynqa2R0428A5JuAdsi0Hk58MgKwL3n4+aFA@mail.gmail.com>
Message-ID: <5AF1F01A.5040407@stoneleaf.us>

With Tim's and Guido's latest suggestions,

+1

--
~Ethan~

From vstinner at redhat.com  Wed May  9 12:10:55 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Wed, 9 May 2018 12:10:55 -0400
Subject: [python-committers] Results of the poll: Do you like the PEP 572
 Assignment Expressions?
Message-ID: <CA+3bQGHR_JjiK4B2ed_YT9A6VmJBjy_TsWSSwTxac5mCBpAxjw@mail.gmail.com>

Hi,

As announced last week, I publish the result of the poll I started on
the *current* Chris Angelico's PEP 572 "Assignment Expressions":

   https://www.python.org/dev/peps/pep-0572/

Results:

* Like (+1): 3 (8%)
* Dislike (-1): 29 (76%)
* No opinion (0): 6 (16%)

Percents if you ignore no opinion:

* Like (+1): 3 (9%)
* Dislike (-1): 29 (91%)

Two people voted on a variant of the PEP, so I excluded from my results:

* Steven D'Aprano:  With the changes suggested by Guido, +1
* Ethan Furman: With Tim's and Guido's latest suggestions, +1

Again, it was just a poll. Not a vote. Multiple people also added a
second vote for a variant of the PEP. I only counted results on the
current PEP version.

It seems like "Tim's and Guido's latest suggestions" have big impact
and are awaited :-)

Like, vote: +1
==============

* Stefan Krah
* Tim Peters
* Jason R. Coombs

Dislike, vote: -1
=================

* Victor Stinner
* Antoine Pitrou
* Tal Einat
* Jack Jansen
* Berker Peksa?
* M.-A. Lemburg
* Alex Gaynor
* Nick Coghlan
* Paul Moore
* Eric Snow
* Yury Selivanov
* Facundo Batista
* Alexander Belopolsky
* ?ukasz Langa
* Stefan Richthofer
* Julien Palard
* Serhiy Storchaka
* Terry Reedy
* Steve Dower
* Raymond Hettinger
* Christian Heimes
* Gregory P. Smith
* Mark Dickinson
* Nathaniel Smith
* Carol Willing
* Kushal Das
* Larry Hastings
* Senthil Kumaran
* Andrew Svetlov

No opinion, vote: 0
===================

* INADA Naoki
* Ivan Levkivskyi
* Chris Jerdonek
* Barry Warsaw
* Ned Deily
* Robert Collins

Victor

From mariatta.wijaya at gmail.com  Mon May 14 14:21:48 2018
From: mariatta.wijaya at gmail.com (Mariatta Wijaya)
Date: Mon, 14 May 2018 11:21:48 -0700
Subject: [python-committers] Orphaned backports
In-Reply-To: <CAP1=2W4yWu5ZsrZcmAjo=Q91_2nDFuaiCh=B6f90MSjz3YaReg@mail.gmail.com>
References: <pbicbu$u3r$1@blaine.gmane.org>
 <2dac841a-881f-40b6-646a-674459fe0cc1@udel.edu>
 <CAP1=2W7DGf-ozQ=ZBSAxYq1VgMeDJ9vkbm4tEDB505Xjn_UG9g@mail.gmail.com>
 <48cb8f3c-59c0-ad20-33b7-a78cb557b805@gmail.com>
 <CAP1=2W4yWu5ZsrZcmAjo=Q91_2nDFuaiCh=B6f90MSjz3YaReg@mail.gmail.com>
Message-ID: <CAGbohnY01a1RgyQ1tafa0_Y=r5A4Hzyt1LfVL2hOM0Lu5T2NzA@mail.gmail.com>

To help with this, miss-islington will now assign the PR where backport had
failed to the core dev who merged the original PR.


Mariatta

On Tue, Apr 24, 2018 at 8:57 AM, Brett Cannon <brett at python.org> wrote:

>
>
> On Tue, 24 Apr 2018 at 02:59 Serhiy Storchaka <storchaka at gmail.com> wrote:
>
>> 23.04.18 19:47, Brett Cannon ????:
>>
>> On Sun, 22 Apr 2018 at 11:27 Terry Reedy <tjreedy at udel.edu> wrote:
>>
>>> Does github allow repository owners to send email directly to people who
>>> have submitted PRs or at least, people with commit privileges (in this
>>> case, those whose have done particular merges)?
>>>
>>
>> No. People have to provide explicit permission to expose their email
>> address. Otherwise the best we have are @ mentions in a comment.
>>
>>
>> Aren't all active committer subscribed to this mailing list?
>>
>
> They should be. Doesn't mean they pay attention to it. ;)
>
> -Brett
>
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180514/cdb9c8c4/attachment.html>

From brett at python.org  Mon May 14 14:26:47 2018
From: brett at python.org (Brett Cannon)
Date: Mon, 14 May 2018 14:26:47 -0400
Subject: [python-committers] Orphaned backports
In-Reply-To: <CAGbohnY01a1RgyQ1tafa0_Y=r5A4Hzyt1LfVL2hOM0Lu5T2NzA@mail.gmail.com>
References: <pbicbu$u3r$1@blaine.gmane.org>
 <2dac841a-881f-40b6-646a-674459fe0cc1@udel.edu>
 <CAP1=2W7DGf-ozQ=ZBSAxYq1VgMeDJ9vkbm4tEDB505Xjn_UG9g@mail.gmail.com>
 <48cb8f3c-59c0-ad20-33b7-a78cb557b805@gmail.com>
 <CAP1=2W4yWu5ZsrZcmAjo=Q91_2nDFuaiCh=B6f90MSjz3YaReg@mail.gmail.com>
 <CAGbohnY01a1RgyQ1tafa0_Y=r5A4Hzyt1LfVL2hOM0Lu5T2NzA@mail.gmail.com>
Message-ID: <CAP1=2W4_HXCae-mkJkHE1bAZHOc65zKmyrBcgUqc-OiHN8ZK0g@mail.gmail.com>

On Mon, 14 May 2018 at 14:22 Mariatta Wijaya <mariatta.wijaya at gmail.com>
wrote:

> To help with this, miss-islington will now assign the PR where backport
> had failed to the core dev who merged the original PR.
>

Great feature!

-Brett


>
>
> Mariatta
>
> On Tue, Apr 24, 2018 at 8:57 AM, Brett Cannon <brett at python.org> wrote:
>
>>
>>
>> On Tue, 24 Apr 2018 at 02:59 Serhiy Storchaka <storchaka at gmail.com>
>> wrote:
>>
>>> 23.04.18 19:47, Brett Cannon ????:
>>>
>>> On Sun, 22 Apr 2018 at 11:27 Terry Reedy <tjreedy at udel.edu> wrote:
>>>
>>>> Does github allow repository owners to send email directly to people
>>>> who
>>>> have submitted PRs or at least, people with commit privileges (in this
>>>> case, those whose have done particular merges)?
>>>>
>>>
>>> No. People have to provide explicit permission to expose their email
>>> address. Otherwise the best we have are @ mentions in a comment.
>>>
>>>
>>> Aren't all active committer subscribed to this mailing list?
>>>
>>
>> They should be. Doesn't mean they pay attention to it. ;)
>>
>> -Brett
>>
>>
>> _______________________________________________
>> python-committers mailing list
>> python-committers at python.org
>> https://mail.python.org/mailman/listinfo/python-committers
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
>>
> ?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180514/3529a9ed/attachment.html>

From larry at hastings.org  Mon May 14 16:41:00 2018
From: larry at hastings.org (Larry Hastings)
Date: Mon, 14 May 2018 16:41:00 -0400
Subject: [python-committers] Proposing Mark Shannon to be a core developer
Message-ID: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org>



Dr. Mark Shannon contributed the "key sharing dictionary" to Python, 
writing both the PEP and the implementation.? This shipped in Python 3.3 
and was listed as one of the top features of that release as according 
to the "What's New?" document.

We've asked Mark in the past if he'd be interested in becoming a core 
developer--and he actually said no.? At the time he said he didn't like 
our antiquated workflow.? Now that we've switched to the git-based core 
dev workflow, this objection is gone, and he's now interested in 
accepting the commit bit and the responsibilities that it entails.

I suspect you, my colleagues in CPython core development, will be 
surprised at the current state of affairs.? I'm expecting a load of "you 
mean Mark *isn't* a core developer yet?" replies.


Submitted for your consideration,


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180514/5a0778ca/attachment.html>

From antoine at python.org  Mon May 14 16:42:50 2018
From: antoine at python.org (Antoine Pitrou)
Date: Mon, 14 May 2018 22:42:50 +0200
Subject: [python-committers] Proposing Mark Shannon to be a core
 developer
In-Reply-To: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org>
References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org>
Message-ID: <b1188ec9-7551-c737-db2a-9f8417289743@python.org>


+1.

Regards

Antoine.


Le 14/05/2018 ? 22:41, Larry Hastings a ?crit?:
> 
> 
> Dr. Mark Shannon contributed the "key sharing dictionary" to Python,
> writing both the PEP and the implementation.? This shipped in Python 3.3
> and was listed as one of the top features of that release as according
> to the "What's New?" document.
> 
> We've asked Mark in the past if he'd be interested in becoming a core
> developer--and he actually said no.? At the time he said he didn't like
> our antiquated workflow.? Now that we've switched to the git-based core
> dev workflow, this objection is gone, and he's now interested in
> accepting the commit bit and the responsibilities that it entails.
> 
> I suspect you, my colleagues in CPython core development, will be
> surprised at the current state of affairs.? I'm expecting a load of "you
> mean Mark *isn't* a core developer yet?" replies.
> 
> 
> Submitted for your consideration,
> 
> 
> //arry/
> 
> 
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
> 

From tim.peters at gmail.com  Mon May 14 16:44:30 2018
From: tim.peters at gmail.com (Tim Peters)
Date: Mon, 14 May 2018 15:44:30 -0500
Subject: [python-committers] Proposing Mark Shannon to be a core
 developer
In-Reply-To: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org>
References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org>
Message-ID: <CAExdVNmOj3vPHemhe9wjivbazfufQzMTDEy07Jgv0Fknnd=2bA@mail.gmail.com>

+1

From eric at trueblade.com  Mon May 14 16:44:53 2018
From: eric at trueblade.com (Eric V. Smith)
Date: Mon, 14 May 2018 16:44:53 -0400
Subject: [python-committers] Proposing Mark Shannon to be a core
 developer
In-Reply-To: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org>
References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org>
Message-ID: <cc17569f-a5ac-f736-855f-8389d04ebc42@trueblade.com>

+1

Eric

On 5/14/18 4:41 PM, Larry Hastings wrote:
>
>
> Dr. Mark Shannon contributed the "key sharing dictionary" to Python,
> writing both the PEP and the implementation.  This shipped in Python 3.3
> and was listed as one of the top features of that release as according
> to the "What's New?" document.
>
> We've asked Mark in the past if he'd be interested in becoming a core
> developer--and he actually said no.  At the time he said he didn't like
> our antiquated workflow.  Now that we've switched to the git-based core
> dev workflow, this objection is gone, and he's now interested in
> accepting the commit bit and the responsibilities that it entails.
>
> I suspect you, my colleagues in CPython core development, will be
> surprised at the current state of affairs.  I'm expecting a load of "you
> mean Mark *isn't* a core developer yet?" replies.
>
>
> Submitted for your consideration,
>
>
> //arry/
>
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>

From guido at python.org  Mon May 14 17:12:30 2018
From: guido at python.org (Guido van Rossum)
Date: Mon, 14 May 2018 17:12:30 -0400
Subject: [python-committers] Proposing Mark Shannon to be a core
 developer
In-Reply-To: <cc17569f-a5ac-f736-855f-8389d04ebc42@trueblade.com>
References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org>
 <cc17569f-a5ac-f736-855f-8389d04ebc42@trueblade.com>
Message-ID: <CAP7+vJJmc8JFSMOq0R9fvifx5Y6v+Q=sX0zJ4wbfyVwY8wY8Ow@mail.gmail.com>

+2

On Mon, May 14, 2018 at 4:44 PM, Eric V. Smith <eric at trueblade.com> wrote:

> +1
>
> Eric
>
> On 5/14/18 4:41 PM, Larry Hastings wrote:
>
>>
>>
>> Dr. Mark Shannon contributed the "key sharing dictionary" to Python,
>> writing both the PEP and the implementation.  This shipped in Python 3.3
>> and was listed as one of the top features of that release as according
>> to the "What's New?" document.
>>
>> We've asked Mark in the past if he'd be interested in becoming a core
>> developer--and he actually said no.  At the time he said he didn't like
>> our antiquated workflow.  Now that we've switched to the git-based core
>> dev workflow, this objection is gone, and he's now interested in
>> accepting the commit bit and the responsibilities that it entails.
>>
>> I suspect you, my colleagues in CPython core development, will be
>> surprised at the current state of affairs.  I'm expecting a load of "you
>> mean Mark *isn't* a core developer yet?" replies.
>>
>>
>> Submitted for your consideration,
>>
>>
>> //arry/
>>
>>
>> _______________________________________________
>> python-committers mailing list
>> python-committers at python.org
>> https://mail.python.org/mailman/listinfo/python-committers
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
>> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180514/646794f5/attachment.html>

From ethan at stoneleaf.us  Mon May 14 17:18:13 2018
From: ethan at stoneleaf.us (Ethan Furman)
Date: Mon, 14 May 2018 14:18:13 -0700
Subject: [python-committers] Proposing Mark Shannon to be a core
 developer
In-Reply-To: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org>
References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org>
Message-ID: <5AF9FD15.6060408@stoneleaf.us>

On 05/14/2018 01:41 PM, Larry Hastings wrote:

> Dr. Mark Shannon contributed the "key sharing dictionary" to Python, writing both the PEP and the implementation.  This
> shipped in Python 3.3 and was listed as one of the top features of that release as according to the "What's New?" document.
>
> We've asked Mark in the past if he'd be interested in becoming a core developer--and he actually said no.  At the time
> he said he didn't like our antiquated workflow.  Now that we've switched to the git-based core dev workflow, this
> objection is gone, and he's now interested in accepting the commit bit and the responsibilities that it entails.

+1

--
~Ethan~

From ericsnowcurrently at gmail.com  Mon May 14 17:42:59 2018
From: ericsnowcurrently at gmail.com (Eric Snow)
Date: Mon, 14 May 2018 17:42:59 -0400
Subject: [python-committers] Proposing Mark Shannon to be a core
 developer
In-Reply-To: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org>
References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org>
Message-ID: <CALFfu7Cvg87ZT=ci=yvYdg6aHu+rb2qgPUg07Y76wQM5rL_tGg@mail.gmail.com>

+1

-eric

On Mon, May 14, 2018 at 4:41 PM, Larry Hastings <larry at hastings.org> wrote:
>
>
> Dr. Mark Shannon contributed the "key sharing dictionary" to Python, writing
> both the PEP and the implementation.  This shipped in Python 3.3 and was
> listed as one of the top features of that release as according to the
> "What's New?" document.
>
> We've asked Mark in the past if he'd be interested in becoming a core
> developer--and he actually said no.  At the time he said he didn't like our
> antiquated workflow.  Now that we've switched to the git-based core dev
> workflow, this objection is gone, and he's now interested in accepting the
> commit bit and the responsibilities that it entails.
>
> I suspect you, my colleagues in CPython core development, will be surprised
> at the current state of affairs.  I'm expecting a load of "you mean Mark
> *isn't* a core developer yet?" replies.
>
>
> Submitted for your consideration,
>
>
> /arry
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>

From levkivskyi at gmail.com  Mon May 14 17:55:17 2018
From: levkivskyi at gmail.com (Ivan Levkivskyi)
Date: Mon, 14 May 2018 17:55:17 -0400
Subject: [python-committers] Proposing Mark Shannon to be a core
 developer
In-Reply-To: <CALFfu7Cvg87ZT=ci=yvYdg6aHu+rb2qgPUg07Y76wQM5rL_tGg@mail.gmail.com>
References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org>
 <CALFfu7Cvg87ZT=ci=yvYdg6aHu+rb2qgPUg07Y76wQM5rL_tGg@mail.gmail.com>
Message-ID: <CAOMjWkkhEw+qUoxATjMuNJ6NY3_pcECSGO1zz5XN28PV6SpENA@mail.gmail.com>

+1

Yes, I actually thought he is a core dev for ages :-)

--
Ivan



On 14 May 2018 at 17:42, Eric Snow <ericsnowcurrently at gmail.com> wrote:

> +1
>
> -eric
>
> On Mon, May 14, 2018 at 4:41 PM, Larry Hastings <larry at hastings.org>
> wrote:
> >
> >
> > Dr. Mark Shannon contributed the "key sharing dictionary" to Python,
> writing
> > both the PEP and the implementation.  This shipped in Python 3.3 and was
> > listed as one of the top features of that release as according to the
> > "What's New?" document.
> >
> > We've asked Mark in the past if he'd be interested in becoming a core
> > developer--and he actually said no.  At the time he said he didn't like
> our
> > antiquated workflow.  Now that we've switched to the git-based core dev
> > workflow, this objection is gone, and he's now interested in accepting
> the
> > commit bit and the responsibilities that it entails.
> >
> > I suspect you, my colleagues in CPython core development, will be
> surprised
> > at the current state of affairs.  I'm expecting a load of "you mean Mark
> > *isn't* a core developer yet?" replies.
> >
> >
> > Submitted for your consideration,
> >
> >
> > /arry
> >
> > _______________________________________________
> > python-committers mailing list
> > python-committers at python.org
> > https://mail.python.org/mailman/listinfo/python-committers
> > Code of Conduct: https://www.python.org/psf/codeofconduct/
> >
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180514/1059d443/attachment.html>

From kbk at shore.net  Mon May 14 18:10:59 2018
From: kbk at shore.net (Kurt B. Kaiser)
Date: Mon, 14 May 2018 18:10:59 -0400
Subject: [python-committers] Proposing Mark Shannon to be a core
 developer
In-Reply-To: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org>
References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org>
Message-ID: <1526335859.430437.1372009008.7984E42C@webmail.messagingengine.com>

+1

On Mon, May 14, 2018, at 4:41 PM, Larry Hastings wrote:
> 
> 
> Dr. Mark Shannon contributed the "key sharing dictionary" to Python, 
> writing both the PEP and the implementation.? This shipped in Python 3.3 
> and was listed as one of the top features of that release as according 
> to the "What's New?" document.
> 
> We've asked Mark in the past if he'd be interested in becoming a core 
> developer--and he actually said no.? At the time he said he didn't like 
> our antiquated workflow.? Now that we've switched to the git-based core 
> dev workflow, this objection is gone, and he's now interested in 
> accepting the commit bit and the responsibilities that it entails.
> 
> I suspect you, my colleagues in CPython core development, will be 
> surprised at the current state of affairs.? I'm expecting a load of "you 
> mean Mark *isn't* a core developer yet?" replies.
> 
> 
> Submitted for your consideration,
> 
> 
> //arry/
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/

From p.f.moore at gmail.com  Mon May 14 18:32:30 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 14 May 2018 23:32:30 +0100
Subject: [python-committers] Proposing Mark Shannon to be a core
 developer
In-Reply-To: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org>
References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org>
Message-ID: <CACac1F9LH8g-jN9ZpKsQWPz8BG2Ltaq+b_TLMuLYbs-8J5pH2g@mail.gmail.com>

+1 from me :-)

On 14 May 2018 at 21:41, Larry Hastings <larry at hastings.org> wrote:
>
>
> Dr. Mark Shannon contributed the "key sharing dictionary" to Python, writing
> both the PEP and the implementation.  This shipped in Python 3.3 and was
> listed as one of the top features of that release as according to the
> "What's New?" document.
>
> We've asked Mark in the past if he'd be interested in becoming a core
> developer--and he actually said no.  At the time he said he didn't like our
> antiquated workflow.  Now that we've switched to the git-based core dev
> workflow, this objection is gone, and he's now interested in accepting the
> commit bit and the responsibilities that it entails.
>
> I suspect you, my colleagues in CPython core development, will be surprised
> at the current state of affairs.  I'm expecting a load of "you mean Mark
> *isn't* a core developer yet?" replies.
>
>
> Submitted for your consideration,
>
>
> /arry
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>

From songofacandy at gmail.com  Mon May 14 18:13:41 2018
From: songofacandy at gmail.com (INADA Naoki)
Date: Tue, 15 May 2018 07:13:41 +0900
Subject: [python-committers] Proposing Mark Shannon to be a core
 developer
In-Reply-To: <CAOMjWkkhEw+qUoxATjMuNJ6NY3_pcECSGO1zz5XN28PV6SpENA@mail.gmail.com>
References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org>
 <CALFfu7Cvg87ZT=ci=yvYdg6aHu+rb2qgPUg07Y76wQM5rL_tGg@mail.gmail.com>
 <CAOMjWkkhEw+qUoxATjMuNJ6NY3_pcECSGO1zz5XN28PV6SpENA@mail.gmail.com>
Message-ID: <CAEfz+Tx7ms1B_uerGXyFiCHF+30_+qoz5Z1_yH5Ma8Av+BP_-Q@mail.gmail.com>

+1

2018?5?15?(?) 6:55 Ivan Levkivskyi <levkivskyi at gmail.com>:

> +1
>
> Yes, I actually thought he is a core dev for ages :-)
>

Me too.


> --
> Ivan
>
>
>
> On 14 May 2018 at 17:42, Eric Snow <ericsnowcurrently at gmail.com> wrote:
>
>> +1
>>
>> -eric
>>
>> On Mon, May 14, 2018 at 4:41 PM, Larry Hastings <larry at hastings.org>
>> wrote:
>> >
>> >
>> > Dr. Mark Shannon contributed the "key sharing dictionary" to Python,
>> writing
>> > both the PEP and the implementation.  This shipped in Python 3.3 and was
>> > listed as one of the top features of that release as according to the
>> > "What's New?" document.
>> >
>> > We've asked Mark in the past if he'd be interested in becoming a core
>> > developer--and he actually said no.  At the time he said he didn't like
>> our
>> > antiquated workflow.  Now that we've switched to the git-based core dev
>> > workflow, this objection is gone, and he's now interested in accepting
>> the
>> > commit bit and the responsibilities that it entails.
>> >
>> > I suspect you, my colleagues in CPython core development, will be
>> surprised
>> > at the current state of affairs.  I'm expecting a load of "you mean Mark
>> > *isn't* a core developer yet?" replies.
>> >
>> >
>> > Submitted for your consideration,
>> >
>> >
>> > /arry
>> >
>> > _______________________________________________
>> > python-committers mailing list
>> > python-committers at python.org
>> > https://mail.python.org/mailman/listinfo/python-committers
>> > Code of Conduct: https://www.python.org/psf/codeofconduct/
>> >
>> _______________________________________________
>> python-committers mailing list
>> python-committers at python.org
>> https://mail.python.org/mailman/listinfo/python-committers
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180515/30b0fb9b/attachment-0001.html>

From storchaka at gmail.com  Mon May 14 18:45:00 2018
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Tue, 15 May 2018 01:45:00 +0300
Subject: [python-committers] Proposing Mark Shannon to be a core
 developer
In-Reply-To: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org>
References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org>
Message-ID: <1a0517d7-5763-d1f9-84b0-c8725d73ebc3@gmail.com>

14.05.18 23:41, Larry Hastings ????:

> Dr. Mark Shannon contributed the "key sharing dictionary" to Python, 
> writing both the PEP and the implementation.? This shipped in Python 
> 3.3 and was listed as one of the top features of that release as 
> according to the "What's New?" document.
>
> We've asked Mark in the past if he'd be interested in becoming a core 
> developer--and he actually said no.? At the time he said he didn't 
> like our antiquated workflow.? Now that we've switched to the 
> git-based core dev workflow, this objection is gone, and he's now 
> interested in accepting the commit bit and the responsibilities that 
> it entails.
>
> I suspect you, my colleagues in CPython core development, will be 
> surprised at the current state of affairs.? I'm expecting a load of 
> "you mean Mark *isn't* a core developer yet?" replies.

+1 from me. I always wondered why he is not a core developer.


From willingc at gmail.com  Mon May 14 18:58:36 2018
From: willingc at gmail.com (Carol Willing)
Date: Mon, 14 May 2018 18:58:36 -0400
Subject: [python-committers] Proposing Mark Shannon to be a core
 developer
In-Reply-To: <CAEfz+Tx7ms1B_uerGXyFiCHF+30_+qoz5Z1_yH5Ma8Av+BP_-Q@mail.gmail.com>
References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org>
 <CALFfu7Cvg87ZT=ci=yvYdg6aHu+rb2qgPUg07Y76wQM5rL_tGg@mail.gmail.com>
 <CAOMjWkkhEw+qUoxATjMuNJ6NY3_pcECSGO1zz5XN28PV6SpENA@mail.gmail.com>
 <CAEfz+Tx7ms1B_uerGXyFiCHF+30_+qoz5Z1_yH5Ma8Av+BP_-Q@mail.gmail.com>
Message-ID: <CAM3VvhxZAK6OcG+As=SvrMwQ8MiyQQskjOTvhoVkK5fgyZV82w@mail.gmail.com>

+1

On Mon, May 14, 2018, 6:47 PM INADA Naoki <songofacandy at gmail.com> wrote:

> +1
>
> 2018?5?15?(?) 6:55 Ivan Levkivskyi <levkivskyi at gmail.com>:
>
>> +1
>>
>> Yes, I actually thought he is a core dev for ages :-)
>>
>
> Me too.
>
>
>> --
>> Ivan
>>
>>
>>
>> On 14 May 2018 at 17:42, Eric Snow <ericsnowcurrently at gmail.com> wrote:
>>
>>> +1
>>>
>>> -eric
>>>
>>> On Mon, May 14, 2018 at 4:41 PM, Larry Hastings <larry at hastings.org>
>>> wrote:
>>> >
>>> >
>>> > Dr. Mark Shannon contributed the "key sharing dictionary" to Python,
>>> writing
>>> > both the PEP and the implementation.  This shipped in Python 3.3 and
>>> was
>>> > listed as one of the top features of that release as according to the
>>> > "What's New?" document.
>>> >
>>> > We've asked Mark in the past if he'd be interested in becoming a core
>>> > developer--and he actually said no.  At the time he said he didn't
>>> like our
>>> > antiquated workflow.  Now that we've switched to the git-based core dev
>>> > workflow, this objection is gone, and he's now interested in accepting
>>> the
>>> > commit bit and the responsibilities that it entails.
>>> >
>>> > I suspect you, my colleagues in CPython core development, will be
>>> surprised
>>> > at the current state of affairs.  I'm expecting a load of "you mean
>>> Mark
>>> > *isn't* a core developer yet?" replies.
>>> >
>>> >
>>> > Submitted for your consideration,
>>> >
>>> >
>>> > /arry
>>> >
>>> > _______________________________________________
>>> > python-committers mailing list
>>> > python-committers at python.org
>>> > https://mail.python.org/mailman/listinfo/python-committers
>>> > Code of Conduct: https://www.python.org/psf/codeofconduct/
>>> >
>>> _______________________________________________
>>> python-committers mailing list
>>> python-committers at python.org
>>> https://mail.python.org/mailman/listinfo/python-committers
>>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>>
>>
>> _______________________________________________
>> python-committers mailing list
>> python-committers at python.org
>> https://mail.python.org/mailman/listinfo/python-committers
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180514/11133e84/attachment.html>

From yselivanov.ml at gmail.com  Mon May 14 20:30:45 2018
From: yselivanov.ml at gmail.com (Yury Selivanov)
Date: Mon, 14 May 2018 20:30:45 -0400
Subject: [python-committers] Proposing Mark Shannon to be a core
 developer
In-Reply-To: <CAM3VvhxZAK6OcG+As=SvrMwQ8MiyQQskjOTvhoVkK5fgyZV82w@mail.gmail.com>
References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org>
 <CALFfu7Cvg87ZT=ci=yvYdg6aHu+rb2qgPUg07Y76wQM5rL_tGg@mail.gmail.com>
 <CAOMjWkkhEw+qUoxATjMuNJ6NY3_pcECSGO1zz5XN28PV6SpENA@mail.gmail.com>
 <CAEfz+Tx7ms1B_uerGXyFiCHF+30_+qoz5Z1_yH5Ma8Av+BP_-Q@mail.gmail.com>
 <CAM3VvhxZAK6OcG+As=SvrMwQ8MiyQQskjOTvhoVkK5fgyZV82w@mail.gmail.com>
Message-ID: <CA+St6D01SmUNaF_zUAvPDwi6AJp29UCVEf17k51-0BaCUdPwgA@mail.gmail.com>

+1

Yury
-- 
         Yury
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180514/573c22ea/attachment.html>

From lukasz at langa.pl  Mon May 14 20:33:18 2018
From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=)
Date: Mon, 14 May 2018 20:33:18 -0400
Subject: [python-committers] Proposing Mark Shannon to be a core
 developer
In-Reply-To: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org>
References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org>
Message-ID: <DD924746-FBAE-4D40-8FB0-A69E25251610@langa.pl>

+1

-- 
Best regards,
?ukasz Langa

> On May 14, 2018, at 4:41 PM, Larry Hastings <larry at hastings.org> wrote:
> 
> 
> 
> Dr. Mark Shannon contributed the "key sharing dictionary" to Python, writing both the PEP and the implementation.  This shipped in Python 3.3 and was listed as one of the top features of that release as according to the "What's New?" document.
> 
> We've asked Mark in the past if he'd be interested in becoming a core developer--and he actually said no.  At the time he said he didn't like our antiquated workflow.  Now that we've switched to the git-based core dev workflow, this objection is gone, and he's now interested in accepting the commit bit and the responsibilities that it entails.
> 
> I suspect you, my colleagues in CPython core development, will be surprised at the current state of affairs.  I'm expecting a load of "you mean Mark *isn't* a core developer yet?" replies.
> 
> 
> Submitted for your consideration,
> 
> 
> /arry
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180514/cc034d36/attachment-0001.html>

From christian at python.org  Mon May 14 21:38:05 2018
From: christian at python.org (Christian Heimes)
Date: Mon, 14 May 2018 21:38:05 -0400
Subject: [python-committers] Proposing Mark Shannon to be a core
 developer
In-Reply-To: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org>
References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org>
Message-ID: <4c9f3924-fcf4-ceef-d475-35cc6bf166f5@python.org>

On 2018-05-14 16:41, Larry Hastings wrote:
> 
> 
> Dr. Mark Shannon contributed the "key sharing dictionary" to Python,
> writing both the PEP and the implementation.? This shipped in Python 3.3
> and was listed as one of the top features of that release as according
> to the "What's New?" document.
> 
> We've asked Mark in the past if he'd be interested in becoming a core
> developer--and he actually said no.? At the time he said he didn't like
> our antiquated workflow.? Now that we've switched to the git-based core
> dev workflow, this objection is gone, and he's now interested in
> accepting the commit bit and the responsibilities that it entails.
> 
> I suspect you, my colleagues in CPython core development, will be
> surprised at the current state of affairs.? I'm expecting a load of "you
> mean Mark *isn't* a core developer yet?" replies.
>

+1

From eric at trueblade.com  Mon May 14 21:49:36 2018
From: eric at trueblade.com (Eric V. Smith)
Date: Mon, 14 May 2018 21:49:36 -0400
Subject: [python-committers] AppVeyor and Travis-CI
Message-ID: <1093b6a8-1cfd-cab0-6d6c-b0acc4700e11@trueblade.com>

I accidentally checked in some test files, and they got backported to 
3.7. I pushed a commit to delete them, and it was committed to master.

But in the 3.7 backport, something has gone wrong with AppVeyor and 
Travis-CI.

https://github.com/python/cpython/pull/6844

AppVeyor says "Expected ? Waiting for status to be reported". There's no 
obvious way to get it to actually report the status, or to restart. 
There is no "Details" button listed on the PR page.

For Travis-CI, Miss Isslington sent me an email that says "Backport 
status check is done, and it's a failure ? ." The Travis-CI log file 
ends with a timeout:

======================================================================
FAIL: test_stdin_broken_pipe 
(test.test_asyncio.test_subprocess.SubprocessSafeWatcherTests)
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"/home/travis/build/python/cpython/Lib/test/test_asyncio/test_subprocess.py", 
line 214, in test_stdin_broken_pipe
     self.loop.run_until_complete, coro)
AssertionError: (<class 'BrokenPipeError'>, <class 
'ConnectionResetError'>) not raised by run_until_complete
----------------------------------------------------------------------

I'm sure this is all due to the heavy load the systems are under. I 
can't find a way to kick both of these off again. I couldn't find 
anything in the devguide, but if I missed it please let me know.

Thanks.
Eric

From tjreedy at udel.edu  Mon May 14 23:36:07 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 14 May 2018 23:36:07 -0400
Subject: [python-committers] AppVeyor and Travis-CI
In-Reply-To: <1093b6a8-1cfd-cab0-6d6c-b0acc4700e11@trueblade.com>
References: <1093b6a8-1cfd-cab0-6d6c-b0acc4700e11@trueblade.com>
Message-ID: <4a843ab2-2c2f-b490-bebc-02cf5bcb8bb4@udel.edu>

On 5/14/2018 9:49 PM, Eric V. Smith wrote:
> I accidentally checked in some test files, and they got backported to 
> 3.7. I pushed a commit to delete them, and it was committed to master.
> 
> But in the 3.7 backport, something has gone wrong with AppVeyor and 
> Travis-CI.
> 
> https://github.com/python/cpython/pull/6844
> 
> AppVeyor says "Expected ? Waiting for status to be reported". There's no 
> obvious way to get it to actually report the status, or to restart. 
> There is no "Details" button listed on the PR page.
> 
> For Travis-CI, Miss Isslington sent me an email that says "Backport 
> status check is done, and it's a failure ? ." The Travis-CI log file 
> ends with a timeout:
> 
> ======================================================================
> FAIL: test_stdin_broken_pipe 
> (test.test_asyncio.test_subprocess.SubprocessSafeWatcherTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  ? File 
> "/home/travis/build/python/cpython/Lib/test/test_asyncio/test_subprocess.py", 
> line 214, in test_stdin_broken_pipe
>  ??? self.loop.run_until_complete, coro)
> AssertionError: (<class 'BrokenPipeError'>, <class 
> 'ConnectionResetError'>) not raised by run_until_complete
> ----------------------------------------------------------------------
> 
> I'm sure this is all due to the heavy load the systems are under. I 
> can't find a way to kick both of these off again. I couldn't find 
> anything in the devguide, but if I missed it please let me know.

I have triggered retesting by editing the blurb.  It may be that 
touching by adding and deleting a space was enough, or maybe I had to 
actually change something.

But retesting right now, with tests failing, is useless.  I just 
submitting a trivial change and got the same unrelated failures for 
importlib, multiprocessing, and asyncio.

Warning -- files was modified by test_importlib
   Before: []
   After:  ['core']

ERROR: test_ignore (test.test_multiprocessing_forkserver.TestIgnoreEINTR)
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"/home/travis/build/python/cpython/Lib/test/_test_multiprocessing.py", 
line 4359, in test_ignore
     os.kill(p.pid, signal.SIGUSR1)
ProcessLookupError: [Errno 3] No such process
----------------------------------------------------------------------
Ran 310 tests in 93.862s
FAILED (errors=1, skipped=27)
test test_multiprocessing_forkserver failed

and the same or similar multiple failures for asyncio

Both our tests ended with

FAILED (failures=2, skipped=14)
test test_asyncio failed
2 tests failed again:
     test_asyncio test_multiprocessing_forkserver
Total duration: 14 min 29 sec
Tests result: FAILURE

and we cannot merge.


From vstinner at redhat.com  Tue May 15 00:27:19 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Tue, 15 May 2018 00:27:19 -0400
Subject: [python-committers] Proposing Mark Shannon to be a core
 developer
In-Reply-To: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org>
References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org>
Message-ID: <CA+3bQGGU598TkrMqDvsB3Y=xwMP8HOeWZRq1z3pOBgEC0QKKyw@mail.gmail.com>

2018-05-14 16:41 GMT-04:00 Larry Hastings <larry at hastings.org>:
> Dr. Mark Shannon contributed the "key sharing dictionary" to Python, writing
> both the PEP and the implementation.  This shipped in Python 3.3 and was
> listed as one of the top features of that release as according to the
> "What's New?" document.
>
> We've asked Mark in the past if he'd be interested in becoming a core
> developer--and he actually said no.  At the time he said he didn't like our
> antiquated workflow.  Now that we've switched to the git-based core dev
> workflow, this objection is gone, and he's now interested in accepting the
> commit bit and the responsibilities that it entails.
>
> I suspect you, my colleagues in CPython core development, will be surprised
> at the current state of affairs.  I'm expecting a load of "you mean Mark
> *isn't* a core developer yet?" replies.

Wait. Mark is already a core dev, right? I don't understand your email :-)

+1, obvisouly.

Victor

From nad at python.org  Tue May 15 07:51:52 2018
From: nad at python.org (Ned Deily)
Date: Tue, 15 May 2018 07:51:52 -0400
Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
Message-ID: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>

This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your
feature fixes, bug fixes, and documentation updates in before
2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days
from now. We will then tag and produce the 3.7.0 release candidate.
Our goal continues been to be to have no changes between the release
candidate and final; AFTER NEXT WEEK'S RC1, CHANGES APPLIED TO THE 3.7
BRANCH WILL BE RELEASED IN 3.7.1. Please double-check that there are
no critical problems outstanding and that documentation for new
features in 3.7 is complete (including NEWS and What's New items), and
that 3.7 is getting exposure and tested with our various platorms and
third-party distributions and applications. Those of us who are
participating in the development sprints at PyCon US 2018 here in
Cleveland can feel the excitement building as we work through the
remaining issues, including completing the "What's New in 3.7"
document and final feature documentation. (We wish you could all be
here.)

As noted before, the ABI for 3.7.0 was frozen as of 3.7.0b3. You
should now be treating the 3.7 branch as if it were already released
and in maintenance mode. That means you should only push the kinds of
changes that are appropriate for a maintenance release:
non-ABI-changing bug and feature fixes and documentation updates. If
you find a problem that requires an ABI-altering or other significant
user-facing change (for example, something likely to introduce an
incompatibility with existing users' code or require rebuilding of
user extension modules), please make sure to set the b.p.o issue to
"release blocker" priority and describe there why you feel the change
is necessary. If you are reviewing PRs for 3.7 (and please do!), be on
the lookout for and flag potential incompatibilities (we've all made
them).

Thanks again for all of your hard work towards making 3.7.0 yet
another great release - coming to a website near you on 06-15!

Release Managerly Yours,
--Ned

https://www.python.org/dev/peps/pep-0537/

--
  Ned Deily
  nad at python.org -- []


From andrew.svetlov at gmail.com  Tue May 15 08:43:05 2018
From: andrew.svetlov at gmail.com (Andrew Svetlov)
Date: Tue, 15 May 2018 15:43:05 +0300
Subject: [python-committers] Idea: Create subteams?
In-Reply-To: <CA+St6D09+6juu1_rHkeVByKTf9Sn_3NSDF3kEpVWKJ2aaPFOjQ@mail.gmail.com>
References: <CA+3bQGFTXK=6U-23e23wM5UBv6xR4ONSzyE6zYb0-b66O0ZGnQ@mail.gmail.com>
 <CA+St6D09+6juu1_rHkeVByKTf9Sn_3NSDF3kEpVWKJ2aaPFOjQ@mail.gmail.com>
Message-ID: <CAL3CFcVTvy2T4uBUYGsLNHbRdtPHNRZK71z61hgYiYDZvyFNBA@mail.gmail.com>

Agree with Yuri. We have not big amount of non-committer contributions into
asyncio, and every non-trivial change requires very careful review.

On Thu, Apr 26, 2018, 17:32 Yury Selivanov <yselivanov.ml at gmail.com> wrote:

> On Thu, Apr 26, 2018 at 10:12 AM Victor Stinner <vstinner at redhat.com>
> wrote:
> [..]
> > I identified 3 obvious subteams:
>
> > * Documentation
> > * IDLE
> > * asyncio
>
> Sorry, asyncio isn't an obvious choice for me. There are not so many
> low-hanging fruits left in asyncio except improvements to its
> documentation. I'm a firm -1 to allow people to merge without Andrew's or
> my review at this point, almost no PRs are fine when they are submitted
> (including our own). There's a lot of complexity in asyncio which isn't
> immediately evident to people who are not working with its internals on a
> daily basis.
>
> Now, people who report and submit asyncio PRs seem to do that just fine
> without subteams. Although it's rare to see people contributing more than
> once, but that's not an asyncio-specific pattern, I see it in every big and
> complex project I happen to contribute to.  Even having a dedicated asyncio
> mailing list doesn't help to get people to contribute to asyncio more
> frequently.
>
> Don't get me wrong, Andrew and I would certainly welcome any help we can
> get, but I'd be against running a public experiment with asyncio to see if
> 2 of us can handle the management of the new sub-teams idea.  Unfortunately
> 2 of us just don't have capacity for that.
>
> Please pick another project for your idea. Maybe we should try it for
> documentation first, where we have a lot of core devs who can help with PR
> reviews and management of "subteams".
>
> Yury
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-- 
Thanks,
Andrew Svetlov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180515/cea0a280/attachment.html>

From guido at python.org  Tue May 15 11:34:37 2018
From: guido at python.org (Guido van Rossum)
Date: Tue, 15 May 2018 11:34:37 -0400
Subject: [python-committers] Proposing Mark Shannon to be a core
 developer
In-Reply-To: <CA+3bQGGU598TkrMqDvsB3Y=xwMP8HOeWZRq1z3pOBgEC0QKKyw@mail.gmail.com>
References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org>
 <CA+3bQGGU598TkrMqDvsB3Y=xwMP8HOeWZRq1z3pOBgEC0QKKyw@mail.gmail.com>
Message-ID: <CAP7+vJLrKwM61vGGcEKXtCQtDLzRBYubp2g07273F_M2n-=B5A@mail.gmail.com>

Let's stop the email barrage, Mark is in. Can someone tell Mark what to do?

On Tue, May 15, 2018 at 12:27 AM, Victor Stinner <vstinner at redhat.com>
wrote:

> 2018-05-14 16:41 GMT-04:00 Larry Hastings <larry at hastings.org>:
> > Dr. Mark Shannon contributed the "key sharing dictionary" to Python,
> writing
> > both the PEP and the implementation.  This shipped in Python 3.3 and was
> > listed as one of the top features of that release as according to the
> > "What's New?" document.
> >
> > We've asked Mark in the past if he'd be interested in becoming a core
> > developer--and he actually said no.  At the time he said he didn't like
> our
> > antiquated workflow.  Now that we've switched to the git-based core dev
> > workflow, this objection is gone, and he's now interested in accepting
> the
> > commit bit and the responsibilities that it entails.
> >
> > I suspect you, my colleagues in CPython core development, will be
> surprised
> > at the current state of affairs.  I'm expecting a load of "you mean Mark
> > *isn't* a core developer yet?" replies.
>
> Wait. Mark is already a core dev, right? I don't understand your email :-)
>
> +1, obvisouly.
>
> Victor
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180515/c5c0a6ef/attachment.html>

From eric at trueblade.com  Tue May 15 11:35:58 2018
From: eric at trueblade.com (Eric V. Smith)
Date: Tue, 15 May 2018 11:35:58 -0400
Subject: [python-committers] AppVeyor and Travis-CI
In-Reply-To: <CAP1=2W65i1PcynL1SZPjwPeZhxQG+i-WzM4tXuPwOhFP7DzvcA@mail.gmail.com>
References: <1093b6a8-1cfd-cab0-6d6c-b0acc4700e11@trueblade.com>
 <CAP1=2W65i1PcynL1SZPjwPeZhxQG+i-WzM4tXuPwOhFP7DzvcA@mail.gmail.com>
Message-ID: <c9350682-0180-b69b-c548-3e0ddeb6f1d1@trueblade.com>

Thanks. You mean close and re-open the bpo issue?

In the past I saw a Travis "re-run" button, but now I don't. I expected 
to see it on the Travis page, but last night I only saw a "More options" 
menu and no "re-run". The next time something fails I'll look again.

On 5/15/18 11:23 AM, Brett Cannon wrote:
> You can always close and then open an issue to re-trigger CI. As for
> Travis specifically, you  should have the proper permissions to forcibly
> re-run the builds.
>
> On Mon, 14 May 2018 at 21:50 Eric V. Smith <eric at trueblade.com
> <mailto:eric at trueblade.com>> wrote:
>
>     I accidentally checked in some test files, and they got backported to
>     3.7. I pushed a commit to delete them, and it was committed to master.
>
>     But in the 3.7 backport, something has gone wrong with AppVeyor and
>     Travis-CI.
>
>     https://github.com/python/cpython/pull/6844
>
>     AppVeyor says "Expected ? Waiting for status to be reported".
>     There's no
>     obvious way to get it to actually report the status, or to restart.
>     There is no "Details" button listed on the PR page.
>
>     For Travis-CI, Miss Isslington sent me an email that says "Backport
>     status check is done, and it's a failure ? ." The Travis-CI log file
>     ends with a timeout:
>
>     ======================================================================
>     FAIL: test_stdin_broken_pipe
>     (test.test_asyncio.test_subprocess.SubprocessSafeWatcherTests)
>     ----------------------------------------------------------------------
>     Traceback (most recent call last):
>        File
>     "/home/travis/build/python/cpython/Lib/test/test_asyncio/test_subprocess.py",
>
>     line 214, in test_stdin_broken_pipe
>          self.loop.run_until_complete, coro)
>     AssertionError: (<class 'BrokenPipeError'>, <class
>     'ConnectionResetError'>) not raised by run_until_complete
>     ----------------------------------------------------------------------
>
>     I'm sure this is all due to the heavy load the systems are under. I
>     can't find a way to kick both of these off again. I couldn't find
>     anything in the devguide, but if I missed it please let me know.
>
>     Thanks.
>     Eric
>     _______________________________________________
>     python-committers mailing list
>     python-committers at python.org <mailto:python-committers at python.org>
>     https://mail.python.org/mailman/listinfo/python-committers
>     Code of Conduct: https://www.python.org/psf/codeofconduct/
>

From brett at python.org  Tue May 15 11:23:00 2018
From: brett at python.org (Brett Cannon)
Date: Tue, 15 May 2018 11:23:00 -0400
Subject: [python-committers] AppVeyor and Travis-CI
In-Reply-To: <1093b6a8-1cfd-cab0-6d6c-b0acc4700e11@trueblade.com>
References: <1093b6a8-1cfd-cab0-6d6c-b0acc4700e11@trueblade.com>
Message-ID: <CAP1=2W65i1PcynL1SZPjwPeZhxQG+i-WzM4tXuPwOhFP7DzvcA@mail.gmail.com>

You can always close and then open an issue to re-trigger CI. As for Travis
specifically, you  should have the proper permissions to forcibly re-run
the builds.

On Mon, 14 May 2018 at 21:50 Eric V. Smith <eric at trueblade.com> wrote:

> I accidentally checked in some test files, and they got backported to
> 3.7. I pushed a commit to delete them, and it was committed to master.
>
> But in the 3.7 backport, something has gone wrong with AppVeyor and
> Travis-CI.
>
> https://github.com/python/cpython/pull/6844
>
> AppVeyor says "Expected ? Waiting for status to be reported". There's no
> obvious way to get it to actually report the status, or to restart.
> There is no "Details" button listed on the PR page.
>
> For Travis-CI, Miss Isslington sent me an email that says "Backport
> status check is done, and it's a failure ? ." The Travis-CI log file
> ends with a timeout:
>
> ======================================================================
> FAIL: test_stdin_broken_pipe
> (test.test_asyncio.test_subprocess.SubprocessSafeWatcherTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>    File
> "/home/travis/build/python/cpython/Lib/test/test_asyncio/test_subprocess.py",
>
> line 214, in test_stdin_broken_pipe
>      self.loop.run_until_complete, coro)
> AssertionError: (<class 'BrokenPipeError'>, <class
> 'ConnectionResetError'>) not raised by run_until_complete
> ----------------------------------------------------------------------
>
> I'm sure this is all due to the heavy load the systems are under. I
> can't find a way to kick both of these off again. I couldn't find
> anything in the devguide, but if I missed it please let me know.
>
> Thanks.
> Eric
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180515/e6c5121c/attachment.html>

From guido at python.org  Tue May 15 14:02:56 2018
From: guido at python.org (Guido van Rossum)
Date: Tue, 15 May 2018 14:02:56 -0400
Subject: [python-committers] AppVeyor and Travis-CI
In-Reply-To: <c9350682-0180-b69b-c548-3e0ddeb6f1d1@trueblade.com>
References: <1093b6a8-1cfd-cab0-6d6c-b0acc4700e11@trueblade.com>
 <CAP1=2W65i1PcynL1SZPjwPeZhxQG+i-WzM4tXuPwOhFP7DzvcA@mail.gmail.com>
 <c9350682-0180-b69b-c548-3e0ddeb6f1d1@trueblade.com>
Message-ID: <CAP7+vJ+t_tOwtdg6dbh3ZSZrWRX1enFGHx9MsomPn7mVoWx9bQ@mail.gmail.com>

IIUC you have to close and reopen the PR.

On Tue, May 15, 2018 at 11:35 AM, Eric V. Smith <eric at trueblade.com> wrote:

> Thanks. You mean close and re-open the bpo issue?
>
> In the past I saw a Travis "re-run" button, but now I don't. I expected to
> see it on the Travis page, but last night I only saw a "More options" menu
> and no "re-run". The next time something fails I'll look again.
>
> On 5/15/18 11:23 AM, Brett Cannon wrote:
>
>> You can always close and then open an issue to re-trigger CI. As for
>> Travis specifically, you  should have the proper permissions to forcibly
>> re-run the builds.
>>
>> On Mon, 14 May 2018 at 21:50 Eric V. Smith <eric at trueblade.com
>> <mailto:eric at trueblade.com>> wrote:
>>
>>     I accidentally checked in some test files, and they got backported to
>>     3.7. I pushed a commit to delete them, and it was committed to master.
>>
>>     But in the 3.7 backport, something has gone wrong with AppVeyor and
>>     Travis-CI.
>>
>>     https://github.com/python/cpython/pull/6844
>>
>>     AppVeyor says "Expected ? Waiting for status to be reported".
>>     There's no
>>     obvious way to get it to actually report the status, or to restart.
>>     There is no "Details" button listed on the PR page.
>>
>>     For Travis-CI, Miss Isslington sent me an email that says "Backport
>>     status check is done, and it's a failure ? ." The Travis-CI log file
>>     ends with a timeout:
>>
>>     ============================================================
>> ==========
>>     FAIL: test_stdin_broken_pipe
>>     (test.test_asyncio.test_subprocess.SubprocessSafeWatcherTests)
>>     ------------------------------------------------------------
>> ----------
>>     Traceback (most recent call last):
>>        File
>>     "/home/travis/build/python/cpython/Lib/test/test_asyncio/tes
>> t_subprocess.py",
>>
>>     line 214, in test_stdin_broken_pipe
>>          self.loop.run_until_complete, coro)
>>     AssertionError: (<class 'BrokenPipeError'>, <class
>>     'ConnectionResetError'>) not raised by run_until_complete
>>     ------------------------------------------------------------
>> ----------
>>
>>     I'm sure this is all due to the heavy load the systems are under. I
>>     can't find a way to kick both of these off again. I couldn't find
>>     anything in the devguide, but if I missed it please let me know.
>>
>>     Thanks.
>>     Eric
>>     _______________________________________________
>>     python-committers mailing list
>>     python-committers at python.org <mailto:python-committers at python.org>
>>     https://mail.python.org/mailman/listinfo/python-committers
>>     Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
>> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180515/047a9174/attachment.html>

From tjreedy at udel.edu  Tue May 15 16:36:33 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 15 May 2018 16:36:33 -0400
Subject: [python-committers] AppVeyor and Travis-CI
In-Reply-To: <CAP7+vJ+t_tOwtdg6dbh3ZSZrWRX1enFGHx9MsomPn7mVoWx9bQ@mail.gmail.com>
References: <1093b6a8-1cfd-cab0-6d6c-b0acc4700e11@trueblade.com>
 <CAP1=2W65i1PcynL1SZPjwPeZhxQG+i-WzM4tXuPwOhFP7DzvcA@mail.gmail.com>
 <c9350682-0180-b69b-c548-3e0ddeb6f1d1@trueblade.com>
 <CAP7+vJ+t_tOwtdg6dbh3ZSZrWRX1enFGHx9MsomPn7mVoWx9bQ@mail.gmail.com>
Message-ID: <d8f46785-993e-37ac-9084-0c2d54e7a522@udel.edu>

I am getting repeated bogus failures, completely unrelated to a trivial 
patch, more often than not, on Travis-CI
For instance,
https://travis-ci.org/python/cpython/jobs/379349709
2 tests failed:
     test_asyncio test_multiprocessing_forkserver
1 test altered the execution environment:
     test_importlib

The failures repeated on retest.  Can someone turn off the bad test methods?

tjr

From mariatta.wijaya at gmail.com  Tue May 15 16:51:24 2018
From: mariatta.wijaya at gmail.com (Mariatta Wijaya)
Date: Tue, 15 May 2018 16:51:24 -0400
Subject: [python-committers] Proposing Mark Shannon to be a core
 developer
In-Reply-To: <CAP7+vJLrKwM61vGGcEKXtCQtDLzRBYubp2g07273F_M2n-=B5A@mail.gmail.com>
References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org>
 <CA+3bQGGU598TkrMqDvsB3Y=xwMP8HOeWZRq1z3pOBgEC0QKKyw@mail.gmail.com>
 <CAP7+vJLrKwM61vGGcEKXtCQtDLzRBYubp2g07273F_M2n-=B5A@mail.gmail.com>
Message-ID: <CAGbohnY-GRjwF0ZKtEZCo8RayLRn92muP4f4ncrFShDCH-UXRw@mail.gmail.com>

Part of the new core dev initiation should be watching this talk, titled
"What is a Python Core Developer?" https://youtu.be/hhj7eb6TrtI

On Tue, May 15, 2018, 11:35 AM Guido van Rossum <guido at python.org> wrote:

> Let's stop the email barrage, Mark is in. Can someone tell Mark what to do?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180515/e2cc7836/attachment.html>

From guido at python.org  Tue May 15 17:01:19 2018
From: guido at python.org (Guido van Rossum)
Date: Tue, 15 May 2018 17:01:19 -0400
Subject: [python-committers] Proposing Mark Shannon to be a core
 developer
In-Reply-To: <CAGbohnY-GRjwF0ZKtEZCo8RayLRn92muP4f4ncrFShDCH-UXRw@mail.gmail.com>
References: <3e76f3af-6991-0561-987e-71b5a36165d4@hastings.org>
 <CA+3bQGGU598TkrMqDvsB3Y=xwMP8HOeWZRq1z3pOBgEC0QKKyw@mail.gmail.com>
 <CAP7+vJLrKwM61vGGcEKXtCQtDLzRBYubp2g07273F_M2n-=B5A@mail.gmail.com>
 <CAGbohnY-GRjwF0ZKtEZCo8RayLRn92muP4f4ncrFShDCH-UXRw@mail.gmail.com>
Message-ID: <CAP7+vJ+uBA=k+5Tx=wVPT+RsjpdbWwHKRYG1VHdBmi+AV9sGUQ@mail.gmail.com>

Thanks Mariatta!

It would also be nice if we gave new committers a task along the lines of
"mentor one woman or other person of diversity through their first
non-trivial PR". (If the new committer is not comfortable actually merging
the PR they can ask a more experienced core dev to do that -- after all new
core devs are supposed to be mentored themselves by a more experienced core
dev.)

Even nicer would be if *every* core dev made a commitment to "sponsor" at
least one person of diversity. I understand not everyone has the time. But
perhaps *some* core devs will volunteer! Increasing the core's diversity is
a very important goal to ensure the future health of Python.

On Tue, May 15, 2018 at 4:51 PM, Mariatta Wijaya <mariatta.wijaya at gmail.com>
wrote:

> Part of the new core dev initiation should be watching this talk, titled
> "What is a Python Core Developer?" https://youtu.be/hhj7eb6TrtI
>
> On Tue, May 15, 2018, 11:35 AM Guido van Rossum <guido at python.org> wrote:
>
>> Let's stop the email barrage, Mark is in. Can someone tell Mark what to
>> do?
>>
>>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180515/5d8802eb/attachment.html>

From vstinner at redhat.com  Wed May 16 02:22:52 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Wed, 16 May 2018 02:22:52 -0400
Subject: [python-committers] AppVeyor and Travis-CI
In-Reply-To: <d8f46785-993e-37ac-9084-0c2d54e7a522@udel.edu>
References: <1093b6a8-1cfd-cab0-6d6c-b0acc4700e11@trueblade.com>
 <CAP1=2W65i1PcynL1SZPjwPeZhxQG+i-WzM4tXuPwOhFP7DzvcA@mail.gmail.com>
 <c9350682-0180-b69b-c548-3e0ddeb6f1d1@trueblade.com>
 <CAP7+vJ+t_tOwtdg6dbh3ZSZrWRX1enFGHx9MsomPn7mVoWx9bQ@mail.gmail.com>
 <d8f46785-993e-37ac-9084-0c2d54e7a522@udel.edu>
Message-ID: <CA+3bQGEf1-rQK=MSCkJ=LuLpxQBC8+J6zhjbpNN0Xs02t8+HbQ@mail.gmail.com>

It seems like the job has been rescheduled. I cannot see the failure
("394 tests OK"). Would you mind to open a bug report?

Do you only see these failures in the 3.6 branch?

Victor

2018-05-15 16:36 GMT-04:00 Terry Reedy <tjreedy at udel.edu>:
> I am getting repeated bogus failures, completely unrelated to a trivial
> patch, more often than not, on Travis-CI
> For instance,
> https://travis-ci.org/python/cpython/jobs/379349709
> 2 tests failed:
>     test_asyncio test_multiprocessing_forkserver
> 1 test altered the execution environment:
>     test_importlib
>
> The failures repeated on retest.  Can someone turn off the bad test methods?
>
> tjr
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/

From vstinner at redhat.com  Wed May 16 02:31:16 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Wed, 16 May 2018 02:31:16 -0400
Subject: [python-committers] AppVeyor and Travis-CI
In-Reply-To: <CA+3bQGEf1-rQK=MSCkJ=LuLpxQBC8+J6zhjbpNN0Xs02t8+HbQ@mail.gmail.com>
References: <1093b6a8-1cfd-cab0-6d6c-b0acc4700e11@trueblade.com>
 <CAP1=2W65i1PcynL1SZPjwPeZhxQG+i-WzM4tXuPwOhFP7DzvcA@mail.gmail.com>
 <c9350682-0180-b69b-c548-3e0ddeb6f1d1@trueblade.com>
 <CAP7+vJ+t_tOwtdg6dbh3ZSZrWRX1enFGHx9MsomPn7mVoWx9bQ@mail.gmail.com>
 <d8f46785-993e-37ac-9084-0c2d54e7a522@udel.edu>
 <CA+3bQGEf1-rQK=MSCkJ=LuLpxQBC8+J6zhjbpNN0Xs02t8+HbQ@mail.gmail.com>
Message-ID: <CA+3bQGEaKdOXvmrtbywuYg4oD8errL+ah4Pov7oCxp9_O9OYOQ@mail.gmail.com>

Oh, maybe I saw them. Are you talking about:

"test_multiprocessing_forkserver: TestIgnoreEINTR.test_ignore() fails
on Travis CI"
https://bugs.python.org/issue33531

"test_asyncio: test_subprocess test_stdin_broken_pipe() failure on Travis CI"
https://bugs.python.org/issue33532

(I just created these two issues.)

Victor

2018-05-16 2:22 GMT-04:00 Victor Stinner <vstinner at redhat.com>:
> It seems like the job has been rescheduled. I cannot see the failure
> ("394 tests OK"). Would you mind to open a bug report?
>
> Do you only see these failures in the 3.6 branch?
>
> Victor
>
> 2018-05-15 16:36 GMT-04:00 Terry Reedy <tjreedy at udel.edu>:
>> I am getting repeated bogus failures, completely unrelated to a trivial
>> patch, more often than not, on Travis-CI
>> For instance,
>> https://travis-ci.org/python/cpython/jobs/379349709
>> 2 tests failed:
>>     test_asyncio test_multiprocessing_forkserver
>> 1 test altered the execution environment:
>>     test_importlib
>>
>> The failures repeated on retest.  Can someone turn off the bad test methods?
>>
>> tjr
>>
>> _______________________________________________
>> python-committers mailing list
>> python-committers at python.org
>> https://mail.python.org/mailman/listinfo/python-committers
>> Code of Conduct: https://www.python.org/psf/codeofconduct/

From tjreedy at udel.edu  Wed May 16 02:42:03 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 16 May 2018 02:42:03 -0400
Subject: [python-committers] AppVeyor and Travis-CI
In-Reply-To: <CA+3bQGEaKdOXvmrtbywuYg4oD8errL+ah4Pov7oCxp9_O9OYOQ@mail.gmail.com>
References: <1093b6a8-1cfd-cab0-6d6c-b0acc4700e11@trueblade.com>
 <CAP1=2W65i1PcynL1SZPjwPeZhxQG+i-WzM4tXuPwOhFP7DzvcA@mail.gmail.com>
 <c9350682-0180-b69b-c548-3e0ddeb6f1d1@trueblade.com>
 <CAP7+vJ+t_tOwtdg6dbh3ZSZrWRX1enFGHx9MsomPn7mVoWx9bQ@mail.gmail.com>
 <d8f46785-993e-37ac-9084-0c2d54e7a522@udel.edu>
 <CA+3bQGEf1-rQK=MSCkJ=LuLpxQBC8+J6zhjbpNN0Xs02t8+HbQ@mail.gmail.com>
 <CA+3bQGEaKdOXvmrtbywuYg4oD8errL+ah4Pov7oCxp9_O9OYOQ@mail.gmail.com>
Message-ID: <05e2e96b-0674-f92d-c8bf-87e19ea2a980@udel.edu>

On 5/16/2018 2:31 AM, Victor Stinner wrote:
> Oh, maybe I saw them. Are you talking about:
> 
> "test_multiprocessing_forkserver: TestIgnoreEINTR.test_ignore() fails
> on Travis CI"
> https://bugs.python.org/issue33531
> 
> "test_asyncio: test_subprocess test_stdin_broken_pipe() failure on Travis CI"
> https://bugs.python.org/issue33532
> 
> (I just created these two issues.)

Those are the two test files that failed, though I believe there were 
more test methods that failed in test_asyncio.

> 2018-05-16 2:22 GMT-04:00 Victor Stinner <vstinner at redhat.com>:
>> It seems like the job has been rescheduled.

I later restarted just the Travis test, so as to not toss the OK 
Appveyor test and have to wait another 4 hours to get it to pass again.

  I cannot see the failure
>> ("394 tests OK"). Would you mind to open a bug report?
>>
>> Do you only see these failures in the 3.6 branch?

No.  However, it happened again on my next 3.6 only patch.  I restarted 
just Travis and it passed.  The failure rate the last 24 hours has been 
about 1/3.

>> 2018-05-15 16:36 GMT-04:00 Terry Reedy <tjreedy at udel.edu>:
>>> I am getting repeated bogus failures, completely unrelated to a trivial
>>> patch, more often than not, on Travis-CI
>>> For instance,
>>> https://travis-ci.org/python/cpython/jobs/379349709
>>> 2 tests failed:
>>>      test_asyncio test_multiprocessing_forkserver
>>> 1 test altered the execution environment:
>>>      test_importlib
>>>
>>> The failures repeated on retest.  Can someone turn off the bad test methods?

From eric at trueblade.com  Wed May 16 07:31:09 2018
From: eric at trueblade.com (Eric V. Smith)
Date: Wed, 16 May 2018 07:31:09 -0400
Subject: [python-committers] AppVeyor and Travis-CI
In-Reply-To: <CAFRnB2WmVN9pHkOx4LU+AzaDXP7-khPPfnJF5-LMFrSMp8dQCg@mail.gmail.com>
References: <1093b6a8-1cfd-cab0-6d6c-b0acc4700e11@trueblade.com>
 <CAP1=2W65i1PcynL1SZPjwPeZhxQG+i-WzM4tXuPwOhFP7DzvcA@mail.gmail.com>
 <c9350682-0180-b69b-c548-3e0ddeb6f1d1@trueblade.com>
 <CAFRnB2WmVN9pHkOx4LU+AzaDXP7-khPPfnJF5-LMFrSMp8dQCg@mail.gmail.com>
Message-ID: <3194174d-68f3-f1ad-b365-e3ec5cc0b8a2@trueblade.com>

That's very helpful, thanks. The issue was that I wasn't logged on to 
Travis. I didn't know that was a thing.

I'll check and see if this info is in the devguide.

Eric


On 5/15/18 12:20 PM, Alex Gaynor wrote:
> FWIW, attached is an image pointing out the re-run button. If you're 
> not seeing those it means either a) you're not logged into Travis, b) 
> somehow it's not picking up your permissions correctly.
>
> Alex
>
> On Tue, May 15, 2018 at 11:36 AM Eric V. Smith <eric at trueblade.com 
> <mailto:eric at trueblade.com>> wrote:
>
>     Thanks. You mean close and re-open the bpo issue?
>
>     In the past I saw a Travis "re-run" button, but now I don't. I
>     expected
>     to see it on the Travis page, but last night I only saw a "More
>     options"
>     menu and no "re-run". The next time something fails I'll look again.
>
>     On 5/15/18 11:23 AM, Brett Cannon wrote:
>     > You can always close and then open an issue to re-trigger CI. As for
>     > Travis specifically, you  should have the proper permissions to
>     forcibly
>     > re-run the builds.
>     >
>     > On Mon, 14 May 2018 at 21:50 Eric V. Smith <eric at trueblade.com
>     <mailto:eric at trueblade.com>
>     > <mailto:eric at trueblade.com <mailto:eric at trueblade.com>>> wrote:
>     >
>     >     I accidentally checked in some test files, and they got
>     backported to
>     >     3.7. I pushed a commit to delete them, and it was committed
>     to master.
>     >
>     >     But in the 3.7 backport, something has gone wrong with
>     AppVeyor and
>     >     Travis-CI.
>     >
>     > https://github.com/python/cpython/pull/6844
>     >
>     >     AppVeyor says "Expected ? Waiting for status to be reported".
>     >     There's no
>     >     obvious way to get it to actually report the status, or to
>     restart.
>     >     There is no "Details" button listed on the PR page.
>     >
>     >     For Travis-CI, Miss Isslington sent me an email that says
>     "Backport
>     >     status check is done, and it's a failure ? ." The Travis-CI
>     log file
>     >     ends with a timeout:
>     >
>     >
>      ======================================================================
>     >     FAIL: test_stdin_broken_pipe
>     >  (test.test_asyncio.test_subprocess.SubprocessSafeWatcherTests)
>     >
>      ----------------------------------------------------------------------
>     >     Traceback (most recent call last):
>     >        File
>     >
>      "/home/travis/build/python/cpython/Lib/test/test_asyncio/test_subprocess.py",
>     >
>     >     line 214, in test_stdin_broken_pipe
>     >          self.loop.run_until_complete, coro)
>     >     AssertionError: (<class 'BrokenPipeError'>, <class
>     >     'ConnectionResetError'>) not raised by run_until_complete
>     >
>      ----------------------------------------------------------------------
>     >
>     >     I'm sure this is all due to the heavy load the systems are
>     under. I
>     >     can't find a way to kick both of these off again. I couldn't
>     find
>     >     anything in the devguide, but if I missed it please let me know.
>     >
>     >     Thanks.
>     >     Eric
>     >     _______________________________________________
>     >     python-committers mailing list
>     > python-committers at python.org
>     <mailto:python-committers at python.org>
>     <mailto:python-committers at python.org
>     <mailto:python-committers at python.org>>
>     > https://mail.python.org/mailman/listinfo/python-committers
>     >     Code of Conduct: https://www.python.org/psf/codeofconduct/
>     >
>     _______________________________________________
>     python-committers mailing list
>     python-committers at python.org <mailto:python-committers at python.org>
>     https://mail.python.org/mailman/listinfo/python-committers
>     Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>
>
> -- 
> "I disapprove of what you say, but I will defend to the death your 
> right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: D1B3 ADC0 E023 8CA6
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180516/9321bbd5/attachment.html>

From alex.gaynor at gmail.com  Tue May 15 12:20:33 2018
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Tue, 15 May 2018 12:20:33 -0400
Subject: [python-committers] AppVeyor and Travis-CI
In-Reply-To: <c9350682-0180-b69b-c548-3e0ddeb6f1d1@trueblade.com>
References: <1093b6a8-1cfd-cab0-6d6c-b0acc4700e11@trueblade.com>
 <CAP1=2W65i1PcynL1SZPjwPeZhxQG+i-WzM4tXuPwOhFP7DzvcA@mail.gmail.com>
 <c9350682-0180-b69b-c548-3e0ddeb6f1d1@trueblade.com>
Message-ID: <CAFRnB2WmVN9pHkOx4LU+AzaDXP7-khPPfnJF5-LMFrSMp8dQCg@mail.gmail.com>

FWIW, attached is an image pointing out the re-run button. If you're not
seeing those it means either a) you're not logged into Travis, b) somehow
it's not picking up your permissions correctly.

Alex

On Tue, May 15, 2018 at 11:36 AM Eric V. Smith <eric at trueblade.com> wrote:

> Thanks. You mean close and re-open the bpo issue?
>
> In the past I saw a Travis "re-run" button, but now I don't. I expected
> to see it on the Travis page, but last night I only saw a "More options"
> menu and no "re-run". The next time something fails I'll look again.
>
> On 5/15/18 11:23 AM, Brett Cannon wrote:
> > You can always close and then open an issue to re-trigger CI. As for
> > Travis specifically, you  should have the proper permissions to forcibly
> > re-run the builds.
> >
> > On Mon, 14 May 2018 at 21:50 Eric V. Smith <eric at trueblade.com
> > <mailto:eric at trueblade.com>> wrote:
> >
> >     I accidentally checked in some test files, and they got backported to
> >     3.7. I pushed a commit to delete them, and it was committed to
> master.
> >
> >     But in the 3.7 backport, something has gone wrong with AppVeyor and
> >     Travis-CI.
> >
> >     https://github.com/python/cpython/pull/6844
> >
> >     AppVeyor says "Expected ? Waiting for status to be reported".
> >     There's no
> >     obvious way to get it to actually report the status, or to restart.
> >     There is no "Details" button listed on the PR page.
> >
> >     For Travis-CI, Miss Isslington sent me an email that says "Backport
> >     status check is done, and it's a failure ? ." The Travis-CI log file
> >     ends with a timeout:
> >
> >
>  ======================================================================
> >     FAIL: test_stdin_broken_pipe
> >     (test.test_asyncio.test_subprocess.SubprocessSafeWatcherTests)
> >
>  ----------------------------------------------------------------------
> >     Traceback (most recent call last):
> >        File
> >
>  "/home/travis/build/python/cpython/Lib/test/test_asyncio/test_subprocess.py",
> >
> >     line 214, in test_stdin_broken_pipe
> >          self.loop.run_until_complete, coro)
> >     AssertionError: (<class 'BrokenPipeError'>, <class
> >     'ConnectionResetError'>) not raised by run_until_complete
> >
>  ----------------------------------------------------------------------
> >
> >     I'm sure this is all due to the heavy load the systems are under. I
> >     can't find a way to kick both of these off again. I couldn't find
> >     anything in the devguide, but if I missed it please let me know.
> >
> >     Thanks.
> >     Eric
> >     _______________________________________________
> >     python-committers mailing list
> >     python-committers at python.org <mailto:python-committers at python.org>
> >     https://mail.python.org/mailman/listinfo/python-committers
> >     Code of Conduct: https://www.python.org/psf/codeofconduct/
> >
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>


-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: D1B3 ADC0 E023 8CA6
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180515/9a635700/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2018-05-15 at 12.19.02 PM.png
Type: image/png
Size: 102955 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180515/9a635700/attachment-0001.png>

From brian at python.org  Wed May 16 09:52:50 2018
From: brian at python.org (Brian Curtin)
Date: Wed, 16 May 2018 09:52:50 -0400
Subject: [python-committers] Mentoring Office Hours - the idea,
 and a question
Message-ID: <CAD+XWwqj+mab63zdctmqmcREmV2jy=tjK2FncbnY21wMSVD8GQ@mail.gmail.com>

Hey all,

At the Language Summit last week, after Mariatta's talk we had a
conversation around diversity and how to grow our contributor base, which
led to someone (Steve Dower?) suggesting we post a sort of "Office Hours"
list. This would be a list of current core developers who are interested in
being available at set time(s) for helping mentor newer contributors in our
community through our process and, if they're interested, mentoring them
through the process of becoming core developers themselves.

This "Office Hours" concept is a type of thing that has worked well
elsewhere, including around the software world, and we have some people
interested in offering said mentorship, so I would like to move on to
getting this list up somewhere so we can start doing it.

With that said, before I go make a PR to the devguide to start iterating on
the implementation, an important question:

As this is both an event similar to an in-person meetup and an event meant
to be a safe space for those getting started, it will explicitly mention
the code of conduct. As such, it needs a person/persons/list to contact
should something arise in this context that needs to be handled. What/who
should that be?
 * Suggestion 1: use the already in-place core-mentorship-owner at python.org,
though I can't tell who's on there.
 * Suggestion 2: Create some new list with a few key people on it.
 * Suggestion 3: List some direct names. Who?

As for implementation, there are some tools out there we could possibly
use, but in the interests of getting something out there I'm just going to
make a table and fill in some common information, starting with my own.
Calendar apps and other integrations can come as we figure them out.

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180516/d05dddac/attachment.html>

From vstinner at redhat.com  Wed May 16 11:31:26 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Wed, 16 May 2018 11:31:26 -0400
Subject: [python-committers] Mentoring Office Hours - the idea,
 and a question
In-Reply-To: <CAD+XWwqj+mab63zdctmqmcREmV2jy=tjK2FncbnY21wMSVD8GQ@mail.gmail.com>
References: <CAD+XWwqj+mab63zdctmqmcREmV2jy=tjK2FncbnY21wMSVD8GQ@mail.gmail.com>
Message-ID: <CA+3bQGEQSJtu+T0q9cy2W3yHfUr6ZkApo_DPo+SJ2tuATJQDsQ@mail.gmail.com>

Hi,

I'm usually available between 10:00 and 16:00 in the French timezone
(currently, it's CEST = UTC+2).

A few months ago, I wrote a tutorial and a list of available core
developers... currently it's just me :-D

   http://cpython-core-tutorial.readthedocs.io/en/latest/getting_help.html

Maybe this list should be moved in the developer guide?

   https://devguide.python.org/help/

I chose to put it in my tutorial, since it's less official, and I was
not sure if I should put myself in the official guide ;-)

--

I also heard the idea of pair-programming using a chat, a video
conference, or something else.

For example, when you work on a bug, do it with a contributor to show
how you work. I never did that before, but I may try ;-)

Victor

2018-05-16 9:52 GMT-04:00 Brian Curtin <brian at python.org>:
> Hey all,
>
> At the Language Summit last week, after Mariatta's talk we had a
> conversation around diversity and how to grow our contributor base, which
> led to someone (Steve Dower?) suggesting we post a sort of "Office Hours"
> list. This would be a list of current core developers who are interested in
> being available at set time(s) for helping mentor newer contributors in our
> community through our process and, if they're interested, mentoring them
> through the process of becoming core developers themselves.
>
> This "Office Hours" concept is a type of thing that has worked well
> elsewhere, including around the software world, and we have some people
> interested in offering said mentorship, so I would like to move on to
> getting this list up somewhere so we can start doing it.
>
> With that said, before I go make a PR to the devguide to start iterating on
> the implementation, an important question:
>
> As this is both an event similar to an in-person meetup and an event meant
> to be a safe space for those getting started, it will explicitly mention the
> code of conduct. As such, it needs a person/persons/list to contact should
> something arise in this context that needs to be handled. What/who should
> that be?
>  * Suggestion 1: use the already in-place core-mentorship-owner at python.org,
> though I can't tell who's on there.
>  * Suggestion 2: Create some new list with a few key people on it.
>  * Suggestion 3: List some direct names. Who?
>
> As for implementation, there are some tools out there we could possibly use,
> but in the interests of getting something out there I'm just going to make a
> table and fill in some common information, starting with my own. Calendar
> apps and other integrations can come as we figure them out.
>
> Brian
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>

From brian at python.org  Wed May 16 11:50:13 2018
From: brian at python.org (Brian Curtin)
Date: Wed, 16 May 2018 11:50:13 -0400
Subject: [python-committers] Mentoring Office Hours - the idea,
 and a question
In-Reply-To: <CA+3bQGEQSJtu+T0q9cy2W3yHfUr6ZkApo_DPo+SJ2tuATJQDsQ@mail.gmail.com>
References: <CAD+XWwqj+mab63zdctmqmcREmV2jy=tjK2FncbnY21wMSVD8GQ@mail.gmail.com>
 <CA+3bQGEQSJtu+T0q9cy2W3yHfUr6ZkApo_DPo+SJ2tuATJQDsQ@mail.gmail.com>
Message-ID: <CAD+XWwpnuAS1yhCVwLYX6d4hO2mLXGd8HcHx7pJ-70G7piuZSg@mail.gmail.com>

Yep, this is something I'm adding directly in the devguide so it's right
where new contributors are already going to be looking for help and
information.

As for how those mentors and mentees actually do the work, to start with I
think it's something that each person should just do what they're
comfortable with and have access to, and then once we have some data to
work off of, maybe then we prescribe some specific ways of doing it. I'm ok
to do video things, but some might not be, so in getting this started I
wanted to just begin with names, days, times, and contact information on an
official website. If someone wants mentorship and they're available when
I'm available, they reach out to me and we find a way to talk.

On Wed, May 16, 2018 at 11:31 AM Victor Stinner <vstinner at redhat.com> wrote:

> Hi,
>
> I'm usually available between 10:00 and 16:00 in the French timezone
> (currently, it's CEST = UTC+2).
>
> A few months ago, I wrote a tutorial and a list of available core
> developers... currently it's just me :-D
>
>    http://cpython-core-tutorial.readthedocs.io/en/latest/getting_help.html
>
> Maybe this list should be moved in the developer guide?
>
>    https://devguide.python.org/help/
>
> I chose to put it in my tutorial, since it's less official, and I was
> not sure if I should put myself in the official guide ;-)
>
> --
>
> I also heard the idea of pair-programming using a chat, a video
> conference, or something else.
>
> For example, when you work on a bug, do it with a contributor to show
> how you work. I never did that before, but I may try ;-)
>
> Victor
>
> 2018-05-16 9:52 GMT-04:00 Brian Curtin <brian at python.org>:
> > Hey all,
> >
> > At the Language Summit last week, after Mariatta's talk we had a
> > conversation around diversity and how to grow our contributor base, which
> > led to someone (Steve Dower?) suggesting we post a sort of "Office Hours"
> > list. This would be a list of current core developers who are interested
> in
> > being available at set time(s) for helping mentor newer contributors in
> our
> > community through our process and, if they're interested, mentoring them
> > through the process of becoming core developers themselves.
> >
> > This "Office Hours" concept is a type of thing that has worked well
> > elsewhere, including around the software world, and we have some people
> > interested in offering said mentorship, so I would like to move on to
> > getting this list up somewhere so we can start doing it.
> >
> > With that said, before I go make a PR to the devguide to start iterating
> on
> > the implementation, an important question:
> >
> > As this is both an event similar to an in-person meetup and an event
> meant
> > to be a safe space for those getting started, it will explicitly mention
> the
> > code of conduct. As such, it needs a person/persons/list to contact
> should
> > something arise in this context that needs to be handled. What/who should
> > that be?
> >  * Suggestion 1: use the already in-place
> core-mentorship-owner at python.org,
> > though I can't tell who's on there.
> >  * Suggestion 2: Create some new list with a few key people on it.
> >  * Suggestion 3: List some direct names. Who?
> >
> > As for implementation, there are some tools out there we could possibly
> use,
> > but in the interests of getting something out there I'm just going to
> make a
> > table and fill in some common information, starting with my own. Calendar
> > apps and other integrations can come as we figure them out.
> >
> > Brian
> >
> > _______________________________________________
> > python-committers mailing list
> > python-committers at python.org
> > https://mail.python.org/mailman/listinfo/python-committers
> > Code of Conduct: https://www.python.org/psf/codeofconduct/
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180516/ffbc236f/attachment.html>

From tjreedy at udel.edu  Wed May 16 12:22:27 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 16 May 2018 12:22:27 -0400
Subject: [python-committers] AppVeyor and Travis-CI
In-Reply-To: <CAFRnB2WmVN9pHkOx4LU+AzaDXP7-khPPfnJF5-LMFrSMp8dQCg@mail.gmail.com>
References: <1093b6a8-1cfd-cab0-6d6c-b0acc4700e11@trueblade.com>
 <CAP1=2W65i1PcynL1SZPjwPeZhxQG+i-WzM4tXuPwOhFP7DzvcA@mail.gmail.com>
 <c9350682-0180-b69b-c548-3e0ddeb6f1d1@trueblade.com>
 <CAFRnB2WmVN9pHkOx4LU+AzaDXP7-khPPfnJF5-LMFrSMp8dQCg@mail.gmail.com>
Message-ID: <2a5f268a-9d72-cd90-9a08-3a934654c2e2@udel.edu>

On 5/15/2018 12:20 PM, Alex Gaynor wrote:
> FWIW, attached is an image pointing out the re-run button. If you're not 
> seeing those it means either a) you're not logged into Travis, b) 
> somehow it's not picking up your permissions correctly.

Is there anything in the devguide about this?  The first time I tried to 
use a rebuild button, there was some sort of login/registration 
procedure.  Since then, it just works when I am logged in to github.

Thank you for the image.  I did not know that the unlabeled symbols at 
the end of each line for the three sub-builds was a rerun button for the 
one sub-build.  Good to know to only re-run what is needed.

TJR



From vstinner at redhat.com  Wed May 16 18:08:36 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Wed, 16 May 2018 18:08:36 -0400
Subject: [python-committers] Mentoring Office Hours - the idea,
 and a question
In-Reply-To: <CA+3bQGEQSJtu+T0q9cy2W3yHfUr6ZkApo_DPo+SJ2tuATJQDsQ@mail.gmail.com>
References: <CAD+XWwqj+mab63zdctmqmcREmV2jy=tjK2FncbnY21wMSVD8GQ@mail.gmail.com>
 <CA+3bQGEQSJtu+T0q9cy2W3yHfUr6ZkApo_DPo+SJ2tuATJQDsQ@mail.gmail.com>
Message-ID: <CA+3bQGGxKFTdharHKzp1Jgx9UgWzB6LvSvnVuXf0QnwB+eXLVw@mail.gmail.com>

2018-05-16 11:31 GMT-04:00 Victor Stinner <vstinner at redhat.com>:
> I'm usually available between 10:00 and 16:00 in the French timezone
> (currently, it's CEST = UTC+2).

Oh, let me be more specific:

10:00-12:00 and 14:00-16:00, Monday to Friday

Yeah, in France we take our time to eat ;-)

Victor

From steve.dower at python.org  Wed May 16 18:09:29 2018
From: steve.dower at python.org (Steve Dower)
Date: Wed, 16 May 2018 18:09:29 -0400
Subject: [python-committers] Visual Studio Team Services checks on pull
 requests
Message-ID: <43046f2f-64e3-2625-cc6f-07df7c53e4b9@python.org>

Hi all

Just a quick note right now - don't have time for all the details.

I'm experimenting with using Visual Studio Team Services to do builds of
CPython. Right now, you'll probably see failed builds on all PRs while I
get security options figured out.

These *will not* block your PR, so feel free to ignore them. Apologies
for the noise in the meantime.

Cheers,
STeve

From steve.dower at python.org  Wed May 16 18:27:26 2018
From: steve.dower at python.org (Steve Dower)
Date: Wed, 16 May 2018 18:27:26 -0400
Subject: [python-committers] Visual Studio Team Services checks on
 pullrequests
In-Reply-To: <43046f2f-64e3-2625-cc6f-07df7c53e4b9@python.org>
References: <43046f2f-64e3-2625-cc6f-07df7c53e4b9@python.org>
Message-ID: <mailman.99.1526509656.2757.python-committers@python.org>

And a quick follow up ? the builds should be running successfully now. Still some write up to do for everyone (tomorrow's job at the sprints), but you should be able to click through already and see the logs.

Thanks Microsoft for the 20 concurrent builds on Windows, macOS and Linux :)

Top-posted from my Windows phone

From: Steve Dower
Sent: Wednesday, May 16, 2018 18:10
To: python-committers at python.org
Subject: [python-committers] Visual Studio Team Services checks on pullrequests

Hi all

Just a quick note right now - don't have time for all the details.

I'm experimenting with using Visual Studio Team Services to do builds of
CPython. Right now, you'll probably see failed builds on all PRs while I
get security options figured out.

These *will not* block your PR, so feel free to ignore them. Apologies
for the noise in the meantime.

Cheers,
STeve
_______________________________________________
python-committers mailing list
python-committers at python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180516/968ead80/attachment.html>

From benjamin at python.org  Thu May 17 01:46:51 2018
From: benjamin at python.org (Benjamin Peterson)
Date: Wed, 16 May 2018 22:46:51 -0700
Subject: [python-committers] Visual Studio Team Services checks on
 pullrequests
In-Reply-To: <40mTb25PHvzFqyH@mail.python.org>
References: <43046f2f-64e3-2625-cc6f-07df7c53e4b9@python.org>
 <40mTb25PHvzFqyH@mail.python.org>
Message-ID: <1526536011.1063117.1375126352.51A2DC99@webmail.messagingengine.com>



On Wed, May 16, 2018, at 15:27, Steve Dower wrote:
> Thanks Microsoft for the 20 concurrent builds on Windows, macOS and Linux :)

That is quite generous! Will it be ongoing?

From brett at python.org  Thu May 17 09:35:26 2018
From: brett at python.org (Brett Cannon)
Date: Thu, 17 May 2018 09:35:26 -0400
Subject: [python-committers] Visual Studio Team Services checks on
 pullrequests
In-Reply-To: <1526536011.1063117.1375126352.51A2DC99@webmail.messagingengine.com>
References: <43046f2f-64e3-2625-cc6f-07df7c53e4b9@python.org>
 <40mTb25PHvzFqyH@mail.python.org>
 <1526536011.1063117.1375126352.51A2DC99@webmail.messagingengine.com>
Message-ID: <CAP1=2W7L4W9Q_Dy4vCSLfu+MrZK4J2NppSv5ibwLvTzOHnCw5Q@mail.gmail.com>

On Thu, 17 May 2018 at 01:47 Benjamin Peterson <benjamin at python.org> wrote:

>
>
> On Wed, May 16, 2018, at 15:27, Steve Dower wrote:
> > Thanks Microsoft for the 20 concurrent builds on Windows, macOS and
> Linux :)
>
> That is quite generous! Will it be ongoing?
>

Yes, this is not just for the sprints. This is a continual contribution so
this level of performance will be year-round. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180517/a3dfec49/attachment.html>

From steve.dower at python.org  Thu May 17 10:07:44 2018
From: steve.dower at python.org (Steve Dower)
Date: Thu, 17 May 2018 10:07:44 -0400
Subject: [python-committers] Visual Studio Team Services checks on
 pullrequests
In-Reply-To: <40mTb03mwLzFqyW@mail.python.org>
References: <43046f2f-64e3-2625-cc6f-07df7c53e4b9@python.org>
 <40mTb03mwLzFqyW@mail.python.org>
Message-ID: <e83848f4-12a7-34e0-3b79-4328a6d86f71@python.org>

Okay, now that it's morning and I have coffee, here's a full update on
what I've been doing (those at the language summit have heard some of
this already).

Visual Studio Team Services is Microsoft's integrated code/build/release
infrastructure service. The official marketing page is
https://www.visualstudio.com/team-services/ but you can think of it as
github code+github issues+Travis but engineered for huge teams (i.e.
Microsoft keeps all of Windows in git, all the millions of issues they
have, and all the builds they do, are in VSTS and it scales to thousands
of developers just fine).

I've been working with the team to improve their Python support and
generally raise awareness of the new service, and one of the things they
agreed to is to provide a free set of build machines for CPython. These
allow us to run up to 20 simultaneous Windows, macOS and Linux builds
with no other limits.

My main project at the PyCon US sprints has been setting these builds
up. As of about 16 hours ago the PR builds are now hooked up to github
(for an example, see https://github.com/python/cpython/pull/6933). They
are not required to merge, so don't feel the need to block PRs if
everything else passes, but we'd like to fix up the issues they are
hitting. As far as I can tell, most of the problems are transient test
failures that ought to be fixed anyway.

Brief interruption for some links:
* https://python.visualstudio.com/cpython/_build/index?_a=queued (queued
and recently completed builds)
* https://github.com/python/cpython/tree/master/.vsts (build definitions)
* https://github.com/python/cpython/pull/6933 (sample PR with build status)

Authentication for python.visualstudio.com is currently manually
managed, but everything relevant under
https://python.visualstudio.com/cpython is visible without
authentication (this is a new VSTS feature that we got enabled early).
Right now I don't want to add lots of people manually, and we'll be
looking at how to make this simpler in the future. There isn't much you
can do while logged in anyway :)

There are some missing features. I'm still in contact with the team and
I'll be passing along requests, so feel free to let me know if you need
anything. Currently I'm aware of:
* no way to requeue a PR build (whether logged in or not)
* no link from a build to the github PR page
* templated build steps aren't enabled yet (see linux-deps.yml if you're
interested)

We don't yet have a specific timeline for making VSTS builds required
and reducing Travis/AppVeyor usage. I also haven't set up VSTS for
Python 2.7, and honestly I'm fine with keeping the existing systems
there. As a slight aside, we're also working with some other projects to
provide similar setups (specifically Twisted and some PyPA-associated
projects), so if you think you'd benefit from this on one of your other
projects let me know and we can see what's available.

Also, if you start evaluating/using VSTS for other projects because of
this, *please* let me know. New users is what the VSTS team is trying to
achieve, so every time I can send back positive reports it helps
convince them to keep donating build time.

Feel free to email me with any questions or feedback, either on or off-list.

Cheers,
Steve


From antoine at python.org  Thu May 17 10:14:55 2018
From: antoine at python.org (Antoine Pitrou)
Date: Thu, 17 May 2018 16:14:55 +0200
Subject: [python-committers] Visual Studio Team Services checks on
 pullrequests
In-Reply-To: <e83848f4-12a7-34e0-3b79-4328a6d86f71@python.org>
References: <43046f2f-64e3-2625-cc6f-07df7c53e4b9@python.org>
 <40mTb03mwLzFqyW@mail.python.org>
 <e83848f4-12a7-34e0-3b79-4328a6d86f71@python.org>
Message-ID: <5b6fe721-e3c8-831c-e306-d44c382375a2@python.org>


Le 17/05/2018 ? 16:07, Steve Dower a ?crit?:
> Okay, now that it's morning and I have coffee, here's a full update on
> what I've been doing (those at the language summit have heard some of
> this already).
> 
> Visual Studio Team Services is Microsoft's integrated code/build/release
> infrastructure service. The official marketing page is
> https://www.visualstudio.com/team-services/ but you can think of it as
> github code+github issues+Travis but engineered for huge teams (i.e.
> Microsoft keeps all of Windows in git, all the millions of issues they
> have, and all the builds they do, are in VSTS and it scales to thousands
> of developers just fine).
> 
> I've been working with the team to improve their Python support and
> generally raise awareness of the new service, and one of the things they
> agreed to is to provide a free set of build machines for CPython. These
> allow us to run up to 20 simultaneous Windows, macOS and Linux builds
> with no other limits.

That sounds cool.  Which builds are you looking to migrate to VSTS?
macOS sounds like a no-brainer as the Travis-CI macOS infrastructure is
known to be very lacking (though it has been a bit better lately).
Windows may be reasonable since AppVeyor doesn't provide any parallelism
AFAIK.  As for Linux, I think it may be better to keep some of our CI on
Travis (if only not to depend entirely on a donated service).

Also a concern: currently the Travis-CI and AppVeyor configurations also
work, transparently, on user's forks as long as they activated those
(free) services on their fork.  What about VSTS, though?  If CPython
were to migrate all of its CI to VSTS, would I still get CI on my
CPython fork?

Regards

Antoine.

From steve.dower at python.org  Thu May 17 10:46:57 2018
From: steve.dower at python.org (Steve Dower)
Date: Thu, 17 May 2018 10:46:57 -0400
Subject: [python-committers] Visual Studio Team Services checks on
 pullrequests
In-Reply-To: <5b6fe721-e3c8-831c-e306-d44c382375a2@python.org>
References: <43046f2f-64e3-2625-cc6f-07df7c53e4b9@python.org>
 <40mTb03mwLzFqyW@mail.python.org>
 <e83848f4-12a7-34e0-3b79-4328a6d86f71@python.org>
 <5b6fe721-e3c8-831c-e306-d44c382375a2@python.org>
Message-ID: <cebdb166-51d8-95eb-b669-c972ac67d723@python.org>

On 17May2018 1014, Antoine Pitrou wrote:
> That sounds cool.  Which builds are you looking to migrate to VSTS?
> macOS sounds like a no-brainer as the Travis-CI macOS infrastructure is
> known to be very lacking (though it has been a bit better lately).
> Windows may be reasonable since AppVeyor doesn't provide any parallelism
> AFAIK.  As for Linux, I think it may be better to keep some of our CI on
> Travis (if only not to depend entirely on a donated service).

That sounds fine. It'll be decided on core-workflow, but I tried to
enable everything (except the 2.7 branch :) )

> Also a concern: currently the Travis-CI and AppVeyor configurations also
> work, transparently, on user's forks as long as they activated those
> (free) services on their fork.  What about VSTS, though?  If CPython
> were to migrate all of its CI to VSTS, would I still get CI on my
> CPython fork?

I've enabled as much as I have options for (including clicking through
the security warnings), so if it's still lacking in certain areas then
I'll pass that feedback along. It definitely runs against PRs sent from
forks, but I don't think it'll run against pushes to your own fork
unless you sign up for your own (free) instance. The YAML files should
work fine though, but they won't automatically create themselves.

Cheers,
Steve


From tjreedy at udel.edu  Thu May 17 10:59:32 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 17 May 2018 10:59:32 -0400
Subject: [python-committers] Visual Studio Team Services checks on
 pullrequests
In-Reply-To: <e83848f4-12a7-34e0-3b79-4328a6d86f71@python.org>
References: <43046f2f-64e3-2625-cc6f-07df7c53e4b9@python.org>
 <40mTb03mwLzFqyW@mail.python.org>
 <e83848f4-12a7-34e0-3b79-4328a6d86f71@python.org>
Message-ID: <e78e7983-5bc8-77a8-48c7-187837090776@udel.edu>

On 5/17/2018 10:07 AM, Steve Dower wrote:

> Feel free to email me with any questions or feedback, either on or off-list.

When a test fails and verbose test by test output is displayed, it would 
be really nice if error lines, or at least 'ERROR' were highlighted more 
somehow.  Either in red (hard with plain text, I guess) or ***ERROR***, 
for instance.  In the example, test_asyncio failed (this is a know 
intermittent problem) and includes lines like

test_sock_sendfile_fallback 
(test.test_asyncio.test_base_events.BaseLoopSockSendfileTests) ... ERROR

with no traceback.  It is hard to be sure that one has seen all such lines.

tjr

From storchaka at gmail.com  Thu May 17 14:31:37 2018
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Thu, 17 May 2018 21:31:37 +0300
Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
In-Reply-To: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
Message-ID: <468a581b-2aa2-7fea-7a51-cd566f5c5a68@gmail.com>

15.05.18 14:51, Ned Deily ????:
> This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your
> feature fixes, bug fixes, and documentation updates in before
> 2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days
> from now. We will then tag and produce the 3.7.0 release candidate.
> Our goal continues been to be to have no changes between the release
> candidate and final; AFTER NEXT WEEK'S RC1, CHANGES APPLIED TO THE 3.7
> BRANCH WILL BE RELEASED IN 3.7.1. Please double-check that there are
> no critical problems outstanding and that documentation for new
> features in 3.7 is complete (including NEWS and What's New items), and
> that 3.7 is getting exposure and tested with our various platorms and
> third-party distributions and applications. Those of us who are
> participating in the development sprints at PyCon US 2018 here in
> Cleveland can feel the excitement building as we work through the
> remaining issues, including completing the "What's New in 3.7"
> document and final feature documentation. (We wish you could all be
> here.)

The "What's New in 3.7" document is still not complete. Actually it is 
far completing. In the previous releases somebody made a thoughtful 
review of the NEWS file and added all significant changes in What's New, 
and also removed insignificant entries, reorganized entries, fixed 
errors, improved wording and formatting. Many thanks to Martin Panter, 
Elvis Pranskevichus, Yury Selivanov, R. David Murray, Nick Coghlan, 
Antoine Pitrou, Victor Stinner and others for their great work! But 
seems in 3.7 this documents doesn't have an editor.


From nad at python.org  Thu May 17 14:39:35 2018
From: nad at python.org (Ned Deily)
Date: Thu, 17 May 2018 14:39:35 -0400
Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
In-Reply-To: <468a581b-2aa2-7fea-7a51-cd566f5c5a68@gmail.com>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
 <468a581b-2aa2-7fea-7a51-cd566f5c5a68@gmail.com>
Message-ID: <5B1F42D3-5BAD-47C5-8276-0CE4203834AD@python.org>

Elvis has been working on the What?s New doc at the sprints this week. He should be checking in his edits soon.  Stay tuned!

  --
    Ned Deily
    nad at python.org -- []



> On May 17, 2018, at 14:31, Serhiy Storchaka <storchaka at gmail.com> wrote:
> 
> 15.05.18 14:51, Ned Deily ????:
>> This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your
>> feature fixes, bug fixes, and documentation updates in before
>> 2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days
>> from now. We will then tag and produce the 3.7.0 release candidate.
>> Our goal continues been to be to have no changes between the release
>> candidate and final; AFTER NEXT WEEK'S RC1, CHANGES APPLIED TO THE 3.7
>> BRANCH WILL BE RELEASED IN 3.7.1. Please double-check that there are
>> no critical problems outstanding and that documentation for new
>> features in 3.7 is complete (including NEWS and What's New items), and
>> that 3.7 is getting exposure and tested with our various platorms and
>> third-party distributions and applications. Those of us who are
>> participating in the development sprints at PyCon US 2018 here in
>> Cleveland can feel the excitement building as we work through the
>> remaining issues, including completing the "What's New in 3.7"
>> document and final feature documentation. (We wish you could all be
>> here.)
> 
> The "What's New in 3.7" document is still not complete. Actually it is far completing. In the previous releases somebody made a thoughtful review of the NEWS file and added all significant changes in What's New, and also removed insignificant entries, reorganized entries, fixed errors, improved wording and formatting. Many thanks to Martin Panter, Elvis Pranskevichus, Yury Selivanov, R. David Murray, Nick Coghlan, Antoine Pitrou, Victor Stinner and others for their great work! But seems in 3.7 this documents doesn't have an editor.
> 


From storchaka at gmail.com  Thu May 17 15:14:11 2018
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Thu, 17 May 2018 22:14:11 +0300
Subject: [python-committers] [Python-Dev] FINAL WEEK FOR 3.7.0 CHANGES!
In-Reply-To: <15747132.OTsdByEcpE@hammer.magicstack.net>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
 <468a581b-2aa2-7fea-7a51-cd566f5c5a68@gmail.com>
 <15747132.OTsdByEcpE@hammer.magicstack.net>
Message-ID: <6b2cbd3c-1db7-5ef4-da18-33d19c765229@gmail.com>

17.05.18 21:43, Elvis Pranskevichus ????:

> I'm working on the What's New document.  Will start putting PRs in the
> next few days.

Great!


From brett at python.org  Thu May 17 14:39:14 2018
From: brett at python.org (Brett Cannon)
Date: Thu, 17 May 2018 14:39:14 -0400
Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
In-Reply-To: <468a581b-2aa2-7fea-7a51-cd566f5c5a68@gmail.com>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
 <468a581b-2aa2-7fea-7a51-cd566f5c5a68@gmail.com>
Message-ID: <CAP1=2W7+YkTyUF9Ypye7w7iJq8n+iSgUi6VSn-jDy3xs_tg3uw@mail.gmail.com>

On Thu, 17 May 2018 at 14:31 Serhiy Storchaka <storchaka at gmail.com> wrote:

> 15.05.18 14:51, Ned Deily ????:
> > This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your
> > feature fixes, bug fixes, and documentation updates in before
> > 2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days
> > from now. We will then tag and produce the 3.7.0 release candidate.
> > Our goal continues been to be to have no changes between the release
> > candidate and final; AFTER NEXT WEEK'S RC1, CHANGES APPLIED TO THE 3.7
> > BRANCH WILL BE RELEASED IN 3.7.1. Please double-check that there are
> > no critical problems outstanding and that documentation for new
> > features in 3.7 is complete (including NEWS and What's New items), and
> > that 3.7 is getting exposure and tested with our various platorms and
> > third-party distributions and applications. Those of us who are
> > participating in the development sprints at PyCon US 2018 here in
> > Cleveland can feel the excitement building as we work through the
> > remaining issues, including completing the "What's New in 3.7"
> > document and final feature documentation. (We wish you could all be
> > here.)
>
> The "What's New in 3.7" document is still not complete. Actually it is
> far completing. In the previous releases somebody made a thoughtful
> review of the NEWS file and added all significant changes in What's New,
> and also removed insignificant entries, reorganized entries, fixed
> errors, improved wording and formatting. Many thanks to Martin Panter,
> Elvis Pranskevichus, Yury Selivanov, R. David Murray, Nick Coghlan,
> Antoine Pitrou, Victor Stinner and others for their great work! But
> seems in 3.7 this documents doesn't have an editor.
>

Maybe we should start thinking about flagging PRs or issues as needing a
What's New entry to help track when they need one, or always expect it in a
PR and ignore that requirement when a 'skip whats new' label is applied.
That would at least make it easier to keep track of what needs to be done.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180517/3bd3598f/attachment.html>

From tjreedy at udel.edu  Thu May 17 20:27:32 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 17 May 2018 20:27:32 -0400
Subject: [python-committers] Visual Studio Team Services checks on
 pullrequests
In-Reply-To: <cebdb166-51d8-95eb-b669-c972ac67d723@python.org>
References: <43046f2f-64e3-2625-cc6f-07df7c53e4b9@python.org>
 <40mTb03mwLzFqyW@mail.python.org>
 <e83848f4-12a7-34e0-3b79-4328a6d86f71@python.org>
 <5b6fe721-e3c8-831c-e306-d44c382375a2@python.org>
 <cebdb166-51d8-95eb-b669-c972ac67d723@python.org>
Message-ID: <4b20f58b-6a42-8069-2522-6f0e7a8b8649@udel.edu>

Can VSTS run GUI tests on any of the systems?  Right now, only Appveyor 
and one or two of the Windows buildbots do so.

From njs at pobox.com  Thu May 17 20:31:32 2018
From: njs at pobox.com (Nathaniel Smith)
Date: Thu, 17 May 2018 17:31:32 -0700
Subject: [python-committers] Visual Studio Team Services checks on
 pullrequests
In-Reply-To: <4b20f58b-6a42-8069-2522-6f0e7a8b8649@udel.edu>
References: <43046f2f-64e3-2625-cc6f-07df7c53e4b9@python.org>
 <40mTb03mwLzFqyW@mail.python.org>
 <e83848f4-12a7-34e0-3b79-4328a6d86f71@python.org>
 <5b6fe721-e3c8-831c-e306-d44c382375a2@python.org>
 <cebdb166-51d8-95eb-b669-c972ac67d723@python.org>
 <4b20f58b-6a42-8069-2522-6f0e7a8b8649@udel.edu>
Message-ID: <CAPJVwB=S2dw_Hx6bGdqU0wcg1srs53SkAz3yg5BYuNh=DBphqw@mail.gmail.com>

On Thu, May 17, 2018 at 5:27 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> Can VSTS run GUI tests on any of the systems?  Right now, only Appveyor and
> one or two of the Windows buildbots do so.

It's certainly possible to use Xvfb to run headless GUI tests on Linux
(or other Unixes that use X11). Any CI service should be able to
handle this, e.g.:
https://docs.travis-ci.com/user/gui-and-headless-browsers/#Using-xvfb-to-Run-Tests-That-Require-a-GUI

-n

-- 
Nathaniel J. Smith -- https://vorpus.org

From tjreedy at udel.edu  Thu May 17 21:09:18 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 17 May 2018 21:09:18 -0400
Subject: [python-committers] Can I just rerun a test on AppVeyor?
Message-ID: <e5d2b25e-4e82-9f9a-4a30-9b809e78e5e2@udel.edu>

I can restart a test on just Travis when AppVeyor (and now MSTS) all 
passed.  But for the last few hours, test_async has failed 1/4 to 1/3 of 
the runs.  This means that test_async failed twice, so I suspect that it 
actually fails about half the time.  A connection error seems to be the 
main culprit.

I could not find a rebuild button on the AppVeyor page, even after 
connecting my github account with AppVeyor.  I ended up closing and 
reopening, but this wastes resources on Travis and now MSTS.

On the rerun, it failed the first time and then passed on the rerun


From zachary.ware+pydev at gmail.com  Thu May 17 22:36:27 2018
From: zachary.ware+pydev at gmail.com (Zachary Ware)
Date: Thu, 17 May 2018 21:36:27 -0500
Subject: [python-committers] Can I just rerun a test on AppVeyor?
In-Reply-To: <e5d2b25e-4e82-9f9a-4a30-9b809e78e5e2@udel.edu>
References: <e5d2b25e-4e82-9f9a-4a30-9b809e78e5e2@udel.edu>
Message-ID: <CAKJDb-N5MOmuafRFZjk8caWMSUShwZQDo6wMaru05uuCt8B6SQ@mail.gmail.com>

On Thu, May 17, 2018 at 8:09 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> I can restart a test on just Travis when AppVeyor (and now MSTS) all passed.
> But for the last few hours, test_async has failed 1/4 to 1/3 of the runs.
> This means that test_async failed twice, so I suspect that it actually fails
> about half the time.  A connection error seems to be the main culprit.
>
> I could not find a rebuild button on the AppVeyor page, even after
> connecting my github account with AppVeyor.  I ended up closing and
> reopening, but this wastes resources on Travis and now MSTS.
>
> On the rerun, it failed the first time and then passed on the rerun

It is unfortunately non-obvious that you have to choose "python"
rather than your own GitHub username after clicking the "login via
GitHub" button, but after logging in that way you should have a
"Re-build PR" button at the top of the page of any PR build.

I'm not certain that permissions were set correctly before, but they
definitely should be now.

-- 
Zach

From tjreedy at udel.edu  Thu May 17 22:44:48 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 17 May 2018 22:44:48 -0400
Subject: [python-committers] Can I just rerun a test on AppVeyor?
In-Reply-To: <CAKJDb-N5MOmuafRFZjk8caWMSUShwZQDo6wMaru05uuCt8B6SQ@mail.gmail.com>
References: <e5d2b25e-4e82-9f9a-4a30-9b809e78e5e2@udel.edu>
 <CAKJDb-N5MOmuafRFZjk8caWMSUShwZQDo6wMaru05uuCt8B6SQ@mail.gmail.com>
Message-ID: <93c6b433-2f89-1970-91e2-a3be5d9a248f@udel.edu>

On 5/17/2018 10:36 PM, Zachary Ware wrote:
> On Thu, May 17, 2018 at 8:09 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>> I can restart a test on just Travis when AppVeyor (and now MSTS) all passed.
>> But for the last few hours, test_async has failed 1/4 to 1/3 of the runs.
>> This means that test_async failed twice, so I suspect that it actually fails
>> about half the time.  A connection error seems to be the main culprit.
>>
>> I could not find a rebuild button on the AppVeyor page, even after
>> connecting my github account with AppVeyor.  I ended up closing and
>> reopening, but this wastes resources on Travis and now MSTS.
>>
>> On the rerun, it failed the first time and then passed on the rerun
> 
> It is unfortunately non-obvious that you have to choose "python"
> rather than your own GitHub username after clicking the "login via
> GitHub" button,

You're right.  I choose my name.  0-(.
In retrospect, it makes sense since the job is being done on the python 
account, not mine.

> but after logging in that way you should have a
> "Re-build PR" button at the top of the page of any PR build.
> 
> I'm not certain that permissions were set correctly before, but they
> definitely should be now.

Thanks.


From greg at krypto.org  Fri May 18 00:25:13 2018
From: greg at krypto.org (Gregory P. Smith)
Date: Thu, 17 May 2018 21:25:13 -0700
Subject: [python-committers] Bring back Travis & AppVeyor,
 make VSTS non-blocking
Message-ID: <CAGE7PNL3Ksup2gSQF=TNfsGrXLv6tRkaD72zDBsW6DbZBxNmCQ@mail.gmail.com>

VSTS is clearly not yet a stable continuous integration platform.  It needs
to be made non-blocking, and AppVeyor and Travis need to be brought back!

Examples:
 https://github.com/python/cpython/pull/6938#issuecomment-389908094
   Windows broke -
https://python.visualstudio.com/cpython/_build?buildId=522
 https://github.com/python/cpython/pull/6939
   Linux broke - https://python.visualstudio.com/cpython/_build?buildId=523

This was on a documentation-only change.

We cannot be changing to new PR-merge-blocking continuous integration
services at this point during a release cycle.  This is preventing changes
from making it in.

-gps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180517/5877d34c/attachment.html>

From storchaka at gmail.com  Fri May 18 03:55:14 2018
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Fri, 18 May 2018 10:55:14 +0300
Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
In-Reply-To: <CAP1=2W7+YkTyUF9Ypye7w7iJq8n+iSgUi6VSn-jDy3xs_tg3uw@mail.gmail.com>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
 <468a581b-2aa2-7fea-7a51-cd566f5c5a68@gmail.com>
 <CAP1=2W7+YkTyUF9Ypye7w7iJq8n+iSgUi6VSn-jDy3xs_tg3uw@mail.gmail.com>
Message-ID: <9a0fdca2-b9a7-aa7d-4007-e30e677940be@gmail.com>

17.05.18 21:39, Brett Cannon ????:
> Maybe we should start thinking about flagging PRs or issues as needing 
> a What's New entry to help track when they need one, or always expect 
> it in a PR and ignore that requirement when a 'skip whats new' label 
> is applied. That would at least make it easier to keep track of what 
> needs to be done.

The requirement of flagging PRs or issues as needing a What's New entry 
doesn't differ in principle from the requirement of creating a What's 
New entry for these changes. The latter is good, and I'm trying always 
create a What's New entry for significant enhancement or potentially 
breaking change. And even I sometimes is unsure and don't document some 
important changes (like in issue30399). Needed a look of yet one pair of 
eyes.

As for requiring a What's New entry by default and introducing a 'skip 
whats new' label, I suppose this will add much nuisance. Most PRs 
(except docs and tests changes) need a news entry, but most PRs don't 
need a What's New entry because their are bug fixes. Therefore a 'skip 
whats new' label will be required much more times than 'skip news' or 
'skip issue' labels.

A thing that can help is a tool that makes a structural diff between 
NEWS files for different versions and between different branches. It 
will filter out bugfix changes. The simple 'diff' is not well 
appropriate because entries can be in different order, and news entries 
now are scattered between several files, and news entries for previous 
version sometimes should be searched in different files, and sometimes 
should be searched on a different branch. The text of entries in 
different versions can also be different because the same issue can 
change the behavior on the master and backport the part of changes as a 
bugfix.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180518/97b4b00a/attachment-0001.html>

From tjreedy at udel.edu  Fri May 18 12:41:21 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 18 May 2018 12:41:21 -0400
Subject: [python-committers] Bring back Travis & AppVeyor,
 make VSTS non-blocking
In-Reply-To: <CAGE7PNL3Ksup2gSQF=TNfsGrXLv6tRkaD72zDBsW6DbZBxNmCQ@mail.gmail.com>
References: <CAGE7PNL3Ksup2gSQF=TNfsGrXLv6tRkaD72zDBsW6DbZBxNmCQ@mail.gmail.com>
Message-ID: <93977d72-9972-03d3-d59e-791d63a7320f@udel.edu>

On 5/18/2018 12:25 AM, Gregory P. Smith wrote:
> VSTS is clearly not yet a stable continuous integration platform.? It 
> needs to be made non-blocking, and AppVeyor and Travis need to be 
> brought back!
> 
> Examples:
> https://github.com/python/cpython/pull/6938#issuecomment-389908094
>  ? ?Windows broke - 
> https://python.visualstudio.com/cpython/_build?buildId=522
> https://github.com/python/cpython/pull/6939
>  ? ?Linux broke - https://python.visualstudio.com/cpython/_build?buildId=523

Travis and AppVeyor are there on both issues, and both can be merged -- 
manually -- by pressing 'Squach and merge', even though not green.  The 
VSTS results are not blocking -- they are not marked as 'Required'.  The 
problem is that miss-islington was not changed, and sees any VSTS 
failure as a status check failure and a reason to not do the automerge 
you requested by approving the change.

> This was on a documentation-only change.
> 
> We cannot be changing to new PR-merge-blocking continuous integration 
> services at this point during a release cycle.? This is preventing 
> changes from making it in.

What *is* blocking merges and making them painful at times are the 
haphazard failures of test_asyncio on the blocking bots, Travis and 
AppVeyor, at a rate as high as 1/4 of individual test runs.  See
https://bugs.python.org/issue33531
On one backport last night, I had to run Travis 4 times, which means I 
had to periodically monitor the backport instead of approve and forget. 
And then I had to manually merge.

tjr



From guido at python.org  Fri May 18 18:25:37 2018
From: guido at python.org (Guido van Rossum)
Date: Fri, 18 May 2018 15:25:37 -0700
Subject: [python-committers] A different way to focus discussions
Message-ID: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>

Discussing PEPs on python-dev and python-ideas is clearly not scalable any
more. (Even python-committers probably doesn't scale too well. :-)

I wonder if it would make sense to require that for each PEP a new GitHub
*repo* be created whose contents would just be a draft PEP and whose issue
tracker and PR manager would be used to debate the PEP and propose specific
changes.

This way the discussion is still public: when the PEP-specific repo is
created the author(s) can notify python-ideas, and when they are closer to
submitting they can notify python-dev, but the discussion doesn't attract
uninformed outsiders as much as python-{dev,ideas} discussions do, and it's
much easier for outsiders who want to learn more about the proposal to find
all relevant discussion.

PEP authors may also choose to use a different repo hosting site, e.g.
Bitbucket or GitLab. We can provide a script that allows checking the
formatting of the PEP easily (basically pep2html.py from the peps repo).

Using a separate repo per PEP has the advantage that people interested in a
topic can subscribe to all traffic in that repo -- if we were to use the
tracker of the peps repo you would have to subscribe to all peps traffic.

Thoughts? (We can dogfood this proposal too, if there's interest. :-)

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180518/f6a2a63a/attachment.html>

From levkivskyi at gmail.com  Fri May 18 18:58:32 2018
From: levkivskyi at gmail.com (Ivan Levkivskyi)
Date: Fri, 18 May 2018 18:58:32 -0400
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
References: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
Message-ID: <CAOMjWkkLqqYMbCiqhke+amJ87eVeWQhd=4pwJ1B5=7XNFmgCDg@mail.gmail.com>

I would like to clarify, what would be a typical time-line for a PEP? Will
it look like this:

0. Preliminary discussions to determine whether an idea is PEP-worthy (can
happen anywhere, python-ideas, SIGs, even offline)
1. A PEP number is requested by a champion and assigned by a PEP editor (in
python/peps repo)
2. PEP is drafted and discussed by a narrow circle of interested
participants (happens in a separate repo)
3. When PEP is ready and polished make a PR to python/peps repo, and post
it to python-dev to get feedback (if any) from a wider audience
4. If reasonable objections appear at this step, go to step 2
5. Repeat steps 2-4 until accepted/rejected/deferred

Is this what you propose? Or you want to completely avoid posting to
python-dev?

--
Ivan



On 18 May 2018 at 18:25, Guido van Rossum <guido at python.org> wrote:

> Discussing PEPs on python-dev and python-ideas is clearly not scalable any
> more. (Even python-committers probably doesn't scale too well. :-)
>
> I wonder if it would make sense to require that for each PEP a new GitHub
> *repo* be created whose contents would just be a draft PEP and whose issue
> tracker and PR manager would be used to debate the PEP and propose specific
> changes.
>
> This way the discussion is still public: when the PEP-specific repo is
> created the author(s) can notify python-ideas, and when they are closer to
> submitting they can notify python-dev, but the discussion doesn't attract
> uninformed outsiders as much as python-{dev,ideas} discussions do, and it's
> much easier for outsiders who want to learn more about the proposal to find
> all relevant discussion.
>
> PEP authors may also choose to use a different repo hosting site, e.g.
> Bitbucket or GitLab. We can provide a script that allows checking the
> formatting of the PEP easily (basically pep2html.py from the peps repo).
>
> Using a separate repo per PEP has the advantage that people interested in
> a topic can subscribe to all traffic in that repo -- if we were to use the
> tracker of the peps repo you would have to subscribe to all peps traffic.
>
> Thoughts? (We can dogfood this proposal too, if there's interest. :-)
>
> --
> --Guido van Rossum (python.org/~guido)
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180518/3c7dd698/attachment.html>

From willingc at gmail.com  Fri May 18 19:13:13 2018
From: willingc at gmail.com (Carol Willing)
Date: Fri, 18 May 2018 16:13:13 -0700
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
References: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
Message-ID: <E6051FDB-C2AE-4060-BB4C-D1124C2D953B@gmail.com>



> On May 18, 2018, at 3:25 PM, Guido van Rossum <guido at python.org <mailto:guido at python.org>> wrote:
> 
> Discussing PEPs on python-dev and python-ideas is clearly not scalable any more. (Even python-committers probably doesn't scale too well. :-)
> 
> I wonder if it would make sense to require that for each PEP a new GitHub *repo* be created whose contents would just be a draft PEP and whose issue tracker and PR manager would be used to debate the PEP and propose specific changes.
> 

We have something similar for Project Jupyter. We have a jupyter-incubator org for third party projects that may someday be accepted into the Jupyter core. One repo in particular, https://github.com/jupyter-incubator/proposals <https://github.com/jupyter-incubator/proposals>, keeps track of all the currently active proposals with links out to their repos, if not hosted within the incubator org.

> This way the discussion is still public: when the PEP-specific repo is created the author(s) can notify python-ideas, and when they are closer to submitting they can notify python-dev, but the discussion doesn't attract uninformed outsiders as much as python-{dev,ideas} discussions do, and it's much easier for outsiders who want to learn more about the proposal to find all relevant discussion.
> 
> PEP authors may also choose to use a different repo hosting site, e.g. Bitbucket or GitLab. We can provide a script that allows checking the formatting of the PEP easily (basically pep2html.py from the peps repo).
> 
> Using a separate repo per PEP has the advantage that people interested in a topic can subscribe to all traffic in that repo -- if we were to use the tracker of the peps repo you would have to subscribe to all peps traffic.

This makes sense - one repo per proposed PEP as PRs can be used to help iterate the wording and issues can focus on specific subtopics. Having one repo that acts as a landing page for all of the in-progress PEPs would help folks keep track of where an in-progress PEP is located.

> 
> Thoughts? (We can dogfood this proposal too, if there's interest. :-)
> 
> -- 
> --Guido van Rossum (python.org/~guido <http://python.org/~guido>)
> _______________________________________________
> python-committers mailing list
> python-committers at python.org <mailto:python-committers at python.org>
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180518/6b37d019/attachment-0001.html>

From greg at krypto.org  Fri May 18 19:29:01 2018
From: greg at krypto.org (Gregory P. Smith)
Date: Fri, 18 May 2018 16:29:01 -0700
Subject: [python-committers] Travis & AppVeyor hidden on Github,
 scroll the invisible region to see them.
In-Reply-To: <93977d72-9972-03d3-d59e-791d63a7320f@udel.edu>
References: <CAGE7PNL3Ksup2gSQF=TNfsGrXLv6tRkaD72zDBsW6DbZBxNmCQ@mail.gmail.com>
 <93977d72-9972-03d3-d59e-791d63a7320f@udel.edu>
Message-ID: <CAGE7PNLjXEOZEe5iJtOdOzQbG_bFDYaPz3LUCxpQk-A45Upmjg@mail.gmail.com>

On Fri, May 18, 2018 at 9:45 AM Terry Reedy <tjreedy at udel.edu> wrote:

> On 5/18/2018 12:25 AM, Gregory P. Smith wrote:
> > VSTS is clearly not yet a stable continuous integration platform.  It
> > needs to be made non-blocking, and AppVeyor and Travis need to be
> > brought back!
> >
> > Examples:
> > https://github.com/python/cpython/pull/6938#issuecomment-389908094
> >     Windows broke -
> > https://python.visualstudio.com/cpython/_build?buildId=522
> > https://github.com/python/cpython/pull/6939
> >     Linux broke -
> https://python.visualstudio.com/cpython/_build?buildId=523
>
> Travis and AppVeyor are there on both issues, and both can be merged --
> manually -- by pressing 'Squach and merge', even though not green.  The
> VSTS results are not blocking -- they are not marked as 'Required'.


Sorry! A combination of github UX flaws led me to misunderstand what I was
seeing. The things I wanted to see were still run, but they are not
displayed, so I assumed they were gone.  That plus the no green button made
me assume the new things that were displayed containing one red item were
all that there was to see and that they were blocking everything.

There is a hidden secret scrolling region when "show all checks" is active
on github instead of actually showing all.  It only shows five (read: not
the five I want).  The things I wanted to see were at the bottom and thus
not displayed as it puts the VSTS builds up top for some unknown to me
reason.

I am intentionally not merging those PRs yet as I referred to them from
several places as examples of this problem.

The
> problem is that miss-islington was not changed, and sees any VSTS
> failure as a status check failure and a reason to not do the automerge
> you requested by approving the change.
>

That at least we can fix until we trust VSTS to be reliable.  As is, the
more checkers we have to block on, the more likely anything flaky (either
infrastructure or tests+code itself) is to block any given change.

What do people think about teaching miss-islington how to re-launch
specific CI runs a few times to deflake failures? ("1 out of n passes
counts as a pass") - That requires compute resources, but when it is what
the human is going to need to do anyways... why not reduce the need and
just automate it the first couple of times? I don't know how feasible this
is for any given CI system we use today on CPython given the various ways
in which they operate.

-gps


>
> > This was on a documentation-only change.
> >
> > We cannot be changing to new PR-merge-blocking continuous integration
> > services at this point during a release cycle.  This is preventing
> > changes from making it in.
>
> What *is* blocking merges and making them painful at times are the
> haphazard failures of test_asyncio on the blocking bots, Travis and
> AppVeyor, at a rate as high as 1/4 of individual test runs.  See
> https://bugs.python.org/issue33531
> On one backport last night, I had to run Travis 4 times, which means I
> had to periodically monitor the backport instead of approve and forget.
> And then I had to manually merge.
>
> tjr
>
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180518/3757d1db/attachment.html>

From guido at python.org  Fri May 18 19:41:42 2018
From: guido at python.org (Guido van Rossum)
Date: Fri, 18 May 2018 16:41:42 -0700
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <CAOMjWkkLqqYMbCiqhke+amJ87eVeWQhd=4pwJ1B5=7XNFmgCDg@mail.gmail.com>
References: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
 <CAOMjWkkLqqYMbCiqhke+amJ87eVeWQhd=4pwJ1B5=7XNFmgCDg@mail.gmail.com>
Message-ID: <CAP7+vJ+WR605chtapeRN+rp6NjQ4kOkbu1ZHkn4_hfPc-hvzTw@mail.gmail.com>

On Fri, May 18, 2018 at 3:58 PM, Ivan Levkivskyi <levkivskyi at gmail.com>
wrote:

> I would like to clarify, what would be a typical time-line for a PEP? Will
> it look like this:
>
> 0. Preliminary discussions to determine whether an idea is PEP-worthy (can
> happen anywhere, python-ideas, SIGs, even offline)
> 1. A PEP number is requested by a champion and assigned by a PEP editor
> (in python/peps repo)
>

I expect some proposals to get stuck before they're ever in a state
acceptable even as draft PEP, so I'd like to put off requesting a PEP
number as long as possible.


> 2. PEP is drafted and discussed by a narrow circle of interested
> participants (happens in a separate repo)
> 3. When PEP is ready and polished make a PR to python/peps repo, and post
> it to python-dev to get feedback (if any) from a wider audience
>

I expect there to be a long trajectory where the PEP does exist in the peps
repo but should still be discussed in its own repo. Mentions on python-dev
should be limited to the occasional link to the PEP's own repo, with
strongly worded requests to go to that repo to provide feedback.


> 4. If reasonable objections appear at this step, go to step 2
>

The process should be clear that objections posted to python-dev will be
ignored -- only objections posted to the PEP's own repo's issue tracker
will be considered.


> 5. Repeat steps 2-4 until accepted/rejected/deferred
>
> Is this what you propose? Or you want to completely avoid posting to
> python-dev?
>

I want to completely avoid discussion on python-dev. This probably means we
should never post the full text of the PEP there. (We may have to amend PEP
1 to support this.)

There are probably some other parts needed too, e.g. guidelines as to when
a PEP is considered ripe for copying to the peps repo (and scripts/bots to
make repeated copies easy -- e.g. there could be a bot that copies a PEP
from that PEP's own repo to the peps repo each time a commit is made to the
master branch in its own repo). There could also be guidelines to ensure a
PEP is in a fairly non-controversial state (probably using the IETF's motto
"rough consensus and working code") before being considered for approval.
There's definitely some time when a PEP has an assigned number but is still
controversial -- during that state debate on python-dev should be strictly
redirected to the PEP's own repo.

For some PEPs it may make sense to assign a senior reviewer who decides
what's considered non-controversial.

We can borrow more from the IETF process for RFCs:
https://www.rfc-editor.org/pubprocess/

--Guido

PS. Carol: Jupyter's process looks great! I just don't have the guts to
propose any serious changes to the physical logistics of publishing PEPs,
since changes to the structure of the peps repo are so hard. We still
haven't converted all PEPs to .rst format, despite efforts by Mariatta and
others, and attempts to move all PEPs to a subdirectory have also failed,
due to perpetual lack of resources to complete the task (and e.g. the need
to update scripts on python.org whenever the peps repo structure changes).



>
> --
> Ivan
>
>
>
> On 18 May 2018 at 18:25, Guido van Rossum <guido at python.org> wrote:
>
>> Discussing PEPs on python-dev and python-ideas is clearly not scalable
>> any more. (Even python-committers probably doesn't scale too well. :-)
>>
>> I wonder if it would make sense to require that for each PEP a new GitHub
>> *repo* be created whose contents would just be a draft PEP and whose issue
>> tracker and PR manager would be used to debate the PEP and propose specific
>> changes.
>>
>> This way the discussion is still public: when the PEP-specific repo is
>> created the author(s) can notify python-ideas, and when they are closer to
>> submitting they can notify python-dev, but the discussion doesn't attract
>> uninformed outsiders as much as python-{dev,ideas} discussions do, and it's
>> much easier for outsiders who want to learn more about the proposal to find
>> all relevant discussion.
>>
>> PEP authors may also choose to use a different repo hosting site, e.g.
>> Bitbucket or GitLab. We can provide a script that allows checking the
>> formatting of the PEP easily (basically pep2html.py from the peps repo).
>>
>> Using a separate repo per PEP has the advantage that people interested in
>> a topic can subscribe to all traffic in that repo -- if we were to use the
>> tracker of the peps repo you would have to subscribe to all peps traffic.
>>
>> Thoughts? (We can dogfood this proposal too, if there's interest. :-)
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>>
>> _______________________________________________
>> python-committers mailing list
>> python-committers at python.org
>> https://mail.python.org/mailman/listinfo/python-committers
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
>>
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180518/931d1711/attachment-0001.html>

From greg at krypto.org  Fri May 18 19:46:00 2018
From: greg at krypto.org (Gregory P. Smith)
Date: Fri, 18 May 2018 16:46:00 -0700
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
References: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
Message-ID: <CAGE7PNLMOGjKc-P2YHRVRoCaScdumXD1ntuNkfXxyBN8_t5xBQ@mail.gmail.com>

On Fri, May 18, 2018 at 3:28 PM Guido van Rossum <guido at python.org> wrote:

> Discussing PEPs on python-dev and python-ideas is clearly not scalable any
> more. (Even python-committers probably doesn't scale too well. :-)
>
> I wonder if it would make sense to require that for each PEP a new GitHub
> *repo* be created whose contents would just be a draft PEP and whose issue
> tracker and PR manager would be used to debate the PEP and propose specific
> changes.
>
> This way the discussion is still public: when the PEP-specific repo is
> created the author(s) can notify python-ideas, and when they are closer to
> submitting they can notify python-dev, but the discussion doesn't attract
> uninformed outsiders as much as python-{dev,ideas} discussions do, and it's
> much easier for outsiders who want to learn more about the proposal to find
> all relevant discussion.
>

overall I think this idea has merit.

flaws?  People who haven't yet given attention to the PEP over in its own
world are likely to spawn the same threads on -ideas or -dev when the PEP
is introduced there.

So long as something is public, there will always be outsiders. It also
seems like using a forum such as a repository full of PRs threads can lose
the discussion history as PRs are not a mailing list archive and can
disappear at the whim of the corporation hosting them.  But do we care
about that?  In theory all arguments and alternatives for/against are
_supposed_ to be captured into the PEP doc itself before it is accepted.

I do like the ability to have a technical code discussion in markdown as
PRs allow vs email.  But if there are 100 people chiming in, I doubt this
would make anything any easier to follow.

PEP authors may also choose to use a different repo hosting site, e.g.
> Bitbucket or GitLab. We can provide a script that allows checking the
> formatting of the PEP easily (basically pep2html.py from the peps repo).
>
> Using a separate repo per PEP has the advantage that people interested in
> a topic can subscribe to all traffic in that repo -- if we were to use the
> tracker of the peps repo you would have to subscribe to all peps traffic.
>

It sounds like your primary goals here are
 (a) to avoid PEP discussions on the -dev and -ideas mailing lists and
 (b) to have a central place for all discussions spawned from a specific
PEP instead of trying to piece together 18 centithreads with varying
subjects from python-* list archives.

I think (a) would happen at the start, and (b) would be true in this
scenario so it is probably worth a try.

I do expect (a) to overflow to the mailing list anyways at times.  But this
would give us the opportunity to redirect that away from the list.  It
should still be better than the common mailing list free for all we have
today.  It seems a bit more like a "working group" system. (which is what
Carol's description of Jupyter incubator reminds me of)

*repos* where PEP discussions take place could optionally be CPython forks
with an example implementation to eventually be used to construct the
ultimate PRs adding it if the PEP is accepted.


> Thoughts? (We can dogfood this proposal too, if there's interest. :-)
>

I'm all for picking a victom^Wvolunteer PEP to try dogfood it on.

-gps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180518/0a06bc03/attachment.html>

From levkivskyi at gmail.com  Fri May 18 19:51:25 2018
From: levkivskyi at gmail.com (Ivan Levkivskyi)
Date: Fri, 18 May 2018 19:51:25 -0400
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <CAGE7PNLMOGjKc-P2YHRVRoCaScdumXD1ntuNkfXxyBN8_t5xBQ@mail.gmail.com>
References: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
 <CAGE7PNLMOGjKc-P2YHRVRoCaScdumXD1ntuNkfXxyBN8_t5xBQ@mail.gmail.com>
Message-ID: <CAOMjWkkjL3B3_PFzb58WO8v0e5yiAfXZx+g3onyZZD4BO5TLsA@mail.gmail.com>

On 18 May 2018 at 19:46, Gregory P. Smith <greg at krypto.org> wrote:

>
> I'm all for picking a victom^Wvolunteer PEP to try dogfood it on.
>
>
Can few related PEPs share the same repository? For example, I want to
start writing three PEPs about extensions to PEP 484 type system: literal
types, final/const qualifier, and integer generics (simple dependent types).
They all are tightly connected (but I don't want a single mega-PEP), can I
put these three in the same repo?

--
Ivan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180518/ad5b516c/attachment.html>

From guido at python.org  Fri May 18 20:02:28 2018
From: guido at python.org (Guido van Rossum)
Date: Fri, 18 May 2018 17:02:28 -0700
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <CAOMjWkkjL3B3_PFzb58WO8v0e5yiAfXZx+g3onyZZD4BO5TLsA@mail.gmail.com>
References: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
 <CAGE7PNLMOGjKc-P2YHRVRoCaScdumXD1ntuNkfXxyBN8_t5xBQ@mail.gmail.com>
 <CAOMjWkkjL3B3_PFzb58WO8v0e5yiAfXZx+g3onyZZD4BO5TLsA@mail.gmail.com>
Message-ID: <CAP7+vJLQ3mwiG68ZiUCSejvyB6DZtEfPbZiGWp4Y9jo7-FOFtA@mail.gmail.com>

Yes, you can do that.

On Fri, May 18, 2018, 16:51 Ivan Levkivskyi <levkivskyi at gmail.com> wrote:

> On 18 May 2018 at 19:46, Gregory P. Smith <greg at krypto.org> wrote:
>
>>
>> I'm all for picking a victom^Wvolunteer PEP to try dogfood it on.
>>
>>
> Can few related PEPs share the same repository? For example, I want to
> start writing three PEPs about extensions to PEP 484 type system: literal
> types, final/const qualifier, and integer generics (simple dependent types).
> They all are tightly connected (but I don't want a single mega-PEP), can I
> put these three in the same repo?
>
> --
> Ivan
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180518/fa9b6857/attachment.html>

From vstinner at redhat.com  Fri May 18 20:10:52 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Sat, 19 May 2018 02:10:52 +0200
Subject: [python-committers] Comments on moving issues to GitHub
Message-ID: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>

Hi,

I failed to get the microphone after Mariatta's secret talk about
moving Python issues from bugs.python.org (Roundup) to GitHub.

I just wanted to add that it's common (at least once per month) that
someone comes to #python-dev to report that they cannot connect to
bugs.python.org (the authentication is broken). Usually, I tried to
point them to the meta-bug tracker, but I hate doing that... The
concept of a meta-bug tracker blows my mind :-)

Right now, I tied to add a comment on an issue and I got the error:

"""
Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request POST /issue32534.

Reason: Error reading from remote server

________________________________
Apache/2.2.16 (Debian) Server at bugs.python.org Port 443
"""

Sometimes, I get a SSL error. I reported the issue 7 months ago, and
sometimes I still get the error:

https://github.com/python/psf-infra-meta/issues/4

It's a random error, but using a loop, it's easy to reproduce it.


I don't have a strong opinion about moving issues to GitHub. I just
wanted to point out that if we keep bugs.python.org, we need more
volunteers to maintain it. I would prefer to not have to redirect new
comers, who want to report a simple bug, to a "meta bug tracker"...


I don't plan to report the proxy error, since my previous bug report
(SSL error) is still not fixed and it's the first time that I got this
error.

Victor

From njs at pobox.com  Fri May 18 21:29:24 2018
From: njs at pobox.com (Nathaniel Smith)
Date: Fri, 18 May 2018 18:29:24 -0700
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
References: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
Message-ID: <CAPJVwBmo=_aGwxOWzJW5d4FX571Nv3kaWWab0bjMTxUquTeuCA@mail.gmail.com>

On Fri, May 18, 2018 at 3:25 PM, Guido van Rossum <guido at python.org> wrote:
> Discussing PEPs on python-dev and python-ideas is clearly not scalable any
> more. (Even python-committers probably doesn't scale too well. :-)

PEP 572 seems like something of a perfect storm... it's simultaneously
a bikeshed and a nuclear power plant [1], and also the rare proposal
that you like but that significant numbers of core devs find deeply
objectionable; any one of these would tend to produce a lot of email,
and then the combination is something else again. Is this proposal
mostly responding to that, or something that you've been thinking for
a while?

[1] For those unfamiliar with this example:
https://en.wikipedia.org/wiki/Law_of_triviality#Examples

> I wonder if it would make sense to require that for each PEP a new GitHub
> *repo* be created whose contents would just be a draft PEP and whose issue
> tracker and PR manager would be used to debate the PEP and propose specific
> changes.

To some extent this has been happening informally for a while. Just
off the top of my head:

PEP 465: https://github.com/numpy/numpy/pull/4351
PEP 543: https://github.com/python-hyper/pep543/issues/2#issuecomment-309199376
PEP 513: https://github.com/pypa/manylinux#the-pep-itself
A repo full of packaging PEPs: https://github.com/pypa/interoperability-peps

For a lot of us these days, putting a document in a repo is just the
default way to work on it (and get feedback, etc.).

Managing the relationship between these repos and the main peps repo
is currently pretty awkward. They tend to get out of sync in both
directions ? people make edits directly to the PEP repo ? plus in
general some pieces of information are in one place and some in
another, there's no link between them, the original repo can get
misplaced over time...

> This way the discussion is still public: when the PEP-specific repo is
> created the author(s) can notify python-ideas, and when they are closer to
> submitting they can notify python-dev, but the discussion doesn't attract
> uninformed outsiders as much as python-{dev,ideas} discussions do, and it's
> much easier for outsiders who want to learn more about the proposal to find
> all relevant discussion.
>
> PEP authors may also choose to use a different repo hosting site, e.g.
> Bitbucket or GitLab. We can provide a script that allows checking the
> formatting of the PEP easily (basically pep2html.py from the peps repo).

I'd be somewhat tempted to require people to use Github and to move
the repo into the python/ organization when it gets a number, so that
there's one canonical place to look for the history and we have some
control over its lifecycle.

More radical idea: what if the PEPs index just linked to the Github
rendering of each file? That's always going to be up to date, it comes
with a link to the issue tracker at the top, it has a nice "Edit"
button if someone wants to submit small fixes as a PR...

> Using a separate repo per PEP has the advantage that people interested in a
> topic can subscribe to all traffic in that repo -- if we were to use the
> tracker of the peps repo you would have to subscribe to all peps traffic.
>
> Thoughts? (We can dogfood this proposal too, if there's interest. :-)

Rust's RFC process is a bit different, but may be of interest:
https://github.com/rust-lang/rfcs

One thing people might worry about is missing out on discussion
they're interested in ? there wouldn't be one central place to
subscribe to see discussions. Rust's concept of a "final comment
period" is a nice way to manage this.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org

From njs at pobox.com  Fri May 18 21:33:00 2018
From: njs at pobox.com (Nathaniel Smith)
Date: Fri, 18 May 2018 18:33:00 -0700
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <CAOMjWkkjL3B3_PFzb58WO8v0e5yiAfXZx+g3onyZZD4BO5TLsA@mail.gmail.com>
References: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
 <CAGE7PNLMOGjKc-P2YHRVRoCaScdumXD1ntuNkfXxyBN8_t5xBQ@mail.gmail.com>
 <CAOMjWkkjL3B3_PFzb58WO8v0e5yiAfXZx+g3onyZZD4BO5TLsA@mail.gmail.com>
Message-ID: <CAPJVwB=zBjd8-5tw4h4F61nVb6cyqWsrW9D4PLu0vYbC1qUGjA@mail.gmail.com>

On Fri, May 18, 2018 at 4:51 PM, Ivan Levkivskyi <levkivskyi at gmail.com> wrote:
> On 18 May 2018 at 19:46, Gregory P. Smith <greg at krypto.org> wrote:
>>
>>
>> I'm all for picking a victom^Wvolunteer PEP to try dogfood it on.
>>
>
> Can few related PEPs share the same repository? For example, I want to start
> writing three PEPs about extensions to PEP 484 type system: literal types,
> final/const qualifier, and integer generics (simple dependent types).
> They all are tightly connected (but I don't want a single mega-PEP), can I
> put these three in the same repo?

Another common pattern we see with trickier PEPs is the creation of
multiple competing proposals. This strikes me as healthy and something
we want to encourage. Maybe these should also go in the same repo by
default?

This is also a case where assigning PEP numbers earlier rather than
later seems useful. Unambiguously referring to PEP 521, PEP 550, PEP
567, and PEP 568 would be difficult without the numbers :-).

-n

-- 
Nathaniel J. Smith -- https://vorpus.org

From njs at pobox.com  Fri May 18 22:39:59 2018
From: njs at pobox.com (Nathaniel Smith)
Date: Fri, 18 May 2018 19:39:59 -0700
Subject: [python-committers] Travis & AppVeyor hidden on Github,
 scroll the invisible region to see them.
In-Reply-To: <CAGE7PNLjXEOZEe5iJtOdOzQbG_bFDYaPz3LUCxpQk-A45Upmjg@mail.gmail.com>
References: <CAGE7PNL3Ksup2gSQF=TNfsGrXLv6tRkaD72zDBsW6DbZBxNmCQ@mail.gmail.com>
 <93977d72-9972-03d3-d59e-791d63a7320f@udel.edu>
 <CAGE7PNLjXEOZEe5iJtOdOzQbG_bFDYaPz3LUCxpQk-A45Upmjg@mail.gmail.com>
Message-ID: <CAPJVwBkOQHVPOwuAv6A8S-o_mkjF0PqgPAcGp+J1p4aDw73Rjw@mail.gmail.com>

On Fri, May 18, 2018 at 4:29 PM, Gregory P. Smith <greg at krypto.org> wrote:
> What do people think about teaching miss-islington how to re-launch specific
> CI runs a few times to deflake failures? ("1 out of n passes counts as a
> pass") - That requires compute resources, but when it is what the human is
> going to need to do anyways... why not reduce the need and just automate it
> the first couple of times? I don't know how feasible this is for any given
> CI system we use today on CPython given the various ways in which they
> operate.

This can also be done with a loop inside individual tests, which would
avoid complications with CI APIs and make sure that if any new flaky
tests show up then we'll notice it.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org

From antoine at python.org  Sat May 19 01:45:56 2018
From: antoine at python.org (Antoine Pitrou)
Date: Sat, 19 May 2018 07:45:56 +0200
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <CAP7+vJ+WR605chtapeRN+rp6NjQ4kOkbu1ZHkn4_hfPc-hvzTw@mail.gmail.com>
References: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
 <CAOMjWkkLqqYMbCiqhke+amJ87eVeWQhd=4pwJ1B5=7XNFmgCDg@mail.gmail.com>
 <CAP7+vJ+WR605chtapeRN+rp6NjQ4kOkbu1ZHkn4_hfPc-hvzTw@mail.gmail.com>
Message-ID: <dc477b8f-e8e9-f2b2-71db-f193e7860087@python.org>


Hi,

Note that some PEPs are, still, mostly uncontroversial (PEP 574 is an
example).

I agree with Nathaniel : PEP 572 is the poster child for lengthy, heated
discussions.  I'm still surprised you thought it was a good idea to
discuss this.  Perhaps it we tried to discourage syntax change and/or
builtin change PEPs a little more we'd have less heated PEPs :-)

It would be *very* interesting if someone was willing to do some stats
on PEPs over time: e.g. number of PEPs discussed every year, discussion
length, number of discusssion participants.  I actually expect overall
PEP activity to have gone down since the 2000s.


Le 19/05/2018 ? 01:41, Guido van Rossum a ?crit?:
> I want to completely avoid discussion on python-dev. This probably means
> we should never post the full text of the PEP there. (We may have to
> amend PEP 1 to support this.)

Are you saying PEPs wouldn't even be *validated* by python-dev?
If so, it's not a mere change to focus discussions, it's also a change
in governance.

And while we may decide to change this piece of the governance model,
the replacement process should IMO be something a little less vague than
? discussion happens on Github with whoever happens to be interested or
available ?.  Sorry if this is misrepresenting your position.

Regards

Antoine.



> There are probably some other parts needed too, e.g. guidelines as to
> when a PEP is considered ripe for copying to the peps repo (and
> scripts/bots to make repeated copies easy -- e.g. there could be a bot
> that copies a PEP from that PEP's own repo to the peps repo each time a
> commit is made to the master branch in its own repo). There could also
> be guidelines to ensure a PEP is in a fairly non-controversial state
> (probably using the IETF's motto "rough consensus and working code")
> before being considered for approval. There's definitely some time when
> a PEP has an assigned number but is still controversial -- during that
> state debate on python-dev should be strictly redirected to the PEP's
> own repo.
> 
> For some PEPs it may make sense to assign a senior reviewer who decides
> what's considered non-controversial.
> 
> We can borrow more from the IETF process for RFCs:
> https://www.rfc-editor.org/pubprocess/
> 
> --Guido
> 
> PS. Carol: Jupyter's process looks great! I just don't have the guts to
> propose any serious changes to the physical logistics of publishing
> PEPs, since changes to the structure of the peps repo are so hard. We
> still haven't converted all PEPs to .rst format, despite efforts by
> Mariatta and others, and attempts to move all PEPs to a subdirectory
> have also failed, due to perpetual lack of resources to complete the
> task (and e.g. the need to update scripts on python.org
> <http://python.org> whenever the peps repo structure changes).

From storchaka at gmail.com  Sat May 19 02:52:14 2018
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Sat, 19 May 2018 09:52:14 +0300
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
References: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
Message-ID: <46caeafe-b821-667c-76b4-450b681f69a8@gmail.com>

19.05.18 01:25, Guido van Rossum ????:
> I wonder if it would make sense to require that for each PEP a new 
> GitHub *repo* be created whose contents would just be a draft PEP and 
> whose issue tracker and PR manager would be used to debate the PEP and 
> propose specific changes.
>
> This way the discussion is still public: when the PEP-specific repo is 
> created the author(s) can notify python-ideas, and when they are 
> closer to submitting they can notify python-dev, but the discussion 
> doesn't attract uninformed outsiders as much as python-{dev,ideas} 
> discussions do, and it's much easier for outsiders who want to learn 
> more about the proposal to find all relevant discussion.
>
> PEP authors may also choose to use a different repo hosting site, e.g. 
> Bitbucket or GitLab. We can provide a script that allows checking the 
> formatting of the PEP easily (basically pep2html.py from the peps repo).

What will happen with these repos after accepting or rejecting 
corresponding PEPs?


From p.f.moore at gmail.com  Sat May 19 06:36:25 2018
From: p.f.moore at gmail.com (Paul Moore)
Date: Sat, 19 May 2018 11:36:25 +0100
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
References: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
Message-ID: <CACac1F8pjhcQCiqROszoDZG7wbRyQ0ehA2auf0CsGm8S3Xd0mA@mail.gmail.com>

On 18 May 2018 at 23:25, Guido van Rossum <guido at python.org> wrote:
> Discussing PEPs on python-dev and python-ideas is clearly not scalable any
> more. (Even python-committers probably doesn't scale too well. :-)

It's not scalable, certainly. But it's still (IMO) fine for all but
the larger PEPs - the trick is spotting which PEPs are "too big" :-)

I'm not sure that the issue with python-ideas is that bad. That list
is *designed* for incomplete and unformed proposals, and so long
threads are common (and accepted) on there. People on python-ideas are
used to skimming or ignoring/blocking threads they aren't interested
in. So by the time things are ready to go to python-dev (or wherever)
there's a good sense of whether the PEP is likely to be controversial.
I'd suggest that this is the point when the decision to go to
python-dev or github could be made.

> I wonder if it would make sense to require that for each PEP a new GitHub
> *repo* be created whose contents would just be a draft PEP and whose issue
> tracker and PR manager would be used to debate the PEP and propose specific
> changes.
>
> This way the discussion is still public: when the PEP-specific repo is
> created the author(s) can notify python-ideas, and when they are closer to
> submitting they can notify python-dev, but the discussion doesn't attract
> uninformed outsiders as much as python-{dev,ideas} discussions do, and it's
> much easier for outsiders who want to learn more about the proposal to find
> all relevant discussion.
>
> PEP authors may also choose to use a different repo hosting site, e.g.
> Bitbucket or GitLab. We can provide a script that allows checking the
> formatting of the PEP easily (basically pep2html.py from the peps repo).

I would prefer that PEP repos remain on github, and that once the PEP
is finalised (accepted, rejected, whatever) moved under the CPython
organisation (the whole repo, issue tracker, history, everything) so
that the history of discussion isn't lost. Current PEP discussions are
retained on the list archives, and I think the discussion history is
valuable (even if a lot of it ends up being noise at the moment). I'd
rather not have to maintain extra accounts for bitbucket or gitlab,
and learn how notifications and tracking work on those platforms. A
common interface is important. Adding barriers to contribution does
filter out casual commenters, but I'm sure we don't want to be seen to
be deliberately making it *hard* for outsiders to get involved.

> Using a separate repo per PEP has the advantage that people interested in a
> topic can subscribe to all traffic in that repo -- if we were to use the
> tracker of the peps repo you would have to subscribe to all peps traffic.
>
> Thoughts? (We can dogfood this proposal too, if there's interest. :-)

(Later)
> I want to completely avoid discussion on python-dev. This probably means we should never post the full text of the PEP there. (We may have to amend PEP 1 to support this.)

Avoiding *discussion* is probably OK. But regular summaries of
progress would, I think, be critical. Otherwise python-dev is
essentially cut out of the loop, and this becomes more of a change in
governance, as Antoine mentioned.

I'm not quite sure what your intention was, but I'd like to see a
series of announcements on python-dev for a PEP which is being
discussed offline:

1. An initial announcement of the creation of the PEP repo, giving a
summary of the PEP (the abstract from the proposal), and a pointer to
where interested parties should go to participate in discussions.
2. Progress announcements, maybe once a month, repeating the summary
and adding a "what has changed" summary.
3. Preliminary announcement of the decision on the PEP (a "release
candidate" if you like) stating that the decision has been made, what
that decision is, and that it will be officially announced in (say) a
week.
4. Final announcement, giving the summary, the decision, and pointers
to the final PEP text and the discussion (now hosted permanently under
the cpython org on github).

The point of the "release candidate" stage is the same as the RC for a
release - last chance to raise showstopper problems, plus announcing
the start of the "release" work (moving the repo, specifically).

I'm not that wedded to the RC announcement, but it will avoid the
final decision coming as a complete surprise to python-dev. As a data
point, I currently have no idea whether the discussions on the binding
expression PEP are still just rumbling on, or whether a decision is
imminent. Of course, if the progress announcements are sufficiently
good, the RC may not be necessary (it would effectively just be the
last in a series of summaries).

Paul

From steve at pearwood.info  Sat May 19 10:37:14 2018
From: steve at pearwood.info (Steven D'Aprano)
Date: Sun, 20 May 2018 00:37:14 +1000
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
References: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
Message-ID: <20180519143714.GY12683@ando.pearwood.info>

On Fri, May 18, 2018 at 03:25:37PM -0700, Guido van Rossum wrote:
> Discussing PEPs on python-dev and python-ideas is clearly not scalable any
> more. (Even python-committers probably doesn't scale too well. :-)
> 
> I wonder if it would make sense to require that for each PEP a new GitHub
> *repo* be created whose contents would just be a draft PEP and whose issue
> tracker and PR manager would be used to debate the PEP and propose specific
> changes.

Do we have a reason to think that moving to Github will help discussions 
scale better?

At the moment, a controversial PEP generates a flood of email on 
Python-Ideas and a flood of email on Python-Dev. If all we do is add a 
third flood of posts on Github, that's not much of a win :-)

Aside from the nuisance value of having to sign up to yet another 
forum (Github as well as a mailing list), which isn't that big a 
nuisance given that these days most people have a Github account, I'm 
not too clear on the benefit of this.


> This way the discussion is still public: when the PEP-specific repo is
> created the author(s) can notify python-ideas, and when they are closer to
> submitting they can notify python-dev, but the discussion doesn't attract
> uninformed outsiders as much as python-{dev,ideas} discussions do, and it's
> much easier for outsiders who want to learn more about the proposal to find
> all relevant discussion.

Isn't that a bit of a contradiction?

- moving to GitHub doesn't attract outsiders
- while making it easier for outsiders




-- 
Steve

From antoine at python.org  Sun May 20 04:56:21 2018
From: antoine at python.org (Antoine Pitrou)
Date: Sun, 20 May 2018 10:56:21 +0200
Subject: [python-committers] Comments on moving issues to GitHub
In-Reply-To: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
Message-ID: <005b303f-2055-1057-6434-65dda83fc85a@python.org>


Le 19/05/2018 ? 02:10, Victor Stinner a ?crit?:
> Hi,
> 
> I failed to get the microphone after Mariatta's secret talk about
> moving Python issues from bugs.python.org (Roundup) to GitHub.

A "secret talk"? What is that?

> I don't have a strong opinion about moving issues to GitHub.

If that's on the table, it seems to me that categorization, sorting and
filtering on GitHub issues is rather poor, while the basic UI experience
(editing messages, etc.) is better.  Also, I think customization (e.g.
of the default view) is basically inexistent.

Regards

Antoine.

From stefan at bytereef.org  Sun May 20 07:45:45 2018
From: stefan at bytereef.org (Stefan Krah)
Date: Sun, 20 May 2018 13:45:45 +0200
Subject: [python-committers] Comments on moving issues to GitHub
In-Reply-To: <005b303f-2055-1057-6434-65dda83fc85a@python.org>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
 <005b303f-2055-1057-6434-65dda83fc85a@python.org>
Message-ID: <20180520114545.GA2717@bytereef.org>

On Sun, May 20, 2018 at 10:56:21AM +0200, Antoine Pitrou wrote:
> If that's on the table, it seems to me that categorization, sorting and
> filtering on GitHub issues is rather poor, while the basic UI experience
> (editing messages, etc.) is better.  Also, I think customization (e.g.
> of the default view) is basically inexistent.

Also search via Google "site:bugs.python.org <term>" usually gives quite
nice results, while the same for GitHub issues usually does not work at
all (far too many unrelated results).


Then there's the original promise of the GitHub migration that in the
case of GH bankruptcy or a sudden lockdown the tracker would still be
available.



Stefan Krah




From njs at pobox.com  Sun May 20 13:19:25 2018
From: njs at pobox.com (Nathaniel Smith)
Date: Sun, 20 May 2018 10:19:25 -0700
Subject: [python-committers] Comments on moving issues to GitHub
In-Reply-To: <005b303f-2055-1057-6434-65dda83fc85a@python.org>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
 <005b303f-2055-1057-6434-65dda83fc85a@python.org>
Message-ID: <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>

On Sun, May 20, 2018, 03:18 Antoine Pitrou <antoine at python.org> wrote:

>
> Le 19/05/2018 ? 02:10, Victor Stinner a ?crit :
> > Hi,
> >
> > I failed to get the microphone after Mariatta's secret talk about
> > moving Python issues from bugs.python.org (Roundup) to GitHub.
>
> A "secret talk"? What is that?
>

She gave a talk at the language summit to discuss what people thought of
the idea, and she had some fun making the topic a surprise so she could see
people's reactions. I don't think there's any secret beyond that.

IIRC, the general reaction was that it was definitely worth exploring, but
that it would be a lot of work and require solutions to a lot of problems
to make sure people's workflows weren't too impacted, so we'd need a much
more detailed proposal before any decision could be made.

-n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180520/85722810/attachment.html>

From barry at python.org  Sun May 20 13:42:28 2018
From: barry at python.org (Barry Warsaw)
Date: Sun, 20 May 2018 10:42:28 -0700
Subject: [python-committers] Comments on moving issues to GitHub
In-Reply-To: <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
 <005b303f-2055-1057-6434-65dda83fc85a@python.org>
 <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>
Message-ID: <58D4E1B2-C0BC-4315-B5DC-307C9BB75214@python.org>

On May 20, 2018, at 10:19, Nathaniel Smith <njs at pobox.com> wrote:
> 
> IIRC, the general reaction was that it was definitely worth exploring, but that it would be a lot of work and require solutions to a lot of problems to make sure people's workflows weren't too impacted, so we'd need a much more detailed proposal before any decision could be made.

Note too that Bryan Clark from GitHub, who I believe is a product manager there, was at the packaging mini-summit.  If/when we have a specific set of asks for the migration, we can reach out to him and see how they can help.  For example, I specifically asked about my favorite GitLab feature ?commit when CI passes? and it sounded like they were working on that.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180520/43018541/attachment.sig>

From brett at python.org  Sun May 20 15:03:59 2018
From: brett at python.org (Brett Cannon)
Date: Sun, 20 May 2018 12:03:59 -0700
Subject: [python-committers] Comments on moving issues to GitHub
In-Reply-To: <58D4E1B2-C0BC-4315-B5DC-307C9BB75214@python.org>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
 <005b303f-2055-1057-6434-65dda83fc85a@python.org>
 <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>
 <58D4E1B2-C0BC-4315-B5DC-307C9BB75214@python.org>
Message-ID: <CAP1=2W7LbAYq4OjARvPxip1do3hHaFLDBDZ6BqOuQe7mG9FEqQ@mail.gmail.com>

On Sun, 20 May 2018 at 10:43 Barry Warsaw <barry at python.org> wrote:

> On May 20, 2018, at 10:19, Nathaniel Smith <njs at pobox.com> wrote:
> >
> > IIRC, the general reaction was that it was definitely worth exploring,
> but that it would be a lot of work and require solutions to a lot of
> problems to make sure people's workflows weren't too impacted, so we'd need
> a much more detailed proposal before any decision could be made.
>
> Note too that Bryan Clark from GitHub, who I believe is a product manager
> there, was at the packaging mini-summit.  If/when we have a specific set of
> asks for the migration, we can reach out to him and see how they can help.
> For example, I specifically asked about my favorite GitLab feature ?commit
> when CI passes? and it sounded like they were working on that.
>

There was also general consensus that the state of maintenance for bpo is
subpar due to lack of staffing and that more people will need to come
forward to help maintain it if we decide to not transition to another issue
tracker like GitHub or GitLab.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180520/f6802981/attachment.html>

From nad at python.org  Sun May 20 18:34:29 2018
From: nad at python.org (Ned Deily)
Date: Sun, 20 May 2018 18:34:29 -0400
Subject: [python-committers] 3.7.0rc1 deadline extended two days to
 2018-05-23 AOE [Re: FINAL WEEK FOR 3.7.0 CHANGES!]
In-Reply-To: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
Message-ID: <916214BF-DA73-4380-9C3D-2479CCE3A537@python.org>

We are going to extend for 48 hours the deadline for 3.7.0rc1, that is, until 2018-05-23 23:59 AOE.  While we have made tremendous progress towards the release candidate over the past week especially with the huge efforts at the PyCon US Sprints, we still have some important issues to resolve.  A stumbling block has been the increased instability in the test suite, primarily in test_asyncio, which has caused delays in merging PRs due to intermittent failures in CI test runs and which has caused widespread buildbot failures.  Another factor is that this weekend and Monday are public holidays in many countries, something I did not take into account when drawing up the schedule.  (Note that next weekend is a major public holiday in the USA.)  So let's plan on using the extra two days to work through the remaining release blockers.

Thanks again!
--Ned

On May 15, 2018, at 07:51, Ned Deily <nad at python.org> wrote:
> This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your
> feature fixes, bug fixes, and documentation updates in before
> 2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days
> from now. We will then tag and produce the 3.7.0 release candidate.
> Our goal continues been to be to have no changes between the release
> candidate and final; AFTER NEXT WEEK'S RC1, CHANGES APPLIED TO THE 3.7
> BRANCH WILL BE RELEASED IN 3.7.1. Please double-check that there are
> no critical problems outstanding and that documentation for new
> features in 3.7 is complete (including NEWS and What's New items), and
> that 3.7 is getting exposure and tested with our various platorms and
> third-party distributions and applications. Those of us who are
> participating in the development sprints at PyCon US 2018 here in
> Cleveland can feel the excitement building as we work through the
> remaining issues, including completing the "What's New in 3.7"
> document and final feature documentation. (We wish you could all be
> here.)
> 
> As noted before, the ABI for 3.7.0 was frozen as of 3.7.0b3. You
> should now be treating the 3.7 branch as if it were already released
> and in maintenance mode. That means you should only push the kinds of
> changes that are appropriate for a maintenance release:
> non-ABI-changing bug and feature fixes and documentation updates. If
> you find a problem that requires an ABI-altering or other significant
> user-facing change (for example, something likely to introduce an
> incompatibility with existing users' code or require rebuilding of
> user extension modules), please make sure to set the b.p.o issue to
> "release blocker" priority and describe there why you feel the change
> is necessary. If you are reviewing PRs for 3.7 (and please do!), be on
> the lookout for and flag potential incompatibilities (we've all made
> them).
> 
> Thanks again for all of your hard work towards making 3.7.0 yet
> another great release - coming to a website near you on 06-15!
> 
> Release Managerly Yours,
> --Ned
> 
> https://www.python.org/dev/peps/pep-0537/

--
  Ned Deily
  nad at python.org -- []


From ncoghlan at gmail.com  Mon May 21 06:24:43 2018
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 21 May 2018 20:24:43 +1000
Subject: [python-committers] Comments on moving issues to GitHub
In-Reply-To: <CAP1=2W7LbAYq4OjARvPxip1do3hHaFLDBDZ6BqOuQe7mG9FEqQ@mail.gmail.com>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
 <005b303f-2055-1057-6434-65dda83fc85a@python.org>
 <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>
 <58D4E1B2-C0BC-4315-B5DC-307C9BB75214@python.org>
 <CAP1=2W7LbAYq4OjARvPxip1do3hHaFLDBDZ6BqOuQe7mG9FEqQ@mail.gmail.com>
Message-ID: <CADiSq7f-jsfYoCmaryPuHn4e=UQXy9yibbrLs6Z7WbYOVhhjLw@mail.gmail.com>

On 21 May 2018 at 05:03, Brett Cannon <brett at python.org> wrote:

>
>
> On Sun, 20 May 2018 at 10:43 Barry Warsaw <barry at python.org> wrote:
>
>> On May 20, 2018, at 10:19, Nathaniel Smith <njs at pobox.com> wrote:
>> >
>> > IIRC, the general reaction was that it was definitely worth exploring,
>> but that it would be a lot of work and require solutions to a lot of
>> problems to make sure people's workflows weren't too impacted, so we'd need
>> a much more detailed proposal before any decision could be made.
>>
>> Note too that Bryan Clark from GitHub, who I believe is a product manager
>> there, was at the packaging mini-summit.  If/when we have a specific set of
>> asks for the migration, we can reach out to him and see how they can help.
>> For example, I specifically asked about my favorite GitLab feature ?commit
>> when CI passes? and it sounded like they were working on that.
>>
>
> There was also general consensus that the state of maintenance for bpo is
> subpar due to lack of staffing and that more people will need to come
> forward to help maintain it if we decide to not transition to another issue
> tracker like GitHub or GitLab.
>

Right, one of the outcomes of the discussion at the Summit was that any
proposal to migrate to a different issue tracker would need to present a
clear statement of the *problems intended to be solved*, such that the
folks that would prefer to see us stay on our own issue tracker could
present a competing proposal to solve those problems without a wholesale
migration to another system.

Some examples of problems that would benefit from attention:

- fixing the SSL/TLS connectivity issues
- making the issue tracker usable on mobile devices
- ability to edit the description for issues that evolve over time, not
just the title
- improved editing support for comments (both in initial formatting, and in
being able to correct errors)
- REST API access to tracker data
- simplifying account creation (especially for folks that already have
GitHub accounts)
- rationalising the metadata fields by asking which ones actually see
significant use

Some examples of problems that in-place enhancement of the tracker would
inherently avoid, but a migration proposal would need to address:

- preservation of existing incoming links to issues
- figuring out which issues to migrate automatically (all of them? None of
them? Open issues only?)
- figuring out a new way to track PSF CLA signatures
- figuring out a replacement for the Experts Index integration into the
Roundup nosy list
- figuring out replacements for the custom metadata fields that we actually
use regularly
- meeting our original GitHub migration commitment to continue offering a
way of engaging with the core development process without requiring
accounts with any entity other than the PSF

It's far from being a foregone conclusion that migrating to a new issue
tracker will be the preferred answer, but there are also genuine problems
with the status quo that need to be addressed somehow.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180521/ef3b3998/attachment.html>

From barry at python.org  Mon May 21 14:26:47 2018
From: barry at python.org (Barry Warsaw)
Date: Mon, 21 May 2018 11:26:47 -0700
Subject: [python-committers] Comments on moving issues to GitHub
In-Reply-To: <CADiSq7f-jsfYoCmaryPuHn4e=UQXy9yibbrLs6Z7WbYOVhhjLw@mail.gmail.com>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
 <005b303f-2055-1057-6434-65dda83fc85a@python.org>
 <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>
 <58D4E1B2-C0BC-4315-B5DC-307C9BB75214@python.org>
 <CAP1=2W7LbAYq4OjARvPxip1do3hHaFLDBDZ6BqOuQe7mG9FEqQ@mail.gmail.com>
 <CADiSq7f-jsfYoCmaryPuHn4e=UQXy9yibbrLs6Z7WbYOVhhjLw@mail.gmail.com>
Message-ID: <563A3482-057F-48EF-9A11-265D4265D5B6@python.org>

On May 21, 2018, at 03:24, Nick Coghlan <ncoghlan at gmail.com> wrote:

> Right, one of the outcomes of the discussion at the Summit was that any proposal to migrate to a different issue tracker would need to present a clear statement of the *problems intended to be solved*, such that the folks that would prefer to see us stay on our own issue tracker could present a competing proposal to solve those problems without a wholesale migration to another system.

I?d like to see multiple PEPs for this migration.  The first would clearly outline discussion points that apply regardless of where we migrate to, or whether we migrate at all.  This would include lists of common use cases, the problems with the current system, the features we like (and regularly use!) in the current system, and a list of key points that can be compared against any proposed solution.

E.g. for this latter, let?s say one of the points is ?ability to easily ignore all discussions on tickets you don?t care about?.  You could imagine a row in a table that shows how any of the proposed solutions compare to what we have today.  You could color code this on a gradient, say from dark green (?it will be much better on system X?) to dark red (?it?ll be much more difficult on system Y?).

That would be one PEP, and it would be the baseline for making a decision.  Additional PEPs would make specific proposals, e.g. move to GH, stay on bpo as is, significantly invest in bpo, etc.  They?d reference the baseline PEP and include that table with the color coded rows.

Then perhaps after the decision is made, there would maybe be an implementation PEP describing the steps it will take to migrate, and the ETA.

Cheers,
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180521/9cfddbfb/attachment.sig>

From larry at hastings.org  Mon May 21 14:31:48 2018
From: larry at hastings.org (Larry Hastings)
Date: Mon, 21 May 2018 11:31:48 -0700
Subject: [python-committers] Comments on moving issues to GitHub
In-Reply-To: <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>
References: <CA+3bQGEbj+3p2doN3k44cbFskNhTVjHXOw60VXEwR9+GTm16cQ@mail.gmail.com>
 <005b303f-2055-1057-6434-65dda83fc85a@python.org>
 <CAPJVwBk4dGYPY01BLRyJ=b=1bVpDXUUo36z9r726B+OCO_G7Zw@mail.gmail.com>
Message-ID: <880b6e2e-d658-41d6-063e-0ec67b756505@hastings.org>



On 05/20/2018 10:19 AM, Nathaniel Smith wrote:
> On Sun, May 20, 2018, 03:18 Antoine Pitrou <antoine at python.org 
> <mailto:antoine at python.org>> wrote:
>
>
>     Le 19/05/2018 ? 02:10, Victor Stinner a ?crit?:
>     > Hi,
>     >
>     > I failed to get the microphone after Mariatta's secret talk about
>     > moving Python issues from bugs.python.org
>     <http://bugs.python.org> (Roundup) to GitHub.
>
>     A "secret talk"? What is that?
>
>
> She gave a talk at the language summit to discuss what people thought 
> of the idea, and she had some fun making the topic a surprise so she 
> could see people's reactions. I don't think there's any secret beyond 
> that.

You have it exactly.? She wanted us (the Language Summit organizers) to 
keep the talk title a secret until she could reveal it herself in front 
of the audience.? I suggested the official title on the schedule be 
"Mariatta's Topic Of Mystery" and we collectively went with that.? At 
this point nothing about it is a secret.


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180521/10f080d8/attachment.html>

From barry at python.org  Tue May 22 14:58:19 2018
From: barry at python.org (Barry Warsaw)
Date: Tue, 22 May 2018 11:58:19 -0700
Subject: [python-committers] A different way to focus discussions
Message-ID: <D34B336B-9A04-4ECB-B303-B8D5C7C0AECF@python.org>

[I think my other response got dropped, so apologies for any duplicates]

Guido van Rossum wrote:
> I wonder if it would make sense to require that for each PEP a new GitHub
> *repo* be created whose contents would just be a draft PEP and whose issue
> tracker and PR manager would be used to debate the PEP and propose specific
> changes.

I don't think I'd want to see tons of new PEP repos under the current `python` organization.  Maybe we should create a new organization for this experiment?

Also, since non-core devs can and do create PEPs, the permission management will be different than the normal repos.  Clearly the PEP authors should be owners of the individual repos, but they should probably also decide how merges happen, and who else can contribute to their repo.

It also means that PEP editors probably have an additional responsibility to create the PEP repo.

PEP 1's Discussions-To header can probably be co-opted for the URL to the GH repo.  Right now, that field is described as an email address, but it would be appropriate IMHO to also allow a URL for discussions.

> Thoughts? (We can dogfood this proposal too, if there's interest. :-)

I don't know whether this will help focus rambling PEP discussions.  I personally don't love the linearity of GH comments.  Threading is useful!

OTOH, it seems like a low-cost experiment to try so if there's a volunteer who wants to be the guinea pig, I'm fine with it.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180522/48d74acf/attachment.sig>

From antoine at python.org  Tue May 22 15:07:43 2018
From: antoine at python.org (Antoine Pitrou)
Date: Tue, 22 May 2018 21:07:43 +0200
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <D34B336B-9A04-4ECB-B303-B8D5C7C0AECF@python.org>
References: <D34B336B-9A04-4ECB-B303-B8D5C7C0AECF@python.org>
Message-ID: <850d1cf9-4f8c-c5c8-0c4b-d6b985dd4f5d@python.org>


Le 22/05/2018 ? 20:58, Barry Warsaw a ?crit?:
> 
>> Thoughts? (We can dogfood this proposal too, if there's interest. :-)
> 
> I don't know whether this will help focus rambling PEP discussions.  I personally don't love the linearity of GH comments.  Threading is useful!

What has become of the Discourse experiment?

Regards

Antoine.

From guido at python.org  Tue May 22 15:44:33 2018
From: guido at python.org (Guido van Rossum)
Date: Tue, 22 May 2018 12:44:33 -0700
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <D34B336B-9A04-4ECB-B303-B8D5C7C0AECF@python.org>
References: <D34B336B-9A04-4ECB-B303-B8D5C7C0AECF@python.org>
Message-ID: <CAP7+vJ+JDxfXye7OzwT1JsB-QqUvbtSD5yhKXA=aqSWzr6u5_g@mail.gmail.com>

On Tue, May 22, 2018 at 11:58 AM, Barry Warsaw <barry at python.org> wrote:

> [I think my other response got dropped, so apologies for any duplicates]
>
> Guido van Rossum wrote:
> > I wonder if it would make sense to require that for each PEP a new GitHub
> > *repo* be created whose contents would just be a draft PEP and whose
> issue
> > tracker and PR manager would be used to debate the PEP and propose
> specific
> > changes.
>
> I don't think I'd want to see tons of new PEP repos under the current
> `python` organization.  Maybe we should create a new organization for this
> experiment?
>

Hm, what's the cost of those extra repos? As long as they have consistent
names (e.g. pep-1234) they're easy to ignore right? Or does GitHub have a
quota of repos per org?


> Also, since non-core devs can and do create PEPs, the permission
> management will be different than the normal repos.  Clearly the PEP
> authors should be owners of the individual repos, but they should probably
> also decide how merges happen, and who else can contribute to their repo.
>
> It also means that PEP editors probably have an additional responsibility
> to create the PEP repo.
>

I was thinking of a workflow where the pep author initially creates the
repo under their own username and directs discussion there. Then when their
PEP is accepted (or rejected!) they can donate their repo to the python
org. I know such a thing is possible (we did it for the mypy and typeshed
repos).


> PEP 1's Discussions-To header can probably be co-opted for the URL to the
> GH repo.  Right now, that field is described as an email address, but it
> would be appropriate IMHO to also allow a URL for discussions.
>

Sure.

> Thoughts? (We can dogfood this proposal too, if there's interest. :-)
>
> I don't know whether this will help focus rambling PEP discussions.  I
> personally don't love the linearity of GH comments.  Threading is useful!
>

Ironically for me GitHub is less linear than email. It's easier to ask
people to open a new issue than it is to ask them to start a new thread. So
e.g. if a discussion starts about a survey of feature X in various
languages, when it veers off into a tutorial for a specific language that
could be a separate issue, and the meta-discussion on how the list of
languages should be selected could be made another issue.


> OTOH, it seems like a low-cost experiment to try so if there's a volunteer
> who wants to be the guinea pig, I'm fine with it.
>

I think Mark Shannon volunteered PEP 576 (though so far he hasn't created a
separate repo, he's just created a PR for the peps repo IIUC). I hope Nick
will also volunteer PEP 577 for this.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180522/442a06eb/attachment.html>

From vstinner at redhat.com  Tue May 22 15:57:16 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Tue, 22 May 2018 21:57:16 +0200
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <dc477b8f-e8e9-f2b2-71db-f193e7860087@python.org>
References: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
 <CAOMjWkkLqqYMbCiqhke+amJ87eVeWQhd=4pwJ1B5=7XNFmgCDg@mail.gmail.com>
 <CAP7+vJ+WR605chtapeRN+rp6NjQ4kOkbu1ZHkn4_hfPc-hvzTw@mail.gmail.com>
 <dc477b8f-e8e9-f2b2-71db-f193e7860087@python.org>
Message-ID: <CA+3bQGFpmsGUFT5TdqLQb=4DvwGWCHF4CLh9m6zrxAbDuf6iUg@mail.gmail.com>

Hi,

2018-05-19 7:45 GMT+02:00 Antoine Pitrou <antoine at python.org>:
> It would be *very* interesting if someone was willing to do some stats
> on PEPs over time: e.g. number of PEPs discussed every year, discussion
> length, number of discusssion participants.  I actually expect overall
> PEP activity to have gone down since the 2000s.

I counted the number of emails per PEP (sent to python-dev or
python-ideas) on the period Jan 2017 - April 2018:
https://mail.python.org/pipermail/python-committers/2018-April/005310.html

My script:
https://github.com/vstinner/misc/blob/master/python/parse_mailman_mbox_peps.py

I downloaded "[ Gzip'd Text 227 KB ]" links from
https://mail.python.org/pipermail/python-dev/ and
https://mail.python.org/pipermail/python-ideas/ and then uncompressed
them.

Victor

From brett at python.org  Tue May 22 16:06:33 2018
From: brett at python.org (Brett Cannon)
Date: Tue, 22 May 2018 13:06:33 -0700
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <850d1cf9-4f8c-c5c8-0c4b-d6b985dd4f5d@python.org>
References: <D34B336B-9A04-4ECB-B303-B8D5C7C0AECF@python.org>
 <850d1cf9-4f8c-c5c8-0c4b-d6b985dd4f5d@python.org>
Message-ID: <CAP1=2W4uA56uFOS6RhNtzEgQAEWXvN62KZz_aae5UKTOchzaSg@mail.gmail.com>

On Tue, 22 May 2018 at 12:07 Antoine Pitrou <antoine at python.org> wrote:

>
> Le 22/05/2018 ? 20:58, Barry Warsaw a ?crit :
> >
> >> Thoughts? (We can dogfood this proposal too, if there's interest. :-)
> >
> > I don't know whether this will help focus rambling PEP discussions.  I
> personally don't love the linearity of GH comments.  Threading is useful!
>
> What has become of the Discourse experiment?
>

A Discourse experiment was never started. If you mean Zulip it's still
going at python.zulipchat.com.


>
> Regards
>
> Antoine.
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180522/37410809/attachment.html>

From antoine at python.org  Tue May 22 16:09:50 2018
From: antoine at python.org (Antoine Pitrou)
Date: Tue, 22 May 2018 22:09:50 +0200
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <CAP1=2W4uA56uFOS6RhNtzEgQAEWXvN62KZz_aae5UKTOchzaSg@mail.gmail.com>
References: <D34B336B-9A04-4ECB-B303-B8D5C7C0AECF@python.org>
 <850d1cf9-4f8c-c5c8-0c4b-d6b985dd4f5d@python.org>
 <CAP1=2W4uA56uFOS6RhNtzEgQAEWXvN62KZz_aae5UKTOchzaSg@mail.gmail.com>
Message-ID: <522f0a00-d93a-9473-7990-0b3d34c44e7d@python.org>


Le 22/05/2018 ? 22:06, Brett Cannon a ?crit?:
> 
> 
> On Tue, 22 May 2018 at 12:07 Antoine Pitrou <antoine at python.org
> <mailto:antoine at python.org>> wrote:
> 
> 
>     Le 22/05/2018 ? 20:58, Barry Warsaw a ?crit?:
>     >
>     >> Thoughts? (We can dogfood this proposal too, if there's interest. :-)
>     >
>     > I don't know whether this will help focus rambling PEP
>     discussions.? I personally don't love the linearity of GH comments.?
>     Threading is useful!
> 
>     What has become of the Discourse experiment?
> 
> 
> A Discourse experiment was never started. If you mean Zulip it's still
> going at python.zulipchat.com <http://python.zulipchat.com>.

I meant this, whatever it was: https://discuss.python.org/ :-)

I don't think Zulip works for structured discussion.  I also find it
slightly less usable than I expected.

Regards

Antoine.

From barry at python.org  Tue May 22 16:52:21 2018
From: barry at python.org (Barry Warsaw)
Date: Tue, 22 May 2018 13:52:21 -0700
Subject: [python-committers] A different way to focus discussions
Message-ID: <DC64BE6D-8CF1-44CD-A563-84696F6E1EB1@python.org>

On May 22, 2018, at 12:44, Guido van Rossum <guido at python.org> wrote:
> 
> Hm, what's the cost of those extra repos? As long as they have consistent names (e.g. pep-1234) they're easy to ignore right? Or does GitHub have a quota of repos per org?

I think there is a quota for non-paying organizations, but I?m not sure.  I was just thinking about clutter on https://github.com/python but maybe it won?t be so bad with?

> I was thinking of a workflow where the pep author initially creates the repo under their own username and directs discussion there. Then when their PEP is accepted (or rejected!) they can donate their repo to the python org. I know such a thing is possible (we did it for the mypy and typeshed repos).

? +1!

> Ironically for me GitHub is less linear than email. It's easier to ask people to open a new issue than it is to ask them to start a new thread. So e.g. if a discussion starts about a survey of feature X in various languages, when it veers off into a tutorial for a specific language that could be a separate issue, and the meta-discussion on how the list of languages should be selected could be made another issue.

I see what you?re saying.  Yes, that could work if the PEP author is really diligent about shunting detours into new issues.  I?ve just found that within PRs or issues, the linearity can be quite difficult to follow.  (FWIW, IMHO, GitLab does better here, but that?s besides the point.)

> I think Mark Shannon volunteered PEP 576 (though so far he hasn't created a separate repo, he's just created a PR for the peps repo IIUC). I hope Nick will also volunteer PEP 577 for this.

+1

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180522/fa29993d/attachment.sig>

From vstinner at redhat.com  Tue May 22 17:50:48 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Tue, 22 May 2018 23:50:48 +0200
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
References: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
Message-ID: <CA+3bQGGUd1S39j_r3eHdZ0RnRkgPnSgt37=s+9xSNOzf-3_OXw@mail.gmail.com>

Hi,

2018-05-19 0:25 GMT+02:00 Guido van Rossum <guido at python.org>:
> Discussing PEPs on python-dev and python-ideas is clearly not scalable any
> more. (Even python-committers probably doesn't scale too well. :-)
>
> I wonder if it would make sense to require that for each PEP a new GitHub
> *repo* be created whose contents would just be a draft PEP and whose issue
> tracker and PR manager would be used to debate the PEP and propose specific
> changes.

Which problem do you want to solve? Reduce the number of emails per
month on python-ideas and python-dev? Reduce the number of messages
per PEP?

If the number of messages per PEP is the problem, I don't see how
replacing emails with GitHub would help. GitHub allows to add comments
on:

* commits
* issues
* pull requests

Anyone can open new issues and new pull requests. It might be harder
to follow discussions if they are occur at different parts of a single
repository.

I guess that your motivation is to prevent another PEP 572 mess.

IMHO the discussions on the PEP 572 became a mess because nobody
wanted to moderate the discussion. I asked on python-committers how to
calm down the discussion, but no action has been taken and the flow of
emails didn't stop.

A moderator can try to summarize the discussion or can ask to stop
discussing the PEP until the PEP is updated. For the PEP 572, it seems
like a few issues have been spotted in the PEP, but I don't recall an
email saying "these points must be fixed in the PEP, please wait until
the PEP is updated".

Will it be simpler to moderate discussions on GitHub? Or do you expect
that less people will go to GitHub, than on python-dev/python-ideas,
to discuss?

I like emails because it's plain text, it's easily readable on all
devices, there are archives (controlled by Python) which are readable
online, etc. I also like threads in emails. It's easy to see if I
missed messages. On GitHub, there is no markers of unread messages,
only notifications (well, there are also notifications with messages
;-)).

IMHO a PEP should summarize the most important discussed points.
Otherwise, each time that someone who don't know the PEP will read it,
the same discussion will restart from scratch. And I don't think that
PEP 572 made that.

> Thoughts? (We can dogfood this proposal too, if there's interest. :-)

Apart the PEP 572, I recalled that I have been annoyed by the fspath
protocol before a PEP has been written. I also recall that the
discussions stopped when I asked to wait until Brett (and someone
else, sorry I forgot) writes a PEP. For other PEPs, I think that the
volume of emails is acceptable.

I also like the idea of getting all PEPs in python-dev because it's
easier for me to be aware of currently discussed PEPs, even if I don't
read the discussions.

But it seems like I'm getting old and resist to the shiny new GitHub
which will solve all our issues ;-)

Victor

From donald at stufft.io  Tue May 22 17:58:39 2018
From: donald at stufft.io (Donald Stufft)
Date: Tue, 22 May 2018 17:58:39 -0400
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <CA+3bQGGUd1S39j_r3eHdZ0RnRkgPnSgt37=s+9xSNOzf-3_OXw@mail.gmail.com>
References: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
 <CA+3bQGGUd1S39j_r3eHdZ0RnRkgPnSgt37=s+9xSNOzf-3_OXw@mail.gmail.com>
Message-ID: <1C46B3CF-9B04-47CC-8290-2B776AB60DDF@stufft.io>


> On May 22, 2018, at 5:50 PM, Victor Stinner <vstinner at redhat.com> wrote:
> 
> IMHO the discussions on the PEP 572 became a mess because nobody
> wanted to moderate the discussion. I asked on python-committers how to
> calm down the discussion, but no action has been taken and the flow of
> emails didn't stop.

FWIW, I think this is a key thing? Mailing lists are not easily moderatable. There?s no way to pause discussion, redirect, etc besides generating *more* email (and the tooling to do it is lackluster, it?s pretty much just asking people to do something, and hope everyone complies). Fracturing the discussion amongst multiple repos is one way of handling that, another option is better tooling for moderation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180522/0a069d9b/attachment-0001.html>

From vstinner at redhat.com  Tue May 22 18:09:43 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Wed, 23 May 2018 00:09:43 +0200
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <1C46B3CF-9B04-47CC-8290-2B776AB60DDF@stufft.io>
References: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
 <CA+3bQGGUd1S39j_r3eHdZ0RnRkgPnSgt37=s+9xSNOzf-3_OXw@mail.gmail.com>
 <1C46B3CF-9B04-47CC-8290-2B776AB60DDF@stufft.io>
Message-ID: <CA+3bQGEvUkgVN94kPV4BHkutNOJ4a+Ryb2S0ZyDKFEiBgmED+w@mail.gmail.com>

2018-05-22 23:58 GMT+02:00 Donald Stufft <donald at stufft.io>:
> FWIW, I think this is a key thing? Mailing lists are not easily moderatable.
> There?s no way to pause discussion, redirect, etc besides generating *more*
> email (and the tooling to do it is lackluster, it?s pretty much just asking
> people to do something, and hope everyone complies). Fracturing the
> discussion amongst multiple repos is one way of handling that, another
> option is better tooling for moderation.

Another solution is to use Special Interest Group (SIG) mailing lists
to discuss PEPs.

distutils-sig accepted many PEPs which were never posted to
python-dev. Someone told me that PEPs are not posted to python-dev to
avoid restarting discussions from scratch ;-) I have been told when I
asked why TOML has been chosen instead of YAML for a PEP ;-) It was
maybe the PEP 518, I don't recall.

Do we need a new more specific mailing lists to discuss PEPs changing
the Python language?

Or a generic noisy-pep mailing lists for PEPs with high traffic? :-)

Victor

From guido at python.org  Tue May 22 20:21:53 2018
From: guido at python.org (Guido van Rossum)
Date: Tue, 22 May 2018 17:21:53 -0700
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <CA+3bQGGUd1S39j_r3eHdZ0RnRkgPnSgt37=s+9xSNOzf-3_OXw@mail.gmail.com>
References: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
 <CA+3bQGGUd1S39j_r3eHdZ0RnRkgPnSgt37=s+9xSNOzf-3_OXw@mail.gmail.com>
Message-ID: <CAP7+vJJUPeirLk2H46djViwtp21wg=yO-9Hq4ej7JxcBjUS1tw@mail.gmail.com>

On Tue, May 22, 2018 at 2:50 PM, Victor Stinner <vstinner at redhat.com> wrote:

> 2018-05-19 0:25 GMT+02:00 Guido van Rossum <guido at python.org>:
> > Discussing PEPs on python-dev and python-ideas is clearly not scalable
> any
> > more. (Even python-committers probably doesn't scale too well. :-)
> >
> > I wonder if it would make sense to require that for each PEP a new GitHub
> > *repo* be created whose contents would just be a draft PEP and whose
> issue
> > tracker and PR manager would be used to debate the PEP and propose
> specific
> > changes.
>
> Which problem do you want to solve? Reduce the number of emails per
> month on python-ideas and python-dev? Reduce the number of messages
> per PEP?
>

Both. The lists have gotten out of hand, and it's clear that many people
don't bother to read much of the discussion before posting an outraged
response to something they disagree with.


> If the number of messages per PEP is the problem, I don't see how
> replacing emails with GitHub would help. GitHub allows to add comments
> on:
>
> * commits
> * issues
> * pull requests
>
> Anyone can open new issues and new pull requests. It might be harder
> to follow discussions if they are occur at different parts of a single
> repository.
>

That's why I propose one repo per new PEP (or small cluster of related
PEPs). I agree that just having one PR per PEP in the peps repo would not
be an improvement.

The single repo puts all related discussion together (all issues in that
repo are about the same topic). This makes it easier for the PEP author to
read all traffic related to their PEP without forcing them to read all of
python-{ideas,dev}, while making it easier for others to create new threads
(no worries that the PEP author won't see your comment). It also lets the
PEP author effectively moderate the discussion (they can close issues and
even delete off-topic messages). It also makes it possible for interested
3rd parties to read all traffic related to a repo (just subscribe to the
repo).


> I guess that your motivation is to prevent another PEP 572 mess.
>
> IMHO the discussions on the PEP 572 became a mess because nobody
> wanted to moderate the discussion. I asked on python-committers how to
> calm down the discussion, but no action has been taken and the flow of
> emails didn't stop.
>

What action *can* you take on mailing lists like python-{ideas,dev}?


> A moderator can try to summarize the discussion or can ask to stop
> discussing the PEP until the PEP is updated. For the PEP 572, it seems
> like a few issues have been spotted in the PEP, but I don't recall an
> email saying "these points must be fixed in the PEP, please wait until
> the PEP is updated".
>
> Will it be simpler to moderate discussions on GitHub? Or do you expect
> that less people will go to GitHub, than on python-dev/python-ideas,
> to discuss?
>

GitHub has superior moderation abilities over our mailing lists, plus the
volume per topic (PEP or cluster of PEPs) is lower than the entire volume
of python-{ideas,dev}.

If it discourages drive-by comments by people not really invested in the
discussion but eager to show off their opinions, well, that's just an added
benefit.


> I like emails because it's plain text, it's easily readable on all
> devices, there are archives (controlled by Python) which are readable
> online, etc. I also like threads in emails. It's easy to see if I
> missed messages. On GitHub, there is no markers of unread messages,
> only notifications (well, there are also notifications with messages
> ;-)).
>

Maybe you should learn more about how to use GitHub? I find the experience
superior, and I routinely keep up with it on my phone.


> IMHO a PEP should summarize the most important discussed points.
> Otherwise, each time that someone who don't know the PEP will read it,
> the same discussion will restart from scratch. And I don't think that
> PEP 572 made that.
>

That's an unreasonable requirement when the discussion gets out of hand
like it got in that case. I hope to make it easier for the PEP author(s) to
keep up in part so they will have an easier time summarizing (and won't be
drawn into fruitless arguments as much by semi-troll comments).


> > Thoughts? (We can dogfood this proposal too, if there's interest. :-)
>
> Apart the PEP 572, I recalled that I have been annoyed by the fspath
> protocol before a PEP has been written. I also recall that the
> discussions stopped when I asked to wait until Brett (and someone
> else, sorry I forgot) writes a PEP. For other PEPs, I think that the
> volume of emails is acceptable.
>

That was a long time ago. Note that the cluster around PEP 550 was #2 on
your list, this was also fairly recent. I feel that traffic *in general*
has been up (I routinely see threads on python-ideas now where I think
"dumb idea" and mute the conversation).


> I also like the idea of getting all PEPs in python-dev because it's
> easier for me to be aware of currently discussed PEPs, even if I don't
> read the discussions.
>
> But it seems like I'm getting old and resist to the shiny new GitHub
> which will solve all our issues ;-)
>

To the contrary, *I* am getting old and I no longer have the energy to deal
with mailing lists. Since most PEPs pass through my inbox, I hope I still
have some say on how the discussion should be kept sane.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180522/1d474138/attachment.html>

From steve at pearwood.info  Tue May 22 21:06:20 2018
From: steve at pearwood.info (Steven D'Aprano)
Date: Wed, 23 May 2018 11:06:20 +1000
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <1C46B3CF-9B04-47CC-8290-2B776AB60DDF@stufft.io>
References: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
 <CA+3bQGGUd1S39j_r3eHdZ0RnRkgPnSgt37=s+9xSNOzf-3_OXw@mail.gmail.com>
 <1C46B3CF-9B04-47CC-8290-2B776AB60DDF@stufft.io>
Message-ID: <20180523010620.GJ12683@ando.pearwood.info>

On Tue, May 22, 2018 at 05:58:39PM -0400, Donald Stufft wrote:
> 
> > On May 22, 2018, at 5:50 PM, Victor Stinner <vstinner at redhat.com> wrote:
> > 
> > IMHO the discussions on the PEP 572 became a mess because nobody
> > wanted to moderate the discussion. I asked on python-committers how to
> > calm down the discussion, but no action has been taken and the flow of
> > emails didn't stop.
> 
> FWIW, I think this is a key thing? Mailing lists are not easily 
> moderatable.

*Unmoderated* mailing lists are not easily moderated.


> There?s no way to pause discussion, redirect, etc 

Does Github allow us to do these things? Not a rhetorical question.


> besides 
> generating *more* email (and the tooling to do it is lackluster, it?s 
> pretty much just asking people to do something, and hope everyone 
> complies). Fracturing the discussion amongst multiple repos is one way 
> of handling that, another option is better tooling for moderation. 

It is one thing to identify a problem, another thing to state that 
something is a solution to that problem, and a completely different 
thing to actually solve the problem. How does fracturing the discussion 
help?

One of the problems with PEP 372 was that the discussion was fractured 
across multiple threads on two mailing lists, leading to the same points 
being raised over and over again. (I think Chris was premature in taking 
it to Python-Dev while it was still be actively argued on Python-Ideas.)

It seems to me that "fracturing the discussion amongst multiple repos" 
will have the same effect: increase the total volume, not decrease it, 
as well as increasing the chances that salient points will be missed. Am 
I wrong?

As for better tooling for moderation, I asked earlier in this thread how 
moving to Github will help. What is this tooling?


I think the problem with PEP 572 was that it was a perfect storm of a 
number of factors:

- it relates to a feature simple enough that everyone has an opinion;

- the statement/expression divide ("assignment is NOT an expression,
  and that's a feature!") has been a point of distinction between
  Python and "the competition" for 20+ years;

- hence some very strong feelings;

- legitimate concerns over complexity and the assign/equals bug;

- bike-shedding and arguments over syntax;

- distraction over unrelated proposal to change the way scoping works
  inside classes;

- lots of newcomers to the community.

I count at least three discussions about this on Reddit:

https://redd.it/8fpv3f
https://redd.it/8fokpw
https://redd.it/8ex72p

Most PEPs don't get even one.

Trialling Github with a simpler, less emotional and bike-sheddy PEP may 
not demonstrate how well the process works when everyone and their pet 
cat has an opinion.



-- 
Steve

From willingc at gmail.com  Tue May 22 21:17:00 2018
From: willingc at gmail.com (Carol Willing)
Date: Tue, 22 May 2018 18:17:00 -0700
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <CAP7+vJJUPeirLk2H46djViwtp21wg=yO-9Hq4ej7JxcBjUS1tw@mail.gmail.com>
References: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
 <CA+3bQGGUd1S39j_r3eHdZ0RnRkgPnSgt37=s+9xSNOzf-3_OXw@mail.gmail.com>
 <CAP7+vJJUPeirLk2H46djViwtp21wg=yO-9Hq4ej7JxcBjUS1tw@mail.gmail.com>
Message-ID: <4BF1AB56-A0F2-4E71-B96D-40B898FFDA7A@gmail.com>



> On May 22, 2018, at 5:21 PM, Guido van Rossum <guido at python.org <mailto:guido at python.org>> wrote:
> 
> On Tue, May 22, 2018 at 2:50 PM, Victor Stinner <vstinner at redhat.com <mailto:vstinner at redhat.com>> wrote:
> 2018-05-19 0:25 GMT+02:00 Guido van Rossum <guido at python.org <mailto:guido at python.org>>:
> > Discussing PEPs on python-dev and python-ideas is clearly not scalable any
> > more. (Even python-committers probably doesn't scale too well. :-)
> >
> > I wonder if it would make sense to require that for each PEP a new GitHub
> > *repo* be created whose contents would just be a draft PEP and whose issue
> > tracker and PR manager would be used to debate the PEP and propose specific
> > changes.
> 
> Which problem do you want to solve? Reduce the number of emails per
> month on python-ideas and python-dev? Reduce the number of messages
> per PEP?
> 
> Both. The lists have gotten out of hand, and it's clear that many people don't bother to read much of the discussion before posting an outraged response to something they disagree with.
>  
> If the number of messages per PEP is the problem, I don't see how
> replacing emails with GitHub would help. GitHub allows to add comments
> on:
> 
> * commits
> * issues
> * pull requests
> 
> Anyone can open new issues and new pull requests. It might be harder
> to follow discussions if they are occur at different parts of a single
> repository.
> 
> That's why I propose one repo per new PEP (or small cluster of related PEPs). I agree that just having one PR per PEP in the peps repo would not be an improvement.
> 
> The single repo puts all related discussion together (all issues in that repo are about the same topic). This makes it easier for the PEP author to read all traffic related to their PEP without forcing them to read all of python-{ideas,dev}, while making it easier for others to create new threads (no worries that the PEP author won't see your comment). It also lets the PEP author effectively moderate the discussion (they can close issues and even delete off-topic messages). It also makes it possible for interested 3rd parties to read all traffic related to a repo (just subscribe to the repo).
>  
> I guess that your motivation is to prevent another PEP 572 mess.
> 
> IMHO the discussions on the PEP 572 became a mess because nobody
> wanted to moderate the discussion. I asked on python-committers how to
> calm down the discussion, but no action has been taken and the flow of
> emails didn't stop.
> 
> What action *can* you take on mailing lists like python-{ideas,dev}?
>  
> A moderator can try to summarize the discussion or can ask to stop
> discussing the PEP until the PEP is updated. For the PEP 572, it seems
> like a few issues have been spotted in the PEP, but I don't recall an
> email saying "these points must be fixed in the PEP, please wait until
> the PEP is updated".
> 
> Will it be simpler to moderate discussions on GitHub? Or do you expect
> that less people will go to GitHub, than on python-dev/python-ideas,
> to discuss?
> 
> GitHub has superior moderation abilities over our mailing lists, plus the volume per topic (PEP or cluster of PEPs) is lower than the entire volume of python-{ideas,dev}.
> 
> If it discourages drive-by comments by people not really invested in the discussion but eager to show off their opinions, well, that's just an added benefit.
>  
> I like emails because it's plain text, it's easily readable on all
> devices, there are archives (controlled by Python) which are readable
> online, etc. I also like threads in emails. It's easy to see if I
> missed messages. On GitHub, there is no markers of unread messages,
> only notifications (well, there are also notifications with messages
> ;-)).
> 
> Maybe you should learn more about how to use GitHub? I find the experience superior, and I routinely keep up with it on my phone.
>  
> IMHO a PEP should summarize the most important discussed points.
> Otherwise, each time that someone who don't know the PEP will read it,
> the same discussion will restart from scratch. And I don't think that
> PEP 572 made that.
> 
> That's an unreasonable requirement when the discussion gets out of hand like it got in that case. I hope to make it easier for the PEP author(s) to keep up in part so they will have an easier time summarizing (and won't be drawn into fruitless arguments as much by semi-troll comments).
>  
> > Thoughts? (We can dogfood this proposal too, if there's interest. :-)
> 
> Apart the PEP 572, I recalled that I have been annoyed by the fspath
> protocol before a PEP has been written. I also recall that the
> discussions stopped when I asked to wait until Brett (and someone
> else, sorry I forgot) writes a PEP. For other PEPs, I think that the
> volume of emails is acceptable.
> 
> That was a long time ago. Note that the cluster around PEP 550 was #2 on your list, this was also fairly recent. I feel that traffic *in general* has been up (I routinely see threads on python-ideas now where I think "dumb idea" and mute the conversation).
>  
> I also like the idea of getting all PEPs in python-dev because it's
> easier for me to be aware of currently discussed PEPs, even if I don't
> read the discussions.
> 
> But it seems like I'm getting old and resist to the shiny new GitHub
> which will solve all our issues ;-)
> 
> To the contrary, *I* am getting old and I no longer have the energy to deal with mailing lists. Since most PEPs pass through my inbox, I hope I still have some say on how the discussion should be kept sane.
> 
> -- 
> --Guido van Rossum (python.org/~guido <http://python.org/~guido>)
> _______________________________________________
> python-committers mailing list
> python-committers at python.org <mailto:python-committers at python.org>
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/

FWIW, I'm going to throw out some negotiation tips since most of what is happening before a PEP is approved or rejected is negotiation of some form. Ideally, I would like to add these to the dev guide in a checklist section for Feedback on PEPs. These are all research driven from Harvard.


One-text principle (All parties work from the same document.) Setting ground rules for feedback on the text such as:

- What is wrong with this draft as it is presented now?

- Do you have important interests that this draft does not adequately address? Which ones? Why are they important?

- What else seems wrong or is missing from the draft? Why are these things important?

- Do you have other ideas for improvement? What are your reasons for suggesting these items? What key unmet interests do they address?

- Do you have other ideas about how conflicting interests can be creatively and fairly resolved?

- Understanding why you would like this particular interest met, but given that it has become clear that it is in direct conflict with other's interests, why should meeting your interest take priority over meeting theirs? What standards or fair process might we apply to deciding this?


Keeping emotions from boiling over

1. Focus on your physical reaction.
2. Listen to what your counterpart is saying
3. Show you have heard them
4. Show some empathy.
5. Find out more.
6. Take a break.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180522/abd23869/attachment.html>

From storchaka at gmail.com  Wed May 23 07:45:23 2018
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Wed, 23 May 2018 14:45:23 +0300
Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
In-Reply-To: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
Message-ID: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com>

15.05.18 14:51, Ned Deily ????:
> This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your
> feature fixes, bug fixes, and documentation updates in before
> 2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days
> from now. We will then tag and produce the 3.7.0 release candidate.
> Our goal continues been to be to have no changes between the release
> candidate and final; AFTER NEXT WEEK'S RC1, CHANGES APPLIED TO THE 3.7
> BRANCH WILL BE RELEASED IN 3.7.1. Please double-check that there are
> no critical problems outstanding and that documentation for new
> features in 3.7 is complete (including NEWS and What's New items), and
> that 3.7 is getting exposure and tested with our various platorms and
> third-party distributions and applications. Those of us who are
> participating in the development sprints at PyCon US 2018 here in
> Cleveland can feel the excitement building as we work through the
> remaining issues, including completing the "What's New in 3.7"
> document and final feature documentation. (We wish you could all be
> here.)

Is it possible to add yet one beta instead?

CI was broken for few latest days, tests are not passed on my computer 
still (and fail on some buildbots), updating What's New exposed new 
features which need additional testing (and maybe fixing or reverting), 
and I'm not comfortable about some changes which would be harder to fix 
after the release.

From antoine at python.org  Wed May 23 07:47:57 2018
From: antoine at python.org (Antoine Pitrou)
Date: Wed, 23 May 2018 13:47:57 +0200
Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
In-Reply-To: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
 <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com>
Message-ID: <64f85804-e21d-c85d-d6f4-ba3a58cd231c@python.org>


Also there's https://bugs.python.org/issue33612 which appears quite
critical.

Regards

Antoine.


Le 23/05/2018 ? 13:45, Serhiy Storchaka a ?crit?:
> 15.05.18 14:51, Ned Deily ????:
>> This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your
>> feature fixes, bug fixes, and documentation updates in before
>> 2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days
>> from now. We will then tag and produce the 3.7.0 release candidate.
>> Our goal continues been to be to have no changes between the release
>> candidate and final; AFTER NEXT WEEK'S RC1, CHANGES APPLIED TO THE 3.7
>> BRANCH WILL BE RELEASED IN 3.7.1. Please double-check that there are
>> no critical problems outstanding and that documentation for new
>> features in 3.7 is complete (including NEWS and What's New items), and
>> that 3.7 is getting exposure and tested with our various platorms and
>> third-party distributions and applications. Those of us who are
>> participating in the development sprints at PyCon US 2018 here in
>> Cleveland can feel the excitement building as we work through the
>> remaining issues, including completing the "What's New in 3.7"
>> document and final feature documentation. (We wish you could all be
>> here.)
> 
> Is it possible to add yet one beta instead?
> 
> CI was broken for few latest days, tests are not passed on my computer 
> still (and fail on some buildbots), updating What's New exposed new 
> features which need additional testing (and maybe fixing or reverting), 
> and I'm not comfortable about some changes which would be harder to fix 
> after the release.
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
> 

From vstinner at redhat.com  Wed May 23 07:59:45 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Wed, 23 May 2018 13:59:45 +0200
Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
In-Reply-To: <64f85804-e21d-c85d-d6f4-ba3a58cd231c@python.org>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
 <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com>
 <64f85804-e21d-c85d-d6f4-ba3a58cd231c@python.org>
Message-ID: <CA+3bQGGxY5=8PRF_WpW2BJsdg3giq+cFRviScVj9_HZ05VLrzQ@mail.gmail.com>

2018-05-23 13:47 GMT+02:00 Antoine Pitrou <antoine at python.org>:
> Also there's https://bugs.python.org/issue33612 which appears quite
> critical.

Can someone please have a look at my socketserver change?
https://github.com/python/cpython/pull/6911

bpo-31151 changed ForkingMixIn and bpo-31233 changed ThreadingMixIn to
block on server_closer() for processes/threads. I propose to add a new
opt-in option to get the Python 3.6 behaviour. The old behaviour was
wrong, but I expect that some people rely on it."
https://bugs.python.org/issue33540

Victor

From vstinner at redhat.com  Wed May 23 08:16:14 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Wed, 23 May 2018 14:16:14 +0200
Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
In-Reply-To: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
 <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com>
Message-ID: <CA+3bQGEs5B+nLkQaDLPnf3yz-KJ4gObQO=k_Nu1eO6VUvD9_Dg@mail.gmail.com>

2018-05-23 13:45 GMT+02:00 Serhiy Storchaka <storchaka at gmail.com>:
> CI was broken for few latest days, tests are not passed on my computer still
> (and fail on some buildbots), (...)

I looked at buildbots and I confirm that many of the 3.x buildbots are red:

AMD64 FreeBSD 10.x Shared 3.x
AMD64 Windows8.1 Non-Debug 3.x
ARMv7 Ubuntu 3.x
PPC64 Fedora 3.x
s390x RHEL 3.x
x86 Gentoo Installed with X 3.x
x86 Gentoo Refleaks 3.x
AMD64 Windows8.1 Refleaks 3.x

Victor

From vstinner at redhat.com  Wed May 23 08:21:38 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Wed, 23 May 2018 14:21:38 +0200
Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
In-Reply-To: <CA+3bQGEs5B+nLkQaDLPnf3yz-KJ4gObQO=k_Nu1eO6VUvD9_Dg@mail.gmail.com>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
 <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com>
 <CA+3bQGEs5B+nLkQaDLPnf3yz-KJ4gObQO=k_Nu1eO6VUvD9_Dg@mail.gmail.com>
Message-ID: <CA+3bQGGWtvXLgFp_LrL73ELwD9vH+t1r6SwU38G201O8a7Q9uA@mail.gmail.com>

Ah, Python doesn't compile on Windows anymore :-)
https://bugs.python.org/issue33614

Victor

2018-05-23 14:16 GMT+02:00 Victor Stinner <vstinner at redhat.com>:
> 2018-05-23 13:45 GMT+02:00 Serhiy Storchaka <storchaka at gmail.com>:
>> CI was broken for few latest days, tests are not passed on my computer still
>> (and fail on some buildbots), (...)
>
> I looked at buildbots and I confirm that many of the 3.x buildbots are red:
>
> AMD64 FreeBSD 10.x Shared 3.x
> AMD64 Windows8.1 Non-Debug 3.x
> ARMv7 Ubuntu 3.x
> PPC64 Fedora 3.x
> s390x RHEL 3.x
> x86 Gentoo Installed with X 3.x
> x86 Gentoo Refleaks 3.x
> AMD64 Windows8.1 Refleaks 3.x
>
> Victor

From nad at python.org  Wed May 23 09:13:53 2018
From: nad at python.org (Ned Deily)
Date: Wed, 23 May 2018 09:13:53 -0400
Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
In-Reply-To: <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
 <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com>
Message-ID: <BB5AA469-781C-442B-9F98-3365286A9043@python.org>

On May 23, 2018, at 07:45, Serhiy Storchaka <storchaka at gmail.com> wrote:
> 15.05.18 14:51, Ned Deily ????:
>> This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your
>> feature fixes, bug fixes, and documentation updates in before
>> 2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days
>> from now. We will then tag and produce the 3.7.0 release candidate.
>> Our goal continues been to be to have no changes between the release
>> candidate and final; AFTER NEXT WEEK'S RC1, CHANGES APPLIED TO THE 3.7
>> BRANCH WILL BE RELEASED IN 3.7.1. Please double-check that there are
>> no critical problems outstanding and that documentation for new
>> features in 3.7 is complete (including NEWS and What's New items), and
>> that 3.7 is getting exposure and tested with our various platorms and
>> third-party distributions and applications. Those of us who are
>> participating in the development sprints at PyCon US 2018 here in
>> Cleveland can feel the excitement building as we work through the
>> remaining issues, including completing the "What's New in 3.7"
>> document and final feature documentation. (We wish you could all be
>> here.)
> Is it possible to add yet one beta instead?
> 
> CI was broken for few latest days, tests are not passed on my computer still (and fail on some buildbots), updating What's New exposed new features which need additional testing (and maybe fixing or reverting), and I'm not comfortable about some changes which would be harder to fix after the release.

it is possible but there's no point in doing either another beta or a release candidate until we understand and address the current blocking issues, like the major buildbot failures.  We have another 24 hours until rc1 was planned to be tagged.  Let's keep working on the known issues and we will make a decision then.

--
  Ned Deily
  nad at python.org -- []


From ethan at stoneleaf.us  Wed May 23 13:13:27 2018
From: ethan at stoneleaf.us (Ethan Furman)
Date: Wed, 23 May 2018 10:13:27 -0700
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <20180523010620.GJ12683@ando.pearwood.info>
References: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
 <CA+3bQGGUd1S39j_r3eHdZ0RnRkgPnSgt37=s+9xSNOzf-3_OXw@mail.gmail.com>
 <1C46B3CF-9B04-47CC-8290-2B776AB60DDF@stufft.io>
 <20180523010620.GJ12683@ando.pearwood.info>
Message-ID: <5B05A137.3080903@stoneleaf.us>

On 05/22/2018 06:06 PM, Steven D'Aprano wrote:
> On Tue, May 22, 2018 at 05:58:39PM -0400, Donald Stufft wrote:
>>> On May 22, 2018, at 5:50 PM, Victor Stinner wrote:

> One of the problems with PEP 572 was that the discussion was fractured
> across multiple threads on two mailing lists, leading to the same points
> being raised over and over again. (I think Chris was premature in taking
> it to Python-Dev while it was still be actively argued on Python-Ideas.)

I have to take the blame for that.  It looked to me like the PEP was as good as it was going to get on -ideas so I 
encouraged Chris to move it over to -dev.

--
~Ethan~

From nad at python.org  Thu May 24 03:23:59 2018
From: nad at python.org (Ned Deily)
Date: Thu, 24 May 2018 03:23:59 -0400
Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
In-Reply-To: <BB5AA469-781C-442B-9F98-3365286A9043@python.org>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
 <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com>
 <BB5AA469-781C-442B-9F98-3365286A9043@python.org>
Message-ID: <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org>

On May 23, 2018, at 09:13, Ned Deily <nad at python.org> wrote:
> On May 23, 2018, at 07:45, Serhiy Storchaka <storchaka at gmail.com> wrote:
>> Is it possible to add yet one beta instead?
>> CI was broken for few latest days, tests are not passed on my computer still (and fail on some buildbots), updating What's New exposed new features which need additional testing (and maybe fixing or reverting), and I'm not comfortable about some changes which would be harder to fix after the release.
> it is possible but there's no point in doing either another beta or a release candidate until we understand and address the current blocking issues, like the major buildbot failures.  We have another 24 hours until rc1 was planned to be tagged.  Let's keep working on the known issues and we will make a decision then.

An update: thanks to a lot of effort over the past day by a number of
people (including Victor, Serhiy, Christian, Zach, and others I'm sure
I'm forgetting - my apologies), we have addressed all of the "release
blocker" issues and all but one of the persistent failures on the 3.7
stable buildbots. We should have the couple of remaining "deferred
blockers" including the remaining stable buildbots in green status by
later today. At that point, we will be ready to tag 3.7.0rc1 and begin
producing the release candidate artifacts.

So this *is* really your last chance: if you know of any true releasing
blocking issues for 3.7.0, you have about 12 more hours to log it in
the bug tracker as a "release blocker". I'll send out an email once we
start the release manufacturing. Any merges to the 3.7 branch after
that will be released in 3.7.1 which we tentatively are planning to
ship sometime before the end of July (< 2018-07-31). If you do find a
critical problem in 3.7.0rc1 that you think needs to be fixed in 3.7.0,
please merge a fix into 3.7 (and other appropriate branches), leave the
issue open and marked as "release blocker", and add a note why you
think the fix needs to be cherry-picked into 3.7.0.

More later today!

--Ned

P.S. To address a few of the earlier comments on this thread:

Antoine: > Also there's https://bugs.python.org/issue33612 which
appears quite critical.

Resolved

Victor: > Can someone please have a look at my socketserver change?

Reviewed and merged

Victor: > I looked at buildbots and I confirm that many of the 3.x
buildbots are red:

Yes, but it's the 3.7 buildbots that are of interest now, not the 3.x
ones :) And, as noted above, I believe we have cleaned up (or will
shortly) the remaining 3.7 stable buildbot failures. Coincidentally,
we've also fixed some of the 3.x (master -> 3.8) buildbots.

Victor: > Ah, Python doesn't compile on Windows anymore :-)

Stale files on one of the Windows buildbots -> cleaned up

--
  Ned Deily
  nad at python.org -- []


From nad at python.org  Thu May 24 10:35:41 2018
From: nad at python.org (Ned Deily)
Date: Thu, 24 May 2018 10:35:41 -0400
Subject: [python-committers] [Python-Dev] FINAL WEEK FOR 3.7.0 CHANGES!
In-Reply-To: <CA+3bQGFqf4-wEiu1wrYcaVHjJMtDtm+a-XZeg1pPbR_UJQ91Kg@mail.gmail.com>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
 <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com>
 <BB5AA469-781C-442B-9F98-3365286A9043@python.org>
 <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org>
 <CA+3bQGFqf4-wEiu1wrYcaVHjJMtDtm+a-XZeg1pPbR_UJQ91Kg@mail.gmail.com>
Message-ID: <D1A7B0B5-C18F-42DF-A859-0000724E115B@python.org>

On May 24, 2018, at 07:26, Victor Stinner <vstinner at redhat.com> wrote:
> 2018-05-24 9:23 GMT+02:00 Ned Deily <nad at python.org>:
>> Any merges to the 3.7 branch after
>> that will be released in 3.7.1 which we tentatively are planning to
>> ship sometime before the end of July (< 2018-07-31).
> I recall that Python 3.6.0 was full of bugs, some functions like
> os.waitpid() on Windows (if I recall correctly) were completely
> broken.
> 
> We can do our best to test as much as possible, hope that more and
> more people use the "nightly" Python version to run their CI, but we
> always miss bugs. We always get the most testers when the final x.y.0
> version is released.
> 
> Why waiting two months to release bugfixes?

We're not planning on waiting two months.  First, 3.7.0 final is not
planned to release until 2018-06-15; if necessary, there could be one
or more emergency bug fixes in it.  Second, "before the end of July
(< 2018-07-31)" does not mean we have to wait until the end of July.
If necessary, it could be near the beginning of the month,
so closer to two weeks after the release.  Right now, our focus
should be on getting high-quality 3.7.0rc1 and 3.7.0 final releases
out there to our users and then we can focus on what comes next.

Getting close!

--
  Ned Deily
  nad at python.org -- []


From storchaka at gmail.com  Thu May 24 11:35:44 2018
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Thu, 24 May 2018 18:35:44 +0300
Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
In-Reply-To: <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
 <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com>
 <BB5AA469-781C-442B-9F98-3365286A9043@python.org>
 <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org>
Message-ID: <df16adf2-725a-8f05-f94b-a6439d3c5c85@gmail.com>

24.05.18 10:23, Ned Deily ????:
> So this *is* really your last chance: if you know of any true releasing
> blocking issues for 3.7.0, you have about 12 more hours to log it in
> the bug tracker as a "release blocker". I'll send out an email once we
> start the release manufacturing. Any merges to the 3.7 branch after
> that will be released in 3.7.1 which we tentatively are planning to
> ship sometime before the end of July (< 2018-07-31). If you do find a
> critical problem in 3.7.0rc1 that you think needs to be fixed in 3.7.0,
> please merge a fix into 3.7 (and other appropriate branches), leave the
> issue open and marked as "release blocker", and add a note why you
> think the fix needs to be cherry-picked into 3.7.0.

I have doubts about two issues. I feel the responsibility for them 
because I had the opportunity to solve them before, but I lost it.

1. Changes in the AST. Few third-party projects was broken by it and 
already are fixed. I suppose yet few projects will be changed after 3.7 
be released. It is interesting that IPython was broken in different way 
than other projects. It was needed to reintroduce the docstring in the 
list of statements, effectively reverting the 3.7 change. IPython allows 
to enter several statements at prompt, and therefore it compiles them 
with the 'exec' mode instead of 'single' as the CPython REPL and IDLE 
shell. Currently CPython doesn't allow you to paste arbitrary script 
like the following:

if a:
 ??? b
if c:
 ??? d

You need to add an empty line between top-level complex statements. If 
one time CPython will add support of pasting several statements without 
empty lines between, it might need to add the same hack as IPython. I 
afraid that we might be needed to change AST again, in 3.7.1 or in 3.8.0.

2. Pickle support in typing is not perfect. I was going to fix it (I had 
almost ready code), but lost a chance of doing this before. It can be 
changed in 3.7.1, but this means that pickles of some derived typing 
types created in 3.7.0 will be not compatible with future versions (may 
be 3.7.1 will not break compatibility, but it will be broken in future 
because we will not specially supported compatibility with 3.7.0).

There is third issue, related to NetBSD, but it is less important.

I think two weeks will be enough for fixing these issues, but not at rc1 
stage.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180524/8a1dcb06/attachment.html>

From nad at python.org  Thu May 24 12:02:48 2018
From: nad at python.org (Ned Deily)
Date: Thu, 24 May 2018 12:02:48 -0400
Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
In-Reply-To: <df16adf2-725a-8f05-f94b-a6439d3c5c85@gmail.com>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
 <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com>
 <BB5AA469-781C-442B-9F98-3365286A9043@python.org>
 <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org>
 <df16adf2-725a-8f05-f94b-a6439d3c5c85@gmail.com>
Message-ID: <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org>

On May 24, 2018, at 11:35, Serhiy Storchaka <storchaka at gmail.com> wrote:
> I have doubts about two issues. I feel the responsibility for them because I had the opportunity to solve them before, but I lost it.
[...]

Serhiy, what are the bugs.python.org issue numbers for these?  Are they marked as "release blocker"?

--
  Ned Deily
  nad at python.org -- []


From levkivskyi at gmail.com  Thu May 24 12:25:51 2018
From: levkivskyi at gmail.com (Ivan Levkivskyi)
Date: Thu, 24 May 2018 12:25:51 -0400
Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
In-Reply-To: <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
 <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com>
 <BB5AA469-781C-442B-9F98-3365286A9043@python.org>
 <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org>
 <df16adf2-725a-8f05-f94b-a6439d3c5c85@gmail.com>
 <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org>
Message-ID: <CAOMjWknCk1qWS9XCm4xxn9V-=JK-tL9KtTfM=CtJrgUccjxCpA@mail.gmail.com>

> 2. Pickle support in typing is not perfect. I was going to fix it (I had
almost ready code), but lost a chance of doing this before. It can be
changed in 3.7.1, but this means that pickles of some derived typing types
created in 3.7.0 will be not compatible with future versions (may be 3.7.1
will not break compatibility, but it will be broken in future because we
will not specially supported compatibility with 3.7.0).

I think I had fixed this one. At least the examples reported on typing
tracker are now fixed.
Do you have some other examples that still fail?

--
Ivan



On 24 May 2018 at 12:02, Ned Deily <nad at python.org> wrote:

> On May 24, 2018, at 11:35, Serhiy Storchaka <storchaka at gmail.com> wrote:
> > I have doubts about two issues. I feel the responsibility for them
> because I had the opportunity to solve them before, but I lost it.
> [...]
>
> Serhiy, what are the bugs.python.org issue numbers for these?  Are they
> marked as "release blocker"?
>
> --
>   Ned Deily
>   nad at python.org -- []
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180524/d9b3a244/attachment.html>

From storchaka at gmail.com  Thu May 24 12:26:27 2018
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Thu, 24 May 2018 19:26:27 +0300
Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
In-Reply-To: <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
 <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com>
 <BB5AA469-781C-442B-9F98-3365286A9043@python.org>
 <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org>
 <df16adf2-725a-8f05-f94b-a6439d3c5c85@gmail.com>
 <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org>
Message-ID: <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com>

24.05.18 19:02, Ned Deily ????:
> On May 24, 2018, at 11:35, Serhiy Storchaka <storchaka at gmail.com> wrote:
>> I have doubts about two issues. I feel the responsibility for them because I had the opportunity to solve them before, but I lost it.
> [...]
>
> Serhiy, what are the bugs.python.org issue numbers for these?  Are they marked as "release blocker"?

For docstring in AST: https://bugs.python.org/issue32911

Inada's patch looked complex (actually it mostly restored the code 
before his previous change). We didn't know about IPython and we decided 
that it is not worth to change this code at this stage (after beta2). 
And definitely it will be later to do this after rc1.

For pickling of typing types: https://bugs.python.org/issue32873

Ivan fixed cases supported before 3.7. They now are backward and forward 
compatible. But cases not supported before 3.7 (like List[int]) now 
produce fragile pickles.


From levkivskyi at gmail.com  Thu May 24 12:42:27 2018
From: levkivskyi at gmail.com (Ivan Levkivskyi)
Date: Thu, 24 May 2018 12:42:27 -0400
Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
In-Reply-To: <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
 <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com>
 <BB5AA469-781C-442B-9F98-3365286A9043@python.org>
 <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org>
 <df16adf2-725a-8f05-f94b-a6439d3c5c85@gmail.com>
 <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org>
 <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com>
Message-ID: <CAOMjWk=KWeRBKS_1whJSXLcYnXKC6S9_mrvPsbbzg9VJHBBpaA@mail.gmail.com>

> But cases not supported before 3.7 (like List[int]) now produce fragile
pickles.

List[int] pickled in 3.7 can't be un-pickled in 3.6, but I wouldn't worry
too much about this because it never worked in 3.6.
I remember you proposed using __getitem__ in __reduce__, but I am not sure
it is a better way, although it will fix the above problem.

I don't think this one is a blocker and we can move this discussion back to
b.p.o., unless you have some particular concerns.

The AST one however looks more serious.

--
Ivan



On 24 May 2018 at 12:26, Serhiy Storchaka <storchaka at gmail.com> wrote:

> 24.05.18 19:02, Ned Deily ????:
>
>> On May 24, 2018, at 11:35, Serhiy Storchaka <storchaka at gmail.com> wrote:
>>
>>> I have doubts about two issues. I feel the responsibility for them
>>> because I had the opportunity to solve them before, but I lost it.
>>>
>> [...]
>>
>> Serhiy, what are the bugs.python.org issue numbers for these?  Are they
>> marked as "release blocker"?
>>
>
> For docstring in AST: https://bugs.python.org/issue32911
>
> Inada's patch looked complex (actually it mostly restored the code before
> his previous change). We didn't know about IPython and we decided that it
> is not worth to change this code at this stage (after beta2). And
> definitely it will be later to do this after rc1.
>
> For pickling of typing types: https://bugs.python.org/issue32873
>
> Ivan fixed cases supported before 3.7. They now are backward and forward
> compatible. But cases not supported before 3.7 (like List[int]) now produce
> fragile pickles.
>
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180524/bb69e654/attachment-0001.html>

From brett at python.org  Thu May 24 12:54:19 2018
From: brett at python.org (Brett Cannon)
Date: Thu, 24 May 2018 09:54:19 -0700
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <522f0a00-d93a-9473-7990-0b3d34c44e7d@python.org>
References: <D34B336B-9A04-4ECB-B303-B8D5C7C0AECF@python.org>
 <850d1cf9-4f8c-c5c8-0c4b-d6b985dd4f5d@python.org>
 <CAP1=2W4uA56uFOS6RhNtzEgQAEWXvN62KZz_aae5UKTOchzaSg@mail.gmail.com>
 <522f0a00-d93a-9473-7990-0b3d34c44e7d@python.org>
Message-ID: <CAP1=2W5GHRptaFSEShOi0XhzzXamC6qtHTXgR-AGtk317NfJNA@mail.gmail.com>

On Tue, 22 May 2018 at 13:10 Antoine Pitrou <antoine at python.org> wrote:

>
> Le 22/05/2018 ? 22:06, Brett Cannon a ?crit :
> >
> >
> > On Tue, 22 May 2018 at 12:07 Antoine Pitrou <antoine at python.org
> > <mailto:antoine at python.org>> wrote:
> >
> >
> >     Le 22/05/2018 ? 20:58, Barry Warsaw a ?crit :
> >     >
> >     >> Thoughts? (We can dogfood this proposal too, if there's interest.
> :-)
> >     >
> >     > I don't know whether this will help focus rambling PEP
> >     discussions.  I personally don't love the linearity of GH comments.
> >     Threading is useful!
> >
> >     What has become of the Discourse experiment?
> >
> >
> > A Discourse experiment was never started. If you mean Zulip it's still
> > going at python.zulipchat.com <http://python.zulipchat.com>.
>
> I meant this, whatever it was: https://discuss.python.org/ :-)
>

Ah, that never went anywhere because it was just a short experiment that
the overload-sig did. If people wanted to do a serious experiment with it
then we can discuss it over on core-workflow.


>
> I don't think Zulip works for structured discussion.  I also find it
> slightly less usable than I expected.
>

Why specifically? Do you still find IRC more usable? Just trying to
understand how Discourse would be different enough to solve the issue
you're having.

-Brett


>
> Regards
>
> Antoine.
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180524/7f254d43/attachment.html>

From brett at python.org  Thu May 24 13:01:30 2018
From: brett at python.org (Brett Cannon)
Date: Thu, 24 May 2018 10:01:30 -0700
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <20180523010620.GJ12683@ando.pearwood.info>
References: <CAP7+vJJ-BUjHjtDShnEKBWDe=vW_RwqfEZH4Um6yxcp=oAJAHw@mail.gmail.com>
 <CA+3bQGGUd1S39j_r3eHdZ0RnRkgPnSgt37=s+9xSNOzf-3_OXw@mail.gmail.com>
 <1C46B3CF-9B04-47CC-8290-2B776AB60DDF@stufft.io>
 <20180523010620.GJ12683@ando.pearwood.info>
Message-ID: <CAP1=2W7A3Hj3bJ_z3oixOHCAL=FC+yHCQPps5MHzFX-i1AcMjg@mail.gmail.com>

On Tue, 22 May 2018 at 18:07 Steven D'Aprano <steve at pearwood.info> wrote:

> On Tue, May 22, 2018 at 05:58:39PM -0400, Donald Stufft wrote:
> >
> > > On May 22, 2018, at 5:50 PM, Victor Stinner <vstinner at redhat.com>
> wrote:
> > >
> > > IMHO the discussions on the PEP 572 became a mess because nobody
> > > wanted to moderate the discussion. I asked on python-committers how to
> > > calm down the discussion, but no action has been taken and the flow of
> > > emails didn't stop.
> >
> > FWIW, I think this is a key thing? Mailing lists are not easily
> > moderatable.
>
> *Unmoderated* mailing lists are not easily moderated.
>
>
> > There?s no way to pause discussion, redirect, etc
>
> Does Github allow us to do these things? Not a rhetorical question.
>

Locking/pausing issues and PRs yes (both temporarily and permanently),
redirection not specifically beyond cross-referencing to another issue/PR
in a comment.

-Brett


>
>
> > besides
> > generating *more* email (and the tooling to do it is lackluster, it?s
> > pretty much just asking people to do something, and hope everyone
> > complies). Fracturing the discussion amongst multiple repos is one way
> > of handling that, another option is better tooling for moderation.
>
> It is one thing to identify a problem, another thing to state that
> something is a solution to that problem, and a completely different
> thing to actually solve the problem. How does fracturing the discussion
> help?
>
> One of the problems with PEP 372 was that the discussion was fractured
> across multiple threads on two mailing lists, leading to the same points
> being raised over and over again. (I think Chris was premature in taking
> it to Python-Dev while it was still be actively argued on Python-Ideas.)
>
> It seems to me that "fracturing the discussion amongst multiple repos"
> will have the same effect: increase the total volume, not decrease it,
> as well as increasing the chances that salient points will be missed. Am
> I wrong?
>
> As for better tooling for moderation, I asked earlier in this thread how
> moving to Github will help. What is this tooling?
>
>
> I think the problem with PEP 572 was that it was a perfect storm of a
> number of factors:
>
> - it relates to a feature simple enough that everyone has an opinion;
>
> - the statement/expression divide ("assignment is NOT an expression,
>   and that's a feature!") has been a point of distinction between
>   Python and "the competition" for 20+ years;
>
> - hence some very strong feelings;
>
> - legitimate concerns over complexity and the assign/equals bug;
>
> - bike-shedding and arguments over syntax;
>
> - distraction over unrelated proposal to change the way scoping works
>   inside classes;
>
> - lots of newcomers to the community.
>
> I count at least three discussions about this on Reddit:
>
> https://redd.it/8fpv3f
> https://redd.it/8fokpw
> https://redd.it/8ex72p
>
> Most PEPs don't get even one.
>
> Trialling Github with a simpler, less emotional and bike-sheddy PEP may
> not demonstrate how well the process works when everyone and their pet
> cat has an opinion.
>
>
>
> --
> Steve
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180524/41e7bea9/attachment.html>

From nad at python.org  Thu May 24 13:08:19 2018
From: nad at python.org (Ned Deily)
Date: Thu, 24 May 2018 13:08:19 -0400
Subject: [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!
In-Reply-To: <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
 <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com>
 <BB5AA469-781C-442B-9F98-3365286A9043@python.org>
 <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org>
 <df16adf2-725a-8f05-f94b-a6439d3c5c85@gmail.com>
 <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org>
 <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com>
Message-ID: <E036A817-BE1E-48F7-AB0E-8AA2DD486206@python.org>

On May 24, 2018, at 12:26, Serhiy Storchaka <storchaka at gmail.com> wrote:
> 24.05.18 19:02, Ned Deily ????:
>> On May 24, 2018, at 11:35, Serhiy Storchaka <storchaka at gmail.com> wrote:
>>> I have doubts about two issues. I feel the responsibility for them because I had the opportunity to solve them before, but I lost it.
>> [...]
>> 
>> Serhiy, what are the bugs.python.org issue numbers for these?  Are they marked as "release blocker"?
> For docstring in AST: https://bugs.python.org/issue32911
> 
> Inada's patch looked complex (actually it mostly restored the code before his previous change). We didn't know about IPython and we decided that it is not worth to change this code at this stage (after beta2). And definitely it will be later to do this after rc1.

We have had many discussions about this issue earlier and, while there were arguments made for more than one approach, I believe we reached agreement that this was a deliberate incompatibility that we and our users could live with.  The issue has been closed since 2018-03-18.  At some point, we need to move on.  However, if additional exposure downstream has identified significant new problems, then the issue should be re-opened and a specific proposal made.  BTW, do we know what the iPython folks think about this?  But there still seems to be disagreements about whether anything needs to be changed.  As I commented yesterday, I *really* don't want to keep revisiting this but I am not going to make a technical call.  Without an open "release blocker" issue, though, nothing is going to change for 3.7.0rc1.  If you (or anyone else) feels strongly enough about it, you should re-open the issue now and make it as a "release blocker" and we should discuss the implications and possible plans of action in the issue.

> For pickling of typing types: https://bugs.python.org/issue32873
> 
> Ivan fixed cases supported before 3.7. They now are backward and forward compatible. But cases not supported before 3.7 (like List[int]) now produce fragile pickles.

That issue was closed by Ivan and there have been no comments on it since 2018-04-04.  I'll defer to his recent reply in this thread.

--
  Ned Deily
  nad at python.org -- []


From brett at python.org  Thu May 24 12:56:01 2018
From: brett at python.org (Brett Cannon)
Date: Thu, 24 May 2018 09:56:01 -0700
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <DC64BE6D-8CF1-44CD-A563-84696F6E1EB1@python.org>
References: <DC64BE6D-8CF1-44CD-A563-84696F6E1EB1@python.org>
Message-ID: <CAP1=2W4ZaR9K2zhR6wOUOV0APaKSRKgrYm8EYcTtL_jzRGFB=Q@mail.gmail.com>

On Tue, 22 May 2018 at 13:52 Barry Warsaw <barry at python.org> wrote:

> On May 22, 2018, at 12:44, Guido van Rossum <guido at python.org> wrote:
> >
> > Hm, what's the cost of those extra repos? As long as they have
> consistent names (e.g. pep-1234) they're easy to ignore right? Or does
> GitHub have a quota of repos per org?
>
> I think there is a quota for non-paying organizations, but I?m not sure.
> I was just thinking about clutter on https://github.com/python but maybe
> it won?t be so bad with?
>

I don't think there's a quota.

-Brett


>
> > I was thinking of a workflow where the pep author initially creates the
> repo under their own username and directs discussion there. Then when their
> PEP is accepted (or rejected!) they can donate their repo to the python
> org. I know such a thing is possible (we did it for the mypy and typeshed
> repos).
>
> ? +1!
>
> > Ironically for me GitHub is less linear than email. It's easier to ask
> people to open a new issue than it is to ask them to start a new thread. So
> e.g. if a discussion starts about a survey of feature X in various
> languages, when it veers off into a tutorial for a specific language that
> could be a separate issue, and the meta-discussion on how the list of
> languages should be selected could be made another issue.
>
> I see what you?re saying.  Yes, that could work if the PEP author is
> really diligent about shunting detours into new issues.  I?ve just found
> that within PRs or issues, the linearity can be quite difficult to follow.
> (FWIW, IMHO, GitLab does better here, but that?s besides the point.)
>

You do realize you are very quickly volunteering to propose to write the
PEP for moving issues to GitLab, right? ;)


>
> > I think Mark Shannon volunteered PEP 576 (though so far he hasn't
> created a separate repo, he's just created a PR for the peps repo IIUC). I
> hope Nick will also volunteer PEP 577 for this.
>
> +1
>
> -Barry
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180524/a5eac04f/attachment.html>

From antoine at python.org  Thu May 24 13:45:35 2018
From: antoine at python.org (Antoine Pitrou)
Date: Thu, 24 May 2018 19:45:35 +0200
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <CAP1=2W5GHRptaFSEShOi0XhzzXamC6qtHTXgR-AGtk317NfJNA@mail.gmail.com>
References: <D34B336B-9A04-4ECB-B303-B8D5C7C0AECF@python.org>
 <850d1cf9-4f8c-c5c8-0c4b-d6b985dd4f5d@python.org>
 <CAP1=2W4uA56uFOS6RhNtzEgQAEWXvN62KZz_aae5UKTOchzaSg@mail.gmail.com>
 <522f0a00-d93a-9473-7990-0b3d34c44e7d@python.org>
 <CAP1=2W5GHRptaFSEShOi0XhzzXamC6qtHTXgR-AGtk317NfJNA@mail.gmail.com>
Message-ID: <178e4a00-184f-2622-6f98-c187ab9c178a@python.org>


Le 24/05/2018 ? 18:54, Brett Cannon a ?crit?:
> 
>     I don't think Zulip works for structured discussion.? I also find it
>     slightly less usable than I expected.
> 
> Why specifically? Do you still find IRC more usable?

Um, no.  But I find Zulip's way of grouping discussions by day *then* by
topic makes things a bit confusing and not very easy to follow.  It
seems designed for people who log in every day.

> Just trying to
> understand how Discourse would be different enough to solve the issue
> you're having.

Which issue exactly?  Zulip is decent as a chat system.  It wouldn't
really work for PEP discussions, IMO.  That's why I asked about Discourse.

Regards

Antoine.

From larry at hastings.org  Thu May 24 13:46:27 2018
From: larry at hastings.org (Larry Hastings)
Date: Thu, 24 May 2018 10:46:27 -0700
Subject: [python-committers] Marking issues as "Release Blocker" priority
 (was Re: FINAL WEEK FOR 3.7.0 CHANGES!)
In-Reply-To: <E036A817-BE1E-48F7-AB0E-8AA2DD486206@python.org>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
 <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com>
 <BB5AA469-781C-442B-9F98-3365286A9043@python.org>
 <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org>
 <df16adf2-725a-8f05-f94b-a6439d3c5c85@gmail.com>
 <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org>
 <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com>
 <E036A817-BE1E-48F7-AB0E-8AA2DD486206@python.org>
Message-ID: <5ddfa702-f3a0-a9ac-41b5-b89ff3b1b274@hastings.org>



On 05/24/2018 10:08 AM, Ned Deily wrote:
> If you (or anyone else) feels strongly enough about it, you should re-open the issue now and make it as a "release blocker" and we should discuss the implications and possible plans of action in the issue.

About that.? According to the Python Dev Guide:

    Whether a bug is a *release blocker* for the current release
    schedule is decided by the release manager. Triagers may recommend
    this priority and should add the release manager to the nosy list.

    https://devguide.python.org/triaging/#priority

Of course, a particular release manager (e.g. Ned here) can change the 
policy for their releases.? But by default, unless you're the release 
manager for release X, you should not mark issues as "Release Blocker" 
for release X.? This seems like a sensible policy to me, and effective 
immediately I'm going to hold to this policy for my releases (3.4 and 3.5).


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180524/93b1befe/attachment.html>

From brett at python.org  Thu May 24 14:02:45 2018
From: brett at python.org (Brett Cannon)
Date: Thu, 24 May 2018 11:02:45 -0700
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <178e4a00-184f-2622-6f98-c187ab9c178a@python.org>
References: <D34B336B-9A04-4ECB-B303-B8D5C7C0AECF@python.org>
 <850d1cf9-4f8c-c5c8-0c4b-d6b985dd4f5d@python.org>
 <CAP1=2W4uA56uFOS6RhNtzEgQAEWXvN62KZz_aae5UKTOchzaSg@mail.gmail.com>
 <522f0a00-d93a-9473-7990-0b3d34c44e7d@python.org>
 <CAP1=2W5GHRptaFSEShOi0XhzzXamC6qtHTXgR-AGtk317NfJNA@mail.gmail.com>
 <178e4a00-184f-2622-6f98-c187ab9c178a@python.org>
Message-ID: <CAP1=2W5mzFhof3O7nc-Rp8rgac+03Lbz6eh97TLu+=CH49Jsag@mail.gmail.com>

On Thu, 24 May 2018 at 10:45 Antoine Pitrou <antoine at python.org> wrote:

>
> Le 24/05/2018 ? 18:54, Brett Cannon a ?crit :
> >
> >     I don't think Zulip works for structured discussion.  I also find it
> >     slightly less usable than I expected.
> >
> > Why specifically? Do you still find IRC more usable?
>
> Um, no.  But I find Zulip's way of grouping discussions by day *then* by
> topic makes things a bit confusing and not very easy to follow.  It
> seems designed for people who log in every day.
>

Ah, you must be reading Zulip through "All Messages". I personally read
each topic individually by pressing "n" to navigate through each topic with
an unread message, otherwise I too lose too much context.


>
> > Just trying to
> > understand how Discourse would be different enough to solve the issue
> > you're having.
>
> Which issue exactly?  Zulip is decent as a chat system.  It wouldn't
> really work for PEP discussions, IMO.  That's why I asked about Discourse.
>

Fair enough. Would you want a PEPs section and then some naming convention
per thread to denote which PEP a thread is about?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180524/bf384c2a/attachment-0001.html>

From antoine at python.org  Thu May 24 14:05:09 2018
From: antoine at python.org (Antoine Pitrou)
Date: Thu, 24 May 2018 20:05:09 +0200
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <CAP1=2W5mzFhof3O7nc-Rp8rgac+03Lbz6eh97TLu+=CH49Jsag@mail.gmail.com>
References: <D34B336B-9A04-4ECB-B303-B8D5C7C0AECF@python.org>
 <850d1cf9-4f8c-c5c8-0c4b-d6b985dd4f5d@python.org>
 <CAP1=2W4uA56uFOS6RhNtzEgQAEWXvN62KZz_aae5UKTOchzaSg@mail.gmail.com>
 <522f0a00-d93a-9473-7990-0b3d34c44e7d@python.org>
 <CAP1=2W5GHRptaFSEShOi0XhzzXamC6qtHTXgR-AGtk317NfJNA@mail.gmail.com>
 <178e4a00-184f-2622-6f98-c187ab9c178a@python.org>
 <CAP1=2W5mzFhof3O7nc-Rp8rgac+03Lbz6eh97TLu+=CH49Jsag@mail.gmail.com>
Message-ID: <6fff1d0e-b076-a289-d050-3c28b223b0dd@python.org>


Le 24/05/2018 ? 20:02, Brett Cannon a ?crit?:
>     > Just trying to
>     > understand how Discourse would be different enough to solve the issue
>     > you're having.
> 
>     Which issue exactly?? Zulip is decent as a chat system.? It wouldn't
>     really work for PEP discussions, IMO.? That's why I asked about
>     Discourse.
> 
> Fair enough. Would you want a PEPs section and then some naming
> convention per thread to denote which PEP a thread is about?

That could work.  I'm not acquainted with Discourse, are there subsections?

From donald at stufft.io  Thu May 24 14:07:48 2018
From: donald at stufft.io (Donald Stufft)
Date: Thu, 24 May 2018 14:07:48 -0400
Subject: [python-committers] A different way to focus discussions
In-Reply-To: <6fff1d0e-b076-a289-d050-3c28b223b0dd@python.org>
References: <D34B336B-9A04-4ECB-B303-B8D5C7C0AECF@python.org>
 <850d1cf9-4f8c-c5c8-0c4b-d6b985dd4f5d@python.org>
 <CAP1=2W4uA56uFOS6RhNtzEgQAEWXvN62KZz_aae5UKTOchzaSg@mail.gmail.com>
 <522f0a00-d93a-9473-7990-0b3d34c44e7d@python.org>
 <CAP1=2W5GHRptaFSEShOi0XhzzXamC6qtHTXgR-AGtk317NfJNA@mail.gmail.com>
 <178e4a00-184f-2622-6f98-c187ab9c178a@python.org>
 <CAP1=2W5mzFhof3O7nc-Rp8rgac+03Lbz6eh97TLu+=CH49Jsag@mail.gmail.com>
 <6fff1d0e-b076-a289-d050-3c28b223b0dd@python.org>
Message-ID: <7906134F-0D17-4157-BB01-58349394B330@stufft.io>



> On May 24, 2018, at 2:05 PM, Antoine Pitrou <antoine at python.org> wrote:
> 
> 
> Le 24/05/2018 ? 20:02, Brett Cannon a ?crit :
>>> Just trying to
>>> understand how Discourse would be different enough to solve the issue
>>> you're having.
>> 
>>    Which issue exactly?  Zulip is decent as a chat system.  It wouldn't
>>    really work for PEP discussions, IMO.  That's why I asked about
>>    Discourse.
>> 
>> Fair enough. Would you want a PEPs section and then some naming
>> convention per thread to denote which PEP a thread is about?
> 
> That could work.  I'm not acquainted with Discourse, are there subsections?


Yes, you can nest sections as deeply as you want, but the sections are typically static (I mean they can change over time, but making one per PEP would be a weird use of discourse).


From nad at python.org  Thu May 24 14:09:01 2018
From: nad at python.org (Ned Deily)
Date: Thu, 24 May 2018 14:09:01 -0400
Subject: [python-committers] Marking issues as "Release Blocker"
 priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!)
In-Reply-To: <5ddfa702-f3a0-a9ac-41b5-b89ff3b1b274@hastings.org>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
 <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com>
 <BB5AA469-781C-442B-9F98-3365286A9043@python.org>
 <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org>
 <df16adf2-725a-8f05-f94b-a6439d3c5c85@gmail.com>
 <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org>
 <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com>
 <E036A817-BE1E-48F7-AB0E-8AA2DD486206@python.org>
 <5ddfa702-f3a0-a9ac-41b5-b89ff3b1b274@hastings.org>
Message-ID: <FDDFEC1B-6BC9-48CB-830B-E60F02F497F3@python.org>

On May 24, 2018, at 13:46, Larry Hastings <larry at hastings.org> wrote:
> On 05/24/2018 10:08 AM, Ned Deily wrote:
>> If you (or anyone else) feels strongly enough about it, you should re-open the issue now and make it as a "release blocker" and we should discuss the implications and possible plans of action in the issue.
> 
> About that.  According to the Python Dev Guide:
> Whether a bug is a *release blocker* for the current release schedule is decided by the release manager. Triagers may recommend this priority and should add the release manager to the nosy list.
> 
> https://devguide.python.org/triaging/#priority
> Of course, a particular release manager (e.g. Ned here) can change the policy for their releases.  But by default, unless you're the release manager for release X, you should not mark issues as "Release Blocker" for release X.  This seems like a sensible policy to me, and effective immediately I'm going to hold to this policy for my releases (3.4 and 3.5).

I think we're reading the same words a bit differently.  There's no question that the Release Manager makes the ultimate call whether an issue remains a "Release Blocker" or not.  But it seems to me that the safest and most reliable way to ensure that the Release Manager makes that decision is by having a triager or submitter *provisionally* set the priority to "release blocker".  It is then on the Release Manager's radar to accept or reject.  I think that policy is totally in the spirit of the Dev Guide wording but I'm fine with other release managers accepting differing interpretations for their releases ;)

As for 3.6.x and 3.7.x, I would much prefer to have too many proposed "release blocker" issues than to have too few.  And the sooner they are reported, the better.

--
  Ned Deily
  nad at python.org -- []


From doko at ubuntu.com  Thu May 24 17:04:02 2018
From: doko at ubuntu.com (Matthias Klose)
Date: Thu, 24 May 2018 23:04:02 +0200
Subject: [python-committers] Marking issues as "Release Blocker"
 priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!)
In-Reply-To: <FDDFEC1B-6BC9-48CB-830B-E60F02F497F3@python.org>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
 <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com>
 <BB5AA469-781C-442B-9F98-3365286A9043@python.org>
 <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org>
 <df16adf2-725a-8f05-f94b-a6439d3c5c85@gmail.com>
 <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org>
 <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com>
 <E036A817-BE1E-48F7-AB0E-8AA2DD486206@python.org>
 <5ddfa702-f3a0-a9ac-41b5-b89ff3b1b274@hastings.org>
 <FDDFEC1B-6BC9-48CB-830B-E60F02F497F3@python.org>
Message-ID: <888c6cd4-3245-45ab-8222-f4d2e98cb516@ubuntu.com>

On 24.05.2018 20:09, Ned Deily wrote:
> On May 24, 2018, at 13:46, Larry Hastings <larry at hastings.org> wrote:
>> On 05/24/2018 10:08 AM, Ned Deily wrote:
>>> If you (or anyone else) feels strongly enough about it, you should re-open the issue now and make it as a "release blocker" and we should discuss the implications and possible plans of action in the issue.
>>
>> About that.  According to the Python Dev Guide:
>> Whether a bug is a *release blocker* for the current release schedule is decided by the release manager. Triagers may recommend this priority and should add the release manager to the nosy list.
>>
>> https://devguide.python.org/triaging/#priority
>> Of course, a particular release manager (e.g. Ned here) can change the policy for their releases.  But by default, unless you're the release manager for release X, you should not mark issues as "Release Blocker" for release X.  This seems like a sensible policy to me, and effective immediately I'm going to hold to this policy for my releases (3.4 and 3.5).
> 
> I think we're reading the same words a bit differently.  There's no question that the Release Manager makes the ultimate call whether an issue remains a "Release Blocker" or not.  But it seems to me that the safest and most reliable way to ensure that the Release Manager makes that decision is by having a triager or submitter *provisionally* set the priority to "release blocker".  It is then on the Release Manager's radar to accept or reject.  I think that policy is totally in the spirit of the Dev Guide wording but I'm fine with other release managers accepting differing interpretations for their releases ;)
> 
> As for 3.6.x and 3.7.x, I would much prefer to have too many proposed "release blocker" issues than to have too few.  And the sooner they are reported, the better.

Ned's interpretation is the one I'm using for submitting such issues (maybe not
twelve hours before a final release). What other documented ways would you have
to get the attention of a release manager.

Having different interpretations depending on the release manager doesn't look
very practically.

Matthias

From nad at python.org  Fri May 25 01:33:43 2018
From: nad at python.org (Ned Deily)
Date: Fri, 25 May 2018 01:33:43 -0400
Subject: [python-committers] 3.7.0rc1 Delayed [was] FINAL WEEK FOR 3.7.0
 CHANGES!
In-Reply-To: <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
 <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com>
 <BB5AA469-781C-442B-9F98-3365286A9043@python.org>
 <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org>
Message-ID: <45628031-F42C-4B3B-8B1C-F3BE3B49BBA6@python.org>

On May 24, 2018, at 03:23, Ned Deily <nad at python.org> wrote:
> On May 23, 2018, at 09:13, Ned Deily <nad at python.org> wrote:
>> On May 23, 2018, at 07:45, Serhiy Storchaka <storchaka at gmail.com> wrote:
>>> Is it possible to add yet one beta instead?
>>> CI was broken for few latest days, tests are not passed on my computer still (and fail on some buildbots), updating What's New exposed new features which need additional testing (and maybe fixing or reverting), and I'm not comfortable about some changes which would be harder to fix after the release.
>> it is possible but there's no point in doing either another beta or a release candidate until we understand and address the current blocking issues, like the major buildbot failures.  We have another 24 hours until rc1 was planned to be tagged.  Let's keep working on the known issues and we will make a decision then.
> An update: thanks to a lot of effort over the past day by a number of
> people (including Victor, Serhiy, Christian, Zach, and others I'm sure
> I'm forgetting - my apologies), we have addressed all of the "release
> blocker" issues and all but one of the persistent failures on the 3.7
> stable buildbots. We should have the couple of remaining "deferred
> blockers" including the remaining stable buildbots in green status by
> later today. At that point, we will be ready to tag 3.7.0rc1 and begin
> producing the release candidate artifacts.

Further update: some good news and some changes.

The good news is that we have resolutions for all of the previous release and deferred blockers.  Thanks to a number of people for continuing to help get the remaining stable buildbot issues taken care of along with some lingering bugs. 

The not-quite-as-good news is that we have had more discussions about some unexpected incompatibilities that have shown up with downstream user testing with the AST docstrings changes in place (see bpo-32911).  We have had some previous discussions about the expected user impact and, earlier in the beta phase, I encouraged us to stay the course with the feature as implemented.  But I am now persuaded that we owe it to our users to take one more look at this to make sure we do not force them to make changes for 3.7 and then once again for 3.8.  More details are in the bug tracker issue; I strongly encourage those of us who have been involved with this to "vote" there on the proposal to either (A) proceed with the release of the current implementation in 3.7.0 or (B) revert the feature in 3.7.0 and retarget for 3.8.  Should the consensus be to revert (B), we will plan to have one more fast-track beta release (b5) prior to the release candidate, in order to allow downstream users to test their projects with the removal.  PLEASE, keep the discussion about this on the bug tracker (and not here!) and keep it brief so we can move forward quickly.  Because of the upcoming 3-day holiday weekend in some countries, I have set Tue 2018-05-29 18:00 UTC as a cutoff for "voting" but, if a clear consensus emerges earlier, we will likely cut the discussion short.  So chime in now on the bug tracker if you have a stake in this issue.

https://bugs.python.org/issue32911

This does mean that yesterday's "last chance" has been extended a bit, at most a few days.  I will let you know as soon as we have made a decision about the feature and will provide updated 3.7.0 schedule info at that time.

--Ned

--
  Ned Deily
  nad at python.org -- []


From ncoghlan at gmail.com  Fri May 25 10:52:43 2018
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 26 May 2018 00:52:43 +1000
Subject: [python-committers] Marking issues as "Release Blocker"
 priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!)
In-Reply-To: <FDDFEC1B-6BC9-48CB-830B-E60F02F497F3@python.org>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
 <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com>
 <BB5AA469-781C-442B-9F98-3365286A9043@python.org>
 <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org>
 <df16adf2-725a-8f05-f94b-a6439d3c5c85@gmail.com>
 <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org>
 <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com>
 <E036A817-BE1E-48F7-AB0E-8AA2DD486206@python.org>
 <5ddfa702-f3a0-a9ac-41b5-b89ff3b1b274@hastings.org>
 <FDDFEC1B-6BC9-48CB-830B-E60F02F497F3@python.org>
Message-ID: <CADiSq7fOjTzST42=RxOFLuMAfzWYbYXrkG5Vz-86xQ5D_Q2NCQ@mail.gmail.com>

On 25 May 2018 at 04:09, Ned Deily <nad at python.org> wrote:

> On May 24, 2018, at 13:46, Larry Hastings <larry at hastings.org> wrote:
> > On 05/24/2018 10:08 AM, Ned Deily wrote:
> >> If you (or anyone else) feels strongly enough about it, you should
> re-open the issue now and make it as a "release blocker" and we should
> discuss the implications and possible plans of action in the issue.
> >
> > About that.  According to the Python Dev Guide:
> > Whether a bug is a *release blocker* for the current release schedule is
> decided by the release manager. Triagers may recommend this priority and
> should add the release manager to the nosy list.
> >
> > https://devguide.python.org/triaging/#priority
> > Of course, a particular release manager (e.g. Ned here) can change the
> policy for their releases.  But by default, unless you're the release
> manager for release X, you should not mark issues as "Release Blocker" for
> release X.  This seems like a sensible policy to me, and effective
> immediately I'm going to hold to this policy for my releases (3.4 and 3.5).
>
> I think we're reading the same words a bit differently.  There's no
> question that the Release Manager makes the ultimate call whether an issue
> remains a "Release Blocker" or not.  But it seems to me that the safest and
> most reliable way to ensure that the Release Manager makes that decision is
> by having a triager or submitter *provisionally* set the priority to
> "release blocker".  It is then on the Release Manager's radar to accept or
> reject.  I think that policy is totally in the spirit of the Dev Guide
> wording but I'm fine with other release managers accepting differing
> interpretations for their releases ;)
>

Right, my interpretation of that policy has been that to request RM review
of a potential blocker I should:

- set the status to Release Blocker
- add the relevant RM to the nosy list
- add a comment explaining why I think it might be a release blocker and
asking the RM to take a look it at

The RM then makes their decision by either commenting to say they're
accepting the issue as a blocker, bumping it down to deferred blocker (if
they don't think it's a blocker *yet*), or else bumping it down to one of
the non-blocking priorities (if they don't agree that it's a blocker at
all).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180526/f137068b/attachment.html>

From brett at python.org  Fri May 25 11:26:11 2018
From: brett at python.org (Brett Cannon)
Date: Fri, 25 May 2018 08:26:11 -0700
Subject: [python-committers] Marking issues as "Release Blocker"
 priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!)
In-Reply-To: <CADiSq7fOjTzST42=RxOFLuMAfzWYbYXrkG5Vz-86xQ5D_Q2NCQ@mail.gmail.com>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
 <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com>
 <BB5AA469-781C-442B-9F98-3365286A9043@python.org>
 <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org>
 <df16adf2-725a-8f05-f94b-a6439d3c5c85@gmail.com>
 <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org>
 <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com>
 <E036A817-BE1E-48F7-AB0E-8AA2DD486206@python.org>
 <5ddfa702-f3a0-a9ac-41b5-b89ff3b1b274@hastings.org>
 <FDDFEC1B-6BC9-48CB-830B-E60F02F497F3@python.org>
 <CADiSq7fOjTzST42=RxOFLuMAfzWYbYXrkG5Vz-86xQ5D_Q2NCQ@mail.gmail.com>
Message-ID: <CAP1=2W7-O_qBct=uDTCpczRVz+poYSKGq2t0YgZgs0rTRK1FxA@mail.gmail.com>

On Fri, May 25, 2018, 07:53 Nick Coghlan, <ncoghlan at gmail.com> wrote:

> On 25 May 2018 at 04:09, Ned Deily <nad at python.org> wrote:
>
>> On May 24, 2018, at 13:46, Larry Hastings <larry at hastings.org> wrote:
>> > On 05/24/2018 10:08 AM, Ned Deily wrote:
>> >> If you (or anyone else) feels strongly enough about it, you should
>> re-open the issue now and make it as a "release blocker" and we should
>> discuss the implications and possible plans of action in the issue.
>> >
>> > About that.  According to the Python Dev Guide:
>> > Whether a bug is a *release blocker* for the current release schedule
>> is decided by the release manager. Triagers may recommend this priority and
>> should add the release manager to the nosy list.
>> >
>> > https://devguide.python.org/triaging/#priority
>> > Of course, a particular release manager (e.g. Ned here) can change the
>> policy for their releases.  But by default, unless you're the release
>> manager for release X, you should not mark issues as "Release Blocker" for
>> release X.  This seems like a sensible policy to me, and effective
>> immediately I'm going to hold to this policy for my releases (3.4 and 3.5).
>>
>> I think we're reading the same words a bit differently.  There's no
>> question that the Release Manager makes the ultimate call whether an issue
>> remains a "Release Blocker" or not.  But it seems to me that the safest and
>> most reliable way to ensure that the Release Manager makes that decision is
>> by having a triager or submitter *provisionally* set the priority to
>> "release blocker".  It is then on the Release Manager's radar to accept or
>> reject.  I think that policy is totally in the spirit of the Dev Guide
>> wording but I'm fine with other release managers accepting differing
>> interpretations for their releases ;)
>>
>
> Right, my interpretation of that policy has been that to request RM review
> of a potential blocker I should:
>
> - set the status to Release Blocker
> - add the relevant RM to the nosy list
> - add a comment explaining why I think it might be a release blocker and
> asking the RM to take a look it at
>
> The RM then makes their decision by either commenting to say they're
> accepting the issue as a blocker, bumping it down to deferred blocker (if
> they don't think it's a blocker *yet*), or else bumping it down to one of
> the non-blocking priorities (if they don't agree that it's a blocker at
> all).
>

That's how I've always done it as well. As Ned said, better safe than sorry
by guessing at something being a release blocker than something
accidentally being lost in the cracks.



> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180525/01f16233/attachment.html>

From brett at python.org  Fri May 25 13:43:21 2018
From: brett at python.org (Brett Cannon)
Date: Fri, 25 May 2018 10:43:21 -0700
Subject: [python-committers] Quick reminder: please don't push long-lived
 dev branches to the CPython repo
Message-ID: <CAP1=2W4AqORE0NMYK5Mwbfx9wEoB5XySoLdyKHyhf_6EH1kEWA@mail.gmail.com>

If you create a dev branch that is going to live for less than 24 hours
because you edited some typo in the docs or something through GitHub's UI,
then that's fine. But long-lived dev branches should be done in one's
personal fork. This is for two reasons: one is so that others don't
inadvertently download your dev branch when they do a `git pull` (and
because people often forget to do `git pull --prune`), and two because it
eats up our CI (which is especially precious while we are still on AppVeyor
and the turn-around time there is so long).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180525/c87ea312/attachment.html>

From tjreedy at udel.edu  Fri May 25 16:19:18 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 25 May 2018 16:19:18 -0400
Subject: [python-committers] Quick reminder: please don't push
 long-lived dev branches to the CPython repo
In-Reply-To: <CAP1=2W4AqORE0NMYK5Mwbfx9wEoB5XySoLdyKHyhf_6EH1kEWA@mail.gmail.com>
References: <CAP1=2W4AqORE0NMYK5Mwbfx9wEoB5XySoLdyKHyhf_6EH1kEWA@mail.gmail.com>
Message-ID: <5cd515f5-4efe-544c-0fe8-7672bc08caa3@udel.edu>

On 5/25/2018 1:43 PM, Brett Cannon wrote:
> If you create a dev branch that is going to live for less than 24 hours 
> because you edited some typo in the docs or something through GitHub's 
> UI, then that's fine. But long-lived dev branches should be done in 
> one's personal fork. This is for two reasons: one is so that others 
> don't inadvertently download your dev branch when they do a `git pull` 
> (and because people often forget to do `git pull --prune`),

--prune is not mentioned on https://devguide.python.org/gitbootcamp/

  and two
> because it eats up our CI (which is especially precious while we are 
> still on AppVeyor and the turn-around time there is so long).

From steve.dower at python.org  Fri May 25 17:01:10 2018
From: steve.dower at python.org (Steve Dower)
Date: Fri, 25 May 2018 14:01:10 -0700
Subject: [python-committers] Quick reminder: please don't push
 long-lived dev branches to the CPython repo
In-Reply-To: <CAP1=2W4AqORE0NMYK5Mwbfx9wEoB5XySoLdyKHyhf_6EH1kEWA@mail.gmail.com>
References: <CAP1=2W4AqORE0NMYK5Mwbfx9wEoB5XySoLdyKHyhf_6EH1kEWA@mail.gmail.com>
Message-ID: <bf2d5b94-bda4-fae1-9b31-67a93942f5ee@python.org>

On 25May2018 1043, Brett Cannon wrote:
> (and because people often forget to do `git pull --prune`), and two 
> because it eats up our CI (which is especially precious while we are 
> still on AppVeyor and the turn-around time there is so long).

Don't we have branch filters on CI? (I certainly put them on the VSTS 
builds, and I thought they were there on AppVeyor/Travis too.)

Cheers,
Steve

From brett at python.org  Mon May 28 12:19:04 2018
From: brett at python.org (Brett Cannon)
Date: Mon, 28 May 2018 09:19:04 -0700
Subject: [python-committers] Quick reminder: please don't push
 long-lived dev branches to the CPython repo
In-Reply-To: <bf2d5b94-bda4-fae1-9b31-67a93942f5ee@python.org>
References: <CAP1=2W4AqORE0NMYK5Mwbfx9wEoB5XySoLdyKHyhf_6EH1kEWA@mail.gmail.com>
 <bf2d5b94-bda4-fae1-9b31-67a93942f5ee@python.org>
Message-ID: <CAP1=2W7=VvZBH8LF1PNoAQFM3fVRk=Pk=9A73juD5OWgdBJThQ@mail.gmail.com>

On Fri, 25 May 2018 at 14:01 Steve Dower <steve.dower at python.org> wrote:

> On 25May2018 1043, Brett Cannon wrote:
> > (and because people often forget to do `git pull --prune`), and two
> > because it eats up our CI (which is especially precious while we are
> > still on AppVeyor and the turn-around time there is so long).
>
> Don't we have branch filters on CI? (I certainly put them on the VSTS
> builds, and I thought they were there on AppVeyor/Travis too.)
>

We have filters for Travis, not sure about AppVeyor. I think the branch
that triggered this was also immediately opened as a PR and pushing to the
branch updates the PR and so that also didn't help matters either.

But regardless, making everyone download the branch is still a bit annoying

-Brett


>
> Cheers,
> Steve
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180528/3d895c80/attachment.html>

From nad at python.org  Mon May 28 13:47:56 2018
From: nad at python.org (Ned Deily)
Date: Mon, 28 May 2018 13:47:56 -0400
Subject: [python-committers] [Python-Dev] Troubles to merge changes in
 the 2.7 branch: PR "out-of-date" branch
In-Reply-To: <CAPJVwBngBiYGsUEThi14g-AHto4vYL9F6JFhq7WZJvMAoxY2Ew@mail.gmail.com>
References: <CA+3bQGGNseXGBPysfa_J9jc_6AyPu8bk4Bvf9p9eYFTq3B4FUA@mail.gmail.com>
 <163a70fca60.27a3.db5b03704c129196a4e9415e55413ce6@gmail.com>
 <CAP1=2W70jE4mDC+SSehsBnNKdi1tg07NKLTrmj5ehFrBGD1JEg@mail.gmail.com>
 <CAPJVwBngBiYGsUEThi14g-AHto4vYL9F6JFhq7WZJvMAoxY2Ew@mail.gmail.com>
Message-ID: <821FDA20-E5F6-4650-8754-DD77A909DB5A@python.org>

On May 28, 2018, at 13:19, Nathaniel Smith <njs at pobox.com> wrote:
> 
> Isn't that what happens if someone enables the check box at Repository Settings -> Branches -> Branch protection rules -> [pick a branch] -> Require branches to be up to date before merging ?

Hmm, for some some reason, it appears that, at the moment, the 2.7, 3.4, and 3.5 branches have that option set, while 3.6, 3.7, and master don't.  I'm not sure how we got to that state.  Any other reasons to prefer on versus off?

On Mon, May 28, 2018, 09:11 Brett Cannon <brett at python.org> wrote:
> Ryan is right that there's no special setting in GitHub at least which would make merging more strict for certain branches as you're describing.
> 
> On Mon, 28 May 2018 at 07:06 Ryan Gonzalez <rymg19 at gmail.com> wrote:
> AFAIK there's no setting like this available, and I've done this many times 
> on other repos with no trouble. Maybe it could be a GitHub bug?
> 
> On May 28, 2018 4:59:03 AM Victor Stinner <vstinner at redhat.com> wrote:
> 
> > Hi,
> >
> > Since one or two weeks, I noticed that it's difficult to merge pull
> > requests into the 2.7 branch. If a different commit is pushed in the
> > meanwhile (if a different PR has been merged), the 2.7 branch diverges
> > and the PR is immediately marked as "This branch is out-of-date with
> > the base branch" and the "Squash and Merge" button is disabled (grey).
> >
> > For example my PR https://github.com/python/cpython/pull/7120 which
> > changes Lib/test/regrtest.py cannot be merged because a commit
> > touching the documentation (Doc/ directory) has been merged after I
> > posted my PR and before the CI completed.
> >
> > I don't see the same behavior on the master branch. Is the 2.7 branch
> > configured as more strict?

--
  Ned Deily
  nad at python.org -- []


From nad at python.org  Tue May 29 12:11:12 2018
From: nad at python.org (Ned Deily)
Date: Tue, 29 May 2018 12:11:12 -0400
Subject: [python-committers] Python 3.7.0 updated schedule: beta 5 cutoff in
 24 hours
Message-ID: <333C2C43-459C-46C4-A3AE-637FA05D0057@python.org>

Here's an update on the 3.7.0 endgame. As announced several days ago, we
made the difficult decision to hold back on 3.7.0rc1 due primarily to some
unexpected difficulties being seen downstream due to changes in how
docstrings were handled in 3.7.0 (details below). After some discussions
about various approaches, we agreed on a solution that should minimize
downstream impact without losing all the benefits of the existing 3.7
changes. Thanks to a lot of work over the long weekend by a number of
people that solution is now merged in the 3.7 branch. In parallel with
that, a number of people spent a lot of time looking at CI and buildbot
test failures, mostly intermittent ones. As a result, a number of actual
bugs were fixed and also problems with a number of tests were fixed which
should make the test suite more robust.

All this is good news. Primarily because of the important user-facing
changes made with the AST docstring API, I feel we need to do one more beta
release before we are ready for the release candidate. About 24 hours from
now, approximately 2018-05-30 18:00UTC, I plan to tag and start
manufacturing 3.7.0b5. This will be a short beta cycle, aimed mainly at
users of the AST API so they can recheck that their packages with 3.7.0.
Assuming all goes well, we will then plan to tag 3.7.0rc1 on 2018-06-11 and
3.7.0 final on 2017-06-27. I am also rescheduling 3.6.6rc1 and 3.6.6 final
to match the new 3.7.0 dates.

All fixes that have been merged into the 3.7 branch as of cutoff tomorrow
will be in 3.7.0b5 and fixes merged afterwards will be in 3.7.0rc1 up to
its cutoff point. After 3.7.0rc1 cutoff, 3.7 merges will appear in 3.7.1.
Please continue to exercise diligence when deciding whether a change is
appropriate for 3.7; as a rule of thumb, treat the 3.7 branch as if it were
already released and in maintenance mode. Please also pay attention to CI
test failures and buildbot test failures and see if you can help resolve
them.

I want to thank everyone who has been involved so far in helping us through
this endgame and who have given up their personal time to work on making
Python better. I, for one, am deeply grateful.

2018-05-30 3.7.0b5
2018-06-11 3.7.0rc1 & 3.6.6rc1
2018-06-27 3.7.0final & 3.6.6final

--Ned

On May 25, 2018, at 01:33, Ned Deily <nad at python.org> wrote:
> On May 24, 2018, at 03:23, Ned Deily <nad at python.org> wrote:
>> On May 23, 2018, at 09:13, Ned Deily <nad at python.org> wrote:
>>> On May 23, 2018, at 07:45, Serhiy Storchaka <storchaka at gmail.com> wrote:
>>>> Is it possible to add yet one beta instead?
>>>> CI was broken for few latest days, tests are not passed on my computer still (and fail on some buildbots), updating What's New exposed new features which need additional testing (and maybe fixing or reverting), and I'm not comfortable about some changes which would be harder to fix after the release.
>>> it is possible but there's no point in doing either another beta or a release candidate until we understand and address the current blocking issues, like the major buildbot failures.  We have another 24 hours until rc1 was planned to be tagged.  Let's keep working on the known issues and we will make a decision then.
>> An update: thanks to a lot of effort over the past day by a number of
>> people (including Victor, Serhiy, Christian, Zach, and others I'm sure
>> I'm forgetting - my apologies), we have addressed all of the "release
>> blocker" issues and all but one of the persistent failures on the 3.7
>> stable buildbots. We should have the couple of remaining "deferred
>> blockers" including the remaining stable buildbots in green status by
>> later today. At that point, we will be ready to tag 3.7.0rc1 and begin
>> producing the release candidate artifacts.
> Further update: some good news and some changes.
> 
> The good news is that we have resolutions for all of the previous release and deferred blockers.  Thanks to a number of people for continuing to help get the remaining stable buildbot issues taken care of along with some lingering bugs. 
> 
> The not-quite-as-good news is that we have had more discussions about some unexpected incompatibilities that have shown up with downstream user testing with the AST docstrings changes in place (see bpo-32911).  We have had some previous discussions about the expected user impact and, earlier in the beta phase, I encouraged us to stay the course with the feature as implemented.  But I am now persuaded that we owe it to our users to take one more look at this to make sure we do not force them to make changes for 3.7 and then once again for 3.8.  More details are in the bug tracker issue; I strongly encourage those of us who have been involved with this to "vote" there on the proposal to either (A) proceed with the release of the current implementation in 3.7.0 or (B) revert the feature in 3.7.0 and retarget for 3.8.  Should the consensus be to revert (B), we will plan to have one more fast-track beta release (b5) prior to the release candidate, in order to allow downstream users to tes
> t their projects with the removal.  PLEASE, keep the discussion about this on the bug tracker (and not here!) and keep it brief so we can move forward quickly.  Because of the upcoming 3-day holiday weekend in some countries, I have set Tue 2018-05-29 18:00 UTC as a cutoff for "voting" but, if a clear consensus emerges earlier, we will likely cut the discussion short.  So chime in now on the bug tracker if you have a stake in this issue.
> 
> https://bugs.python.org/issue32911
> 
> This does mean that yesterday's "last chance" has been extended a bit, at most a few days.  I will let you know as soon as we have made a decision about the feature and will provide updated 3.7.0 schedule info at that time.


--
  Ned Deily
  nad at python.org -- []


From rdmurray at bitdance.com  Tue May 29 17:45:29 2018
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 29 May 2018 17:45:29 -0400
Subject: [python-committers] Triage perms for Elvis
Message-ID: <20180529214529.AFA0F251783@webabinitio.net>

At Yuri's request I've given Elvis triage privileges on the tracker.
I don't anticipate any objections, given the work he's done on
What's New and other things.

--David

From nad at python.org  Tue May 29 17:53:38 2018
From: nad at python.org (Ned Deily)
Date: Tue, 29 May 2018 17:53:38 -0400
Subject: [python-committers] Triage perms for Elvis
In-Reply-To: <20180529214529.AFA0F251783@webabinitio.net>
References: <20180529214529.AFA0F251783@webabinitio.net>
Message-ID: <26EB5121-4F52-42C7-8567-DA3116701A22@python.org>

On May 29, 2018, at 17:45, R. David Murray <rdmurray at bitdance.com> wrote:
> At Yuri's request I've given Elvis triage privileges on the tracker.
> I don't anticipate any objections, given the work he's done on
> What's New and other things.

+1

Thanks!

--
  Ned Deily
  nad at python.org -- []


From christian at python.org  Tue May 29 18:05:56 2018
From: christian at python.org (Christian Heimes)
Date: Wed, 30 May 2018 00:05:56 +0200
Subject: [python-committers] Triage perms for Elvis
In-Reply-To: <20180529214529.AFA0F251783@webabinitio.net>
References: <20180529214529.AFA0F251783@webabinitio.net>
Message-ID: <580b305c-e126-4949-ae93-443051f7ee61@python.org>

On 2018-05-29 23:45, R. David Murray wrote:
> At Yuri's request I've given Elvis triage privileges on the tracker.
> I don't anticipate any objections, given the work he's done on
> What's New and other things.

+1

From lukasz at langa.pl  Tue May 29 20:54:58 2018
From: lukasz at langa.pl (Lukasz Langa)
Date: Tue, 29 May 2018 17:54:58 -0700
Subject: [python-committers] Triage perms for Elvis
In-Reply-To: <20180529214529.AFA0F251783@webabinitio.net>
References: <20180529214529.AFA0F251783@webabinitio.net>
Message-ID: <1C2646A2-1956-44F1-A524-FD694276CEBD@langa.pl>

+1

> On May 29, 2018, at 2:45 PM, R. David Murray <rdmurray at bitdance.com> wrote:
> 
> At Yuri's request I've given Elvis triage privileges on the tracker.
> I don't anticipate any objections, given the work he's done on
> What's New and other things.
> 
> --David
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/


From andrew.svetlov at gmail.com  Wed May 30 03:12:28 2018
From: andrew.svetlov at gmail.com (Andrew Svetlov)
Date: Wed, 30 May 2018 10:12:28 +0300
Subject: [python-committers] Triage perms for Elvis
In-Reply-To: <1C2646A2-1956-44F1-A524-FD694276CEBD@langa.pl>
References: <20180529214529.AFA0F251783@webabinitio.net>
 <1C2646A2-1956-44F1-A524-FD694276CEBD@langa.pl>
Message-ID: <CAL3CFcXfr8NV5Fcs_O4Uwr=mffL5V-nSTTq8jhP_fi60P_Sgow@mail.gmail.com>

+1

On Wed, May 30, 2018 at 3:54 AM Lukasz Langa <lukasz at langa.pl> wrote:

> +1
>
> > On May 29, 2018, at 2:45 PM, R. David Murray <rdmurray at bitdance.com>
> wrote:
> >
> > At Yuri's request I've given Elvis triage privileges on the tracker.
> > I don't anticipate any objections, given the work he's done on
> > What's New and other things.
> >
> > --David
> > _______________________________________________
> > python-committers mailing list
> > python-committers at python.org
> > https://mail.python.org/mailman/listinfo/python-committers
> > Code of Conduct: https://www.python.org/psf/codeofconduct/
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-- 
Thanks,
Andrew Svetlov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180530/118b09a1/attachment-0001.html>

From larry at hastings.org  Wed May 30 13:15:04 2018
From: larry at hastings.org (Larry Hastings)
Date: Wed, 30 May 2018 10:15:04 -0700
Subject: [python-committers] Marking issues as "Release Blocker"
 priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!)
In-Reply-To: <CAP1=2W7-O_qBct=uDTCpczRVz+poYSKGq2t0YgZgs0rTRK1FxA@mail.gmail.com>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
 <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com>
 <BB5AA469-781C-442B-9F98-3365286A9043@python.org>
 <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org>
 <df16adf2-725a-8f05-f94b-a6439d3c5c85@gmail.com>
 <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org>
 <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com>
 <E036A817-BE1E-48F7-AB0E-8AA2DD486206@python.org>
 <5ddfa702-f3a0-a9ac-41b5-b89ff3b1b274@hastings.org>
 <FDDFEC1B-6BC9-48CB-830B-E60F02F497F3@python.org>
 <CADiSq7fOjTzST42=RxOFLuMAfzWYbYXrkG5Vz-86xQ5D_Q2NCQ@mail.gmail.com>
 <CAP1=2W7-O_qBct=uDTCpczRVz+poYSKGq2t0YgZgs0rTRK1FxA@mail.gmail.com>
Message-ID: <bd156953-805a-c6b5-6689-c68a0eb42d9c@hastings.org>


Well, I must admit, I'm a little baffled.? The text states unequivocally 
that the release manager is the only person who decides whether or not a 
bug is a "release blocker".? This means nobody else is permitted to make 
this decision.? So I don't see how somebody else can mark a bug as a 
"release blocker" without first deciding that it's a "release 
blocker"--which they're not permitted to do given the rules laid down by 
the Dev Guide.

But if that's not the intended Core Dev policy, then that's not the 
intended Core Dev policy.? Given that literally everybody else 
interpreted the text differently than me, this suggests that the text is 
at the very least ambiguous, if not outright misleading and should be 
updated.? I'll try to put together a PR to bring it more in line with 
everyone's de facto interpretation.

BTW, this all came up because a core dev marked a minor documentation 
change as a "release blocker" for the 3.5 branch, stating that they did 
this "because it'd be nice to see it make it out in the next release".? 
ISTM that opinions vary on what constitutes a "release blocker", and 
maybe empowering only the release managers to make that call would be a 
good way forward--which is what ISTM is what the Dev Guide already says 
anyway.? But I guess not!


//arry/

On 05/25/2018 08:26 AM, Brett Cannon wrote:
>
>
> On Fri, May 25, 2018, 07:53 Nick Coghlan, <ncoghlan at gmail.com 
> <mailto:ncoghlan at gmail.com>> wrote:
>
>     On 25 May 2018 at 04:09, Ned Deily <nad at python.org
>     <mailto:nad at python.org>> wrote:
>
>         On May 24, 2018, at 13:46, Larry Hastings <larry at hastings.org
>         <mailto:larry at hastings.org>> wrote:
>         > On 05/24/2018 10:08 AM, Ned Deily wrote:
>         >> If you (or anyone else) feels strongly enough about it, you
>         should re-open the issue now and make it as a "release
>         blocker" and we should discuss the implications and possible
>         plans of action in the issue.
>         >
>         > About that.? According to the Python Dev Guide:
>         > Whether a bug is a *release blocker* for the current release
>         schedule is decided by the release manager. Triagers may
>         recommend this priority and should add the release manager to
>         the nosy list.
>         >
>         > https://devguide.python.org/triaging/#priority
>         > Of course, a particular release manager (e.g. Ned here) can
>         change the policy for their releases. But by default, unless
>         you're the release manager for release X, you should not mark
>         issues as "Release Blocker" for release X.? This seems like a
>         sensible policy to me, and effective immediately I'm going to
>         hold to this policy for my releases (3.4 and 3.5).
>
>         I think we're reading the same words a bit differently.?
>         There's no question that the Release Manager makes the
>         ultimate call whether an issue remains a "Release Blocker" or
>         not.? But it seems to me that the safest and most reliable way
>         to ensure that the Release Manager makes that decision is by
>         having a triager or submitter *provisionally* set the priority
>         to "release blocker".? It is then on the Release Manager's
>         radar to accept or reject.? I think that policy is totally in
>         the spirit of the Dev Guide wording but I'm fine with other
>         release managers accepting differing interpretations for their
>         releases ;)
>
>
>     Right, my interpretation of that policy has been that to request
>     RM review of a potential blocker I should:
>
>     - set the status to Release Blocker
>     - add the relevant RM to the nosy list
>     - add a comment explaining why I think it might be a release
>     blocker and asking the RM to take a look it at
>
>     The RM then makes their decision by either commenting to say
>     they're accepting the issue as a blocker, bumping it down to
>     deferred blocker (if they don't think it's a blocker *yet*), or
>     else bumping it down to one of the non-blocking priorities (if
>     they don't agree that it's a blocker at all).
>
>
> That's how I've always done it as well. As Ned said, better safe than 
> sorry by guessing at something being a release blocker than something 
> accidentally being lost in the cracks.
>
>
>
>     Cheers,
>     Nick.
>
>     -- 
>     Nick Coghlan?? | ncoghlan at gmail.com <mailto:ncoghlan at gmail.com>??
>     | Brisbane, Australia
>     _______________________________________________
>     python-committers mailing list
>     python-committers at python.org <mailto:python-committers at python.org>
>     https://mail.python.org/mailman/listinfo/python-committers
>     Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180530/a15a3576/attachment.html>

From donald at stufft.io  Wed May 30 13:21:40 2018
From: donald at stufft.io (Donald Stufft)
Date: Wed, 30 May 2018 13:21:40 -0400
Subject: [python-committers] Marking issues as "Release Blocker"
 priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!)
In-Reply-To: <bd156953-805a-c6b5-6689-c68a0eb42d9c@hastings.org>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
 <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com>
 <BB5AA469-781C-442B-9F98-3365286A9043@python.org>
 <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org>
 <df16adf2-725a-8f05-f94b-a6439d3c5c85@gmail.com>
 <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org>
 <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com>
 <E036A817-BE1E-48F7-AB0E-8AA2DD486206@python.org>
 <5ddfa702-f3a0-a9ac-41b5-b89ff3b1b274@hastings.org>
 <FDDFEC1B-6BC9-48CB-830B-E60F02F497F3@python.org>
 <CADiSq7fOjTzST42=RxOFLuMAfzWYbYXrkG5Vz-86xQ5D_Q2NCQ@mail.gmail.com>
 <CAP1=2W7-O_qBct=uDTCpczRVz+poYSKGq2t0YgZgs0rTRK1FxA@mail.gmail.com>
 <bd156953-805a-c6b5-6689-c68a0eb42d9c@hastings.org>
Message-ID: <955F645F-C2B9-4811-BB0E-E8D5CDA85D7E@stufft.io>


> On May 30, 2018, at 1:15 PM, Larry Hastings <larry at hastings.org> wrote:
> 
> ISTM that opinions vary on what constitutes a "release blocker", and maybe empowering only the release managers to make that call would be a good way forward--which is what ISTM is what the Dev Guide already says anyway.  But I guess not!

I think that RMs are empowered to decide what is a ?real" release blocker, but you need some mechanism to flag an issue as potentially a release blocker for the RM to make a decision on it. Making a decision on that potentially release blocker should also itself be a release blocker (because if it?s possibly a release blocker, then we should treat it as such until the person empowered to make that call has decided one way or another).

So I think for the system to work, you need to either allow anyone to flag an issue as a release blocker, and the RM is empowered to say ?No this really isn?t? and unflag it, or you need two flags, for release blocker, and maybe release blocker, and both block the release.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180530/ecbecea0/attachment-0001.html>

From mal at egenix.com  Wed May 30 13:46:54 2018
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 30 May 2018 19:46:54 +0200
Subject: [python-committers] Marking issues as "Release Blocker"
 priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!)
In-Reply-To: <955F645F-C2B9-4811-BB0E-E8D5CDA85D7E@stufft.io>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
 <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com>
 <BB5AA469-781C-442B-9F98-3365286A9043@python.org>
 <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org>
 <df16adf2-725a-8f05-f94b-a6439d3c5c85@gmail.com>
 <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org>
 <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com>
 <E036A817-BE1E-48F7-AB0E-8AA2DD486206@python.org>
 <5ddfa702-f3a0-a9ac-41b5-b89ff3b1b274@hastings.org>
 <FDDFEC1B-6BC9-48CB-830B-E60F02F497F3@python.org>
 <CADiSq7fOjTzST42=RxOFLuMAfzWYbYXrkG5Vz-86xQ5D_Q2NCQ@mail.gmail.com>
 <CAP1=2W7-O_qBct=uDTCpczRVz+poYSKGq2t0YgZgs0rTRK1FxA@mail.gmail.com>
 <bd156953-805a-c6b5-6689-c68a0eb42d9c@hastings.org>
 <955F645F-C2B9-4811-BB0E-E8D5CDA85D7E@stufft.io>
Message-ID: <db646e98-0009-69a0-612c-1c542b336369@egenix.com>

In terms of process, it's always good to have a method to escalate a
question to higher management in a way which doesn't require the
manager to first parse long text messages.

So a status such as "Potential Release Blocker" or "RM Review"
sounds like a good way forward.

Of course a friendly ping via some other channel usually
also helps get attention :-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, May 30 2018)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...           http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...           http://zope.egenix.com/
________________________________________________________________________

::: We implement business ideas - efficiently in both time and costs :::

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


From larry at hastings.org  Wed May 30 15:03:59 2018
From: larry at hastings.org (Larry Hastings)
Date: Wed, 30 May 2018 12:03:59 -0700
Subject: [python-committers] Marking issues as "Release Blocker"
 priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!)
In-Reply-To: <955F645F-C2B9-4811-BB0E-E8D5CDA85D7E@stufft.io>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
 <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com>
 <BB5AA469-781C-442B-9F98-3365286A9043@python.org>
 <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org>
 <df16adf2-725a-8f05-f94b-a6439d3c5c85@gmail.com>
 <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org>
 <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com>
 <E036A817-BE1E-48F7-AB0E-8AA2DD486206@python.org>
 <5ddfa702-f3a0-a9ac-41b5-b89ff3b1b274@hastings.org>
 <FDDFEC1B-6BC9-48CB-830B-E60F02F497F3@python.org>
 <CADiSq7fOjTzST42=RxOFLuMAfzWYbYXrkG5Vz-86xQ5D_Q2NCQ@mail.gmail.com>
 <CAP1=2W7-O_qBct=uDTCpczRVz+poYSKGq2t0YgZgs0rTRK1FxA@mail.gmail.com>
 <bd156953-805a-c6b5-6689-c68a0eb42d9c@hastings.org>
 <955F645F-C2B9-4811-BB0E-E8D5CDA85D7E@stufft.io>
Message-ID: <fef25088-1ea9-fc26-c4c5-bd4aea09a682@hastings.org>



On 05/30/2018 10:21 AM, Donald Stufft wrote:
>
>> On May 30, 2018, at 1:15 PM, Larry Hastings <larry at hastings.org 
>> <mailto:larry at hastings.org>> wrote:
>>
>> ISTM that opinions vary on what constitutes a "release blocker", and 
>> maybe empowering only the release managers to make that call would be 
>> a good way forward--which is what ISTM is what the Dev Guide already 
>> says anyway.? But I guess not!
>
> I think that RMs are empowered to decide what is a ?real" release 
> blocker, but you need some mechanism to flag an issue as potentially a 
> release blocker for the RM to make a decision on it. Making a decision 
> on that potentially release blocker should also itself be a release 
> blocker (because if it?s possibly a release blocker, then we should 
> treat it as such until the person empowered to make that call has 
> decided one way or another).
>
> So I think for the system to work, you need to either allow anyone to 
> flag an issue as a release blocker, and the RM is empowered to say ?No 
> this really isn?t? and unflag it, or you need two flags, for release 
> blocker, and maybe release blocker, and both block the release.

Yes, ISTM that the Dev Guide covers this.? The section on priority says:

    Triagers may recommend this priority and should add the release
    manager to the nosy list.

In other words: if a dev thinks an issue should be a release blocker for 
version X, they should add the RM to the nosy list and make a comment 
recommending the issue be escalated to release blocker.? I thought it 
was telling that it /doesn't/ instruct triagers to mark the issue as a 
release blocker themselves.


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180530/066e9d71/attachment.html>

From brett at python.org  Wed May 30 14:59:01 2018
From: brett at python.org (Brett Cannon)
Date: Wed, 30 May 2018 11:59:01 -0700
Subject: [python-committers] Marking issues as "Release Blocker"
 priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!)
In-Reply-To: <955F645F-C2B9-4811-BB0E-E8D5CDA85D7E@stufft.io>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
 <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com>
 <BB5AA469-781C-442B-9F98-3365286A9043@python.org>
 <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org>
 <df16adf2-725a-8f05-f94b-a6439d3c5c85@gmail.com>
 <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org>
 <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com>
 <E036A817-BE1E-48F7-AB0E-8AA2DD486206@python.org>
 <5ddfa702-f3a0-a9ac-41b5-b89ff3b1b274@hastings.org>
 <FDDFEC1B-6BC9-48CB-830B-E60F02F497F3@python.org>
 <CADiSq7fOjTzST42=RxOFLuMAfzWYbYXrkG5Vz-86xQ5D_Q2NCQ@mail.gmail.com>
 <CAP1=2W7-O_qBct=uDTCpczRVz+poYSKGq2t0YgZgs0rTRK1FxA@mail.gmail.com>
 <bd156953-805a-c6b5-6689-c68a0eb42d9c@hastings.org>
 <955F645F-C2B9-4811-BB0E-E8D5CDA85D7E@stufft.io>
Message-ID: <CAP1=2W5_ePtrtnTpwTe+NSNdME6N3SE1baenTzoZPNnzoP_4Fg@mail.gmail.com>

On Wed, 30 May 2018 at 10:21 Donald Stufft <donald at stufft.io> wrote:

>
> On May 30, 2018, at 1:15 PM, Larry Hastings <larry at hastings.org> wrote:
>
> ISTM that opinions vary on what constitutes a "release blocker", and maybe
> empowering only the release managers to make that call would be a good way
> forward--which is what ISTM is what the Dev Guide already says anyway.  But
> I guess not!
>
>
> I think that RMs are empowered to decide what is a ?real" release blocker,
> but you need some mechanism to flag an issue as potentially a release
> blocker for the RM to make a decision on it. Making a decision on that
> potentially release blocker should also itself be a release blocker
> (because if it?s possibly a release blocker, then we should treat it as
> such until the person empowered to make that call has decided one way or
> another).
>

And this is how I have always interpreted it. Larry is totally within his
rights to say "that is not a release blocker" and switch it to not being
one. At the end of the day it's Larry who presses the proverbial "Release"
button and that label technically means nothing if he chooses to ignore it.


>
> So I think for the system to work, you need to either allow anyone to flag
> an issue as a release blocker, and the RM is empowered to say ?No this
> really isn?t? and unflag it, or you need two flags, for release blocker,
> and maybe release blocker, and both block the release.
>

Yep, or as MAL suggested, a "potential release blocker" or something where
we expect only RMs to push something all the way up to an actual "release
blocker".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180530/5e7b40ee/attachment.html>

From larry at hastings.org  Wed May 30 15:07:41 2018
From: larry at hastings.org (Larry Hastings)
Date: Wed, 30 May 2018 12:07:41 -0700
Subject: [python-committers] Marking issues as "Release Blocker"
 priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!)
In-Reply-To: <CAP1=2W5_ePtrtnTpwTe+NSNdME6N3SE1baenTzoZPNnzoP_4Fg@mail.gmail.com>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
 <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com>
 <BB5AA469-781C-442B-9F98-3365286A9043@python.org>
 <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org>
 <df16adf2-725a-8f05-f94b-a6439d3c5c85@gmail.com>
 <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org>
 <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com>
 <E036A817-BE1E-48F7-AB0E-8AA2DD486206@python.org>
 <5ddfa702-f3a0-a9ac-41b5-b89ff3b1b274@hastings.org>
 <FDDFEC1B-6BC9-48CB-830B-E60F02F497F3@python.org>
 <CADiSq7fOjTzST42=RxOFLuMAfzWYbYXrkG5Vz-86xQ5D_Q2NCQ@mail.gmail.com>
 <CAP1=2W7-O_qBct=uDTCpczRVz+poYSKGq2t0YgZgs0rTRK1FxA@mail.gmail.com>
 <bd156953-805a-c6b5-6689-c68a0eb42d9c@hastings.org>
 <955F645F-C2B9-4811-BB0E-E8D5CDA85D7E@stufft.io>
 <CAP1=2W5_ePtrtnTpwTe+NSNdME6N3SE1baenTzoZPNnzoP_4Fg@mail.gmail.com>
Message-ID: <743f53c3-46d9-5ec8-55c6-bfe4a0562978@hastings.org>



On 05/30/2018 11:59 AM, Brett Cannon wrote:
> On Wed, 30 May 2018 at 10:21 Donald Stufft <donald at stufft.io 
> <mailto:donald at stufft.io>> wrote:
>
>
>     So I think for the system to work, you need to either allow anyone
>     to flag an issue as a release blocker, and the RM is empowered to
>     say ?No this really isn?t? and unflag it, or you need two flags,
>     for release blocker, and maybe release blocker, and both block the
>     release.
>
>
> Yep, or as MAL suggested, a "potential release blocker" or something 
> where we expect only RMs to push something all the way up to an actual 
> "release blocker".

I suggest we simply use the existing "critical" priority to also mean 
"potential release blocker".? If not, what would be the salient 
difference between a "critical" bug and a "potential release blocker" bug?


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180530/e62414b2/attachment-0001.html>

From donald at stufft.io  Wed May 30 15:09:22 2018
From: donald at stufft.io (Donald Stufft)
Date: Wed, 30 May 2018 15:09:22 -0400
Subject: [python-committers] Marking issues as "Release Blocker"
 priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!)
In-Reply-To: <fef25088-1ea9-fc26-c4c5-bd4aea09a682@hastings.org>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
 <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com>
 <BB5AA469-781C-442B-9F98-3365286A9043@python.org>
 <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org>
 <df16adf2-725a-8f05-f94b-a6439d3c5c85@gmail.com>
 <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org>
 <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com>
 <E036A817-BE1E-48F7-AB0E-8AA2DD486206@python.org>
 <5ddfa702-f3a0-a9ac-41b5-b89ff3b1b274@hastings.org>
 <FDDFEC1B-6BC9-48CB-830B-E60F02F497F3@python.org>
 <CADiSq7fOjTzST42=RxOFLuMAfzWYbYXrkG5Vz-86xQ5D_Q2NCQ@mail.gmail.com>
 <CAP1=2W7-O_qBct=uDTCpczRVz+poYSKGq2t0YgZgs0rTRK1FxA@mail.gmail.com>
 <bd156953-805a-c6b5-6689-c68a0eb42d9c@hastings.org>
 <955F645F-C2B9-4811-BB0E-E8D5CDA85D7E@stufft.io>
 <fef25088-1ea9-fc26-c4c5-bd4aea09a682@hastings.org>
Message-ID: <7D500DE9-1196-465A-BBC5-89652BC6D3CE@stufft.io>



> On May 30, 2018, at 3:03 PM, Larry Hastings <larry at hastings.org> wrote:
> 
> Yes, ISTM that the Dev Guide covers this.  The section on priority says:
> Triagers may recommend this priority and should add the release manager to the nosy list.
> In other words: if a dev thinks an issue should be a release blocker for version X, they should add the RM to the nosy list and make a comment recommending the issue be escalated to release blocker.  I thought it was telling that it doesn't instruct triagers to mark the issue as a release blocker themselves.


That seems a rather poor way of handling it TBH. A key thing is that an escalation for a decision should itself be a release blocker, because if someone thinks the issue might be, then we should get a decision on whether it is or not before the release goes out. Relying on a comment seems far too easy for the release manager to accidentally miss it or forget about it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180530/5551a96d/attachment.html>

From nad at python.org  Wed May 30 15:41:58 2018
From: nad at python.org (Ned Deily)
Date: Wed, 30 May 2018 15:41:58 -0400
Subject: [python-committers] Marking issues as "Release Blocker"
 priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!)
In-Reply-To: <7D500DE9-1196-465A-BBC5-89652BC6D3CE@stufft.io>
References: <AB6A7032-2D29-4932-870C-EA2C44F04EAF@python.org>
 <6304cea3-52fc-fd19-b920-016715f6f5d1@gmail.com>
 <BB5AA469-781C-442B-9F98-3365286A9043@python.org>
 <33CAAEBB-8DE3-494D-9306-415D70D9A27B@python.org>
 <df16adf2-725a-8f05-f94b-a6439d3c5c85@gmail.com>
 <6C79D66A-548E-45BF-BD23-F35A90FAE49A@python.org>
 <6506e386-1be7-db3e-626b-9bcac8d5b7dd@gmail.com>
 <E036A817-BE1E-48F7-AB0E-8AA2DD486206@python.org>
 <5ddfa702-f3a0-a9ac-41b5-b89ff3b1b274@hastings.org>
 <FDDFEC1B-6BC9-48CB-830B-E60F02F497F3@python.org>
 <CADiSq7fOjTzST42=RxOFLuMAfzWYbYXrkG5Vz-86xQ5D_Q2NCQ@mail.gmail.com>
 <CAP1=2W7-O_qBct=uDTCpczRVz+poYSKGq2t0YgZgs0rTRK1FxA@mail.gmail.com>
 <bd156953-805a-c6b5-6689-c68a0eb42d9c@hastings.org>
 <955F645F-C2B9-4811-BB0E-E8D5CDA85D7E@stufft.io>
 <fef25088-1ea9-fc26-c4c5-bd4aea09a682@hastings.org>
 <7D500DE9-1196-465A-BBC5-89652BC6D3CE@stufft.io>
Message-ID: <68538F88-1179-41DE-90D6-59A91CC28EF6@python.org>

On May 30, 2018, at 15:09, Donald Stufft <donald at stufft.io> wrote:
> On May 30, 2018, at 3:03 PM, Larry Hastings <larry at hastings.org> wrote:
>> Yes, ISTM that the Dev Guide covers this.  The section on priority says:
>> Triagers may recommend this priority and should add the release manager to the nosy list.
>> In other words: if a dev thinks an issue should be a release blocker for version X, they should add the RM to the nosy list and make a comment recommending the issue be escalated to release blocker.  I thought it was telling that it doesn't instruct triagers to mark the issue as a release blocker themselves.
> 
> That seems a rather poor way of handling it TBH. A key thing is that an escalation for a decision should itself be a release blocker, because if someone thinks the issue might be, then we should get a decision on whether it is or not before the release goes out. Relying on a comment seems far too easy for the release manager to accidentally miss it or forget about it.

Yes. And I think Donald's earlier description of the current process was 100% correct.  It is true that, at some level, the current "release blocker" could be broken into two separate states, a "release blocker proposed" and "release blocker accepted".  But why?  In nearly a dozen years of following the bug tracker and  the Python process, I don't recall this ever coming up before.  As a practical matter, there is absolutely no ambiguity as the issue history shows who set the priority to "release blocker".  Again, it's a near foolproof way (since RM's are not allowed to make a release with a "release blocker" open against that release) to ensure the issue has been evaluated by the RM.  And it has worked well for many people for many reasons.  And it just doesn't happen very often, i.e. we don't have many release blockers.

I think the only reason this came up was because of our policy, enforced by GitHub settings, that merges to "security fix only" branches may only be performed by the release manager, unlike other branches.  And in this case, the core developer just wanted to make sure that the release manager saw and acted on the outstanding PR for the security branch.  I think that action made perfect sense to me.

So, I really really don't think there's a problem today that needs solving and, worse, the suggestions so far add complexity with no benefit at all as far as I can see.  May I respectfully suggest that we just drop this discussion and move on, please?

--
  Ned Deily
  nad at python.org -- []


From nad at python.org  Thu May 31 00:32:14 2018
From: nad at python.org (Ned Deily)
Date: Thu, 31 May 2018 00:32:14 -0400
Subject: [python-committers] [RELEASE] Python 3.7.0b5 bonus beta!
Message-ID: <CC1A7AC5-5D16-4852-A0E5-8CD715AF2C6F@python.org>

A 3.7 update: Python 3.7.0b5 is now the final beta preview of Python 3.7,
the next feature release of Python. 3.7.0b4 was intended to be the final
beta but, due to some unexpected compatibility issues discovered during
beta testing of third-party packages, we decided to revert some changes
in how Python's 3.7 Abstract Syntax Tree parser deals with docstrings;
3.7.0b5 now behaves like 3.6.x and previous releases (refer to the
3.7.0b5 changelog for more information).

**If your code makes use of the ast module, you are strongly encouraged
to test (or retest) that code with 3.7.0b5, especially if you previously
made changes to work with earlier preview versons of 3.7.0.**

As always, please report issues found to bugs.python.org as soon as
possible. Please keep in mind that this is a preview release and its use
is not recommended for production environments. Attention macOS users:
there is now a new installer variant for macOS 10.9+ that includes a
built-in version of Tcl/Tk 8.6. This variant is expected to become the
default version when 3.7.0 releases. Check it out!

The next (and final, we hope!) preview release will be the release
candidate which is now planned for 2018-06-11, followed by the official
release of 3.7.0, now planned for 2018-06-27. You can find Python 3.7.0b5
and more information here:

    https://www.python.org/downloads/release/python-370b5/

--
  Ned Deily
  nad at python.org -- []