python-committers April 2017

python-committers@python.org

25 participants
10 discussions

I have blocked Wes Turner from the Python org on GitHub

by Brett Cannon

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

3 years, 11 months

Proposal for procedures regarding CoC actions

by Raymond Hettinger

I would like to make a procedural proposal based on the ideas emerging from the other python-committers discussion regarding the two month suspension of Github project access for a developer who was posting non-productively. It seems that there is general agreement to differentiate commonplace list moderation actions from CoC actions which are more of a nuclear option to be reserved for egregious cases of harassment and abuse. Also, there is general agreement not to concentrate that power in the hands of a single person and that we should have some principles and procedures in place. I propose that when someone thinks there is a problem serious enough to warrant a Code-of-Conduct action, that it get referred to a group of three people to make the decision. Two of those three people should be long-term, senior, and respected core devs who have good knowledge of the community (Brett Cannon, Nick Coghlan, Antoine Pitrou, et al). The third person should be someone who is also well-respected but more independent and who has more experience in sociology and community management issues (Alex Gaynor or Carol Willing come to mind). To prevent endless bickering and sharing of sensitive details, the group's decision should be considered settled business which can only be overridden either by an appeal to the PSF board or by the BDFL. When possible, the affected person should be contacted and given an opportunity to defend themselves. The decision shall be announced on python-committers with an overall rationale but without personal details. The group shall consider the needs of the community first and foremost, and secondarily shall prioritize being as respectful as possible to all parties, and thirdly shall do whatever they can to mitigate the harm to the violator. The actions shall be taken with an intent to protect the vibrancy of the Python community rather than with an intent to punish, humiliate, or discredit the affected person. When possible, some path to redemption or forgiveness shall be offered. Respectfully submitted, Raymond Hettinger

4 years

Codecov and PR

by Victor Stinner

Hi, I tried to merge a pull request on my phone, but I got the error: "Pull requests that have a failing status can’t be merged on a phone." The GitHub PEP announced that it will be possible to merge a change from the beach. Well, it's doable but only if you bring a laptop, not a phone :-) All tests pass except Codecov which is unstable. On a computer, I can merge such PR. What is the status of Codecov? Is someone actively working on fixing it to make it more reliable. I dislike code coverage in general, even more when it's run in a CI. Can we change the merge policy to allow merge on a phone? Or can we fix Codecov? Note: the PR is https://github.com/python/cpython/pull/1237#pullrequestreview-34044762 Codecov says "10% of diff hit (target: 100%)". The newly added code is tested on Windows on release build. Maybe Codecov only tests on Windows? I dislike code coverage because there is a temptation to write artficial tests whereas the code is tested indirectly or the code is not important enough to *require* tests. Victor

4 years

Re: [python-committers] Codecov and PR

by Victor Stinner

`self.initfp()` is very unlikely raise exceptions. But MemoryError, KeyboardInterrupt or other rare exceptions may be happen. unittest.mock helps a lot to test such corner case: mock initfp() with a MemoryError side effect, maybe also close () to check that the method was called... The new problem is that on 3 instructions, 2 are mocked... The test now checks the test itself or the real application? Victor

4 years

cherry_picker.py updated

by Mariatta Wijaya

Hi, If you've been using cherry_picker.py, please update it ( by doing `git pull` ). With this update, the branch number is automatically prefixed in the commit message. (https://github.com/python/core-workflow/issues/44) Added --abort/--continue options to address https://github.com/python/core-workflow/issues/45 Lastly, I added --status option, which will just perform `git status` for the cpython directory. Thanks :) Mariatta Wijaya

4 years

Re: [python-committers] [Core-mentorship] Regarding reviewing test cases written for tabnanny module

by Guido van Rossum

Thanks for the clarification. We should probably move this discussion to the python-committers list rather than core-mentorship. On Mon, Apr 10, 2017 at 12:12 PM, Terry Reedy <tjreedy(a)udel.edu> wrote: > On 4/10/2017 12:54 PM, Guido van Rossum wrote: > >> So the response from Martin Panter >> (https://github.com/python/cpython/pull/851#issuecomment-292755992) >> sounds like he's not set up for the new GitHub workflow. I'm CC'ing >> Martin here. >> > > The specific issue Martin raised is "Sorry but I don’t have an easy way to > see your fixes relative to the old version I reviewed." If the original > and modified patches were posted in proper format to b.p.o., then one could > hit [review] to start Rietveld and request a side-by-side diff of the two > versions. This is perfect for reviewing responses to comments, especially > those made in-line. For this issue, Martin made about 20 inline comments. > > I don't see any way to get the equivalent on a github PR. It appears that > the original patch is replaced by the revised patch. To me, Rietveld was a > great review tool and its loss a regression in the work process. I hope > that this can be fixed somehow. > > tjr > > > > _______________________________________________ > Core-mentorship mailing list > Core-mentorship(a)python.org > https://mail.python.org/mailman/listinfo/core-mentorship > -- --Guido van Rossum (python.org/~guido)

4 years

A status check for issue number is coming soon

by Brett Cannon

I have created a new GitHub bot called Bedevere ( https://github.com/python/bedevere; see the README if you don't know the Monty Python and the Holy Grail reference). Once activated on the cpython repo it will add a status check -- just like Travis and AppVeyor -- based on whether an issue number is found in a pull request's title. If it's there then the Details link will point to that issue on bugs.python.org (i.e. no more copying and pasting the number to get back to the issue). If it's missing then the status will be marking failing. For those PRs where an issue number is not necessary, you can add the "trivial" label and that will make the status be passing. Long-term. Bedevere will probably gain other checks like whether there is a news entry (that solution is being actively worked on and I'm still hopeful will be in place this month). My hope is by having a single bot for these kinds of checks we can make it easier to automate what we can that doesn't make sense to do in the CI test builds (i.e. everything related to the PR itself, but not the code in the PR). Now Bedevere has not been turned on yet because I'm sick and I don't want to try and diagnose issues the way I'm feeling, but I just wanted to let people know that the problem of people forgetting issue numbers is getting a fix (hopefully) shortly.

4 years, 1 month

Deprecation Policy PEP Thread

by Senthil Kumaran

I was looking for our Deprecation Policy and stumbled on this thread from January 2016. --------- PEP: XXX Title: Deprecation Policy Version: $Revision$ Last-Modified: $Date$ Author: Ezio Melotti <ezio.melotti at gmail.com> Status: Draft Type: Process Content-Type: text/x-rst Created: 29-Jan-2016 Post-History: https://mail.python.org/pipermail/python-committers/2016-January/003706.html I see that Ezio has already answered many questions in that thread, and perhaps a minor update to the proposal text is required. My assumption is, there is still in active interest in documenting our deprecation policy, and it might be a good idea to move forward with a pep PR? -- Senthil

4 years, 1 month

Please briefly explain reverts in commit message

by Terry Reedy

I read commit messages to learn from others and understand the CPython development. There have been several recent revert commits with no explanation (that I can see) in the commit message. I would like to see at least something brief. Some possibilities I can think of: Accidentally pushed green button. Buildbot for system X failed. Change in untested feature caught by application X. Fix did not really work, at least not everywhere. Fix worked but increased resource usage too much. 'Neutral' code rewrite worse than original. ??? -- Terry Jan Reedy

4 years, 1 month

Spurious bugs.p.o messages

by Antoine Pitrou

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

4 years, 1 month

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-committers April 2017