[python-committers] Re: Restarting individual CI runs

[Alex Gaynor]

Yes, but at least you don't have to wait 19 hours to do so (github
actions also doesn't let you restart jobs until they're all completed,
or cancelled I suppose).

Alex

On Tue, Jun 22, 2021 at 3:54 PM Guido van Rossum  wrote:
>
> That's too bad, we really should ask for this.
>
> A timeout on a job still marks it as failed, I presume, so we still have to 
> restart all jobs... :-(
>
> On Tue, Jun 22, 2021 at 12:40 PM Alex Gaynor  wrote:
>>
>> Github actions doesn't have the ability to restart individual jobs,
>> sadly (I've asked for this when they've done research sessions).
>>
>> FWIW, I'd recommend adding a timeout to jobs (it can be set in the YML
>> file), that way hung jobs don't hang for hours and hours.
>>
>> Alex
>>
>> On Tue, Jun 22, 2021 at 3:16 PM Guido van Rossum  wrote:
>> >
>> > Quite frequently I see PRs that have all but one test green, and one test 
>> > just hanging for a long time (e.g. 19 hours). It would be useful to have 
>> > the ability to restart a particular test rather than re-running all tests 
>> > (by closing and reopening the PR). Does this functionality exist? IIRC on 
>> > Travis-CI it did exist, but only for privileged users. Does GitHub Actions 
>> > have such a thing?
>> >
>> > Example: https://github.com/python/cpython/pull/25551 -- the Address 
>> > Sanitizer run has been waiting for 19 hours.
>> >
>> > --
>> > --Guido van Rossum (python.org/~guido)
>> > Pronouns: he/him (why is my pronoun here?)
>> > ___
>> > python-committers mailing list -- python-committers@python.org
>> > To unsubscribe send an email to python-committers-le...@python.org
>> > https://mail.python.org/mailman3/lists/python-committers.python.org/
>> > Message archived at 
>> > https://mail.python.org/archives/list/python-committers@python.org/message/X4KPYUNKZWLRZ5GQDZWXTE5Y4WGSHSA6/
>> > Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
>>
>>
>> --
>> All that is necessary for evil to succeed is for good people to do nothing.
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> Pronouns: he/him (why is my pronoun here?)



-- 
All that is necessary for evil to succeed is for good people to do nothing.
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/NN6PA7SHESXCVD2HBZY7U64BHJO45L32/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Restarting individual CI runs

[Alex Gaynor]

Github actions doesn't have the ability to restart individual jobs,
sadly (I've asked for this when they've done research sessions).

FWIW, I'd recommend adding a timeout to jobs (it can be set in the YML
file), that way hung jobs don't hang for hours and hours.

Alex

On Tue, Jun 22, 2021 at 3:16 PM Guido van Rossum  wrote:
>
> Quite frequently I see PRs that have all but one test green, and one test 
> just hanging for a long time (e.g. 19 hours). It would be useful to have the 
> ability to restart a particular test rather than re-running all tests (by 
> closing and reopening the PR). Does this functionality exist? IIRC on 
> Travis-CI it did exist, but only for privileged users. Does GitHub Actions 
> have such a thing?
>
> Example: https://github.com/python/cpython/pull/25551 -- the Address 
> Sanitizer run has been waiting for 19 hours.
>
> --
> --Guido van Rossum (python.org/~guido)
> Pronouns: he/him (why is my pronoun here?)
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-committers@python.org/message/X4KPYUNKZWLRZ5GQDZWXTE5Y4WGSHSA6/
> Code of Conduct: https://www.python.org/psf/codeofconduct/



-- 
All that is necessary for evil to succeed is for good people to do nothing.
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/5J56NWPR45EUK6T77G4YP2SYPRR4XVGW/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Notification of a three-month ban from Python core development

[Alex Gaynor]

It was sent to all of python-committers  as a heads up that _someone_ was
banned.

I didn't follow the thread in question, so this is all a little opaque to
me, I have no idea who we're talking about or what their conduct is. I
assume that's intentional.

Alex

On Wed, Jul 22, 2020 at 3:40 PM Ivan Levkivskyi 
wrote:

> Hi,
>
> I don't remember participating in any of the recent discussions on the
> mentioned lists. Why is this sent to me? Can you mention any particular
> posts?
> The scary atmosphere here becomes unbearable. I wasn't very active lately
> anyway, and I think I will stop contributing indefinitely.
>
> Best regards,
> Ivan
>
>
> On Wed, 22 Jul 2020 at 20:30, Python Steering Council <
> steering-coun...@python.org> wrote:
>
>> The following message was sent to a core developer. This message was
>> thoughtfully and respectfully sent by the Steering Council as a serious
>> reminder that the privilege to serve as a core developer comes with the
>> responsibility to act thoughtfully.
>>
>> ---
>>
>> Based on Code of Conduct violations in your recent mailing list posts,
>> and under the recommendation of the Code of Conduct Working Group, the
>> Python Steering Council has voted to issue a three-month corrective action
>> to you for Core Python development.
>> This corrective action bans you from all Core Development privileges
>> including commit rights, issue tracker privileges, and participation in all
>> core development communication spaces including mailing lists, Discourse,
>> and Zulip channels. This corrective action will be in effect for three
>> months. At the end of the three month period, these privileges will be
>> automatically reinstated.
>>
>> The Python Code of Conduct workgroup reviewed the conduct reports and
>> recommended that corrective action was necessary for the violations. The
>> Python Steering Council finds these violations to be serious breaches of
>> civility and expected core development conduct.
>>
>> Please consider this corrective action as a serious reminder that Python
>> core development is a privilege. This privilege to serve as a core
>> developer comes with the responsibility to act thoughtfully and reflect on
>> how hostile communications are harmful to other members of the community.
>> We trust that you will respect the temporary loss of privileges and the
>> seriousness of this action.
>>
>> Respectfully,
>> Python Steering Council
>> ___
>> python-committers mailing list -- python-committers@python.org
>> To unsubscribe send an email to python-committers-le...@python.org
>> https://mail.python.org/mailman3/lists/python-committers.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-committers@python.org/message/2HC5XPURMQL6VRCXPMLQUL7OXBGU6OMS/
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-committers@python.org/message/CLS5E634FCMB6W5H5JBLHZNSFRKKZGJG/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>


-- 
All that is necessary for evil to succeed is for good people to do nothing.
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/VW3JFOUCWVTH4GE7E7PXAMQGPJE36Y4O/
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Azure build operations

[Alex Gaynor]

There's a link that does that on _github_. (On mobile, sorry for terseness).

Alex

On Tue, May 21, 2019, 2:10 PM Antoine Pitrou  wrote:

>
> Hello,
>
> How can I restart a failed build on Azure?
>
> https://dev.azure.com/Python/cpython/_build/results?buildId=43161&view=logs&j=18d1a34d-6940-5fc1-f55b-405e2fba32b1
>
> Regards
>
> Antoine.
> ___
> 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] miss-islington backport pipeline is stalled?

[Alex Gaynor]

Would it make sense to work with the PSF infra staff so that
miss-isslington is hooked up to the PSF Sentry account so folks can get
email notifications and similar on unhandled exceptions?

Alex

On Wed, May 8, 2019 at 1:02 PM Mariatta  wrote:

> There was an error from Redis. I think this is the first time I've seen
> it, so I don't have any resolution on how to fix it right now.  😟
> I will look into handling the error and have miss-islington leave a
> comment in the PR when there is such error.
>
> log:
>
> at=info method=POST path="/" host=miss-islington.herokuapp.com 
> request_id=8de611a2-6112-4039-a425-97850ac989b0 fwd="140.82.115.15" 
> dyno=web.1 connect=1ms service=1005ms status=200 bytes=168 protocol=https
> May 08 09:35:15 miss-islington app/web.1: Traceback (most recent call last):
> May 08 09:35:15 miss-islington app/web.1:   File 
> "/app/.heroku/python/lib/python3.6/site-packages/redis/connection.py", line 
> 600, in send_packed_command
> May 08 09:35:15 miss-islington app/web.1: self._sock.sendall(item)
> May 08 09:35:15 miss-islington app/web.1: TimeoutError: [Errno 110] 
> Connection timed out
> May 08 09:35:15 miss-islington app/web.1: During handling of the above 
> exception, another exception occurred:
> May 08 09:35:15 miss-islington app/web.1: Traceback (most recent call last):
> May 08 09:35:15 miss-islington app/web.1:   File 
> "/app/.heroku/python/lib/python3.6/site-packages/kombu/connection.py", line 
> 431, in _reraise_as_library_errors
> May 08 09:35:15 miss-islington app/web.1: yield
> May 08 09:35:15 miss-islington app/web.1:   File 
> "/app/.heroku/python/lib/python3.6/site-packages/celery/app/base.py", line 
> 744, in send_task
> May 08 09:35:15 miss-islington app/web.1: self.backend.on_task_call(P, 
> task_id)
> May 08 09:35:15 miss-islington app/web.1:   File 
> "/app/.heroku/python/lib/python3.6/site-packages/celery/backends/redis.py", 
> line 265, in on_task_call
> May 08 09:35:15 miss-islington app/web.1: 
> self.result_consumer.consume_from(task_id)
> May 08 09:35:15 miss-islington app/web.1:   File 
> "/app/.heroku/python/lib/python3.6/site-packages/celery/backends/redis.py", 
> line 126, in consume_from
> May 08 09:35:15 miss-islington app/web.1: self._consume_from(task_id)
> May 08 09:35:15 miss-islington app/web.1:   File 
> "/app/.heroku/python/lib/python3.6/site-packages/celery/backends/redis.py", 
> line 132, in _consume_from
> May 08 09:35:15 miss-islington app/web.1: self._pubsub.subscribe(key)
> May 08 09:35:15 miss-islington app/web.1:   File 
> "/app/.heroku/python/lib/python3.6/site-packages/redis/client.py", line 3096, 
> in subscribe
> May 08 09:35:15 miss-islington app/web.1: ret_val = 
> self.execute_command('SUBSCRIBE', *iterkeys(new_channels))
> May 08 09:35:15 miss-islington app/web.1:   File 
> "/app/.heroku/python/lib/python3.6/site-packages/redis/client.py", line 3009, 
> in execute_command
> May 08 09:35:15 miss-islington app/web.1: self._execute(connection, 
> connection.send_command, *args)
> May 08 09:35:15 miss-islington app/web.1:   File 
> "/app/.heroku/python/lib/python3.6/site-packages/redis/client.py", line 3013, 
> in _execute
> May 08 09:35:15 miss-islington app/web.1: return command(*args)
> May 08 09:35:15 miss-islington app/web.1:   File 
> "/app/.heroku/python/lib/python3.6/site-packages/redis/connection.py", line 
> 620, in send_command
> May 08 09:35:15 miss-islington app/web.1: 
> self.send_packed_command(self.pack_command(*args))
> May 08 09:35:15 miss-islington app/web.1:   File 
> "/app/.heroku/python/lib/python3.6/site-packages/redis/connection.py", line 
> 613, in send_packed_command
> May 08 09:35:15 miss-islington app/web.1: (errno, errmsg))
> May 08 09:35:15 miss-islington app/web.1: redis.exceptions.ConnectionError: 
> Error 110 while writing to socket. Connection timed out.
>
>
>
> ᐧ
>
> On Wed, May 8, 2019 at 9:44 AM Gregory P. Smith  wrote:
>
>> Yesterday it failed to produce a backport or tell me that it couldn't
>> (after the "i'm now working on ..." message was left on the master PR).  I
>> waited a couple hours just in case and ran cherry_picker myself instead.
>> Same thing today apparently on
>> https://github.com/python/cpython/pull/13192 assuming the usual backport
>> latency is no more than a minute or two.
>>
>> -gps
>> ___
>> 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/
>


-- 
All that is necessary for evil to succeed is for good people to do nothing.
___
python-committers mailing list
python-com

Re: [python-committers] Merge with spurious CI failures?

[Alex Gaynor]

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

Thanks gps!

Alex

On Wed, May 8, 2019 at 11:58 AM Antoine Pitrou  wrote:

>
> Ok, apparently the SSL cert on self-signed.pythontest.net was changed
> but it wasn't updated in our source tree, hence the failure.
>
> Regards
>
> Antoine.
>
>
> Le 08/05/2019 à 17:49, Mariatta a écrit :
> > If you can't merge from GitHub UI then you won't be able to do it from
> > GitHub command line (it respects the same branch protection policy)
> >
> > I don't think we should merge if tests are still failing. Perhaps the
> > test should be adjusted to handle this spurious errors? Can it be marked
> > as "allowed failure" or something like that?
> >
> >
> > On Wed, May 8, 2019, 8:32 AM Antoine Pitrou  > > wrote:
> >
> >
> > Hello,
> >
> > There are spurious CI failures (SSL certificate issue in
> test_httplib).
> > Therefore the "Squash and merge" button is greyed out.
> >
> > How should I merge? Using the command-line instructions from Github?
> >
> > Regards
> >
> > Antoine.
> > ___
> > 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/
>


-- 
All that is necessary for evil to succeed is for good people to do nothing.
___
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] Merge with spurious CI failures?

[Alex Gaynor]

Tests for that PR would presumably be green :-)

Alex

On Wed, May 8, 2019 at 11:51 AM Eric V. Smith  wrote:

> Surely there must be some way around it. After all, how would you merge a
> PR to fix this test?
>
> --
> Eric V. Smith
> True Blade Systems, Inc
> (301) 859-4544
>
> On May 8, 2019, at 11:49 AM, Mariatta  wrote:
>
> If you can't merge from GitHub UI then you won't be able to do it from
> GitHub command line (it respects the same branch protection policy)
>
> I don't think we should merge if tests are still failing. Perhaps the test
> should be adjusted to handle this spurious errors? Can it be marked as
> "allowed failure" or something like that?
>
>
> On Wed, May 8, 2019, 8:32 AM Antoine Pitrou  wrote:
>
>>
>> Hello,
>>
>> There are spurious CI failures (SSL certificate issue in test_httplib).
>> Therefore the "Squash and merge" button is greyed out.
>>
>> How should I merge? Using the command-line instructions from Github?
>>
>> Regards
>>
>> Antoine.
>> ___
>> 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/
>
> ___
> 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/
>


-- 
All that is necessary for evil to succeed is for good people to do nothing.
___
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] Merge with spurious CI failures?

[Alex Gaynor]

I don't know if CPython has a specific policy about this -- other projects
I work on generally have a "we need to get master's tests passing again
before anything can merge" policy.

Alex

On Wed, May 8, 2019 at 11:44 AM Antoine Pitrou  wrote:

>
> They're deterministic.  Apparently the test which connects to
> "self-signed.pythontest.net" always fails now with a "self-signed
> certificate" error...
>
> Le 08/05/2019 à 17:37, Alex Gaynor a écrit :
> > Are these intermittent failures, or is there bustage on master right now?
> >
> > My usual habit on other projects (I'm not very active on CPython these
> > days) is to restart the build on travis so that is a nice green
> checkmark.
> >
> > Alex
> >
> > On Wed, May 8, 2019 at 11:32 AM Antoine Pitrou  > <mailto:anto...@python.org>> wrote:
> >
> >
> > Hello,
> >
> > There are spurious CI failures (SSL certificate issue in
> test_httplib).
> > Therefore the "Squash and merge" button is greyed out.
> >
> > How should I merge? Using the command-line instructions from Github?
> >
> > Regards
> >
> > Antoine.
> > ___
> > python-committers mailing list
> > python-committers@python.org <mailto:python-committers@python.org>
> > https://mail.python.org/mailman/listinfo/python-committers
> > Code of Conduct: https://www.python.org/psf/codeofconduct/
> >
> >
> >
> > --
> > All that is necessary for evil to succeed is for good people to do
> nothing.
> ___
> 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/
>


-- 
All that is necessary for evil to succeed is for good people to do nothing.
___
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] Merge with spurious CI failures?

[Alex Gaynor]

Are these intermittent failures, or is there bustage on master right now?

My usual habit on other projects (I'm not very active on CPython these
days) is to restart the build on travis so that is a nice green checkmark.

Alex

On Wed, May 8, 2019 at 11:32 AM Antoine Pitrou  wrote:

>
> Hello,
>
> There are spurious CI failures (SSL certificate issue in test_httplib).
> Therefore the "Squash and merge" button is greyed out.
>
> How should I merge? Using the command-line instructions from Github?
>
> Regards
>
> Antoine.
> ___
> 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/
>


-- 
All that is necessary for evil to succeed is for good people to do nothing.
___
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] Moderation of the Python community

[Alex Gaynor]

I think you're dramatically overestimating a) the possibility that someone
would attempt to use the CoC process frivolously, b) the possibility that
the CoC WG would act on such a complaint without good cause.

FWIW I was involved in removing a core developer from another community for
CoC violations. It was fucking exhausting, and I think basically everyone
involved was burned by the process. I cannot imagine anyone trying to
maliciously or frivolously use such a process.

Alex

On Wed, Oct 17, 2018 at 6:03 PM Victor Stinner  wrote:

> Le mer. 17 oct. 2018 à 21:09, Donald Stufft  a écrit :
> > Honestly, I think an independent group managing these issues is the
> right way to handle them. I’m loathe to bring it up because the situation
> was a long time ago, and has been resolved, but I’ve personally had to
> engage the CoC process in regards to another core developers behavior. At
> the time the way that was handled was contacting the PSF board, if the
> process was instead to contact python-committers or something I likely
> would’t have done it at all. I think it is important that if someone feels
> they’re having a problem in a particular space, that they feel they have an
> impartial and independent group of people to raise those concerns with.
> >
> > With regards to whether the CoC can evict a core developer of Python.. I
> think it absolutely needs to be able to do that. Otherwise it’s basically
> stating that it’s fine for someone to harass someone else… as long as the
> person doing the harassing is a core developer. If anything, core
> developers should be held to a higher, not a lower standard. Obviously
> excommunication is not step 1 on any CoC, and such a thing would only be
> used after a history of repeated, on going unacceptable behavior, but if
> the CoC doesn’t have any teeth, than it’s not worth the metaphorical paper
> it’s written on.
> >
> > So, when it comes to the conduct we expect from people, core developers
> should not be treated specially in either expectations nor process.
>
> Ok, now in the case of my PEP 8015: do you think that the "Python Core
> Board" should be involved in the process to evict a core developer of
> Python?
>
>https://www.python.org/dev/peps/pep-8015/#python-core-board
>
> For example, can we imagine that a core developer would only be
> evicted if the PSF conduct WG *and* the Python Core Board would agree
> to evict the core dev? Such situation should be very exceptional, and
> it may be unpopular if the conduct WG and the Python Core Board
> disagree :-(
>
> If the Python Core Board can block an eviction (have "a veto" on the
> final vote), the risk is that friends of the Board are "protected" by
> their friendship. And it also opens the question of an evicting a
> member of the Python Core Board in case of extremely severe Code of
> Conduct violation... But this question can be asked as well for
> members of the PSF conduct WG :-)
>
> I don't know the answers to my question. But maybe it would be safer
> for everyone that the *worst* case (evict a core dev) would be defined
> somewhere, as in a PEP.
>
> 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/
>


-- 
All that is necessary for evil to succeed is for good people to do nothing.
___
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] Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause)

[Alex Gaynor]

Is there a copy of the original email? (I'm not a regular python-ideas
reader)

Based on Brett's description though, the content sounds very far over the
line, and I wouldn't want to interfere with the WG's decision.

Alex

On Thu, Sep 20, 2018 at 4:25 PM Antoine Pitrou  wrote:

>
> Hi,
>
> I'm choosing to forward this to python-committers because I don't think
> python-ideas is a reasonable place to discuss CoC decisions.
>
> I think the action taken by Brett (apparently decided with Titus and a
> mysterious "conduct working group") is not the right one:
>
> - a definitive ban is an extremely strong decision that should only be
> taken if nothing else works.  May I remind that Anatoly was able to post
> prolifically and unconstructively for several years, being warned
> several times, before being finally banned?  Comparatively, this one ban
> seems expeditive.
>
> - the reasons given, to me, don't make sense at all.  The word "n-"
> is not a forbidden word if you want to describe, precisely, linguistics
> and the relativity of meanings (instead of actually *qualifying* someone
> or a groupe of people), which is what the OP claimed to do.  The other
> reasons look like a similar kind of over-reaction.  Even if something
> there looks inappropriate to you, it's still enough of a grey area that
> a ban is absolutely the wrong answer.
>
> I deduce that it's ok to say "slave" in a discussion instead of using an
> expression such as "the s-word".  Why one term is allowed and the other,
> not, may be clear to Americans (or, perhaps, a large fraction thereof),
> but hey, it's not clear to other people around the world.  Banning a
> (apparently) Dutch person because he doesn't understand American
> standards of offense is not only unfair, but it makes our community
> *not* inclusive of other cultures.
>
> As a French person myself, I could not, even if I wanted to, turn myself
> into an authentic American: what is obvious to you is not obvious to me
> and it would be extremely brutal and humiliating to ban me for having
> the wrong nationality and the wrong culture.  I will ask: please
> consider the work and effort that it *already* takes for other people to
> adapt to standards of discussion that are, obviously, those of a
> particular culture.  Otherwise you're raising barriers even more, not
> lowering them.
>
>
> At the end of it, it looks like we have a real moderation problem.
> python-ideas threads frequently veer out into unconstructive
> back-and-forths (and, well, that's not *only* the ethically-sensitive
> threads).  The CoC is being applied erratically, sometimes
> precipitately, by apparently overworked and emotionally exhausted
> moderators, with bad consequences on the quality of the decisions.
>
> Moderators should not become emotionally exhausted (which means we need
> a more adequate discussion system *and* a more collegial, spread out,
> team of moderators); and, if they become so, I would humbly suggest it's
> a better idea - even if not always easy to follow - to step back and
> take some rest than make decisions in such a state.  We also need real
> guidelines to the moderators as to which decision on the scale of
> possible decisions to apply, depending on severity of the offense /
> violation and on the "offendor"'s past behaviour.
>
> In the end, I hope we can set ourselves better moderation standards.  As
> for me, I find the current situation very worrying, including for my
> ability to contribute constructively to Python.  If I have to fear
> banning for every word that I say and that might be deemed inappropriate
> in the moderators' culture, I might just as well leave instead of
> feeling stressed and anguished everytime I post something.  I would not
> want to live this in paid work: why would I endure it as a volunteer,
> while my main gratification should be the pleasure taken in contributing?
>
> Regards
>
> Antoine.
>
>
>
> - Message Transféré -
>
> Date : Thu, 20 Sep 2018 11:56:05 -0700
> De : Brett Cannon 
> À : Jacco van Dorp 
> Cc : python-ideas 
> Groupe de discussion : gmane.comp.python.ideas
> Sujet : CoC violation (was: Retire or reword the "Beautiful is better
> than ugly" Zen clause)
>
>
> The below email was reported to the PSF board for code of conduct
> violations and then passed on to the conduct working group to decide on
> an appropriate response.
>
> Based on the WG's recommendation and after discussing it with Titus, the
> decision has been made to ban Jacco from python-ideas. Trivializing
> assault, using the n-word, and making inappropriate comments about
> someone's mental stability are all uncalled for and entirely
> unnecessary to carry on a reasonable discourse of conversation that
> remains welcoming to others.
> ___
> 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] And Now for Something Completely Different

[Alex Gaynor]

On Wed, Jul 25, 2018 at 7:24 PM Donald Stufft  wrote:

>
>
> On Jul 25, 2018, at 2:01 PM, Brett Cannon  wrote:
>
> Right, and your proposal means I now have to judge proposed core
> developers on which side of popular opinion they will come down on in hopes
> that they vote in ways I agree with and thus help take the language in a
> direction I think is appropriate.
>
>
> It makes me think a bit of the US Supreme Court, where judges who might
> someday want to be on that court, learn to be very careful about hiding
> their true opinions (without directly lying of course) on a number of very
> controversial topics, knowing that coming out for/against them is likely to
> blow up their changes of ever progressing to that point.
> ___
> 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/
>

(I've been quite on this thread thus far, just soaking everything else up,
but this side note about SCOTUS made me want to share this potentially
relevant observation/nerdery.)

Recent trends in Supreme Court nominees increasingly have justices coming
from the DC Circuit [0]. The reason for this (IMO) is that the DC Circuit
deals very heavily in parts of the law that only lawyers care about --
primarily administrative law and suits against the federal government. They
see almost no cases dealing with social issues. As a result, nominees tend
to have records without cases that will generate significant controversy
amongst the public (while still being able to demonstrate their judicial
philosophy to folks who understand such things).

The analogy in the Python-verse might be inviting a new core developer for
their work on runtime internals, but then having the ability to sway stdlib
design once they become a core dev.

This type of system stands in contrast with the one the Rust community has,
where they have dedicated teams, which people are members of (some people
are members of many), and they define the scope of the team's
responsibility/authority. So you can be a member of the compilers team,
with no say over how the community team functions.

Hope everyone enjoyed my Supreme Court nerdery,
Alex

[0]: Chief Justice Roberts, Justice Ginsburg, Justice Thomas, Judge
Garland, and Judge Kavanaugh.

-- 
All that is necessary for evil to succeed is for good people to do nothing.
___
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] I created the "needs backport to 3.7" label on GitHub

[Alex Gaynor]

Is there documentation somewhere on "how to create a release branch" that
we should add "creating a label" step to?

Alex

On Wed, Jan 31, 2018 at 6:40 PM, Mariatta Wijaya 
wrote:

> I noticed that there is a 3.7 branch now.
> So you can use this label if you want miss-islington to backport a PR to
> 3.7.
>
>
> ___
> 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/
>
>


-- 
"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
___
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] Security: please enable 2-factor authentication on GitHub and your email

[Alex Gaynor]

Thanks -- I'll pass it along to the team working on U2F at Mozilla.

Alex

On Sun, Jan 7, 2018 at 11:42 AM, Antoine Pitrou  wrote:

>
> It turns out that is a bug with Ubuntu's package for Firefox.  It works
> fine with the upstream build... :-(
>
> https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1741768
>
> Regards
>
> Antoine.
>
>
> Le 06/01/2018 à 20:42, Barry Warsaw a écrit :
> > On Jan 6, 2018, at 14:00, Alex Gaynor  wrote:
> >>
> >> Hey Antoine,
> >>
> >> Assuming you're on Firefox57, it requires a pref -- once the WebAuthn
> spec is finalized we'll drop the pref -- https://mobile.twitter.com/
> jamespugjones/status/91231495223226
> >
> > Oh wow, this is exciting!  I’ve been annoyed by the lack of support for
> my Yubikey in FF57, but I just enabled these and quick check by logging
> into GH seems to show that it works, at least for some sites.  Thanks for
> the link.
> >
> > -Barry
> >
>
>


-- 
"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
___
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] Security: please enable 2-factor authentication on GitHub and your email

[Alex Gaynor]

Hey Antoine,

Assuming you're on Firefox57, it requires a pref -- once the WebAuthn spec
is finalized we'll drop the pref --
https://mobile.twitter.com/jamespugjones/status/91231495223226

Alex

On Sat, Jan 6, 2018 at 1:59 PM, Antoine Pitrou  wrote:

>
> Hi,
>
> So, for the record (even though this discussion has petered out), I've
> just bought a U2F key and it doesn't work on Ubuntu Firefox (though it
> works on Chromium).  So it's pretty much unusable for me.
>
> Regards
>
> Antoine.
> ___
> 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/
>



-- 
"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
___
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] How to force Travis to re-run?

[Alex Gaynor]

If you look at the travis-ui, do you see little "restart" arrows (example
attached)? Those are what do it -- I went ahead and restarted the failed
job on this one.

Alex

On Sat, Jan 6, 2018 at 11:43 AM, Eric V. Smith  wrote:

> I'm trying to merge this: https://github.com/python/cpython/pull/5113
>
> Travis failed, but not due to something in this PR (looks like a random
> networking failure). How do I trigger the Travis check to re-run? Or I
> guess just skipping it would be okay as a last resort, but I'd really like
> to try re-running it first.
>
> 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/
>



-- 
"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
___
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] Security: please enable 2-factor authentication on GitHub and your email

[Alex Gaynor]

They require a preference to be enabled, but yeah, Security Keys in Firefox
Quantum 🎉
https://mobile.twitter.com/jamespugjones/status/91231495223226

Alex

On Tue, Dec 12, 2017 at 11:21 AM, Antoine Pitrou  wrote:

>
> If some people are inclined to push for 2FA, I think it would be more
> productive to write some kind of document giving advice and suggestions
> and addressing all potential issues (such as backups, cross-platform
> compatibility, software integration with various tools, etc.).  For
> example I have 2FA enabled on Github but I just learned that U2F keys
> are supposed to work with Firefox 57.0.
>
> Regards
>
> Antoine.
>
>
> Le 12/12/2017 à 17:12, Brett Cannon a écrit :
> >
> >
> > On Tue, Dec 12, 2017, 05:07 M.-A. Lemburg,  > > wrote:
> >
> > I'm with David on this one. 2FA is good for admin accounts, but
> > doesn't add much protection for regular committers. Think of what
> > you're trying to protect against: git checkins are all audited and
> > can easily be undone.
> >
> >
> > But David has an admin account for the repo. 😉 Anyway, it sounds like
> > we're not going to force this in anyone, but perhaps it might be worth
> > considering for admin accounts since they control whether force pushes
> > are possible.
> >
> > -brett
> >
> >
> > --
> > Marc-Andre Lemburg
> > eGenix.com
> >
> > Professional Python Services directly from the Experts (#1, Dec 12
> 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@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/
> >
> ___
> 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/
>



-- 
"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
___
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] Security: please enable 2-factor authentication on GitHub and your email

[Alex Gaynor]

The reason for the username-then-a-new-page-for-password flow in many cases
is that the sites have multiple flows depending on your username! The GMail
login page for example can send you to either the password page since
you're a consumer account, the password page because you're a GSuite
account using Google login, an off-site page since you're a GSuite using
SAML. (This is ignoring the need to choose 2FA flows -- TOTP vs SMS vs
Security Key!)

Alex

On Mon, Dec 11, 2017 at 3:11 PM, R. David Murray 
wrote:

> On Mon, 11 Dec 2017 14:52:54 -0500, "R. David Murray" <
> rdmur...@bitdance.com> wrote:
> > Indeed.  If 2fa is required for contribution to CPython, I'll stop
> > contributing.  Granted, I haven't done many merges lately, but a few
> > is a bigger number than zero :)
>
> And in case you think this means I don't consider security important:
> I have been using strong, unique-per-site passwords (and in many cases
> unique usernames/emails) for many years, and I run my own email server.
>
> --David
>
> Aside: something I have never understood is the relatively recent
> craze for enter-username-first-then-go-to-password-screen.  Most of the
> implementations I have encountered tell you if the username is unknown.
> That reduces the cracker's search space by a considerable amount.  Using
> your email address as the account id has the same problem, magnified.
> I had already started using unique usernames/emails before that trend
> happened, to battle spam, but it certainly reinforced my motivation for
> doing so.  I unfortunately haven't gotten around to backfilling a lot
> of the sites I did sign up to using my primary email address :(
> ___
> 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/
>



-- 
"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
___
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] Security: please enable 2-factor authentication on GitHub and your email

[Alex Gaynor]

It's possible to generate a key on a regular computer and transfer it to a
YubiKey if you prefer. (It's not like software key generation has been
flawless either; [OpenSSL/Debian fiasco]. Oh well, such is life).

Even if you're not going to put your SSH keys on a YubiKey, I _strongly_
encourage folks to get a Security Key (aka U2F device), of which YubiKeys
are one brand, and use it for 2FA with Google/Github/Facebook/etc. In
addition to (IMO) being more usable than Google Authenticator, Security
Keys are resistant to phishing, which is a huge win.

Alex

On Mon, Dec 11, 2017 at 7:57 AM, Stefan Krah  wrote:

> On Mon, Dec 11, 2017 at 01:47:50PM +0100, Victor Stinner wrote:
> > 2017-12-11 13:29 GMT+01:00 Stefan Krah :
> > > Ssh isn't available everywhere, I don't want to install an app or give
> > > out my phone number to half of Silicon Valley [1].
> >
> > SMS and FreeOTP are just a few options that you have to generate/get OTP.
> >
> > I suggest to use Yubikey. It doesn't need to install an app or to give
> > your phone number, but it costs 50$. The advantage is that you can use
> > it to store your SSH and GPG keys.
>
>
> I'm not a fan of hardware key generation. :-)
>
>
> https://en.wikipedia.org/wiki/YubiKey
>
> "In October 2017, security researchers found a vulnerability (known as
> ROCA) in the implementation of RSA keypair generation in a cryptographic
> library used by a large number of Infineon security chips. The
> vulnerability allows an attacker to reconstruct the private key by using
> the public key.[18][19] All YubiKey 4, YubiKey 4C, and YubiKey 4 nano
> within the revisions 4.2.6 to 4.3.4 are affected by this vulnerability.[20]
> Yubico publicized a tool to check if a Yubikey is affected and replaces
> affected tokens for free.[21]"
>
>
>
>
> ___
> 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/
>



-- 
"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
___
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] Adding Ivan Levkivskyi as a core committer

[Alex Gaynor]

Someone needs to invite him to this list :-)

On Dec 6, 2017 11:44 AM, "Guido van Rossum"  wrote:

> I think I figured it out -- I invited him to the python org on GitHub.
> Anything else?
>
> On Wed, Dec 6, 2017 at 8:37 AM, Guido van Rossum  wrote:
>
>> OK, let's make it so. It's been a long time since I initiated a new
>> committer -- what has to happen next? I just flipped his committer bit on
>> bpo, is there anything else that needs to happen?
>>
>> On Wed, Dec 6, 2017 at 8:27 AM, Yury Selivanov 
>> wrote:
>>
>>> +1 from me.  I first had an idea to give Ivan commit privileges when I
>>> was merging his PEP 526 implementation, so I think it's long overdue.
>>>
>>> Yury
>>>
>>> On Tue, Dec 5, 2017 at 8:00 PM, Guido van Rossum 
>>> wrote:
>>> > I'd like to propose Ivan Levkivskyi as a new core committer. He's
>>> > (re-)written most of the typing.py module and will do so again for
>>> Python
>>> > 3.7, he's the sole or primary author on several PEPs (526, 544, 560,
>>> 562),
>>> > is co-author on several more (483, 561) and has been acknowledged in
>>> yet
>>> > others (557, 563).
>>> >
>>> > He is responsible for at least 16 commits in master.
>>> >
>>> > I have worked with him for a long time on typing.py and on mypy (where
>>> he is
>>> > a core dev) and I can vouch for him completely.
>>> >
>>> > --
>>> > --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/
>>> >
>>>
>>
>>
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>>
>
>
>
> --
> --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/
>
>
___
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] Enabling depreciation warnings feature code cutoff

[Alex Gaynor]

I also feel this decision was a mistake. If there's a consensus to revert,
I'm happy to draft a PEP.

Alex

On Nov 6, 2017 1:58 PM, "Neil Schemenauer"  wrote:

> On 2017-11-06, Nick Coghlan wrote:
> > Gah, seven years on from Python 2.7's release, I still get caught by
> > that. I'm tempted to propose we reverse that decision and go back to
> > enabling them by default :P
>
> Either enable them by default or make them really easy to enable for
> development evironments.  I think some setting of the PYTHONWARNINGS
> evironment variable should do it.  It is not obvious to me how to do
> it though.  Maybe there should be an environment variable that does
> it more directly.  E.g.
>
> PYTHONWARNDEPRECATED=1
>
> Another idea is to have venv to turn them on by default or, based on
> a command-line option, do it.  Or, maybe the unit testing frameworks
> should turn on the warnings when they run.
>
> The current "disabled by default" behavior is obviously not working
> very well.  I had them turned on for a while and found quite a
> number of warnings in what are otherwise high-quality Python
> packages.  Obviously the vast majority of developers don't have them
> turned on.
>
> Regards,
>
>   Neil
> ___
> 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] Merging a PR with failed CI

[Alex Gaynor]

On other projects I work on, my usual practice is to restart the Travis job
and wait for it to pass.

Alex

On Sun, Oct 22, 2017 at 1:48 PM, Antoine Pitrou  wrote:

>
> Hello,
>
> What is the recommended way of merging a PR when Travis-CI failed for
> unrelated reasons? (apparently an external NNTP server is having hiccups)
>
> See https://github.com/python/cpython/pull/4065
>
> Regards
>
> Antoine.
> ___
> 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/
>



-- 
"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
___
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] OK to back-fill "awaiting" labels on open issues?

[Alex Gaynor]

Can we please use a phrase for re-triggering a review that makes more sense
like "I've updated the patch, please re-review", rather than magic inside
baseball language?

Alex

On Fri, Oct 6, 2017 at 5:29 PM, Brett Cannon  wrote:

> I noticed today that out of about 19 pages of issues, only the first 5
> have "awaiting" labels. Would people object if I back-filled those open
> issues lacking an "awaiting" label? For those that have a "changes
> requested" review a comment that said roughly "we noticed there's a review
> asking for changes; if you already did that then let us know by saying 'I
> didn't expect the Spanish Inquisition' and we will update this pull request
> accordingly" (the other stages don't have potential false-positives).
>
> The reason I'm asking before coding this up and running it is there will
> be some churn in notifications for those issues that get a comment about
> "awaiting changes".
>
> ___
> 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/
>
>


-- 
"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
___
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] Travis CI: macOS is now blocking -- remove macOS from Travis CI?

[Alex Gaynor]

If you find a macOS CI platform with more capacity, please let me know :-)

Travis has been totally underwater of late, but I don't know of any
alternatives; probably because operating a fleet of macOS builders is a
giant pain. You need Apple hardware, and it turns out you can either
purchase a trashcan or a mac mini, and neither of those is really designed
for a server farm.

If anyone here can magically whisper in Tim Cook's ear, can you ask him to
license macOS to AWS or Google Cloud or something?

:-(,
Alex

On Tue, Sep 19, 2017 at 7:02 PM, Brett Cannon  wrote:

>
>
> On Tue, 19 Sep 2017 at 15:04 Barry Warsaw  wrote:
>
>> On Sep 19, 2017, at 15:32, Victor Stinner 
>> wrote:
>> >
>> > The macOS job has been removed from Travis CI at the beginnig of the
>> > CPython sprint two weeks ago. Since the macOS build was removed, I'm
>> > less annoyed by Travis CI: it seems more stable.
>> >
>> > Are you ok to not add again the macOS job to Travis CI?
>> >
>> > Again, my rationale is that we already have 3 macOS buildbots and I'm
>> > looking closely at all buildbot failures. I try to keep track of *all*
>> > failures, even random failure. A recent macOS example:
>> > https://bugs.python.org/issue31510
>> >
>> > Sadly, remaining random failures are the most rare and most difficult
>> > to reproduce. (I fixed a lot of them last months.)
>>
>> If the macOS tests aren’t stable, then yes, removing them is better than
>> frustrating developers who can’t reproduce CI failures, even on the CI
>> machines let alone their own development boxes.
>>
>> I forget though, was it a problem with macOS CI stability or general
>> throughput?  I thought they just couldn’t keep up with the workload, in
>> which case it seems like we should be able to throw more resources at it,
>> right?
>>
>
> If it is a Travis issue then there are no more resources to throw at it
> from a Travis perspective: what they are already providing us is rather
> large and paying out of pocket is rather costly. The only other option is
> to find another CI provider who has macOS support and use them just for
> that platform.
>
> ___
> 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/
>
>


-- 
"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
___
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] Cherry picker bot deployed in CPython repo

[Alex Gaynor]

This is a great UX win for our development process. Thanks for making this
happen!

Alex

On Tue, Sep 5, 2017 at 9:10 PM, Mariatta Wijaya 
wrote:

> Hi,
>
> The cherry picker bot has just been deployed to CPython repo, codenamed
> miss-islington.
>
> miss-islington made the very first backport PR for CPython and became a
> first time GitHub contributor: https://github.com/python/cpython/pull/3369
>
>
> GitHub repo: https://github.com/python/miss-islington
>
> What is this?
> ==
>
> As part of our workflow, quite often changes made on the master branch
> need to be backported to the earlier versions. (for example: from master to
> 3.6 and 2.7)
>
> Previously the backport has to be done manually by either a core developer
> or the original PR author.
>
> With the bot, the backport PR is created automatically after the PR has
> been merged. A core developer will need to review the backport PR.
>
> The issue was tracked in https://github.com/python/core-workflow/issues/8
>
> How it works
> ==
>
> 1. If a PR needs to be backported to one of the maintenance branches, a
> core developer should apply the "needs backport to X.Y" label. Do this
> **before** you merge the PR.
>
> 2. Merge the PR
>
> 3. miss-islington will leave a comment on the PR, saying it is working on
> backporting the PR.
>
> 4. If there's no merge conflict, the PR should be created momentarily.
>
> 5. Review the backport PR created by miss-islington and merge it when
> you're ready.
>
> Merge Conflicts / Problems?
> ==
>
> In case of merge conflicts, or if a backport PR was not created within 2
> minutes, it likely failed and you should do the backport manually.
>
> Manual backport can be done using cherry_picker: https://pypi.
> org/project/cherry-picker/
>
> Older merged PRs not yet backported?
> ==
>
> At the moment, those need to be backported manually.
>
> Don't want PR to be backported by a bot?
> 
>
> My recommendation is to apply the "needs backport to X.Y" **after** the PR
> has been merged. The label is still useful to remind ourselves that this PR
> still needs backporting.
>
> Who is Miss Islington?
> =
>
> I found out from Wikipedia that Miss Islington is the name of the witch in
> Monty Python and The Holy Grail.
>
> miss-islington has not signed the CLA!
> =
>
> A core dev can ignore the warning and merge the PR anyway.
>
> Thanks!
>
>
> Mariatta Wijaya
>
> ___
> 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/
>
>


-- 
"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
___
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] mention-bot is dead, long live the (misnamed) CODEOWNERS file!

[Alex Gaynor]

The other big advantage to using teams is that they'll automatically apply
to all branches.

Alex

On Tue, Aug 1, 2017 at 6:23 PM, Barry Warsaw  wrote:

> On Aug 1, 2017, at 17:09, Christian Heimes  wrote:
>
> > Marietta, Brett, thanks for your work!
>
> Indeed!
>
> > I suggested teams to make the file a bit easier to maintain. The rule
> > format works differently than the old mentionbot format. In the old
> > format we had a relationship user -> files. The new CODEOWNERS format
> > has files -> users mapping with last rules trumps all semantic. We have
> > to be careful to not override parts of a previous rules. I believe teams
> > reduce the burden.
>
> Using teams would also reduce conflicts on changes to CODEOWNERS.  We’d
> need only specify the teams and then can use the GH u/i to manage team
> membership.
>
> -Barry
>
>
> ___
> 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/
>
>


-- 
"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
___
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 tests failing for CPython?

[Alex Gaynor]

Great, thanks for digging in!

Alex

On Mon, May 29, 2017 at 2:46 PM, Zachary Ware 
wrote:

> On Mon, May 29, 2017 at 9:19 AM, Zachary Ware
>  wrote:
> > On Mon, May 29, 2017 at 9:09 AM, Alex Gaynor 
> wrote:
> >> Hi all,
> >>
> >> It looks like appveyor tests are currently failing on all builds
> (something
> >> about UNC paths + imports). Was appveyor enabled recently, or did the
> test
> >> regress?
> >
> > AppVeyor has been enabled for some time, but is not (yet) required.
> > It's possible that something has regressed, but it looks kind of like
> > AppVeyor changed something in the environment, particularly since all
> > of our Windows buildbots are fine.
>
> AppVeyor is investigating, see
> https://appveyor.tenderapp.com/discussions/problems/6765-
> environmental-change-blocking-unc-path-access
> for updates.
>
> --
> Zach
>



-- 
"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
___
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] Appveyor tests failing for CPython?

[Alex Gaynor]

Hi all,

It looks like appveyor tests are currently failing on all builds (something
about UNC paths + imports). Was appveyor enabled recently, or did the test
regress?

Alex

-- 
"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
___
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 Carol Willing to become a core developer

[Alex Gaynor]

Carol's also served on the PSF board of directors for a number of years. +1

Alex

On Tue, May 23, 2017 at 2:15 PM, Brett Cannon  wrote:

> While at the PyCon US sprints the idea came up of offering Carol Willing
> developer privileges. Everyone at the table -- about 6 of us -- liked the
> idea and Carol also said she would happy to become a core dev, so I'm
> officially putting her forward for consideration.
>
> For those of you who don't know Carol, she basically knows our developer
> workflow better than most of us. :) ; she's very active on the devguide and
> core-mentorship. Carol has also attended the PyCon US language summit two
> years in a row as a representative for the Jupyter project. She is actually
> so good with new people that she managed to get my wife to make her first
> open source contribution (something I never managed to do).
>
> As usual, if you support/object to this idea, please say so. :)
>
> ___
> 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/
>
>


-- 
"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
___
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] No Travis-CI on OS X?

[Alex Gaynor]

Travis's macOS builds aren't as slow as they used to be, between them
adding capacity and our queue increase.

Alex

On Tue, May 2, 2017 at 5:38 PM, Antoine Pitrou  wrote:

>
>
> Is there a way to get faster OS X builds with our connections at Travis-CI?
> I agree that OS X builds are usually very slow (though it depends on
> daytime, see https://www.traviscistatus.com/#week), but perhaps it's
> possible to improve on that :-)
>
> Regards
>
> Antoine.
>
>
> Le 02/05/2017 à 23:37, Donald Stufft a écrit :
> >
> >
> >> On May 2, 2017, at 5:35 PM, Antoine Pitrou  >> > wrote:
> >>
> >>
> >> Hi,
> >>
> >> Perhaps it would be possible to set up a Travis CI matrix entry for OS
> >> X, those builds are often quite slow but at least it could be part of
> >> the "allowed failures" suite.  That would help detect platform issues at
> >> PR time rather than later :-)
> >>
> >
> >
> > I think the only reason we don’t have them on is because the macOS
> > builds on Travis are _Super_ slow and regularly get a large backlog.
> > Fast Finish and Allowed Failures would help with that though.
> >
> > —
> > Donald Stufft
> >
> >
> >
> ___
> 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/
>



-- 
"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
___
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] I have blocked Wes Turner from the Python org on GitHub

[Alex Gaynor]

I'll be another voice saying that the CoC isn't the right mechanism -- the
CoC is for harassment and abuse (at least, most community's CoCs are, the
Python one is pretty vague).

That said, I have no problem with the action taken, banning people who are
extremely unproductive is a necessary step for open source communities, and
one I think we are all extremely reticent to take, so much so that it got
it's own chapter in the excellent book, Producing Open Source Software:
http://producingoss.com/en/difficult-people.html

Back to lurking'ly yours,
Alex

On Sat, Apr 1, 2017 at 2:35 PM, Brett Cannon  wrote:

>
>
> On Sat, 1 Apr 2017 at 09:27 M.-A. Lemburg  wrote:
>
>> On 01.04.2017 05:44, Raymond Hettinger wrote:
>> >
>> >> On Mar 31, 2017, at 2:40 PM, Brett Cannon  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.)
>> >
>> > ...
>> > 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.
>>
>> It's definitely a requirement of any CoC management to have at
>> least two people decide on this, since CoCs in general are
>> always open to interpretation and need to take multiple views
>> into account.
>
>
> OK, but who is the second person supposed to be? Since this was the
> core-workflow issue tracker for the core-workflow mailing list I figured it
> fell on to my shoulders to deal with (I actually had to check the mailing
> list this morning to see if I even had co-owners on it since I actually
> didn't remember explicitly having any). Am I to ask just any core dev for a
> gut check to make sure this is a reasonable action to take?
>
> I guess my point is that we don't have any form of policy or practices in
> place for this sort of thing. An action of this level has (fortunately)
> only occurred with Anatoly and we took so long to deal with it that no one
> questioned my actions when I first used the CoC on python-ideas.
>
>
>> Wes's comments are nowhere near a CoC violation,
>> IMO.
>>
>
> There's also extensive history spanning multiple mailing lists for Wes'
> behaviour. This isn't isolated to just what I linked to, it just happens to
> be what finally pushed me to take action. If I could block him at my
> personal account level and have his posts not show up for me I would, or if
> I could just block him for the core-workflow issue tracker I would, but we
> just  don't have that level of blocking on GitHub and the finest grain
> available is organization level.
>
>
>>
>> I agree with Raymond that CoCs are not meant as a tool to
>> silence people with different ideas or communication styles
>> out of convenience.
>>
>
> Now we're getting into a philosophical discussion as to whether the CoC
> covers people who choose to continually communicate in an unproductive  way
> even after it has been pointed out to them that they are not contributing
> constructively to the conversation (as Paul more eloquently stated). To me
> the CoC covers that as part of requiring people to be respectful of others.
> Time is one of those things that I can't get back and which we all have a
> limited supply of to spend on this project, so having someone suck it away
> in small doses regularly even after they have been told by multiple people
> that they are not contributing seems like a CoC violation to me.
>
>
>>
>> It's the ultimate tool, not the first to consider.
>
>
> It wasn't my first anything. As I have said, this isn't some isolated
> incident in the Python community with Wes. And I didn't do this on a whim.
> I literally felt like crap for about an hour after hitting the red "Block"
> button because I realize the ramifications of what I did, so please don't
> think I just had a bad day and decided to take it out on someone or did
> this just because I didn't like someone's four messages on GitHub.
>
>
>> If Wes were
>> continuously offensive that would be a reason to start discussing
>> CoC related actions.
>>
>
> As I said, this spans at least distutils-sig and python-ideas for years
> (to the point that I have had his emails being marked as re

Re: [python-committers] 4 weeks with the new workflow: what needs changing?

[Alex Gaynor]

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  wrote:

>
>
> On Mon, 13 Mar 2017 at 10:04 Donald Stufft  wrote:
>
>>
>> On Mar 13, 2017, at 11:54 AM, Barry Warsaw  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@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
___
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] 4 weeks with the new workflow: what needs changing?

[Alex Gaynor]

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  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@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
___
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] Disable Codecov on GitHub pull requests?

[Alex Gaynor]

I'm obviously not very active in CPython development these days, but
actively tracking the impact of each PR on coverage has been extremely
useful in every other project I've worked on.

It's the best way to automatically ensure PRs are not regressing coverage
too much, and doesn't require much manual work. FWIW, on projects I've
worked on we have turned off the codecov "comments", and instead just rely
on the status checker.

Alex

On Mon, Feb 13, 2017 at 9:49 AM, Victor Stinner 
wrote:

> Hi,
>
> I don't get the value of code coverage on a CI. I *like* running code
> coverage sometimes, but I don't like being annoying by "test failed:
> coverage -0,01%" by a change completely unrelated to code (note: this
> issue has been fixed be using a threshold of 1%). I'm annoyed by all
> these Codecov messages. Berker just told me that he even created a
> Gmail filter to drop all these email notifications...
>
> What do you think of keeping this very useful feature, but not use it
> on pull requests: only run it on the branches (once changes are
> merged), to not "pollute" pull requests?
>
> 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/
>



-- 
"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
___
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] We will be moving to GitHub (hopefully) in 2016

[Alex Gaynor]

Probably the easiest thing is to point the linkifier at our own webservice
that just does:

if hash not in cache:
try:
 requests.head("github.com/hash")
 except requests.error:
 try:
request.head("hg.python.org/hash")
 except request.error:
return 404
 else:
cache[hash] = hg.python.org
 else:
 cache[hash] = github
return cache[hash]


I'll send you my consulting bill :-)
Alex

On Mon, Jan 4, 2016 at 8:33 PM, R. David Murray 
wrote:

> On Tue, 05 Jan 2016 01:26:58 +, "Gregory P. Smith" 
> wrote:
> > On Mon, Jan 4, 2016 at 12:34 PM R. David Murray 
> > wrote:
> >
> > > to have to do some extra work to make the hash links work in the bug
> > > tracker, since I don't think there's any a priori way to distinguish
> > > between hg hashes and git hashes.
> > >
> >
> > Just ignore the remote possibility of short 32-bit hash prefix collisions
> > (possible, but infrequent): the way to resolve that is when a hash lookup
> > fails, to look it up in a translation index of former hg hashes.
> >  practical.  good enough.
>
> Yes, collision is not the problem, it's that you can't distinguish them
> without a lookup table or something.  Which means we have to do more
> than just change the URL in the existing linkifier, which was my point.
>
> --David
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
>



-- 
"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: 125F 5C67 DFE9 4084
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] We will be moving to GitHub (hopefully) in 2016

[Alex Gaynor]

My git clone is 350MB (after a make clean), a fresh hg clone is 650MB.

Alex

On Mon, Jan 4, 2016 at 5:38 PM, Georg Brandl  wrote:

> On 01/01/2016 08:24 PM, Brett Cannon wrote:
> > If you want to read the reasons I chose GitHub over GitLab,
> > see
> https://mail.python.org/pipermail/core-workflow/2016-January/000345.html .
> > If you want to discuss the decision or help with the transition, please
> > subscribe to the core-workflow mailing list.
> >
> > Happy 2016 everyone, and here is to hoping we will have an easier
> developer
> > workflow by the end of this year!
>
> Thanks for pioneering all the work and discussion needed to come to this
> decision.
>
> I think that in combination with a homu-style bot we can get a very nice
> improved workflow going.
>
> Georg
>
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
>



-- 
"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: 125F 5C67 DFE9 4084
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] We will be moving to GitHub (hopefully) in 2016

[Alex Gaynor]

+1

Alex

On Mon, Jan 4, 2016 at 4:07 PM, Donald Stufft  wrote:

>
> > On Jan 4, 2016, at 3:51 PM, Barry Warsaw  wrote:
> >
> > I once looked at it and decided it wasn't something I wanted to touch ;)
> so
> > paying Eric to do it might not be a bad idea.
>
>
> I’d prefer it if we didn’t financially support ESR since he likes to spout
> off racist and misogynistic garbage. I’m sure we can figure out how to
> successfully migrate from Hg to git. I’ve already done it once on the demo
> repo, if that’s not good enough I’ll work on it some more if need be.
>
> -
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
> DCFA
>
>
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
>
>


-- 
"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: 125F 5C67 DFE9 4084
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Github accounts (was: formalising retirement as a Python committer)

[Alex Gaynor]

For Django this has literally never come up.

Alex

On Sat, Jan 2, 2016 at 1:24 PM, Brett Cannon  wrote:

> Another idea I had is could someone reach out to another project like
> Django or Go that switched to GitHub and see how they handled this
> situation for contributors? I don't feel I'm in a good position to ask
> about this since I personally don't have this issue so I don't think I
> could judge what would be an acceptable solution beyond the paid micro
> account solution.
>
> On Sat, 2 Jan 2016 at 09:49 Brett Cannon  wrote:
>
>> On Sat, 2 Jan 2016 at 07:14 Nick Coghlan  wrote:
>>
>>> On 3 January 2016 at 00:12, Paul Moore  wrote:
>>> > On 2 January 2016 at 13:46, M.-A. Lemburg  wrote:
>>> >> I guess the PSF could refund any Github charges incurred to
>>> >> remedy the situation. Their smallest plan is USD 7 per month
>>> >> and account, so that would mean costs of USD 84 per year and
>>> >> committer - this certainly within range of what the PSF can
>>> >> provide without problem.
>>> >
>>> > Alternatively, would it be worth reaching out to Github to ask if they
>>> > would be willing to allow an exception? The condition seems intended
>>> > to disallow spamming or camping of accounts, which clearly isn't the
>>> > case here.
>>> >
>>> > Note: I have no direct interest in this, as I only use my github
>>> > account for personal activities, so the issue doesn't affect me.
>>>
>>> I use my own GitHub account for both personal projects and for work,
>>> but Red Hat's open source contribution policies are probably the most
>>> liberal on the planet, so I don't have any need to separate them.
>>>
>>
>> Ditto for me and Microsoft.
>>
>>
>>>
>>> However, it's also the case that if an employer is simultaneously:
>>>
>>> 1. Expecting employees to maintain a clear separation between personal
>>> and paid activity on GitHub; and
>>> 2. Refusing to pay for dedicated GitHub work accounts for their employees
>>>
>>> Then there's a contradiction between their expectations and their
>>> failure to provide employees with the resources needed to meet those
>>> expectations.
>>>
>>
>> I also know of people whose company is being mean to them by saying "we
>> expect you to use your single free account for us and it's your problem if
>> you want a clean separation because we're too cheap to pay for your own
>> account" getting around this by ignoring the ToS restriction. Obviously not
>> everyone will feel comfortable doing that, but I have never known anyone to
>> have their GitHub account shut down because they had separate work and
>> personal accounts that were both on the free tier.
>>
>> But as MAL said, the PSF could easily cover the fee for a core dev to get
>> a paid micro account if someone felt they really wanted it.
>>
>
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
>
>


-- 
"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: 125F 5C67 DFE9 4084
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] We will be moving to GitHub (hopefully) in 2016

[Alex Gaynor]

Brett (and everyone else),

Thanks so much for all the time you put into working through this decision!

Alex

On Fri, Jan 1, 2016 at 2:24 PM, Brett Cannon  wrote:

> If you want to read the reasons I chose GitHub over GitLab, see
> https://mail.python.org/pipermail/core-workflow/2016-January/000345.html .
> If you want to discuss the decision or help with the transition, please
> subscribe to the core-workflow mailing list.
>
> Happy 2016 everyone, and here is to hoping we will have an easier
> developer workflow by the end of this year!
>
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
>
>


-- 
"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: 125F 5C67 DFE9 4084
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Contact info for possible workflow tool security issue

[Alex Gaynor]

security@ seems like the right address, since at a minimum we have all the
people who'll know where to route the issue to.

Alex


On Thu, Jun 19, 2014 at 6:32 PM, Benjamin Peterson 
wrote:

> On Thu, Jun 19, 2014, at 18:23, Antoine Pitrou wrote:
> >
> >
> > Le 19/06/2014 21:13, Nick Coghlan a écrit :
> > > A colleague spotted a possible security issue with one of the CPython
> > > workflow tools (specifically with the configuration of our
> > > installation, rather than with the upstream project), and would like
> > > to know where to report it securely.
> > >
> > > Currently the developer guide covers CPython itself
> > > (secur...@python.org), and infrastruct...@python.org is the likely
> > > place for the main PSF infrastructure, but it isn't clear where such
> > > problems with the CPython worfklow tools should be reported.
> >
> > I think security@ is fine.
> > infrastructure@ is not, since anyone can read it.
>
> There's also infrastructure-st...@python.org, which is private, but they
> don't own much of the CPython developer infra. If it's the tracker, for
> example, you're better off emailing Martin/bitdancer/Ezio privately.
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
>



-- 
"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: 125F 5C67 DFE9 4084
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

[python-committers] Brian Kearns for commit

[Alex Gaynor]

Hi all,

I'd like to propose Brian Kearns for commit. He's been a committer on PyPy
for about a year and a half now, and in particular he's done a bunch of
"Python version" works: things like upgrading us from the 2.7.3 stdlib to
the 2.7.6 stdlib, and py3k work. He's interested in having commit for the
purposes of doing interop work on the stdlib tests: things like making sure
tests aren't reliant on refcounting, correctly marking tests as impl
details, etc.

Thanks,
Alex

-- 
"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: 125F 5C67 DFE9 4084
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] LCA2014 presentation on Zuul, OpenStack's merge gating system

[Alex Gaynor]

While I'm not a particularly active python-developer, I have spent quite a
bit of time using OpenStack's Zuul/gerrit system/workflow and all I can say
is it: It is the right way to write software. Huge +1 from me on every
project using it :-)

Alex


On Sat, Jan 18, 2014 at 11:34 PM, Nick Coghlan  wrote:

> One of the items I have on the language summit agenda is the core
> reviewer workflow used by the OpenStack project, specifically Zuul,
> the merge gating system that powers that workflow. I know some other
> folks here are working on OpenStack these days so this will already be
> familiar to them, but many aren't. I'm not either, but my day job
> involves developing CI workflow automation tools for Red Hat, so I'm
> paying very close attention to what the OpenStack infrastructure team
> are up to.
>
> We don't necessarily have to wait until the language summit to discuss
> it though, so I figured I'd pass along a link to James Blair's
> presentation at linux.conf.au 2014:
>
> Stream: https://www.youtube.com/watch?v=sLD9LHc1QFM
> Download:
> http://mirror.linux.org.au/linux.conf.au/2014/Friday/106-How_OpenStack_Improves_Code_Quality_with_Project_Gating_and_Zuul_-_James_Blair.mp4
>
> The Zuul docs are at: http://ci.openstack.org/zuul/
> The OpenStack Zuul dashboard is at: http://status.openstack.org/zuul/
>
> The key difference, relative to our current workflow, is to take the
> human out of the loop for the final pre-merge test run. Instead, once
> a core reviewer gives a patch a +2, the process of taking that
> reviewed patch, checking it still merges correctly, checking it passes
> all the tests on the stable buildbots and then merging it into source
> control would all be handled automatically by Zuul.
>
> This will require and/or enable eliminating several of the current
> annoyances in the core development workflow:
>
> - the annoyingly manual "download patch, apply patch, run tests
> locally, commit change, push change, watch the buildbots for problems"
> approach goes away entirely (while what we have now is substantially
> better than what we had a few years ago, times move on and projects
> like OpenStack raise the bar when it comes to figuring out how to make
> the most effective of scarce contributor time)
> - spurious conflicts on NEWS will go away (as we'll have to finally
> address this in order to avoid breaking Zuul's gating)
> - push races will go away (since merging would now be handled by Zuul,
> non conflicting changes would be rebased automatically, and only
> conflicting changes would be bounced back to the submitter for
> updates). Critically, conference sprints might create a backlog in
> Zuul, but they wouldn't completely break a developer's workflow
> through incessant push races relating to non-conflicting changes.
> - POSIX developers breaking the Windows buildbots and vice-versa
> (since Zuul would ensure at least the stable buildbots remain green by
> blocking such changes before they hit the main branches). This means
> even when we get such things wrong, we will no longer have the time
> pressure of needing to unbreak other people's builds.
> - approving and merging pure docs patches should become largely
> trivial, as it should be possible to configure Zuul to only check that
> the docs build cleanly for those, rather than running the full test
> suite across all the stable buildbots.
> - checking for a contributor licensing agreement in Roundup before
> processing a patch could also be automated, rather than requiring core
> developers to check for it manually.
>
> Zuul, as OpenStack use it, already has plugins for the Gerrit code
> review/git repo management system (at least as customised by the
> OpenStack infrastructure folks), as well as for Jenkins to run the
> automated CI tests.
>
> Rather than suggesting wholesale changes to our own infrastructure,
> what I am suggesting we consider is devoting time (and potentially PSF
> funding) to getting Zuul to play nice with Roundup, Reitveld, BuildBot
> and Mercurial. (Like the rest of our existing infrastructure, Zuul is
> a web service implemented in Python).
>
> The main technical challenges I foresee are:
>
> * dealing with maintenance branches (especially for patches which
> don't merge forward cleanly), since OpenStack currently appear to
> "handle" that limitation by just not providing upstream maintenance
> branches at all, leaving downstream vendors to fill the gap
> * finally cleaning up the way we manage the NEWS file (see
> http://bugs.python.org/issue18967 for discussion)
> * replicating Gerrit's patch approval/voting mechanism in Reitveld
> * replicating Gerrit's merge/rebase capabilities in Mercurial (I'm
> sure Mercurial is functionally capable of this, I just don't know the
> best way to model it).
> * actually writing the new Zuul plugins to talk to the services used
> by the CPython project, rather than those used by OpenStack
>
> There would also be a non-trivial update to the developer guide
> involve

Re: [python-committers] Anatoly has been warned about his behaviour potentially leading to his loss of tracker privileges

[Alex Gaynor]

These steps sound right to me. Make the notification a private email, not a
public one -- this doesn't have to be a big deal. It's not a warning shot
to other people, this is one isolated individual, and we should treat it as
such.

Alex


On Sat, Nov 30, 2013 at 1:44 AM, Nick Coghlan  wrote:

> On 30 November 2013 15:23, Guido van Rossum  wrote:
> > Nick,
> >
> > I think we've seen the issue from every possible side now. I trust your
> > judgment that he has pulled this trick once too many times. So please
> > implement the ban. Or wait until the next infraction -- that's up to you.
> > Either way, since the archives of this list are public, our deliberations
> > will stand up to scrutiny.
> >
> > My offer to mediate (*after* he's been banned) stands, but it's up to
> you if
> > and how you want to mention that to Anatoly.
>
> OK, moving on to mechanics, here's what I would like to propose:
>
> - flip his moderation bit on the mailing lists, at least for
> python-dev, python-ideas and distutils-sig (are there any other lists
> where his presence is considered disruptive?).
>
> - revoke his tracker privileges. If he would like something done on
> the tracker, he can ask Guido or Ezio to make the change on his
> behalf.
>
> I'm willing to be the bearer of bad news, and let Anatoly know this is
> being done, and cc' Guido and Ezio (as I'll also pass along their
> offers of assistance).
>
> Regards,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
>



-- 
"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: 125F 5C67 DFE9 4084
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Anatoly Techtonik's contribution (again)

[Alex Gaynor]

I'm not sure if it's because I'm reading the lists more, or if he's
actually posting more, but I definitely seem to see him more frequently.
And almost none of it is positive contribution, it's almost entirely people
wasting time trying to humor him. I'm honestly not sure I've ever seen a
discussion with him add value to the community.

Karl Fogel's book, "Producing Open Source Software", has heavily influenced
my thinking here (http://producingoss.com/en/difficult-people.html), but I
think we ought to reconsider banning him from the mailing lists that we run.

Alex


On Fri, Nov 29, 2013 at 9:07 AM, Antoine Pitrou  wrote:

>
> Hello,
>
> I'm a bit curious, but do people think Anatoly is now behaving more
> constructively than before? He does seem to post *less*, otherwise...
>
> After all, he's just sent another rant about the "community process" in
> which the word CLA seems to appear multiple times:
> https://mail.python.org/pipermail/python-dev/2013-November/130632.html
>
> Regards
>
> Antoine.
>
>
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
>



-- 
"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: 125F 5C67 DFE9 4084
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Python bug bounty

[Alex Gaynor]

Yes, we probably should. The Django project was contacted by them, I've
we've been working with them to set up a workflow, when I saw this I'd
assumed someone had been contacted for CPython.

Alex


On Thu, Nov 7, 2013 at 3:24 AM, Christian Heimes wrote:

> Am 07.11.2013 11:45, schrieb M.-A. Lemburg:
> > On 07.11.2013 11:40, Christian Heimes wrote:
> >> Hi,
> >>
> >> this is going through the news right now. Has anybody contact us about
> >> the bug bounty program for Python?
> >>
> >>   https://hackerone.com/python
> >
> > FWIW, the PSF was not contacted about this in advance.
> >
> > Sounds like a nice project, though.
>
> The PSRT wasn't contacted either.
>
> I like it, it's a great idea! It just came as a surprise to me. Should
> we contact them and establish a work flow?
>
> Christian
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
>



-- 
"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: 125F 5C67 DFE9 4084
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] PEP commit privilieges for Donald Stufft?

[Alex Gaynor]

+1 from me, Donald is doing awesome work in this area.

Alex


On Wed, Aug 14, 2013 at 9:49 AM, Nick Coghlan  wrote:

> Donald is the current main developer for PyPI and is doing a lot of
> work on PyPI related PEPs this days - it would reduce the
> administrative overhead if he could update the related PEPs directly.
>
> Any objections to my getting him to send his public SSH key to
> hgaccounts for inclusion?
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> python-committers mailing list
> python-committers@python.org
> http://mail.python.org/mailman/listinfo/python-committers
>



-- 
"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: 125F 5C67 DFE9 4084
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] PyCon US 2013 attendees

[Alex Gaynor]

I'll be there for the summit, conference, and murphy willing sprints.

Alex


On Mon, Feb 25, 2013 at 11:14 AM, Eli Bendersky  wrote:

>
>
>
> On Mon, Feb 25, 2013 at 11:00 AM, Chris Jerdonek  > wrote:
>
>> Is the attendee list for next March's PyCon available to registrants?
>> What core developers are attending?  Maybe members of this list that
>> are going can reply to this e-mail, or someone more familiar with the
>> speaker list can at least start the list off.
>>
>> I'm attending.
>>
>>
> I plan to attend the language summit and conference. Not sure about the
> sprints yet.
>
> Eli
>
>
> ___
> python-committers mailing list
> python-committers@python.org
> http://mail.python.org/mailman/listinfo/python-committers
>
>


-- 
"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
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Python Language Summit at PyCon US

[Alex Gaynor]

On Tue, Jan 10, 2012 at 7:04 AM, Michael Foord wrote:

> Hello Python Committers,
>
> As usual we will hold a Python Language Summit before the PyCon US
> conference.
>
> The language summit will be in the conference hotel, to discuss the
> ongoing development of the Python language. It will be held on the
>  *Wednesday* before the conference (Wednesday 7th March), a change from
> previous years.
>
> The language summit is an invite only event. All Python core developers,
> plus selected others, are invited. If you would like to attend, for all or
> part of the day, please respond off list to me so I can keep a track of
> numbers.
>
> If you have topics you would like to see on the agenda please also let me
> know.
>
> I'll send more details on the event, times and the location within the
> venue, nearer the date.
>
> All the best,
>
> Michael Foord
>
> --
> http://www.voidspace.org.uk/
>
>
> May you do good and not evil
> May you find forgiveness for yourself and forgive others
> May you share freely, never taking more than you give.
> -- the sqlite blessing
> http://www.sqlite.org/different.html
>
>
>
>
>
> ___
> python-committers mailing list
> python-committers@python.org
> http://mail.python.org/mailman/listinfo/python-committers
>

Hey Michael,

I'd love to attend.

Alex

-- 
"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
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Recording committer status in the bug tracker

[Alex Gaynor]

On Tue, Mar 15, 2011 at 11:22 PM, "Martin v. Löwis" wrote:

> I added a boolean flag to the bug tracker indicating what user accounts
> belong to committers. Please check that the flag is set in Your Details,
> Is Committer. If it's not, please let me know.
>
> Regards,
> Martin
> ___
> python-committers mailing list
> python-committers@python.org
> http://mail.python.org/mailman/listinfo/python-committers
>

I'm not showing as a committer (also not showing as CLA received, but I
suppose that's different).

Alex

-- 
"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
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers