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
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.
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
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
Note: the PR is
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.
`self.initfp()` is very unlikely raise exceptions. But MemoryError,
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?
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
>> 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.
> Core-mentorship mailing list
--Guido van Rossum (python.org/~guido)
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.
I was looking for our Deprecation Policy and stumbled on this thread
from January 2016.
Title: Deprecation Policy
Author: Ezio Melotti <ezio.melotti at gmail.com>
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
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
Just a heads up that the following PR:
has generated a lot of spurious PR additions on bugs.python.org,
probably because that PR references a lot of issues
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 :-))