[python-committers] Re: Performance benchmarks for 3.9

[Chris Jerdonek]

MOn Wed, Oct 14, 2020 at 8:03 AM Pablo Galindo Salgado 
wrote:

> > Would it be possible rerun the tests with the current
> setup for say the last 1000 revisions or perhaps a subset of these
> (e.g. every 10th revision) to try to binary search for the revision which
> introduced the change ?
>
> Every run takes 1-2 h so doing 1000 would be certainly time-consuming :)
>

Would it be possible instead to run git-bisect for only a _particular_
benchmark? It seems that may be all that’s needed to track down particular
regressions. Also, if e.g. git-bisect is used it wouldn’t be every e.g.
10th revision but rather O(log(n)) revisions.

—Chris




That's why from now on I am trying to invest in daily builds for master,
> so we can answer that exact question if we detect regressions in the
> future.
>
>
> On Wed, 14 Oct 2020 at 15:04, M.-A. Lemburg  wrote:
>
>> On 14.10.2020 16:00, Pablo Galindo Salgado wrote:
>> >> Would it be possible to get the data for older runs back, so that
>> > it's easier to find the changes which caused the slowdown ?
>> >
>> > Unfortunately no. The reasons are that that data was misleading because
>> > different points were computed with a different version of
>> pyperformance and
>> > therefore with different packages (and therefore different code). So
>> the points
>> > could not be compared among themselves.
>> >
>> > Also, past data didn't include 3.9 commits because the data gathering
>> was not
>> > automated and it didn't run in a long time :(
>>
>> Make sense.
>>
>> Would it be possible rerun the tests with the current
>> setup for say the last 1000 revisions or perhaps a subset of these
>> (e.g. every 10th revision) to try to binary search for the revision which
>> introduced the change ?
>>
>> > On Wed, 14 Oct 2020 at 14:57, M.-A. Lemburg > > > wrote:
>> >
>> > Hi Pablo,
>> >
>> > thanks for pointing this out.
>> >
>> > Would it be possible to get the data for older runs back, so that
>> > it's easier to find the changes which caused the slowdown ?
>> >
>> > Going to the timeline, it seems that the system only has data
>> > for Oct 14 (today):
>> >
>> >
>> https://speed.python.org/timeline/#/?exe=12&ben=regex_dna&env=1&revs=1000&equid=off&quarts=on&extr=on&base=none
>> >
>> > In addition to unpack_sequence, the regex_dna test has slowed
>> > down a lot compared to Py3.8.
>> >
>> >
>> https://github.com/python/pyperformance/blob/master/pyperformance/benchmarks/bm_unpack_sequence.py
>> >
>> https://github.com/python/pyperformance/blob/master/pyperformance/benchmarks/bm_regex_dna.py
>> >
>> > Thanks.
>> >
>> > On 14.10.2020 15:16, Pablo Galindo Salgado wrote:
>> > > Hi!
>> > >
>> > > I have updated the branch benchmarks in the pyperformance server
>> and now they
>> > > include 3.9. There are
>> > > some benchmarks that are faster but on the other hand some
>> benchmarks are
>> > > substantially slower, pointing
>> > > at a possible performance regression in 3.9 in some aspects. In
>> particular
>> > some
>> > > tests like "unpack sequence" are
>> > > almost 20% slower. As there are some other tests were 3.9 is
>> faster, is
>> > not fair
>> > > to conclude that 3.9 is slower, but
>> > > this is something we should look into in my opinion.
>> > >
>> > > You can check these benchmarks I am talking about by:
>> > >
>> > > * Go here: https://speed.python.org/comparison/
>> > > * In the left bar, select "lto-pgo latest in branch '3.9'" and
>> "lto-pgo latest
>> > > in branch '3.8'"
>> > > * To better read the plot, I would recommend to select a
>> "Normalization"
>> > to the
>> > > 3.8 branch (this is in the top part of the page)
>> > >and to check the "horizontal" checkbox.
>> > >
>> > > These benchmarks are very stable: I have executed them several
>> times over the
>> > > weekend yielding the same results and,
>> > > more importantly, they are being executed on a server specially
>> prepared to
>> > > running reproducible benchmarks: CPU affinity,
>> > > CPU isolation, CPU pinning for NUMA nodes, CPU frequency is
>> fixed, CPU
>> > governor
>> > > set to performance mode, IRQ affinity is
>> > > disabled for the benchmarking CPU nodes...etc so you can trust
>> these numbers.
>> > >
>> > > I kindly suggest for everyone interested in trying to improve the
>> 3.9 (and
>> > > master) performance, to review these benchmarks
>> > > and try to identify the problems and fix them or to find what
>> changes
>> > introduced
>> > > the regressions in the first place. All benchmarks
>> > > are the ones being executed by the pyperformance suite
>> > > (https://github.com/python/pyperformance) so you can execute them
>> > > locally if you need to.
>> > >
>> > > ---
>> > >
>> > > On a related note, I am also working on the speed.python.org
>> > 

Re: [python-committers] If you care about the voting method, please vote ; -)

[Chris Jerdonek]

On Fri, Nov 2, 2018 at 5:09 PM Tim Peters  wrote:
>
> [Chris Jerdonek ]
> > It would have been nice to know beforehand if the results of the poll
> > were going to change the PEP.
>
> Don't look at me ;-)  Like I said, "I'm not in charge of anything",
> and I had no input in changing PEP 8001 beyond contributing to the
> message thread, same as everyone else.

My reply was to Brett and not to you. If I had known the poll was
going to be binding, I could have made an effort to participate in the
discussion and try to sway people. As it was, the discussion was
started and dominated by people who were against IRV. They are the
most motivated to change things, and they're also the ones most
motivated to participate in the poll. I couldn't afford to participate
in such a discussion otherwise, as I said in the discussion. There are
already 98 messages -- many of which are lengthy -- not to mention
messages in other threads. It would take a lot of time and emotional
energy to engage in such a discussion.

--Chris



> I viewed the poll as being
> informational, to get a sense of how people felt about the issues.
> Apparently someone actually in charge of the PEP thought consensus was
> "clear enough", presumably in part because of the poll results, but
> also presumably because of the quite extensive following discussion
> (of which the poll results can fairly be said to be representative).
>
> > I didn't participate because I didn't feel like the poll had a fair
> > process like the PEP's themselves.
>
> Which you've already said in the discuss.python.org thread.  So,
> mentally, when I viewed the poll, I added one vote to IRV for you.  I
> don't know whether Brett did too, but IRV was trailing too much for it
> to make a material difference.
>
> As above, I expect it was really the discussion that drove the
> decision, of which the poll results were but a summary.  But October
> is over, so Brett can speak for himself now ;-)
___
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] If you care about the voting method, please vote ; -)

[Chris Jerdonek]

It would have been nice to know beforehand if the results of the poll
were going to change the PEP. I didn't participate because I didn't
feel like the poll had a fair process like the PEP's themselves.

--Chris

