From donald at stufft.io  Thu Mar  2 08:20:04 2017
From: donald at stufft.io (Donald Stufft)
Date: Thu, 2 Mar 2017 08:20:04 -0500
Subject: [python-committers] Please Publicize your Github Membership for
 Python
Message-ID: <96AC10F9-FC60-44BF-9002-F0DC6F50C8A9@stufft.io>

Hello!

Some of our automation needs to be able to determine who is a member of the Python organization on Github to effectively work. Unfortunately it currently can only see users who have publicized their membership in the Org, but so far only 50 out of 138 current members have done so.

If you have a minute and are able to do that, it would be great.

It?s pretty easy to do, just go to https://github.com/orgs/python/people <https://github.com/orgs/python/people> and locate yourself on the list. Once you found yourself, if you look to the right hand side of your entry, you?ll see either the word ?Private? or ?Public?, if it says ?Private?, click on it and select ?Public? (https://s.caremad.io/MLlxY1W5r0/ <https://s.caremad.io/MLlxY1W5r0/>). That?s all you need to do.


Thanks a lot!

?
Donald Stufft



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

From brett at python.org  Thu Mar  2 23:15:17 2017
From: brett at python.org (Brett Cannon)
Date: Fri, 03 Mar 2017 04:15:17 +0000
Subject: [python-committers] Travis requirement temporarily turned off
Message-ID: <CAP1=2W6diAVnddxVprFNfTmKPtE17=Uw-8-3SNv3zFPrs2PAXw@mail.gmail.com>

Travis is severely backed up at the moment. Knowing that 3.6.1rc1 is due
this weekend I have temporarily turned off Travis requiring to be passing
so that those who test locally can skip being blocked by hour-long (or
more) wait times for Travis. If you don't want to test I would then still
strongly recommend on waiting for Travis if you don't feel like your PR is
critical to 3.6.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170303/1fca2602/attachment.html>

From ncoghlan at gmail.com  Fri Mar  3 02:03:38 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 3 Mar 2017 17:03:38 +1000
Subject: [python-committers] Please Publicize your Github Membership for
 Python
In-Reply-To: <96AC10F9-FC60-44BF-9002-F0DC6F50C8A9@stufft.io>
References: <96AC10F9-FC60-44BF-9002-F0DC6F50C8A9@stufft.io>
Message-ID: <CADiSq7c+u6nMuC3VWTrf8ACE1mphW0eediA_PRjt6ZAsUp9R1A@mail.gmail.com>

On 2 March 2017 at 23:20, Donald Stufft <donald at stufft.io> wrote:

> Hello!
>
> Some of our automation needs to be able to determine who is a member of
> the Python organization on Github to effectively work. Unfortunately it
> currently can only see users who have publicized their membership in the
> Org, but so far only 50 out of 138 current members have done so.
>

Providing some more specifics on the helper that needs this:

- Donald & Brett recently enabled https://github.com/facebook/mention-bot
which tries to find and mention relevant reviewers based on files touched
in the commit
- the bot only has access to public info, so if your org membership is
private, it will never mention you, so you may miss PRs you actually want
to review
- if your org info is public, but you don't want the mentions, then you can
add yourself to the blacklist in
https://github.com/python/cpython/blob/master/.mention-bot (as Guido has)
- if you want to find your own reviewers for your PRs, add yourself to the
PR blacklist in the same file (as Benjamin has)

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/20170303/f9e86b41/attachment.html>

From victor.stinner at gmail.com  Fri Mar  3 05:23:28 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Fri, 3 Mar 2017 11:23:28 +0100
Subject: [python-committers] Please Publicize your Github Membership for
 Python
In-Reply-To: <CADiSq7c+u6nMuC3VWTrf8ACE1mphW0eediA_PRjt6ZAsUp9R1A@mail.gmail.com>
References: <96AC10F9-FC60-44BF-9002-F0DC6F50C8A9@stufft.io>
 <CADiSq7c+u6nMuC3VWTrf8ACE1mphW0eediA_PRjt6ZAsUp9R1A@mail.gmail.com>
Message-ID: <CAMpsgwYw-4Ee1Vx2XxNZ7sr+hKnxZPvj+hgrs3DgDNYZt7RVUA@mail.gmail.com>

Donald just merged a change to not restrict mention-bot to members of
the GitHub Python organization:
https://github.com/python/cpython/pull/393

Victor

2017-03-03 8:03 GMT+01:00 Nick Coghlan <ncoghlan at gmail.com>:
> On 2 March 2017 at 23:20, Donald Stufft <donald at stufft.io> wrote:
>>
>> Hello!
>>
>> Some of our automation needs to be able to determine who is a member of
>> the Python organization on Github to effectively work. Unfortunately it
>> currently can only see users who have publicized their membership in the
>> Org, but so far only 50 out of 138 current members have done so.
>
>
> Providing some more specifics on the helper that needs this:
>
> - Donald & Brett recently enabled https://github.com/facebook/mention-bot
> which tries to find and mention relevant reviewers based on files touched in
> the commit
> - the bot only has access to public info, so if your org membership is
> private, it will never mention you, so you may miss PRs you actually want to
> review
> - if your org info is public, but you don't want the mentions, then you can
> add yourself to the blacklist in
> https://github.com/python/cpython/blob/master/.mention-bot (as Guido has)
> - if you want to find your own reviewers for your PRs, add yourself to the
> PR blacklist in the same file (as Benjamin has)
>
> 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/

From donald at stufft.io  Fri Mar  3 06:24:02 2017
From: donald at stufft.io (Donald Stufft)
Date: Fri, 3 Mar 2017 06:24:02 -0500
Subject: [python-committers] Please Publicize your Github Membership for
 Python
In-Reply-To: <CADiSq7c+u6nMuC3VWTrf8ACE1mphW0eediA_PRjt6ZAsUp9R1A@mail.gmail.com>
References: <96AC10F9-FC60-44BF-9002-F0DC6F50C8A9@stufft.io>
 <CADiSq7c+u6nMuC3VWTrf8ACE1mphW0eediA_PRjt6ZAsUp9R1A@mail.gmail.com>
Message-ID: <233B0AAF-F512-464C-905B-A7CC1D8CE19F@stufft.io>


> On Mar 3, 2017, at 2:03 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> On 2 March 2017 at 23:20, Donald Stufft <donald at stufft.io <mailto:donald at stufft.io>> wrote:
> Hello!
> 
> Some of our automation needs to be able to determine who is a member of the Python organization on Github to effectively work. Unfortunately it currently can only see users who have publicized their membership in the Org, but so far only 50 out of 138 current members have done so.
> 
> Providing some more specifics on the helper that needs this:
> 
> - Donald & Brett recently enabled https://github.com/facebook/mention-bot <https://github.com/facebook/mention-bot> which tries to find and mention relevant reviewers based on files touched in the commit
> - the bot only has access to public info, so if your org membership is private, it will never mention you, so you may miss PRs you actually want to review
> - if your org info is public, but you don't want the mentions, then you can add yourself to the blacklist in https://github.com/python/cpython/blob/master/.mention-bot <https://github.com/python/cpython/blob/master/.mention-bot> (as Guido has)
> - if you want to find your own reviewers for your PRs, add yourself to the PR blacklist in the same file (as Benjamin has)
> 
> Cheers,
> Nick.
> 
> -- 
> Nick Coghlan   |   ncoghlan at gmail.com <mailto:ncoghlan at gmail.com>   |   Brisbane, Australia


There?s also an option to *always* get notified for files that match a certain set of globs too.

?
Donald Stufft



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170303/092e9862/attachment-0001.html>

From donald at stufft.io  Fri Mar  3 08:11:47 2017
From: donald at stufft.io (Donald Stufft)
Date: Fri, 3 Mar 2017 08:11:47 -0500
Subject: [python-committers] Please Publicize your Github Membership for
 Python
In-Reply-To: <CADiSq7c+u6nMuC3VWTrf8ACE1mphW0eediA_PRjt6ZAsUp9R1A@mail.gmail.com>
References: <96AC10F9-FC60-44BF-9002-F0DC6F50C8A9@stufft.io>
 <CADiSq7c+u6nMuC3VWTrf8ACE1mphW0eediA_PRjt6ZAsUp9R1A@mail.gmail.com>
Message-ID: <B66F400E-DA72-484C-B20C-807CBE3AF841@stufft.io>


> On Mar 3, 2017, at 2:03 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> - if your org info is public, but you don't want the mentions, then you can add yourself to the blacklist in https://github.com/python/cpython/blob/master/.mention-bot <https://github.com/python/cpython/blob/master/.mention-bot> (as Guido has)
> - if you want to find your own reviewers for your PRs, add yourself to the PR blacklist in the same file (as Benjamin has)


Note, this .mention-bot file is a JSON file, so if you want to exclude yourself you?ll need to add yourself to the list of the already existing keys.

?
Donald Stufft



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

From nad at python.org  Sun Mar  5 07:01:30 2017
From: nad at python.org (Ned Deily)
Date: Sun, 5 Mar 2017 07:01:30 -0500
Subject: [python-committers] [RELEASE] Python 3.6.1rc1 is now available
Message-ID: <50484B0A-BA03-42D0-B5EC-4D8E1CF1BC26@python.org>

On behalf of the Python development community and the Python 3.6 release
team, I would like to announce the availability of Python 3.6.1rc1.
3.6.1rc1 is the first release candidate for Python 3.6.1, the first
maintenance release of Python 3.6.  3.6.0 was released on 2017-12-22
to great interest and now, three months later, we are providing the
first set of bugfixes and documentation updates for it.  While
3.6.1rc1 is a preview release and, thus, not intended for production
environments, we encourage you to explore it and provide feedback
via the Python bug tracker (https://bugs.python.org).  Although it
should be transparent to users of Python, 3.6.1 is the first release
after some major changes to our development process so we ask users
who build Python from source to be on the lookout for any unexpected
differences.

3.6.1 is planned for final release on 2017-03-20 with the next
maintenance release expected to follow in about 3 months.
 
Please see "What?s New In Python 3.6" for more information:

https://docs.python.org/3.6/whatsnew/3.6.html

You can find Python 3.6.1rc1 here:

https://www.python.org/downloads/release/python-361rc1/

More information about the 3.6 release schedule can be found here:

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

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


From barry at python.org  Sun Mar  5 17:31:00 2017
From: barry at python.org (Barry Warsaw)
Date: Sun, 5 Mar 2017 17:31:00 -0500
Subject: [python-committers] Signups for 2017 Python Language Summit are now
 open
Message-ID: <20170305173100.2e358bca@subdivisions.wooz.org>

It?s that time again: time to start thinking about the Python Language Summit!
The 2017 summit will be held on Wednesday, May 17, from 10am to 4pm, at the
Oregon Convention Center in Portland, Oregon, USA.  Your befezzled hosts Larry
and Barry will once again be at the helm.

The summit?s purpose is to disseminate information and spark conversation
among core Python developers.  It?s our yearly opportunity to get together for
an in-person discussion, to review interesting developments of the previous
year and hash out where we?re going next.  And we have lots to talk about!
Since our last summit, Python 3.6 was released, and the main CPython
development process has been moved to GitHub.  Naturally Python 3.7
development continues apace.

Speaking of changes, we?re continuing to evolve the summit.  Everyone seemed
to like the lightning talks, so we?ll keep those.  Everyone seemed to hate us
keeping the schedule secret -sorry!- so we?ll make that available beforehand,
with the understanding that it?ll be fluid as the day progresses.  Due to room
size limitations and the yearly increase in participation, we?re limiting
summit invitations to just core developers and invited speakers.  As usual,
we?ll have whiteboards and a projector.  But this year we?re adding roaming
microphones, so everybody in the room will be able to hear your question!

With the help of the ever awesome Ewa, this year we?ll have badge ribbons for
Language Summit participants, which we?ll hand out at the summit room in the
morning.

As with last year, we?re using Google Forms to collect signups.  The form will
let you request an invitation to the summit and optionally propose a talk.
Signups are open now, and will remain open until Wednesday April 12th, 2017.
You can find the link to the signup form from the summit?s official web page,
here:

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

But never forget: you don?t need to be registered for PyCon in order to attend
the summit!

One final note.  We?re re-inviting Jake Edge from Linux Weekly News to attend
the summit and provide press coverage.  Jake?s done a phenomenal job of
covering the previous two years? summits, providing valuable information not
just for summit attendees, but also for the Python community at large.  Jake?s
coverage goes a long way toward demystifying the summit, while remaining
respectful of confidential information that?s deemed ?off the record? ahead of
time by participants.

We hope to see you at the summit!

[BL]arry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170305/3dd89efe/attachment.sig>

From brett at python.org  Mon Mar  6 14:30:35 2017
From: brett at python.org (Brett Cannon)
Date: Mon, 06 Mar 2017 19:30:35 +0000
Subject: [python-committers] Travis requirement temporarily turned off
In-Reply-To: <CAP1=2W6diAVnddxVprFNfTmKPtE17=Uw-8-3SNv3zFPrs2PAXw@mail.gmail.com>
References: <CAP1=2W6diAVnddxVprFNfTmKPtE17=Uw-8-3SNv3zFPrs2PAXw@mail.gmail.com>
Message-ID: <CAP1=2W66fOGT3u259JJo=jt7-dEm9Je_cmBg55Yuy34gH2NGCQ@mail.gmail.com>

I have turned back on the requirement that Travis be passing for PRs since
3.6.1rc1 is out and we now already have one instance where a merge broke
the build (https://github.com/python/cpython/pull/518; it's been fixed). We
will revisit this topic when I email on Friday about the workflow.

On Thu, 2 Mar 2017 at 20:15 Brett Cannon <brett at python.org> wrote:

> Travis is severely backed up at the moment. Knowing that 3.6.1rc1 is due
> this weekend I have temporarily turned off Travis requiring to be passing
> so that those who test locally can skip being blocked by hour-long (or
> more) wait times for Travis. If you don't want to test I would then still
> strongly recommend on waiting for Travis if you don't feel like your PR is
> critical to 3.6.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170306/346a2b26/attachment.html>

From victor.stinner at gmail.com  Mon Mar  6 19:32:03 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Tue, 7 Mar 2017 01:32:03 +0100
Subject: [python-committers] GitHub: allow Rebase and merge
Message-ID: <CAMpsgwYjuqiYs-+tid8Z80izu2Om2rYZz+fMs=9xsM-h_R+9Ow@mail.gmail.com>

Hi,

Would it be possible to keep "Squash and merge" button by default on
GitHub pull requests, but allow "Rebase and merge" to keep multiple
commits when they are well written. Example of such PR:
https://github.com/python/cpython/pull/489/commits

Maybe the second commit lacks bpo-xxx, but it's not a big deal. I
prefer smaller atomic commits when possible.

Victor

From brett at python.org  Tue Mar  7 12:42:34 2017
From: brett at python.org (Brett Cannon)
Date: Tue, 07 Mar 2017 17:42:34 +0000
Subject: [python-committers] GitHub: allow Rebase and merge
In-Reply-To: <CAMpsgwYjuqiYs-+tid8Z80izu2Om2rYZz+fMs=9xsM-h_R+9Ow@mail.gmail.com>
References: <CAMpsgwYjuqiYs-+tid8Z80izu2Om2rYZz+fMs=9xsM-h_R+9Ow@mail.gmail.com>
Message-ID: <CAP1=2W7jdpUqQ+_U=XZDCgu8sUK-htgVLJchyMoZuTRjfZhrNg@mail.gmail.com>

It's possible, but we don't control what the default option is.

On Mon, 6 Mar 2017 at 16:32 Victor Stinner <victor.stinner at gmail.com> wrote:

> Hi,
>
> Would it be possible to keep "Squash and merge" button by default on
> GitHub pull requests, but allow "Rebase and merge" to keep multiple
> commits when they are well written. Example of such PR:
> https://github.com/python/cpython/pull/489/commits
>
> Maybe the second commit lacks bpo-xxx, but it's not a big deal. I
> prefer smaller atomic commits when possible.
>
> 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170307/95fa60da/attachment.html>

From nad at python.org  Tue Mar  7 20:59:06 2017
From: nad at python.org (Ned Deily)
Date: Tue, 7 Mar 2017 20:59:06 -0500
Subject: [python-committers] 3.6.1 release status and plans
Message-ID: <FC705FCF-A61B-4948-8415-5A6DEF36BD89@python.org>

An update on the 3.6.1 release:  As you probably noticed, 3.6.1 release candidate 1 was made available (finally!) two days ago.  Thank you for your patience as we worked though the details of producing a release using our new GitHub-based development workflow.  As we've noted, it's really important for all segments of the community to try using 3.6.1rc1 to help make sure something didn't break along the way.  Please report any potential problems via the bugs.python.org tracker and mark them as "release blocker". 

Because rc1 was delayed a week, I've moved the planned release date for 3.6.1 final back a week as well, now 2017-03-20.  That gives two weeks of exposure for rc1.  The plan is to, if at all possible, not ship any additional changes in the final beyond what is already in rc1 unless we discover any release-blocking critical problems in rc1.  The 3.6 branch remains open for new cherry-pick PRs etc but you should expect that any PRs that are merged into the 3.6 branch since the v3.6.1rc1 tag will first be released in 3.6.2, expected before the end of June (about 3 months).

Again, if something critical comes up that you feel needs to be in 3.6.1, you need to make sure the issue is marked as a "release blocker" and you should make sure I am aware of it.  If any such release blockers do arise, we will discuss them and decide whether they should go into 3.6.1 and whether a second release candidate is needed.

Thanks for your support!

--Ned

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


From ncoghlan at gmail.com  Wed Mar  8 02:57:33 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 8 Mar 2017 17:57:33 +1000
Subject: [python-committers] [Python-Dev] 3.6.1 release status and plans
In-Reply-To: <FC705FCF-A61B-4948-8415-5A6DEF36BD89@python.org>
References: <FC705FCF-A61B-4948-8415-5A6DEF36BD89@python.org>
Message-ID: <CADiSq7evWrigFnb5R_ozga1YdB8LqeSRi_rg=2DorprUPoiv_g@mail.gmail.com>

On 8 March 2017 at 11:59, Ned Deily <nad at python.org> wrote:

> An update on the 3.6.1 release:  As you probably noticed, 3.6.1 release
> candidate 1 was made available (finally!) two days ago.  Thank you for your
> patience as we worked though the details of producing a release using our
> new GitHub-based development workflow.  As we've noted, it's really
> important for all segments of the community to try using 3.6.1rc1 to help
> make sure something didn't break along the way.  Please report any
> potential problems via the bugs.python.org tracker and mark them as
> "release blocker".
>
> Because rc1 was delayed a week, I've moved the planned release date for
> 3.6.1 final back a week as well, now 2017-03-20.  That gives two weeks of
> exposure for rc1.  The plan is to, if at all possible, not ship any
> additional changes in the final beyond what is already in rc1 unless we
> discover any release-blocking critical problems in rc1.  The 3.6 branch
> remains open for new cherry-pick PRs etc but you should expect that any PRs
> that are merged into the 3.6 branch since the v3.6.1rc1 tag will first be
> released in 3.6.2, expected before the end of June (about 3 months).
>

And if anyone notices some oddities with sys.path initialisation, we're
aware of them and are looking into it: http://bugs.python.org/issue29723
(it currently appears to be a case where a fix that worked as intended in
Windows is unexpectedly leaving the parent directory of the given directory
or archive on sys.path when running directories and zip archives on other
platforms).

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/20170308/2c5a4484/attachment.html>

From tjreedy at udel.edu  Wed Mar  8 03:43:54 2017
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 8 Mar 2017 03:43:54 -0500
Subject: [python-committers] 3.6.1 release status and plans
In-Reply-To: <FC705FCF-A61B-4948-8415-5A6DEF36BD89@python.org>
References: <FC705FCF-A61B-4948-8415-5A6DEF36BD89@python.org>
Message-ID: <977a07c7-b3f7-e6c3-6ca5-245edc1235d9@udel.edu>

On 3/7/2017 8:59 PM, Ned Deily wrote:
> An update on the 3.6.1 release:  As you probably noticed, 3.6.1 release candidate 1 was made available (finally!) two days ago.  Thank you for your patience as we worked though the details of producing a release using our new GitHub-based development workflow.  As we've noted, it's really important for all segments of the community to try using 3.6.1rc1 to help make sure something didn't break along the way.  Please report any potential problems via the bugs.python.org tracker and mark them as "release blocker".
>
> Because rc1 was delayed a week, I've moved the planned release date for 3.6.1 final back a week as well, now 2017-03-20.  That gives two weeks of exposure for rc1.  The plan is to, if at all possible, not ship any additional changes in the final beyond what is already in rc1 unless we discover any release-blocking critical problems in rc1.  The 3.6 branch remains open for new cherry-pick PRs etc but you should expect that any PRs that are merged into the 3.6 branch since the v3.6.1rc1 tag will first be released in 3.6.2, expected before the end of June (about 3 months).
>
> Again, if something critical comes up that you feel needs to be in 3.6.1, you need to make sure the issue is marked as a "release blocker" and you should make sure I am aware of it.  If any such release blockers do arise, we will discuss them and decide whether they should go into 3.6.1 and whether a second release candidate is needed.

Ned, 7 tests fail for me on Windows.  I believe 3.6.0 ran clean or 
nearly so.  Pasteing below is best I can do right now as I had eye 
operation less than 24 hours ago.
C:\Users\Terry>py -m test -j10 -ugui -v test_codecencodings_iso2022 
test_random test_re test_regrtest test_sax test_subprocess test_tools
== CPython 3.6.1rc1 
(v3.6.1rc1^0:e0fbe5feee4f9c00f09eb9659c2182183036261a, Mar 4 2017, 
20:00:12) [MSC v.1900 64 bit (AMD64)]
==   Windows-10-10.0.14393-SP0 little-endian
==   hash algorithm: siphash24 64bit
==  cwd: C:\Users\Terry\AppData\Local\Temp\test_python_8516
==  encodings: locale=cp1252, FS=utf-8
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, 
optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, 
ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, 
hash_randomization=1, isolated=0)
Run tests in parallel using 10 child processes
0:00:01 [1/7/1] test_codecencodings_iso2022 failed
test_callback_None_index 
(test.test_codecencodings_iso2022.Test_ISO2022_JP) ... ok
test_callback_backward_index 
(test.test_codecencodings_iso2022.Test_ISO2022_JP) ... ok
test_callback_forward_index 
(test.test_codecencodings_iso2022.Test_ISO2022_JP) ... ok
test_callback_index_outofbound 
(test.test_codecencodings_iso2022.Test_ISO2022_JP) ... ok
test_callback_long_index 
(test.test_codecencodings_iso2022.Test_ISO2022_JP) ... ok
test_callback_returns_bytes 
(test.test_codecencodings_iso2022.Test_ISO2022_JP) ... ok
test_callback_wrong_objects 
(test.test_codecencodings_iso2022.Test_ISO2022_JP) ... ok
test_chunkcoding (test.test_codecencodings_iso2022.Test_ISO2022_JP) ... ok
test_customreplace_encode 
(test.test_codecencodings_iso2022.Test_ISO2022_JP) ... ok
test_errorhandle (test.test_codecencodings_iso2022.Test_ISO2022_JP) ... ok
test_incrementaldecoder 
(test.test_codecencodings_iso2022.Test_ISO2022_JP) ... ok
test_incrementalencoder 
(test.test_codecencodings_iso2022.Test_ISO2022_JP) ... ok
test_incrementalencoder_error_callback 
(test.test_codecencodings_iso2022.Test_ISO2022_JP) ... ok
test_streamreader (test.test_codecencodings_iso2022.Test_ISO2022_JP) ... ok
test_streamwriter (test.test_codecencodings_iso2022.Test_ISO2022_JP) ... ok
test_streamwriter_reset_no_pending 
(test.test_codecencodings_iso2022.Test_ISO2022_JP) ... ok
test_xmlcharrefreplace 
(test.test_codecencodings_iso2022.Test_ISO2022_JP) ... ok
test_callback_None_index 
(test.test_codecencodings_iso2022.Test_ISO2022_JP2) ... ok
test_callback_backward_index 
(test.test_codecencodings_iso2022.Test_ISO2022_JP2) ... ok
test_callback_forward_index 
(test.test_codecencodings_iso2022.Test_ISO2022_JP2) ... ok
test_callback_index_outofbound 
(test.test_codecencodings_iso2022.Test_ISO2022_JP2) ... ok
test_callback_long_index 
(test.test_codecencodings_iso2022.Test_ISO2022_JP2) ... ok
test_callback_returns_bytes 
(test.test_codecencodings_iso2022.Test_ISO2022_JP2) ... ok
test_callback_wrong_objects 
(test.test_codecencodings_iso2022.Test_ISO2022_JP2) ... ok
test_chunkcoding (test.test_codecencodings_iso2022.Test_ISO2022_JP2) ... ok
test_customreplace_encode 
(test.test_codecencodings_iso2022.Test_ISO2022_JP2) ... ok
test_errorhandle (test.test_codecencodings_iso2022.Test_ISO2022_JP2) ... ok
test_incrementaldecoder 
(test.test_codecencodings_iso2022.Test_ISO2022_JP2) ... ok
test_incrementalencoder 
(test.test_codecencodings_iso2022.Test_ISO2022_JP2) ... ok
test_incrementalencoder_error_callback 
(test.test_codecencodings_iso2022.Test_ISO2022_JP2) ... ok
test_streamreader (test.test_codecencodings_iso2022.Test_ISO2022_JP2) ... ok
test_streamwriter (test.test_codecencodings_iso2022.Test_ISO2022_JP2) ... ok
test_streamwriter_reset_no_pending 
(test.test_codecencodings_iso2022.Test_ISO2022_JP2) ... ok
test_xmlcharrefreplace 
(test.test_codecencodings_iso2022.Test_ISO2022_JP2) ... ok
test_callback_None_index 
(test.test_codecencodings_iso2022.Test_ISO2022_KR) ... ok
test_callback_backward_index 
(test.test_codecencodings_iso2022.Test_ISO2022_KR) ... ok
test_callback_forward_index 
(test.test_codecencodings_iso2022.Test_ISO2022_KR) ... ok
test_callback_index_outofbound 
(test.test_codecencodings_iso2022.Test_ISO2022_KR) ... ok
test_callback_long_index 
(test.test_codecencodings_iso2022.Test_ISO2022_KR) ... ok
test_callback_returns_bytes 
(test.test_codecencodings_iso2022.Test_ISO2022_KR) ... ok
test_callback_wrong_objects 
(test.test_codecencodings_iso2022.Test_ISO2022_KR) ... ok
test_chunkcoding (test.test_codecencodings_iso2022.Test_ISO2022_KR) ... 
skipped 'iso2022_kr.txt cannot be used to test "chunk coding"'
test_customreplace_encode 
(test.test_codecencodings_iso2022.Test_ISO2022_KR) ... ok
test_errorhandle (test.test_codecencodings_iso2022.Test_ISO2022_KR) ... ok
test_incrementaldecoder 
(test.test_codecencodings_iso2022.Test_ISO2022_KR) ... FAIL
test_incrementalencoder 
(test.test_codecencodings_iso2022.Test_ISO2022_KR) ... FAIL
test_incrementalencoder_error_callback 
(test.test_codecencodings_iso2022.Test_ISO2022_KR) ... ok
test_streamreader (test.test_codecencodings_iso2022.Test_ISO2022_KR) ... 
FAIL
test_streamwriter (test.test_codecencodings_iso2022.Test_ISO2022_KR) ... 
FAIL
test_streamwriter_reset_no_pending 
(test.test_codecencodings_iso2022.Test_ISO2022_KR) ... ok
test_xmlcharrefreplace 
(test.test_codecencodings_iso2022.Test_ISO2022_KR) ... ok

======================================================================
FAIL: test_incrementaldecoder 
(test.test_codecencodings_iso2022.Test_ISO2022_KR)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "C:\Programs\Python36\lib\test\multibytecodec_support.py", line 
208, in test_incrementaldecoder
     self.assertEqual(ostream.getvalue(), self.tstring[1])
AssertionError: b'\xe[334 
chars]\x80\n\xed\x9a\xa8\xec\x9c\xa8\xec\xa0\x81\xec[1668 chars]4.\n' != 
b'\xe[334 chars]\x80\r\n\xed\x9a\xa8\xec\x9c\xa8\xec\xa0\x81\x[1682 
chars]\r\n'

======================================================================
FAIL: test_incrementalencoder 
(test.test_codecencodings_iso2022.Test_ISO2022_KR)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "C:\Programs\Python36\lib\test\multibytecodec_support.py", line 
191, in test_incrementalencoder
     self.assertEqual(ostream.getvalue(), self.tstring[0])
AssertionError: b"\x1[143 chars]\x0f\r\n\x0eH?@2@{@N\x0f \x0e0m<vAX\x0f 
\x0e5%[631 chars]\r\n" != b"\x1[143 chars]\x0f\n\x0eH?@2@{@N\x0f 
\x0e0m<vAX\x0f \x0e5%@L[617 chars]f.\n"

======================================================================
FAIL: test_streamreader (test.test_codecencodings_iso2022.Test_ISO2022_KR)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "C:\Programs\Python36\lib\test\multibytecodec_support.py", line 
247, in test_streamreader
     self.assertEqual(ostream.getvalue(), self.tstring[1])
AssertionError: b'\xe[334 
chars]\x80\n\xed\x9a\xa8\xec\x9c\xa8\xec\xa0\x81\xec[1668 chars]4.\n' != 
b'\xe[334 chars]\x80\r\n\xed\x9a\xa8\xec\x9c\xa8\xec\xa0\x81\x[1682 
chars]\r\n'

======================================================================
FAIL: test_streamwriter (test.test_codecencodings_iso2022.Test_ISO2022_KR)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "C:\Programs\Python36\lib\test\multibytecodec_support.py", line 
271, in test_streamwriter
     self.assertEqual(ostream.getvalue(), self.tstring[0])
AssertionError: b"\x1[143 chars]\x0f\r\n\x0eH?@2@{@N\x0f \x0e0m<vAX\x0f 
\x0e5%[631 chars]\r\n" != b"\x1[143 chars]\x0f\n\x0eH?@2@{@N\x0f 
\x0e0m<vAX\x0f \x0e5%@L[617 chars]f.\n"

----------------------------------------------------------------------
Ran 51 tests in 0.188s

FAILED (failures=4, skipped=1)
test test_codecencodings_iso2022 failed
0:00:06 [2/7/2] test_random failed
test_53_bits_per_float (test.test_random.MersenneTwister_TestBasicOps) 
... ok
test_autoseed (test.test_random.MersenneTwister_TestBasicOps) ... ok
test_bigrand (test.test_random.MersenneTwister_TestBasicOps) ... ok
test_bigrand_ranges (test.test_random.MersenneTwister_TestBasicOps) ... ok
test_bug_1727780 (test.test_random.MersenneTwister_TestBasicOps) ... ERROR
test_bug_27706 (test.test_random.MersenneTwister_TestBasicOps) ... ok
test_bug_9025 (test.test_random.MersenneTwister_TestBasicOps) ... ok
test_choice (test.test_random.MersenneTwister_TestBasicOps) ... ok
test_choices (test.test_random.MersenneTwister_TestBasicOps) ... ok
test_choices_algorithms (test.test_random.MersenneTwister_TestBasicOps) 
... ok
test_gauss (test.test_random.MersenneTwister_TestBasicOps) ... ok
test_genrandbits (test.test_random.MersenneTwister_TestBasicOps) ... ok
test_guaranteed_stable (test.test_random.MersenneTwister_TestBasicOps) 
... ok
test_long_seed (test.test_random.MersenneTwister_TestBasicOps) ... ok
test_pickling (test.test_random.MersenneTwister_TestBasicOps) ... ok
test_randbelow_logic (test.test_random.MersenneTwister_TestBasicOps) ... ok
test_randbelow_overridden_random 
(test.test_random.MersenneTwister_TestBasicOps) ... ok
test_randrange_bug_1590891 
(test.test_random.MersenneTwister_TestBasicOps) ... ok
test_rangelimits (test.test_random.MersenneTwister_TestBasicOps) ... ok
test_referenceImplementation 
(test.test_random.MersenneTwister_TestBasicOps) ... ok
test_sample (test.test_random.MersenneTwister_TestBasicOps) ... ok
test_sample_distribution (test.test_random.MersenneTwister_TestBasicOps) 
... ok
test_sample_inputs (test.test_random.MersenneTwister_TestBasicOps) ... ok
test_sample_on_dicts (test.test_random.MersenneTwister_TestBasicOps) ... ok
test_saverestore (test.test_random.MersenneTwister_TestBasicOps) ... ok
test_seed_when_randomness_source_not_found 
(test.test_random.MersenneTwister_TestBasicOps) ... ok
test_seedargs (test.test_random.MersenneTwister_TestBasicOps) ... ok
test_setstate_first_arg (test.test_random.MersenneTwister_TestBasicOps) 
... ok
test_setstate_middle_arg (test.test_random.MersenneTwister_TestBasicOps) 
... ok
test_shuffle (test.test_random.MersenneTwister_TestBasicOps) ... ok
test_strong_reference_implementation 
(test.test_random.MersenneTwister_TestBasicOps) ... ok
test_53_bits_per_float (test.test_random.SystemRandom_TestBasicOps) ... ok
test_autoseed (test.test_random.SystemRandom_TestBasicOps) ... ok
test_bigrand (test.test_random.SystemRandom_TestBasicOps) ... ok
test_bigrand_ranges (test.test_random.SystemRandom_TestBasicOps) ... ok
test_bug_1727780 (test.test_random.SystemRandom_TestBasicOps) ... ERROR
test_bug_9025 (test.test_random.SystemRandom_TestBasicOps) ... ok
test_choice (test.test_random.SystemRandom_TestBasicOps) ... ok
test_choices (test.test_random.SystemRandom_TestBasicOps) ... ok
test_gauss (test.test_random.SystemRandom_TestBasicOps) ... ok
test_genrandbits (test.test_random.SystemRandom_TestBasicOps) ... ok
test_pickling (test.test_random.SystemRandom_TestBasicOps) ... ok
test_randbelow_logic (test.test_random.SystemRandom_TestBasicOps) ... ok
test_randrange_errors (test.test_random.SystemRandom_TestBasicOps) ... ok
test_randrange_nonunit_step (test.test_random.SystemRandom_TestBasicOps) 
... ok
test_rangelimits (test.test_random.SystemRandom_TestBasicOps) ... ok
test_sample (test.test_random.SystemRandom_TestBasicOps) ... ok
test_sample_distribution (test.test_random.SystemRandom_TestBasicOps) ... ok
test_sample_inputs (test.test_random.SystemRandom_TestBasicOps) ... ok
test_sample_on_dicts (test.test_random.SystemRandom_TestBasicOps) ... ok
test_saverestore (test.test_random.SystemRandom_TestBasicOps) ... ok
test_seed_when_randomness_source_not_found 
(test.test_random.SystemRandom_TestBasicOps) ... ok
test_seedargs (test.test_random.SystemRandom_TestBasicOps) ... ok
test_shuffle (test.test_random.SystemRandom_TestBasicOps) ... ok
test_avg_std (test.test_random.TestDistributions) ... ok
test_betavariate_return_zero (test.test_random.TestDistributions) ... ok
test_constant (test.test_random.TestDistributions) ... ok
test_gammavariate_errors (test.test_random.TestDistributions) ... ok
test_gammavariate_full_code_coverage 
(test.test_random.TestDistributions) ... ok
test_von_mises_large_kappa (test.test_random.TestDistributions) ... ok
test_von_mises_range (test.test_random.TestDistributions) ... ok
test_zeroinputs (test.test_random.TestDistributions) ... ok
testMagicConstants (test.test_random.TestModule) ... ok
test__all__ (test.test_random.TestModule) ... ok
test_random_subclass_with_kwargs (test.test_random.TestModule) ... ok

======================================================================
ERROR: test_bug_1727780 (test.test_random.MersenneTwister_TestBasicOps)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "C:\Programs\Python36\lib\test\test_random.py", line 257, in 
test_bug_1727780
     r = pickle.load(f)
ModuleNotFoundError: No module named 'random\r'

======================================================================
ERROR: test_bug_1727780 (test.test_random.SystemRandom_TestBasicOps)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "C:\Programs\Python36\lib\test\test_random.py", line 257, in 
test_bug_1727780
     r = pickle.load(f)
ModuleNotFoundError: No module named 'random\r'

----------------------------------------------------------------------
Ran 65 tests in 0.813s

FAILED (errors=2)
test test_random failed
0:00:17 [3/7/3] test_re failed
test_re_benchmarks (test.test_re.ExternalTests)
re_tests benchmarks ... ok
test_re_tests (test.test_re.ExternalTests)
re_tests test suite ... ok
test_overlap_table (test.test_re.ImplementationTest) ... ok
test_bytes (test.test_re.PatternReprTests) ... ok
test_inline_flags (test.test_re.PatternReprTests) ... ok
test_locale (test.test_re.PatternReprTests) ... ok
test_long_pattern (test.test_re.PatternReprTests) ... ok
test_multiple_flags (test.test_re.PatternReprTests) ... ok
test_quotes (test.test_re.PatternReprTests) ... ok
test_single_flag (test.test_re.PatternReprTests) ... ok
test_unicode_flag (test.test_re.PatternReprTests) ... ok
test_unknown_flags (test.test_re.PatternReprTests) ... ok
test_without_flags (test.test_re.PatternReprTests) ... ok
test_anyall (test.test_re.ReTests) ... ok
test_ascii_and_unicode_flag (test.test_re.ReTests) ... ok
test_backref_group_name_in_exception (test.test_re.ReTests) ... ok
test_basic_re_sub (test.test_re.ReTests) ... ok
test_big_codesize (test.test_re.ReTests) ... ok
test_bigcharset (test.test_re.ReTests) ... ok
test_bug_113254 (test.test_re.ReTests) ... ok
test_bug_114660 (test.test_re.ReTests) ... ok
test_bug_117612 (test.test_re.ReTests) ... ok
test_bug_1661 (test.test_re.ReTests) ... ok
test_bug_16688 (test.test_re.ReTests) ... ok
test_bug_20998 (test.test_re.ReTests) ... ok
test_bug_2537 (test.test_re.ReTests) ... ok
test_bug_29444 (test.test_re.ReTests) ... ok
test_bug_3629 (test.test_re.ReTests) ... ok
test_bug_418626 (test.test_re.ReTests) ... ok
test_bug_448951 (test.test_re.ReTests) ... ok
test_bug_449000 (test.test_re.ReTests) ... ok
test_bug_449964 (test.test_re.ReTests) ... ok
test_bug_462270 (test.test_re.ReTests) ... ok
test_bug_527371 (test.test_re.ReTests) ... ok
test_bug_581080 (test.test_re.ReTests) ... ok
test_bug_612074 (test.test_re.ReTests) ... ok
test_bug_6509 (test.test_re.ReTests) ... ok
test_bug_6561 (test.test_re.ReTests) ... ok
test_bug_725106 (test.test_re.ReTests) ... ok
test_bug_725149 (test.test_re.ReTests) ... ok
test_bug_764548 (test.test_re.ReTests) ... ok
test_bug_817234 (test.test_re.ReTests) ... ok
test_bug_926075 (test.test_re.ReTests) ... ok
test_bug_931848 (test.test_re.ReTests) ... ok
test_bytes_str_mixing (test.test_re.ReTests) ... ok
test_category (test.test_re.ReTests) ... ok
test_character_set_errors (test.test_re.ReTests) ... ok
test_compile (test.test_re.ReTests) ... ok
test_constants (test.test_re.ReTests) ... ok
test_dealloc (test.test_re.ReTests) ... ok
test_debug_flag (test.test_re.ReTests) ... ok
test_dollar_matches_twice (test.test_re.ReTests)
$ matches the end of string, and just before the terminating ... ok
test_empty_array (test.test_re.ReTests) ... ok
test_enum (test.test_re.ReTests) ... ok
test_error (test.test_re.ReTests) ... ok
test_expand (test.test_re.ReTests) ... ok
test_finditer (test.test_re.ReTests) ... ok
test_flags (test.test_re.ReTests) ... ok
test_getattr (test.test_re.ReTests) ... ok
test_getlower (test.test_re.ReTests) ... ok
test_group (test.test_re.ReTests) ... ok
test_group_name_in_exception (test.test_re.ReTests) ... ok
test_groupdict (test.test_re.ReTests) ... ok
test_ignore_case (test.test_re.ReTests) ... ok
test_ignore_case_range (test.test_re.ReTests) ... ok
test_ignore_case_set (test.test_re.ReTests) ... ok
test_inline_flags (test.test_re.ReTests) ... ok
test_issue17998 (test.test_re.ReTests) ... ok
test_keep_buffer (test.test_re.ReTests) ... ok
test_keyword_parameters (test.test_re.ReTests) ... ok
test_large_search (test.test_re.ReTests) ... ok
test_large_subn (test.test_re.ReTests) ... ok
test_locale_caching (test.test_re.ReTests) ... skipped 'test needs 
en_US.iso88591 locale'
test_locale_flag (test.test_re.ReTests) ... FAIL
test_lookahead (test.test_re.ReTests) ... ok
test_lookbehind (test.test_re.ReTests) ... ok
test_match_getitem (test.test_re.ReTests) ... ok
test_match_repr (test.test_re.ReTests) ... ok
test_misc_errors (test.test_re.ReTests) ... ok
test_multiple_repeat (test.test_re.ReTests) ... ok
test_not_literal (test.test_re.ReTests) ... ok
test_nothing_to_repeat (test.test_re.ReTests) ... ok
test_other_escapes (test.test_re.ReTests) ... ok
test_pattern_compare (test.test_re.ReTests) ... ok
test_pattern_compare_bytes (test.test_re.ReTests) ... ok
test_pickling (test.test_re.ReTests) ... ok
test_qualified_re_split (test.test_re.ReTests) ... ok
test_qualified_re_sub (test.test_re.ReTests) ... ok
test_re_escape (test.test_re.ReTests) ... ok
test_re_escape_byte (test.test_re.ReTests) ... ok
test_re_escape_non_ascii (test.test_re.ReTests) ... ok
test_re_escape_non_ascii_bytes (test.test_re.ReTests) ... ok
test_re_findall (test.test_re.ReTests) ... ok
test_re_fullmatch (test.test_re.ReTests) ... ok
test_re_groupref (test.test_re.ReTests) ... ok
test_re_groupref_exists (test.test_re.ReTests) ... ok
test_re_groupref_overflow (test.test_re.ReTests) ... ok
test_re_match (test.test_re.ReTests) ... ok
test_re_split (test.test_re.ReTests) ... ok
test_re_subn (test.test_re.ReTests) ... ok
test_repeat_minmax (test.test_re.ReTests) ... ok
test_repeat_minmax_overflow (test.test_re.ReTests) ... ok
test_repeat_minmax_overflow_maxrepeat (test.test_re.ReTests) ... ok
test_scanner (test.test_re.ReTests) ... ok
test_scoped_flags (test.test_re.ReTests) ... ok
test_search_coverage (test.test_re.ReTests) ... ok
test_search_dot_unicode (test.test_re.ReTests) ... ok
test_search_star_plus (test.test_re.ReTests) ... ok
test_special_escapes (test.test_re.ReTests) ... ok
test_sre_byte_class_literals (test.test_re.ReTests) ... ok
test_sre_byte_literals (test.test_re.ReTests) ... ok
test_sre_character_class_literals (test.test_re.ReTests) ... ok
test_sre_character_literals (test.test_re.ReTests) ... ok
test_stack_overflow (test.test_re.ReTests) ... ok
test_string_boundaries (test.test_re.ReTests) ... ok
test_sub_template_numeric_escape (test.test_re.ReTests) ... ok
test_symbolic_groups (test.test_re.ReTests) ... ok
test_symbolic_refs (test.test_re.ReTests) ... ok
test_unlimited_zero_width_repeat (test.test_re.ReTests) ... ok
test_weakref (test.test_re.ReTests) ... ok

======================================================================
FAIL: test_locale_flag (test.test_re.ReTests)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "C:\Programs\Python36\lib\test\test_re.py", line 1425, in 
test_locale_flag
     self.assertTrue(pat.match(bletter))
AssertionError: None is not true

----------------------------------------------------------------------
Ran 120 tests in 0.799s

FAILED (failures=1, skipped=1)
test test_re failed
0:00:17 [4/7/4] test_tools failed
test_alter_comments (test.test_tools.test_fixcid.Test) ... ok
test_directory (test.test_tools.test_fixcid.Test) ... ok
test_parse_strings (test.test_tools.test_fixcid.Test) ... ok
test_gprof (test.test_tools.test_gprof2html.Gprof2htmlTests) ... ok
test_POT_Creation_Date (test.test_tools.test_i18n.Test_pygettext)
Match the date format from xgettext for POT-Creation-Date ... ok
test_header (test.test_tools.test_i18n.Test_pygettext)
Make sure the required fields are in the header, according to: ... ok
test_checksum_fodder (test.test_tools.test_md5sum.MD5SumTests) ... ok
test_dash_l (test.test_tools.test_md5sum.MD5SumTests) ... ok
test_dash_s (test.test_tools.test_md5sum.MD5SumTests) ... ok
test_dash_t (test.test_tools.test_md5sum.MD5SumTests) ... ok
test_multiple_files (test.test_tools.test_md5sum.MD5SumTests) ... ok
test_noargs (test.test_tools.test_md5sum.MD5SumTests) ... ok
test_usage (test.test_tools.test_md5sum.MD5SumTests) ... ok
test_inverse_attribute_error (test.test_tools.test_pdeps.PdepsTests) ... ok
test_process_errors (test.test_tools.test_pdeps.PdepsTests) ... ok
test_empty_line (test.test_tools.test_pindent.PindentTests) ... ok
test_escaped_newline (test.test_tools.test_pindent.PindentTests) ... ok
test_multilevel (test.test_tools.test_pindent.PindentTests) ... ok
test_oneline (test.test_tools.test_pindent.PindentTests) ... ok
test_preserve_indents (test.test_tools.test_pindent.PindentTests) ... ok
test_selftest (test.test_tools.test_pindent.PindentTests) ... ok
test_statements (test.test_tools.test_pindent.PindentTests) ... ok
test_help (test.test_tools.test_reindent.ReindentTests) ... ok
test_noargs (test.test_tools.test_reindent.ReindentTests) ... ok
test_analyze_dxp_import (test.test_tools.test_sundry.TestSundryScripts) 
... ok
test_sundry (test.test_tools.test_sundry.TestSundryScripts) ... ERROR
test_sundry_windows (test.test_tools.test_sundry.TestSundryScripts) ... ok
test_files (test.test_tools.test_unparse.DirectoryTestCase) ... Testing 
C:\Programs\Python36\Lib\test\test_userlist.py
Testing C:\Programs\Python36\Lib\test\test_unicodedata.py
Testing C:\Programs\Python36\Lib\compileall.py
Testing C:\Programs\Python36\Lib\test\test_scope.py
Testing C:\Programs\Python36\Lib\test\test_cgitb.py
Testing C:\Programs\Python36\Lib\test\test_wsgiref.py
Testing C:\Programs\Python36\Lib\test\test_zipapp.py
Testing C:\Programs\Python36\Lib\test\test_dynamic.py
Testing C:\Programs\Python36\Lib\test\test_tk.py
Testing C:\Programs\Python36\Lib\test\test_configparser.py
ok
test_annotations (test.test_tools.test_unparse.UnparseTestCase) ... ok
test_bytes (test.test_tools.test_unparse.UnparseTestCase) ... ok
test_chained_comparisons (test.test_tools.test_unparse.UnparseTestCase) 
... ok
test_class_decorators (test.test_tools.test_unparse.UnparseTestCase) ... ok
test_class_definition (test.test_tools.test_unparse.UnparseTestCase) ... ok
test_del_statement (test.test_tools.test_unparse.UnparseTestCase) ... ok
test_dict_comprehension (test.test_tools.test_unparse.UnparseTestCase) 
... ok
test_dict_unpacking_in_dict 
(test.test_tools.test_unparse.UnparseTestCase) ... ok
test_elifs (test.test_tools.test_unparse.UnparseTestCase) ... ok
test_for_else (test.test_tools.test_unparse.UnparseTestCase) ... ok
test_fstrings (test.test_tools.test_unparse.UnparseTestCase) ... ok
test_function_arguments (test.test_tools.test_unparse.UnparseTestCase) 
... ok
test_huge_float (test.test_tools.test_unparse.UnparseTestCase) ... ok
test_imaginary_literals (test.test_tools.test_unparse.UnparseTestCase) 
... ok
test_integer_parens (test.test_tools.test_unparse.UnparseTestCase) ... ok
test_lambda_parentheses (test.test_tools.test_unparse.UnparseTestCase) 
... ok
test_min_int (test.test_tools.test_unparse.UnparseTestCase) ... ok
test_nonlocal (test.test_tools.test_unparse.UnparseTestCase) ... ok
test_raise_from (test.test_tools.test_unparse.UnparseTestCase) ... ok
test_relative_import (test.test_tools.test_unparse.UnparseTestCase) ... ok
test_set_comprehension (test.test_tools.test_unparse.UnparseTestCase) ... ok
test_set_literal (test.test_tools.test_unparse.UnparseTestCase) ... ok
test_shifts (test.test_tools.test_unparse.UnparseTestCase) ... ok
test_starred_assignment (test.test_tools.test_unparse.UnparseTestCase) 
... ok
test_try_except_finally (test.test_tools.test_unparse.UnparseTestCase) 
... ok
test_unary_parens (test.test_tools.test_unparse.UnparseTestCase) ... ok
test_while_else (test.test_tools.test_unparse.UnparseTestCase) ... ok
test_with_as (test.test_tools.test_unparse.UnparseTestCase) ... ok
test_with_simple (test.test_tools.test_unparse.UnparseTestCase) ... ok
test_with_two_items (test.test_tools.test_unparse.UnparseTestCase) ... ok

======================================================================
ERROR: test_sundry (test.test_tools.test_sundry.TestSundryScripts)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "C:\Programs\Python36\lib\optparse.py", line 1387, in parse_args
     stop = self._process_args(largs, rargs, values)
   File "C:\Programs\Python36\lib\optparse.py", line 1427, in _process_args
     self._process_long_opt(rargs, values)
   File "C:\Programs\Python36\lib\optparse.py", line 1480, in 
_process_long_opt
     opt = self._match_long_opt(opt)
   File "C:\Programs\Python36\lib\optparse.py", line 1465, in 
_match_long_opt
     return _match_abbrev(opt, self._long_opt)
   File "C:\Programs\Python36\lib\optparse.py", line 1670, in _match_abbrev
     raise BadOptionError(s)
optparse.BadOptionError: no such option: --slaveargs

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
   File "C:\Programs\Python36\lib\test\test_tools\test_sundry.py", line 
36, in test_sundry
     import_tool(name)
   File "C:\Programs\Python36\lib\test\test_tools\__init__.py", line 21, 
in import_tool
     return importlib.import_module(toolname)
   File "C:\Programs\Python36\lib\importlib\__init__.py", line 126, in 
import_module
     return _bootstrap._gcd_import(name[level:], package, level)
   File "<frozen importlib._bootstrap>", line 978, in _gcd_import
   File "<frozen importlib._bootstrap>", line 961, in _find_and_load
   File "<frozen importlib._bootstrap>", line 950, in 
_find_and_load_unlocked
   File "<frozen importlib._bootstrap>", line 655, in _load_unlocked
   File "<frozen importlib._bootstrap_external>", line 678, in exec_module
   File "<frozen importlib._bootstrap>", line 205, in 
_call_with_frames_removed
   File "C:\Programs\Python36\Tools\scripts\2to3.py", line 5, in <module>
     sys.exit(main("lib2to3.fixes"))
   File "C:\Programs\Python36\lib\lib2to3\main.py", line 179, in main
     options, args = parser.parse_args(args)
   File "C:\Programs\Python36\lib\optparse.py", line 1389, in parse_args
     self.error(str(err))
   File "C:\Programs\Python36\lib\optparse.py", line 1569, in error
     self.exit(2, "%s: error: %s\n" % (self.get_prog_name(), msg))
   File "C:\Programs\Python36\lib\optparse.py", line 1559, in exit
     sys.exit(status)
SystemExit: 2

----------------------------------------------------------------------
Ran 58 tests in 2.730s

FAILED (errors=1)
Usage: 2to3 [options] file|dir ...

regrtest.py: error: no such option: --slaveargs
test test_tools failed
0:00:17 [5/7/5] test_regrtest failed
test_coverage (test.test_regrtest.ArgsTestCase) ... ok
test_failing_test (test.test_regrtest.ArgsTestCase) ... ok
test_forever (test.test_regrtest.ArgsTestCase) ... ok
test_fromfile (test.test_regrtest.ArgsTestCase) ... ok
test_huntrleaks_fd_leak (test.test_regrtest.ArgsTestCase) ... skipped 
'need a debug build'
test_interrupted (test.test_regrtest.ArgsTestCase) ... ok
test_list_tests (test.test_regrtest.ArgsTestCase) ... ok
test_random (test.test_regrtest.ArgsTestCase) ... ok
test_resources (test.test_regrtest.ArgsTestCase) ... ok
test_slow_interrupted (test.test_regrtest.ArgsTestCase) ... ok
test_slowest (test.test_regrtest.ArgsTestCase) ... ok
test_wait (test.test_regrtest.ArgsTestCase) ... ok
test_arg (test.test_regrtest.ParseArgsTestCase) ... ok
test_arg_option_arg (test.test_regrtest.ParseArgsTestCase) ... ok
test_coverage (test.test_regrtest.ParseArgsTestCase) ... ok
test_coverdir (test.test_regrtest.ParseArgsTestCase) ... ok
test_exclude (test.test_regrtest.ParseArgsTestCase) ... ok
test_failfast (test.test_regrtest.ParseArgsTestCase) ... ok
test_forever (test.test_regrtest.ParseArgsTestCase) ... ok
test_fromfile (test.test_regrtest.ParseArgsTestCase) ... ok
test_header (test.test_regrtest.ParseArgsTestCase) ... ok
test_help (test.test_regrtest.ParseArgsTestCase) ... ok
test_huntrleaks (test.test_regrtest.ParseArgsTestCase) ... ok
test_long_option__partial (test.test_regrtest.ParseArgsTestCase) ... ok
test_match (test.test_regrtest.ParseArgsTestCase) ... ok
test_memlimit (test.test_regrtest.ParseArgsTestCase) ... ok
test_multiprocess (test.test_regrtest.ParseArgsTestCase) ... ok
test_nocoverdir (test.test_regrtest.ParseArgsTestCase) ... ok
test_nowindows (test.test_regrtest.ParseArgsTestCase) ... ok
test_option_and_arg (test.test_regrtest.ParseArgsTestCase) ... ok
test_option_with_empty_string_value 
(test.test_regrtest.ParseArgsTestCase) ... ok
test_quiet (test.test_regrtest.ParseArgsTestCase) ... ok
test_randomize (test.test_regrtest.ParseArgsTestCase) ... ok
test_randseed (test.test_regrtest.ParseArgsTestCase) ... ok
test_runleaks (test.test_regrtest.ParseArgsTestCase) ... ok
test_single (test.test_regrtest.ParseArgsTestCase) ... ok
test_slaveargs (test.test_regrtest.ParseArgsTestCase) ... ok
test_slow (test.test_regrtest.ParseArgsTestCase) ... ok
test_start (test.test_regrtest.ParseArgsTestCase) ... ok
test_testdir (test.test_regrtest.ParseArgsTestCase) ... ok
test_threshold (test.test_regrtest.ParseArgsTestCase) ... ok
test_timeout (test.test_regrtest.ParseArgsTestCase) ... ok
test_two_options (test.test_regrtest.ParseArgsTestCase) ... ok
test_unknown_option (test.test_regrtest.ParseArgsTestCase) ... ok
test_unrecognized_argument (test.test_regrtest.ParseArgsTestCase) ... ok
test_use (test.test_regrtest.ParseArgsTestCase) ... ok
test_verbose (test.test_regrtest.ParseArgsTestCase) ... ok
test_verbose2 (test.test_regrtest.ParseArgsTestCase) ... ok
test_verbose3 (test.test_regrtest.ParseArgsTestCase) ... ok
test_wait (test.test_regrtest.ParseArgsTestCase) ... ok
test_module_autotest (test.test_regrtest.ProgramsTestCase) ... ok
test_module_from_test_autotest (test.test_regrtest.ProgramsTestCase) ... ok
test_module_regrtest (test.test_regrtest.ProgramsTestCase) ... ok
test_module_test (test.test_regrtest.ProgramsTestCase) ... ok
test_pcbuild_rt (test.test_regrtest.ProgramsTestCase) ... ERROR
test_script_autotest (test.test_regrtest.ProgramsTestCase) ... ok
test_script_regrtest (test.test_regrtest.ProgramsTestCase) ... ok
test_tools_buildbot_test (test.test_regrtest.ProgramsTestCase) ... 
skipped 'test.bat script is not installed'
test_tools_script_run_tests (test.test_regrtest.ProgramsTestCase) ... 
skipped 'run_tests.py script is not installed'

======================================================================
ERROR: test_pcbuild_rt (test.test_regrtest.ProgramsTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "C:\Programs\Python36\lib\test\test_regrtest.py", line 566, in 
test_pcbuild_rt
     self.run_batch(script, *rt_args, *self.regrtest_args, *self.tests)
   File "C:\Programs\Python36\lib\test\test_regrtest.py", line 541, in 
run_batch
     proc = self.run_command(args)
   File "C:\Programs\Python36\lib\test\test_regrtest.py", line 438, in 
run_command
     **kw)
   File "C:\Programs\Python36\lib\subprocess.py", line 403, in run
     with Popen(*popenargs, **kwargs) as process:
   File "C:\Programs\Python36\lib\subprocess.py", line 707, in __init__
     restore_signals, start_new_session)
   File "C:\Programs\Python36\lib\subprocess.py", line 990, in 
_execute_child
     startupinfo)
FileNotFoundError: [WinError 2] The system cannot find the file specified

----------------------------------------------------------------------
Ran 59 tests in 6.175s

FAILED (errors=1, skipped=3)
test test_regrtest failed
0:00:17 [6/7/6] test_sax failed
test_make_parser2 (test.test_sax.MakeParserTest) ... ok
test_parseString_bytes (test.test_sax.ParseTest) ... ok
test_parseString_text (test.test_sax.ParseTest) ... ok
test_parse_InputSource (test.test_sax.ParseTest) ... ok
test_parse_bytes (test.test_sax.ParseTest) ... ok
test_parse_text (test.test_sax.ParseTest) ... ok
test_double_quoteattr (test.test_sax.SaxutilsTest) ... ok
test_escape_all (test.test_sax.SaxutilsTest) ... ok
test_escape_basic (test.test_sax.SaxutilsTest) ... ok
test_escape_extra (test.test_sax.SaxutilsTest) ... ok
test_make_parser (test.test_sax.SaxutilsTest) ... ok
test_quoteattr_basic (test.test_sax.SaxutilsTest) ... ok
test_single_double_quoteattr (test.test_sax.SaxutilsTest) ... ok
test_single_quoteattr (test.test_sax.SaxutilsTest) ... ok
test_unescape_all (test.test_sax.SaxutilsTest) ... ok
test_unescape_amp_extra (test.test_sax.SaxutilsTest) ... ok
test_unescape_basic (test.test_sax.SaxutilsTest) ... ok
test_unescape_extra (test.test_sax.SaxutilsTest) ... ok
test_binary_file (test.test_sax.PrepareInputSourceTest) ... ok
test_byte_stream (test.test_sax.PrepareInputSourceTest) ... ok
test_character_stream (test.test_sax.PrepareInputSourceTest) ... ok
test_string (test.test_sax.PrepareInputSourceTest) ... ok
test_system_id (test.test_sax.PrepareInputSourceTest) ... ok
test_text_file (test.test_sax.PrepareInputSourceTest) ... ok
test_1463026_1 (test.test_sax.StringXmlgenTest) ... ok
test_1463026_1_empty (test.test_sax.StringXmlgenTest) ... ok
test_1463026_2 (test.test_sax.StringXmlgenTest) ... ok
test_1463026_2_empty (test.test_sax.StringXmlgenTest) ... ok
test_1463026_3 (test.test_sax.StringXmlgenTest) ... ok
test_1463026_3_empty (test.test_sax.StringXmlgenTest) ... ok
test_5027_1 (test.test_sax.StringXmlgenTest) ... ok
test_5027_2 (test.test_sax.StringXmlgenTest) ... ok
test_no_close_file (test.test_sax.StringXmlgenTest) ... ok
test_xmlgen_attr_escape (test.test_sax.StringXmlgenTest) ... ok
test_xmlgen_basic (test.test_sax.StringXmlgenTest) ... ok
test_xmlgen_basic_empty (test.test_sax.StringXmlgenTest) ... ok
test_xmlgen_content (test.test_sax.StringXmlgenTest) ... ok
test_xmlgen_content_empty (test.test_sax.StringXmlgenTest) ... ok
test_xmlgen_content_escape (test.test_sax.StringXmlgenTest) ... ok
test_xmlgen_encoding (test.test_sax.StringXmlgenTest) ... ok
test_xmlgen_encoding_bytes (test.test_sax.StringXmlgenTest) ... ok
test_xmlgen_fragment (test.test_sax.StringXmlgenTest) ... ok
test_xmlgen_ignorable (test.test_sax.StringXmlgenTest) ... ok
test_xmlgen_ignorable_empty (test.test_sax.StringXmlgenTest) ... ok
test_xmlgen_ns (test.test_sax.StringXmlgenTest) ... ok
test_xmlgen_ns_empty (test.test_sax.StringXmlgenTest) ... ok
test_xmlgen_pi (test.test_sax.StringXmlgenTest) ... ok
test_1463026_1 (test.test_sax.BytesXmlgenTest) ... ok
test_1463026_1_empty (test.test_sax.BytesXmlgenTest) ... ok
test_1463026_2 (test.test_sax.BytesXmlgenTest) ... ok
test_1463026_2_empty (test.test_sax.BytesXmlgenTest) ... ok
test_1463026_3 (test.test_sax.BytesXmlgenTest) ... ok
test_1463026_3_empty (test.test_sax.BytesXmlgenTest) ... ok
test_5027_1 (test.test_sax.BytesXmlgenTest) ... ok
test_5027_2 (test.test_sax.BytesXmlgenTest) ... ok
test_no_close_file (test.test_sax.BytesXmlgenTest) ... ok
test_xmlgen_attr_escape (test.test_sax.BytesXmlgenTest) ... ok
test_xmlgen_basic (test.test_sax.BytesXmlgenTest) ... ok
test_xmlgen_basic_empty (test.test_sax.BytesXmlgenTest) ... ok
test_xmlgen_content (test.test_sax.BytesXmlgenTest) ... ok
test_xmlgen_content_empty (test.test_sax.BytesXmlgenTest) ... ok
test_xmlgen_content_escape (test.test_sax.BytesXmlgenTest) ... ok
test_xmlgen_encoding (test.test_sax.BytesXmlgenTest) ... ok
test_xmlgen_encoding_bytes (test.test_sax.BytesXmlgenTest) ... ok
test_xmlgen_fragment (test.test_sax.BytesXmlgenTest) ... ok
test_xmlgen_ignorable (test.test_sax.BytesXmlgenTest) ... ok
test_xmlgen_ignorable_empty (test.test_sax.BytesXmlgenTest) ... ok
test_xmlgen_ns (test.test_sax.BytesXmlgenTest) ... ok
test_xmlgen_ns_empty (test.test_sax.BytesXmlgenTest) ... ok
test_xmlgen_pi (test.test_sax.BytesXmlgenTest) ... ok
test_xmlgen_unencodable (test.test_sax.BytesXmlgenTest) ... ok
test_1463026_1 (test.test_sax.WriterXmlgenTest) ... ok
test_1463026_1_empty (test.test_sax.WriterXmlgenTest) ... ok
test_1463026_2 (test.test_sax.WriterXmlgenTest) ... ok
test_1463026_2_empty (test.test_sax.WriterXmlgenTest) ... ok
test_1463026_3 (test.test_sax.WriterXmlgenTest) ... ok
test_1463026_3_empty (test.test_sax.WriterXmlgenTest) ... ok
test_5027_1 (test.test_sax.WriterXmlgenTest) ... ok
test_5027_2 (test.test_sax.WriterXmlgenTest) ... ok
test_no_close_file (test.test_sax.WriterXmlgenTest) ... ok
test_xmlgen_attr_escape (test.test_sax.WriterXmlgenTest) ... ok
test_xmlgen_basic (test.test_sax.WriterXmlgenTest) ... ok
test_xmlgen_basic_empty (test.test_sax.WriterXmlgenTest) ... ok
test_xmlgen_content (test.test_sax.WriterXmlgenTest) ... ok
test_xmlgen_content_empty (test.test_sax.WriterXmlgenTest) ... ok
test_xmlgen_content_escape (test.test_sax.WriterXmlgenTest) ... ok
test_xmlgen_encoding (test.test_sax.WriterXmlgenTest) ... ok
test_xmlgen_encoding_bytes (test.test_sax.WriterXmlgenTest) ... ok
test_xmlgen_fragment (test.test_sax.WriterXmlgenTest) ... ok
test_xmlgen_ignorable (test.test_sax.WriterXmlgenTest) ... ok
test_xmlgen_ignorable_empty (test.test_sax.WriterXmlgenTest) ... ok
test_xmlgen_ns (test.test_sax.WriterXmlgenTest) ... ok
test_xmlgen_ns_empty (test.test_sax.WriterXmlgenTest) ... ok
test_xmlgen_pi (test.test_sax.WriterXmlgenTest) ... ok
test_xmlgen_unencodable (test.test_sax.WriterXmlgenTest) ... ok
test_1463026_1 (test.test_sax.StreamWriterXmlgenTest) ... ok
test_1463026_1_empty (test.test_sax.StreamWriterXmlgenTest) ... ok
test_1463026_2 (test.test_sax.StreamWriterXmlgenTest) ... ok
test_1463026_2_empty (test.test_sax.StreamWriterXmlgenTest) ... ok
test_1463026_3 (test.test_sax.StreamWriterXmlgenTest) ... ok
test_1463026_3_empty (test.test_sax.StreamWriterXmlgenTest) ... ok
test_5027_1 (test.test_sax.StreamWriterXmlgenTest) ... ok
test_5027_2 (test.test_sax.StreamWriterXmlgenTest) ... ok
test_no_close_file (test.test_sax.StreamWriterXmlgenTest) ... ok
test_xmlgen_attr_escape (test.test_sax.StreamWriterXmlgenTest) ... ok
test_xmlgen_basic (test.test_sax.StreamWriterXmlgenTest) ... ok
test_xmlgen_basic_empty (test.test_sax.StreamWriterXmlgenTest) ... ok
test_xmlgen_content (test.test_sax.StreamWriterXmlgenTest) ... ok
test_xmlgen_content_empty (test.test_sax.StreamWriterXmlgenTest) ... ok
test_xmlgen_content_escape (test.test_sax.StreamWriterXmlgenTest) ... ok
test_xmlgen_encoding (test.test_sax.StreamWriterXmlgenTest) ... ok
test_xmlgen_encoding_bytes (test.test_sax.StreamWriterXmlgenTest) ... ok
test_xmlgen_fragment (test.test_sax.StreamWriterXmlgenTest) ... ok
test_xmlgen_ignorable (test.test_sax.StreamWriterXmlgenTest) ... ok
test_xmlgen_ignorable_empty (test.test_sax.StreamWriterXmlgenTest) ... ok
test_xmlgen_ns (test.test_sax.StreamWriterXmlgenTest) ... ok
test_xmlgen_ns_empty (test.test_sax.StreamWriterXmlgenTest) ... ok
test_xmlgen_pi (test.test_sax.StreamWriterXmlgenTest) ... ok
test_xmlgen_unencodable (test.test_sax.StreamWriterXmlgenTest) ... ok
test_1463026_1 (test.test_sax.StreamReaderWriterXmlgenTest) ... ok
test_1463026_1_empty (test.test_sax.StreamReaderWriterXmlgenTest) ... ok
test_1463026_2 (test.test_sax.StreamReaderWriterXmlgenTest) ... ok
test_1463026_2_empty (test.test_sax.StreamReaderWriterXmlgenTest) ... ok
test_1463026_3 (test.test_sax.StreamReaderWriterXmlgenTest) ... ok
test_1463026_3_empty (test.test_sax.StreamReaderWriterXmlgenTest) ... ok
test_5027_1 (test.test_sax.StreamReaderWriterXmlgenTest) ... ok
test_5027_2 (test.test_sax.StreamReaderWriterXmlgenTest) ... ok
test_no_close_file (test.test_sax.StreamReaderWriterXmlgenTest) ... ok
test_xmlgen_attr_escape (test.test_sax.StreamReaderWriterXmlgenTest) ... ok
test_xmlgen_basic (test.test_sax.StreamReaderWriterXmlgenTest) ... ok
test_xmlgen_basic_empty (test.test_sax.StreamReaderWriterXmlgenTest) ... ok
test_xmlgen_content (test.test_sax.StreamReaderWriterXmlgenTest) ... ok
test_xmlgen_content_empty (test.test_sax.StreamReaderWriterXmlgenTest) 
... ok
test_xmlgen_content_escape (test.test_sax.StreamReaderWriterXmlgenTest) 
... ok
test_xmlgen_encoding (test.test_sax.StreamReaderWriterXmlgenTest) ... ok
test_xmlgen_encoding_bytes (test.test_sax.StreamReaderWriterXmlgenTest) 
... ok
test_xmlgen_fragment (test.test_sax.StreamReaderWriterXmlgenTest) ... ok
test_xmlgen_ignorable (test.test_sax.StreamReaderWriterXmlgenTest) ... ok
test_xmlgen_ignorable_empty (test.test_sax.StreamReaderWriterXmlgenTest) 
... ok
test_xmlgen_ns (test.test_sax.StreamReaderWriterXmlgenTest) ... ok
test_xmlgen_ns_empty (test.test_sax.StreamReaderWriterXmlgenTest) ... ok
test_xmlgen_pi (test.test_sax.StreamReaderWriterXmlgenTest) ... ok
test_xmlgen_unencodable (test.test_sax.StreamReaderWriterXmlgenTest) ... ok
test_expat_attrs_empty (test.test_sax.ExpatReaderTest) ... ok
test_expat_attrs_wattr (test.test_sax.ExpatReaderTest) ... ok
test_expat_binary_file (test.test_sax.ExpatReaderTest) ... FAIL
test_expat_binary_file_bytes_name (test.test_sax.ExpatReaderTest) ... FAIL
test_expat_binary_file_int_name (test.test_sax.ExpatReaderTest) ... FAIL
test_expat_binary_file_nonascii (test.test_sax.ExpatReaderTest) ... FAIL
test_expat_dtdhandler (test.test_sax.ExpatReaderTest) ... ok
test_expat_entityresolver (test.test_sax.ExpatReaderTest) ... ok
test_expat_incremental (test.test_sax.ExpatReaderTest) ... ok
test_expat_incremental_reset (test.test_sax.ExpatReaderTest) ... ok
test_expat_inpsource_byte_stream (test.test_sax.ExpatReaderTest) ... FAIL
test_expat_inpsource_character_stream (test.test_sax.ExpatReaderTest) 
... FAIL
test_expat_inpsource_filename (test.test_sax.ExpatReaderTest) ... FAIL
test_expat_inpsource_sysid (test.test_sax.ExpatReaderTest) ... FAIL
test_expat_inpsource_sysid_nonascii (test.test_sax.ExpatReaderTest) ... FAIL
test_expat_locator_noinfo (test.test_sax.ExpatReaderTest) ... ok
test_expat_locator_withinfo (test.test_sax.ExpatReaderTest) ... ok
test_expat_locator_withinfo_nonascii (test.test_sax.ExpatReaderTest) ... ok
test_expat_nsattrs_empty (test.test_sax.ExpatReaderTest) ... ok
test_expat_nsattrs_wattr (test.test_sax.ExpatReaderTest) ... ok
test_expat_text_file (test.test_sax.ExpatReaderTest) ... FAIL
test_expat_incomplete (test.test_sax.ErrorReportingTest) ... ok
test_expat_inpsource_location (test.test_sax.ErrorReportingTest) ... ok
test_sax_parse_exception_str (test.test_sax.ErrorReportingTest) ... ok
test_attrs_empty (test.test_sax.XmlReaderTest) ... ok
test_attrs_wattr (test.test_sax.XmlReaderTest) ... ok
test_nsattrs_empty (test.test_sax.XmlReaderTest) ... ok
test_nsattrs_wattr (test.test_sax.XmlReaderTest) ... ok

======================================================================
FAIL: test_expat_binary_file (test.test_sax.ExpatReaderTest)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "C:\Programs\Python36\lib\test\test_sax.py", line 836, in 
test_expat_binary_file
     self.assertEqual(result.getvalue(), xml_test_out)
AssertionError: b'<?x[36 chars]1"?>\n<HTML 
xmlns:pp="http://www.isogen.com/pa[1508 chars]TML>' != b'<?x[36 
chars]1"?>\r\n<HTML xmlns:pp="http://www.isogen.com/[1736 chars]TML>'

======================================================================
FAIL: test_expat_binary_file_bytes_name (test.test_sax.ExpatReaderTest)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "C:\Programs\Python36\lib\test\test_sax.py", line 874, in 
test_expat_binary_file_bytes_name
     self.assertEqual(result.getvalue(), xml_test_out)
AssertionError: b'<?x[36 chars]1"?>\n<HTML 
xmlns:pp="http://www.isogen.com/pa[1508 chars]TML>' != b'<?x[36 
chars]1"?>\r\n<HTML xmlns:pp="http://www.isogen.com/[1736 chars]TML>'

======================================================================
FAIL: test_expat_binary_file_int_name (test.test_sax.ExpatReaderTest)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "C:\Programs\Python36\lib\test\test_sax.py", line 886, in 
test_expat_binary_file_int_name
     self.assertEqual(result.getvalue(), xml_test_out)
AssertionError: b'<?x[36 chars]1"?>\n<HTML 
xmlns:pp="http://www.isogen.com/pa[1508 chars]TML>' != b'<?x[36 
chars]1"?>\r\n<HTML xmlns:pp="http://www.isogen.com/[1736 chars]TML>'

======================================================================
FAIL: test_expat_binary_file_nonascii (test.test_sax.ExpatReaderTest)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "C:\Programs\Python36\lib\test\test_sax.py", line 862, in 
test_expat_binary_file_nonascii
     self.assertEqual(result.getvalue(), xml_test_out)
AssertionError: b'<?x[36 chars]1"?>\n<HTML 
xmlns:pp="http://www.isogen.com/pa[1508 chars]TML>' != b'<?x[36 
chars]1"?>\r\n<HTML xmlns:pp="http://www.isogen.com/[1736 chars]TML>'

======================================================================
FAIL: test_expat_inpsource_byte_stream (test.test_sax.ExpatReaderTest)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "C:\Programs\Python36\lib\test\test_sax.py", line 1053, in 
test_expat_inpsource_byte_stream
     self.assertEqual(result.getvalue(), xml_test_out)
AssertionError: b'<?x[36 chars]1"?>\n<HTML 
xmlns:pp="http://www.isogen.com/pa[1508 chars]TML>' != b'<?x[36 
chars]1"?>\r\n<HTML xmlns:pp="http://www.isogen.com/[1736 chars]TML>'

======================================================================
FAIL: test_expat_inpsource_character_stream (test.test_sax.ExpatReaderTest)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "C:\Programs\Python36\lib\test\test_sax.py", line 1066, in 
test_expat_inpsource_character_stream
     self.assertEqual(result.getvalue(), xml_test_out)
AssertionError: b'<?x[36 chars]1"?>\n<HTML 
xmlns:pp="http://www.isogen.com/pa[1508 chars]TML>' != b'<?x[36 
chars]1"?>\r\n<HTML xmlns:pp="http://www.isogen.com/[1736 chars]TML>'

======================================================================
FAIL: test_expat_inpsource_filename (test.test_sax.ExpatReaderTest)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "C:\Programs\Python36\lib\test\test_sax.py", line 1015, in 
test_expat_inpsource_filename
     self.assertEqual(result.getvalue(), xml_test_out)
AssertionError: b'<?x[36 chars]1"?>\n<HTML 
xmlns:pp="http://www.isogen.com/pa[1508 chars]TML>' != b'<?x[36 
chars]1"?>\r\n<HTML xmlns:pp="http://www.isogen.com/[1736 chars]TML>'

======================================================================
FAIL: test_expat_inpsource_sysid (test.test_sax.ExpatReaderTest)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "C:\Programs\Python36\lib\test\test_sax.py", line 1025, in 
test_expat_inpsource_sysid
     self.assertEqual(result.getvalue(), xml_test_out)
AssertionError: b'<?x[36 chars]1"?>\n<HTML 
xmlns:pp="http://www.isogen.com/pa[1508 chars]TML>' != b'<?x[36 
chars]1"?>\r\n<HTML xmlns:pp="http://www.isogen.com/[1736 chars]TML>'

======================================================================
FAIL: test_expat_inpsource_sysid_nonascii (test.test_sax.ExpatReaderTest)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "C:\Programs\Python36\lib\test\test_sax.py", line 1040, in 
test_expat_inpsource_sysid_nonascii
     self.assertEqual(result.getvalue(), xml_test_out)
AssertionError: b'<?x[36 chars]1"?>\n<HTML 
xmlns:pp="http://www.isogen.com/pa[1508 chars]TML>' != b'<?x[36 
chars]1"?>\r\n<HTML xmlns:pp="http://www.isogen.com/[1736 chars]TML>'

======================================================================
FAIL: test_expat_text_file (test.test_sax.ExpatReaderTest)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "C:\Programs\Python36\lib\test\test_sax.py", line 847, in 
test_expat_text_file
     self.assertEqual(result.getvalue(), xml_test_out)
AssertionError: b'<?x[36 chars]1"?>\n<HTML 
xmlns:pp="http://www.isogen.com/pa[1508 chars]TML>' != b'<?x[36 
chars]1"?>\r\n<HTML xmlns:pp="http://www.isogen.com/[1736 chars]TML>'

----------------------------------------------------------------------
Ran 171 tests in 0.303s

FAILED (failures=10)
test test_sax failed
0:00:17 [7/7/7] test_subprocess failed
test_noshell_sequence_with_spaces 
(test.test_subprocess.CommandsWithSpaces) ... ok
test_noshell_string_with_spaces 
(test.test_subprocess.CommandsWithSpaces) ... ok
test_shell_sequence_with_spaces 
(test.test_subprocess.CommandsWithSpaces) ... ok
test_shell_string_with_spaces (test.test_subprocess.CommandsWithSpaces) 
... ok
test_broken_pipe_cleanup (test.test_subprocess.ContextManagerTests)
Broken pipe error should not prevent wait() (Issue 21619) ... ok
test_communicate_stdin (test.test_subprocess.ContextManagerTests) ... ok
test_invalid_args (test.test_subprocess.ContextManagerTests) ... ok
test_pipe (test.test_subprocess.ContextManagerTests) ... ok
test_returncode (test.test_subprocess.ContextManagerTests) ... ok
test__all__ (test.test_subprocess.MiscTests)
Ensure that __all__ is populated properly. ... ok
test_getoutput (test.test_subprocess.MiscTests) ... ok
test_CalledProcessError_str_non_zero 
(test.test_subprocess.POSIXProcessTestCase) ... skipped 'POSIX specific 
tests'
test_CalledProcessError_str_signal 
(test.test_subprocess.POSIXProcessTestCase) ... skipped 'POSIX specific 
tests'
test_CalledProcessError_str_unknown_signal 
(test.test_subprocess.POSIXProcessTestCase) ... skipped 'POSIX specific 
tests'
test_args_string (test.test_subprocess.POSIXProcessTestCase) ... skipped 
'POSIX specific tests'
test_bytes_program (test.test_subprocess.POSIXProcessTestCase) ... 
skipped 'POSIX specific tests'
test_call_string (test.test_subprocess.POSIXProcessTestCase) ... skipped 
'POSIX specific tests'
test_child_terminated_in_stopped_state 
(test.test_subprocess.POSIXProcessTestCase)
Test wait() behavior when waitpid returns WIFSTOPPED; issue29335. ... 
skipped 'POSIX specific tests'
test_close_fd_0 (test.test_subprocess.POSIXProcessTestCase) ... skipped 
'POSIX specific tests'
test_close_fd_1 (test.test_subprocess.POSIXProcessTestCase) ... skipped 
'POSIX specific tests'
test_close_fd_2 (test.test_subprocess.POSIXProcessTestCase) ... skipped 
'POSIX specific tests'
test_close_fds (test.test_subprocess.POSIXProcessTestCase) ... skipped 
'POSIX specific tests'
test_close_fds_0_1 (test.test_subprocess.POSIXProcessTestCase) ... 
skipped 'POSIX specific tests'
test_close_fds_0_1_2 (test.test_subprocess.POSIXProcessTestCase) ... 
skipped 'POSIX specific tests'
test_close_fds_0_2 (test.test_subprocess.POSIXProcessTestCase) ... 
skipped 'POSIX specific tests'
test_close_fds_1_2 (test.test_subprocess.POSIXProcessTestCase) ... 
skipped 'POSIX specific tests'
test_close_fds_after_preexec (test.test_subprocess.POSIXProcessTestCase) 
... skipped 'POSIX specific tests'
test_close_fds_when_max_fd_is_lowered 
(test.test_subprocess.POSIXProcessTestCase)
Confirm that issue21618 is fixed (may fail under valgrind). ... skipped 
'POSIX specific tests'
test_communicate_BrokenPipeError_stdin_close 
(test.test_subprocess.POSIXProcessTestCase) ... skipped 'POSIX specific 
tests'
test_communicate_BrokenPipeError_stdin_close_with_timeout 
(test.test_subprocess.POSIXProcessTestCase) ... skipped 'POSIX specific 
tests'
test_communicate_BrokenPipeError_stdin_flush 
(test.test_subprocess.POSIXProcessTestCase) ... skipped 'POSIX specific 
tests'
test_communicate_BrokenPipeError_stdin_write 
(test.test_subprocess.POSIXProcessTestCase) ... skipped 'POSIX specific 
tests'
test_exception_bad_args_0 (test.test_subprocess.POSIXProcessTestCase)
Test error in the child raised in the parent for a bad args[0]. ... 
skipped 'POSIX specific tests'
test_exception_bad_executable (test.test_subprocess.POSIXProcessTestCase)
Test error in the child raised in the parent for a bad executable. ... 
skipped 'POSIX specific tests'
test_exception_cwd (test.test_subprocess.POSIXProcessTestCase)
Test error in the child raised in the parent for a bad cwd. ... skipped 
'POSIX specific tests'
test_fork_exec (test.test_subprocess.POSIXProcessTestCase) ... skipped 
'POSIX specific tests'
test_fork_exec_sorted_fd_sanity_check 
(test.test_subprocess.POSIXProcessTestCase) ... skipped 'POSIX specific 
tests'
test_invalid_args (test.test_subprocess.POSIXProcessTestCase) ... 
skipped 'POSIX specific tests'
test_kill (test.test_subprocess.POSIXProcessTestCase) ... skipped 'POSIX 
specific tests'
test_kill_dead (test.test_subprocess.POSIXProcessTestCase) ... skipped 
'POSIX specific tests'
test_leak_fast_process_del_killed 
(test.test_subprocess.POSIXProcessTestCase) ... skipped 'POSIX specific 
tests'
test_pass_fds (test.test_subprocess.POSIXProcessTestCase) ... skipped 
'POSIX specific tests'
test_pass_fds_inheritable (test.test_subprocess.POSIXProcessTestCase) 
... skipped 'POSIX specific tests'
test_pipe_cloexec (test.test_subprocess.POSIXProcessTestCase) ... 
skipped 'POSIX specific tests'
test_pipe_cloexec_real_tools (test.test_subprocess.POSIXProcessTestCase) 
... skipped 'POSIX specific tests'
test_preexec (test.test_subprocess.POSIXProcessTestCase) ... skipped 
'POSIX specific tests'
test_preexec_errpipe_does_not_double_close_pipes 
(test.test_subprocess.POSIXProcessTestCase)
Issue16140: Don't double close pipes on preexec error. ... skipped 
'POSIX specific tests'
test_preexec_exception (test.test_subprocess.POSIXProcessTestCase) ... 
skipped 'POSIX specific tests'
test_preexec_fork_failure (test.test_subprocess.POSIXProcessTestCase) 
... skipped 'POSIX specific tests'
test_preexec_gc_module_failure 
(test.test_subprocess.POSIXProcessTestCase) ... skipped 'POSIX specific 
tests'
test_remapping_std_fds (test.test_subprocess.POSIXProcessTestCase) ... 
skipped 'POSIX specific tests'
test_restore_signals (test.test_subprocess.POSIXProcessTestCase) ... 
skipped 'POSIX specific tests'
test_run_abort (test.test_subprocess.POSIXProcessTestCase) ... skipped 
'POSIX specific tests'
test_select_unbuffered (test.test_subprocess.POSIXProcessTestCase) ... 
skipped 'POSIX specific tests'
test_send_signal (test.test_subprocess.POSIXProcessTestCase) ... skipped 
'POSIX specific tests'
test_send_signal_dead (test.test_subprocess.POSIXProcessTestCase) ... 
skipped 'POSIX specific tests'
test_shell_sequence (test.test_subprocess.POSIXProcessTestCase) ... 
skipped 'POSIX specific tests'
test_shell_string (test.test_subprocess.POSIXProcessTestCase) ... 
skipped 'POSIX specific tests'
test_small_errpipe_write_fd (test.test_subprocess.POSIXProcessTestCase)
Issue #15798: Popen should work when stdio fds are available. ... 
skipped 'POSIX specific tests'
test_specific_shell (test.test_subprocess.POSIXProcessTestCase) ... 
skipped 'POSIX specific tests'
test_start_new_session (test.test_subprocess.POSIXProcessTestCase) ... 
skipped 'POSIX specific tests'
test_stderr_stdin_are_single_inout_fd 
(test.test_subprocess.POSIXProcessTestCase) ... skipped 'POSIX specific 
tests'
test_stdout_stderr_are_single_inout_fd 
(test.test_subprocess.POSIXProcessTestCase) ... skipped 'POSIX specific 
tests'
test_stdout_stdin_are_single_inout_fd 
(test.test_subprocess.POSIXProcessTestCase) ... skipped 'POSIX specific 
tests'
test_surrogates_error_message 
(test.test_subprocess.POSIXProcessTestCase) ... skipped 'POSIX specific 
tests'
test_swap_fds (test.test_subprocess.POSIXProcessTestCase) ... skipped 
'POSIX specific tests'
test_terminate (test.test_subprocess.POSIXProcessTestCase) ... skipped 
'POSIX specific tests'
test_terminate_dead (test.test_subprocess.POSIXProcessTestCase) ... 
skipped 'POSIX specific tests'
test_undecodable_env (test.test_subprocess.POSIXProcessTestCase) ... 
skipped 'POSIX specific tests'
test_wait_when_sigchild_ignored 
(test.test_subprocess.POSIXProcessTestCase) ... skipped 'POSIX specific 
tests'
test_zombie_fast_process_del (test.test_subprocess.POSIXProcessTestCase) 
... skipped 'POSIX specific tests'
test_bufsize_equal_one_binary_mode 
(test.test_subprocess.ProcessTestCase) ... ok
test_bufsize_equal_one_text_mode (test.test_subprocess.ProcessTestCase) 
... ok
test_bufsize_is_none (test.test_subprocess.ProcessTestCase) ... ok
test_call_kwargs (test.test_subprocess.ProcessTestCase) ... ok
test_call_seq (test.test_subprocess.ProcessTestCase) ... ok
test_call_timeout (test.test_subprocess.ProcessTestCase) ... ok
test_check_call_nonzero (test.test_subprocess.ProcessTestCase) ... ok
test_check_call_zero (test.test_subprocess.ProcessTestCase) ... ok
test_check_output (test.test_subprocess.ProcessTestCase) ... ok
test_check_output_input_arg (test.test_subprocess.ProcessTestCase) ... ok
test_check_output_nonzero (test.test_subprocess.ProcessTestCase) ... ok
test_check_output_stderr (test.test_subprocess.ProcessTestCase) ... ok
test_check_output_stdin_arg (test.test_subprocess.ProcessTestCase) ... ok
test_check_output_stdin_with_input_arg 
(test.test_subprocess.ProcessTestCase) ... ok
test_check_output_stdout_arg (test.test_subprocess.ProcessTestCase) ... ok
test_check_output_timeout (test.test_subprocess.ProcessTestCase) ... ok
test_communicate (test.test_subprocess.ProcessTestCase) ... ok
test_communicate_eintr (test.test_subprocess.ProcessTestCase) ... 
skipped 'Requires signal.SIGUSR1'
test_communicate_epipe (test.test_subprocess.ProcessTestCase) ... ok
test_communicate_epipe_only_stdin (test.test_subprocess.ProcessTestCase) 
... ok
test_communicate_errors (test.test_subprocess.ProcessTestCase) ... ok
test_communicate_pipe_buf (test.test_subprocess.ProcessTestCase) ... ok
test_communicate_pipe_fd_leak (test.test_subprocess.ProcessTestCase) ... ok
test_communicate_returns (test.test_subprocess.ProcessTestCase) ... ok
test_communicate_stderr (test.test_subprocess.ProcessTestCase) ... ok
test_communicate_stdin (test.test_subprocess.ProcessTestCase) ... ok
test_communicate_stdout (test.test_subprocess.ProcessTestCase) ... ok
test_communicate_timeout (test.test_subprocess.ProcessTestCase) ... ok
test_communicate_timeout_large_output 
(test.test_subprocess.ProcessTestCase) ... ok
test_cwd (test.test_subprocess.ProcessTestCase) ... ok
test_cwd_with_absolute_arg (test.test_subprocess.ProcessTestCase) ... ok
test_cwd_with_pathlike (test.test_subprocess.ProcessTestCase) ... ERROR
test_cwd_with_relative_arg (test.test_subprocess.ProcessTestCase) ... 
skipped 'pending resolution of issue #15533'
test_cwd_with_relative_executable (test.test_subprocess.ProcessTestCase) 
... skipped 'pending resolution of issue #15533'
test_double_close_on_error (test.test_subprocess.ProcessTestCase) ... ok
test_empty_env (test.test_subprocess.ProcessTestCase) ... skipped 
'cannot test an empty env on Windows'
test_env (test.test_subprocess.ProcessTestCase) ... ok
test_executable (test.test_subprocess.ProcessTestCase) ... ok
test_executable_replaces_shell (test.test_subprocess.ProcessTestCase) 
... skipped 'executable argument replaces shell'
test_executable_takes_precedence (test.test_subprocess.ProcessTestCase) 
... ok
test_executable_with_cwd (test.test_subprocess.ProcessTestCase) ... ok
test_executable_without_cwd (test.test_subprocess.ProcessTestCase) ... ok
test_failed_child_execute_fd_leak (test.test_subprocess.ProcessTestCase)
Test for the fork() failure fd leak reported in issue16327. ... skipped 
'Linux specific'
test_handles_closed_on_exception (test.test_subprocess.ProcessTestCase) 
... ok
test_invalid_args (test.test_subprocess.ProcessTestCase) ... ok
test_invalid_bufsize (test.test_subprocess.ProcessTestCase) ... ok
test_io_buffered_by_default (test.test_subprocess.ProcessTestCase) ... ok
test_io_unbuffered_works (test.test_subprocess.ProcessTestCase) ... ok
test_issue8780 (test.test_subprocess.ProcessTestCase) ... ok
test_leaking_fds_on_error (test.test_subprocess.ProcessTestCase) ... ok
test_list2cmdline (test.test_subprocess.ProcessTestCase) ... ok
test_no_leaking (test.test_subprocess.ProcessTestCase) ... skipped 
'failed to reach the file descriptor limit (tried 2050)'
test_poll (test.test_subprocess.ProcessTestCase) ... ok
test_stderr_devnull (test.test_subprocess.ProcessTestCase) ... ok
test_stderr_filedes (test.test_subprocess.ProcessTestCase) ... ok
test_stderr_fileobj (test.test_subprocess.ProcessTestCase) ... ok
test_stderr_none (test.test_subprocess.ProcessTestCase) ... ok
test_stderr_pipe (test.test_subprocess.ProcessTestCase) ... ok
test_stderr_redirect_with_no_stdout_redirect 
(test.test_subprocess.ProcessTestCase) ... ok
test_stdin_devnull (test.test_subprocess.ProcessTestCase) ... ok
test_stdin_filedes (test.test_subprocess.ProcessTestCase) ... ok
test_stdin_fileobj (test.test_subprocess.ProcessTestCase) ... ok
test_stdin_none (test.test_subprocess.ProcessTestCase) ... ok
test_stdin_pipe (test.test_subprocess.ProcessTestCase) ... ok
test_stdout_devnull (test.test_subprocess.ProcessTestCase) ... ok
test_stdout_filedes (test.test_subprocess.ProcessTestCase) ... ok
test_stdout_filedes_of_stdout (test.test_subprocess.ProcessTestCase) ... ok
test_stdout_fileobj (test.test_subprocess.ProcessTestCase) ... ok
test_stdout_none (test.test_subprocess.ProcessTestCase) ... ok
test_stdout_pipe (test.test_subprocess.ProcessTestCase) ... ok
test_stdout_stderr_file (test.test_subprocess.ProcessTestCase) ... ok
test_stdout_stderr_pipe (test.test_subprocess.ProcessTestCase) ... ok
test_threadsafe_wait (test.test_subprocess.ProcessTestCase)
Issue21291: Popen.wait() needs to be threadsafe for returncode. ... ok
test_universal_newlines (test.test_subprocess.ProcessTestCase) ... ok
test_universal_newlines_communicate 
(test.test_subprocess.ProcessTestCase) ... ok
test_universal_newlines_communicate_encodings 
(test.test_subprocess.ProcessTestCase) ... ok
test_universal_newlines_communicate_input_none 
(test.test_subprocess.ProcessTestCase) ... ok
test_universal_newlines_communicate_stdin 
(test.test_subprocess.ProcessTestCase) ... ok
test_universal_newlines_communicate_stdin_stdout_stderr 
(test.test_subprocess.ProcessTestCase) ... ok
test_wait (test.test_subprocess.ProcessTestCase) ... ok
test_wait_endtime (test.test_subprocess.ProcessTestCase)
Confirm that the deprecated endtime parameter warns. ... ok
test_wait_timeout (test.test_subprocess.ProcessTestCase) ... ok
test_writes_before_communicate (test.test_subprocess.ProcessTestCase) ... ok
test_bufsize_equal_one_binary_mode 
(test.test_subprocess.ProcessTestCaseNoPoll) ... skipped 'Test needs 
selectors.PollSelector'
test_bufsize_equal_one_text_mode 
(test.test_subprocess.ProcessTestCaseNoPoll) ... skipped 'Test needs 
selectors.PollSelector'
test_bufsize_is_none (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_call_kwargs (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_call_seq (test.test_subprocess.ProcessTestCaseNoPoll) ... skipped 
'Test needs selectors.PollSelector'
test_call_timeout (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_check_call_nonzero (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_check_call_zero (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_check_output (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_check_output_input_arg (test.test_subprocess.ProcessTestCaseNoPoll) 
... skipped 'Test needs selectors.PollSelector'
test_check_output_nonzero (test.test_subprocess.ProcessTestCaseNoPoll) 
... skipped 'Test needs selectors.PollSelector'
test_check_output_stderr (test.test_subprocess.ProcessTestCaseNoPoll) 
... skipped 'Test needs selectors.PollSelector'
test_check_output_stdin_arg (test.test_subprocess.ProcessTestCaseNoPoll) 
... skipped 'Test needs selectors.PollSelector'
test_check_output_stdin_with_input_arg 
(test.test_subprocess.ProcessTestCaseNoPoll) ... skipped 'Test needs 
selectors.PollSelector'
test_check_output_stdout_arg 
(test.test_subprocess.ProcessTestCaseNoPoll) ... skipped 'Test needs 
selectors.PollSelector'
test_check_output_timeout (test.test_subprocess.ProcessTestCaseNoPoll) 
... skipped 'Test needs selectors.PollSelector'
test_communicate (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_communicate_eintr (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_communicate_epipe (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_communicate_epipe_only_stdin 
(test.test_subprocess.ProcessTestCaseNoPoll) ... skipped 'Test needs 
selectors.PollSelector'
test_communicate_errors (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_communicate_pipe_buf (test.test_subprocess.ProcessTestCaseNoPoll) 
... skipped 'Test needs selectors.PollSelector'
test_communicate_pipe_fd_leak 
(test.test_subprocess.ProcessTestCaseNoPoll) ... skipped 'Test needs 
selectors.PollSelector'
test_communicate_returns (test.test_subprocess.ProcessTestCaseNoPoll) 
... skipped 'Test needs selectors.PollSelector'
test_communicate_stderr (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_communicate_stdin (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_communicate_stdout (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_communicate_timeout (test.test_subprocess.ProcessTestCaseNoPoll) 
... skipped 'Test needs selectors.PollSelector'
test_communicate_timeout_large_output 
(test.test_subprocess.ProcessTestCaseNoPoll) ... skipped 'Test needs 
selectors.PollSelector'
test_cwd (test.test_subprocess.ProcessTestCaseNoPoll) ... skipped 'Test 
needs selectors.PollSelector'
test_cwd_with_absolute_arg (test.test_subprocess.ProcessTestCaseNoPoll) 
... skipped 'Test needs selectors.PollSelector'
test_cwd_with_pathlike (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_cwd_with_relative_arg (test.test_subprocess.ProcessTestCaseNoPoll) 
... skipped 'Test needs selectors.PollSelector'
test_cwd_with_relative_executable 
(test.test_subprocess.ProcessTestCaseNoPoll) ... skipped 'Test needs 
selectors.PollSelector'
test_double_close_on_error (test.test_subprocess.ProcessTestCaseNoPoll) 
... skipped 'Test needs selectors.PollSelector'
test_empty_env (test.test_subprocess.ProcessTestCaseNoPoll) ... skipped 
'Test needs selectors.PollSelector'
test_env (test.test_subprocess.ProcessTestCaseNoPoll) ... skipped 'Test 
needs selectors.PollSelector'
test_executable (test.test_subprocess.ProcessTestCaseNoPoll) ... skipped 
'Test needs selectors.PollSelector'
test_executable_replaces_shell 
(test.test_subprocess.ProcessTestCaseNoPoll) ... skipped 'Test needs 
selectors.PollSelector'
test_executable_takes_precedence 
(test.test_subprocess.ProcessTestCaseNoPoll) ... skipped 'Test needs 
selectors.PollSelector'
test_executable_with_cwd (test.test_subprocess.ProcessTestCaseNoPoll) 
... skipped 'Test needs selectors.PollSelector'
test_executable_without_cwd (test.test_subprocess.ProcessTestCaseNoPoll) 
... skipped 'Test needs selectors.PollSelector'
test_failed_child_execute_fd_leak 
(test.test_subprocess.ProcessTestCaseNoPoll)
Test for the fork() failure fd leak reported in issue16327. ... skipped 
'Test needs selectors.PollSelector'
test_handles_closed_on_exception 
(test.test_subprocess.ProcessTestCaseNoPoll) ... skipped 'Test needs 
selectors.PollSelector'
test_invalid_args (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_invalid_bufsize (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_io_buffered_by_default (test.test_subprocess.ProcessTestCaseNoPoll) 
... skipped 'Test needs selectors.PollSelector'
test_io_unbuffered_works (test.test_subprocess.ProcessTestCaseNoPoll) 
... skipped 'Test needs selectors.PollSelector'
test_issue8780 (test.test_subprocess.ProcessTestCaseNoPoll) ... skipped 
'Test needs selectors.PollSelector'
test_leaking_fds_on_error (test.test_subprocess.ProcessTestCaseNoPoll) 
... skipped 'Test needs selectors.PollSelector'
test_list2cmdline (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_no_leaking (test.test_subprocess.ProcessTestCaseNoPoll) ... skipped 
'Test needs selectors.PollSelector'
test_poll (test.test_subprocess.ProcessTestCaseNoPoll) ... skipped 'Test 
needs selectors.PollSelector'
test_stderr_devnull (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_stderr_filedes (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_stderr_fileobj (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_stderr_none (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_stderr_pipe (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_stderr_redirect_with_no_stdout_redirect 
(test.test_subprocess.ProcessTestCaseNoPoll) ... skipped 'Test needs 
selectors.PollSelector'
test_stdin_devnull (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_stdin_filedes (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_stdin_fileobj (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_stdin_none (test.test_subprocess.ProcessTestCaseNoPoll) ... skipped 
'Test needs selectors.PollSelector'
test_stdin_pipe (test.test_subprocess.ProcessTestCaseNoPoll) ... skipped 
'Test needs selectors.PollSelector'
test_stdout_devnull (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_stdout_filedes (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_stdout_filedes_of_stdout 
(test.test_subprocess.ProcessTestCaseNoPoll) ... skipped 'Test needs 
selectors.PollSelector'
test_stdout_fileobj (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_stdout_none (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_stdout_pipe (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_stdout_stderr_file (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_stdout_stderr_pipe (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_threadsafe_wait (test.test_subprocess.ProcessTestCaseNoPoll)
Issue21291: Popen.wait() needs to be threadsafe for returncode. ... 
skipped 'Test needs selectors.PollSelector'
test_universal_newlines (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_universal_newlines_communicate 
(test.test_subprocess.ProcessTestCaseNoPoll) ... skipped 'Test needs 
selectors.PollSelector'
test_universal_newlines_communicate_encodings 
(test.test_subprocess.ProcessTestCaseNoPoll) ... skipped 'Test needs 
selectors.PollSelector'
test_universal_newlines_communicate_input_none 
(test.test_subprocess.ProcessTestCaseNoPoll) ... skipped 'Test needs 
selectors.PollSelector'
test_universal_newlines_communicate_stdin 
(test.test_subprocess.ProcessTestCaseNoPoll) ... skipped 'Test needs 
selectors.PollSelector'
test_universal_newlines_communicate_stdin_stdout_stderr 
(test.test_subprocess.ProcessTestCaseNoPoll) ... skipped 'Test needs 
selectors.PollSelector'
test_wait (test.test_subprocess.ProcessTestCaseNoPoll) ... skipped 'Test 
needs selectors.PollSelector'
test_wait_endtime (test.test_subprocess.ProcessTestCaseNoPoll)
Confirm that the deprecated endtime parameter warns. ... skipped 'Test 
needs selectors.PollSelector'
test_wait_timeout (test.test_subprocess.ProcessTestCaseNoPoll) ... 
skipped 'Test needs selectors.PollSelector'
test_writes_before_communicate 
(test.test_subprocess.ProcessTestCaseNoPoll) ... skipped 'Test needs 
selectors.PollSelector'
test_capture_stderr (test.test_subprocess.RunFuncTestCase) ... ok
test_capture_stdout (test.test_subprocess.RunFuncTestCase) ... ok
test_check (test.test_subprocess.RunFuncTestCase) ... ok
test_check_output_input_arg (test.test_subprocess.RunFuncTestCase) ... ok
test_check_output_stdin_arg (test.test_subprocess.RunFuncTestCase) ... ok
test_check_output_stdin_with_input_arg 
(test.test_subprocess.RunFuncTestCase) ... ok
test_check_output_timeout (test.test_subprocess.RunFuncTestCase) ... ok
test_check_zero (test.test_subprocess.RunFuncTestCase) ... ok
test_returncode (test.test_subprocess.RunFuncTestCase) ... ok
test_run_kwargs (test.test_subprocess.RunFuncTestCase) ... ok
test_timeout (test.test_subprocess.RunFuncTestCase) ... ok
test_call_string (test.test_subprocess.Win32ProcessTestCase) ... ok
test_close_fds (test.test_subprocess.Win32ProcessTestCase) ... ok
test_creationflags (test.test_subprocess.Win32ProcessTestCase) ... ok
test_invalid_args (test.test_subprocess.Win32ProcessTestCase) ... ok
test_kill (test.test_subprocess.Win32ProcessTestCase) ... ok
test_kill_dead (test.test_subprocess.Win32ProcessTestCase) ... ok
test_send_signal (test.test_subprocess.Win32ProcessTestCase) ... ok
test_send_signal_dead (test.test_subprocess.Win32ProcessTestCase) ... ok
test_shell_encodings (test.test_subprocess.Win32ProcessTestCase) ... ok
test_shell_sequence (test.test_subprocess.Win32ProcessTestCase) ... ok
test_shell_string (test.test_subprocess.Win32ProcessTestCase) ... ok
test_startupinfo (test.test_subprocess.Win32ProcessTestCase) ... ok
test_terminate (test.test_subprocess.Win32ProcessTestCase) ... ok
test_terminate_dead (test.test_subprocess.Win32ProcessTestCase) ... ok

======================================================================
ERROR: test_cwd_with_pathlike (test.test_subprocess.ProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
   File "C:\Programs\Python36\lib\test\test_subprocess.py", line 358, in 
test_cwd_with_pathlike
     self._assert_cwd(temp_dir, sys.executable, cwd=_PathLikeObj())
   File "C:\Programs\Python36\lib\test\test_subprocess.py", line 336, in 
_assert_cwd
     **kwargs)
   File "C:\Programs\Python36\lib\subprocess.py", line 707, in __init__
     restore_signals, start_new_session)
   File "C:\Programs\Python36\lib\subprocess.py", line 990, in 
_execute_child
     startupinfo)
TypeError: CreateProcess() argument 8 must be str or None, not _PathLikeObj

----------------------------------------------------------------------
Ran 262 tests in 16.808s

FAILED (errors=1, skipped=150)
     a DOS box should flash briefly ...
test test_subprocess failed

7 tests failed:
     test_codecencodings_iso2022 test_random test_re test_regrtest
     test_sax test_subprocess test_tools

Total duration: 17 sec
Tests result: FAILURE

From steve.dower at python.org  Wed Mar  8 09:56:58 2017
From: steve.dower at python.org (Steve Dower)
Date: Wed, 8 Mar 2017 06:56:58 -0800
Subject: [python-committers] Signups for 2017 Python Language Summit are
 nowopen
In-Reply-To: <20170305173100.2e358bca@subdivisions.wooz.org>
References: <20170305173100.2e358bca@subdivisions.wooz.org>
Message-ID: <E1cld2G-0006Qv-9p@se2-syd.hostedmail.net.au>

I registered, and *then* thought of the session I'd like to give.

How do you want us to fix this situation? Direct [BL]arry email? Register again?

Top-posted from my Windows Phone

-----Original Message-----
From: "Barry Warsaw" <barry at python.org>
Sent: ?3/?5/?2017 14:31
To: "python-committers at python.org" <python-committers at python.org>
Subject: [python-committers] Signups for 2017 Python Language Summit are nowopen

It?s that time again: time to start thinking about the Python Language Summit!
The 2017 summit will be held on Wednesday, May 17, from 10am to 4pm, at the
Oregon Convention Center in Portland, Oregon, USA.  Your befezzled hosts Larry
and Barry will once again be at the helm.

The summit?s purpose is to disseminate information and spark conversation
among core Python developers.  It?s our yearly opportunity to get together for
an in-person discussion, to review interesting developments of the previous
year and hash out where we?re going next.  And we have lots to talk about!
Since our last summit, Python 3.6 was released, and the main CPython
development process has been moved to GitHub.  Naturally Python 3.7
development continues apace.

Speaking of changes, we?re continuing to evolve the summit.  Everyone seemed
to like the lightning talks, so we?ll keep those.  Everyone seemed to hate us
keeping the schedule secret -sorry!- so we?ll make that available beforehand,
with the understanding that it?ll be fluid as the day progresses.  Due to room
size limitations and the yearly increase in participation, we?re limiting
summit invitations to just core developers and invited speakers.  As usual,
we?ll have whiteboards and a projector.  But this year we?re adding roaming
microphones, so everybody in the room will be able to hear your question!

With the help of the ever awesome Ewa, this year we?ll have badge ribbons for
Language Summit participants, which we?ll hand out at the summit room in the
morning.

As with last year, we?re using Google Forms to collect signups.  The form will
let you request an invitation to the summit and optionally propose a talk.
Signups are open now, and will remain open until Wednesday April 12th, 2017.
You can find the link to the signup form from the summit?s official web page,
here:

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

But never forget: you don?t need to be registered for PyCon in order to attend
the summit!

One final note.  We?re re-inviting Jake Edge from Linux Weekly News to attend
the summit and provide press coverage.  Jake?s done a phenomenal job of
covering the previous two years? summits, providing valuable information not
just for summit attendees, but also for the Python community at large.  Jake?s
coverage goes a long way toward demystifying the summit, while remaining
respectful of confidential information that?s deemed ?off the record? ahead of
time by participants.

We hope to see you at the summit!

[BL]arry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170308/0b35fe57/attachment.html>

From victor.stinner at gmail.com  Wed Mar  8 09:59:42 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Wed, 8 Mar 2017 15:59:42 +0100
Subject: [python-committers] 3.6.1 release status and plans
In-Reply-To: <977a07c7-b3f7-e6c3-6ca5-245edc1235d9@udel.edu>
References: <FC705FCF-A61B-4948-8415-5A6DEF36BD89@python.org>
 <977a07c7-b3f7-e6c3-6ca5-245edc1235d9@udel.edu>
Message-ID: <CAMpsgwYysNgj4zQdZDm6GT4C_gbV2VKxtwOmwsfTFuNWVGqDzA@mail.gmail.com>

> Ned, 7 tests fail for me on Windows.  I believe 3.6.0 ran clean or nearly
> so.  Pasteing below is best I can do right now as I had eye operation less
> than 24 hours ago.

It's an issue with newlines and Git which only impact tests:
http://bugs.python.org/issue29530

Victor

From mal at egenix.com  Wed Mar  8 10:42:09 2017
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 8 Mar 2017 16:42:09 +0100
Subject: [python-committers] PR merges don't seem to show up on b.p.o
Message-ID: <74a4ebc7-c0dd-dd2b-f74b-287edab6c257@egenix.com>

Is there a reason for this ?

Example:
https://github.com/python/cpython/pull/422
and
http://bugs.python.org/issue20087

Also: I'd like to remind other committers that discussions of PRs
should happen on the ticket, not the PR. In the above case, the PR
was merged while we were still discussing the patch on the ticket.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

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

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

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


From barry at python.org  Wed Mar  8 11:03:47 2017
From: barry at python.org (Barry Warsaw)
Date: Wed, 8 Mar 2017 11:03:47 -0500
Subject: [python-committers] Signups for 2017 Python Language Summit are
 nowopen
In-Reply-To: <E1cld2G-0006Qv-9p@se2-syd.hostedmail.net.au>
References: <20170305173100.2e358bca@subdivisions.wooz.org>
 <E1cld2G-0006Qv-9p@se2-syd.hostedmail.net.au>
Message-ID: <20170308110347.1397c1d0@subdivisions.wooz.org>

On Mar 08, 2017, at 06:56 AM, Steve Dower wrote:

>I registered, and *then* thought of the session I'd like to give.
>
>How do you want us to fix this situation? Direct [BL]arry email? Register
>again?

It looks like you can't edit your submission once it's sent, although Larry
says you can if you've saved the URL to your submission.

Given that there are still several weeks before we close sign ups, and even a
little farther before the summit, *and* that we want the summit to be topical
and relevant, I suspect this won't be the last time someone comes up with a
presentation idea after the fact.

It's fine to just email the two of us off-list with your presentation idea.

[BL]arry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170308/c5ea37b0/attachment.sig>

From victor.stinner at gmail.com  Wed Mar  8 11:21:40 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Wed, 8 Mar 2017 17:21:40 +0100
Subject: [python-committers] PR merges don't seem to show up on b.p.o
In-Reply-To: <74a4ebc7-c0dd-dd2b-f74b-287edab6c257@egenix.com>
References: <74a4ebc7-c0dd-dd2b-f74b-287edab6c257@egenix.com>
Message-ID: <CAMpsgwbEXL2okSEDUKfwDR5xwzvnu=fSQpuLgUYjpOUGRZOkmw@mail.gmail.com>

2017-03-08 16:42 GMT+01:00 M.-A. Lemburg <mal at egenix.com>:
> Is there a reason for this ?

It is a bug:
http://psf.upfronthosting.co.za/roundup/meta/issue613

Victor

>
> Example:
> https://github.com/python/cpython/pull/422
> and
> http://bugs.python.org/issue20087
>
> Also: I'd like to remind other committers that discussions of PRs
> should happen on the ticket, not the PR. In the above case, the PR
> was merged while we were still discussing the patch on the ticket.
>
> Thanks,
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Experts (#1, Mar 08 2017)
>>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>>> Python Database Interfaces ...           http://products.egenix.com/
>>>> Plone/Zope Database Interfaces ...           http://zope.egenix.com/
> ________________________________________________________________________
>
> ::: We implement business ideas - efficiently in both time and costs :::
>
>    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>            Registered at Amtsgericht Duesseldorf: HRB 46611
>                http://www.egenix.com/company/contact/
>                       http://www.malemburg.com/
>
> _______________________________________________
> 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 victor.stinner at gmail.com  Thu Mar  9 04:28:46 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Thu, 9 Mar 2017 10:28:46 +0100
Subject: [python-committers] New ncoghlan-bpo-29537-NEWS branch?
Message-ID: <CAMpsgwZZtVuscf13uEQc76g4KvSZP_y8UUkTZLmTEa4V8az9Dw@mail.gmail.com>

Hi,

Updating my local copy of CPython Git repository created a new
ncoghlan-bpo-29537-NEWS branch. Was it deliberate? If not, should we
prevent the creation of new Git branches? Maybe restrict this feature
outside releases? Or restrict the feature to release managers? Just to
prevent mistakes.

Victor

From victor.stinner at gmail.com  Thu Mar  9 04:30:34 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Thu, 9 Mar 2017 10:30:34 +0100
Subject: [python-committers] New ncoghlan-bpo-29537-NEWS branch?
In-Reply-To: <CAMpsgwZZtVuscf13uEQc76g4KvSZP_y8UUkTZLmTEa4V8az9Dw@mail.gmail.com>
References: <CAMpsgwZZtVuscf13uEQc76g4KvSZP_y8UUkTZLmTEa4V8az9Dw@mail.gmail.com>
Message-ID: <CAMpsgwZ3CgHXkFXOfOX4C7Ytpp913wVpah9DGNeuwM5rO7YBXA@mail.gmail.com>

Oh, in fact they are other branches (I ignored 2x and 3.x branches):

  remotes/origin/HEAD -> origin/master
  remotes/origin/benjamin-binary-test-data
  remotes/origin/benjamin-locale-aliases
  remotes/origin/benjamin-reinit-tls
  remotes/origin/benjamin-wcsxfrm-error
  remotes/origin/berkerpeksag-patch-1
  remotes/origin/legacy-trunk
  remotes/origin/master
  remotes/origin/ncoghlan-bpo-29537-NEWS
  remotes/origin/ncoghlan-devguide-link

Do we need need a kind of sandbox repository for experiments?

Victor

2017-03-09 10:28 GMT+01:00 Victor Stinner <victor.stinner at gmail.com>:
> Hi,
>
> Updating my local copy of CPython Git repository created a new
> ncoghlan-bpo-29537-NEWS branch. Was it deliberate? If not, should we
> prevent the creation of new Git branches? Maybe restrict this feature
> outside releases? Or restrict the feature to release managers? Just to
> prevent mistakes.
>
> Victor

From ncoghlan at gmail.com  Thu Mar  9 07:07:09 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 9 Mar 2017 22:07:09 +1000
Subject: [python-committers] New ncoghlan-bpo-29537-NEWS branch?
In-Reply-To: <CAMpsgwZ3CgHXkFXOfOX4C7Ytpp913wVpah9DGNeuwM5rO7YBXA@mail.gmail.com>
References: <CAMpsgwZZtVuscf13uEQc76g4KvSZP_y8UUkTZLmTEa4V8az9Dw@mail.gmail.com>
 <CAMpsgwZ3CgHXkFXOfOX4C7Ytpp913wVpah9DGNeuwM5rO7YBXA@mail.gmail.com>
Message-ID: <CADiSq7fSf+UYUujtz_M_3Mwq6KJuVdt+qOw5q2QixOgP7hzFiA@mail.gmail.com>

On 9 March 2017 at 19:30, Victor Stinner <victor.stinner at gmail.com> wrote:

> Do we need need a kind of sandbox repository for experiments?
>

Mine aren't experiments, they're temporary branches from using the online
editor for minor fixups (GitHub doesn't give you the option to put those in
your fork if you have merge access on the main repo).

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/20170309/e3913e66/attachment.html>

From brett at python.org  Thu Mar  9 13:32:13 2017
From: brett at python.org (Brett Cannon)
Date: Thu, 09 Mar 2017 18:32:13 +0000
Subject: [python-committers] New ncoghlan-bpo-29537-NEWS branch?
In-Reply-To: <CADiSq7fSf+UYUujtz_M_3Mwq6KJuVdt+qOw5q2QixOgP7hzFiA@mail.gmail.com>
References: <CAMpsgwZZtVuscf13uEQc76g4KvSZP_y8UUkTZLmTEa4V8az9Dw@mail.gmail.com>
 <CAMpsgwZ3CgHXkFXOfOX4C7Ytpp913wVpah9DGNeuwM5rO7YBXA@mail.gmail.com>
 <CADiSq7fSf+UYUujtz_M_3Mwq6KJuVdt+qOw5q2QixOgP7hzFiA@mail.gmail.com>
Message-ID: <CAP1=2W46JYRdAGoTj4tk5XHZwGadyaW=1qevUY=SkuuHkcrAQA@mail.gmail.com>

On Thu, 9 Mar 2017 at 04:07 Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 9 March 2017 at 19:30, Victor Stinner <victor.stinner at gmail.com> wrote:
>
> Do we need need a kind of sandbox repository for experiments?
>
>
> Mine aren't experiments, they're temporary branches from using the online
> editor for minor fixups (GitHub doesn't give you the option to put those in
> your fork if you have merge access on the main repo).
>

In general I expect none of those branches to live longer than 24 hours as
the PRs they were created for should be merged in less than an hour. If a
branch is older than a day then it means someone probably forgot to delete
the branch after merging a PR.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170309/53e83b12/attachment.html>

From rdmurray at bitdance.com  Thu Mar  9 14:30:05 2017
From: rdmurray at bitdance.com (R. David Murray)
Date: Thu, 09 Mar 2017 14:30:05 -0500
Subject: [python-committers] New ncoghlan-bpo-29537-NEWS branch?
In-Reply-To: <CAP1=2W46JYRdAGoTj4tk5XHZwGadyaW=1qevUY=SkuuHkcrAQA@mail.gmail.com>
References: <CAMpsgwZZtVuscf13uEQc76g4KvSZP_y8UUkTZLmTEa4V8az9Dw@mail.gmail.com>
 <CAMpsgwZ3CgHXkFXOfOX4C7Ytpp913wVpah9DGNeuwM5rO7YBXA@mail.gmail.com>
 <CADiSq7fSf+UYUujtz_M_3Mwq6KJuVdt+qOw5q2QixOgP7hzFiA@mail.gmail.com>
 <CAP1=2W46JYRdAGoTj4tk5XHZwGadyaW=1qevUY=SkuuHkcrAQA@mail.gmail.com>
Message-ID: <20170309193005.91CDF1B1003D@webabinitio.net>

On Thu, 09 Mar 2017 18:32:13 +0000, Brett Cannon <brett at python.org> wrote:
> On Thu, 9 Mar 2017 at 04:07 Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> > On 9 March 2017 at 19:30, Victor Stinner <victor.stinner at gmail.com> wrote:
> >
> > Do we need need a kind of sandbox repository for experiments?
> >
> >
> > Mine aren't experiments, they're temporary branches from using the online
> > editor for minor fixups (GitHub doesn't give you the option to put those in
> > your fork if you have merge access on the main repo).
> >
> 
> In general I expect none of those branches to live longer than 24 hours as
> the PRs they were created for should be merged in less than an hour. If a
> branch is older than a day then it means someone probably forgot to delete
> the branch after merging a PR.

If it isn't already in the devguide (I have to admit I haven't really
read the new guide yet), once you end up pulling one of those branches
into your remotes, it will stay there until you do:

    git remote prune <upstream>

The above will delete any local copies of branches that have been
deleted in <upstream>.

--David

From ncoghlan at gmail.com  Thu Mar  9 20:01:44 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 10 Mar 2017 11:01:44 +1000
Subject: [python-committers] New ncoghlan-bpo-29537-NEWS branch?
In-Reply-To: <CAP1=2W46JYRdAGoTj4tk5XHZwGadyaW=1qevUY=SkuuHkcrAQA@mail.gmail.com>
References: <CAMpsgwZZtVuscf13uEQc76g4KvSZP_y8UUkTZLmTEa4V8az9Dw@mail.gmail.com>
 <CAMpsgwZ3CgHXkFXOfOX4C7Ytpp913wVpah9DGNeuwM5rO7YBXA@mail.gmail.com>
 <CADiSq7fSf+UYUujtz_M_3Mwq6KJuVdt+qOw5q2QixOgP7hzFiA@mail.gmail.com>
 <CAP1=2W46JYRdAGoTj4tk5XHZwGadyaW=1qevUY=SkuuHkcrAQA@mail.gmail.com>
Message-ID: <CADiSq7fp-zqj6s64hiFsLABxs2VXQSn-kKfEFHQZUbF+tsBXsg@mail.gmail.com>

On 10 March 2017 at 04:32, Brett Cannon <brett at python.org> wrote:

>
>
> On Thu, 9 Mar 2017 at 04:07 Nick Coghlan <ncoghlan at gmail.com> wrote:
>
>> On 9 March 2017 at 19:30, Victor Stinner <victor.stinner at gmail.com>
>> wrote:
>>
>> Do we need need a kind of sandbox repository for experiments?
>>
>>
>> Mine aren't experiments, they're temporary branches from using the online
>> editor for minor fixups (GitHub doesn't give you the option to put those in
>> your fork if you have merge access on the main repo).
>>
>
> In general I expect none of those branches to live longer than 24 hours as
> the PRs they were created for should be merged in less than an hour. If a
> branch is older than a day then it means someone probably forgot to delete
> the branch after merging a PR.
>

That was the case for one of mine, but for the other, it was a matter of
needing to run "git remote prune" to clean up the already deleted branch
for anyone that had sync'ed it already.

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/20170310/62c47a62/attachment.html>

From victor.stinner at gmail.com  Thu Mar  9 20:08:54 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Fri, 10 Mar 2017 02:08:54 +0100
Subject: [python-committers] New ncoghlan-bpo-29537-NEWS branch?
In-Reply-To: <CAMpsgwYjEJ_iTRp9=B04rqUzzinh4ZDg_V1vYNVk7o9bzxb-uQ@mail.gmail.com>
References: <CAMpsgwZZtVuscf13uEQc76g4KvSZP_y8UUkTZLmTEa4V8az9Dw@mail.gmail.com>
 <CAMpsgwZ3CgHXkFXOfOX4C7Ytpp913wVpah9DGNeuwM5rO7YBXA@mail.gmail.com>
 <CADiSq7fSf+UYUujtz_M_3Mwq6KJuVdt+qOw5q2QixOgP7hzFiA@mail.gmail.com>
 <CAP1=2W46JYRdAGoTj4tk5XHZwGadyaW=1qevUY=SkuuHkcrAQA@mail.gmail.com>
 <CAMpsgwZbhDOe2cc11SeVA7EuTWVn83mGg742+QGWo7_3GQBWaQ@mail.gmail.com>
 <CAMpsgwYjEJ_iTRp9=B04rqUzzinh4ZDg_V1vYNVk7o9bzxb-uQ@mail.gmail.com>
Message-ID: <CAMpsgwbOYnJLG_gdmgWFUv4uL9RaH2ifE+HdPW6La89sqmQLsg@mail.gmail.com>

Le 9 mars 2017 7:32 PM, "Brett Cannon" <brett at python.org> a ?crit :

In general I expect none of those branches to live longer than 24 hours as
the PRs they were created for should be merged in less than an hour. If a
branch is older than a day then it means someone probably forgot to delete
the branch after merging a PR.


My main experience with Git is the OpenStack project and in this project
there is no such "temporary" branches.

I didn't know that it was possible to remove an "upstream" branch in Git.

I will see in a few weeks if these branches are an issu in practice or not
;-)

Right now, I'm still a little bit lost in the long list of branches. I have
many local branches too.

Victor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170310/62d16bc3/attachment.html>

From barry at python.org  Thu Mar  9 20:59:48 2017
From: barry at python.org (Barry Warsaw)
Date: Thu, 9 Mar 2017 20:59:48 -0500
Subject: [python-committers] New ncoghlan-bpo-29537-NEWS branch?
In-Reply-To: <20170309193005.91CDF1B1003D@webabinitio.net>
References: <CAMpsgwZZtVuscf13uEQc76g4KvSZP_y8UUkTZLmTEa4V8az9Dw@mail.gmail.com>
 <CAMpsgwZ3CgHXkFXOfOX4C7Ytpp913wVpah9DGNeuwM5rO7YBXA@mail.gmail.com>
 <CADiSq7fSf+UYUujtz_M_3Mwq6KJuVdt+qOw5q2QixOgP7hzFiA@mail.gmail.com>
 <CAP1=2W46JYRdAGoTj4tk5XHZwGadyaW=1qevUY=SkuuHkcrAQA@mail.gmail.com>
 <20170309193005.91CDF1B1003D@webabinitio.net>
Message-ID: <20170309205948.689fbc0b@subdivisions.wooz.org>

On Mar 09, 2017, at 02:30 PM, R. David Murray wrote:

>If it isn't already in the devguide (I have to admit I haven't really
>read the new guide yet), once you end up pulling one of those branches
>into your remotes, it will stay there until you do:
>
>    git remote prune <upstream>
>
>The above will delete any local copies of branches that have been
>deleted in <upstream>.

It may be equivalent, but I generally do `git fetch --prune --all` to get rid
of local copies of deleted branches in all remotes.  Then `git branch -d` to
remove any local tracking branches of pruned branches, e.g. if one of my
branches has been merged and deleted on GitHub.

Not to start an editor war, but *if* you are an Emacs user, I highly recommend
magit for dealing with git repositories.  It's completely changed my opinion
of git for the better.  I no longer complain that much about git's command
line --'cause I barely use it!  That, and git bash completion which you can
probably get from your Linux distro if you use such a thing, has actually made
git pretty indispensable for me now.  (Brett may be shocked given my previous
advocacy for alternatives. ;)

Maybe we should have a git tips and tricks BoF at Pycon.  I'd love to hear
about ways other people use git, especially on the CPython repo.

Cheers,
-Barry

From brett at python.org  Fri Mar 10 13:23:08 2017
From: brett at python.org (Brett Cannon)
Date: Fri, 10 Mar 2017 18:23:08 +0000
Subject: [python-committers] New ncoghlan-bpo-29537-NEWS branch?
In-Reply-To: <CAMpsgwbOYnJLG_gdmgWFUv4uL9RaH2ifE+HdPW6La89sqmQLsg@mail.gmail.com>
References: <CAMpsgwZZtVuscf13uEQc76g4KvSZP_y8UUkTZLmTEa4V8az9Dw@mail.gmail.com>
 <CAMpsgwZ3CgHXkFXOfOX4C7Ytpp913wVpah9DGNeuwM5rO7YBXA@mail.gmail.com>
 <CADiSq7fSf+UYUujtz_M_3Mwq6KJuVdt+qOw5q2QixOgP7hzFiA@mail.gmail.com>
 <CAP1=2W46JYRdAGoTj4tk5XHZwGadyaW=1qevUY=SkuuHkcrAQA@mail.gmail.com>
 <CAMpsgwZbhDOe2cc11SeVA7EuTWVn83mGg742+QGWo7_3GQBWaQ@mail.gmail.com>
 <CAMpsgwYjEJ_iTRp9=B04rqUzzinh4ZDg_V1vYNVk7o9bzxb-uQ@mail.gmail.com>
 <CAMpsgwbOYnJLG_gdmgWFUv4uL9RaH2ifE+HdPW6La89sqmQLsg@mail.gmail.com>
Message-ID: <CAP1=2W7WFGiExL2gUX=Bc5tnC3pV4zn+dyDy0=_KYZBcKrXAsw@mail.gmail.com>

FYI the clearing out of branches that are no longer open for development is
being discussed at https://github.com/python/core-workflow/issues/31

On Thu, 9 Mar 2017 at 17:08 Victor Stinner <victor.stinner at gmail.com> wrote:

> Le 9 mars 2017 7:32 PM, "Brett Cannon" <brett at python.org> a ?crit :
>
> In general I expect none of those branches to live longer than 24 hours as
> the PRs they were created for should be merged in less than an hour. If a
> branch is older than a day then it means someone probably forgot to delete
> the branch after merging a PR.
>
>
> My main experience with Git is the OpenStack project and in this project
> there is no such "temporary" branches.
>
> I didn't know that it was possible to remove an "upstream" branch in Git.
>
> I will see in a few weeks if these branches are an issu in practice or not
> ;-)
>
> Right now, I'm still a little bit lost in the long list of branches. I
> have many local branches too.
>
> Victor
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170310/947cb427/attachment.html>

From brett at python.org  Fri Mar 10 17:13:14 2017
From: brett at python.org (Brett Cannon)
Date: Fri, 10 Mar 2017 22:13:14 +0000
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
Message-ID: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>

I can't believe it's been 4 weeks. It feels like it was ages/yesterday when
we moved. :)

First, I hope people are not regretting letting/having me make this
migration. I know there have been some things to work through (and others
still to come), but I hope this is all a net positive (either now or in the
near future).

Second, I wanted to get initial feedback on things we can easily tweak:

   - Requiring Travis to pass (I *really* don't want to turn this off as we
   already had a broken build when I temporarily turned it off at someone's
   request when Travis was backed up from the AWS S3 outage; I also don't plan
   to make AppVeyor required unless there's a way to make it be skipped for
   doc-only changes)
   - Cherry-picking working out? (We can go back to forward merging if
   people really want to, but I think long-term cherry-picking will allow for
   more automation)
      - Along with that, are the labels for cherry-picking working out?
      (Some devs seem to like using title labels like `[3.6]` to flag
      cherry-picks so it's more obvious in emails so I don't know if the labels
      are really that useful)
   - Is the mention bot helpful? (Our config is at
   https://github.com/python/cpython/blob/master/.mention-bot and the docs
   are at https://github.com/facebook/mention-bot)
   - Anything to tweak about the coverage bot and reports? (Our config is
   at https://github.com/python/cpython/blob/master/.codecov.yml and docs
   at https://docs.codecov.io/docs/codecov-yaml)

Third, I wanted to point out some of the more critical discussions going on
at https://github.com/python/core-workflow/issues. Specifically,
https://github.com/python/core-workflow/issues/6 is working towards a
solution for Misc/NEWS so if you care about the final solution you should
participate there. After Misc/NEWS is solved the next step becomes solving
the cherry-picking overhead with a more automated approach. We are also
discussing closed branches to make the list of branches more manageable at
https://github.com/python/core-workflow/issues/31.

Fourth, the lack of messages showing up on bugs.python.org after a commit
is being tracked at http://psf.upfronthosting.co.za/roundup/meta/issue613.
I'm sure Ezio and Maciej would appreciate any help people may be able to
volunteer to help in solving the problem.

Fifth, anything I missed? :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170310/21060a07/attachment.html>

From donald at stufft.io  Fri Mar 10 19:32:17 2017
From: donald at stufft.io (Donald Stufft)
Date: Fri, 10 Mar 2017 19:32:17 -0500
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
Message-ID: <3A2A1F62-A10C-4991-BB4C-0A866D123C9D@stufft.io>


> On Mar 10, 2017, at 5:13 PM, Brett Cannon <brett at python.org> wrote:
> 
> I can't believe it's been 4 weeks. It feels like it was ages/yesterday when we moved. :)
> 
> First, I hope people are not regretting letting/having me make this migration. I know there have been some things to work through (and others still to come), but I hope this is all a net positive (either now or in the near future).
> 
> Second, I wanted to get initial feedback on things we can easily tweak:
> Requiring Travis to pass (I really don't want to turn this off as we already had a broken build when I temporarily turned it off at someone's request when Travis was backed up from the AWS S3 outage; I also don't plan to make AppVeyor required unless there's a way to make it be skipped for doc-only changes)

I agree with not wanting to turn off mandatory CI. It?d be nice to get as much coverage of platforms as we can as required CI on a per-merge basis, but there is obviously a balance to be had here between quick responses and maximal coverage.

> Cherry-picking working out? (We can go back to forward merging if people really want to, but I think long-term cherry-picking will allow for more automation)
> Along with that, are the labels for cherry-picking working out? (Some devs seem to like using title labels like `[3.6]` to flag cherry-picks so it's more obvious in emails so I don't know if the labels are really that useful)

For the couple of things I?ve done I?ve not had any problem with it.

One thing I noticed that might be weird is that Misc/NEWS is kind of weird now. On `master` it only contains entries for 3.6 up until the point that 3.6 was branched off of `master` (or more specifically in this case, since we migrated to a cherry-picking work flow). This will likely cause some issues now that I think about it with the stuff in #python/core-workflow#6 because files added to `master` between the last release of X.Y and when X.Y gets branched off of `master` are going to show up as new in X.Y+1. This could be resolved I think by, immediately altering branching X.Y off of `master`, deleting all pending news files and also cherry-picking the ?compile? step of say, 3.6 into the `master` branch (and so on up the line). Alternatively still do the delete thing, but make the ``Misc/NEWS`` specific to a particular release series.

> Is the mention bot helpful? (Our config is at https://github.com/python/cpython/blob/master/.mention-bot <https://github.com/python/cpython/blob/master/.mention-bot> and the docs are at https://github.com/facebook/mention-bot <https://github.com/facebook/mention-bot>)

I?ve found it helpful thus far. It?s poked me on a  few issues and I jumped in and gave a review on them. There is too much churn in python/cpython for me to get notified of every issue. I suspect as we get more people submitting PRs (and thus, retaining author) it will get more diverse in who it notifies as well.

> Anything to tweak about the coverage bot and reports? (Our config is at https://github.com/python/cpython/blob/master/.codecov.yml <https://github.com/python/cpython/blob/master/.codecov.yml> and docs at https://docs.codecov.io/docs/codecov-yaml <https://docs.codecov.io/docs/codecov-yaml>)
> Third, I wanted to point out some of the more critical discussions going on at https://github.com/python/core-workflow/issues <https://github.com/python/core-workflow/issues>. Specifically, https://github.com/python/core-workflow/issues/6 <https://github.com/python/core-workflow/issues/6> is working towards a solution for Misc/NEWS so if you care about the final solution you should participate there. After Misc/NEWS is solved the next step becomes solving the cherry-picking overhead with a more automated approach. We are also discussing closed branches to make the list of branches more manageable at https://github.com/python/core-workflow/issues/31 <https://github.com/python/core-workflow/issues/31>.
> 
> Fourth, the lack of messages showing up on bugs.python.org <http://bugs.python.org/> after a commit is being tracked at http://psf.upfronthosting.co.za/roundup/meta/issue613 <http://psf.upfronthosting.co.za/roundup/meta/issue613>. I'm sure Ezio and Maciej would appreciate any help people may be able to volunteer to help in solving the problem.
> 
> Fifth, anything I missed? :)
> _______________________________________________
> 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/


?
Donald Stufft



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

From vadmium+py at gmail.com  Fri Mar 10 20:38:28 2017
From: vadmium+py at gmail.com (Martin Panter)
Date: Sat, 11 Mar 2017 01:38:28 +0000
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <3A2A1F62-A10C-4991-BB4C-0A866D123C9D@stufft.io>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <3A2A1F62-A10C-4991-BB4C-0A866D123C9D@stufft.io>
Message-ID: <CA+eR4cE7K3ja1Q72U2FMUiTB7uqOs2G-RkFiWcBG2TO=9umy6g@mail.gmail.com>

> On Mar 10, 2017, at 5:13 PM, Brett Cannon <brett at python.org> wrote:
> Is the mention bot helpful? (Our config is at
> https://github.com/python/cpython/blob/master/.mention-bot and the docs are
> at https://github.com/facebook/mention-bot)

On 11 March 2017 at 00:32, Donald Stufft <donald at stufft.io> wrote:
> I?ve found it helpful thus far. It?s poked me on a  few issues and I jumped
> in and gave a review on them. There is too much churn in python/cpython for
> me to get notified of every issue. I suspect as we get more people
> submitting PRs (and thus, retaining author) it will get more diverse in who
> it notifies as well.

I dislike it. At the moment I have the Git Hub repository blocked, but
this means I can?t even subscribe myself to interesting threads any
more. I think there were way too many useless emails (lacking context,
uninteresting to me, etc). It is automated spam.

I encourage you to remove it, or at least make it opt-in. Perhaps you
can encourage contributors to look themselves at the ?experts? list,
history of the relevant code, or whatever, to find potential people to
invite to a Git Hub discussion.

From donald at stufft.io  Fri Mar 10 20:39:52 2017
From: donald at stufft.io (Donald Stufft)
Date: Fri, 10 Mar 2017 20:39:52 -0500
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <CA+eR4cE7K3ja1Q72U2FMUiTB7uqOs2G-RkFiWcBG2TO=9umy6g@mail.gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <3A2A1F62-A10C-4991-BB4C-0A866D123C9D@stufft.io>
 <CA+eR4cE7K3ja1Q72U2FMUiTB7uqOs2G-RkFiWcBG2TO=9umy6g@mail.gmail.com>
Message-ID: <8919FD88-1EFA-434D-BFC9-7C3A984D1130@stufft.io>


> On Mar 10, 2017, at 8:38 PM, Martin Panter <vadmium+py at gmail.com> wrote:
> 
>> On Mar 10, 2017, at 5:13 PM, Brett Cannon <brett at python.org> wrote:
>> Is the mention bot helpful? (Our config is at
>> https://github.com/python/cpython/blob/master/.mention-bot and the docs are
>> at https://github.com/facebook/mention-bot)
> 
> On 11 March 2017 at 00:32, Donald Stufft <donald at stufft.io> wrote:
>> I?ve found it helpful thus far. It?s poked me on a  few issues and I jumped
>> in and gave a review on them. There is too much churn in python/cpython for
>> me to get notified of every issue. I suspect as we get more people
>> submitting PRs (and thus, retaining author) it will get more diverse in who
>> it notifies as well.
> 
> I dislike it. At the moment I have the Git Hub repository blocked, but
> this means I can?t even subscribe myself to interesting threads any
> more. I think there were way too many useless emails (lacking context,
> uninteresting to me, etc). It is automated spam.
> 
> I encourage you to remove it, or at least make it opt-in. Perhaps you
> can encourage contributors to look themselves at the ?experts? list,
> history of the relevant code, or whatever, to find potential people to
> invite to a Git Hub discussion.


You know you can tell it not to message you?


?
Donald Stufft



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

From ezio.melotti at gmail.com  Fri Mar 10 22:14:54 2017
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Sat, 11 Mar 2017 05:14:54 +0200
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
Message-ID: <CACBhJdErOmLCTGPi=kvNh3bLco_6_uZx4ZNyT9NSDVX0Spp5GA@mail.gmail.com>

On Sat, Mar 11, 2017 at 12:13 AM, Brett Cannon <brett at python.org> wrote:
> I can't believe it's been 4 weeks. It feels like it was ages/yesterday when
> we moved. :)
>
> First, I hope people are not regretting letting/having me make this
> migration. I know there have been some things to work through (and others
> still to come), but I hope this is all a net positive (either now or in the
> near future).
>
> Second, I wanted to get initial feedback on things we can easily tweak:
>
> Requiring Travis to pass (I really don't want to turn this off as we already
> had a broken build when I temporarily turned it off at someone's request
> when Travis was backed up from the AWS S3 outage; I also don't plan to make
> AppVeyor required unless there's a way to make it be skipped for doc-only
> changes)
> Cherry-picking working out? (We can go back to forward merging if people
> really want to, but I think long-term cherry-picking will allow for more
> automation)
>
> Along with that, are the labels for cherry-picking working out? (Some devs
> seem to like using title labels like `[3.6]` to flag cherry-picks so it's
> more obvious in emails so I don't know if the labels are really that useful)
>
> Is the mention bot helpful? (Our config is at
> https://github.com/python/cpython/blob/master/.mention-bot and the docs are
> at https://github.com/facebook/mention-bot)
> Anything to tweak about the coverage bot and reports? (Our config is at
> https://github.com/python/cpython/blob/master/.codecov.yml and docs at
> https://docs.codecov.io/docs/codecov-yaml)
>
> Third, I wanted to point out some of the more critical discussions going on
> at https://github.com/python/core-workflow/issues. Specifically,
> https://github.com/python/core-workflow/issues/6 is working towards a
> solution for Misc/NEWS so if you care about the final solution you should
> participate there. After Misc/NEWS is solved the next step becomes solving
> the cherry-picking overhead with a more automated approach. We are also
> discussing closed branches to make the list of branches more manageable at
> https://github.com/python/core-workflow/issues/31.
>
> Fourth, the lack of messages showing up on bugs.python.org after a commit is
> being tracked at http://psf.upfronthosting.co.za/roundup/meta/issue613. I'm
> sure Ezio and Maciej would appreciate any help people may be able to
> volunteer to help in solving the problem.
>

I'm planning to look at this next week (if Maciej doesn't beat me to it).
FTR we have been working on a docker container that contains a test
instance of the tracker: https://github.com/python/docker-bpo/
Even though there are still a few rough edges, it's now pretty
straightforward to get a test tracker up and running.
Next we are planning to make a script to test/debug GitHub payloads
(so I can easily debug issue613) and eventually we will put the image
on DockerHub.

> Fifth, anything I missed? :)
>

I find the documentation in the devguide still lacking.
I've been trying to improve it, but first I have to figure out all the
details of the new workflow.

Best Regards,
Ezio Melotti

From zachary.ware+pydev at gmail.com  Sat Mar 11 03:03:24 2017
From: zachary.ware+pydev at gmail.com (Zachary Ware)
Date: Sat, 11 Mar 2017 02:03:24 -0600
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
Message-ID: <CAKJDb-MM+N=d698OacJyxO+TM=gY-vZrGR54us5UghO5rajHZg@mail.gmail.com>

On Fri, Mar 10, 2017 at 4:13 PM, Brett Cannon <brett at python.org> wrote:
> Requiring Travis to pass (I really don't want to turn this off as we already
> had a broken build when I temporarily turned it off at someone's request
> when Travis was backed up from the AWS S3 outage; I also don't plan to make
> AppVeyor required unless there's a way to make it be skipped for doc-only
> changes)

See GH-611.  I hadn't actually thought about that yet, but it turns
out to be pretty easy.

Also, I'm for keeping the Travis requirement, and also requiring
AppVeyor once we've ironed out some flaky tests.

> Cherry-picking working out? (We can go back to forward merging if people
> really want to, but I think long-term cherry-picking will allow for more
> automation)

Right now, cherry-picking is very annoying but I'm not sure that
merging would be much better with the PR requirement.  I'm looking
forward to automation!

> Along with that, are the labels for cherry-picking working out? (Some devs
> seem to like using title labels like `[3.6]` to flag cherry-picks so it's
> more obvious in emails so I don't know if the labels are really that useful)

I've considered whether I'd prefer having separate 'cherry-pick',
'needs backport', and 'x.y' labels rather than 'cherry-pick for x.y'
and 'needs backport to x.y'.  The separate 'x.y' labels would be
useful for issues that only pertain to a particular branch, but
requires selecting two separate labels when marking a PR as a
cherry-pick.  I'm not sure which I would actually prefer, I'm just
throwing the idea out there.

> Is the mention bot helpful? (Our config is at
> https://github.com/python/cpython/blob/master/.mention-bot and the docs are
> at https://github.com/facebook/mention-bot)

I think so, it has prompted me to give a quick review on a couple of
PRs.  It is occasionally annoying, but it's not hard to ignore.  I can
see how it would be *very* annoying for anyone who has touched large
swaths of the codebase, though.  If there's a way to make it opt-in,
perhaps we could give that a spin?

> Anything to tweak about the coverage bot and reports? (Our config is at
> https://github.com/python/cpython/blob/master/.codecov.yml and docs at
> https://docs.codecov.io/docs/codecov-yaml)

I haven't been noticing much of anything from the coverage bot since
we disallowed its comments.

Overall, I'm positive on the move.  Thanks for continuing to shepherd
the migration, Brett!

-- 
Zach

From donald at stufft.io  Sat Mar 11 11:05:39 2017
From: donald at stufft.io (Donald Stufft)
Date: Sat, 11 Mar 2017 11:05:39 -0500
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <CAKJDb-MM+N=d698OacJyxO+TM=gY-vZrGR54us5UghO5rajHZg@mail.gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <CAKJDb-MM+N=d698OacJyxO+TM=gY-vZrGR54us5UghO5rajHZg@mail.gmail.com>
Message-ID: <2E334A07-393D-4C32-965E-5496F7D76CC4@stufft.io>


> On Mar 11, 2017, at 3:03 AM, Zachary Ware <zachary.ware+pydev at gmail.com> wrote:
> 
>> 
>> Is the mention bot helpful? (Our config is at
>> https://github.com/python/cpython/blob/master/.mention-bot <https://github.com/python/cpython/blob/master/.mention-bot> and the docs are
>> at https://github.com/facebook/mention-bot <https://github.com/facebook/mention-bot>)
> 
> I think so, it has prompted me to give a quick review on a couple of
> PRs.  It is occasionally annoying, but it's not hard to ignore.  I can
> see how it would be *very* annoying for anyone who has touched large
> swaths of the codebase, though.  If there's a way to make it opt-in,
> perhaps we could give that a spin?


There?s no way to make it opt-in except by having people explicitly list what files they want to be notified on (either on an always basis, or on a ?if you couldn?t find enough people through your heuristics? basis).

?
Donald Stufft



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

From mariatta.wijaya at gmail.com  Sat Mar 11 13:25:11 2017
From: mariatta.wijaya at gmail.com (Mariatta Wijaya)
Date: Sat, 11 Mar 2017 10:25:11 -0800
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <2E334A07-393D-4C32-965E-5496F7D76CC4@stufft.io>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <CAKJDb-MM+N=d698OacJyxO+TM=gY-vZrGR54us5UghO5rajHZg@mail.gmail.com>
 <2E334A07-393D-4C32-965E-5496F7D76CC4@stufft.io>
Message-ID: <CAGbohnbf3gu_rjX6KuWX6r=adQ4s5pLc=Xw_9WsAgND6ZNQVDw@mail.gmail.com>

>
> Requiring Travis to pass


Yes please.

 Cherry-picking working out?

Works for me. And I've done a lot of this :)

are the labels for cherry-picking working out?

I like the [3.6] Prefix (Thanks Berker for suggesting it originally)
I think [cherry-pick for  3.6] label is still useful as a visual cue in the
GitHub Web UI, but it does create extra work for core devs to apply the
labels. Perhaps won't be an issue once the cherry-pick bot is in place?
Anyway, I think we should keep both :)

Is the mention bot helpful?
>
I think if we can reduce the number of reviewers from 5 to 3 or 2, it might
reduce the amount of spam people are getting?
When someone starts blacklisting themselves from the mention-bot, it
just means that another person will now get spammed, and then decided to
blacklist themselves too.

anything I missed?

I'm wishing for an easy way to differentiate/identify PRs where:
- It's been reviewed, changes were requested, but author has not
responded/made updates. --> so don't bother reviewing
- It's been reviewed, changes were requested, and author has updated the
PR. --> so it's ready for another look
At the moment, both of these scenarios are shown as  "Changes Requested" in
GitHub web UI. It's hard to determine whether it's time to re-review the PR
or not.

Maybe we can add [wip] in the title after we requested the change. Once PR
author made further changes, they can remove the [wip].

Right now, cherry-picking is very annoying but I'm not sure that
> merging would be much better with the PR requirement.  I'm looking
> forward to automation!


I have a semi-automated command line script here:
https://github.com/mariatta/chic_a_cherry_picker
Please try it out :) I've cherry-picked quite a number of commits with this.
Works well when you don't anticipate any merge conflicts :)

The command line is something like:
$ python -m cherry_picker some-commit-sha1 3.6 3.5
It will do the cherry-pick and opens up web browser for creating the PR,
with head and base branches preselected.
All you need to do is enter [3.5] or [3.6] in the description, and press
the shiny green 'Create Pull Request' button.

Related: here's a list of merged PRs that need backporting to 3.6
https://github.com/python/cpython/pulls?utf8=%E2%9C%93&q=is%3Apr%20label%3A%22needs%20backport%20to%203.6%22%20is%3Amerged%20


Overall, I'm positive on the move.  Thanks for continuing to shepherd
> the migration, Brett!

+1.Thanks!



Mariatta Wijaya

On Sat, Mar 11, 2017 at 8:05 AM, Donald Stufft <donald at stufft.io> wrote:

>
> On Mar 11, 2017, at 3:03 AM, Zachary Ware <zachary.ware+pydev at gmail.com>
> wrote:
>
>
> Is the mention bot helpful? (Our config is at
> https://github.com/python/cpython/blob/master/.mention-bot and the docs
> are
> at https://github.com/facebook/mention-bot)
>
>
> I think so, it has prompted me to give a quick review on a couple of
> PRs.  It is occasionally annoying, but it's not hard to ignore.  I can
> see how it would be *very* annoying for anyone who has touched large
> swaths of the codebase, though.  If there's a way to make it opt-in,
> perhaps we could give that a spin?
>
>
>
> There?s no way to make it opt-in except by having people explicitly list
> what files they want to be notified on (either on an always basis, or on a
> ?if you couldn?t find enough people through your heuristics? basis).
>
> ?
> Donald Stufft
>
>
>
>
> _______________________________________________
> 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/20170311/d1886991/attachment.html>

From vadmium+py at gmail.com  Sat Mar 11 21:30:38 2017
From: vadmium+py at gmail.com (Martin Panter)
Date: Sun, 12 Mar 2017 02:30:38 +0000
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <8919FD88-1EFA-434D-BFC9-7C3A984D1130@stufft.io>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <3A2A1F62-A10C-4991-BB4C-0A866D123C9D@stufft.io>
 <CA+eR4cE7K3ja1Q72U2FMUiTB7uqOs2G-RkFiWcBG2TO=9umy6g@mail.gmail.com>
 <8919FD88-1EFA-434D-BFC9-7C3A984D1130@stufft.io>
Message-ID: <CA+eR4cGnzGDXbuo8Fqx+FZiLNL4p0cOk-1frP9u90QR=HX8Wbw@mail.gmail.com>

> On Mar 10, 2017, at 5:13 PM, Brett Cannon <brett at python.org> wrote:
> Is the mention bot helpful? (Our config is at
> https://github.com/python/cpython/blob/master/.mention-bot and the docs are
> at https://github.com/facebook/mention-bot)

> On Mar 10, 2017, at 8:38 PM, Martin Panter <vadmium+py at gmail.com> wrote:
> I dislike it. At the moment I have the Git Hub repository blocked, but
> this means I can?t even subscribe myself to interesting threads any
> more. I think there were way too many useless emails (lacking context,
> uninteresting to me, etc). It is automated spam.
>
> I encourage you to remove it, or at least make it opt-in. Perhaps you
> can encourage contributors to look themselves at the ?experts? list,
> history of the relevant code, or whatever, to find potential people to
> invite to a Git Hub discussion.

On 11 March 2017 at 01:39, Donald Stufft <donald at stufft.io> wrote:
> You know you can tell it not to message you?

I have tried <https://github.com/mention-bot/how-to-unsubscribe>, but
that didn?t seem to have much effect. At least, I was still getting
subscribed to new pull requests after blocking the bot.

I am also aware of
<https://github.com/python/cpython/blob/master/.mention-bot> but
haven?t added myself there yet.

From donald at stufft.io  Sat Mar 11 22:09:21 2017
From: donald at stufft.io (Donald Stufft)
Date: Sat, 11 Mar 2017 22:09:21 -0500
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <CA+eR4cGnzGDXbuo8Fqx+FZiLNL4p0cOk-1frP9u90QR=HX8Wbw@mail.gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <3A2A1F62-A10C-4991-BB4C-0A866D123C9D@stufft.io>
 <CA+eR4cE7K3ja1Q72U2FMUiTB7uqOs2G-RkFiWcBG2TO=9umy6g@mail.gmail.com>
 <8919FD88-1EFA-434D-BFC9-7C3A984D1130@stufft.io>
 <CA+eR4cGnzGDXbuo8Fqx+FZiLNL4p0cOk-1frP9u90QR=HX8Wbw@mail.gmail.com>
Message-ID: <7F3D871B-CE55-41BA-BCB5-C32B9370CEB3@stufft.io>


> On Mar 11, 2017, at 9:30 PM, Martin Panter <vadmium+py at gmail.com> wrote:
> 
> I am also aware of
> <https://github.com/python/cpython/blob/master/.mention-bot <https://github.com/python/cpython/blob/master/.mention-bot>> but
> haven?t added myself there yet.


Yea this is what I meant, adding your name to the ``userBlacklist`` array.

?
Donald Stufft



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170311/81d9313d/attachment-0001.html>

From ncoghlan at gmail.com  Sun Mar 12 05:59:52 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 12 Mar 2017 19:59:52 +1000
Subject: [python-committers] Recent updates to "make patchcheck"
Message-ID: <CADiSq7cxzo2HeGmZMq8mC=OqRG+Oesv_qJbBrH4vYfra+yRVPQ@mail.gmail.com>

Hi folks,

I use "make patchcheck" a fair bit as a checklist for whether or not a
change needs any further adjustments before merging, but found it's
patch-based approach less then helpful with the new PR-centric workflow.

Accordingly, I just merged a few key updates to master and the 2.7/3.5/3.6
branches:

- it will automatically determine the current base branch, and check all
files changed relatively to that branch, rather than only checking
uncommitted changes
- it accepts any ".git" entry as indicating a checkout (nor just
directories), since "git worktree" defines ".git" as a configuration file

The automatic determination of the base branch is as follows:

- if an "upstream" remote is defined, it's used as the base branch remote,
otherwise "origin" is used
- if sys.version_info.releaselevel is "alpha", the base branch is
"<remote>/master"
- otherwise it is "<remote>/X.Y" (also based on sys.version_info)

Note that this works fine for "make patchcheck" (since it uses the just
built Python to run Tools/scripts/patchcheck.py), but anyone running the
tool directly rather than through the makefile may have to adjust how they
do things.

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/20170312/308c8838/attachment.html>

From ncoghlan at gmail.com  Sun Mar 12 07:10:14 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 12 Mar 2017 21:10:14 +1000
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
Message-ID: <CADiSq7fMG-J19tnRBgwZHXSGnKXtp99JZ=nk5V_KS4YfB460Tg@mail.gmail.com>

On 11 March 2017 at 08:13, Brett Cannon <brett at python.org> wrote:

> I can't believe it's been 4 weeks. It feels like it was ages/yesterday
> when we moved. :)
>
> First, I hope people are not regretting letting/having me make this
> migration. I know there have been some things to work through (and others
> still to come), but I hope this is all a net positive (either now or in the
> near future).
>
> Second, I wanted to get initial feedback on things we can easily tweak:
>
>    - Requiring Travis to pass (I *really* don't want to turn this off as
>    we already had a broken build when I temporarily turned it off at someone's
>    request when Travis was backed up from the AWS S3 outage; I also don't plan
>    to make AppVeyor required unless there's a way to make it be skipped for
>    doc-only changes)
>
> I think this is a good thing, but it's annoying some times when processing
a change that needs to go to all 4 currently active branches. The other
case where it's annoying is when backfilling NEWS entries - if there's a
backlog, then it still takes a while to get to the point of Travis
detecting that there isn't actually anything for Travis to do.

It's probably worth talking to the PSF and Travis CI to see if it's
possible to speed things up a bit or get more parallel workers (some of the
PSF's larger sponsors are actually providing in-kind donations of services
rather than purely financial sponsorship).

>
>    - Cherry-picking working out? (We can go back to forward merging if
>    people really want to, but I think long-term cherry-picking will allow for
>    more automation)
>
> I'm still a fan of cherry picking, as it simplifies the typical case to
"fix master, worry about backports later".

>
>    - Along with that, are the labels for cherry-picking working out?
>       (Some devs seem to like using title labels like `[3.6]` to flag
>       cherry-picks so it's more obvious in emails so I don't know if the labels
>       are really that useful)
>
> There was at least one PR submitter confused in IRC today as to whether or
not the "Needs backport to..." labels were asking *them* to do something.


>
>    - Is the mention bot helpful? (Our config is at
>    https://github.com/python/cpython/blob/master/.mention-bot
>    <https://github.com/python/cpython/blob/master/.mention-bot> and the
>    docs are at https://github.com/facebook/mention-bot)
>
> Honestly, I'm starting to think we're going to have to tweak it a bit (or
come up with our own variant) to get something suitable for a primarily
volunteer-based development team, rather than the primarily paid teams that
I believe the mention-bot was originally written for. As it currently
stands, it's veering too far into burnout-inducing "Have you done enough
for CPython lately?" territory for my liking:
https://nolanlawson.com/2017/03/05/what-it-feels-like-to-be-an-open-source-maintainer/

So I'd personally vote for this to be turned off until there's a way to run
it in an *opt-in* configuration, rather than the current opt-out setup.

Another possibility would be to tweak the GitHub/bugs.python.org bridge to
add comments for PR *creation*, such that everyone on the nosy list gets
the alert that the PR exists (hence implicitly requesting a review from the
maintainers following the issue). That way things would better align with
the entries we've added to the experts index.

>
>    - Anything to tweak about the coverage bot and reports? (Our config is
>    at https://github.com/python/cpython/blob/master/.codecov.yml and docs
>    at https://docs.codecov.io/docs/codecov-yaml)
>
> I was going to ask if there was a way to get the "Details" link to go
straight to a useful report, but it seems like that may have already been
tweaked.


> Third, I wanted to point out some of the more critical discussions going
> on at https://github.com/python/core-workflow/issues. Specifically,
> https://github.com/python/core-workflow/issues/6 is working towards a
> solution for Misc/NEWS so if you care about the final solution you should
> participate there. After Misc/NEWS is solved the next step becomes solving
> the cherry-picking overhead with a more automated approach.
>

For the cherry-picking automation, I've been very happy with Mariatta's
utility, and I believe that with a few robustness tweaks and a
conflict-avoiding approach to handling Misc/NEWS it would be up to the task
of generating the actual PRs as well. (The other side of the bot that
actually handled the interaction with GitHub could presumably be modeled on
the way the existing knights-who-say-ni bot works)

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/20170312/75922d6e/attachment.html>

From p.f.moore at gmail.com  Sun Mar 12 07:37:21 2017
From: p.f.moore at gmail.com (Paul Moore)
Date: Sun, 12 Mar 2017 11:37:21 +0000
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
Message-ID: <CACac1F_4H+1qpMe38JXcenC-sfDq+BgMhfHiEZ-+=+RgVgYdAg@mail.gmail.com>

On 10 March 2017 at 22:13, Brett Cannon <brett at python.org> wrote:
> Fifth, anything I missed? :)

One thing, somewhat peripheral. Since the move, issues on bpo now get
PRs added to them. That's fine, but it further reduces the signal to
noise ratio on the emails sent out for an issue (it was always bad,
with emails sent every time someone added or removed themselves from
the nosy list, and things like that, this just makes things a little
worse). Ideally, I'd like to only get emails when new messages are
added to the issue, but I don't think that's possible.

I don't have a problem with the new "PRs attached to this issue" field
- that's of course important to have. But is there any way to not have
them generate emails (probably on a per-user basis, as I'm sure
there's people who appreciate emails when PRs are added)? I guess the
other option is a client-side filter, but I'm not sure how easy it
would be to do something like that.

Paul

From mal at egenix.com  Sun Mar 12 09:33:24 2017
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun, 12 Mar 2017 14:33:24 +0100
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
Message-ID: <c1a33ea8-c3f0-27fc-8ad7-a2e26730147d@egenix.com>

On 10.03.2017 23:13, Brett Cannon wrote:
> Fifth, anything I missed? :)

My main nit after the move is that messages to the checkin list
no longer include the full patch. This makes reviews harder than
necessary (you always have to go through the browser).

Is there some way this could be changed back to what we had
previously or is this a hard limitation of github ?

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...           http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...           http://zope.egenix.com/
________________________________________________________________________

::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::

   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/

From rdmurray at bitdance.com  Sun Mar 12 09:58:53 2017
From: rdmurray at bitdance.com (R. David Murray)
Date: Sun, 12 Mar 2017 09:58:53 -0400
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <CACac1F_4H+1qpMe38JXcenC-sfDq+BgMhfHiEZ-+=+RgVgYdAg@mail.gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <CACac1F_4H+1qpMe38JXcenC-sfDq+BgMhfHiEZ-+=+RgVgYdAg@mail.gmail.com>
Message-ID: <20170312135854.326911B10015@webabinitio.net>

On Sun, 12 Mar 2017 11:37:21 -0000, Paul Moore <p.f.moore at gmail.com> wrote:
> I don't have a problem with the new "PRs attached to this issue" field
> - that's of course important to have. But is there any way to not have
> them generate emails (probably on a per-user basis, as I'm sure
> there's people who appreciate emails when PRs are added)? I guess the
> other option is a client-side filter, but I'm not sure how easy it
> would be to do something like that.

Kind of telling that Nick asked for a "notify when PR created" feature,
and you are asking for it to be disabled :)  Yes, it would need to be
a per-user setting, and currently it is not (it is a global setting
in Roundup).

I'm sure upstream would accept a patch to add a per-user setting for
this (and other things!).  Since the nosy emails are generated by a
reactor (a code snippet specific to the tracker instance) it wouldn't
even *need* to go upstream, and wouldn't be all that hard to write,
I think.  I'm not volunteering, though, not enough time :(

Maybe with the new docker tracker-test-setup that Maciej and Ezio have
refined we'll be able to get more volunteers interested in working
on the tracker codebase.  When they are ready it could use a bit more
visibility (a posting to python-dev and one to core-mentorship, say).

--David

From p.f.moore at gmail.com  Sun Mar 12 10:26:34 2017
From: p.f.moore at gmail.com (Paul Moore)
Date: Sun, 12 Mar 2017 14:26:34 +0000
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <20170312135854.326911B10015@webabinitio.net>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <CACac1F_4H+1qpMe38JXcenC-sfDq+BgMhfHiEZ-+=+RgVgYdAg@mail.gmail.com>
 <20170312135854.326911B10015@webabinitio.net>
Message-ID: <CACac1F-Eu81E7bby-6r_EdCbHSYtsN+QW5TKbKXJ6x5G4VOBMg@mail.gmail.com>

On 12 March 2017 at 13:58, R. David Murray <rdmurray at bitdance.com> wrote:
> On Sun, 12 Mar 2017 11:37:21 -0000, Paul Moore <p.f.moore at gmail.com> wrote:
>> I don't have a problem with the new "PRs attached to this issue" field
>> - that's of course important to have. But is there any way to not have
>> them generate emails (probably on a per-user basis, as I'm sure
>> there's people who appreciate emails when PRs are added)? I guess the
>> other option is a client-side filter, but I'm not sure how easy it
>> would be to do something like that.
>
> Kind of telling that Nick asked for a "notify when PR created" feature,
> and you are asking for it to be disabled :)  Yes, it would need to be
> a per-user setting, and currently it is not (it is a global setting
> in Roundup).

Yeah. Personally, I find that I can skim messages, but notifications
(status changes, PRs added, nosy changes, etc) distract me badly. As a
result, when the ratio of notifications gets too high, I end up
feeling like I have no real option but to unsubscribe altogether,
which reduces my involvement drastically. That's not an issue with the
github move per se - prior to github I was basically ignoring all bpo
traffic for precisely that reason anyway. The move has generated a lot
*more* traffic that I haven't filtered yet (things like the devguide
and workflow issue mails) plus the review mails on PRs, and that
prompted me to try to be more selective in my filtering rather than
just switching everything off blindly. Unfortunately, I ended up
switching off PR emails as there wasn't enough context without the bpo
messages, and I may yet switch off the others and go back to my old
mode of operation. But it did make me think nevertheless (hence this
message).

> I'm sure upstream would accept a patch to add a per-user setting for
> this (and other things!).  Since the nosy emails are generated by a
> reactor (a code snippet specific to the tracker instance) it wouldn't
> even *need* to go upstream, and wouldn't be all that hard to write,

As I've no knowledge of Roundup, and not a huge amount of spare time,
I probably won't get round to doing this, but thanks for the pointer.

Paul

From brett at python.org  Sun Mar 12 17:11:15 2017
From: brett at python.org (Brett Cannon)
Date: Sun, 12 Mar 2017 21:11:15 +0000
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <c1a33ea8-c3f0-27fc-8ad7-a2e26730147d@egenix.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <c1a33ea8-c3f0-27fc-8ad7-a2e26730147d@egenix.com>
Message-ID: <CAP1=2W62-=scBJB4PqGYUyg8gEQ-Ew3HKkOSbOdpU6cNcYen5g@mail.gmail.com>

On Sun, 12 Mar 2017 at 06:33 M.-A. Lemburg <mal at egenix.com> wrote:

> On 10.03.2017 23:13, Brett Cannon wrote:
> > Fifth, anything I missed? :)
>
> My main nit after the move is that messages to the checkin list
> no longer include the full patch. This makes reviews harder than
> necessary (you always have to go through the browser).
>
> Is there some way this could be changed back to what we had
> previously or is this a hard limitation of github ?
>

It's a hard limitation *of the GitHub-provided email solution*. With
GitHub's APIs and enough time someone could either come up with a custom
email solution or a web page that showed this information (you literally
just need to add ".diff" to the end of a URL to get the diff itself for a
PR, e.g. https://github.com/python/cpython/pull/648.diff will redirect to a
raw diff). There might also already be other solutions out there that do
what you're after.

Obviously this all requires work on someone's part. :) (I've also moved
completely off of an email-based workflow so I'm definitely not the right
person to drive this sort of thing.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170312/192c010d/attachment.html>

From brett at python.org  Sun Mar 12 21:12:00 2017
From: brett at python.org (Brett Cannon)
Date: Mon, 13 Mar 2017 01:12:00 +0000
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <CADiSq7fMG-J19tnRBgwZHXSGnKXtp99JZ=nk5V_KS4YfB460Tg@mail.gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <CADiSq7fMG-J19tnRBgwZHXSGnKXtp99JZ=nk5V_KS4YfB460Tg@mail.gmail.com>
Message-ID: <CAP1=2W6j9HqeAFxw=UJmb=GRCP9X-UQgz6uheWufbrNkv_SKVg@mail.gmail.com>

On Sun, 12 Mar 2017 at 04:10 Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 11 March 2017 at 08:13, Brett Cannon <brett at python.org> wrote:
>
> I can't believe it's been 4 weeks. It feels like it was ages/yesterday
> when we moved. :)
>
> First, I hope people are not regretting letting/having me make this
> migration. I know there have been some things to work through (and others
> still to come), but I hope this is all a net positive (either now or in the
> near future).
>
> Second, I wanted to get initial feedback on things we can easily tweak:
>
>    - Requiring Travis to pass (I *really* don't want to turn this off as
>    we already had a broken build when I temporarily turned it off at someone's
>    request when Travis was backed up from the AWS S3 outage; I also don't plan
>    to make AppVeyor required unless there's a way to make it be skipped for
>    doc-only changes)
>
> I think this is a good thing, but it's annoying some times when processing
> a change that needs to go to all 4 currently active branches. The other
> case where it's annoying is when backfilling NEWS entries - if there's a
> backlog, then it still takes a while to get to the point of Travis
> detecting that there isn't actually anything for Travis to do.
>
> It's probably worth talking to the PSF and Travis CI to see if it's
> possible to speed things up a bit or get more parallel workers (some of the
> PSF's larger sponsors are actually providing in-kind donations of services
> rather than purely financial sponsorship).
>

Already have. We got 25 jobs shared between python, pypa, and pyca thanks
to Donald. At this point the best option we have to speed things up is to
consider dropping tests (e.g. do we want to keep the C++ header test, or do
we really need to test both clang and gcc?).


>
>    - Cherry-picking working out? (We can go back to forward merging if
>    people really want to, but I think long-term cherry-picking will allow for
>    more automation)
>
> I'm still a fan of cherry picking, as it simplifies the typical case to
> "fix master, worry about backports later".
>
>
>    - Along with that, are the labels for cherry-picking working out?
>       (Some devs seem to like using title labels like `[3.6]` to flag
>       cherry-picks so it's more obvious in emails so I don't know if the labels
>       are really that useful)
>
> There was at least one PR submitter confused in IRC today as to whether or
> not the "Needs backport to..." labels were asking *them* to do something.
>

I'm not quite sure how to solve that one beyond what is in the devguide.
And did anyone have an opinion on (I think) Mariatta's idea to cut the
labels down to versions + "needs backport" and "cherry-pick"?


>
>
>
>    - Is the mention bot helpful? (Our config is at
>    https://github.com/python/cpython/blob/master/.mention-bot and the
>    docs are at https://github.com/facebook/mention-bot)
>
> Honestly, I'm starting to think we're going to have to tweak it a bit (or
> come up with our own variant) to get something suitable for a primarily
> volunteer-based development team, rather than the primarily paid teams that
> I believe the mention-bot was originally written for. As it currently
> stands, it's veering too far into burnout-inducing "Have you done enough
> for CPython lately?" territory for my liking:
> https://nolanlawson.com/2017/03/05/what-it-feels-like-to-be-an-open-source-maintainer/
>
> So I'd personally vote for this to be turned off until there's a way to
> run it in an *opt-in* configuration, rather than the current opt-out setup.
>

Since there doesn't seem to be strong support I'm leaning towards switching
it off as well, but I will wait until there's been at least a weekday
around the globe for people to notice this email thread.


>
> Another possibility would be to tweak the GitHub/bugs.python.org bridge
> to add comments for PR *creation*, such that everyone on the nosy list gets
> the alert that the PR exists (hence implicitly requesting a review from the
> maintainers following the issue). That way things would better align with
> the entries we've added to the experts index.
>
>
>    - Anything to tweak about the coverage bot and reports? (Our config is
>    at https://github.com/python/cpython/blob/master/.codecov.yml and docs
>    at https://docs.codecov.io/docs/codecov-yaml)
>
> I was going to ask if there was a way to get the "Details" link to go
> straight to a useful report, but it seems like that may have already been
> tweaked.
>
>
> Third, I wanted to point out some of the more critical discussions going
> on at https://github.com/python/core-workflow/issues. Specifically,
> https://github.com/python/core-workflow/issues/6 is working towards a
> solution for Misc/NEWS so if you care about the final solution you should
> participate there. After Misc/NEWS is solved the next step becomes solving
> the cherry-picking overhead with a more automated approach.
>
>
> For the cherry-picking automation, I've been very happy with Mariatta's
> utility, and I believe that with a few robustness tweaks and a
> conflict-avoiding approach to handling Misc/NEWS it would be up to the task
> of generating the actual PRs as well. (The other side of the bot that
> actually handled the interaction with GitHub could presumably be modeled on
> the way the existing knights-who-say-ni bot works)
>

We could consider moving the script to the core-workflow repo if Mariatta
is amenable so that we can all contribute towards improving it and making
it the short/medium-term solution until we have some bot to do the work
(which could theoretically use the script itself).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170313/0eeb36b1/attachment-0001.html>

From raymond.hettinger at gmail.com  Sun Mar 12 22:11:09 2017
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Sun, 12 Mar 2017 19:11:09 -0700
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
Message-ID: <0371996D-5873-4D86-9484-8A9DDF4F1F30@gmail.com>


> On Mar 10, 2017, at 2:13 PM, Brett Cannon <brett at python.org> wrote:
> 
> I wanted to get initial feedback on things we can easily tweak:

Overall, the new workflow is mostly positive.  The tooling looks great and it seems to have increased the number of participants.

There is a disconnect between discussions on the tracker and discussions on the bug tracker. It would be nice if discussions could be better synchronized.

There does seem to be some confusion on when it is okay to commit.  At least one core dev is of the opinion that if tests are passing it is okay for him to approve and commit regardless of area of expertise, status of the tracker item, or approval of the module maintainer.  IMO, having the tests pass is a pretty low bar and seems to bypass consideration of whether the change is the right thing to do.

For me personally, I've not yet had time to read through all the new processes, the new devguide,and  to get my git/github skills up-to-date, so I've been completely left behind (not a single patch or build since the migration).  I'm hoping that I can get caught up over some upcoming weekend, but the migration did create a whole new set of challenges that I've never had in the last 16 years of core development.  For the time being, I'm mostly helpless and can only comment here are there on various issues.

For people who have more time on their hands or who were already familiar which all the tooling, the migration seems to have been much easier.


Raymond




From ncoghlan at gmail.com  Mon Mar 13 04:04:08 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 13 Mar 2017 18:04:08 +1000
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <20170312135854.326911B10015@webabinitio.net>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <CACac1F_4H+1qpMe38JXcenC-sfDq+BgMhfHiEZ-+=+RgVgYdAg@mail.gmail.com>
 <20170312135854.326911B10015@webabinitio.net>
Message-ID: <CADiSq7fcnHxcmR8xE_Sm235XcAy3e8pMnDsFBRCtAWiSii2BnQ@mail.gmail.com>

On 12 March 2017 at 23:58, R. David Murray <rdmurray at bitdance.com> wrote:

> On Sun, 12 Mar 2017 11:37:21 -0000, Paul Moore <p.f.moore at gmail.com>
> wrote:
> > I don't have a problem with the new "PRs attached to this issue" field
> > - that's of course important to have. But is there any way to not have
> > them generate emails (probably on a per-user basis, as I'm sure
> > there's people who appreciate emails when PRs are added)? I guess the
> > other option is a client-side filter, but I'm not sure how easy it
> > would be to do something like that.
>
> Kind of telling that Nick asked for a "notify when PR created" feature,
> and you are asking for it to be disabled :)  Yes, it would need to be
> a per-user setting, and currently it is not (it is a global setting
> in Roundup).
>

I think what I actually want is for the current notifications to be more
useful, mainly by including the GitHub PR URL, rather than the
internal-to-roundup numeric PR ID.

I'd just forgotten about them until Paul mentioned them, as they're not
particularly useful right now :)

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/20170313/17810de2/attachment.html>

From barry at python.org  Mon Mar 13 11:30:21 2017
From: barry at python.org (Barry Warsaw)
Date: Mon, 13 Mar 2017 11:30:21 -0400
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <0371996D-5873-4D86-9484-8A9DDF4F1F30@gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <0371996D-5873-4D86-9484-8A9DDF4F1F30@gmail.com>
Message-ID: <20170313113021.74e64722@subdivisions.wooz.org>

I agree that overall the new workflow is great.  I haven't done a ton of
commits, but the ones I did went very smoothly (modulo the known and hopefully
soon to be fixed Misc/News conflicts).  I also love being able to do reviews
on GH, and I think the more testing automation we can do, the better.  I'm
actually okay with trading run time for quality checks run automatically.

On Mar 12, 2017, at 07:11 PM, Raymond Hettinger wrote:

>There is a disconnect between discussions on the tracker and discussions on
>the bug tracker. It would be nice if discussions could be better
>synchronized.

This is a pretty common problem given that comments can occur in both places.
IME, it actually doesn't even matter that we're using two different systems;
I've seen it when the entire project is on the same hosting platform.

>There does seem to be some confusion on when it is okay to commit.  At least
>one core dev is of the opinion that if tests are passing it is okay for him
>to approve and commit regardless of area of expertise, status of the tracker
>item, or approval of the module maintainer.  IMO, having the tests pass is a
>pretty low bar and seems to bypass consideration of whether the change is the
>right thing to do.

This *is* a problem, although I would state it slightly differently.  It's
good to have module/domain experts and I definitely want such experts to be
active and involved in discussions around their areas of expertise, but I also
don't want to disempower people from approving changes that seem reasonable.
My worry is that strict ownership is a disincentive and paralyzing force for
improvements.

OTOH, how do we decide when a change is "good"?  I'm tracking and reviewing
the $PYTHONHISTORY change.  *I* think it's a good idea, and haven't seen any
compelling arguments against it.  I also really appreciate a few other people
weighing in (PR#473).  I plan on approving it once the code's in shape and the
tests all pass.  Maybe other people will hate it, but that's why we have
version control I suppose.

>For me personally, I've not yet had time to read through all the new
>processes, the new devguide,and to get my git/github skills up-to-date, so
>I've been completely left behind (not a single patch or build since the
>migration).  I'm hoping that I can get caught up over some upcoming weekend,
>but the migration did create a whole new set of challenges that I've never
>had in the last 16 years of core development.  For the time being, I'm mostly
>helpless and can only comment here are there on various issues.
>
>For people who have more time on their hands or who were already familiar
>which all the tooling, the migration seems to have been much easier.

Yes, I think that's true, and that means that patience will be required, both
from new contributors when their patches take time to land, and in ourselves
for our own changes.  I know I was rather impatient when reviews were
required, but I kind of think that might be a good thing (though not in all
cases).

If you've made it this far, one of the things I'm thinking about is removing
the [Python-checkins] Subject prefix from that mailing list.  It's mostly
redundant given that GH is *also* adding a [python/cpython] prefix[*], though
not entirely since non-GH automation like the daily reference leak doesn't
include it.  I like to see more content in the Subject.

Personal annoyance: GH's threading algorithm plays havoc with my MUA's default
display.  I haven't dug into it yet, but I always see later replies earlier in
the thread view, which is counter to every other conversation I read via
email.

I'm still *really* missing diffs in commit messages.

Cheers,
-Barry

[*] If someone knows a Mailman developer, it might be nice to request some
plugin to do custom Subject mangling.  <wink>

From barry at python.org  Mon Mar 13 11:54:09 2017
From: barry at python.org (Barry Warsaw)
Date: Mon, 13 Mar 2017 11:54:09 -0400
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <CAP1=2W6j9HqeAFxw=UJmb=GRCP9X-UQgz6uheWufbrNkv_SKVg@mail.gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <CADiSq7fMG-J19tnRBgwZHXSGnKXtp99JZ=nk5V_KS4YfB460Tg@mail.gmail.com>
 <CAP1=2W6j9HqeAFxw=UJmb=GRCP9X-UQgz6uheWufbrNkv_SKVg@mail.gmail.com>
Message-ID: <20170313115409.2acf3634@subdivisions.wooz.org>

On Mar 13, 2017, at 01:12 AM, Brett Cannon wrote:

>Since there doesn't seem to be strong support I'm leaning towards switching
>it off as well, but I will wait until there's been at least a weekday
>around the globe for people to notice this email thread.

I actually kind of like the idea of a mentionbot, but the current
implementation has some problems.  Rather than calculating who should be
mentioned based on TIL (touched it last), it would be nicer if this got closer
to solving Raymond's comment.  If the domain expert could be notified when PRs
touch stuff they care about, that might be better.  The mentionbot could then
be opt-in for folks who want to see more detail.

-Barry

From alex.gaynor at gmail.com  Mon Mar 13 11:56:25 2017
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Mon, 13 Mar 2017 11:56:25 -0400
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <20170313115409.2acf3634@subdivisions.wooz.org>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <CADiSq7fMG-J19tnRBgwZHXSGnKXtp99JZ=nk5V_KS4YfB460Tg@mail.gmail.com>
 <CAP1=2W6j9HqeAFxw=UJmb=GRCP9X-UQgz6uheWufbrNkv_SKVg@mail.gmail.com>
 <20170313115409.2acf3634@subdivisions.wooz.org>
Message-ID: <CAFRnB2U9cB3UmYNXGN5wFZ6A6ae15CBppO3hVfcCoDqpnUzi=g@mail.gmail.com>

That suggests an interesting question: Why is the Touched It Last so
different from the domain expert :-)

Alex

On Mon, Mar 13, 2017 at 11:54 AM, Barry Warsaw <barry at python.org> wrote:

> On Mar 13, 2017, at 01:12 AM, Brett Cannon wrote:
>
> >Since there doesn't seem to be strong support I'm leaning towards
> switching
> >it off as well, but I will wait until there's been at least a weekday
> >around the globe for people to notice this email thread.
>
> I actually kind of like the idea of a mentionbot, but the current
> implementation has some problems.  Rather than calculating who should be
> mentioned based on TIL (touched it last), it would be nicer if this got
> closer
> to solving Raymond's comment.  If the domain expert could be notified when
> PRs
> touch stuff they care about, that might be better.  The mentionbot could
> then
> be opt-in for folks who want to see more detail.
>
> -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/
>



-- 
"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/20170313/672ed93b/attachment.html>

From antoine at python.org  Mon Mar 13 12:40:30 2017
From: antoine at python.org (Antoine Pitrou)
Date: Mon, 13 Mar 2017 17:40:30 +0100
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <CAFRnB2U9cB3UmYNXGN5wFZ6A6ae15CBppO3hVfcCoDqpnUzi=g@mail.gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <CADiSq7fMG-J19tnRBgwZHXSGnKXtp99JZ=nk5V_KS4YfB460Tg@mail.gmail.com>
 <CAP1=2W6j9HqeAFxw=UJmb=GRCP9X-UQgz6uheWufbrNkv_SKVg@mail.gmail.com>
 <20170313115409.2acf3634@subdivisions.wooz.org>
 <CAFRnB2U9cB3UmYNXGN5wFZ6A6ae15CBppO3hVfcCoDqpnUzi=g@mail.gmail.com>
Message-ID: <78b4eaa1-329c-2d80-0b9d-319f0d19ccd9@python.org>


Le 13/03/2017 ? 16:56, Alex Gaynor a ?crit :
> That suggests an interesting question: Why is the Touched It Last so
> different from the domain expert :-)

Because there are many changes which don't necessitate a domain expert's
intervention (such as replacing one argument-parsing API with another).

Regards

Antoine.

From yselivanov.ml at gmail.com  Mon Mar 13 12:48:30 2017
From: yselivanov.ml at gmail.com (Yury Selivanov)
Date: Mon, 13 Mar 2017 12:48:30 -0400
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
Message-ID: <73fa950c-3f51-772a-35d0-045179d3f94e@gmail.com>

Hi,

First, I'm really happy that we moved to git and GH.  The GH review tool 
is super convenient and CI integration helps.

I'm less happy about requiring to make a PR for every commit. It's a no 
problem for new features development, but it's a huge pain for a bug 
fixing workflow.  Last week I needed to push a bunch of bug fixes to 
3.7/3.6/3.5.  I had about 6 pull requests to the master branch, + 12 
more for 3.6 and 3.5.  I basically killed my entire second half of the 
day waiting until CI checks clear out.  I spend a few hours pushing just 
3 (!!) committs to all branches.  Thanks to Brett, who disabled the push 
CI check for a while, I was able to push the remaining 3 bug fixes and 
their cherry picks in under 10 minutes.

Yesterday I was working on a few asyncio PRs and a bug in async/await.  
All PRs required cherry-picking.  Again, I was spending significant 
amount of time just creating branches/PRs for cherry-picking.  Again 
waiting for CI checks (even thougn I always run the test suite before I 
push).  In the end of the day, I was so frustrated and discouraged that 
I just stopped working on CPython.

The current workflow makes it significantly harder for me to be 
productive.  At this point I'm so discouraged of working on any bug 
fixes that I consider to stop working on them until the full 
cherry-picking automation is implemented.

So I guess what I'm asking for is to consider turning the CI/PR push 
requirement off until we have automatic cherry-picking and a new NEWS 
file workflow.  We lived without this check for many years with 
mercurial.  Yes, all of us pushed some broken commits, but we have 
buildbots and CI, so nothing horrible ever happended.

Thank you,
Yury


On 2017-03-10 5:13 PM, Brett Cannon wrote:
> I can't believe it's been 4 weeks. It feels like it was ages/yesterday 
> when we moved. :)
>
> First, I hope people are not regretting letting/having me make this 
> migration. I know there have been some things to work through (and 
> others still to come), but I hope this is all a net positive (either 
> now or in the near future).
>
> Second, I wanted to get initial feedback on things we can easily tweak:
>
>   * Requiring Travis to pass (I *really* don't want to turn this off
>     as we already had a broken build when I temporarily turned it off
>     at someone's request when Travis was backed up from the AWS S3
>     outage; I also don't plan to make AppVeyor required unless there's
>     a way to make it be skipped for doc-only changes)
>   * Cherry-picking working out? (We can go back to forward merging if
>     people really want to, but I think long-term cherry-picking will
>     allow for more automation)
>       o Along with that, are the labels for cherry-picking working
>         out? (Some devs seem to like using title labels like `[3.6]`
>         to flag cherry-picks so it's more obvious in emails so I don't
>         know if the labels are really that useful)
>   * Is the mention bot helpful? (Our config is at
>     https://github.com/python/cpython/blob/master/.mention-bot and the
>     docs are at https://github.com/facebook/mention-bot)
>   * Anything to tweak about the coverage bot and reports? (Our config
>     is at
>     https://github.com/python/cpython/blob/master/.codecov.yml and
>     docs at https://docs.codecov.io/docs/codecov-yaml)
>
> Third, I wanted to point out some of the more critical discussions 
> going on at https://github.com/python/core-workflow/issues. 
> Specifically, https://github.com/python/core-workflow/issues/6 is 
> working towards a solution for Misc/NEWS so if you care about the 
> final solution you should participate there. After Misc/NEWS is solved 
> the next step becomes solving the cherry-picking overhead with a more 
> automated approach. We are also discussing closed branches to make the 
> list of branches more manageable at 
> https://github.com/python/core-workflow/issues/31.
>
> Fourth, the lack of messages showing up on bugs.python.org 
> <http://bugs.python.org> after a commit is being tracked at 
> http://psf.upfronthosting.co.za/roundup/meta/issue613. I'm sure Ezio 
> and Maciej would appreciate any help people may be able to volunteer 
> to help in solving the problem.
>
> Fifth, anything I missed? :)
>
>
> _______________________________________________
> 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 donald at stufft.io  Mon Mar 13 13:02:26 2017
From: donald at stufft.io (Donald Stufft)
Date: Mon, 13 Mar 2017 13:02:26 -0400
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <20170313115409.2acf3634@subdivisions.wooz.org>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <CADiSq7fMG-J19tnRBgwZHXSGnKXtp99JZ=nk5V_KS4YfB460Tg@mail.gmail.com>
 <CAP1=2W6j9HqeAFxw=UJmb=GRCP9X-UQgz6uheWufbrNkv_SKVg@mail.gmail.com>
 <20170313115409.2acf3634@subdivisions.wooz.org>
Message-ID: <D73C5B30-8D47-45BB-ABF6-E0C145BC379D@stufft.io>


> On Mar 13, 2017, at 11:54 AM, Barry Warsaw <barry at python.org> wrote:
> 
> I actually kind of like the idea of a mentionbot, but the current
> implementation has some problems.  Rather than calculating who should be
> mentioned based on TIL (touched it last), it would be nicer if this got closer
> to solving Raymond's comment.  If the domain expert could be notified when PRs
> touch stuff they care about, that might be better.  The mentionbot could then
> be opt-in for folks who want to see more detail.


So mention-bot supports that, it just needs configured. I suspect though that it?s touched-it-last mentioning will get better once we get more people with commits under their actual name.

?
Donald Stufft



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

From rdmurray at bitdance.com  Mon Mar 13 15:35:59 2017
From: rdmurray at bitdance.com (R. David Murray)
Date: Mon, 13 Mar 2017 15:35:59 -0400
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <73fa950c-3f51-772a-35d0-045179d3f94e@gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <73fa950c-3f51-772a-35d0-045179d3f94e@gmail.com>
Message-ID: <20170313193559.E4D371B10013@webabinitio.net>

On Mon, 13 Mar 2017 12:48:30 -0400, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
> Yesterday I was working on a few asyncio PRs and a bug in async/await.  
> All PRs required cherry-picking.  Again, I was spending significant 
> amount of time just creating branches/PRs for cherry-picking.  Again 
> waiting for CI checks (even thougn I always run the test suite before I 
> push).  In the end of the day, I was so frustrated and discouraged that 
> I just stopped working on CPython.

Branch management was always the most time consuming part of committing,
even under HG.  But github has clearly made it worse.  Personally I doubt
I'm going to do any backports if I'm required to go visit some web pages
to do it.  That doesn't matter much, since I don't have much time for
contribution and have done very few checkins in a good while (even before
the switch).  But Brett was hoping that github would make it *easier* to
get stuff merged, and from my perspective that is only true for doc fixes
(which, granted, is a help :), while making it harder for code fixes.

So, I think the backport-bot should probably be the top priority of
whoever has time to work on this (which, unfortunately, is not me :(

Being able to backport without going through the PR process would also
make sense to me (and I thought we were going to be able to do that),
but I'm not involved enough in the conversations to know the downsides
of that.

--David

From donald at stufft.io  Tue Mar 14 10:58:47 2017
From: donald at stufft.io (Donald Stufft)
Date: Tue, 14 Mar 2017 10:58:47 -0400
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <CAP1=2W6j9HqeAFxw=UJmb=GRCP9X-UQgz6uheWufbrNkv_SKVg@mail.gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <CADiSq7fMG-J19tnRBgwZHXSGnKXtp99JZ=nk5V_KS4YfB460Tg@mail.gmail.com>
 <CAP1=2W6j9HqeAFxw=UJmb=GRCP9X-UQgz6uheWufbrNkv_SKVg@mail.gmail.com>
Message-ID: <8630900E-0A4C-43EE-AF8C-0C3349FD11A4@stufft.io>


> On Mar 12, 2017, at 9:12 PM, Brett Cannon <brett at python.org> wrote:
> 
> Already have. We got 25 jobs shared between python, pypa, and pyca thanks to Donald. At this point the best option we have to speed things up is to consider dropping tests (e.g. do we want to keep the C++ header test, or do we really need to test both clang and gcc?).



Just to let everyone know, this hadn?t been activated yet, but as of this morning it is. So we should now be getting 25 concurrent jobs shared between the three projects. I think this will work out well because it gives us 25 job burst and it?s unlikely that all orgs are having high activity at the same time (except maybe at something like PyCon, but that is going to be an issue either way ;) ).


?
Donald Stufft



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

From brett at python.org  Tue Mar 14 17:07:24 2017
From: brett at python.org (Brett Cannon)
Date: Tue, 14 Mar 2017 21:07:24 +0000
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <D73C5B30-8D47-45BB-ABF6-E0C145BC379D@stufft.io>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <CADiSq7fMG-J19tnRBgwZHXSGnKXtp99JZ=nk5V_KS4YfB460Tg@mail.gmail.com>
 <CAP1=2W6j9HqeAFxw=UJmb=GRCP9X-UQgz6uheWufbrNkv_SKVg@mail.gmail.com>
 <20170313115409.2acf3634@subdivisions.wooz.org>
 <D73C5B30-8D47-45BB-ABF6-E0C145BC379D@stufft.io>
Message-ID: <CAP1=2W46ibQ9=Bsd5FU22jOLoq=He9tc9QtovO=UV1rrNxGh7w@mail.gmail.com>

On Mon, 13 Mar 2017 at 10:04 Donald Stufft <donald at stufft.io> wrote:

>
> On Mar 13, 2017, at 11:54 AM, Barry Warsaw <barry at python.org> wrote:
>
> I actually kind of like the idea of a mentionbot, but the current
> implementation has some problems.  Rather than calculating who should be
> mentioned based on TIL (touched it last), it would be nicer if this got
> closer
> to solving Raymond's comment.  If the domain expert could be notified when
> PRs
> touch stuff they care about, that might be better.  The mentionbot could
> then
> be opt-in for folks who want to see more detail.
>
>
>
> So mention-bot supports that, it just needs configured
>

Specifically, if you look at https://github.com/facebook/mention-bot and
note the alwaysNotifyForPaths option. The problem is what happens to the
experts file? If we end up managing both that file and the mentionbot
confis separately then it leads to a bifurcation of where we track that
info. At that point we have to either consider something to use to easily
update one based on the other (e.g. pull in the experts file and use it to
update the mentionbot config), or we come up with our own solution to the
problem.


> . I suspect though that it?s touched-it-last mentioning will get better
> once we get more people with commits under their actual name.
>

As I think Antoine pointed out, if people are doing fixes that don't
require domain knowledge then that can skew the results (whether that will
skew that much I don't know).

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170314/7b42e506/attachment.html>

From alex.gaynor at gmail.com  Tue Mar 14 17:09:17 2017
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Tue, 14 Mar 2017 17:09:17 -0400
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <CAP1=2W46ibQ9=Bsd5FU22jOLoq=He9tc9QtovO=UV1rrNxGh7w@mail.gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <CADiSq7fMG-J19tnRBgwZHXSGnKXtp99JZ=nk5V_KS4YfB460Tg@mail.gmail.com>
 <CAP1=2W6j9HqeAFxw=UJmb=GRCP9X-UQgz6uheWufbrNkv_SKVg@mail.gmail.com>
 <20170313115409.2acf3634@subdivisions.wooz.org>
 <D73C5B30-8D47-45BB-ABF6-E0C145BC379D@stufft.io>
 <CAP1=2W46ibQ9=Bsd5FU22jOLoq=He9tc9QtovO=UV1rrNxGh7w@mail.gmail.com>
Message-ID: <CAFRnB2UXRFxxqUp1dXyAXEukRa7ZQKWhark=ORU39B05JT_1EQ@mail.gmail.com>

If most patches (by LOC) don't require domain knowledge to commit, I guess
they probably don't need domain knowledge to review.

Alex

On Tue, Mar 14, 2017 at 5:07 PM, Brett Cannon <brett at python.org> wrote:

>
>
> On Mon, 13 Mar 2017 at 10:04 Donald Stufft <donald at stufft.io> wrote:
>
>>
>> On Mar 13, 2017, at 11:54 AM, Barry Warsaw <barry at python.org> wrote:
>>
>> I actually kind of like the idea of a mentionbot, but the current
>> implementation has some problems.  Rather than calculating who should be
>> mentioned based on TIL (touched it last), it would be nicer if this got
>> closer
>> to solving Raymond's comment.  If the domain expert could be notified
>> when PRs
>> touch stuff they care about, that might be better.  The mentionbot could
>> then
>> be opt-in for folks who want to see more detail.
>>
>>
>>
>> So mention-bot supports that, it just needs configured
>>
>
> Specifically, if you look at https://github.com/facebook/mention-bot and
> note the alwaysNotifyForPaths option. The problem is what happens to the
> experts file? If we end up managing both that file and the mentionbot
> confis separately then it leads to a bifurcation of where we track that
> info. At that point we have to either consider something to use to easily
> update one based on the other (e.g. pull in the experts file and use it to
> update the mentionbot config), or we come up with our own solution to the
> problem.
>
>
>> . I suspect though that it?s touched-it-last mentioning will get better
>> once we get more people with commits under their actual name.
>>
>
> As I think Antoine pointed out, if people are doing fixes that don't
> require domain knowledge then that can skew the results (whether that will
> skew that much I don't know).
>
> -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/
>



-- 
"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/20170314/d0fdc247/attachment-0001.html>

From brett at python.org  Tue Mar 14 17:09:50 2017
From: brett at python.org (Brett Cannon)
Date: Tue, 14 Mar 2017 21:09:50 +0000
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <20170313193559.E4D371B10013@webabinitio.net>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <73fa950c-3f51-772a-35d0-045179d3f94e@gmail.com>
 <20170313193559.E4D371B10013@webabinitio.net>
Message-ID: <CAP1=2W6E1rdu6B-5y0v6O7n09DEdV_qsJU89VH=mchY6pWpTJw@mail.gmail.com>

On Mon, 13 Mar 2017 at 12:36 R. David Murray <rdmurray at bitdance.com> wrote:

> On Mon, 13 Mar 2017 12:48:30 -0400, Yury Selivanov <
> yselivanov.ml at gmail.com> wrote:
> > Yesterday I was working on a few asyncio PRs and a bug in async/await.
> > All PRs required cherry-picking.  Again, I was spending significant
> > amount of time just creating branches/PRs for cherry-picking.  Again
> > waiting for CI checks (even thougn I always run the test suite before I
> > push).  In the end of the day, I was so frustrated and discouraged that
> > I just stopped working on CPython.
>
> Branch management was always the most time consuming part of committing,
> even under HG.  But github has clearly made it worse.  Personally I doubt
> I'm going to do any backports if I'm required to go visit some web pages
> to do it.  That doesn't matter much, since I don't have much time for
> contribution and have done very few checkins in a good while (even before
> the switch).  But Brett was hoping that github would make it *easier* to
> get stuff merged, and from my perspective that is only true for doc fixes
> (which, granted, is a help :), while making it harder for code fixes.
>
> So, I think the backport-bot should probably be the top priority of
> whoever has time to work on this (which, unfortunately, is not me :(
>

It's #2 after the Misc/NEWS solution.

-Brett


>
> Being able to backport without going through the PR process would also
> make sense to me (and I thought we were going to be able to do that),
> but I'm not involved enough in the conversations to know the downsides
> of that.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170314/5b264e38/attachment.html>

From brett at python.org  Tue Mar 14 18:00:31 2017
From: brett at python.org (Brett Cannon)
Date: Tue, 14 Mar 2017 22:00:31 +0000
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <73fa950c-3f51-772a-35d0-045179d3f94e@gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <73fa950c-3f51-772a-35d0-045179d3f94e@gmail.com>
Message-ID: <CAP1=2W75PCeWbFLBSN8m6PWK1evP25onVjMBwNJmFhsqMMfBhg@mail.gmail.com>

On Mon, 13 Mar 2017 at 09:48 Yury Selivanov <yselivanov.ml at gmail.com> wrote:

> Hi,
>
> First, I'm really happy that we moved to git and GH.  The GH review tool
> is super convenient and CI integration helps.
>
> I'm less happy about requiring to make a PR for every commit. It's a no
> problem for new features development, but it's a huge pain for a bug
> fixing workflow.  Last week I needed to push a bunch of bug fixes to
> 3.7/3.6/3.5.  I had about 6 pull requests to the master branch, + 12
> more for 3.6 and 3.5.  I basically killed my entire second half of the
> day waiting until CI checks clear out.  I spend a few hours pushing just
> 3 (!!) committs to all branches.  Thanks to Brett, who disabled the push
> CI check for a while, I was able to push the remaining 3 bug fixes and
> their cherry picks in under 10 minutes.
>
> Yesterday I was working on a few asyncio PRs and a bug in async/await.
> All PRs required cherry-picking.  Again, I was spending significant
> amount of time just creating branches/PRs for cherry-picking.


Were you creating the branches manually or using Mariatta's script?


>   Again
> waiting for CI checks (even though I always run the test suite before I
> push).  In the end of the day, I was so frustrated and discouraged that
> I just stopped working on CPython.
>

Our Travis runs just got increased today so this should be improved. As I
have also previously said we can consider scaling back the number of things
we're building if necessary (i.e. we could go as low as 3 instead of the 5
we currently have or trying building using g++ to combine gcc and the C++
header check).


>
> The current workflow makes it significantly harder for me to be
> productive.  At this point I'm so discouraged of working on any bug
> fixes that I consider to stop working on them until the full
> cherry-picking automation is implemented.
>
> So I guess what I'm asking for is to consider turning the CI/PR push
> requirement off until we have automatic cherry-picking and a new NEWS
> file workflow.  We lived without this check for many years with
> mercurial.  Yes, all of us pushed some broken commits, but we have
> buildbots and CI, so nothing horrible ever happended.
>

It's a double-edged sword when you don't gate on CI but you have it for all
PRs. When Serhiy accidentally broke the build when I turned off Travis
gating for you, all PRs for a few hours came in as failing and it confused
some external contributors as to why their PR was coming up red. I had to
tell people that it was already broken before their PR was submitted and
once the fix was in that they needed to rebase to make sure their tests
pass. And the only way to make this not be an issue without gating on CI is
to require all PRs to be fully rebased before merging which is a constant
merge race (which we all know from our forward merging days to be a massive
pain and would then also require all PRs be merged through the command-line
and never online in order to do the rebase for contributors who would
always be behind).

IOW having CI is somewhat of an all-or-nothing thing here, else you are
dealing with the fallout of a broken build for a while (compared to the
Mercurial days where we all did the rebasing manually along with testing in
order to avoid this issue). Now as Donald pointed out, our concurrency
levels went up this morning so hopefully that will help with this.

It also doesn't help when randomness schedules test_tools, test_datetime,
or test_tokenize towards the end of a test run since they all take a few
minutes under clang (don't know why specifically clang, but there you go).

My point is that there are still some things we can do to make the
turn-around time on CI to be faster: see if the slower tests could be sped
up, deciding if we need all builds that we currently have, seeing if our
new concurrency levels help, or even consider gating on AppVeyor instead of
Travis. If all of those things are tried and we are still seeing
unacceptably long wait times on PRs, then we can talk about turning off the
CI gating. Does that seem fair?

-Brett


>
> Thank you,
> Yury
>
>
> On 2017-03-10 5:13 PM, Brett Cannon wrote:
> > I can't believe it's been 4 weeks. It feels like it was ages/yesterday
> > when we moved. :)
> >
> > First, I hope people are not regretting letting/having me make this
> > migration. I know there have been some things to work through (and
> > others still to come), but I hope this is all a net positive (either
> > now or in the near future).
> >
> > Second, I wanted to get initial feedback on things we can easily tweak:
> >
> >   * Requiring Travis to pass (I *really* don't want to turn this off
> >     as we already had a broken build when I temporarily turned it off
> >     at someone's request when Travis was backed up from the AWS S3
> >     outage; I also don't plan to make AppVeyor required unless there's
> >     a way to make it be skipped for doc-only changes)
> >   * Cherry-picking working out? (We can go back to forward merging if
> >     people really want to, but I think long-term cherry-picking will
> >     allow for more automation)
> >       o Along with that, are the labels for cherry-picking working
> >         out? (Some devs seem to like using title labels like `[3.6]`
> >         to flag cherry-picks so it's more obvious in emails so I don't
> >         know if the labels are really that useful)
> >   * Is the mention bot helpful? (Our config is at
> >     https://github.com/python/cpython/blob/master/.mention-bot and the
> >     docs are at https://github.com/facebook/mention-bot)
> >   * Anything to tweak about the coverage bot and reports? (Our config
> >     is at
> >     https://github.com/python/cpython/blob/master/.codecov.yml and
> >     docs at https://docs.codecov.io/docs/codecov-yaml)
> >
> > Third, I wanted to point out some of the more critical discussions
> > going on at https://github.com/python/core-workflow/issues.
> > Specifically, https://github.com/python/core-workflow/issues/6 is
> > working towards a solution for Misc/NEWS so if you care about the
> > final solution you should participate there. After Misc/NEWS is solved
> > the next step becomes solving the cherry-picking overhead with a more
> > automated approach. We are also discussing closed branches to make the
> > list of branches more manageable at
> > https://github.com/python/core-workflow/issues/31.
> >
> > Fourth, the lack of messages showing up on bugs.python.org
> > <http://bugs.python.org> after a commit is being tracked at
> > http://psf.upfronthosting.co.za/roundup/meta/issue613. I'm sure Ezio
> > and Maciej would appreciate any help people may be able to volunteer
> > to help in solving the problem.
> >
> > Fifth, anything I missed? :)
> >
> >
> > _______________________________________________
> > 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/20170314/7f19c627/attachment-0001.html>

From brett at python.org  Tue Mar 14 18:05:17 2017
From: brett at python.org (Brett Cannon)
Date: Tue, 14 Mar 2017 22:05:17 +0000
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <0371996D-5873-4D86-9484-8A9DDF4F1F30@gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <0371996D-5873-4D86-9484-8A9DDF4F1F30@gmail.com>
Message-ID: <CAP1=2W7JFg09S_y6q3-zHgM0oKK1fLj3hckbz4RXkyPxtNUi-w@mail.gmail.com>

On Sun, 12 Mar 2017 at 19:11 Raymond Hettinger <raymond.hettinger at gmail.com>
wrote:

>
> > On Mar 10, 2017, at 2:13 PM, Brett Cannon <brett at python.org> wrote:
> >
> > I wanted to get initial feedback on things we can easily tweak:
>
> Overall, the new workflow is mostly positive.  The tooling looks great and
> it seems to have increased the number of participants.
>
> There is a disconnect between discussions on the tracker and discussions
> on the bug tracker. It would be nice if discussions could be better
> synchronized.
>

There has been discussion of about coming up with some bot that would post
a message on service A when there's been comments on service B, although I
don't know how much that would help (nor which way the comments would go,
e.g. comment on GH that there's stuff on bugs.python.org or the other way
around?). Basically we all just need to be better about keeping only code
review discussions on GH and all other discussions on bugs.python.org. The
other way is to always have a welcome message stating this fact (whether
that's on every PR or only in the CLA message I don't know), but I don't
know if that would help either.

-Brett


>
> There does seem to be some confusion on when it is okay to commit.  At
> least one core dev is of the opinion that if tests are passing it is okay
> for him to approve and commit regardless of area of expertise, status of
> the tracker item, or approval of the module maintainer.  IMO, having the
> tests pass is a pretty low bar and seems to bypass consideration of whether
> the change is the right thing to do.
>
> For me personally, I've not yet had time to read through all the new
> processes, the new devguide,and  to get my git/github skills up-to-date, so
> I've been completely left behind (not a single patch or build since the
> migration).  I'm hoping that I can get caught up over some upcoming
> weekend, but the migration did create a whole new set of challenges that
> I've never had in the last 16 years of core development.  For the time
> being, I'm mostly helpless and can only comment here are there on various
> issues.
>
> For people who have more time on their hands or who were already familiar
> which all the tooling, the migration seems to have been much easier.
>
>
> Raymond
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170314/3ff0b530/attachment.html>

From nad at python.org  Tue Mar 14 18:16:21 2017
From: nad at python.org (Ned Deily)
Date: Tue, 14 Mar 2017 18:16:21 -0400
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <CAP1=2W7JFg09S_y6q3-zHgM0oKK1fLj3hckbz4RXkyPxtNUi-w@mail.gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <0371996D-5873-4D86-9484-8A9DDF4F1F30@gmail.com>
 <CAP1=2W7JFg09S_y6q3-zHgM0oKK1fLj3hckbz4RXkyPxtNUi-w@mail.gmail.com>
Message-ID: <523E945D-EBEA-4934-BB37-A57CF44A1086@python.org>

On Mar 14, 2017, at 18:05, Brett Cannon <brett at python.org> wrote:
> There has been discussion of about coming up with some bot that would post a message on service A when there's been comments on service B, although I don't know how much that would help (nor which way the comments would go, e.g. comment on GH that there's stuff on bugs.python.org or the other way around?). Basically we all just need to be better about keeping only code review discussions on GH and all other discussions on bugs.python.org. The other way is to always have a welcome message stating this fact (whether that's on every PR or only in the CLA message I don't know), but I don't know if that would help either.

There is one pattern that is happening fairly often and that I think we should do something about.  That is, non-committers submitting a PR without first opening an issue on BPO.  It gets very old fast trying to enforce that.  Perhaps one of the bots could flag PRs that do not have a BPO ref in their titles?

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


From donald at stufft.io  Tue Mar 14 18:24:22 2017
From: donald at stufft.io (Donald Stufft)
Date: Tue, 14 Mar 2017 18:24:22 -0400
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
Message-ID: <066EF4E9-29B2-4759-AFAE-6E8FC2D8B406@stufft.io>


> On Mar 10, 2017, at 5:13 PM, Brett Cannon <brett at python.org> wrote:
> 
> Is the mention bot helpful? (Our config is at https://github.com/python/cpython/blob/master/.mention-bot <https://github.com/python/cpython/blob/master/.mention-bot> and the docs are at https://github.com/facebook/mention-bot <https://github.com/facebook/mention-bot>)


Just as an FYI, I?ve turned the mention-bot down from mentioning a max of 5 to a max of 3 reviewers. I?m not sure if this is going to help or not, but at the very least it will reduce the number of people getting notified (and thus hopefully, the total number of notifications). If the touched-it-last algorithm is still not useful then that might be all the more it helps, but it might also be a problem trying to get too many useful reviewers out of touched-it-last.

?
Donald Stufft



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

From barry at python.org  Tue Mar 14 19:25:47 2017
From: barry at python.org (Barry Warsaw)
Date: Tue, 14 Mar 2017 19:25:47 -0400
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <523E945D-EBEA-4934-BB37-A57CF44A1086@python.org>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <0371996D-5873-4D86-9484-8A9DDF4F1F30@gmail.com>
 <CAP1=2W7JFg09S_y6q3-zHgM0oKK1fLj3hckbz4RXkyPxtNUi-w@mail.gmail.com>
 <523E945D-EBEA-4934-BB37-A57CF44A1086@python.org>
Message-ID: <20170314192547.5c831021@subdivisions.wooz.org>

On Mar 14, 2017, at 06:16 PM, Ned Deily wrote:

>There is one pattern that is happening fairly often and that I think we
>should do something about.  That is, non-committers submitting a PR without
>first opening an issue on BPO.  It gets very old fast trying to enforce that.
>Perhaps one of the bots could flag PRs that do not have a BPO ref in their
>titles?

Should there be a way to override that?  In another project of mine on GH, we
use a 'trivial' tag on the PR to bypass that check.

Cheers,
-Barry

From nad at python.org  Tue Mar 14 20:29:59 2017
From: nad at python.org (Ned Deily)
Date: Tue, 14 Mar 2017 20:29:59 -0400
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <20170314192547.5c831021@subdivisions.wooz.org>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <0371996D-5873-4D86-9484-8A9DDF4F1F30@gmail.com>
 <CAP1=2W7JFg09S_y6q3-zHgM0oKK1fLj3hckbz4RXkyPxtNUi-w@mail.gmail.com>
 <523E945D-EBEA-4934-BB37-A57CF44A1086@python.org>
 <20170314192547.5c831021@subdivisions.wooz.org>
Message-ID: <7D0319C8-8DF6-42D9-892F-8387FEBCB02F@python.org>

On Mar 14, 2017, at 19:25, Barry Warsaw <barry at python.org> wrote:
> On Mar 14, 2017, at 06:16 PM, Ned Deily wrote:
>> There is one pattern that is happening fairly often and that I think we
>> should do something about.  That is, non-committers submitting a PR without
>> first opening an issue on BPO.  It gets very old fast trying to enforce that.
>> Perhaps one of the bots could flag PRs that do not have a BPO ref in their
>> titles?
> Should there be a way to override that?  In another project of mine on GH, we
> use a 'trivial' tag on the PR to bypass that check.

Sure, something like that would be fine.

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


From berker.peksag at gmail.com  Wed Mar 15 11:37:21 2017
From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=)
Date: Wed, 15 Mar 2017 18:37:21 +0300
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <CAP1=2W62-=scBJB4PqGYUyg8gEQ-Ew3HKkOSbOdpU6cNcYen5g@mail.gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <c1a33ea8-c3f0-27fc-8ad7-a2e26730147d@egenix.com>
 <CAP1=2W62-=scBJB4PqGYUyg8gEQ-Ew3HKkOSbOdpU6cNcYen5g@mail.gmail.com>
Message-ID: <CAF4280KZgkOT7rCWjU-sZLkNnGyomWi6qKPPxdtq3s78gHiWMg@mail.gmail.com>

On Mon, Mar 13, 2017 at 12:11 AM, Brett Cannon <brett at python.org> wrote:
>
>
> On Sun, 12 Mar 2017 at 06:33 M.-A. Lemburg <mal at egenix.com> wrote:
>>
>> On 10.03.2017 23:13, Brett Cannon wrote:
>> > Fifth, anything I missed? :)
>>
>> My main nit after the move is that messages to the checkin list
>> no longer include the full patch. This makes reviews harder than
>> necessary (you always have to go through the browser).
>>
>> Is there some way this could be changed back to what we had
>> previously or is this a hard limitation of github ?
>
>
> It's a hard limitation of the GitHub-provided email solution. With GitHub's
> APIs and enough time someone could either come up with a custom email
> solution or a web page that showed this information (you literally just need
> to add ".diff" to the end of a URL to get the diff itself for a PR, e.g.
> https://github.com/python/cpython/pull/648.diff will redirect to a raw
> diff). There might also already be other solutions out there that do what
> you're after.
>
> Obviously this all requires work on someone's part. :) (I've also moved
> completely off of an email-based workflow so I'm definitely not the right
> person to drive this sort of thing.)

I wrote https://github.com/berkerpeksag/cpython-emailer-webhook to
solve this problem. It works and its output is almost same as the old
one [1] I even wrote some tests and documentation, but I just noticed
that I forgot to push to GitHub :)

If we all agree on the idea I can help with deploying it. I can use my
own VPS for the initial deploy, but it would be nice to have a PSF
backed server in the long term.

--Berker

[1] https://github.com/python/core-workflow/issues/24#issuecomment-279162079

From mariatta.wijaya at gmail.com  Wed Mar 15 19:02:59 2017
From: mariatta.wijaya at gmail.com (Mariatta Wijaya)
Date: Wed, 15 Mar 2017 16:02:59 -0700
Subject: [python-committers] cherry_picker.py is now in core-workflow repo
Message-ID: <CAGbohnYKYe+BNCDEtitNLNgzfJTWo9rnhBGvSv_eFvBYBdL+FA@mail.gmail.com>

Hi,

I imported my cherry picker script into https://github.com/
python/core-workflow/tree/master/cherry_picker/

Please try it out if you need to do backports for CPython. It still needs
some improvement with handling merge conflict, but if you don't anticipate
any conflict then it should make things easy for you. (things that do not
involve Misc/NEWS, for example)

After the migration, I used it to cherry-pick this PR:
https://github.com/python/cpython/pull/670 can confirm it works.

Thanks Nick Coghlan who has started using and contributing to it too :)
I believe he has a PR coming soon that adds a --dry-run option, which I
look forward to :)

Mariatta Wijaya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170315/aaf7ee8b/attachment.html>

From brett at python.org  Wed Mar 15 19:49:36 2017
From: brett at python.org (Brett Cannon)
Date: Wed, 15 Mar 2017 23:49:36 +0000
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <CAF4280KZgkOT7rCWjU-sZLkNnGyomWi6qKPPxdtq3s78gHiWMg@mail.gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <c1a33ea8-c3f0-27fc-8ad7-a2e26730147d@egenix.com>
 <CAP1=2W62-=scBJB4PqGYUyg8gEQ-Ew3HKkOSbOdpU6cNcYen5g@mail.gmail.com>
 <CAF4280KZgkOT7rCWjU-sZLkNnGyomWi6qKPPxdtq3s78gHiWMg@mail.gmail.com>
Message-ID: <CAP1=2W5MWTO3=wYY2KPZeGdUoZtmeYzwUoRdwKn50QhXPDrPMw@mail.gmail.com>

On Wed, 15 Mar 2017 at 08:44 Berker Peksa? <berker.peksag at gmail.com> wrote:

> On Mon, Mar 13, 2017 at 12:11 AM, Brett Cannon <brett at python.org> wrote:
> >
> >
> > On Sun, 12 Mar 2017 at 06:33 M.-A. Lemburg <mal at egenix.com> wrote:
> >>
> >> On 10.03.2017 23:13, Brett Cannon wrote:
> >> > Fifth, anything I missed? :)
> >>
> >> My main nit after the move is that messages to the checkin list
> >> no longer include the full patch. This makes reviews harder than
> >> necessary (you always have to go through the browser).
> >>
> >> Is there some way this could be changed back to what we had
> >> previously or is this a hard limitation of github ?
> >
> >
> > It's a hard limitation of the GitHub-provided email solution. With
> GitHub's
> > APIs and enough time someone could either come up with a custom email
> > solution or a web page that showed this information (you literally just
> need
> > to add ".diff" to the end of a URL to get the diff itself for a PR, e.g.
> > https://github.com/python/cpython/pull/648.diff will redirect to a raw
> > diff). There might also already be other solutions out there that do what
> > you're after.
> >
> > Obviously this all requires work on someone's part. :) (I've also moved
> > completely off of an email-based workflow so I'm definitely not the right
> > person to drive this sort of thing.)
>
> I wrote https://github.com/berkerpeksag/cpython-emailer-webhook to
> solve this problem. It works and its output is almost same as the old
> one [1] I even wrote some tests and documentation, but I just noticed
> that I forgot to push to GitHub :)
>
> If we all agree on the idea I can help with deploying it. I can use my
> own VPS for the initial deploy, but it would be nice to have a PSF
> backed server in the long term.
>

I believe we have free Heroku resources to putting it there should be easy
(the infrastructure team would know best obviously where we have free
resources).

-Brett


>
> --Berker
>
> [1]
> https://github.com/python/core-workflow/issues/24#issuecomment-279162079
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170315/07d5bac9/attachment.html>

From brett at python.org  Wed Mar 15 20:00:11 2017
From: brett at python.org (Brett Cannon)
Date: Thu, 16 Mar 2017 00:00:11 +0000
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <20170314192547.5c831021@subdivisions.wooz.org>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <0371996D-5873-4D86-9484-8A9DDF4F1F30@gmail.com>
 <CAP1=2W7JFg09S_y6q3-zHgM0oKK1fLj3hckbz4RXkyPxtNUi-w@mail.gmail.com>
 <523E945D-EBEA-4934-BB37-A57CF44A1086@python.org>
 <20170314192547.5c831021@subdivisions.wooz.org>
Message-ID: <CAP1=2W6r59YNP2NaFSu5f3jEF-WcfbcbSHoQT81k1DBg81b+jQ@mail.gmail.com>

On Tue, 14 Mar 2017 at 16:26 Barry Warsaw <barry at python.org> wrote:

> On Mar 14, 2017, at 06:16 PM, Ned Deily wrote:
>
> >There is one pattern that is happening fairly often and that I think we
> >should do something about.  That is, non-committers submitting a PR
> without
> >first opening an issue on BPO.  It gets very old fast trying to enforce
> that.
> >Perhaps one of the bots could flag PRs that do not have a BPO ref in their
> >titles?
>
> Should there be a way to override that?  In another project of mine on GH,
> we
> use a 'trivial' tag on the PR to bypass that check.
>

But that would require that external contributors know to set that label
ahead of time and I'm willing to bet most won't.

I see two ways of solving this. One is to have a bot that leaves a comment
when an issue isn't seen, otherwise it leaves a comment with a link back to
the original issue for easy access. The other is we add a PR template that
mentions that the title should include a reference to the issue for
anything but the most trivial PR (and to create an issue
otherwise).Obviously there's a great variance in effort required but also
with the usefulness of what the solution does.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170316/86005d20/attachment.html>

From barry at python.org  Wed Mar 15 20:03:23 2017
From: barry at python.org (Barry Warsaw)
Date: Wed, 15 Mar 2017 20:03:23 -0400
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <CAP1=2W6r59YNP2NaFSu5f3jEF-WcfbcbSHoQT81k1DBg81b+jQ@mail.gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <0371996D-5873-4D86-9484-8A9DDF4F1F30@gmail.com>
 <CAP1=2W7JFg09S_y6q3-zHgM0oKK1fLj3hckbz4RXkyPxtNUi-w@mail.gmail.com>
 <523E945D-EBEA-4934-BB37-A57CF44A1086@python.org>
 <20170314192547.5c831021@subdivisions.wooz.org>
 <CAP1=2W6r59YNP2NaFSu5f3jEF-WcfbcbSHoQT81k1DBg81b+jQ@mail.gmail.com>
Message-ID: <20170315200323.1b6ebd89@subdivisions.wooz.org>

On Mar 16, 2017, at 12:00 AM, Brett Cannon wrote:

>But that would require that external contributors know to set that label
>ahead of time and I'm willing to bet most won't.

Not if the test has a retry feature.  Your change is trivial but you didn't
add the label.  The test fails.  You add the label and retry the test.  Now it
passes.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170315/9688148a/attachment-0001.sig>

From yselivanov.ml at gmail.com  Wed Mar 15 22:56:33 2017
From: yselivanov.ml at gmail.com (Yury Selivanov)
Date: Wed, 15 Mar 2017 22:56:33 -0400
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <CAP1=2W75PCeWbFLBSN8m6PWK1evP25onVjMBwNJmFhsqMMfBhg@mail.gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <73fa950c-3f51-772a-35d0-045179d3f94e@gmail.com>
 <CAP1=2W75PCeWbFLBSN8m6PWK1evP25onVjMBwNJmFhsqMMfBhg@mail.gmail.com>
Message-ID: <64d1f84b-4b26-2e61-32b9-245495a9eefa@gmail.com>

Hi Brett,

On 2017-03-14 6:00 PM, Brett Cannon wrote:
[..]
>
>
>     Yesterday I was working on a few asyncio PRs and a bug in async/await.
>     All PRs required cherry-picking.  Again, I was spending significant
>     amount of time just creating branches/PRs for cherry-picking.
>
>
> Were you creating the branches manually or using Mariatta's script?

I'll check it out!

>       Again
>     waiting for CI checks (even though I always run the test suite
>     before I
>     push).  In the end of the day, I was so frustrated and discouraged
>     that
>     I just stopped working on CPython.
>
>
> Our Travis runs just got increased today so this should be improved. 
> As I have also previously said we can consider scaling back the number 
> of things we're building if necessary (i.e. we could go as low as 3 
> instead of the 5 we currently have or trying building using g++ to 
> combine gcc and the C++ header check).

Yeah, reducing the number of tasks would really help.  Anything that can 
make required CI checks quicker.

> It's a double-edged sword when you don't gate on CI but you have it 
> for all PRs. When Serhiy accidentally broke the build when I turned 
> off Travis gating for you, all PRs for a few hours came in as failing 
> and it confused some external contributors as to why their PR was 
> coming up red.

Ah, OK, I now better understand the rationale for requiring CI pass.

[..]
>  If all of those things are tried and we are still seeing unacceptably 
> long wait times on PRs, then we can talk about turning off the CI 
> gating. Does that seem fair?

It's not just long waiting times (although it's a huge factor), it's 
that you have to create temporary branches for cherry-picks. With 
scripts or without, it's a lot of bookkeeping. Also, interacting with a 
console is still much more convenient than using web tools (at least for 
me).

Anyways, while I don't totally enjoy the current workflow I see why it 
is as it is right now. I'll try to get used to it.

Thank you,
Yury

P.S. Thanks to everybody who's been working on GH migration. Overall 
it's a very positive change!


From rdmurray at bitdance.com  Wed Mar 15 23:24:22 2017
From: rdmurray at bitdance.com (R. David Murray)
Date: Wed, 15 Mar 2017 23:24:22 -0400
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <64d1f84b-4b26-2e61-32b9-245495a9eefa@gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <73fa950c-3f51-772a-35d0-045179d3f94e@gmail.com>
 <CAP1=2W75PCeWbFLBSN8m6PWK1evP25onVjMBwNJmFhsqMMfBhg@mail.gmail.com>
 <64d1f84b-4b26-2e61-32b9-245495a9eefa@gmail.com>
Message-ID: <20170316032422.540501B10017@webabinitio.net>

On Wed, 15 Mar 2017 22:56:33 -0400, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
> It's not just long waiting times (although it's a huge factor), it's 
> that you have to create temporary branches for cherry-picks. With 
> scripts or without, it's a lot of bookkeeping. Also, interacting with a 
> console is still much more convenient than using web tools (at least for 
> me).

+100 :)

--David

From mal at egenix.com  Thu Mar 16 05:27:13 2017
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 16 Mar 2017 10:27:13 +0100
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <CAP1=2W5MWTO3=wYY2KPZeGdUoZtmeYzwUoRdwKn50QhXPDrPMw@mail.gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <c1a33ea8-c3f0-27fc-8ad7-a2e26730147d@egenix.com>
 <CAP1=2W62-=scBJB4PqGYUyg8gEQ-Ew3HKkOSbOdpU6cNcYen5g@mail.gmail.com>
 <CAF4280KZgkOT7rCWjU-sZLkNnGyomWi6qKPPxdtq3s78gHiWMg@mail.gmail.com>
 <CAP1=2W5MWTO3=wYY2KPZeGdUoZtmeYzwUoRdwKn50QhXPDrPMw@mail.gmail.com>
Message-ID: <3ec2cab4-a2cf-4f86-1b6b-1a939471a143@egenix.com>

On 16.03.2017 00:49, Brett Cannon wrote:
> On Wed, 15 Mar 2017 at 08:44 Berker Peksa? <berker.peksag at gmail.com> wrote:
> 
>> On Mon, Mar 13, 2017 at 12:11 AM, Brett Cannon <brett at python.org> wrote:
>>>
>>>
>>> On Sun, 12 Mar 2017 at 06:33 M.-A. Lemburg <mal at egenix.com> wrote:
>>>>
>>>> On 10.03.2017 23:13, Brett Cannon wrote:
>>>>> Fifth, anything I missed? :)
>>>>
>>>> My main nit after the move is that messages to the checkin list
>>>> no longer include the full patch. This makes reviews harder than
>>>> necessary (you always have to go through the browser).
>>>>
>>>> Is there some way this could be changed back to what we had
>>>> previously or is this a hard limitation of github ?
>>>
>>>
>>> It's a hard limitation of the GitHub-provided email solution. With
>> GitHub's
>>> APIs and enough time someone could either come up with a custom email
>>> solution or a web page that showed this information (you literally just
>> need
>>> to add ".diff" to the end of a URL to get the diff itself for a PR, e.g.
>>> https://github.com/python/cpython/pull/648.diff will redirect to a raw
>>> diff). There might also already be other solutions out there that do what
>>> you're after.
>>>
>>> Obviously this all requires work on someone's part. :) (I've also moved
>>> completely off of an email-based workflow so I'm definitely not the right
>>> person to drive this sort of thing.)
>>
>> I wrote https://github.com/berkerpeksag/cpython-emailer-webhook to
>> solve this problem. It works and its output is almost same as the old
>> one [1] I even wrote some tests and documentation, but I just noticed
>> that I forgot to push to GitHub :)
>>
>> If we all agree on the idea I can help with deploying it. I can use my
>> own VPS for the initial deploy, but it would be nice to have a PSF
>> backed server in the long term.

This would be fantastic :-) Thank you, Berker !

-- 
Marc-Andre Lemburg
eGenix.com

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

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

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


From brett at python.org  Thu Mar 16 12:14:54 2017
From: brett at python.org (Brett Cannon)
Date: Thu, 16 Mar 2017 16:14:54 +0000
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <20170315200323.1b6ebd89@subdivisions.wooz.org>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <0371996D-5873-4D86-9484-8A9DDF4F1F30@gmail.com>
 <CAP1=2W7JFg09S_y6q3-zHgM0oKK1fLj3hckbz4RXkyPxtNUi-w@mail.gmail.com>
 <523E945D-EBEA-4934-BB37-A57CF44A1086@python.org>
 <20170314192547.5c831021@subdivisions.wooz.org>
 <CAP1=2W6r59YNP2NaFSu5f3jEF-WcfbcbSHoQT81k1DBg81b+jQ@mail.gmail.com>
 <20170315200323.1b6ebd89@subdivisions.wooz.org>
Message-ID: <CAP1=2W62t8J0qUstz8VL_9hmwsYXe8mT5FFdK6DkLz_nyaBYEg@mail.gmail.com>

On Wed, 15 Mar 2017 at 17:03 Barry Warsaw <barry at python.org> wrote:

> On Mar 16, 2017, at 12:00 AM, Brett Cannon wrote:
>
> >But that would require that external contributors know to set that label
> >ahead of time and I'm willing to bet most won't.
>
> Not if the test has a retry feature.  Your change is trivial but you didn't
> add the label.  The test fails.  You add the label and retry the test.
> Now it
> passes.
>

Ah, you didn't say you wanted this to be a status check. :) Do we want to
go so far as that rather than a comment or PR template?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170316/c13a40a1/attachment.html>

From brett at python.org  Thu Mar 16 12:16:39 2017
From: brett at python.org (Brett Cannon)
Date: Thu, 16 Mar 2017 16:16:39 +0000
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <20170316032422.540501B10017@webabinitio.net>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <73fa950c-3f51-772a-35d0-045179d3f94e@gmail.com>
 <CAP1=2W75PCeWbFLBSN8m6PWK1evP25onVjMBwNJmFhsqMMfBhg@mail.gmail.com>
 <64d1f84b-4b26-2e61-32b9-245495a9eefa@gmail.com>
 <20170316032422.540501B10017@webabinitio.net>
Message-ID: <CAP1=2W4OZBu3+shjUasUg6CKkJVyySGhT+mJRuLHauao8PS3rw@mail.gmail.com>

On Wed, 15 Mar 2017 at 20:24 R. David Murray <rdmurray at bitdance.com> wrote:

> On Wed, 15 Mar 2017 22:56:33 -0400, Yury Selivanov <
> yselivanov.ml at gmail.com> wrote:
> > It's not just long waiting times (although it's a huge factor), it's
> > that you have to create temporary branches for cherry-picks. With
> > scripts or without, it's a lot of bookkeeping. Also, interacting with a
> > console is still much more convenient than using web tools (at least for
> > me).
>
> +100 :)
>

I'm afraid this one is going to come down to personal preference because I
actually pref the web UI. :) But we will keep working at this to see if we
can't find a happy medium somehow.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170316/f3f75d80/attachment.html>

From yselivanov.ml at gmail.com  Thu Mar 16 12:19:59 2017
From: yselivanov.ml at gmail.com (Yury Selivanov)
Date: Thu, 16 Mar 2017 12:19:59 -0400
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <CAP1=2W4OZBu3+shjUasUg6CKkJVyySGhT+mJRuLHauao8PS3rw@mail.gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <73fa950c-3f51-772a-35d0-045179d3f94e@gmail.com>
 <CAP1=2W75PCeWbFLBSN8m6PWK1evP25onVjMBwNJmFhsqMMfBhg@mail.gmail.com>
 <64d1f84b-4b26-2e61-32b9-245495a9eefa@gmail.com>
 <20170316032422.540501B10017@webabinitio.net>
 <CAP1=2W4OZBu3+shjUasUg6CKkJVyySGhT+mJRuLHauao8PS3rw@mail.gmail.com>
Message-ID: <b4c42aaa-72e7-ebec-99c7-a3f166af7dea@gmail.com>

On 2017-03-16 12:16 PM, Brett Cannon wrote:
>
>
> On Wed, 15 Mar 2017 at 20:24 R. David Murray <rdmurray at bitdance.com 
> <mailto:rdmurray at bitdance.com>> wrote:
>
>     On Wed, 15 Mar 2017 22:56:33 -0400, Yury Selivanov
>     <yselivanov.ml at gmail.com <mailto:yselivanov.ml at gmail.com>> wrote:
>     > It's not just long waiting times (although it's a huge factor), it's
>     > that you have to create temporary branches for cherry-picks. With
>     > scripts or without, it's a lot of bookkeeping. Also, interacting
>     with a
>     > console is still much more convenient than using web tools (at
>     least for
>     > me).
>
>     +100 :)
>
>
> I'm afraid this one is going to come down to personal preference 
> because I actually pref the web UI. :) But we will keep working at 
> this to see if we can't find a happy medium somehow.


I just discovered this handy tool: https://github.com/github/hub. Will 
try to use it and will share my experience.

Yury

From barry at python.org  Thu Mar 16 13:25:46 2017
From: barry at python.org (Barry Warsaw)
Date: Thu, 16 Mar 2017 13:25:46 -0400
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <CAP1=2W62t8J0qUstz8VL_9hmwsYXe8mT5FFdK6DkLz_nyaBYEg@mail.gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <0371996D-5873-4D86-9484-8A9DDF4F1F30@gmail.com>
 <CAP1=2W7JFg09S_y6q3-zHgM0oKK1fLj3hckbz4RXkyPxtNUi-w@mail.gmail.com>
 <523E945D-EBEA-4934-BB37-A57CF44A1086@python.org>
 <20170314192547.5c831021@subdivisions.wooz.org>
 <CAP1=2W6r59YNP2NaFSu5f3jEF-WcfbcbSHoQT81k1DBg81b+jQ@mail.gmail.com>
 <20170315200323.1b6ebd89@subdivisions.wooz.org>
 <CAP1=2W62t8J0qUstz8VL_9hmwsYXe8mT5FFdK6DkLz_nyaBYEg@mail.gmail.com>
Message-ID: <20170316132546.6fef63a7@subdivisions.wooz.org>

On Mar 16, 2017, at 04:14 PM, Brett Cannon wrote:

>Ah, you didn't say you wanted this to be a status check. :) Do we want to
>go so far as that rather than a comment or PR template?

I like it for that on my other projects, so I'm pretty sure I'd like that for
CPython.  I'm a big fan of more automated checks -when they are stable and
robust- for doing the fiddly little checks that are a pain to do manually.  I
like requiring bug reports for most things, plus style checks, etc.  It makes
it so much easier for a submitter to conform because they get immediate
feedback if they break some policy.  There's usually a strong drive to get all
the lights green.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170316/e66ecb8e/attachment.sig>

From brett at python.org  Fri Mar 17 13:37:14 2017
From: brett at python.org (Brett Cannon)
Date: Fri, 17 Mar 2017 17:37:14 +0000
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <20170316132546.6fef63a7@subdivisions.wooz.org>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <0371996D-5873-4D86-9484-8A9DDF4F1F30@gmail.com>
 <CAP1=2W7JFg09S_y6q3-zHgM0oKK1fLj3hckbz4RXkyPxtNUi-w@mail.gmail.com>
 <523E945D-EBEA-4934-BB37-A57CF44A1086@python.org>
 <20170314192547.5c831021@subdivisions.wooz.org>
 <CAP1=2W6r59YNP2NaFSu5f3jEF-WcfbcbSHoQT81k1DBg81b+jQ@mail.gmail.com>
 <20170315200323.1b6ebd89@subdivisions.wooz.org>
 <CAP1=2W62t8J0qUstz8VL_9hmwsYXe8mT5FFdK6DkLz_nyaBYEg@mail.gmail.com>
 <20170316132546.6fef63a7@subdivisions.wooz.org>
Message-ID: <CAP1=2W6yKVC0bRcDoKB0SfB3vWhD64kB7LW+NZUtvPJvcubj3A@mail.gmail.com>

https://github.com/python/core-workflow/issues/13 already exists to track
this idea, so it can be discussed more over there.

On Thu, 16 Mar 2017 at 10:26 Barry Warsaw <barry at python.org> wrote:

> On Mar 16, 2017, at 04:14 PM, Brett Cannon wrote:
>
> >Ah, you didn't say you wanted this to be a status check. :) Do we want to
> >go so far as that rather than a comment or PR template?
>
> I like it for that on my other projects, so I'm pretty sure I'd like that
> for
> CPython.  I'm a big fan of more automated checks -when they are stable and
> robust- for doing the fiddly little checks that are a pain to do
> manually.  I
> like requiring bug reports for most things, plus style checks, etc.  It
> makes
> it so much easier for a submitter to conform because they get immediate
> feedback if they break some policy.  There's usually a strong drive to get
> all
> the lights green.
>
> Cheers,
> -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/20170317/3eab827a/attachment.html>

From storchaka at gmail.com  Sun Mar 19 03:41:25 2017
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Sun, 19 Mar 2017 09:41:25 +0200
Subject: [python-committers] Broken Travis blocks merging
Message-ID: <CAAuNNr4msOmSPJXvkHCrJ5bPFSEMz3q=Z3G5Fai22E8u6h8crw@mail.gmail.com>

For now all Travis CI builds failed. This blocks merging new PRs,
backports and old PRs that need resolving Misc/NEWS conflicts.

For details see https://github.com/python/core-workflow/issues/54 .

From brett at python.org  Sun Mar 19 12:43:53 2017
From: brett at python.org (Brett Cannon)
Date: Sun, 19 Mar 2017 16:43:53 +0000
Subject: [python-committers] Broken Travis blocks merging
In-Reply-To: <CAAuNNr4msOmSPJXvkHCrJ5bPFSEMz3q=Z3G5Fai22E8u6h8crw@mail.gmail.com>
References: <CAAuNNr4msOmSPJXvkHCrJ5bPFSEMz3q=Z3G5Fai22E8u6h8crw@mail.gmail.com>
Message-ID: <CAP1=2W6WRUAfyzYg8r4d6cCO4AGy-wyjjQnxTn8_edFTmB39hQ@mail.gmail.com>

Failure is due to https://travis-ci.org/python/cpython/builds/212301336 which
passed Travis and was reviewed by two other core devs. Unfortunately none
of us picked up on the fact that the success of Travis was because it
skipped running the test suite where the C++ header compatibility test was
moved to.

I have opend https://github.com/python/cpython/pull/718 to fix it and will
backport as soon as Travis is green on that PR.

On Sun, 19 Mar 2017 at 00:41 Serhiy Storchaka <storchaka at gmail.com> wrote:

> For now all Travis CI builds failed. This blocks merging new PRs,
> backports and old PRs that need resolving Misc/NEWS conflicts.
>
> For details see https://github.com/python/core-workflow/issues/54 .
> _______________________________________________
> 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/20170319/96011d90/attachment.html>

From nad at python.org  Tue Mar 21 23:16:50 2017
From: nad at python.org (Ned Deily)
Date: Tue, 21 Mar 2017 23:16:50 -0400
Subject: [python-committers] [RELEASE] Python 3.6.1 is now available
Message-ID: <4AA9F522-CAC7-4ACC-991C-495F17E1045A@python.org>

On behalf of the Python development community and the Python 3.6 release
team, I would like to announce the availability of Python 3.6.1, the
first maintenance release of Python 3.6.  3.6.0 was released on 2016-12-22
to great interest and now, three months later, we are providing the
first set of bugfixes and documentation updates for it.  Although it
should be transparent to users of Python, 3.6.1 is the first release
after some major changes to our development process so we ask users
who build Python from source to be on the lookout for any unexpected
differences.

Please see "What?s New In Python 3.6" for more information:

https://docs.python.org/3.6/whatsnew/3.6.html

You can find Python 3.6.1 here:

https://www.python.org/downloads/release/python-361/

and its change log here:

https://docs.python.org/3.6/whatsnew/changelog.html#python-3-6-1

The next maintenance release of Python 3.6 is expected to follow in
about 3 months by the end of 2017-06.  More information about the 3.6
release schedule can be found here:

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


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


From antoine at python.org  Fri Mar 24 09:25:56 2017
From: antoine at python.org (Antoine Pitrou)
Date: Fri, 24 Mar 2017 14:25:56 +0100
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
Message-ID: <83540c6b-d837-5776-09cd-2b3e29229283@python.org>


Le 10/03/2017 ? 23:13, Brett Cannon a ?crit :
> I can't believe it's been 4 weeks. It feels like it was ages/yesterday
> when we moved. :)
> 
> First, I hope people are not regretting letting/having me make this
> migration. I know there have been some things to work through (and
> others still to come), but I hope this is all a net positive (either now
> or in the near future).
> 
> Second, I wanted to get initial feedback on things we can easily tweak:
> 
>   * Requiring Travis to pass (I *really* don't want to turn this off as
>     we already had a broken build when I temporarily turned it off at
>     someone's request when Travis was backed up from the AWS S3 outage;
>     I also don't plan to make AppVeyor required unless there's a way to
>     make it be skipped for doc-only changes)
>   * Cherry-picking working out? (We can go back to forward merging if
>     people really want to, but I think long-term cherry-picking will
>     allow for more automation)

Now that I'm trying it out, the effect of cherry-picking on Misc/NEWS is
catastrophic.  hg wasn't very friendly (producing obviously spurious
conflicts), but at least it was reasonably easy to correct the
situation.  git seems to leave Misc/NEWS in an extremely messy state.
For example, here is the merge diff I'm getting right now:
https://gist.github.com/pitrou/37dd07d0136644266ca012e979c27847

Good luck spotting devising how to fix Misc/NEWS after that (apart from
retrieving the previous version and adding the NEWS entry manually)...

Regards

Antoine.

From antoine at python.org  Fri Mar 24 09:29:13 2017
From: antoine at python.org (Antoine Pitrou)
Date: Fri, 24 Mar 2017 14:29:13 +0100
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <83540c6b-d837-5776-09cd-2b3e29229283@python.org>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <83540c6b-d837-5776-09cd-2b3e29229283@python.org>
Message-ID: <f96f2b64-f3ff-b87a-41b5-d16ccf57bff1@python.org>


By the way, how do I fetch remote changes for a branch without pulling
it into the working copy?  e.g. I'd like to do "git fetch origin 3.5" or
"git fetch origin/3.5", but that doesn't seem to work...

Regards

Antoine.



Le 24/03/2017 ? 14:25, Antoine Pitrou a ?crit :
> 
> Le 10/03/2017 ? 23:13, Brett Cannon a ?crit :
>> I can't believe it's been 4 weeks. It feels like it was ages/yesterday
>> when we moved. :)
>>
>> First, I hope people are not regretting letting/having me make this
>> migration. I know there have been some things to work through (and
>> others still to come), but I hope this is all a net positive (either now
>> or in the near future).
>>
>> Second, I wanted to get initial feedback on things we can easily tweak:
>>
>>   * Requiring Travis to pass (I *really* don't want to turn this off as
>>     we already had a broken build when I temporarily turned it off at
>>     someone's request when Travis was backed up from the AWS S3 outage;
>>     I also don't plan to make AppVeyor required unless there's a way to
>>     make it be skipped for doc-only changes)
>>   * Cherry-picking working out? (We can go back to forward merging if
>>     people really want to, but I think long-term cherry-picking will
>>     allow for more automation)
> 
> Now that I'm trying it out, the effect of cherry-picking on Misc/NEWS is
> catastrophic.  hg wasn't very friendly (producing obviously spurious
> conflicts), but at least it was reasonably easy to correct the
> situation.  git seems to leave Misc/NEWS in an extremely messy state.
> For example, here is the merge diff I'm getting right now:
> https://gist.github.com/pitrou/37dd07d0136644266ca012e979c27847
> 
> Good luck spotting devising how to fix Misc/NEWS after that (apart from
> retrieving the previous version and adding the NEWS entry manually)...
> 
> Regards
> 
> Antoine.

From antoine at python.org  Fri Mar 24 09:33:46 2017
From: antoine at python.org (Antoine Pitrou)
Date: Fri, 24 Mar 2017 14:33:46 +0100
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
Message-ID: <7ad67c9e-68f1-4e77-1b85-aeb10c2938f1@python.org>


Le 10/03/2017 ? 23:13, Brett Cannon a ?crit :
> I can't believe it's been 4 weeks. It feels like it was ages/yesterday
> when we moved. :)
> 
> First, I hope people are not regretting letting/having me make this
> migration. I know there have been some things to work through (and
> others still to come), but I hope this is all a net positive (either now
> or in the near future).
> 
> Second, I wanted to get initial feedback on things we can easily tweak:
> 
>   * Requiring Travis to pass (I *really* don't want to turn this off as
>     we already had a broken build when I temporarily turned it off at
>     someone's request when Travis was backed up from the AWS S3 outage;
>     I also don't plan to make AppVeyor required unless there's a way to
>     make it be skipped for doc-only changes)
>   * Cherry-picking working out? (We can go back to forward merging if
>     people really want to, but I think long-term cherry-picking will
>     allow for more automation)

Right now, the way cherry-picking works (or doesn't really work, rather)
makes me likely to do "blind cherry-picks", that is try to fix conflicts
and trust the script's output without really bothering to inspect the
code locally, instead relying on Travis and AppVeyor.
I don't know if that's good for long-term quality.

I am more or less used to git, but it's the first time I have a
cherry-picking workflow (the other projects I work on don't really have
a notion of bugfix branch, or only an ephemeral one).  git seems to make
that extremely painful.

Really

Antoine.

From antoine at python.org  Fri Mar 24 09:43:31 2017
From: antoine at python.org (Antoine Pitrou)
Date: Fri, 24 Mar 2017 14:43:31 +0100
Subject: [python-committers] Is clang testing necessary?
Message-ID: <cca5659b-3460-bb33-b143-9d88e46b40bb@python.org>


Hello,

I am curious about the decision to have Travis-CI tests with both clang
and gcc.  clang is a compiler which strives to be very compatible with
gcc.  I would understand testing under OS X with clang in addition to
Linux with gcc, but I'm skeptical we gain much from testing both gcc and
clang under Linux.  Also, it lengthens CI times, as clang produces
slower code in debug mode than gcc does (because we use "-Og" on gcc).

Or perhaps we could switch the clang build to produce a non-debug
interpreter (and therefore a faster test suite)?

Regards

Antoine.

From rdmurray at bitdance.com  Fri Mar 24 11:11:31 2017
From: rdmurray at bitdance.com (R. David Murray)
Date: Fri, 24 Mar 2017 11:11:31 -0400
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <f96f2b64-f3ff-b87a-41b5-d16ccf57bff1@python.org>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <83540c6b-d837-5776-09cd-2b3e29229283@python.org>
 <f96f2b64-f3ff-b87a-41b5-d16ccf57bff1@python.org>
Message-ID: <20170324151131.B3E361B10013@webabinitio.net>

On Fri, 24 Mar 2017 14:29:13 +0100, Antoine Pitrou <antoine at python.org> wrote:
> 
> By the way, how do I fetch remote changes for a branch without pulling
> it into the working copy?  e.g. I'd like to do "git fetch origin 3.5" or
> "git fetch origin/3.5", but that doesn't seem to work...

"git fetch origin 3.5" seems to work fine for me.  Maybe I don't
understand what you are trying to do?

--David

From antoine at python.org  Fri Mar 24 11:22:16 2017
From: antoine at python.org (Antoine Pitrou)
Date: Fri, 24 Mar 2017 16:22:16 +0100
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <20170324151131.B3E361B10013@webabinitio.net>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <83540c6b-d837-5776-09cd-2b3e29229283@python.org>
 <f96f2b64-f3ff-b87a-41b5-d16ccf57bff1@python.org>
 <20170324151131.B3E361B10013@webabinitio.net>
Message-ID: <11624558-a4db-57ae-3d31-d7db0a3df44d@python.org>


Hi,

Le 24/03/2017 ? 16:11, R. David Murray a ?crit :
> On Fri, 24 Mar 2017 14:29:13 +0100, Antoine Pitrou <antoine at python.org> wrote:
>>
>> By the way, how do I fetch remote changes for a branch without pulling
>> it into the working copy?  e.g. I'd like to do "git fetch origin 3.5" or
>> "git fetch origin/3.5", but that doesn't seem to work...
> 
> "git fetch origin 3.5" seems to work fine for me.  Maybe I don't
> understand what you are trying to do?

Apologies for being slightly imprecise.  Yes, "git fetch origin 3.5"
actually fetches the remote changes, but it doesn't update the local
"3.5" branch with those changes, so when I do "git diff 3.5" from
another branch, I get spurious changes in the diff.

(perhaps I should do "git diff origin/3.5" instead?)

Regards

Antoine.

From songofacandy at gmail.com  Fri Mar 24 12:00:53 2017
From: songofacandy at gmail.com (INADA Naoki)
Date: Sat, 25 Mar 2017 01:00:53 +0900
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <11624558-a4db-57ae-3d31-d7db0a3df44d@python.org>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <83540c6b-d837-5776-09cd-2b3e29229283@python.org>
 <f96f2b64-f3ff-b87a-41b5-d16ccf57bff1@python.org>
 <20170324151131.B3E361B10013@webabinitio.net>
 <11624558-a4db-57ae-3d31-d7db0a3df44d@python.org>
Message-ID: <CAEfz+TyrfEGaSOMxwaVoXqGa+NSETewGVfdYD3dkBeFWfC=KEw@mail.gmail.com>

On Sat, Mar 25, 2017 at 12:22 AM, Antoine Pitrou <antoine at python.org> wrote:
>
> Hi,
>
> Le 24/03/2017 ? 16:11, R. David Murray a ?crit :
>> On Fri, 24 Mar 2017 14:29:13 +0100, Antoine Pitrou <antoine at python.org> wrote:
>>>
>>> By the way, how do I fetch remote changes for a branch without pulling
>>> it into the working copy?  e.g. I'd like to do "git fetch origin 3.5" or
>>> "git fetch origin/3.5", but that doesn't seem to work...
>>
>> "git fetch origin 3.5" seems to work fine for me.  Maybe I don't
>> understand what you are trying to do?
>
> Apologies for being slightly imprecise.  Yes, "git fetch origin 3.5"
> actually fetches the remote changes, but it doesn't update the local
> "3.5" branch with those changes, so when I do "git diff 3.5" from
> another branch, I get spurious changes in the diff.
>
> (perhaps I should do "git diff origin/3.5" instead?)
>
> Regards
>
> Antoine.

Yes, `git diff origin/3.5` is normal way.  If you always use feature branch,
there are no need for local 3.5 branch.
I usually create "backport" branch by: `git checkout -b
backport-xxx-35 origin/3.5`.

OTOH, there is hackey way.  Assuming you didn't have checkout of local
3.5 branch,
`git push . origin/3.5:3.5` may update 3.5 branch.

From brett at python.org  Fri Mar 24 12:24:41 2017
From: brett at python.org (Brett Cannon)
Date: Fri, 24 Mar 2017 16:24:41 +0000
Subject: [python-committers] Is clang testing necessary?
In-Reply-To: <cca5659b-3460-bb33-b143-9d88e46b40bb@python.org>
References: <cca5659b-3460-bb33-b143-9d88e46b40bb@python.org>
Message-ID: <CAP1=2W7X0H-XiCkdMEpgw7Ft4JOLd6W-tzY-9Br+P_Qzu_0R8w@mail.gmail.com>

On Fri, 24 Mar 2017 at 06:43 Antoine Pitrou <antoine at python.org> wrote:

>
> Hello,
>
> I am curious about the decision to have Travis-CI tests with both clang
> and gcc.


It was when I was trying to maximize Travis usefulness before the
migration. It's also because we as a project have found bugs in both
compilers previously (I know I personally reported a bug that affected both
of them once upstream).


>   clang is a compiler which strives to be very compatible with
> gcc.  I would understand testing under OS X with clang in addition to
> Linux with gcc, but I'm skeptical we gain much from testing both gcc and
> clang under Linux.  Also, it lengthens CI times, as clang produces
> slower code in debug mode than gcc does (because we use "-Og" on gcc).
>

Is there an equivalent flag for clang we should be using?


>
> Or perhaps we could switch the clang build to produce a non-debug
> interpreter (and therefore a faster test suite)?
>

Another option is if we drop a compiler from a debug build we can use it
for the coverage run so it's at least being exercised somewhere.

If we drop either compiler I would vote for dropping gcc actually as the
compiler messages are much worse on gcc compared to clang. I guess it comes
down to whether we think CI should be used as a fallback for a failing test
suite or if we think CI might help contributors if they happen to have a
bug in their C code that they simply didn't notice (e.g. thought they made
an innocuous  fix that didn't warrant a rebuild).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170324/07350f66/attachment.html>

From brett at python.org  Fri Mar 24 12:28:09 2017
From: brett at python.org (Brett Cannon)
Date: Fri, 24 Mar 2017 16:28:09 +0000
Subject: [python-committers] 4 weeks with the new workflow: what needs
 changing?
In-Reply-To: <83540c6b-d837-5776-09cd-2b3e29229283@python.org>
References: <CAP1=2W5mv39824pqk2r0T4xmXSMJOHzNPhQPUhWCbhZv33iEjA@mail.gmail.com>
 <83540c6b-d837-5776-09cd-2b3e29229283@python.org>
Message-ID: <CAP1=2W4q+3UyXP08kUoavWULte9PESWfCaChu5+6tfj=k7SovA@mail.gmail.com>

On Fri, 24 Mar 2017 at 06:26 Antoine Pitrou <antoine at python.org> wrote:

>
> Le 10/03/2017 ? 23:13, Brett Cannon a ?crit :
> > I can't believe it's been 4 weeks. It feels like it was ages/yesterday
> > when we moved. :)
> >
> > First, I hope people are not regretting letting/having me make this
> > migration. I know there have been some things to work through (and
> > others still to come), but I hope this is all a net positive (either now
> > or in the near future).
> >
> > Second, I wanted to get initial feedback on things we can easily tweak:
> >
> >   * Requiring Travis to pass (I *really* don't want to turn this off as
> >     we already had a broken build when I temporarily turned it off at
> >     someone's request when Travis was backed up from the AWS S3 outage;
> >     I also don't plan to make AppVeyor required unless there's a way to
> >     make it be skipped for doc-only changes)
> >   * Cherry-picking working out? (We can go back to forward merging if
> >     people really want to, but I think long-term cherry-picking will
> >     allow for more automation)
>
> Now that I'm trying it out, the effect of cherry-picking on Misc/NEWS is
> catastrophic.  hg wasn't very friendly (producing obviously spurious
> conflicts), but at least it was reasonably easy to correct the
> situation.  git seems to leave Misc/NEWS in an extremely messy state.
> For example, here is the merge diff I'm getting right now:
> https://gist.github.com/pitrou/37dd07d0136644266ca012e979c27847
>
> Good luck spotting devising how to fix Misc/NEWS after that (apart from
> retrieving the previous version and adding the NEWS entry manually)...
>

This is actively being worked on and I'm hoping to have it resolved in the
next week or so (I really don't see it going passed the end of this month,
but I would be absolutely shocked if it isn't fixed by May).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170324/c64222d2/attachment.html>

From victor.stinner at gmail.com  Fri Mar 24 12:28:17 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Fri, 24 Mar 2017 17:28:17 +0100
Subject: [python-committers] Is clang testing necessary?
In-Reply-To: <CAP1=2W7X0H-XiCkdMEpgw7Ft4JOLd6W-tzY-9Br+P_Qzu_0R8w@mail.gmail.com>
References: <cca5659b-3460-bb33-b143-9d88e46b40bb@python.org>
 <CAP1=2W7X0H-XiCkdMEpgw7Ft4JOLd6W-tzY-9Br+P_Qzu_0R8w@mail.gmail.com>
Message-ID: <CAMpsgwbowOpayBqmLQ70pFWhL6kKwLQHBohnY17qzeAuXqMDUA@mail.gmail.com>

Even if for most changes, testing gcc and clang is useless, I'm in
favor of keeping both for the CI. It doesn't cost much, and it's not
that uncommon that Clang catchs bugs or warnings, than GCC doesn't.

The question is more who checks for compiler warnings in the CI :-)
Currently, you have to dig into logs, it's not really convenient.

Sometimes, I see compiler warnings when I read buildbots stdout. I'm
trying to fix them in a irregular basis :-)

Victor

From brett at python.org  Fri Mar 24 16:37:41 2017
From: brett at python.org (Brett Cannon)
Date: Fri, 24 Mar 2017 20:37:41 +0000
Subject: [python-committers] GitHub now visibly calls out first-time
 contributors
Message-ID: <CAP1=2W42890TXWQoWYf7_0RjUqyV28huw3j14QfPnqXcjsOqUg@mail.gmail.com>

https://twitter.com/benbalter/status/845305265159376896

Basically all of us will get to see when someone is a first-time
contributor (it's not publicly visible, only to people who can merge PRs).
I suspect that will not only lead to some of us being extra hands-on and
forgiving of mistakes, but maybe even try to make a decision about the PR
faster so they are not left wondering the fate of the PR.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170324/326be4c5/attachment.html>

From ncoghlan at gmail.com  Sat Mar 25 11:27:44 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 26 Mar 2017 01:27:44 +1000
Subject: [python-committers] Is clang testing necessary?
In-Reply-To: <CAP1=2W7X0H-XiCkdMEpgw7Ft4JOLd6W-tzY-9Br+P_Qzu_0R8w@mail.gmail.com>
References: <cca5659b-3460-bb33-b143-9d88e46b40bb@python.org>
 <CAP1=2W7X0H-XiCkdMEpgw7Ft4JOLd6W-tzY-9Br+P_Qzu_0R8w@mail.gmail.com>
Message-ID: <CADiSq7e5a5kg+d=gSr_EmATRyy6r+YTRaV8t9XRP2vVFFKkjbg@mail.gmail.com>

On 25 March 2017 at 02:24, Brett Cannon <brett at python.org> wrote:

> Another option is if we drop a compiler from a debug build we can use it
> for the coverage run so it's at least being exercised somewhere.
>
> If we drop either compiler I would vote for dropping gcc actually as the
> compiler messages are much worse on gcc compared to clang. I guess it comes
> down to whether we think CI should be used as a fallback for a failing test
> suite or if we think CI might help contributors if they happen to have a
> bug in their C code that they simply didn't notice (e.g. thought they made
> an innocuous  fix that didn't warrant a rebuild).
>

Catching "forgot to run make before running the tests" is a useful role,
but in that case I'd expect most folks to go "oops" and do a local build,
rather than trying to debug compile errors solely from the CI logs (except
for the cross-platform case, where something works on Windows but not on
*nix, and vice-versa).

However, from the point of view of making it easier for Windows devs to
debug *nix debug errors, it probably makes more sense to use clang for the
main *nix test run, and then use gcc to do the coverage run.

That setup would give:

- all 3 default compilers running in CI (MSVC in Appveyor, clang for the
main Travis tests, gcc for the coverage run)
- Windows devs getting the friendlier clang error messages when they're
trying to debug a cross-platform compilation problem

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/20170326/c0622bea/attachment.html>

From antoine at python.org  Sat Mar 25 13:54:30 2017
From: antoine at python.org (Antoine Pitrou)
Date: Sat, 25 Mar 2017 18:54:30 +0100
Subject: [python-committers] Is clang testing necessary?
In-Reply-To: <CADiSq7e5a5kg+d=gSr_EmATRyy6r+YTRaV8t9XRP2vVFFKkjbg@mail.gmail.com>
References: <cca5659b-3460-bb33-b143-9d88e46b40bb@python.org>
 <CAP1=2W7X0H-XiCkdMEpgw7Ft4JOLd6W-tzY-9Br+P_Qzu_0R8w@mail.gmail.com>
 <CADiSq7e5a5kg+d=gSr_EmATRyy6r+YTRaV8t9XRP2vVFFKkjbg@mail.gmail.com>
Message-ID: <beee27f3-0d9c-1a66-1ebe-3758aed8cca9@python.org>


Le 25/03/2017 ? 16:27, Nick Coghlan a ?crit :
> 
> However, from the point of view of making it easier for Windows devs to
> debug *nix debug errors, it probably makes more sense to use clang for
> the main *nix test run, and then use gcc to do the coverage run.

What's the problem exactly? Situations where MSVC is more lenient than
either gcc or clang? Usually it's the reverse :-)

> That setup would give:
> 
> - all 3 default compilers running in CI (MSVC in Appveyor, clang for the
> main Travis tests, gcc for the coverage run)
> - Windows devs getting the friendlier clang error messages when they're
> trying to debug a cross-platform compilation problem

- Travis builds are longer because gcc benefits from "-Og" which clang
doesn't.

Regards

Antoine.

From ncoghlan at gmail.com  Sun Mar 26 07:30:56 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 26 Mar 2017 21:30:56 +1000
Subject: [python-committers] Is clang testing necessary?
In-Reply-To: <beee27f3-0d9c-1a66-1ebe-3758aed8cca9@python.org>
References: <cca5659b-3460-bb33-b143-9d88e46b40bb@python.org>
 <CAP1=2W7X0H-XiCkdMEpgw7Ft4JOLd6W-tzY-9Br+P_Qzu_0R8w@mail.gmail.com>
 <CADiSq7e5a5kg+d=gSr_EmATRyy6r+YTRaV8t9XRP2vVFFKkjbg@mail.gmail.com>
 <beee27f3-0d9c-1a66-1ebe-3758aed8cca9@python.org>
Message-ID: <CADiSq7d5tvrm_Wv8LXaKX-aNu4vHZkSjL4=sZ+bBn0Bvmd+erA@mail.gmail.com>

On 26 March 2017 at 03:54, Antoine Pitrou <antoine at python.org> wrote:
>
> Le 25/03/2017 ? 16:27, Nick Coghlan a ?crit :
>>
>> However, from the point of view of making it easier for Windows devs to
>> debug *nix debug errors, it probably makes more sense to use clang for
>> the main *nix test run, and then use gcc to do the coverage run.
>
> What's the problem exactly? Situations where MSVC is more lenient than
> either gcc or clang? Usually it's the reverse :-)

I'm mainly thinking of situations where the Windows way of doing
something is different from the *nix way of doing it (e.g. I hit one
in the other direction recently, where setenv becomes something like
SetEnvironmentVarW on the Windows side of things).

While those are generally pretty straightforward complaints about
undefined symbols, it doesn't hurt to favour the compiler that's known
for easier to read messages.

Cheers,
Nick.



-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From larry at hastings.org  Mon Mar 27 14:26:45 2017
From: larry at hastings.org (Larry Hastings)
Date: Mon, 27 Mar 2017 11:26:45 -0700
Subject: [python-committers] Signups for 2017 Python Language Summit are now
 open
Message-ID: <cb7f252c-a6a5-a604-f046-e84d5cad834d@hastings.org>


(reposting, cc'ing python-dev)

It?s that time again: time to start thinking about the Python Language Summit!
The 2017 summit will be held on Wednesday, May 17, from 10am to 4pm, at the
Oregon Convention Center in Portland, Oregon, USA.  Your befezzled hosts Larry
and Barry will once again be at the helm.

The summit?s purpose is to disseminate information and spark conversation
among core Python developers.  It?s our yearly opportunity to get together for
an in-person discussion, to review interesting developments of the previous
year and hash out where we?re going next.  And we have lots to talk about!
Since our last summit, Python 3.6 was released, and the main CPython
development process has been moved to GitHub.  Naturally Python 3.7
development continues apace.

Speaking of changes, we?re continuing to evolve the summit.  Everyone seemed
to like the lightning talks, so we?ll keep those.  Everyone seemed to hate us
keeping the schedule secret -sorry!- so we?ll make that available beforehand,
with the understanding that it?ll be fluid as the day progresses.  Due to room
size limitations and the yearly increase in participation, we?re limiting
summit invitations to just core developers and invited speakers.  As usual,
we?ll have whiteboards and a projector.  But this year we?re adding roaming
microphones, so everybody in the room will be able to hear your question!

With the help of the ever awesome Ewa, this year we?ll have badge ribbons for
Language Summit participants, which we?ll hand out at the summit room in the
morning.

As with last year, we?re using Google Forms to collect signups.  The form will
let you request an invitation to the summit and optionally propose a talk.
Signups are open now, and will remain open until Wednesday April 12th, 2017.
You can find the link to the signup form from the summit?s official web page,
here:

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

But never forget: you don?t need to be registered for PyCon in order to attend
the summit!

One final note.  We?re re-inviting Jake Edge from Linux Weekly News to attend
the summit and provide press coverage.  Jake?s done a phenomenal job of
covering the previous two years? summits, providing valuable information not
just for summit attendees, but also for the Python community at large.  Jake?s
coverage goes a long way toward demystifying the summit, while remaining
respectful of confidential information that?s deemed ?off the record? ahead of
time by participants.

We hope to see you at the summit!


[BL]arry

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

From brett at python.org  Mon Mar 27 19:49:27 2017
From: brett at python.org (Brett Cannon)
Date: Mon, 27 Mar 2017 23:49:27 +0000
Subject: [python-committers] Is clang testing necessary?
In-Reply-To: <CADiSq7d5tvrm_Wv8LXaKX-aNu4vHZkSjL4=sZ+bBn0Bvmd+erA@mail.gmail.com>
References: <cca5659b-3460-bb33-b143-9d88e46b40bb@python.org>
 <CAP1=2W7X0H-XiCkdMEpgw7Ft4JOLd6W-tzY-9Br+P_Qzu_0R8w@mail.gmail.com>
 <CADiSq7e5a5kg+d=gSr_EmATRyy6r+YTRaV8t9XRP2vVFFKkjbg@mail.gmail.com>
 <beee27f3-0d9c-1a66-1ebe-3758aed8cca9@python.org>
 <CADiSq7d5tvrm_Wv8LXaKX-aNu4vHZkSjL4=sZ+bBn0Bvmd+erA@mail.gmail.com>
Message-ID: <CAP1=2W4nMuvgWFQbZxR76FSLbeCQRXq3t_fKGC9BB2coxURw+A@mail.gmail.com>

I've gone ahead and dropped the gcc test build and switched the coverage
test to gcc. If we find in time that clang's speed is really an issue
compared to its better error messages we can swap the compilers' roles.

On Sun, 26 Mar 2017 at 04:31 Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 26 March 2017 at 03:54, Antoine Pitrou <antoine at python.org> wrote:
> >
> > Le 25/03/2017 ? 16:27, Nick Coghlan a ?crit :
> >>
> >> However, from the point of view of making it easier for Windows devs to
> >> debug *nix debug errors, it probably makes more sense to use clang for
> >> the main *nix test run, and then use gcc to do the coverage run.
> >
> > What's the problem exactly? Situations where MSVC is more lenient than
> > either gcc or clang? Usually it's the reverse :-)
>
> I'm mainly thinking of situations where the Windows way of doing
> something is different from the *nix way of doing it (e.g. I hit one
> in the other direction recently, where setenv becomes something like
> SetEnvironmentVarW on the Windows side of things).
>
> While those are generally pretty straightforward complaints about
> undefined symbols, it doesn't hurt to favour the compiler that's known
> for easier to read messages.
>
> 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/20170327/46afd3e4/attachment.html>

From antoine at python.org  Fri Mar 31 14:30:13 2017
From: antoine at python.org (Antoine Pitrou)
Date: Fri, 31 Mar 2017 20:30:13 +0200
Subject: [python-committers] Spurious bugs.p.o messages
Message-ID: <fb9ab482-5e91-7497-5c8e-1a29c669472e@python.org>


Hello,

Just a heads up that the following PR:
https://github.com/python/cpython/pull/552/files
has generated a lot of spurious PR additions on bugs.python.org,
probably because that PR references a lot of issues
(example: https://bugs.python.org/issue23839).

Perhaps it would be nice to have an upper limit on the number of
notified issues when the PR mentions several of them?

(I'm sure someone more active than me, such as Victor or Serhiy, got *a
lot* of notifications from that PR :-))

Regards

Antoine.

From victor.stinner at gmail.com  Fri Mar 31 15:36:34 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Fri, 31 Mar 2017 21:36:34 +0200
Subject: [python-committers] Spurious bugs.p.o messages
In-Reply-To: <fb9ab482-5e91-7497-5c8e-1a29c669472e@python.org>
References: <fb9ab482-5e91-7497-5c8e-1a29c669472e@python.org>
Message-ID: <CAMpsgwYGxeLWNTWYcjB1MOUuOKYpaLdaH2Xd+c+1qU5ecGFzdw@mail.gmail.com>

2017-03-31 20:30 GMT+02:00 Antoine Pitrou <antoine at python.org>:
> Just a heads up that the following PR:
> https://github.com/python/cpython/pull/552/files
> has generated a lot of spurious PR additions on bugs.python.org,
> probably because that PR references a lot of issues
> (example: https://bugs.python.org/issue23839).
>
> Perhaps it would be nice to have an upper limit on the number of
> notified issues when the PR mentions several of them?
>
> (I'm sure someone more active than me, such as Victor or Serhiy, got *a
> lot* of notifications from that PR :-))

Hello, I got 110 emails, something goes wrong? :-)

Victor

From brett at python.org  Fri Mar 31 17:40:15 2017
From: brett at python.org (Brett Cannon)
Date: Fri, 31 Mar 2017 21:40:15 +0000
Subject: [python-committers] I have blocked Wes Turner from the Python org
 on GitHub
Message-ID: <CAP1=2W5=ukka=32n4cUdRLs=tn059Nb9St_J-P2VR4u9Jo2E7g@mail.gmail.com>

In the (long) discussion of https://github.com/python/core-workflow/issues/6,
Wes Turner began to do his usual posting of lists. People pointed out he
was stepping out of line by being somewhat off-topic and seemingly
lecturing folks. He posted some of his lists again and then I warned him
that if he did it again I would block him for a CoC violation since he did
not want to respect anyone's time by taking the time to edit what amount to
dumping his personal notes on GitHub. (This is a long-standing issue, BTW,
with Wes where he has been warned in other settings like distutils-sig
about his posting behaviour.)

Unfortunately he did it again for
https://github.com/python/core-workflow/issues/66. Since GitHub only has
organization-level blocks I have blocked him at that level (I've also
already received some +1s from core devs while writing this email for my
move, so I know others who have interacted with him also support this
decision).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170331/241d0c53/attachment.html>

From brett at python.org  Fri Mar 31 18:08:13 2017
From: brett at python.org (Brett Cannon)
Date: Fri, 31 Mar 2017 22:08:13 +0000
Subject: [python-committers] Spurious bugs.p.o messages
In-Reply-To: <CAMpsgwYGxeLWNTWYcjB1MOUuOKYpaLdaH2Xd+c+1qU5ecGFzdw@mail.gmail.com>
References: <fb9ab482-5e91-7497-5c8e-1a29c669472e@python.org>
 <CAMpsgwYGxeLWNTWYcjB1MOUuOKYpaLdaH2Xd+c+1qU5ecGFzdw@mail.gmail.com>
Message-ID: <CAP1=2W5Yy-wzNfJsN4F+UTkjcaD5fmwXW+GuDHnhYN_y2B9WnQ@mail.gmail.com>

On Fri, 31 Mar 2017 at 12:37 Victor Stinner <victor.stinner at gmail.com>
wrote:

> 2017-03-31 20:30 GMT+02:00 Antoine Pitrou <antoine at python.org>:
> > Just a heads up that the following PR:
> > https://github.com/python/cpython/pull/552/files
> > has generated a lot of spurious PR additions on bugs.python.org,
> > probably because that PR references a lot of issues
> > (example: https://bugs.python.org/issue23839).
> >
> > Perhaps it would be nice to have an upper limit on the number of
> > notified issues when the PR mentions several of them?
> >
> > (I'm sure someone more active than me, such as Victor or Serhiy, got *a
> > lot* of notifications from that PR :-))
>
> Hello, I got 110 emails, something goes wrong? :-)
>

No, it's a side-effect of having Misc/NEWS pasted as a comment into a PR
and the Roundup webhook thinking the issues were comments that warranted
connecting the PR with the issue.  Either we (a) don't worry about it as
people typically don't paste Misc/NEWS into a comment, (b) cap the number
of possible issues in a single webhook event, or (c) don't pick up issue
numbers from comments and only do it from PR titles.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170331/79abd3c9/attachment.html>

From tjreedy at udel.edu  Fri Mar 31 18:59:39 2017
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 31 Mar 2017 18:59:39 -0400
Subject: [python-committers] Spurious bugs.p.o messages
In-Reply-To: <CAP1=2W5Yy-wzNfJsN4F+UTkjcaD5fmwXW+GuDHnhYN_y2B9WnQ@mail.gmail.com>
References: <fb9ab482-5e91-7497-5c8e-1a29c669472e@python.org>
 <CAMpsgwYGxeLWNTWYcjB1MOUuOKYpaLdaH2Xd+c+1qU5ecGFzdw@mail.gmail.com>
 <CAP1=2W5Yy-wzNfJsN4F+UTkjcaD5fmwXW+GuDHnhYN_y2B9WnQ@mail.gmail.com>
Message-ID: <5e6c8356-7d48-afc1-d06b-5ab5bb41e7e7@udel.edu>

On 3/31/2017 6:08 PM, Brett Cannon wrote:
>
>
> On Fri, 31 Mar 2017 at 12:37 Victor Stinner <victor.stinner at gmail.com
> <mailto:victor.stinner at gmail.com>> wrote:
>
>     2017-03-31 20:30 GMT+02:00 Antoine Pitrou <antoine at python.org
>     <mailto:antoine at python.org>>:
>     > Just a heads up that the following PR:
>     > https://github.com/python/cpython/pull/552/files
>     > has generated a lot of spurious PR additions on bugs.python.org
>     <http://bugs.python.org>,
>     > probably because that PR references a lot of issues
>     > (example: https://bugs.python.org/issue23839).
>     >
>     > Perhaps it would be nice to have an upper limit on the number of
>     > notified issues when the PR mentions several of them?
>     >
>     > (I'm sure someone more active than me, such as Victor or Serhiy,
>     got *a
>     > lot* of notifications from that PR :-))
>
>     Hello, I got 110 emails, something goes wrong? :-)

Each link generated an email with a message like
"pull_requests: +994" but with a different number.

> No, it's a side-effect of having Misc/NEWS pasted as a comment into a PR
> and the Roundup webhook thinking the issues were comments that warranted
> connecting the PR with the issue.

I consider this wrong ;-).

>  Either we (a) don't worry about it as
> people typically don't paste Misc/NEWS into a comment, (b) cap the
> number of possible issues in a single webhook event, or (c) don't pick
> up issue numbers from comments and only do it from PR titles.

(c), at least until we discover that there is something that needs to 
automated about numbers.

What I would like is that the BPO issue # in the PR title be a link so 
it is easy to jump from PR to BPO.

--
Terry Jan Reedy



From ezio.melotti at gmail.com  Fri Mar 31 20:20:19 2017
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Fri, 31 Mar 2017 17:20:19 -0700
Subject: [python-committers] Spurious bugs.p.o messages
In-Reply-To: <5e6c8356-7d48-afc1-d06b-5ab5bb41e7e7@udel.edu>
References: <fb9ab482-5e91-7497-5c8e-1a29c669472e@python.org>
 <CAMpsgwYGxeLWNTWYcjB1MOUuOKYpaLdaH2Xd+c+1qU5ecGFzdw@mail.gmail.com>
 <CAP1=2W5Yy-wzNfJsN4F+UTkjcaD5fmwXW+GuDHnhYN_y2B9WnQ@mail.gmail.com>
 <5e6c8356-7d48-afc1-d06b-5ab5bb41e7e7@udel.edu>
Message-ID: <CACBhJdGJMDrrqFzR+MUHJqENH3Ar+G176=nQSknHDytrXjPrbg@mail.gmail.com>

On Fri, Mar 31, 2017 at 3:59 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> On 3/31/2017 6:08 PM, Brett Cannon wrote:
>>
>>
>>
>> On Fri, 31 Mar 2017 at 12:37 Victor Stinner <victor.stinner at gmail.com
>> <mailto:victor.stinner at gmail.com>> wrote:
>>
>>     2017-03-31 20:30 GMT+02:00 Antoine Pitrou <antoine at python.org
>>     <mailto:antoine at python.org>>:
>>     > Just a heads up that the following PR:
>>     > https://github.com/python/cpython/pull/552/files
>>     > has generated a lot of spurious PR additions on bugs.python.org
>>     <http://bugs.python.org>,
>>     > probably because that PR references a lot of issues
>>     > (example: https://bugs.python.org/issue23839).
>>     >
>>     > Perhaps it would be nice to have an upper limit on the number of
>>     > notified issues when the PR mentions several of them?
>>     >
>>     > (I'm sure someone more active than me, such as Victor or Serhiy,
>>     got *a
>>     > lot* of notifications from that PR :-))
>>
>>     Hello, I got 110 emails, something goes wrong? :-)
>
>
> Each link generated an email with a message like
> "pull_requests: +994" but with a different number.
>

The range should be from pull_request826 to pull_request1113.
I tried to unlink a PR from the admin but it still generated an email.
I'm not aware of any method to unlink them without generating emails,
so If you don't mind another wave of emails, I can write a script to
go through them and unlink them from the issues, otherwise I'll just
leave them there. (It might be possible removing them from the db
directly using SQL without generating emails, but I'd rather avoid
touching the db).

>> No, it's a side-effect of having Misc/NEWS pasted as a comment into a PR
>> and the Roundup webhook thinking the issues were comments that warranted
>> connecting the PR with the issue.
>
>
> I consider this wrong ;-).
>
>>  Either we (a) don't worry about it as
>> people typically don't paste Misc/NEWS into a comment, (b) cap the
>> number of possible issues in a single webhook event, or (c) don't pick
>> up issue numbers from comments and only do it from PR titles.
>

I think adding a limit makes sense: 10 issues should probably be
enough, even for meta-issues.
I already started working on a patch, but I'm still thinking what's
the best way to implement it (e.g. limit it to the title only, to
individual messages, to all messages, etc.).

>
> (c), at least until we discover that there is something that needs to
> automated about numbers.
>
> What I would like is that the BPO issue # in the PR title be a link so it is
> easy to jump from PR to BPO.
>

There are some discussion about it, I think on the core-workflow issue tracker.
I'm not up to date, but last time I looked into it the title couldn't
be changed, but it should be possible to use a bot to convert the
issues to links in the message body.  Berker also made a browser
extension[0] that can be used in the meanwhile.

Best Regards,
Ezio Melotti

[0]: https://github.com/berkerpeksag/cpython-bpo-linkify

> --
> Terry Jan Reedy
>

From tjreedy at udel.edu  Fri Mar 31 21:18:32 2017
From: tjreedy at udel.edu (Terry Reedy)
Date: Fri, 31 Mar 2017 21:18:32 -0400
Subject: [python-committers] Spurious bugs.p.o messages
In-Reply-To: <CACBhJdGJMDrrqFzR+MUHJqENH3Ar+G176=nQSknHDytrXjPrbg@mail.gmail.com>
References: <fb9ab482-5e91-7497-5c8e-1a29c669472e@python.org>
 <CAMpsgwYGxeLWNTWYcjB1MOUuOKYpaLdaH2Xd+c+1qU5ecGFzdw@mail.gmail.com>
 <CAP1=2W5Yy-wzNfJsN4F+UTkjcaD5fmwXW+GuDHnhYN_y2B9WnQ@mail.gmail.com>
 <5e6c8356-7d48-afc1-d06b-5ab5bb41e7e7@udel.edu>
 <CACBhJdGJMDrrqFzR+MUHJqENH3Ar+G176=nQSknHDytrXjPrbg@mail.gmail.com>
Message-ID: <a9120d89-cc3a-f1c6-5887-bf354c0da8de@udel.edu>

On 3/31/2017 8:20 PM, Ezio Melotti wrote:
> On Fri, Mar 31, 2017 at 3:59 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>> On 3/31/2017 6:08 PM, Brett Cannon wrote:
>>>
>>>
>>>
>>> On Fri, 31 Mar 2017 at 12:37 Victor Stinner <victor.stinner at gmail.com
>>> <mailto:victor.stinner at gmail.com>> wrote:
>>>
>>>     2017-03-31 20:30 GMT+02:00 Antoine Pitrou <antoine at python.org
>>>     <mailto:antoine at python.org>>:
>>>     > Just a heads up that the following PR:
>>>     > https://github.com/python/cpython/pull/552/files
>>>     > has generated a lot of spurious PR additions on bugs.python.org
>>>     <http://bugs.python.org>,
>>>     > probably because that PR references a lot of issues
>>>     > (example: https://bugs.python.org/issue23839).
>>>     >
>>>     > Perhaps it would be nice to have an upper limit on the number of
>>>     > notified issues when the PR mentions several of them?
>>>     >
>>>     > (I'm sure someone more active than me, such as Victor or Serhiy,
>>>     got *a
>>>     > lot* of notifications from that PR :-))
>>>
>>>     Hello, I got 110 emails, something goes wrong? :-)
>>
>>
>> Each link generated an email with a message like
>> "pull_requests: +994" but with a different number.
>>
>
> The range should be from pull_request826 to pull_request1113.
> I tried to unlink a PR from the admin but it still generated an email.
> I'm not aware of any method to unlink them without generating emails,
> so If you don't mind another wave of emails, I can write a script to
> go through them and unlink them from the issues, otherwise I'll just

I already unlinked for https://bugs.python.org/issue25464, and it did 
generate a message.  I would rather delete another 20 emails than leave 
the junk.


From berker.peksag at gmail.com  Fri Mar 31 21:21:04 2017
From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=)
Date: Sat, 1 Apr 2017 04:21:04 +0300
Subject: [python-committers] I have blocked Wes Turner from the Python
 org on GitHub
In-Reply-To: <CAP1=2W5=ukka=32n4cUdRLs=tn059Nb9St_J-P2VR4u9Jo2E7g@mail.gmail.com>
References: <CAP1=2W5=ukka=32n4cUdRLs=tn059Nb9St_J-P2VR4u9Jo2E7g@mail.gmail.com>
Message-ID: <CAF4280LLtAsG7V2piPSQ9GwQNSW4n4YsYPDRj9j-_5n8rdqkPA@mail.gmail.com>

On Sat, Apr 1, 2017 at 12:40 AM, Brett Cannon <brett at python.org> wrote:
> In the (long) discussion of
> https://github.com/python/core-workflow/issues/6, Wes Turner began to do his
> usual posting of lists. People pointed out he was stepping out of line by
> being somewhat off-topic and seemingly lecturing folks. He posted some of
> his lists again and then I warned him that if he did it again I would block
> him for a CoC violation since he did not want to respect anyone's time by
> taking the time to edit what amount to dumping his personal notes on GitHub.
> (This is a long-standing issue, BTW, with Wes where he has been warned in
> other settings like distutils-sig about his posting behaviour.)
>
> Unfortunately he did it again for
> https://github.com/python/core-workflow/issues/66. Since GitHub only has
> organization-level blocks I have blocked him at that level (I've also
> already received some +1s from core devs while writing this email for my
> move, so I know others who have interacted with him also support this
> decision).

Thanks, Brett! I have set a filter to mark all of his emails as read
on several Python lists for a while.

--Berker

From raymond.hettinger at gmail.com  Fri Mar 31 23:44:02 2017
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Fri, 31 Mar 2017 20:44:02 -0700
Subject: [python-committers] I have blocked Wes Turner from the Python
 org on GitHub
In-Reply-To: <CAP1=2W5=ukka=32n4cUdRLs=tn059Nb9St_J-P2VR4u9Jo2E7g@mail.gmail.com>
References: <CAP1=2W5=ukka=32n4cUdRLs=tn059Nb9St_J-P2VR4u9Jo2E7g@mail.gmail.com>
Message-ID: <72E84E8D-7517-433B-9E2B-FBA513276B77@gmail.com>


> On Mar 31, 2017, at 2:40 PM, Brett Cannon <brett at python.org> wrote:
> 
> In the (long) discussion of https://github.com/python/core-workflow/issues/6, Wes Turner began to do his usual posting of lists. People pointed out he was stepping out of line by being somewhat off-topic and seemingly lecturing folks. He posted some of his lists again and then I warned him that if he did it again I would block him for a CoC violation since he did not want to respect anyone's time by taking the time to edit what amount to dumping his personal notes on GitHub. (This is a long-standing issue, BTW, with Wes where he has been warned in other settings like distutils-sig about his posting behaviour.)

FWIW, this may just be his communication style that reflects his tooling (probably emacs org-mode or some such) and his way of thinking about problems.  Even his personal web page looks like all of his posts:  https://westurner.org/pages/resume  So I don't think he was trolling, it is possible that this is just who he is and may not be something he can easily switch-off.

I don't want to second guess the decision, but we've had a lot worse issues than "being somewhat off-topic and seemingly lecturing folks" or "not taking time to edit".  To me, blocking him seems a bit extreme especially for someone who has been a part of the Python community for a number of years.

I haven't followed many of his posts (which do seem somewhat odd and not entirely coherent), so I don't possess all the facts, so perhaps this was the right thing to do.

That said, I would like to remind everyone that when the diversity statement and code-of-conduct were approved, it was done with the understanding that the primary goal was to be an open and welcoming community that emphasized tolerance of just about everything from gender identity to neuro-diversity and Aspergers.  IIRC, both the diversity statement and CoC were toned down prior to approval, as a compromise with those who were concerned about them being turned into weapons of exclusion rather than tools for inclusion.

I did look at the referenced stream of posts, https://github.com/python/core-workflow/issues/6 . The contributions from Wes Turner did seem somewhat incoherent, disjointed, not useful, and perhaps a little annoying.  I didn't see anything overtly hateful or trolling that would rise to the level of a CoC issue (i.e. it hasn't created an environment that makes others feel unwelcome).

So, if Wes is to be blocked for a while, it should be on the basis of "adding too much noise to an important communication channel" rather than CoC which should be sparingly used for only egregious issues.  Also, if a real CoC issue does arise, I think any actions taken need to have multiple assents from a group of decision makers rather than having one person become a de-facto CoC czar with the power to banish people.

my-two-cents-ly yours,


Raymond Hettinger