Re: [python-committers] Proposing Mark Shannon to be a core developer

[Guido van Rossum]

Thanks Mariatta!

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

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

On Tue, May 15, 2018 at 4:51 PM, Mariatta Wijaya 
wrote:

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


-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Proposing Mark Shannon to be a core developer

[Mariatta Wijaya]

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

On Tue, May 15, 2018, 11:35 AM Guido van Rossum  wrote:

> Let's stop the email barrage, Mark is in. Can someone tell Mark what to do?
>
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] AppVeyor and Travis-CI

[Terry Reedy]

I am getting repeated bogus failures, completely unrelated to a trivial 
patch, more often than not, on Travis-CI

For instance,
https://travis-ci.org/python/cpython/jobs/379349709
2 tests failed:
test_asyncio test_multiprocessing_forkserver
1 test altered the execution environment:
test_importlib

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

tjr
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] AppVeyor and Travis-CI

[Guido van Rossum]

IIUC you have to close and reopen the PR.

On Tue, May 15, 2018 at 11:35 AM, Eric V. Smith  wrote:

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



-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] AppVeyor and Travis-CI

[Brett Cannon]

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

On Mon, 14 May 2018 at 21:50 Eric V. Smith  wrote:

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

Re: [python-committers] AppVeyor and Travis-CI

[Eric V. Smith]

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

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


On 5/15/18 11:23 AM, Brett Cannon wrote:

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

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

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

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

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

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

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

==
FAIL: test_stdin_broken_pipe
(test.test_asyncio.test_subprocess.SubprocessSafeWatcherTests)
--
Traceback (most recent call last):
   File

"/home/travis/build/python/cpython/Lib/test/test_asyncio/test_subprocess.py",

line 214, in test_stdin_broken_pipe
 self.loop.run_until_complete, coro)
AssertionError: (, ) not raised by run_until_complete
--

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

Thanks.
Eric
___
python-committers mailing list
python-committers@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@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Proposing Mark Shannon to be a core developer

[Guido van Rossum]

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

On Tue, May 15, 2018 at 12:27 AM, Victor Stinner 
wrote:

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



-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Idea: Create subteams?

[Andrew Svetlov]

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

On Thu, Apr 26, 2018, 17:32 Yury Selivanov  wrote:

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

[python-committers] FINAL WEEK FOR 3.7.0 CHANGES!

[Ned Deily]

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

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

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

Release Managerly Yours,
--Ned

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

--
  Ned Deily
  n...@python.org -- []

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/