On Fri, Nov 2, 2018 at 3:21 PM Brett Cannon  wrote:
>
> FYI I just updated PEP 8001 with the result of the poll which very clearly 
> favoured the Condorcet method for winner selection.
>
> On Tue, 30 Oct 2018 at 12:52, Tim Peters  wrote:
>>
>> There's a poll about the voting method to use to decide on the winning
>> governance PEP.  We'd like to see more people weigh in:
>>
>> https://discuss.python.org/t/python-governance-electoral-system/290/26
>>
>> PEP 8001 specifies that IRV will be used.  There's pushback against
>> that.  Since a poll is a form of approval voting, there's also
>> pushback against using a poll to vote on the voting method.  But we
>> really don't have the time to pursue infinite regress to its end ;-)
>>
>> I'm not in charge of anything, so take this for what it's worth:  pick
>> the option(s) that are closest to what you can live with, but add a
>> comment to the poll if there's some aspect of what you vote for that
>> you really can't abide (e.g., at least one person said they would vote
>> for Approval, _except_ that they object to getting the PSF Board
>> involved in case there's a tie).  The high-order bit of this poll is
>> about the basic approaches people can live with, not details of how
>> problem cases are handled.
>> ___
>> 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/

Re: [python-committers] Vote on governance will happen between Nov 16 - Nov 30

[Chris Jerdonek]

On Tue, Oct 23, 2018 at 10:46 AM Antoine Pitrou  wrote:
> Le 23/10/2018 à 18:05, Tim Peters a écrit :
> > The rangevoting site has a great deal of info about all sorts of voting
> > systems.  Over a decade ago, Ka-Ping Yee (who used to be very active in
> > Python development) ran some _visual_ voting simulations on 5 popular
> > systems, which scared him (& me) away from IRV forever:
> >
> > http://zesty.ca/voting/sim/
>
> Thanks!  This is a great resource.  I agree that IRV looks scary, while
> Approval or Condorcet look reasonable IMHO.

A major problem with approval voting IMO (and range and score) is that
it constrains how voters can express themselves:

If you really like one candidate but your second choice is so-so but
better than the third, do you "approve" of your second choice? If you
do, you'll be helping to defeat the candidate you really like. So as a
voter your hands are artificially tied.

Regarding Tim's point about IRV and third parties, what third parties
in the US *really* want is proportional representation. PR is much
harder to make progress towards here, but still possible.

One reason third parties support IRV is that it can be a huge
challenge even to be "qualified" (i.e. recognized) as an official
party in many states. Some states require parties to get a certain
threshold of voter support at a statewide election (e.g. have a
candidate win at least 5%). Plurality makes this much harder because
of the spoiler effect / wasted vote dynamics. With IRV, the idea is
that parties will be able to see their true support.

Another reason some advocates favor IRV is that it's a special case
(the n=1 case) of single transferable voting (STV). This is a form of
PR that many advocates feel would be a lot easier to take hold in the
US than, say, the party list systems more common in Europe and
elsewhere. Indeed, over twenty cities in the US once used STV in the
earlier parts of the 20th century. (But it was eventually repealed in
all but one city, in part because of its success in electing minority
candidates.)

--Chris
___
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] python-committers is dead, long live discuss.python.org

[Chris Jerdonek]

Great, thank you!
--Chris



On Wed, Oct 3, 2018 at 3:44 AM Berker Peksağ 
wrote:

> On Wed, Oct 3, 2018 at 1:06 PM Chris Jerdonek 
> wrote:
> > Hi Łukasz, I tried signing up three days ago, but it doesn't look like
> I've been approved yet (e.g. I'm not listed in the members list). I notice
> some other people have been approved during this time based on the group
> count. I tried emailing you privately about this a couple days ago, too.
>
> Hi Chris,
>
> I've just added you to the group.
>
> --Berker
> ___
> 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] python-committers is dead, long live discuss.python.org

[Chris Jerdonek]

On Fri, Sep 28, 2018 at 4:47 PM Łukasz Langa  wrote:

> On 28 Sep 2018, at 23:55, Chris Jerdonek  wrote:
>
> I hope this thread about transitioning is exempt from this call to action!
> :)
>
> This e-mail is specifically re-posted on Discourse so you can discuss it
> there, too :-)
>

Hi Łukasz, I tried signing up three days ago, but it doesn't look like I've
been approved yet (e.g. I'm not listed in the members list). I notice some
other people have been approved during this time based on the group count.
I tried emailing you privately about this a couple days ago, too.

Thanks for any help,
--Chris



- Ł
___
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] python-committers is dead, long live discuss.python.org

[Chris Jerdonek]

On Fri, Sep 28, 2018 at 2:45 PM, Łukasz Langa  wrote:

> There is a user trust system where proven community members get more power
> in time, for example to fix typos and move topics to a better category.
>

Will committers start out as "proven," or will we need to "re-prove"
ourselves to gain additional privileges? How is the trust evaluation
bootstrapped in Python's case, and who can confer additional trust (e.g.
can it be non-committers, etc)?


*CALL TO ACTION*
> We'd like to heavily test this new forum. As such, I would like to ask you
> to *NOT USE* python-committers for the remainder of the year and direct
> all conversation to Discourse.
>

I hope this thread about transitioning is exempt from this call to action!
:)

--Chris


On Fri, Sep 28, 2018 at 2:45 PM, Łukasz Langa  wrote:

> Hello committers,
> since this got pretty long, here's the tl;dr:
>
> - we're at the point where it is hard to make mailing lists work for us;
> - we're switching to Discourse; it's better in many ways;
> - go to https://discuss.python.org/ and create your account there;
> - please do not post to python-committers for the remainder of the year to
> give Discourse a real shot.
>
> And now the long version.
>
> *What's the issue?*
> During the core sprint in Redmond we discussed how we discuss. The
> overwhelming feel is that we have reached the limits of what is possible
> with mailing lists. We identified e-mail as a contributor to some of the
> problems we're dealing with now. To fix more and whine less, I talked with
> everybody in Redmond about a possible replacement for the trusty mailing
> list. We identified one: Discourse.
>
> *What is it?*
> Discourse is forum software started in 2013 by Jeff Atwood, Robin Ward,
> and Sam Saffron. It's used by many large scale open source projects and
> companies, including Github Atom, Twitter Developers, Rust, Kotlin, Elixir,
> Docker, Codeacademy, Patreon, EVE Online, and Imgur. It's open source
> (Ruby, GPL2), it supports plugins and has an API.
>
> *Why is it better than e-mail?*
> It's both a Web app and a terrific mobile application. It supports regular
> flat conversational threads and collapsible replies. There is community
> moderation where users can flag inappropriate messages to notify
> moderators, moderators and authors can lock topics, move discussions
> between categories, archive things that are no longer applicable, and so on.
>
> You can edit posts, quote posts, link between posts, add rich media, code
> snippets with syntax highlighting, there's Markdown support. You can still
> use it via e-mail similarly to how GitHub notifications work. See:
> https://meta.discourse.org/t/set-up-reply-via-email-support/14003
>
> There is a user trust system where proven community members get more power
> in time, for example to fix typos and move topics to a better category.
>
> There's much more: dynamic notifications, topic summaries, emojis, spam
> blocking, single sing-on, two-factor authentication, social login support,
> and so on. Read: https://meta.discourse.org/t/discourse-vs-email-
> mailing-lists/54298.
>
> *What about Zulip?*
> Zulip is chat software which some of us find useful but its UI is proving
> to be challenging for many of us, the mobile application leaves a lot to be
> desired, and it did not end up moving discussions out of the mailing lists.
> I see Zulip as replacement for IRC whereas Discourse is replacement for
> mailing lists (or both; we'll see!).
>
> *Where do I sign up?*
> Create an account at https://discuss.python.org/. You'll recognize the
> set up as essentially mirroring the main mailing lists:
> - Committers
> - Users
> - Ideas
> There's also Discourse-specific sections:
> - Discourse Feedback (post here if things don't work like you'd like)
> - Discourse Staff (hidden category for moderators and admins of the
> instance, boring discussion)
> - Inquisition (hidden category for users with trust level 3+)
>
> As you can see, I combined python-committers and python-dev into just
> "Committers". If we find in the future that this is too limiting, we can
> always open up another category. For now though I'd like to avoid the fate
> of python-dev where there's 20k+ subscribers and we don't know who is who.
>
> *CALL TO ACTION*
> We'd like to heavily test this new forum. As such, I would like to ask you
> to *NOT USE* python-committers for the remainder of the year and direct
> all conversation to Discourse.
>
> The goal to replace the mailing lists with Discourse met unanimous support
> at the core sprint. As long as we don't identify any deal breakers in
> October, I will send an e-mail like this to python-dev on November 1st, and
> to python-list and python-ideas on December 1st. If everything goes
> smoothly, those four mailing lists will be archived by end of this year.
> Other mailing lists are welcome to port over to Discourse too.
>
> *Acknowledgements*
> Pablo and Ernest worked on setting up this instance for us (thank you
> both! 

Re: [python-committers] Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause)

[Chris Jerdonek]

FWIW, as an American I don't think it's appropriate to spell out the
n-word in a mailing list, even if it's not being directed at anybody
or even just being used as an example. There's no need, and it can
only cause discomfort or worse.

--Chris


On Thu, Sep 20, 2018 at 3:35 PM, Ethan Furman  wrote:
> On 09/20/2018 02:17 PM, Brett Cannon wrote:
>
>> I will also say I didn't voice an opinion or participate in the discussion
>> on the conduct WG when deciding how to handle
>> it (beyond outlining our levels of escalation when handling these
>> situations).
>
>
> One thing missing from the ban notification is the length of time?  If this
> is the first offense it should only be two months, right?
>
> And I have to argue against his use of the n-word* as being part of the
> reason -- he wasn't calling anybody that, he was using the word as an
> example of a taboo in one culture that is not in others.  Using that as part
> of the reason to ban him helps me understand the sentiment voiced at the
> sprints of the feeling that the CoC is a weapon waiting to shoot us down.
>
> I fully appreciate the frustration of trying to moderate these lists with
> our limited tools, but we still need to be careful of the reasons we use for
> moderation actions.
>
> Does the CoC WG have an email address?  I'm happy to forward my concerns to
> them about their decision.
>
> --
> ~Ethan~
>
>
> * Before this I wouldn't have spelled out the n-word anyway, but now I'm
> afraid to.
>
> ___
> 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] An alternative governance model

[Chris Jerdonek]

I agree a name other than BDFL should be chosen, especially since (as
I understand it) Guido is still BDFL but just taking a permanent
vacation, and the name implies there should only be one.

Also, if we're considering particular people, I think Nick should also
be considered.

Should the position be decided before starting to decide who should
fill it, though, or should it be decided with a particular person in
mind? I feel like doing the former might be better, because that way
we can also come up with the process for choosing the person, which
we'll need at some point anyways.

--Chris



On Tue, Jul 17, 2018 at 10:55 PM, Kushal Das  wrote:
> On Wed, Jul 18, 2018 at 11:17 AM Tim Peters  wrote:
>>
>>
>> [Barry Warsaw]
>>>
>>> ...
>>>
>>> * We retain a singular BDFL to lead Python
>>> * A Council is selected to serve as advisors to the BDFL, a selection 
>>> committee for succession, and a check against the BDFL.
>>
>>
> +1 to this idea including Brett as BDFL. Though I am wondering if
> anyone asked Brett about it?
>
>> You made a fine case for that a single dictator is the best possible 
>> approach, for much the same reasons Emacs is the best possible editor.  +1
>>
>>> Brett Cannon
>>
>>
>> Not my first choice, but ... yup, I got the email back.  Kim Jong Un is too 
>> busy providing field guidance to potato farms and trolley manufacturers this 
>> year :-(
>>
>> So that leaves Brett!  However, to secure my full enthusiastic support he'll 
>> first need to pledge to make porting Python to Red Star OS[1] his #1 BDFL 
>> priority.  Since a committee or a (ugh!) democracy would never do that, it 
>> would prove he has the pigheadedness required to be an effective dictator ;-)
>>
>
> Red Star OS has Python in it iirc :) Means less work for Brett.
>
>
> Kushal
> --
> Staff, Freedom of the Press Foundation
> CPython Core Developer
> Director, Python Software Foundation
> https://kushaldas.in
> ___
> 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] An alternative governance model

[Chris Jerdonek]

I apologize if this has already been mentioned on a different thread,
but something else I like about the BDFL model is that it avoids
"design by committee." I think Python owes a lot of its success to its
coherence as a language, which is in large part due to Guido's vision,
as well as making the hard decisions along the way.

Of course, it will be hard to fill his shoes, but fortunately we have
many good people to choose from.

The BDFL is in some ways the human embodiment of the Zen of Python, in
that they're the last line of defense to ensure Python remains true to
its Zen.

--Chris


On Tue, Jul 17, 2018 at 8:33 PM, Alex Martelli via python-committers
 wrote:
> Barry, you offer truly compelling arguments for a new BDFL as GvR's
> successor -- FWIW, you've convinced me.
>
> And Brett would be an absolutely outstanding pick as that "new BDFL" -- on
> this, I need no convincing.
>
>
> Alex
>
> On Tue, Jul 17, 2018 at 7:08 PM Barry Warsaw  wrote:
>>
>> I’d like to propose an alternative model, and with it a succession plan,
>> that IMHO hasn’t gotten enough discussion.  It’s fairly radical in that it
>> proposes to not actually change that much!
>>
>> TL;DR: I propose keeping a singular BDFL and adding a Council of Advisors
>> that helps the BDFL in various capacities, with additional responsibilities.
>> I also have someone specific in mind for the NBDFL, but you’ll have to read
>> on for the big reveal.
>>
>> Why keep a singular BDFL?  I think it’s clear that no one can completely
>> replace Guido, and neither should we try, nor do we need to.  The discussion
>> to date has explored refactoring many of the roles that the BDFL has, and
>> that’s all excellent, especially to reduce the burden and burnout factor of
>> the NBDFL.  But I think having a singular BDFL making the tough decisions,
>> with the support and help of the community, is in the best interests of
>> Python over the long term.
>>
>> A singular BDFL provides clear leadership.  With a council of elders, it
>> will be more difficult to communicate both to the Python community, and to
>> the larger, more peripheral user base, that any particular individual has
>> the authority to make decisions.  Regardless of size, there would ultimately
>> be some one person communicating any council decision.  There will
>> inevitably be ambiguity as to the authority of said decision.  How will
>> folks, especially on the periphery, know that Alice Jones or Bob Smith are
>> members of the council and can speak authoritatively on decisions for the
>> language?  “Bob Smith, on Behalf of the GUIDO” is IMHO less obviously and
>> unquestionably authoritative than “Alice Jones, BDFL”.
>>
>> This also comes into play for shutting down discussions early.  With a
>> committee, it’s possible that you’ll have some disagreement among the
>> members as to whether a discussion is fruitful or not, whether it rehashes
>> settled questions, or whether the change fits into the overall direction for
>> Python’s evolution.  Alice Jones may say “No, that’s not gonna happen” only
>> to be overruled or undermined by Bob Smith’s “That’s a good idea”.
>>
>> Taken together, these fall under the umbrella of having one voice for the
>> decision making process.  It may be possible for consensus within the
>> council to come across as a single voice, but I think it will generally be
>> harder.  A council also opens the door for more back-channel lobbying of a
>> sympathetic member.  Yes, such lobbying is possible with a BDFL, but at
>> least there should be less contention.
>>
>> I also think a council will be much more risk adverse than a singular
>> BDFL, and that’s not necessarily a good thing.  While moratoriums and a more
>> conservative approach to change may be appropriate at times, I would prefer
>> those to be deliberate decisions for a specific purpose, rather than the
>> unintended outcome of groupthink or lack of consensus.  A singular BDFL with
>> support from the community will have more authority to make decisions which
>> probably will never be universally accepted, and much less prone to vapor
>> lock due to lack of consensus or internal bickering.
>>
>> I hope Guido won’t mind me relating a comment of his that has really
>> resonated with me over the last few days, and for which I think a singular
>> BDFL will be much more adept at communicating and shepherding.  The question
>> for any new leader is:
>>
>> What is your vision for Python?
>>
>> This question keeps coming to mind as I think about how the evolution of
>> the language will be governed over the next few years or decades.  Yes,
>> Python is a mature language, but it’s far from stagnant.  Guido always had a
>> very clear vision of what Python should be, where it should go, and how new
>> proposed features (or other changes to the Python ecosystem) fit into that
>> vision, even if he didn’t or couldn’t always clearly articulate them.  The
>> NBDFL will necessarily have a different vision than Guido, and I th

Re: [python-committers] Transfer of power

[Chris Jerdonek]

On Sun, Jul 15, 2018 at 11:31 PM, Tim Peters  wrote:
> [Chris Jerdonek]
>>
>> I don’t think we should assume that a stalemate would be okay in all
>> cases. There may be cases in which a decision has to be made (e.g. if
>> nothing changes, bad things will happen). I think one of the most important
>> roles a BDFL serves is to provide a mechanism of last resort to resolve such
>> stalemates should they ever arise. If the replacement we come up with can
>> itself stalemate, I think there will be a problem.
>
> Can you flesh that out with a plausible example?  If "bad things can happen"
> relates to finances or legal issues, the problem is almost certainly the
> PSF's headache to resolve.  If they don't relate to finances or legal
> issues, I'm unclear on what "bad" could mean.  Guido's BDFL pronouncements
> were mostly about language and library design issues.

I only had in mind technical things. Non-technical things didn't cross
my mind. The types of cases I had in mind were (in the abstract) (1) a
feature is rolled out which later turns out to have a severe defect,
and so it needs to be fixed somehow, and people are divided on how it
should be fixed; (2) something changes outside of Python (e.g.
something OS related), which is or will cause a severe defect for
Python users, and people can't agree on how it should be fixed; and
(3) (a case you mentioned) there is a feature that everyone wants to
add, but people are split on some bike shed issue. It's true that a
stalemate for (3) wouldn't be so bad, but it would prevent something
that everybody wants.

For (1) and (2), I'm probably not the best person to provide an
example. But one case in the back of my mind that may have prompted my
reply and that might qualify was when there was a randomness-related
security issue in the summer of 2016. I believe this is the thread
that kicked it off (subject line: "BDFL ruling request: should we
block forever waiting for high-quality random bits?"):
https://mail.python.org/pipermail/python-dev/2016-June/144939.html

Things got so contentious on python-dev that, IIRC, at least one core
developer quit or was threatening to quit, and it prompted the
creation of a new mailing list (Security-SIG) due to the volume of
emails. See the number of emails the thread above spurred alone:
https://mail.python.org/pipermail/python-dev/2016-June/thread.html

To resolve the split, Guido ultimately chose PEP 524 over PEP 522.

> If you want to make a rule that the Elders cannot tie, the only way to do
> that is to say they'll all be impeached and replaced if they ever tie (as
> already noted by Łukasz, having an odd number of Elders doesn't prevent one
> from abstaining).

There's another alternative. You can make a rule that they're not
allowed to abstain (or some variant, like you have to choose someone
else if you need to recuse yourself). I'm a member of such a body in
fact (the San Francisco Elections Commission). If a member wants to
abstain, a member has to request it, and then the Commission has to
pass a majority vote to let the person to abstain. But we wouldn't
even have to have that extra provision.

--Chris


> And we'll keep replacing them until they stop tying.  But
> we'll probably run out of volunteers after the first round of impeachments.
>
> Sneakier:  add a rule that if the Elders tie, then the choice has to be made
> by the President of the PSF.  Which, by sheer coincidence, is Guido :-)
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Chris Jerdonek]

On Sun, Jul 15, 2018 at 6:07 PM Brett Cannon  wrote:

> On Sat, 14 Jul 2018 at 11:37 Tim Peters  wrote:
>
>> [Tim]
>>
>>> > If there are 3 Elders [snip]
>>>
>>
>> [Łukasz Langa]
>>
>> It looks like the number 3 is popular in this context. What makes it so
>>> attractive?
>>>
>>
>> Likely because it was the first specific non-insane number someone
>> mentioned.  It helps to be concrete, but I don't know that anyone is wedded
>> to 3.
>>
>>
>>> I see a bunch of problems with such a low number, like the ability for a
>>> single corporation to take over the design process of Python by employing
>>> just two of the three members (consistently voting over the third one).
>>
>>
>> Perhaps then you don't want a "supreme court" at all.  We've been living
>> for decades with the possibility that a single corporation could buy off
>> Guido.  Would it really help to change 3 to 5?  Then Evil Corp only needs
>> to buy off 3 - but the larger the number, the more likely Evil Corp will
>> get some votes in its favor without needing to pay.
>>
>> If semi-dictators are part of the New Order at all, they need to be
>> trusted a whole lot (although I suggested a mechanism for impeachment too).
>>
>>
>>
>>> 3 also has high likelihood of ties if one of the members abstains.
>>
>>
>> I don't care about that.  How often did Guido abstain?  it's an Elder's
>> _job_ to make potentially unpopular decisions.  If one abstained without
>> extraordinarily solid reason, I'd move to impeach them - they're not doing
>> the job in that case.
>>
>> If they tied, that's fine too.  Ties favor the status quo (same as if the
>> proposed change had been rejected).  For that reason, I'm not even wedded
>> to an odd number.
>>
>
> That's a good point. Since this is typically going to be a yes/no question
> instead of an A/B question, ties that go in favour of the status quo aren't
> a stalemate issue.
>

I don’t think we should assume that a stalemate would be okay in all cases.
There may be cases in which a decision has to be made (e.g. if nothing
changes, bad things will happen). I think one of the most important roles a
BDFL serves is to provide a mechanism of last resort to resolve such
stalemates should they ever arise. If the replacement we come up with can
itself stalemate, I think there will be a problem.

—Chris



> -Brett
>
>
>>
>>
>>
>>> And so on.
>>>
>>
>> Likewise in the other direction.  For example, how many "extremely
>> trusted" people can we even get to volunteer for a contentious, long-term,
>> non-paying job?  I don't know.  "3" probably started with the first person
>> here who suggested specific names and could only come up with 3 ;-)
>>
>>
>> Taking a step back, before we talk names, term limits and even numbers of
>>> council members, Python needs a "constitution" which will codify what the
>>> council is and how it functions.
>>
>>
>> "Feedback loops" - all decisions feed into each other, in all
>> directions.  For example, the number of people on the council has real
>> effects on what it's _possible_ for it do, and on how it functions.  It
>> doesn't hurt to think about everything at once ;-)
>>
>>
>>  Barry calls it PEP 2 but I'd like to understand who is supposed to
>>> author it and who is supposed to accept it.
>>
>>
>>> Any committer is in a position to suggest parts of or the entirety of
>>> such a document. Otherwise we create a fractal problem of who and how
>>> decides on who shouId be writing it. Ultimately we are volunteers, the ones
>>> who step up and do the work.
>>>
>>
>>  Sure!
>>
>> Ideally Guido would accept the PEP but I'm not sure if he is willing to.
>>
>>
>> His initial message here seemed very clear that he wants us to "figure
>> something out for yourselves".  He's tired of the battles, and perhaps you
>> have to be as old as him (as I was 4 years ago) to grasp what "bone weary"
>> really means ;-)
>>
>>
>>> If that is indeed the case then how should this be done so that the
>>> document is universally accepted by all committers?
>>>
>>
>> Perhaps it won't be - after all, much of the point to a
>> dictator-workalike is that universal acceptance is a rare thing in real
>> life. Guido left us with an interesting puzzle to solve :-)
>>
>> ___
>> 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/

Re: [python-committers] Changing commiter status

[Chris Jerdonek]

What will be the threshold of activity? For example, if one hasn’t been
committing due to time but occasionally comments on or opens b.p.o. issues
or reviews pull requests, etc, would that mean the logo disappears? There
is value in having the logo show up when commenting.

—Chris

On Mon, Jun 18, 2018 at 1:52 PM Paul Moore  wrote:

> On 18 June 2018 at 20:41, M.-A. Lemburg  wrote:
> > On 18.06.2018 21:07, Guido van Rossum wrote:
> >> Hm, unless I misunderstood, MAL's
> >>
> >>> Being a core developer of Python is a status
> >>
> >> suggests that core devs might want to keep this status since it confers
> >> "status" on their person (it looks good on a resume for sure). And I
> >> wouldn't want to make it any harder for a 3rd party to verify someone's
> >> claim to this status in their resume.
> >>
> >> Marc-Andre, is that what you meant?
> >
> > I guess I wasn't clear, sorry.
> >
> > Perhaps the better term is "title" rather than "status". My
> > understanding is that you become core developer and essentially
> > keep this title forever.
> >
> > Whether you actually have your keys in the repo to push a PR
> > or not is a different story and not really related to the "title"
> > you earned.
> >
> > Listing the core developers somewhere on an official page
> > would help with the verification you are referring to. At
> > the moment, we don't seem to have this. It does make a difference
> > on CVs and it's one of the few things we can give back to people
> > when contributing code and time to Python.
>
> Just to add my thoughts here. I agree that "being a Python core
> developer" is something people can be proud of (I know I am!), as well
> as being good to put on a CV. It would be a shame to devalue that
> pride by saying in effect that you're no longer a "real" core
> developer if you don't keep contributing.
>
> So I'd very much like to distinguish the idea of "being a core
> developer" from the administrative management of commit privileges.
> The respect and gratitude of our peers is one of the few things it's
> possible to get as a reward for open source contributions - let's be
> generous with that (and with openly acknowledging it).
>
> Paul
> ___
> 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] Security: please enable 2-factor authentication on GitHub and your email

[Chris Jerdonek]

On Mon, Dec 11, 2017 at 4:58 AM, Victor Stinner
 wrote:
> ...
> Oh, my explanation makes the assumption that you all already enabled
> 2-factor auth on your email, right? :-) If you wasn't aware: email is
> simply the *most* critical part of your whole online data. If a hacker
> gets access to your email, you already lost all your online
> accounts...

Why do you say this? Can't this only be true for accounts that allow
password recovery / reset via email?

--Chris


>
> For Gmail users: you may have a look at
> https://myaccount.google.com/security as well. Maybe remove old
> services that have access to your Google account?
>
>
> After the hack, I also generated a new SSH key, even if it wasn't
> stored online and is encrypted by a passphrase. Just because I was
> using the same key since many years. I chose to use the new modern
> ed25519 key format. It uses an elliptic curve rather than RSA, it's a
> different kind of security. While I don't know if it's more secure, I
> read that it's faster :-)
>
> https://en.wikipedia.org/wiki/EdDSA
>
> I was able to use this new key formats on all services... except Launchpad.
>
> Changing a private SSH key isn't easy:
>
> * You have to install the new SSH on most services that you are using
> * You have to manually remove the old SSH key from *all* services that
> you are using (there is no global "SSH revokation" service...)
> * I used ~/.ssh/known_hosts to get most services, but also updated
> GitHub, Bitbucket, etc.
> * There are a few other services like psf-salt/psf-chef where you may
> also want to see your SSH key updated
> * The question is then if the old SSH key must be removed... the
> problem is that I never tried to keep track of services that I'm using
> through SSH, so I decided to keep the old SSH key (outside ~/.ssh). In
> practice, I'm only using my new SSH private since longer than 6 months
> and I was never blocked.
>
> I also had trouble to get working SSH agent on Gnome for my ed25519
> key, but I succeeded to enable the regular ssh-agent using systemd
> --user. Tell me if you want instructions for this part as well.
>
> 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/
___
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 failure on test_asyncgen?

[Chris Jerdonek]

Even on projects I don't have access to, I've also found that running--

git commit --amend

with no changes and then force-pushing (git push -f) works to
re-trigger Travis CI. I believe it updates the date of the last commit
but otherwise leaves everything the same (so no need to edit files).

--Chris

On Thu, Aug 17, 2017 at 11:31 AM, Brett Cannon  wrote:
>
>
>
> On Wed, 16 Aug 2017 at 12:03 Terry Reedy  wrote:
>>
>> On 8/16/2017 2:32 PM, Antoine Pitrou wrote:
>>
>> > One of my PR builds got an AppVeyor failure in test_asyncgen
>> > and I really doubt it is due to the PR itself:
>> > https://ci.appveyor.com/project/python/cpython/build/3.7.0a0.5366#L682
>>
>> The first failure message:
>>
>> test_async_gen_asyncio_gc_aclose_09
>> (test.test_asyncgen.AsyncGenAsyncioTest) ... Task was destroyed but it
>> is pending!
>> task:  wait_for=> finished result=None>>
>> FAIL
>>
>> > ==
>> > FAIL: test_async_gen_asyncio_gc_aclose_09 
>> > (test.test_asyncgen.AsyncGenAsyncioTest)
>> > --
>> > Traceback (most recent call last):
>> >File "C:\projects\cpython\lib\test\test_asyncgen.py", line 627, in 
>> > test_async_gen_asyncio_gc_aclose_09
>> >  self.assertEqual(DONE, 1)
>> > AssertionError: 0 != 1
>>
>> It passed on the retest:
>> test_async_gen_asyncio_gc_aclose_09
>> (test.test_asyncgen.AsyncGenAsyncioTest) ... ok
>>
>> I have seen obviously unrelated intermittent failures like this too.  If
>> it were to happen on Travis on the retest also, and I wanted to merge, I
>> would try to unblock the merge by making an innocuous change in the
>> blurb or some comment or docstring with the web editor.
>
>
> I think as a core dev you can manually re-run the build on Travis. The other 
> option is to close and then open again the PR as that will re-trigger Travis.
>
> ___
> 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] [Core-mentorship] Regarding reviewing test cases written for tabnanny module

[Chris Jerdonek]

On Mon, Apr 10, 2017 at 8:55 PM, Martin Panter  wrote:
> In this particular pull request, I think the submitter has rebased
> their commit, and force-pushed it. These days, I notice Git Hub seems
> to forget old commits pretty soon after you force-push the branch they
> are on. I don't think you can "unsquash" them retrospectively; you
> would need a copy of the old commits saved somewhere.

In the past, after force-pushing on GitHub, I've noticed that
"orphaned" commits can still be accessed as long as you remember the
previous URL / SHA. For example, in this case, clicking "View Changes"
goes to an URL that doesn't show anything:

https://github.com/python/cpython/pull/851/files/d66ae892c51ab84eac71a3f1b558a021a9cc7a0b

While the commit isn't visible under the pull-request URL, it can
still be accessed through the following two URLs (in the proposer's
repo and in the target repo):

https://github.com/ultimatecoder/cpython/commit/d66ae892c51ab84eac71a3f1b558a021a9cc7a0b
https://github.com/python/cpython/commit/d66ae892c51ab84eac71a3f1b558a021a9cc7a0b

I'm not sure if this helps though because the inline comments don't
seem to be present in this URL.

--Chris



>
> Other times people add revised commits on top of their old commits,
> which would have been easier for me in this situation, but I suspect
> that makes it harder for the person pushing the final change if they
> have to squash it into a single commit. (I noticed the eventual commit
> message is often messy, redundant, automatically generated, etc.)
> ___
> 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] Failed to build select

[Chris Jerdonek]

On Sun, Aug 7, 2016 at 11:45 PM, Steven D'Aprano  wrote:
> On Mon, Aug 08, 2016 at 12:17:21AM -0400, Ned Deily wrote:
>> Also, try without setting PYTHONHOME.  I'm not sure what you're trying to do 
>> by setting that but you shouldn't need to.
>
> I didn't think I needed to either, but when I try without it, I get:
>
> Could not find platform dependent libraries 
> Consider setting $PYTHONHOME to [:]
> Could not find platform dependent libraries 
> Consider setting $PYTHONHOME to [:]

FWIW, I would be interested in learning more about the above warning
(its significance, how it can be addressed, whether it can be ignored,
etc). I also get this message when installing 3.5.2 from source on
Ubuntu 14.04.

--Chris
___
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] PyCon US 2013 attendees

[Chris Jerdonek]

On Mon, Feb 25, 2013 at 11:12 AM, Brett Cannon  wrote:
>
> On Mon, Feb 25, 2013 at 2:00 PM, Chris Jerdonek 
> wrote:
>>
> Out of curiosity, why do you want to know? Just anxious to know and don't
> want to wait until the language summit to find out? Or do you want to know
> who will be there to track them down to ask them something?

Partly out of curiosity, but more the latter -- like to discuss
issues/patches of mutual interest in person, etc, or just to meet
them. :)

--Chris
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

[python-committers] PyCon US 2013 attendees

[Chris Jerdonek]

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.

Thanks,
--Chris
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

[python-committers] server-side clones for deletion

[Chris Jerdonek]

I was testing whether Rietveld could be used to review a devguide
patch, and I accidentally created this server-side clone:

http://hg.python.org/cjerdonek/sandbox-devguide/

Is there a way for me to remove it, or does someone else need to do
it?  In addition, if "Remote hg repo" URLs on the issue tracker don't
need to be on hg.python.org, the following one can also be deleted (I
was confusing this with the restriction for custom builders):

http://hg.python.org/sandbox/cjerdonek-devguide/

Thanks,
--Chris
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

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

[Chris Jerdonek]

On Sat, Dec 29, 2012 at 4:14 PM, Ezio Melotti  wrote:
> Hi,
>
> On Sun, Dec 30, 2012 at 1:50 AM, "Martin v. Löwis" 
> wrote:
>>
>> Am 29.12.12 01:21, schrieb Brett Cannon:
>>
>> > It doesn't matter to me who writes the email. I was not thinking so
>> > formally, bit it wouldn't hurt.
>>
>> So has any action been taken?
>
>
> I haven't talked with him again yet.  If I don't get a chance to do it in
> the following days I'll write him an email.

I think it's important that this be done in the form of an official
e-mail as Brett originally suggested, so that it's clear to everyone
what was said and is not just another side discussion.

--Chris


>
>>
>> If not, I'll communicate it to him. I'm
>> personally worried most about the tracker, so I'd propose the policy
>> - he must not reopen any issues. If he really thinks important
>>   information was not considered, he can post them to the closed issue.
>> - he must not resubmit a duplicate of one of his closed issues.
>>
>
> I think I mentioned this last time we talked, and I'll make sure to make it
> clearer next time.
>
> Best Regards,
> Ezio Melotti
>
>
>>
>> Regards,
>> Martin
>
>
>
> ___
> python-committers mailing list
> python-committers@python.org
> http://mail.python.org/mailman/listinfo/python-committers
>
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

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

[Chris Jerdonek]

On Fri, Dec 28, 2012 at 11:39 AM, Brett Cannon  wrote:
>
>
>
> On Wed, Dec 26, 2012 at 3:29 PM, Chris Jerdonek 
> wrote:
>>
>> On Wed, Dec 26, 2012 at 5:28 AM, R. David Murray 
>> wrote:
>> >>
>> >> On 12/25/2012 5:56 PM, Łukasz Langa wrote:
>> >> > I'm seriously considering writing all this as a PEP (most likely
>> >> > without any personal details). I hope this won't be useful in the
>> >> > future but it might help having this gathered as written policy, if
>> >> > only for transparency reasons.
>> >>
>> >> This strike me as over-reaction.
>> >
>> > I'm not at all sure that it is, but that "most likely" had better be
>> > replaced by "most certainly".  Such a policy needs to rest on
>> > fundamental
>> > principles.  "Bad cases make bad law", so one must be careful not to
>> > craft a policy to deal only with a specific egregious thing, but rather
>> > craft something that will serve well in the general cases.
>> > Specifically,
>> > any such policy, and any statement made if we take action on Anatoly,
>> > will
>> > have to address the inevitable calls that we are engaging in censorship.
>> > There are principled answers to that charge, but we must decide which
>> > of them we are following and why, and articulate that clearly and
>> > consistently.
>>
>> +1.  It might seem bureaucratic to some, but I think grounding actions
>> in due process and documented policy is important.  The Diversity
>> Statement is a good example of this.  (That statement has a different
>> purpose though.  It's more about something we want rather than how to
>> handle something we don't want.):
>>
>> http://www.python.org/community/diversity/
>>
>> What is CoC by the way?
>
>
> Code of Conduct.
>
> -Brett
>
>>
>>
>> > As an aside, it has occurred to me that the fundamental problem here is
>> > that we do not feel that Anatoly respects *us*.  So it is no wonder that
>> > we are offended and do not respect him.
>>
>> FWIW, I've found him to be more what I'd call spammy/annoying and
>> lacking in some areas rather than disrespectful (opening many issues
>> with vague descriptions, starting more than his share of threads on
>> python-ideas, etc).  So I've never felt offended.  Granted, I'm
>> relatively new to being involved and don't follow him closely.  I
>> quickly learned to pass over most of what he writes for lack of time.
>> It's a source of amazement to me that what he writes sometimes leads
>> to something productive.
>
>
> This is where I disagree with everyone who is defending Anatoly as someone
> who can be redeemed and given yet another chance to allow him to continue to
> poison the community where he participates because he is just "annoying". On
> python-dev I checked my email on Xmas morning to an email from Anatoly where
> he said "What should I do in case Eric lost interest after his GSoC project
> for PSF appeared as useless for python-dev community". That is not
> "spammy/annoying" but flat-out disrespectful and rude.
>
> I think I was the first person to publicly state I put Anatoly's email into
> the trash after he publicly said the PSF board should be completely
> disbanded and we should restructure the PSF because he viewed it as
> worthless. That was not annoying but disrespectful.
>
> We have spent **years** trying to get him to be more productive and yet he
> manages to not to. He flat-out refuses to sign any contributor agreement and
> expects us to do all the work and gets mad when we don't spend our free time
> fixing what he wants us to. He won't even search the internet for prior
> discussions as David has pointed out. That's not annoying but disrespectful.
>
> I fully understand that we are all nice people and don't want to do anything
> drastic, but simply ignoring him doesn't solve the issue for new people to
> the community who come to python-ideas, python-dev, or even the tracker on
> occasion and actually take the time to read his emails, reply, etc. and
> don't realize that a decent chunk of core developers never even see their
> responses as the entire thread has already been deleted/muted in the core
> dev's inbox. If I was new and spent some time replying to a thread only to
> find out that the person was being ignored and thus my hard work as well I
> would be frustrated.
>
> In order to deal with this, her

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

[Chris Jerdonek]

On Wed, Dec 26, 2012 at 5:28 AM, R. David Murray  wrote:
>>
>> On 12/25/2012 5:56 PM, Łukasz Langa wrote:
>> > I'm seriously considering writing all this as a PEP (most likely
>> > without any personal details). I hope this won't be useful in the
>> > future but it might help having this gathered as written policy, if
>> > only for transparency reasons.
>>
>> This strike me as over-reaction.
>
> I'm not at all sure that it is, but that "most likely" had better be
> replaced by "most certainly".  Such a policy needs to rest on fundamental
> principles.  "Bad cases make bad law", so one must be careful not to
> craft a policy to deal only with a specific egregious thing, but rather
> craft something that will serve well in the general cases.  Specifically,
> any such policy, and any statement made if we take action on Anatoly, will
> have to address the inevitable calls that we are engaging in censorship.
> There are principled answers to that charge, but we must decide which
> of them we are following and why, and articulate that clearly and
> consistently.

+1.  It might seem bureaucratic to some, but I think grounding actions
in due process and documented policy is important.  The Diversity
Statement is a good example of this.  (That statement has a different
purpose though.  It's more about something we want rather than how to
handle something we don't want.):

http://www.python.org/community/diversity/

What is CoC by the way?

> As an aside, it has occurred to me that the fundamental problem here is
> that we do not feel that Anatoly respects *us*.  So it is no wonder that
> we are offended and do not respect him.

FWIW, I've found him to be more what I'd call spammy/annoying and
lacking in some areas rather than disrespectful (opening many issues
with vague descriptions, starting more than his share of threads on
python-ideas, etc).  So I've never felt offended.  Granted, I'm
relatively new to being involved and don't follow him closely.  I
quickly learned to pass over most of what he writes for lack of time.
It's a source of amazement to me that what he writes sometimes leads
to something productive.

--Chris
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

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

[Chris Jerdonek]

On Tue, Dec 25, 2012 at 11:36 PM, Terry Reedy  wrote:
> This is a continuation of my answer to Christian
>
>
> On 12/25/2012 5:56 PM, Łukasz Langa wrote:
>>
>> Dnia 25 gru 2012 o godz. 13:37 Nick Coghlan 
>> napisał(a):
>>
>>> I'm well and truly to the point of caring far more about the
>>> feelings of people who get frustrated trying to deal with his
>>> obtuseness (whether that arises deliberately or through genuine
>>> cluelessness) than I care about his feelings. He has the entire
>>> internet to play on, we don't have to allow him access to
>>> python.org controlled resources.
>>
>>
>> +1
>>
>> I opened this thread so I feel somewhat responsible to carry this out
>> to finish. Give me a day or two to contemplate on how to achieve the
>> following:
>
>
> Please do wait. Contemplation and sleep can work wonders.
>
>
>> 1. Communicate what happened clearly and openly to our community.
>
>
> I am not sure how broadly you mean 'our community', but please no. Nothing
> need or should be said beyond this list. (Unless Anatoly says something
> elsewhere -- but let him be the first.

At the risk of stating something that I imagine everyone already
knows, this list is itself publicly viewable:

http://mail.python.org/mailman/listinfo/python-committers

So in some sense what we write here is already being said beyond this
list (though not actively).  For example, the thread we're engaging in
right now is the second result when Googling "python anatoly".

I guess my point is that what's going on is already pretty open to the
outside (from a read-only perspective).

--Chris
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

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

[Chris Jerdonek]

On Tue, Dec 25, 2012 at 2:51 PM, Eli Bendersky  wrote:
>
>> > Did anything come of this? There are now a few more threads on
>> > python-ideas that are almost pure Anatoly-instigated noise :P
>>
>> Back in November, I had asked if anyone had ever given him an
>> official/explicit warning that he would be kicked out if he continued
>> certain behavior, and it didn't seem that anyone had ever had.  Out of
>> curiosity, has that been done since then?  I think it is good practice
>> to issue a warning before kicking someone out.
>
>
> I'd say that the email sent by Andrew Svetlov certainly counts as a warning.
> I also recall Guido mentioned he'll speak with Anatoly over Skype.

Then I guess I'm asking if he was explicitly warned in either that
e-mail or Skype conversation.  You can tell someone, "people don't
like your behavior" without saying "we will kick you off if you
continue."  One states the consequence.

--Chris
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

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

[Chris Jerdonek]

On Tue, Dec 25, 2012 at 4:37 AM, Nick Coghlan  wrote:
> On Thu, Nov 8, 2012 at 7:10 AM, Andrew Svetlov  
> wrote:
>> Let's wait a bit.
>>
>> On Wed, Nov 7, 2012 at 11:04 PM, Guido van Rossum  wrote:
>>> From his response to me he seems to be unaware that there is a problem...
>>>
>>>
>>> On Wed, Nov 7, 2012 at 12:39 PM, Andrew Svetlov 
>>> wrote:

 I've sent email to Anatoly in Russian describing current situation.
 CC'ed Eli Bendersky and Łukasz Langa as humans who understand Russian
 well enough to be witness for my words.
>
> Did anything come of this? There are now a few more threads on
> python-ideas that are almost pure Anatoly-instigated noise :P

Back in November, I had asked if anyone had ever given him an
official/explicit warning that he would be kicked out if he continued
certain behavior, and it didn't seem that anyone had ever had.  Out of
curiosity, has that been done since then?  I think it is good practice
to issue a warning before kicking someone out.

--Chris
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Commit privs for Serhiy Storchaka?

[Chris Jerdonek]

On Mon, Dec 24, 2012 at 7:55 PM, Trent Nelson  wrote:
>
> On Dec 24, 2012, at 7:29 PM, Nick Coghlan wrote:
>
>> IIRC, commit privileges have been offered based on the last thread, it's up 
>> to Serhiy when he wants to accept them. Perhaps the second nomination will 
>> persuade him to accept :)
> That's odd... I can't see any e-mails in my python-committers folder 
> regarding Serhiy, and I when I chatted to him today on IRC he seemed 
> interested in commit privs.

The thread Nick is referring to is here:

http://mail.python.org/pipermail/python-committers/2012-October/002228.html

The original nomination was here:

http://mail.python.org/pipermail/python-committers/2012-August/002142.html

--Chris
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

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

[Chris Jerdonek]

On Wed, Nov 7, 2012 at 9:01 AM, Guido van Rossum  wrote:
> On Wed, Nov 7, 2012 at 8:55 AM, Antoine Pitrou  wrote:
>>
>> [...]
>> >
>> > All in all, is anyone of the opinion that losing him as a community
>> > member
>> > is worse than keeping him around?
>>
>> No.
>
>
> It's pretty clear that he's not a net value to Python development. But
> perhaps his attempts at contributing (no matter how clumsy) have value for
> him? I imagine it must be pretty lonely being the only geek with deep Python
> knowledge and interest in Minsk. I realize he's making it hard to be
> compassionate. But I still think what sets him apart from the typical troll
> is that he doesn't do it because he likes disagreement. He just lacks social
> skills (English not being his first language may contribute here). And yes,
> he doesn't seem to be learning from the feedback he gets.

That's why I think an explicit warning might be good in this case (if
it hasn't already been given).  He obviously(?) cares about Python, so
the threat of banning might be what it takes to get him to give pause
before posting.  The lack of social skills can go both ways (i.e. both
writing and interpreting), in which case he might not have picked up
on any implicit threat of banning.  But I know very little about the
situation, so feel free to disregard my suggestion.

--Chris
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

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

[Chris Jerdonek]

On Wed, Nov 7, 2012 at 6:08 AM, R. David Murray  wrote:
> On Wed, 07 Nov 2012 14:26:15 +0100,  wrote:
>> What can we do? Apart from the obligatory joke of nudging him gently
>> towards Ruby, I think calling his behavior out is a good idea. Cory
>> Doctorow also thinks that "many trolls are perfectly nice in real life
>> -- sometimes, just calling them on the phone and confronting them with
>> the human being at the other end of their attacks is enough to sober
>> them up" [3]. If that fails, banning him would show that we care about
>> the quality of communication and technical prowess is no excuse for
>> abusive behavior.
>
> As Brett pointed out, calling him on his behavior seems to meet with
> pretty much zero success as far as modifying his future behavior goes.

Aside from calling him out on his behavior and trying to change it,
has anyone additionally made it clear to him that "if you continue
this behavior, you will be banned from [insert as appropriate]"?  Or
is an explicit warning not needed?

--Chris
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Googler Python committers

[Chris Jerdonek]

On Tue, Oct 16, 2012 at 6:32 AM, Eli Bendersky  wrote:
>
> I had the privilege of joining Google's Mountain View office yesterday, and
> was wondering who else from the core development team works there, or in
> Google in general (in addition to Guido, of course).

Congrats, Eli!  This may not be complete or accurate, but (and this
tip can be useful to everybody), the list of committers here has a
column that in some cases shows a company.  Several people from Google
are listed:

http://bugs.python.org/user?iscommitter=1&@action=search&@sort=username&@pagesize=300

(IIRC, you need to be logged in to the tracker to see the page.)

--Chris
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] custom/sandbox repositories

[Chris Jerdonek]

On Sat, Oct 13, 2012 at 10:15 PM, Chris Jerdonek
 wrote:
> On Wed, Oct 10, 2012 at 1:51 AM, Nick Coghlan  wrote:
>> On Wed, Oct 10, 2012 at 1:00 PM, Chris Jerdonek
>>  wrote:
>>> Is the sandbox repository
>>> something we can create on our own, or do we need to request it?
>>
>> You can just use the "server-side clone" link when looking at
>> http://hg.python.org/cpython/
>
> Am I right that the server-side clone feature isn't documented in the
> devguide?  Also, is it okay to specify a three-level name for the
> "target repo name" like "sandbox/cjerdonek/cpython"?

To answer my own question, the answer is no. :)

'Please use a secondary level path such as "sandbox/cpython"'

--Chris
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] custom/sandbox repositories

[Chris Jerdonek]

On Sat, Oct 13, 2012 at 10:28 PM, Ned Deily  wrote:
> In article
> ,
>  Chris Jerdonek  wrote:
>> On Wed, Oct 10, 2012 at 1:51 AM, Nick Coghlan  wrote:
>> > On Wed, Oct 10, 2012 at 1:00 PM, Chris Jerdonek
>> >  wrote:
>> >> Is the sandbox repository
>> >> something we can create on our own, or do we need to request it?
>> >
>> > You can just use the "server-side clone" link when looking at
>> > http://hg.python.org/cpython/
>>
>> Am I right that the server-side clone feature isn't documented in the
>> devguide?  Also, is it okay to specify a three-level name for the
>> "target repo name" like "sandbox/cjerdonek/cpython"?
>
> http://docs.python.org/devguide/committing.html#long-term-development-of-
> features

Thanks.  It's odd that searching neither for "clone" nor "server-side"
pulls that up (using the guide's "Quick Search" box).

--Chris
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] custom/sandbox repositories

[Chris Jerdonek]

On Wed, Oct 10, 2012 at 1:51 AM, Nick Coghlan  wrote:
> On Wed, Oct 10, 2012 at 1:00 PM, Chris Jerdonek
>  wrote:
>> Is the sandbox repository
>> something we can create on our own, or do we need to request it?
>
> You can just use the "server-side clone" link when looking at
> http://hg.python.org/cpython/

Am I right that the server-side clone feature isn't documented in the
devguide?  Also, is it okay to specify a three-level name for the
"target repo name" like "sandbox/cjerdonek/cpython"?

--Chris
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

[python-committers] custom/sandbox repositories

[Chris Jerdonek]

Antoine pointed out to me the possibility of using a custom repository
for testing purposes:

http://docs.python.org/devguide/buildbots.html#custom-builders

Is the standard procedure for a developer to create and use their own
sandbox repository under http://hg.python.org/sandbox/?  Or should we
use an existing sandbox repository (e.g. perhaps by creating a new
head so as to decrease inteference)?  Is the sandbox repository
something we can create on our own, or do we need to request it?

--Chris
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

[python-committers] contributor forms (was Re: contributor form for Alexander Belopolsky)

[Chris Jerdonek]

On Fri, Sep 21, 2012, Jesús Cea Avión wrote:
>
> Alexander Belopolsky is a core developer but the bugtracker doesn't [edit: 
> but now does]
> have a "contributor form received" flag for him?

FWIW, you can see a list of all such core developers using this URL:

http://bugs.python.org/user?iscommitter=1&contrib_form=0&@action=search&@sort=username&@pagesize=300

There are currently 35 without a contributor form (though I realize
that many of them may not currently be active).

--Chris
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Commit privileges for Chris Jerdonek

[Chris Jerdonek]

On Mon, Sep 24, 2012 at 6:11 AM, Brett Cannon  wrote:
> I just cleared Chris' subscription to this list and he has sent in his SSH
> keys (no one has added them yet, though; hopefully soon when Antoine, Georg,
> or myself get around to it).
>
> Welcome aboard, Chris!

Thanks, Brett.  And thanks, everyone.  Georg has already added my SSH
keys, and I've done a few test commits in the test repository on
hg.python.org to try things out (with some pointers earlier from Georg
and Ezio on IRC).

Needless to say, I'm excited to be part of this community.  It also
goes without saying, please let me know if you ever see anything that
I can do to improve how I help.  I'm always open to suggestions.

Cheers,
--Chris
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers