From antoine at python.org  Sat Apr  1 04:17:27 2017
From: antoine at python.org (Antoine Pitrou)
Date: Sat, 1 Apr 2017 10:17:27 +0200
Subject: [python-committers] I have blocked Wes Turner from the Python
 org on GitHub
In-Reply-To: <72E84E8D-7517-433B-9E2B-FBA513276B77@gmail.com>
References: <CAP1=2W5=ukka=32n4cUdRLs=tn059Nb9St_J-P2VR4u9Jo2E7g@mail.gmail.com>
 <72E84E8D-7517-433B-9E2B-FBA513276B77@gmail.com>
Message-ID: <f35afeb0-571a-badb-0c08-5a6dd24ce10a@python.org>


Le 01/04/2017 ? 05:44, Raymond Hettinger a ?crit :
> 
> FWIW, this may just be his communication style that reflects his
tooling (probably emacs org-mode or some such) and his way of thinking
about problems.

It is most probably his communication style, as I have seen him act this
way on other mailing-lists.  I would add that IMHO it is not an
effective communication style: even though he posts lots of "content"
from a quantitative POV, the content is never exploitable as is as it
doesn't seem to ever come with an actual reasoning about the issue at hand.

I have sometimes been mildly annoyed by his posting style on MLs, and I
can imagine how it can become very annoying on a GitHub PR.

> 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.

A big +1 to that.  Thanks for saying it.

Regards

Antoine.

From p.f.moore at gmail.com  Sat Apr  1 05:16:58 2017
From: p.f.moore at gmail.com (Paul Moore)
Date: Sat, 1 Apr 2017 10:16:58 +0100
Subject: [python-committers] I have blocked Wes Turner from the Python
 org on GitHub
In-Reply-To: <f35afeb0-571a-badb-0c08-5a6dd24ce10a@python.org>
References: <CAP1=2W5=ukka=32n4cUdRLs=tn059Nb9St_J-P2VR4u9Jo2E7g@mail.gmail.com>
 <72E84E8D-7517-433B-9E2B-FBA513276B77@gmail.com>
 <f35afeb0-571a-badb-0c08-5a6dd24ce10a@python.org>
Message-ID: <CACac1F8Xfr3dUJssPwU3O7BAgv54FiVstgJ2UoPpTQ_bHR9z_Q@mail.gmail.com>

On 1 April 2017 at 09:17, Antoine Pitrou <antoine at python.org> wrote:
> I have sometimes been mildly annoyed by his posting style on MLs, and I
> can imagine how it can become very annoying on a GitHub PR.

Agreed. I don't feel that Wes' contributions are productive, and I
generally ignore them. I support banning him if he refuses to (or is
incapable of) improving his style - he's certainly been told often
enough in various lists. But it did surprise me that it was addressed
as a CoC issue. I'd hope we have alternative means of dealing with
non-productive behaviours that don't have the implications of a CoC
violation.

As has been noted, Wes' style may be more about how he thinks and
behaves, and may well be something he can't "fix". It's very dangerous
to judge people based on limited interactions, and it's entirely
possible that the code of conduct has more to say about how we treat
Wes than the other way around. But even if that *is* the case, there
comes a point where treating all participants equally does mean we're
OK to say "sorry, you're being unproductive and that won't change, so
we can't work with you" regardless of who they are or their
circumstances. I'd prefer to view what's happened here as a case where
we have to say "we've done our best to be welcoming and work with you,
but it's not going to work out".

If we don't have a good way to do that, let's get one.

Paul

From mal at egenix.com  Sat Apr  1 12:27:30 2017
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat, 1 Apr 2017 18:27:30 +0200
Subject: [python-committers] I have blocked Wes Turner from the Python
 org on GitHub
In-Reply-To: <72E84E8D-7517-433B-9E2B-FBA513276B77@gmail.com>
References: <CAP1=2W5=ukka=32n4cUdRLs=tn059Nb9St_J-P2VR4u9Jo2E7g@mail.gmail.com>
 <72E84E8D-7517-433B-9E2B-FBA513276B77@gmail.com>
Message-ID: <8d0fc725-5512-2d31-159e-a7c531a51ded@egenix.com>

On 01.04.2017 05:44, Raymond Hettinger wrote:
> 
>> On Mar 31, 2017, at 2:40 PM, Brett Cannon <brett at python.org> 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. Wes's comments are nowhere near a CoC violation,
IMO.

I agree with Raymond that CoCs are not meant as a tool to
silence people with different ideas or communication styles
out of convenience.

It's the ultimate tool, not the first to consider. If Wes were
continuously offensive that would be a reason to start discussing
CoC related actions.

--
Marc-Andre Lemburg

From ethan at stoneleaf.us  Sat Apr  1 12:46:24 2017
From: ethan at stoneleaf.us (Ethan Furman)
Date: Sat, 01 Apr 2017 09:46:24 -0700
Subject: [python-committers] I have blocked Wes Turner from the Python
 org on GitHub
In-Reply-To: <CACac1F8Xfr3dUJssPwU3O7BAgv54FiVstgJ2UoPpTQ_bHR9z_Q@mail.gmail.com>
References: <CAP1=2W5=ukka=32n4cUdRLs=tn059Nb9St_J-P2VR4u9Jo2E7g@mail.gmail.com>
 <72E84E8D-7517-433B-9E2B-FBA513276B77@gmail.com>
 <f35afeb0-571a-badb-0c08-5a6dd24ce10a@python.org>
 <CACac1F8Xfr3dUJssPwU3O7BAgv54FiVstgJ2UoPpTQ_bHR9z_Q@mail.gmail.com>
Message-ID: <58DFD960.5010204@stoneleaf.us>

On 04/01/2017 02:16 AM, Paul Moore wrote:
> On 1 April 2017 at 09:17, Antoine Pitrou wrote:

> But even if that *is* the case, there
> comes a point where treating all participants equally does mean we're
> OK to say "sorry, you're being unproductive and that won't change, so
> we can't work with you" regardless of who they are or their
> circumstances. I'd prefer to view what's happened here as a case where
> we have to say "we've done our best to be welcoming and work with you,
> but it's not going to work out".
>
> If we don't have a good way to do that, let's get one.

+1

Whatever the reason, his posts are effectively noise, and he produces a lot.

--
~Ethan~


From tjreedy at udel.edu  Sat Apr  1 13:23:35 2017
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 1 Apr 2017 13:23:35 -0400
Subject: [python-committers] Please briefly explain reverts in commit message
Message-ID: <18e09055-b2e8-70e1-ae54-e6ebe6d9e9cb@udel.edu>

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

From ncoghlan at gmail.com  Sat Apr  1 13:59:01 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 2 Apr 2017 03:59:01 +1000
Subject: [python-committers] I have blocked Wes Turner from the Python
 org on GitHub
In-Reply-To: <CACac1F8Xfr3dUJssPwU3O7BAgv54FiVstgJ2UoPpTQ_bHR9z_Q@mail.gmail.com>
References: <CAP1=2W5=ukka=32n4cUdRLs=tn059Nb9St_J-P2VR4u9Jo2E7g@mail.gmail.com>
 <72E84E8D-7517-433B-9E2B-FBA513276B77@gmail.com>
 <f35afeb0-571a-badb-0c08-5a6dd24ce10a@python.org>
 <CACac1F8Xfr3dUJssPwU3O7BAgv54FiVstgJ2UoPpTQ_bHR9z_Q@mail.gmail.com>
Message-ID: <CADiSq7c1uE8PWTtre1CkhU6HAHKVqeypy-rrw0doObV8d2Cgtw@mail.gmail.com>

On 1 April 2017 at 19:16, Paul Moore <p.f.moore at gmail.com> wrote:
> On 1 April 2017 at 09:17, Antoine Pitrou <antoine at python.org> wrote:
>> I have sometimes been mildly annoyed by his posting style on MLs, and I
>> can imagine how it can become very annoying on a GitHub PR.
>
> Agreed. I don't feel that Wes' contributions are productive, and I
> generally ignore them. I support banning him if he refuses to (or is
> incapable of) improving his style - he's certainly been told often
> enough in various lists. But it did surprise me that it was addressed
> as a CoC issue. I'd hope we have alternative means of dealing with
> non-productive behaviours that don't have the implications of a CoC
> violation.

The CoC is the only mechanism that's written down, since it defines
the terms of the deal for ongoing participation: we're each expected
to be open, considerate, and respectful of others, and that "open by
default" status can be withdrawn given persistent and repeated
failures to be considerate and respectful even in the face of personal
coaching.

Outside that, mailing list moderation decisions are entirely in the
hands of the moderators of any given list, while bugs.python.org is
collectively managed by the current core developers, and the Python
GitHub org is managed by the folks with the "owner" role for that
group (covering both python-dev and the PSF, since that org is used
for more than just CPython)

> As has been noted, Wes' style may be more about how he thinks and
> behaves, and may well be something he can't "fix". It's very dangerous
> to judge people based on limited interactions, and it's entirely
> possible that the code of conduct has more to say about how we treat
> Wes than the other way around.

> But even if that *is* the case, there
> comes a point where treating all participants equally does mean we're
> OK to say "sorry, you're being unproductive and that won't change, so
> we can't work with you" regardless of who they are or their
> circumstances. I'd prefer to view what's happened here as a case where
> we have to say "we've done our best to be welcoming and work with you,
> but it's not going to work out".
>
> If we don't have a good way to do that, let's get one.

Short of cases that are escalated to the PSF Board (for blanket bans
from PSF provided infrastructure, which has still only been deemed
necessary once), the steps typically taken by mailing list moderators
and issue tracker administrators are:

1. giving folks guidance on specific behaviors that are causing
problems for other people (in this case, random info dumps on
distutils-sig, python-ideas, and most recently, core-workflow GitHub
issues)
2. if nothing changes, or the problematic behaviours return, this may
escalate to an enforced suspension (for the issue trackers), or
mandatory moderation (for mailing lists)
3. only if step 2 proves inadequate are other options (like permabans
with no chance for future review) considered, and that currently means
escalating matters to the PSF (since they're the ones with ultimate
responsibility for the management of all of our communication
channels)

In this particular case, we're only at step 2 - self-moderation based
on previously provided guidance has proven inadequate, so an enforced
break specifically from the Python org on GitHub makes sense (mainly
because the tools for dealing with non-productive noise on GitHub
issues aren't anywhere near as well developed as those for email). If
there was finer granularity available on GitHub, the suspension would
presumably have only been from the core-workflow repo specifically,
but that's not currently an available option.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From senthil at uthcode.com  Sat Apr  1 14:49:39 2017
From: senthil at uthcode.com (Senthil Kumaran)
Date: Sat, 1 Apr 2017 11:49:39 -0700
Subject: [python-committers] I have blocked Wes Turner from the Python
 org on GitHub
In-Reply-To: <8d0fc725-5512-2d31-159e-a7c531a51ded@egenix.com>
References: <CAP1=2W5=ukka=32n4cUdRLs=tn059Nb9St_J-P2VR4u9Jo2E7g@mail.gmail.com>
 <72E84E8D-7517-433B-9E2B-FBA513276B77@gmail.com>
 <8d0fc725-5512-2d31-159e-a7c531a51ded@egenix.com>
Message-ID: <CAPOVWOQAuPP+Hd+-sb=Pgc_7YhSzo_5k2kD3WJ7hz8tt5jHaLg@mail.gmail.com>

On Sat, Apr 1, 2017 at 9:27 AM, M.-A. Lemburg <mal at egenix.com> wrote:

> It's the ultimate tool, not the first to consider.

I am with this approach too.  Defining a process and gradually
enforcing CoC through a well-defined process seems to be way to go.
Reading Brett's first email, it appears that it was followed in the
context of the issue/discussion, but due to Github limitations, it
happens to be org-wide.

* If Wes recognizes his mistake and is willing to correct, I am in for
removing the block.
* I also think, sharing upfront (in this or a relevant list) before
enforcing CoC would have gotten others onboard too.

-- 
Senthil

From p.f.moore at gmail.com  Sat Apr  1 14:55:05 2017
From: p.f.moore at gmail.com (Paul Moore)
Date: Sat, 1 Apr 2017 19:55:05 +0100
Subject: [python-committers] I have blocked Wes Turner from the Python
 org on GitHub
In-Reply-To: <CADiSq7c1uE8PWTtre1CkhU6HAHKVqeypy-rrw0doObV8d2Cgtw@mail.gmail.com>
References: <CAP1=2W5=ukka=32n4cUdRLs=tn059Nb9St_J-P2VR4u9Jo2E7g@mail.gmail.com>
 <72E84E8D-7517-433B-9E2B-FBA513276B77@gmail.com>
 <f35afeb0-571a-badb-0c08-5a6dd24ce10a@python.org>
 <CACac1F8Xfr3dUJssPwU3O7BAgv54FiVstgJ2UoPpTQ_bHR9z_Q@mail.gmail.com>
 <CADiSq7c1uE8PWTtre1CkhU6HAHKVqeypy-rrw0doObV8d2Cgtw@mail.gmail.com>
Message-ID: <CACac1F9iEAROxgafHHxO6kXtvL+w0w7o14O8iO1fRA2TKAZJ+g@mail.gmail.com>

On 1 April 2017 at 18:59, Nick Coghlan <ncoghlan at gmail.com> wrote:
> In this particular case, we're only at step 2 - self-moderation based
> on previously provided guidance has proven inadequate, so an enforced
> break specifically from the Python org on GitHub makes sense (mainly
> because the tools for dealing with non-productive noise on GitHub
> issues aren't anywhere near as well developed as those for email). If
> there was finer granularity available on GitHub, the suspension would
> presumably have only been from the core-workflow repo specifically,
> but that's not currently an available option.

That seems entirely sensible. As does the entire process you describe.

Paul

From brett at python.org  Sat Apr  1 14:35:59 2017
From: brett at python.org (Brett Cannon)
Date: Sat, 01 Apr 2017 18:35:59 +0000
Subject: [python-committers] I have blocked Wes Turner from the Python
 org on GitHub
In-Reply-To: <8d0fc725-5512-2d31-159e-a7c531a51ded@egenix.com>
References: <CAP1=2W5=ukka=32n4cUdRLs=tn059Nb9St_J-P2VR4u9Jo2E7g@mail.gmail.com>
 <72E84E8D-7517-433B-9E2B-FBA513276B77@gmail.com>
 <8d0fc725-5512-2d31-159e-a7c531a51ded@egenix.com>
Message-ID: <CAP1=2W5t9RF3ukhamEp_xTWTC8pRnCMd25P6TpsBK5EjJZZxug@mail.gmail.com>

On Sat, 1 Apr 2017 at 09:27 M.-A. Lemburg <mal at egenix.com> wrote:

> On 01.04.2017 05:44, Raymond Hettinger wrote:
> >
> >> On Mar 31, 2017, at 2:40 PM, Brett Cannon <brett at python.org> 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 read for a few months
and I know multiple other people who have done the same).

>From what people have said in opposition to what I did, I think we need to
have a discussion about two things:

1. Is it a CoC violation if someone chooses to ignore repeated warnings
that their communication style is unproductive and thus a waste of people's
time? And if people don't view it as an explicit CoC violation, do we still
view it as enough reason to block someone but under a different name? (I
obviously view it as a CoC violation.)

2. What is the exact procedure someone has to follow to instigate a ban
(and this policy should probably cover GitHub, mailing lists, and anywhere
else someone can be banned)? Is it having two core devs agree to the ban
and it being publicly stated here (as MAL suggested)? Whatever approach we
choose we should write it down in the devguide somewhere.

As for Wes himself, I'm fine with the ban lasting only a couple months (say
the end of May?). Based on the positive feedback I received on the ban I
don't want to just drop it without at least some time passing to get the
point across that something needs to change, but I also don't expect the
ban to be permanent since there wasn't any malicious intent.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170401/89362bb1/attachment.html>

From alex.gaynor at gmail.com  Sat Apr  1 15:08:27 2017
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Sat, 1 Apr 2017 15:08:27 -0400
Subject: [python-committers] I have blocked Wes Turner from the Python
 org on GitHub
In-Reply-To: <CAP1=2W5t9RF3ukhamEp_xTWTC8pRnCMd25P6TpsBK5EjJZZxug@mail.gmail.com>
References: <CAP1=2W5=ukka=32n4cUdRLs=tn059Nb9St_J-P2VR4u9Jo2E7g@mail.gmail.com>
 <72E84E8D-7517-433B-9E2B-FBA513276B77@gmail.com>
 <8d0fc725-5512-2d31-159e-a7c531a51ded@egenix.com>
 <CAP1=2W5t9RF3ukhamEp_xTWTC8pRnCMd25P6TpsBK5EjJZZxug@mail.gmail.com>
Message-ID: <CAFRnB2WTrcYsMTV3tuY46jZVBWjP-GRJWSjC-kDb6i-0Ti8cQQ@mail.gmail.com>

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 <brett at python.org> wrote:

>
>
> On Sat, 1 Apr 2017 at 09:27 M.-A. Lemburg <mal at egenix.com> wrote:
>
>> On 01.04.2017 05:44, Raymond Hettinger wrote:
>> >
>> >> On Mar 31, 2017, at 2:40 PM, Brett Cannon <brett at python.org> 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 read for a few
> months and I know multiple other people who have done the same).
>
> From what people have said in opposition to what I did, I think we need to
> have a discussion about two things:
>
> 1. Is it a CoC violation if someone chooses to ignore repeated warnings
> that their communication style is unproductive and thus a waste of people's
> time? And if people don't view it as an explicit CoC violation, do we still
> view it as enough reason to block someone but under a different name? (I
> obviously view it as a CoC violation.)
>
> 2. What is the exact procedure someone has to follow to instigate a ban
> (and this policy should probably cover GitHub, mailing lists, and anywhere
> else someone can be banned)? Is it having two core devs agree to the ban
> and it being publicly stated here (as MAL suggested)? Whatever approach we
> choose we should write it down in the devguide somewhere.
>
> As for Wes himself, I'm fine with the ban lasting only a couple months
> (say the end of May?). Based on the positive feedback I received on the ban
> I don't want to just drop it without at least some time passing to get the
> point across that something needs to change, but I also don't expect the
> ban to be permanent since there wasn't any malicious intent.
>
> _______________________________________________
> python-committers mailing list
> python-committers at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170401/4b0b76ea/attachment-0001.html>

From p.f.moore at gmail.com  Sat Apr  1 15:30:39 2017
From: p.f.moore at gmail.com (Paul Moore)
Date: Sat, 1 Apr 2017 20:30:39 +0100
Subject: [python-committers] I have blocked Wes Turner from the Python
 org on GitHub
In-Reply-To: <CAP1=2W5t9RF3ukhamEp_xTWTC8pRnCMd25P6TpsBK5EjJZZxug@mail.gmail.com>
References: <CAP1=2W5=ukka=32n4cUdRLs=tn059Nb9St_J-P2VR4u9Jo2E7g@mail.gmail.com>
 <72E84E8D-7517-433B-9E2B-FBA513276B77@gmail.com>
 <8d0fc725-5512-2d31-159e-a7c531a51ded@egenix.com>
 <CAP1=2W5t9RF3ukhamEp_xTWTC8pRnCMd25P6TpsBK5EjJZZxug@mail.gmail.com>
Message-ID: <CACac1F_pxF93LojirmWDECY1kF2D=H5GZh_Fi=ikeSGe1L6N9A@mail.gmail.com>

On 1 April 2017 at 19:35, Brett Cannon <brett at python.org> wrote:
> From what people have said in opposition to what I did, I think we need to
> have a discussion about two things:
>
> 1. Is it a CoC violation if someone chooses to ignore repeated warnings that
> their communication style is unproductive and thus a waste of people's time?
> And if people don't view it as an explicit CoC violation, do we still view
> it as enough reason to block someone but under a different name? (I
> obviously view it as a CoC violation.)

In my view, it would be better described as a "moderation action" (or
something similar). There's a lot of implication when codes of conduct
get involved - the high profile cases tend to be about genuinely
unacceptable behaviour such as harassment, and so it's easy for people
who only hear about what happened second hand, to read more into the
situation than is maybe present.

> 2. What is the exact procedure someone has to follow to instigate a ban (and
> this policy should probably cover GitHub, mailing lists, and anywhere else
> someone can be banned)? Is it having two core devs agree to the ban and it
> being publicly stated here (as MAL suggested)? Whatever approach we choose
> we should write it down in the devguide somewhere.

I agree we should write the process down. My suggestion would be that
the process as described by Nick (which is what you actually followed)
be described as how we deal with people who have demonstrated an
inability to work effectively with the community ("Moderation" is the
best term I can come up with for this process, but I don't think it's
ideal). The Code of Conduct process should (IMO) be reserved for
immediate exclusion of people who have demonstrated inappropriate
behaviour, and it should be very much a last resort action, and
require consensus between a number of core devs to institute.

> As for Wes himself, I'm fine with the ban lasting only a couple months (say
> the end of May?). Based on the positive feedback I received on the ban I
> don't want to just drop it without at least some time passing to get the
> point across that something needs to change, but I also don't expect the ban
> to be permanent since there wasn't any malicious intent.

Just to be clear, I'm completely fine with the action you took with
regard to Wes. I can confirm that it's something that's been coming
for some time (I've interacted with Wes on a number of lists), and I
appreciate the fact that you took the hard decision and actually did
something. I'm just uncomfortable with describing it as a Code of
Conduct issue (which as Alex says, is typically associated more with
harassment and abuse).

Paul

From rdmurray at bitdance.com  Sat Apr  1 16:24:15 2017
From: rdmurray at bitdance.com (R. David Murray)
Date: Sat, 01 Apr 2017 16:24:15 -0400
Subject: [python-committers] I have blocked Wes Turner from the Python
 org on GitHub
In-Reply-To: <CAFRnB2WTrcYsMTV3tuY46jZVBWjP-GRJWSjC-kDb6i-0Ti8cQQ@mail.gmail.com>
References: <CAP1=2W5=ukka=32n4cUdRLs=tn059Nb9St_J-P2VR4u9Jo2E7g@mail.gmail.com>
 <72E84E8D-7517-433B-9E2B-FBA513276B77@gmail.com>
 <8d0fc725-5512-2d31-159e-a7c531a51ded@egenix.com>
 <CAP1=2W5t9RF3ukhamEp_xTWTC8pRnCMd25P6TpsBK5EjJZZxug@mail.gmail.com>
 <CAFRnB2WTrcYsMTV3tuY46jZVBWjP-GRJWSjC-kDb6i-0Ti8cQQ@mail.gmail.com>
Message-ID: <20170401202415.F2DF3B1800A@webabinitio.net>

On Sat, 01 Apr 2017 15:08:27 -0400, Alex Gaynor <alex.gaynor at gmail.com> wrote:
> 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

Add my voice to this set.  I agree especially with Alex's second
paragraph above, so I really appreciate Brett being willing to take
this on.

Regardless of whether or not Python's CoC technically covers this case
(I'm not going to argue that one way or another), as Alex observed:
in the world we currently live in that term has way to much freight
attached to be appropriate for the issue we have with Wes.  That's
sad, because it means it doesn't actually matter all that much what
the CoC actually *says* :(.

--David

From raymond.hettinger at gmail.com  Sat Apr  1 19:07:04 2017
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Sat, 1 Apr 2017 16:07:04 -0700
Subject: [python-committers] Proposal for procedures regarding CoC actions
Message-ID: <3969B8C1-9D9B-45BC-8278-3D8D0607E6F7@gmail.com>

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









From alexander.belopolsky at gmail.com  Sat Apr  1 20:21:07 2017
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Sat, 1 Apr 2017 20:21:07 -0400
Subject: [python-committers] Proposal for procedures regarding CoC
 actions
In-Reply-To: <3969B8C1-9D9B-45BC-8278-3D8D0607E6F7@gmail.com>
References: <3969B8C1-9D9B-45BC-8278-3D8D0607E6F7@gmail.com>
Message-ID: <CAP7h-xYfoPjqcCOH+401PNk629t2PiV+V-N9G3HB+h8LVT0Mzg@mail.gmail.com>

On Sat, Apr 1, 2017 at 7:07 PM, Raymond Hettinger <
raymond.hettinger at gmail.com> wrote:

> 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.


This reminds me of <https://en.wikipedia.org/wiki/NKVD_troika>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170401/c0fc80ba/attachment.html>

From raymond.hettinger at gmail.com  Sat Apr  1 20:43:58 2017
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Sat, 1 Apr 2017 17:43:58 -0700
Subject: [python-committers] Proposal for procedures regarding CoC
 actions
In-Reply-To: <CAP7h-xYfoPjqcCOH+401PNk629t2PiV+V-N9G3HB+h8LVT0Mzg@mail.gmail.com>
References: <3969B8C1-9D9B-45BC-8278-3D8D0607E6F7@gmail.com>
 <CAP7h-xYfoPjqcCOH+401PNk629t2PiV+V-N9G3HB+h8LVT0Mzg@mail.gmail.com>
Message-ID: <D40E7CC7-9966-4283-A8A5-FACD9FF3C672@gmail.com>


> On Apr 1, 2017, at 5:21 PM, Alexander Belopolsky <alexander.belopolsky at gmail.com> wrote:
> 
> 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.
> 
> This reminds me of <https://en.wikipedia.org/wiki/NKVD_troika>.

Well, they both have in common the number "three" :-)

There are however a couple of minor differences:

* One was tasked with "screening the peasant population of the entire Soviet Union" for the express purpose of "the liquidation of the kulaks as a class".

* The other is tasked with handling rare one-off situations where the stated goals are considering the needs of the community, being respectful as possible to all parties, and doing what they can to mitigate the harm to the violator.  The express intent is to protect the vibrancy of the Python community rather than acting with an intent to punish, humiliate, or discredit the affected person.

Other than than those minor differences, it is basically the same thing ;-)


Raymond Hettinger





From alexander.belopolsky at gmail.com  Sat Apr  1 21:39:36 2017
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Sat, 1 Apr 2017 21:39:36 -0400
Subject: [python-committers] Proposal for procedures regarding CoC
 actions
In-Reply-To: <D40E7CC7-9966-4283-A8A5-FACD9FF3C672@gmail.com>
References: <3969B8C1-9D9B-45BC-8278-3D8D0607E6F7@gmail.com>
 <CAP7h-xYfoPjqcCOH+401PNk629t2PiV+V-N9G3HB+h8LVT0Mzg@mail.gmail.com>
 <D40E7CC7-9966-4283-A8A5-FACD9FF3C672@gmail.com>
Message-ID: <CAP7h-xbppguVhwtF7jNuBJ4wDNdZijT+63rnR2fVn9N4pCQELg@mail.gmail.com>

On Sat, Apr 1, 2017 at 8:43 PM, Raymond Hettinger <
raymond.hettinger at gmail.com> wrote:

>
> * The other is tasked with handling rare one-off situations where the
> stated goals are considering the needs of the community, being respectful
> as possible to all parties, and doing what they can to mitigate the harm to
> the violator.  The express intent is to protect the vibrancy of the Python
> community rather than acting with an intent to punish, humiliate, or
> discredit the affected person.


Well, on the scale of things, the population of USSR in 1937 was 170
million and the number of people tried by the troikas was at highest
estimates around 700,000.  That's a lot, but still less than 0.5%.  Trust
me, people serving in troikas had sincere believes that they were
protecting the vibrant new community from those seeking to enslave people.

Luckily, in the Python community, episodes that require repressive actions
are rare enough that they can be dealt on a case by case basis without
causing much distraction.  There is no need to over-formalize the process.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170401/fa0979e6/attachment.html>

From steve at pearwood.info  Sun Apr  2 00:27:29 2017
From: steve at pearwood.info (Steven D'Aprano)
Date: Sun, 2 Apr 2017 14:27:29 +1000
Subject: [python-committers] Proposal for procedures regarding CoC
 actions
In-Reply-To: <CAP7h-xbppguVhwtF7jNuBJ4wDNdZijT+63rnR2fVn9N4pCQELg@mail.gmail.com>
References: <3969B8C1-9D9B-45BC-8278-3D8D0607E6F7@gmail.com>
 <CAP7h-xYfoPjqcCOH+401PNk629t2PiV+V-N9G3HB+h8LVT0Mzg@mail.gmail.com>
 <D40E7CC7-9966-4283-A8A5-FACD9FF3C672@gmail.com>
 <CAP7h-xbppguVhwtF7jNuBJ4wDNdZijT+63rnR2fVn9N4pCQELg@mail.gmail.com>
Message-ID: <20170402042729.GH9464@ando.pearwood.info>

On Sat, Apr 01, 2017 at 09:39:36PM -0400, Alexander Belopolsky wrote:

> Luckily, in the Python community, episodes that require repressive actions
> are rare enough that they can be dealt on a case by case basis without
> causing much distraction.  There is no need to over-formalize the process.

"Over" formalize, of course not. We don't want an excess of bureaucracy, 
but who is to say that Raymond's suggestion is an excess?

Let me preface this by saying that 9 times out of 10, I read the first 
few lines of Wes' emails and hit delete. And the other time I just hit 
delete. I find his posting style annoying and pointless: if there's 
anything of value in them, I can't see it because he doesn't leave 
enough or any context. And frankly, I support Brett's decision to give 
him a temporary ban for (apparently) using the Python/Github 
infrastructure as a personal notepad, wasting people's time.

If that were all Brett had done, I would think "Job well done" and move 
on.

But he didn't. He labelled Wes a CoC violator, both privately and in 
public, for something which is a violation of the CoC only by *really* 
stretching the definition. I mean, come on now, insufficiently 
respectful of people's time? How Orwellian can you get?

I think that's a mistake. A small mistake, to be sure, and I don't 
intend to crucify Brett over it. Brett generally does a great job. But 
small mistakes grow to big mistakes, and I think that this demonstrates 
that Raymond is right, we do need *some* oversight and process before 
labelling people a CoC violator and kicking them out on that basis.

I am concerned about the scope-creep and over-use of the CoC nuclear 
option. This is not the first time either: in my opinion, the proponents 
of the CoC have consistently promised not to do certain things, then 
done so. They promised not to unilaterally add the CoC to mailing lists 
without consultation, then did so. They promised not to use the CoC to 
ban people for trivial offenses, and have done so.

I shouldn't need to say this, but for the avoidance of doubt I DON'T see 
this as part of some disastardly plot by the forces of multi-culturalism 
to suppress dissent. I don't think Brett and others are bad people 
intentionally excluding different viewpoints. I think that their 
intentions are good.

So please don't read this as a total condemnation or censure of Brett. I 
think he was well within his authority as admin to apply a temporary ban 
to Wes. Where I think he overstepped the boundary was by labelling it a 
CoC violation. Words do matter, and while I appreciate this is not the 
same sort of harm as labelling somebody a paedophile or sex offender, 
"banned for violating the CoC" is not something we should say lightly.

Over on Python-Ideas, I've just responded negatively to a technical 
suggestion by Ram Rachum. In my opinion, Ram has a habit of making 
poorly thought-out, superficially-useful suggestions which are 
invariably rejected. Should we hit him with the hammer of "Code of 
Conduct violation" for being insufficiently respectful of people's time? 

A lot of people probably think that *my* posts are excessively pedantic, 
detailed and verbose. Including this one. I've been told off (off-list) 
by at least one senior developer for being too long-winded. Is that a 
CoC violation?

Based on the precedent now set by Wes' ban, the answer could be Yes. Is 
that what the community wants? Is that a good way to encourage a 
diversity of viewpoints and people?

I don't think so.

I don't see any malice in Brett's actions, I think it was just a 
miscalculation. But it normalises the use of CoC for a trivial offense 
that could be handled another way. It really should be a big deal to ban 
somebody for persistent violations of community standards, something we 
only apply to persist griefers, trolls, racists or sexists who insist on 
using the Python mailing lists etc to promote their hateful ideology, 
not just somebody who is apparently just socially awkward.

In a way, what Brett did is a bit like using anti-terrorism legislation 
against Wes for littering. You see, when he tossed that empty packet out 
of the car window, people might have thought it was hiding a grenade, 
and that makes it terrorism.

So I support Raymond's suggestion. I think this demonstrates that good 
intentions alone are not enough, we need a formal process to prevent CoC 
from being (unintentionally) abused, to prevent people being labelled as 
"CoC violators" for merely being a little *too* diverse.



-- 
Steve

From ncoghlan at gmail.com  Sun Apr  2 01:59:01 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 2 Apr 2017 15:59:01 +1000
Subject: [python-committers] Proposal for procedures regarding CoC
 actions
In-Reply-To: <20170402042729.GH9464@ando.pearwood.info>
References: <3969B8C1-9D9B-45BC-8278-3D8D0607E6F7@gmail.com>
 <CAP7h-xYfoPjqcCOH+401PNk629t2PiV+V-N9G3HB+h8LVT0Mzg@mail.gmail.com>
 <D40E7CC7-9966-4283-A8A5-FACD9FF3C672@gmail.com>
 <CAP7h-xbppguVhwtF7jNuBJ4wDNdZijT+63rnR2fVn9N4pCQELg@mail.gmail.com>
 <20170402042729.GH9464@ando.pearwood.info>
Message-ID: <CADiSq7es4vX1-V==-PXMFdWixgJFYH4HeJj1oAYPcus4aBGXsQ@mail.gmail.com>

On 2 April 2017 at 14:27, Steven D'Aprano <steve at pearwood.info> wrote:
> But he didn't. He labelled Wes a CoC violator, both privately and in
> public, for something which is a violation of the CoC only by *really*
> stretching the definition. I mean, come on now, insufficiently
> respectful of people's time? How Orwellian can you get?

I think this is the point of disconnect, as is Raymond's description
of CoC actions as "more of a nuclear option to be reserved for
egregious cases of harassment and abuse."

I'll say it right here: I *have* violated the Python CoC, especially
if you go back and look at discussions like those around the decision
to move away from open source Mercurial hosting to a proprietary git
hosting service. Many of the comments I made during those discussions
were *far* from being respectful or kind, and it took a long time for
me to become open to the idea that helping core developers spend less
time on CPython infrastructure maintenance or fighting with inadequate
ad hoc tooling might be a higher priority goal than helping to
encourage the use of version control tools and service that happen to
be written in Python.

When that kind of thing happens, it's usually because I was
sufficiently annoyed that I didn't go through my usual routine of
proofreading my emails and figuring out how to replace all the second
person pronouns with first person ones and otherwise filtering out the
unproductive noise that can get in the way of people understanding the
point I'm attempting to communicate. That step takes deliberate effort
on my part, but is paid back many times over by reducing the number of
pointless side arguments I'd otherwise get myself into. Proofreading
is also the point where I may decide not to send a particular message
at all, or switch it from a public rebuke to a private reminder of
more appropriate behaviour.

As far as I can tell, folks just tend not to remember those incidents
for long because:

- they're significantly outnumbered by the occasions where I was able
to communicate effectively and help other people achieve *their* goals
(or at least help them gain a better understanding of why their goals
may be unachievable)
- once I calm down, depending on the exact circumstances, I'll
sometimes explicitly apologise for the lack of restraint I exhibited

Whenever we anchor ourselves in an essentialist mindset of "basically
good people with good intentions will never violate a CoC out of
ignorance or as an emotional outburst", then it makes it *really* hard
to apply gentle nudges early in the process where we point out
borderline or outright unacceptable behaviour to people, and ask them
to apply self-moderation techniques to help provide a more enjoyable
environment for everyone else. It also makes it much harder for us as
individuals to say "That was an error on my part, I apologise, and I
will continue to strive to do better in the future".

And from the point of view of the impact on folks suspended and/or
banned, "I got suspended/banned from <channel> due to my inability to
follow explicit directions regarding my communications style" doesn't
seem to me all that different from "I got suspended/banned from
<channel> due to my inability to be respectful and kind towards my
fellow participants".

That said, for the benefit of channel moderators, I do think it would
be a good idea to define a shared set of explicit "Rules for Active
Participation" that are distinct from the more general Code of
Conduct, and are explicitly noted as being handled through moderator
actions focused on providing a productive collaboration environment.

For example:

1. PSF provided communication channels, such as mailing lists, issue
trackers, and code repositories, each exist for a particular purpose.
While initial off-topic posts will be met with a gentle redirection to
a more appropriate location, persistently posting off-topic items will
be grounds for suspension at the discretion of the moderators of that
particular communication channel
2. Messages are posted to be read by others, so it's important to be
respectful of the time and energy of readers, and have a clear purpose
in posting (e.g. asking a question, answering a question, clearly
reporting a problem, proposing a solution to a problem, clarifying a
point of confusion), rather than merely posting for the sake of
posting. As with off-topic posts, persistently disrespecting the time
and energy of readers will be grounds for suspension at the discretion
of the moderators of that particular communication channel
3. Quietly observing the available public communication channels
without actively participating is always an option
4. Keep in mind that neither the PSF nor any of the community channels
it provides offer any form of commercial customer support. Rather, all
communication channels are provided for the benefit of community
contributors and potential future contributors
5. Also keep in mind that there's a lot more to the internet than just
the PSF provided communication channels. Personal blogs, social media,
code hosting services, etc, can all provide a way to collect and
publish material that isn't considered suitable for any available PSF
provided channel
6. When in doubt about the appropriateness of a message, some good
ways to resolve that doubt can be to:
    * spend some more time observing the communications channel in
question, perhaps by browsing the archives of past messages
    * for mailing lists, explicitly *ask* the question that is
concerning you, as most mailing lists allow for at least some
meta-discussion regarding appropriate use of the list
    * for issue trackers and code repositories, look for a suitable
venue (such as a related mailing list) to ask the question
    * if you already know other participants in the channel, ask them
for private feedback first

The "be open, respectful, and kind" guidance in the CoC would then
mostly apply to the channel moderators responsible for enforcing those
Rules for Active Participation, since CoC violations on the
communication channels themselves would *also* break the suggested
rules 1 & 2 above (by being both off-topic and disrespectful of
readers time and energy).

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From p.f.moore at gmail.com  Sun Apr  2 07:34:23 2017
From: p.f.moore at gmail.com (Paul Moore)
Date: Sun, 2 Apr 2017 12:34:23 +0100
Subject: [python-committers] Proposal for procedures regarding CoC
 actions
In-Reply-To: <CADiSq7es4vX1-V==-PXMFdWixgJFYH4HeJj1oAYPcus4aBGXsQ@mail.gmail.com>
References: <3969B8C1-9D9B-45BC-8278-3D8D0607E6F7@gmail.com>
 <CAP7h-xYfoPjqcCOH+401PNk629t2PiV+V-N9G3HB+h8LVT0Mzg@mail.gmail.com>
 <D40E7CC7-9966-4283-A8A5-FACD9FF3C672@gmail.com>
 <CAP7h-xbppguVhwtF7jNuBJ4wDNdZijT+63rnR2fVn9N4pCQELg@mail.gmail.com>
 <20170402042729.GH9464@ando.pearwood.info>
 <CADiSq7es4vX1-V==-PXMFdWixgJFYH4HeJj1oAYPcus4aBGXsQ@mail.gmail.com>
Message-ID: <CACac1F-yRb6f7wwSXWNkkZXpqGU56PFapEsRCkH0HJ2i1it0Fg@mail.gmail.com>

On 2 April 2017 at 06:59, Nick Coghlan <ncoghlan at gmail.com> wrote:
[...]
> And from the point of view of the impact on folks suspended and/or
> banned, "I got suspended/banned from <channel> due to my inability to
> follow explicit directions regarding my communications style" doesn't
> seem to me all that different from "I got suspended/banned from
> <channel> due to my inability to be respectful and kind towards my
> fellow participants".
[...]

In principle, I agree with pretty much all of what you said. However,
the one point I disagree on is that describing someone as having
violated the code of conduct is no big deal. In your quote above, you
avoid the term "Code of Conduct", and I think that's pertinent.

While the Python community is the focus here, I think it's naive to
ignore what other parts of the technical community, and even wider
observers of that community, think. From what I can tell, people in
general are aware that the technical community has identified an issue
with how we handle diversity - openness to contributions from people
outside of the "white male technical geek" stereotype. The means that
technical communities have chosen to address that issue is perceived
as the adoption of explicit codes of conduct that clarify that
exclusive behaviour is unacceptable, and not to be tolerated.

As a result, the public perception of a "code of conduct violation" is
that someone has harassed, or otherwise made a community member
uncomfortable, specifically because they don't conform to the
stereotypical norm. That's not necessarily what any specific code of
conduct might say, but it's how the public perceives such things (and
high-profile blog entries that expose exclusive behaviour, and cite
codes of conduct and how they help and where they fail to, simply
reinforce that perception).

We may not like the fact that a simple term like "Code of Conduct"
gets appropriated in the public perception in such a way, but denying
the reality of it doesn't mean it doesn't happen.

As Raymond said, the health of the community must always come first,
and respecting all parties second. But we should *also* ensure that we
don't inadvertently harm the perpetrator of any violation - and to my
mind, referring to their behaviour using a term that means something
much more serious outside the Python community than it does
internally[1], is precisely the sort of inadvertent harm that we can,
and should, avoid.

Certainly, sometimes people are annoying, or are idiots. I know I can
be. Certainly, some people are persistently like that, and that's a
problem. But *anyone* can be like that - not just white, male
technical geeks. In my view, the point of the CoC should be that we
deal with everyone equally and respectfully, *including* how we deal
with them when they are being annoying idiots. And that means that we
need processes for handling such people that we can apply within the
context of our commitment to inclusivity (to the extent, for example,
that we have to be *really* careful to ensure that we don't
mis-characterise genuine behavioural issues as "being an idiot", but
we still have means to help people with behavioural issues to interact
effectively with us). Moderation processes need to work alongside the
CoC, rather than being subsumed by them.

In summary, though, I think the issue here is simply one of how we
describe things. I think that as a community we do a good job, and
we're continually seeking to do better, which is great. But perception
is key, and terms can be loaded in ways that we may not agree with,
but have to deal with.

Paul

[1] And I think that one of the clear points from this thread is that
even internally, perceptions are not all the same.

From brett at python.org  Sun Apr  2 14:08:33 2017
From: brett at python.org (Brett Cannon)
Date: Sun, 02 Apr 2017 18:08:33 +0000
Subject: [python-committers] Proposal for procedures regarding CoC
 actions
In-Reply-To: <CACac1F-yRb6f7wwSXWNkkZXpqGU56PFapEsRCkH0HJ2i1it0Fg@mail.gmail.com>
References: <3969B8C1-9D9B-45BC-8278-3D8D0607E6F7@gmail.com>
 <CAP7h-xYfoPjqcCOH+401PNk629t2PiV+V-N9G3HB+h8LVT0Mzg@mail.gmail.com>
 <D40E7CC7-9966-4283-A8A5-FACD9FF3C672@gmail.com>
 <CAP7h-xbppguVhwtF7jNuBJ4wDNdZijT+63rnR2fVn9N4pCQELg@mail.gmail.com>
 <20170402042729.GH9464@ando.pearwood.info>
 <CADiSq7es4vX1-V==-PXMFdWixgJFYH4HeJj1oAYPcus4aBGXsQ@mail.gmail.com>
 <CACac1F-yRb6f7wwSXWNkkZXpqGU56PFapEsRCkH0HJ2i1it0Fg@mail.gmail.com>
Message-ID: <CAP1=2W5GHDvxJh=Ejri_vKSfTLsce=rAdeC6MJHr0vRssHJRoQ@mail.gmail.com>

Here's a step-by-step guide of how things would be handled with Raymond's
proposal -- which seems reasonable to me, BTW -- and can act as an initial
draft of what we can put in the devguide:

   1. A person is warned that they are violating the CoC by the moderator
   of the resource being used and it is explained to them how they are
   violating it in hopes that they change their behaviour
   2. Depending on the severity of the violation, the person in question
   may receive multiple warnings until they are told that one more violation
   will lead to a temporary ban
   3. If the person violates again after their final warning, the moderator
   of the resource being used has the right to temporarily ban the violator
   from the resource for a length of time of their choosing, but no more than
   3 months
      1. XXX or some length of time we all are comfortable with that
      doesn't require creating a panel like permanent banishment does;
      2. XXX and who can the person who is temporarily banned appeal to if
      they disagree? PSF board?
   4. When the person who was violating the CoC is allowed back into the
   resource, if they violate the CoC I permanent ban may be considered by
   convening a panel of three people to decide if a permanent ban is necessary
      1. If banishment occurs, it will be followed with an email to
      python-committers recording that the banishment has occurred and
who formed
      the panel in making that decision
      2. The person who has been banned may appeal to the PSF board if they
      disagree with the ban
   5. The moderator of the resource reserves the right to request from the
   PSF board a ban from all PSF-controlled resources if the violations of the
   CoC are deemed severe enough
      1. Banishment from two separate resources will automatically trigger
      a request of the PSF board to ban the violator from all PSF-controlled
      resources


On Sun, 2 Apr 2017 at 04:34 Paul Moore <p.f.moore at gmail.com> wrote:

> On 2 April 2017 at 06:59, Nick Coghlan <ncoghlan at gmail.com> wrote:
> [...]
> > And from the point of view of the impact on folks suspended and/or
> > banned, "I got suspended/banned from <channel> due to my inability to
> > follow explicit directions regarding my communications style" doesn't
> > seem to me all that different from "I got suspended/banned from
> > <channel> due to my inability to be respectful and kind towards my
> > fellow participants".
> [...]
>
> In principle, I agree with pretty much all of what you said. However,
> the one point I disagree on is that describing someone as having
> violated the code of conduct is no big deal. In your quote above, you
> avoid the term "Code of Conduct", and I think that's pertinent.
>
> While the Python community is the focus here, I think it's naive to
> ignore what other parts of the technical community, and even wider
> observers of that community, think. From what I can tell, people in
> general are aware that the technical community has identified an issue
> with how we handle diversity - openness to contributions from people
> outside of the "white male technical geek" stereotype. The means that
> technical communities have chosen to address that issue is perceived
> as the adoption of explicit codes of conduct that clarify that
> exclusive behaviour is unacceptable, and not to be tolerated.
>
> As a result, the public perception of a "code of conduct violation" is
> that someone has harassed, or otherwise made a community member
> uncomfortable, specifically because they don't conform to the
> stereotypical norm. That's not necessarily what any specific code of
> conduct might say, but it's how the public perceives such things (and
> high-profile blog entries that expose exclusive behaviour, and cite
> codes of conduct and how they help and where they fail to, simply
> reinforce that perception).
>
> We may not like the fact that a simple term like "Code of Conduct"
> gets appropriated in the public perception in such a way, but denying
> the reality of it doesn't mean it doesn't happen.
>


> [SNIP]
>
> In summary, though, I think the issue here is simply one of how we
> describe things. I think that as a community we do a good job, and
> we're continually seeking to do better, which is great. But perception
> is key, and terms can be loaded in ways that we may not agree with,
> but have to deal with.
>


Assuming the outline of procedures I wrote up above is fine, what about
people like Wes who are consistently unproductive participants and thus are
IMO being disrespectful of others, just not in an overtly rude way? Do we
open with a sentence saying "In the steps below, a 'bad actor' is anyone
found violating the CoC or who is deemed to be a persistently unproductive
participant and thus being disrespectful of other people's time"? To me
that feels like saying "substitute with [CoC] or
[not-malicious-but-wasting-everyone's-time], whichever fits the situation".
And at that point I feel like we're treating CoC like a naughty word
because we're not willing to say that someone who is wasting people's time
isn't being disrespectful or inconsiderate even though they are.

But based on how others are stating their views, I'm seem to be in the
minority on this one. I'm fine with that as I can view it personally as
political wordsmithing. For me the key is that if I'm going to shoulder the
burden of being a moderator I want to have the ability to keep discussions
open, respectful, and considerate. If that means that someone gets a "CoC"
label when they run afoul of those tenants by being mean while they get an
"persistently unproductive" label when they run afoul of those labels in
how they communicate then I can live with that.

 P.S. I have removed the mention of the CoC from GitHub so that other than
the thread discussing this situation there isn't any disconnected record of
Wes violating the CoC.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170402/613efc58/attachment.html>

From mal at egenix.com  Sun Apr  2 16:07:39 2017
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun, 2 Apr 2017 22:07:39 +0200
Subject: [python-committers] Proposal for procedures regarding CoC
 actions
In-Reply-To: <3969B8C1-9D9B-45BC-8278-3D8D0607E6F7@gmail.com>
References: <3969B8C1-9D9B-45BC-8278-3D8D0607E6F7@gmail.com>
Message-ID: <c0702d67-0d0d-efde-048d-8650023fecb5@egenix.com>

Thanks, Raymond, this reads like a good proposal, but I'd like to
suggest that the three people in question are only intended to
discuss whether a CoC event has taken place or not and what the
person has to say about this.

They should then write up a summary to present to the PSF Board
which then decides. We have already had precedents for this and
it worked well.

No single moderator of a PSF resource should be allowed to impose
a ban on anyone. I also don't think that what Wes has done is
serious enough to be considered a CoC violation or that a ban
was the right action to take.

What I miss in the proposal is more emphasis on getting
feedback from the person in question (I often see CoC rule
sets miss out on this - even though it's one of the most basic
human rights principles: the right to a fair trial) and trying
to change behavior before CoC actions such as bans have to be
triggered.

In most cases, it's possible to find a way forward without
any actions and that's what we should strive for as a community.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Mar 31 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/



On 02.04.2017 01:07, Raymond Hettinger wrote:
> 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
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
> 


From ncoghlan at gmail.com  Sun Apr  2 23:04:24 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 3 Apr 2017 13:04:24 +1000
Subject: [python-committers] Proposal for procedures regarding CoC
 actions
In-Reply-To: <CAP1=2W5GHDvxJh=Ejri_vKSfTLsce=rAdeC6MJHr0vRssHJRoQ@mail.gmail.com>
References: <3969B8C1-9D9B-45BC-8278-3D8D0607E6F7@gmail.com>
 <CAP7h-xYfoPjqcCOH+401PNk629t2PiV+V-N9G3HB+h8LVT0Mzg@mail.gmail.com>
 <D40E7CC7-9966-4283-A8A5-FACD9FF3C672@gmail.com>
 <CAP7h-xbppguVhwtF7jNuBJ4wDNdZijT+63rnR2fVn9N4pCQELg@mail.gmail.com>
 <20170402042729.GH9464@ando.pearwood.info>
 <CADiSq7es4vX1-V==-PXMFdWixgJFYH4HeJj1oAYPcus4aBGXsQ@mail.gmail.com>
 <CACac1F-yRb6f7wwSXWNkkZXpqGU56PFapEsRCkH0HJ2i1it0Fg@mail.gmail.com>
 <CAP1=2W5GHDvxJh=Ejri_vKSfTLsce=rAdeC6MJHr0vRssHJRoQ@mail.gmail.com>
Message-ID: <CADiSq7dV3ZSsYbrm=skOOd5K4CY5op-s-KdZUZjH-HGq=SM_eQ@mail.gmail.com>

On 3 April 2017 at 04:08, Brett Cannon <brett at python.org> wrote:
> On Sun, 2 Apr 2017 at 04:34 Paul Moore <p.f.moore at gmail.com> wrote:
>> As a result, the public perception of a "code of conduct violation" is
>> that someone has harassed, or otherwise made a community member
>> uncomfortable, specifically because they don't conform to the
>> stereotypical norm. That's not necessarily what any specific code of
>> conduct might say, but it's how the public perceives such things (and
>> high-profile blog entries that expose exclusive behaviour, and cite
>> codes of conduct and how they help and where they fail to, simply
>> reinforce that perception).
>>
>> We may not like the fact that a simple term like "Code of Conduct"
>> gets appropriated in the public perception in such a way, but denying
>> the reality of it doesn't mean it doesn't happen.
>
> But based on how others are stating their views, I'm seem to be in the
> minority on this one. I'm fine with that as I can view it personally as
> political wordsmithing. For me the key is that if I'm going to shoulder the
> burden of being a moderator I want to have the ability to keep discussions
> open, respectful, and considerate. If that means that someone gets a "CoC"
> label when they run afoul of those tenants by being mean while they get an
> "persistently unproductive" label when they run afoul of those labels in how
> they communicate then I can live with that.

I essentially agree with Brett here, but I also agree with MAL that at
least for now we can keep this to a simpler two level system where:

1. We write down explicit rules for encouraging productive,
collaborative discussions on PSF provided communication channels,
together with the process that channel moderators are advised to
follow when imposing temporary suspensions of posting privileges. We
then explicitly adopt those rules for the core Python communication
channels (python-dev, python-ideas, core-mentorship, the issue tracker
and meta-tracker, the python org on GitHub) by updating the Developer
Guide appropriately. The trigger for lifting suspensions imposed at
this level can just be that: a) the minimum time period specified by
the moderators has passed; b) the person suspended explicitly requests
that the channel moderators restore their posting privileges.

Whether we call them "Rules for Active Participation" or something
else, this step gives channel moderators the explicit authority to
govern their channels according to their defined purpose, without
having to rely on the Code of Conduct as the sole mechanism for
ensuring that folks don't persist indefinitely in wasting other
people's time.

2. Anything that can't be handled through a temporary suspension of
posting privileges gets escalated to the elected PSF Board. For
example:

- cases where folks feel they have been suspended unfairly by moderators
- cases where moderators believe that a temporary suspension should be
converted to a permanent ban
- cases where moderators believe that a ban from selected channels
should be converted to a ban from all PSF provided communication
channels

This step ensures that channel moderators have a place to appeal for
assistance if behavioural management for particular individuals is
acting as a persistent drain on *their* time and energy, as well as
ensuring that there is a mechanism in place to request reviews of
moderator actions that seem to be unreasonable.

The PSF Board has several desirable properties for this purpose:

1. As the responsible legal entity, the PSF is already the de facto
point of escalation for conduct related concerns on PSF provided
communication channels
2. Since the switch to an open membership model for the PSF, the Board
is a genuinely representative body for the community at large
3. As an elected body, the accountaibility mechanism for Board level
decision making is built into the PSF By-laws
4. The Board membership list at any given point in time is public information
5. The Board is already set up to handle confidential discussion of
sensitive matters
6. The Board are in a good position to request PSF staff assistance in
handling such matters when it seems appropriate to do so

If we started out by formalising that existing two level model of
resource-specific moderators + the PSF (as represented by the Board),
it would then be up to the *Board* to decide if it needed a formal
process for delegating such discussions and decisions to a smaller
group.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From brett at python.org  Fri Apr  7 14:39:28 2017
From: brett at python.org (Brett Cannon)
Date: Fri, 07 Apr 2017 18:39:28 +0000
Subject: [python-committers] A status check for issue number is coming soon
Message-ID: <CAP1=2W4HWdhUR5AcbtWJ1ByaWOcJGNJavrBMVFJMhQmO2pFsBA@mail.gmail.com>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170407/8ab0136f/attachment.html>

From senthil at uthcode.com  Sun Apr  9 15:09:46 2017
From: senthil at uthcode.com (Senthil Kumaran)
Date: Sun, 9 Apr 2017 12:09:46 -0700
Subject: [python-committers] Deprecation Policy PEP Thread
Message-ID: <CAPOVWOT1PpuG_NjUZhTM5XPSJo1eS3c7VxaR5hD_09Ujk_3KhQ@mail.gmail.com>

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

From tjreedy at udel.edu  Sun Apr  9 15:20:07 2017
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 9 Apr 2017 15:20:07 -0400
Subject: [python-committers] Deprecation Policy PEP Thread
In-Reply-To: <CAPOVWOT1PpuG_NjUZhTM5XPSJo1eS3c7VxaR5hD_09Ujk_3KhQ@mail.gmail.com>
References: <CAPOVWOT1PpuG_NjUZhTM5XPSJo1eS3c7VxaR5hD_09Ujk_3KhQ@mail.gmail.com>
Message-ID: <bf414627-6300-8db9-fcac-c458e2648f32@udel.edu>

On 4/9/2017 3:09 PM, Senthil Kumaran wrote:
> 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?

Yes.  I suspect that there is something in the devguide also, but users 
as well as contributors have an interest in the subject.

tjr


From mariatta.wijaya at gmail.com  Sun Apr  9 18:08:15 2017
From: mariatta.wijaya at gmail.com (Mariatta Wijaya)
Date: Mon, 10 Apr 2017 00:08:15 +0200
Subject: [python-committers] Deprecation Policy PEP Thread
In-Reply-To: <bf414627-6300-8db9-fcac-c458e2648f32@udel.edu>
References: <CAPOVWOT1PpuG_NjUZhTM5XPSJo1eS3c7VxaR5hD_09Ujk_3KhQ@mail.gmail.com>
 <bf414627-6300-8db9-fcac-c458e2648f32@udel.edu>
Message-ID: <CAGbohnZXmyE0oox9i8egEJTT6PiKhK-a6YG+sxYNHHj22PEUUw@mail.gmail.com>

> 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?

+1

> I suspect that there is something in the devguide also
I searched the devguide about deprecation policy, and it didn't turn up
anything.


Mariatta Wijaya

On Sun, Apr 9, 2017 at 9:20 PM, Terry Reedy <tjreedy at udel.edu> wrote:

> On 4/9/2017 3:09 PM, Senthil Kumaran wrote:
>
>> 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?
>>
>
> Yes.  I suspect that there is something in the devguide also, but users as
> well as contributors have an interest in the subject.
>
> tjr
>
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170410/ef555c2e/attachment.html>

From guido at python.org  Mon Apr 10 15:18:21 2017
From: guido at python.org (Guido van Rossum)
Date: Mon, 10 Apr 2017 12:18:21 -0700
Subject: [python-committers] [Core-mentorship] Regarding reviewing test
 cases written for tabnanny module
In-Reply-To: <865fb3dc-2985-9dc5-a00e-e0ffb10863aa@udel.edu>
References: <235331dd-4f42-dae9-9f94-a87dc3ee4184@gmail.com>
 <CAP7+vJKm6SU-6et8T_AQ2U0r6fz1yoEw5jSTy9B8kqk6q++iuw@mail.gmail.com>
 <865fb3dc-2985-9dc5-a00e-e0ffb10863aa@udel.edu>
Message-ID: <CAP7+vJJjNok8nOsUhkVy7BbUGVDduBmseo=BeGkkyu6Z5pbyhA@mail.gmail.com>

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 at 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 at python.org
> https://mail.python.org/mailman/listinfo/core-mentorship
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170410/a228f1ed/attachment.html>

From brett at python.org  Mon Apr 10 19:11:24 2017
From: brett at python.org (Brett Cannon)
Date: Mon, 10 Apr 2017 23:11:24 +0000
Subject: [python-committers] A status check for issue number is coming
 soon
In-Reply-To: <CAP1=2W4HWdhUR5AcbtWJ1ByaWOcJGNJavrBMVFJMhQmO2pFsBA@mail.gmail.com>
References: <CAP1=2W4HWdhUR5AcbtWJ1ByaWOcJGNJavrBMVFJMhQmO2pFsBA@mail.gmail.com>
Message-ID: <CAP1=2W6gumzCZ4ZWi+cdirNHnjenUrs_bi-9=1AZdeC1f4Hy4A@mail.gmail.com>

I've activated Bedevere, so there will now be a status check for issue
numbers in the title of a PR. If a PR doesn't call for an issue number then
it can be labeled "trivial".

And the code for the bot lives at https://github.com/python/bedevere if
some messaging needs to be tweaked, etc.

On Fri, 7 Apr 2017 at 11:39 Brett Cannon <brett at python.org> wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170410/9accdb63/attachment.html>

From donald at stufft.io  Mon Apr 10 20:55:21 2017
From: donald at stufft.io (Donald Stufft)
Date: Mon, 10 Apr 2017 20:55:21 -0400
Subject: [python-committers] [Core-mentorship] Regarding reviewing test
 cases written for tabnanny module
In-Reply-To: <CAP7+vJJjNok8nOsUhkVy7BbUGVDduBmseo=BeGkkyu6Z5pbyhA@mail.gmail.com>
References: <235331dd-4f42-dae9-9f94-a87dc3ee4184@gmail.com>
 <CAP7+vJKm6SU-6et8T_AQ2U0r6fz1yoEw5jSTy9B8kqk6q++iuw@mail.gmail.com>
 <865fb3dc-2985-9dc5-a00e-e0ffb10863aa@udel.edu>
 <CAP7+vJJjNok8nOsUhkVy7BbUGVDduBmseo=BeGkkyu6Z5pbyhA@mail.gmail.com>
Message-ID: <F3B07F73-C257-4F4B-8177-CFD0426D9C61@stufft.io>

If someone makes a review on github (as opposed to a simple comment) I believe the state of the code as it was when that review as made can be viewed by hitting the ?View Changes? button next to that review in the timeline.

> On Apr 10, 2017, at 3:18 PM, Guido van Rossum <guido at python.org> wrote:
> 
> 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 at udel.edu <mailto:tjreedy at 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 <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 at python.org <mailto:Core-mentorship at python.org>
> https://mail.python.org/mailman/listinfo/core-mentorship <https://mail.python.org/mailman/listinfo/core-mentorship>
> 
> 
> 
> -- 
> --Guido van Rossum (python.org/~guido <http://python.org/~guido>)
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/


?
Donald Stufft



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170410/233b6a20/attachment-0001.html>

From mariatta.wijaya at gmail.com  Mon Apr 10 23:13:12 2017
From: mariatta.wijaya at gmail.com (Mariatta Wijaya)
Date: Tue, 11 Apr 2017 05:13:12 +0200
Subject: [python-committers] [Core-mentorship] Regarding reviewing test
 cases written for tabnanny module
In-Reply-To: <F3B07F73-C257-4F4B-8177-CFD0426D9C61@stufft.io>
References: <235331dd-4f42-dae9-9f94-a87dc3ee4184@gmail.com>
 <CAP7+vJKm6SU-6et8T_AQ2U0r6fz1yoEw5jSTy9B8kqk6q++iuw@mail.gmail.com>
 <865fb3dc-2985-9dc5-a00e-e0ffb10863aa@udel.edu>
 <CAP7+vJJjNok8nOsUhkVy7BbUGVDduBmseo=BeGkkyu6Z5pbyhA@mail.gmail.com>
 <F3B07F73-C257-4F4B-8177-CFD0426D9C61@stufft.io>
Message-ID: <CAGbohnZQYxDxDP8ipcLdPdmF+FrMmTGnTkYD2fzWL43Sk1aCZQ@mail.gmail.com>

"View Changes" doesn't work when commits in PR were squashed, which seems
to be the case in https://github.com/python/cpython/pull/851

I wonder if there is a way to unsquash the commits? Will it help with
reviewing this PR?

Mariatta Wijaya

On Tue, Apr 11, 2017 at 2:55 AM, Donald Stufft <donald at stufft.io> wrote:

> If someone makes a review on github (as opposed to a simple comment) I
> believe the state of the code as it was when that review as made can be
> viewed by hitting the ?View Changes? button next to that review in the
> timeline.
>
> On Apr 10, 2017, at 3:18 PM, Guido van Rossum <guido at python.org> wrote:
>
> 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 at 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 at python.org
>> https://mail.python.org/mailman/listinfo/core-mentorship
>>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>
>
> ?
> Donald Stufft
>
>
>
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170411/24e3de96/attachment.html>

From vadmium+py at gmail.com  Mon Apr 10 23:55:02 2017
From: vadmium+py at gmail.com (Martin Panter)
Date: Tue, 11 Apr 2017 13:55:02 +1000
Subject: [python-committers] [Core-mentorship] Regarding reviewing test
 cases written for tabnanny module
In-Reply-To: <CAGbohnZQYxDxDP8ipcLdPdmF+FrMmTGnTkYD2fzWL43Sk1aCZQ@mail.gmail.com>
References: <235331dd-4f42-dae9-9f94-a87dc3ee4184@gmail.com>
 <CAP7+vJKm6SU-6et8T_AQ2U0r6fz1yoEw5jSTy9B8kqk6q++iuw@mail.gmail.com>
 <865fb3dc-2985-9dc5-a00e-e0ffb10863aa@udel.edu>
 <CAP7+vJJjNok8nOsUhkVy7BbUGVDduBmseo=BeGkkyu6Z5pbyhA@mail.gmail.com>
 <F3B07F73-C257-4F4B-8177-CFD0426D9C61@stufft.io>
 <CAGbohnZQYxDxDP8ipcLdPdmF+FrMmTGnTkYD2fzWL43Sk1aCZQ@mail.gmail.com>
Message-ID: <CA+eR4cG817mTN5d-DFOkuFuxQ1CzCGHtX4ouw9xWou+DzqAcnQ@mail.gmail.com>

On 11 April 2017 at 13:13, Mariatta Wijaya <mariatta.wijaya at gmail.com> wrote:
> "View Changes" doesn't work when commits in PR were squashed, which seems to
> be the case in https://github.com/python/cpython/pull/851
>
> I wonder if there is a way to unsquash the commits? Will it help with
> reviewing this PR?
>
> Mariatta Wijaya
>
> On Tue, Apr 11, 2017 at 2:55 AM, Donald Stufft <donald at stufft.io> wrote:
>>
>> If someone makes a review on github (as opposed to a simple comment) I
>> believe the state of the code as it was when that review as made can be
>> viewed by hitting the ?View Changes? button next to that review in the
>> timeline.
>>
>> On Apr 10, 2017, at 3:18 PM, Guido van Rossum <guido at python.org> wrote:
>>
>> 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 at 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.

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.

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.)

From guido at python.org  Tue Apr 11 00:53:44 2017
From: guido at python.org (Guido van Rossum)
Date: Mon, 10 Apr 2017 21:53:44 -0700
Subject: [python-committers] [Core-mentorship] Regarding reviewing test
 cases written for tabnanny module
In-Reply-To: <CA+eR4cG817mTN5d-DFOkuFuxQ1CzCGHtX4ouw9xWou+DzqAcnQ@mail.gmail.com>
References: <235331dd-4f42-dae9-9f94-a87dc3ee4184@gmail.com>
 <CAP7+vJKm6SU-6et8T_AQ2U0r6fz1yoEw5jSTy9B8kqk6q++iuw@mail.gmail.com>
 <865fb3dc-2985-9dc5-a00e-e0ffb10863aa@udel.edu>
 <CAP7+vJJjNok8nOsUhkVy7BbUGVDduBmseo=BeGkkyu6Z5pbyhA@mail.gmail.com>
 <F3B07F73-C257-4F4B-8177-CFD0426D9C61@stufft.io>
 <CAGbohnZQYxDxDP8ipcLdPdmF+FrMmTGnTkYD2fzWL43Sk1aCZQ@mail.gmail.com>
 <CA+eR4cG817mTN5d-DFOkuFuxQ1CzCGHtX4ouw9xWou+DzqAcnQ@mail.gmail.com>
Message-ID: <CAP7+vJ+PGtLSW7yh4=Q0dNj0nJicr=vK+b+DmMPE=F_SSwYzYA@mail.gmail.com>

On Mon, Apr 10, 2017 at 8:55 PM, Martin Panter <vadmium+py at gmail.com> 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.
>
> 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.)
>

We have some of this in the mypy project (though it's a much smaller
project). The workflow that I like best (not all contributors use it) is

- When the contributor makes multiple local commits without pushing to the
PR, I recommend using --amend unless they have several commits that
actually are logically distinct and relevant to the reviewer. (--amend is
especially important when fixing lint bugs or typos).

- Please don't use --amend across pushes to the PR

- It's OK to just pull+rebase and then use git push -f, but honestly
pull+merge is fine too

- When responding to a review please NEVER use commit --amend, that's where
reviewing becomes painful

- It's up to the reviewer who merges to rewrite the commit message: the
reviewer usually has a much better sense for what info in the commit
message will still be interesting a month or a year from now than the
contributor. (Often just copying the original comment from the top of the
PR is adequate.)

In mypy I recently disabled merge commits in mypy because some other
committers sometimes accidentally used it, and the history becomes really
ugly. (Maybe Brett already did this for cpython.)

I do agree that Rietveld's workflow is usually much more convenient, with
the exception of what it does around merging or rebasing other diffs.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170410/7dd0f70d/attachment-0001.html>

From chris.jerdonek at gmail.com  Tue Apr 11 02:29:16 2017
From: chris.jerdonek at gmail.com (Chris Jerdonek)
Date: Mon, 10 Apr 2017 23:29:16 -0700
Subject: [python-committers] [Core-mentorship] Regarding reviewing test
 cases written for tabnanny module
In-Reply-To: <CA+eR4cG817mTN5d-DFOkuFuxQ1CzCGHtX4ouw9xWou+DzqAcnQ@mail.gmail.com>
References: <235331dd-4f42-dae9-9f94-a87dc3ee4184@gmail.com>
 <CAP7+vJKm6SU-6et8T_AQ2U0r6fz1yoEw5jSTy9B8kqk6q++iuw@mail.gmail.com>
 <865fb3dc-2985-9dc5-a00e-e0ffb10863aa@udel.edu>
 <CAP7+vJJjNok8nOsUhkVy7BbUGVDduBmseo=BeGkkyu6Z5pbyhA@mail.gmail.com>
 <F3B07F73-C257-4F4B-8177-CFD0426D9C61@stufft.io>
 <CAGbohnZQYxDxDP8ipcLdPdmF+FrMmTGnTkYD2fzWL43Sk1aCZQ@mail.gmail.com>
 <CA+eR4cG817mTN5d-DFOkuFuxQ1CzCGHtX4ouw9xWou+DzqAcnQ@mail.gmail.com>
Message-ID: <CAOTb1wc3EPa=cA5bG3g-c5j=xy1mdAgFd378nACRVGEUof0YgA@mail.gmail.com>

On Mon, Apr 10, 2017 at 8:55 PM, Martin Panter <vadmium+py at gmail.com> 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 at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/

From rdmurray at bitdance.com  Tue Apr 11 10:21:49 2017
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 11 Apr 2017 10:21:49 -0400
Subject: [python-committers] Regarding reviewing test cases written for
 tabnanny module
In-Reply-To: <CAP7+vJ+PGtLSW7yh4=Q0dNj0nJicr=vK+b+DmMPE=F_SSwYzYA@mail.gmail.com>
References: <235331dd-4f42-dae9-9f94-a87dc3ee4184@gmail.com>
 <CAP7+vJKm6SU-6et8T_AQ2U0r6fz1yoEw5jSTy9B8kqk6q++iuw@mail.gmail.com>
 <865fb3dc-2985-9dc5-a00e-e0ffb10863aa@udel.edu>
 <CAP7+vJJjNok8nOsUhkVy7BbUGVDduBmseo=BeGkkyu6Z5pbyhA@mail.gmail.com>
 <F3B07F73-C257-4F4B-8177-CFD0426D9C61@stufft.io>
 <CAGbohnZQYxDxDP8ipcLdPdmF+FrMmTGnTkYD2fzWL43Sk1aCZQ@mail.gmail.com>
 <CA+eR4cG817mTN5d-DFOkuFuxQ1CzCGHtX4ouw9xWou+DzqAcnQ@mail.gmail.com>
 <CAP7+vJ+PGtLSW7yh4=Q0dNj0nJicr=vK+b+DmMPE=F_SSwYzYA@mail.gmail.com>
Message-ID: <20170411142149.5912C1310017@webabinitio.net>

On Mon, 10 Apr 2017 21:53:44 -0700, Guido van Rossum <guido at python.org> wrote:
> - When the contributor makes multiple local commits without pushing to the
> PR, I recommend using --amend unless they have several commits that
> actually are logically distinct and relevant to the reviewer. (--amend is
> especially important when fixing lint bugs or typos).
> 
> - Please don't use --amend across pushes to the PR
> 
> - It's OK to just pull+rebase and then use git push -f, but honestly
> pull+merge is fine too
> 
> - When responding to a review please NEVER use commit --amend, that's where
> reviewing becomes painful

In the devguide PR addressing this issue, I suggested we just say that
one should never force push to the PR.  I can see that a force
push after a rebase *before* addressing review comments would be fine,
but maybe it would be better to prefer merge since we're going to
squash at the end anyway.

> - It's up to the reviewer who merges to rewrite the commit message: the
> reviewer usually has a much better sense for what info in the commit
> message will still be interesting a month or a year from now than the
> contributor. (Often just copying the original comment from the top of the
> PR is adequate.)

Some of our core committers need to learn to do this :)

--David

From ncoghlan at gmail.com  Tue Apr 11 10:42:30 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 12 Apr 2017 00:42:30 +1000
Subject: [python-committers] Regarding reviewing test cases written for
 tabnanny module
In-Reply-To: <20170411142149.5912C1310017@webabinitio.net>
References: <235331dd-4f42-dae9-9f94-a87dc3ee4184@gmail.com>
 <CAP7+vJKm6SU-6et8T_AQ2U0r6fz1yoEw5jSTy9B8kqk6q++iuw@mail.gmail.com>
 <865fb3dc-2985-9dc5-a00e-e0ffb10863aa@udel.edu>
 <CAP7+vJJjNok8nOsUhkVy7BbUGVDduBmseo=BeGkkyu6Z5pbyhA@mail.gmail.com>
 <F3B07F73-C257-4F4B-8177-CFD0426D9C61@stufft.io>
 <CAGbohnZQYxDxDP8ipcLdPdmF+FrMmTGnTkYD2fzWL43Sk1aCZQ@mail.gmail.com>
 <CA+eR4cG817mTN5d-DFOkuFuxQ1CzCGHtX4ouw9xWou+DzqAcnQ@mail.gmail.com>
 <CAP7+vJ+PGtLSW7yh4=Q0dNj0nJicr=vK+b+DmMPE=F_SSwYzYA@mail.gmail.com>
 <20170411142149.5912C1310017@webabinitio.net>
Message-ID: <CADiSq7d4gu3jSvV7xRwQ7_phdjabwR_QKCArV8hcmXqL2ngUvg@mail.gmail.com>

On 12 April 2017 at 00:21, R. David Murray <rdmurray at bitdance.com> wrote:
> On Mon, 10 Apr 2017 21:53:44 -0700, Guido van Rossum <guido at python.org> wrote:
>> - When the contributor makes multiple local commits without pushing to the
>> PR, I recommend using --amend unless they have several commits that
>> actually are logically distinct and relevant to the reviewer. (--amend is
>> especially important when fixing lint bugs or typos).
>>
>> - Please don't use --amend across pushes to the PR
>>
>> - It's OK to just pull+rebase and then use git push -f, but honestly
>> pull+merge is fine too
>>
>> - When responding to a review please NEVER use commit --amend, that's where
>> reviewing becomes painful
>
> In the devguide PR addressing this issue, I suggested we just say that
> one should never force push to the PR.  I can see that a force
> push after a rebase *before* addressing review comments would be fine,
> but maybe it would be better to prefer merge since we're going to
> squash at the end anyway.

Yeah, Serhiy made this point when we were working on the instructions
for committers editing a contributor's PR branch:
https://docs.python.org/devguide/gitbootcamp.html#editing-a-pull-request-prior-to-merging

Since we do the squash & merge to get an atomic commit at the end, it
doesn't make sense to do any force pushes along the way.

>> - It's up to the reviewer who merges to rewrite the commit message: the
>> reviewer usually has a much better sense for what info in the commit
>> message will still be interesting a month or a year from now than the
>> contributor. (Often just copying the original comment from the top of the
>> PR is adequate.)
>
> Some of our core committers need to learn to do this :)

Technically coming up with a meaningful message when committing
patches isn't a new requirement, but I admit it's a lot easier to
forget to clean things up when there's a big green button right in
front of you waiting to be pushed :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From guido at python.org  Tue Apr 11 11:57:05 2017
From: guido at python.org (Guido van Rossum)
Date: Tue, 11 Apr 2017 08:57:05 -0700
Subject: [python-committers] Regarding reviewing test cases written for
 tabnanny module
In-Reply-To: <CADiSq7d4gu3jSvV7xRwQ7_phdjabwR_QKCArV8hcmXqL2ngUvg@mail.gmail.com>
References: <235331dd-4f42-dae9-9f94-a87dc3ee4184@gmail.com>
 <CAP7+vJKm6SU-6et8T_AQ2U0r6fz1yoEw5jSTy9B8kqk6q++iuw@mail.gmail.com>
 <865fb3dc-2985-9dc5-a00e-e0ffb10863aa@udel.edu>
 <CAP7+vJJjNok8nOsUhkVy7BbUGVDduBmseo=BeGkkyu6Z5pbyhA@mail.gmail.com>
 <F3B07F73-C257-4F4B-8177-CFD0426D9C61@stufft.io>
 <CAGbohnZQYxDxDP8ipcLdPdmF+FrMmTGnTkYD2fzWL43Sk1aCZQ@mail.gmail.com>
 <CA+eR4cG817mTN5d-DFOkuFuxQ1CzCGHtX4ouw9xWou+DzqAcnQ@mail.gmail.com>
 <CAP7+vJ+PGtLSW7yh4=Q0dNj0nJicr=vK+b+DmMPE=F_SSwYzYA@mail.gmail.com>
 <20170411142149.5912C1310017@webabinitio.net>
 <CADiSq7d4gu3jSvV7xRwQ7_phdjabwR_QKCArV8hcmXqL2ngUvg@mail.gmail.com>
Message-ID: <CAP7+vJ+MBTazvAyXrvUNFfaooTpi8CbbsdGK13BvOLM=_1ZtJg@mail.gmail.com>

On Tue, Apr 11, 2017 at 7:42 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> Since we do the squash & merge to get an atomic commit at the end, it
> doesn't make sense to do any force pushes along the way.
>

I was going to argue with this, but then I realized you're right. We
shouldn't need rebase any more, merge should be fine for all situations. (I
can think of exceptions but they aren't worth mentioning.)

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170411/7024e687/attachment.html>

From tjreedy at udel.edu  Tue Apr 11 12:25:09 2017
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 11 Apr 2017 12:25:09 -0400
Subject: [python-committers] [Core-mentorship] Regarding reviewing test
 cases written for tabnanny module
In-Reply-To: <CA+eR4cG817mTN5d-DFOkuFuxQ1CzCGHtX4ouw9xWou+DzqAcnQ@mail.gmail.com>
References: <235331dd-4f42-dae9-9f94-a87dc3ee4184@gmail.com>
 <CAP7+vJKm6SU-6et8T_AQ2U0r6fz1yoEw5jSTy9B8kqk6q++iuw@mail.gmail.com>
 <865fb3dc-2985-9dc5-a00e-e0ffb10863aa@udel.edu>
 <CAP7+vJJjNok8nOsUhkVy7BbUGVDduBmseo=BeGkkyu6Z5pbyhA@mail.gmail.com>
 <F3B07F73-C257-4F4B-8177-CFD0426D9C61@stufft.io>
 <CAGbohnZQYxDxDP8ipcLdPdmF+FrMmTGnTkYD2fzWL43Sk1aCZQ@mail.gmail.com>
 <CA+eR4cG817mTN5d-DFOkuFuxQ1CzCGHtX4ouw9xWou+DzqAcnQ@mail.gmail.com>
Message-ID: <c3a459ce-55a4-b95d-9b93-5d888aea4908@udel.edu>

On 4/10/2017 11:55 PM, Martin Panter wrote:
> On 11 April 2017 at 13:13, Mariatta Wijaya <mariatta.wijaya at gmail.com> wrote:
>> "View Changes" doesn't work when commits in PR were squashed, which seems to
>> be the case in https://github.com/python/cpython/pull/851
>>
>> I wonder if there is a way to unsquash the commits? Will it help with
>> reviewing this PR?

> 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.
>
> 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.)

I was under the impression that the green [commit] button would do the 
squashing.   Or at least that it could.

tjr


From donald at stufft.io  Tue Apr 11 13:21:58 2017
From: donald at stufft.io (Donald Stufft)
Date: Tue, 11 Apr 2017 13:21:58 -0400
Subject: [python-committers] [Core-mentorship] Regarding reviewing test
 cases written for tabnanny module
In-Reply-To: <c3a459ce-55a4-b95d-9b93-5d888aea4908@udel.edu>
References: <235331dd-4f42-dae9-9f94-a87dc3ee4184@gmail.com>
 <CAP7+vJKm6SU-6et8T_AQ2U0r6fz1yoEw5jSTy9B8kqk6q++iuw@mail.gmail.com>
 <865fb3dc-2985-9dc5-a00e-e0ffb10863aa@udel.edu>
 <CAP7+vJJjNok8nOsUhkVy7BbUGVDduBmseo=BeGkkyu6Z5pbyhA@mail.gmail.com>
 <F3B07F73-C257-4F4B-8177-CFD0426D9C61@stufft.io>
 <CAGbohnZQYxDxDP8ipcLdPdmF+FrMmTGnTkYD2fzWL43Sk1aCZQ@mail.gmail.com>
 <CA+eR4cG817mTN5d-DFOkuFuxQ1CzCGHtX4ouw9xWou+DzqAcnQ@mail.gmail.com>
 <c3a459ce-55a4-b95d-9b93-5d888aea4908@udel.edu>
Message-ID: <DB3ED680-6C1D-48B9-8220-37452DA44B6C@stufft.io>


> On Apr 11, 2017, at 12:25 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> 
> On 4/10/2017 11:55 PM, Martin Panter wrote:
>> On 11 April 2017 at 13:13, Mariatta Wijaya <mariatta.wijaya at gmail.com> wrote:
>>> "View Changes" doesn't work when commits in PR were squashed, which seems to
>>> be the case in https://github.com/python/cpython/pull/851
>>> 
>>> I wonder if there is a way to unsquash the commits? Will it help with
>>> reviewing this PR?
> 
>> 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.
>> 
>> 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.)
> 
> I was under the impression that the green [commit] button would do the squashing.   Or at least that it could.
> 

Yes it can, and IIRC for CPython we have it set so it _only_ does that. Although the commit message may be ugly if you don?t adjust it in the text editor that pops up when GitHub asks you to confirm the merge since it by default just concats all of the commit messages into a list so you might get a commit message like:

* implement feature

* fix thing

* ugh

* address review

Instead of a nice clean one. That?s going to be up to the person hitting the merge button to edit the commit message to be clean though.

?
Donald Stufft



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170411/c53bdd07/attachment.html>

From tjreedy at udel.edu  Tue Apr 11 14:30:29 2017
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 11 Apr 2017 14:30:29 -0400
Subject: [python-committers] [Core-mentorship] Regarding reviewing test
 cases written for tabnanny module
In-Reply-To: <DB3ED680-6C1D-48B9-8220-37452DA44B6C@stufft.io>
References: <235331dd-4f42-dae9-9f94-a87dc3ee4184@gmail.com>
 <CAP7+vJKm6SU-6et8T_AQ2U0r6fz1yoEw5jSTy9B8kqk6q++iuw@mail.gmail.com>
 <865fb3dc-2985-9dc5-a00e-e0ffb10863aa@udel.edu>
 <CAP7+vJJjNok8nOsUhkVy7BbUGVDduBmseo=BeGkkyu6Z5pbyhA@mail.gmail.com>
 <F3B07F73-C257-4F4B-8177-CFD0426D9C61@stufft.io>
 <CAGbohnZQYxDxDP8ipcLdPdmF+FrMmTGnTkYD2fzWL43Sk1aCZQ@mail.gmail.com>
 <CA+eR4cG817mTN5d-DFOkuFuxQ1CzCGHtX4ouw9xWou+DzqAcnQ@mail.gmail.com>
 <c3a459ce-55a4-b95d-9b93-5d888aea4908@udel.edu>
 <DB3ED680-6C1D-48B9-8220-37452DA44B6C@stufft.io>
Message-ID: <a8b2ddea-2d1a-8046-b13e-0bf0a92737cd@udel.edu>

On 4/11/2017 1:21 PM, Donald Stufft wrote:
>
>> On Apr 11, 2017, at 12:25 PM, Terry Reedy <tjreedy at udel.edu
>> <mailto:tjreedy at udel.edu>> wrote:

>> I was under the impression that the green [commit] button would do the
>> squashing.   Or at least that it could.
>>
>
> Yes it can, and IIRC for CPython we have it set so it _only_ does that.
> Although the commit message may be ugly if you don?t adjust it in the
> text editor that pops up when GitHub asks you to confirm the merge since
> it by default just concats all of the commit messages into a list so you
> might get a commit message like:
>
> * implement feature
>
> * fix thing
>
> * ugh
>
> * address review
>
> Instead of a nice clean one. That?s going to be up to the person hitting
> the merge button to edit the commit message to be clean though.

I think committers should always be responsible for the commit message. 
This will usually mean editing submissions from non-committers.  Since 
message is truncated to first line in some displays, the latter should 
summarize main point of commit.


From mariatta.wijaya at gmail.com  Tue Apr 11 23:10:01 2017
From: mariatta.wijaya at gmail.com (Mariatta Wijaya)
Date: Tue, 11 Apr 2017 20:10:01 -0700
Subject: [python-committers] [Core-mentorship] Regarding reviewing test
 cases written for tabnanny module
In-Reply-To: <a8b2ddea-2d1a-8046-b13e-0bf0a92737cd@udel.edu>
References: <235331dd-4f42-dae9-9f94-a87dc3ee4184@gmail.com>
 <CAP7+vJKm6SU-6et8T_AQ2U0r6fz1yoEw5jSTy9B8kqk6q++iuw@mail.gmail.com>
 <865fb3dc-2985-9dc5-a00e-e0ffb10863aa@udel.edu>
 <CAP7+vJJjNok8nOsUhkVy7BbUGVDduBmseo=BeGkkyu6Z5pbyhA@mail.gmail.com>
 <F3B07F73-C257-4F4B-8177-CFD0426D9C61@stufft.io>
 <CAGbohnZQYxDxDP8ipcLdPdmF+FrMmTGnTkYD2fzWL43Sk1aCZQ@mail.gmail.com>
 <CA+eR4cG817mTN5d-DFOkuFuxQ1CzCGHtX4ouw9xWou+DzqAcnQ@mail.gmail.com>
 <c3a459ce-55a4-b95d-9b93-5d888aea4908@udel.edu>
 <DB3ED680-6C1D-48B9-8220-37452DA44B6C@stufft.io>
 <a8b2ddea-2d1a-8046-b13e-0bf0a92737cd@udel.edu>
Message-ID: <CAGbohnYA+DNo6_TJkJw_scTPo_-0O30c=pTEd+H=acmy_m1zGg@mail.gmail.com>

So there is already a PR in the devguide advising contributors to keep
their commit history intact, see https://github.com/python/devguide/pull/162
Assuming people do read the devguide, then let's hope that we won't lose
the commit history going forward.

There is also already a section in the devguide instructing core devs to
clean up commit message, see http://cpython-devguide.re
adthedocs.io/gitbootcamp.html#accepting-and-merging-a-pull-request If this
is not clear enough, please propose a PR or file an issue.


Back to the original issue with reviewing the PR https://github.com/python/
cpython/pull/851

Other than not being able to review the diff, is there any other problem?
Can the PR be reviewed as is?

Martin, you said: "I?m not really set up to properly review and push stuff
with the new Git Hub setup,"
Are you wanting to make edits to the PR yourself?
If so, maybe you can try these instructions: http://cpython-devguide.
readthedocs.io/gitbootcamp.html#editing-a-pull-request-prior-to-merging



Mariatta Wijaya

On Tue, Apr 11, 2017 at 11:30 AM, Terry Reedy <tjreedy at udel.edu> wrote:

> On 4/11/2017 1:21 PM, Donald Stufft wrote:
>
>>
>> On Apr 11, 2017, at 12:25 PM, Terry Reedy <tjreedy at udel.edu
>>> <mailto:tjreedy at udel.edu>> wrote:
>>>
>>
> I was under the impression that the green [commit] button would do the
>>> squashing.   Or at least that it could.
>>>
>>>
>> Yes it can, and IIRC for CPython we have it set so it _only_ does that.
>> Although the commit message may be ugly if you don?t adjust it in the
>> text editor that pops up when GitHub asks you to confirm the merge since
>> it by default just concats all of the commit messages into a list so you
>> might get a commit message like:
>>
>> * implement feature
>>
>> * fix thing
>>
>> * ugh
>>
>> * address review
>>
>> Instead of a nice clean one. That?s going to be up to the person hitting
>> the merge button to edit the commit message to be clean though.
>>
>
> I think committers should always be responsible for the commit message.
> This will usually mean editing submissions from non-committers.  Since
> message is truncated to first line in some displays, the latter should
> summarize main point of commit.
>
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170411/9334aa55/attachment-0001.html>

From vadmium+py at gmail.com  Thu Apr 13 21:30:01 2017
From: vadmium+py at gmail.com (Martin Panter)
Date: Fri, 14 Apr 2017 01:30:01 +0000
Subject: [python-committers] [Core-mentorship] Regarding reviewing test
 cases written for tabnanny module
In-Reply-To: <CAGbohnYA+DNo6_TJkJw_scTPo_-0O30c=pTEd+H=acmy_m1zGg@mail.gmail.com>
References: <235331dd-4f42-dae9-9f94-a87dc3ee4184@gmail.com>
 <CAP7+vJKm6SU-6et8T_AQ2U0r6fz1yoEw5jSTy9B8kqk6q++iuw@mail.gmail.com>
 <865fb3dc-2985-9dc5-a00e-e0ffb10863aa@udel.edu>
 <CAP7+vJJjNok8nOsUhkVy7BbUGVDduBmseo=BeGkkyu6Z5pbyhA@mail.gmail.com>
 <F3B07F73-C257-4F4B-8177-CFD0426D9C61@stufft.io>
 <CAGbohnZQYxDxDP8ipcLdPdmF+FrMmTGnTkYD2fzWL43Sk1aCZQ@mail.gmail.com>
 <CA+eR4cG817mTN5d-DFOkuFuxQ1CzCGHtX4ouw9xWou+DzqAcnQ@mail.gmail.com>
 <c3a459ce-55a4-b95d-9b93-5d888aea4908@udel.edu>
 <DB3ED680-6C1D-48B9-8220-37452DA44B6C@stufft.io>
 <a8b2ddea-2d1a-8046-b13e-0bf0a92737cd@udel.edu>
 <CAGbohnYA+DNo6_TJkJw_scTPo_-0O30c=pTEd+H=acmy_m1zGg@mail.gmail.com>
Message-ID: <CA+eR4cH7rHyZ9f9tZeLvhggjeqxjhgz6wthDqMnUCL7QsWJe0g@mail.gmail.com>

On 12 April 2017 at 03:10, Mariatta Wijaya <mariatta.wijaya at gmail.com> wrote:
> Back to the original issue with reviewing the PR
> https://github.com/python/cpython/pull/851
>
> Other than not being able to review the diff, is there any other problem?
> Can the PR be reviewed as is?
>
> Martin, you said: "I?m not really set up to properly review and push stuff
> with the new Git Hub setup,"
> Are you wanting to make edits to the PR yourself?
> If so, maybe you can try these instructions:
> http://cpython-devguide.readthedocs.io/gitbootcamp.html#editing-a-pull-request-prior-to-merging

At the moment I don?t have the setup nor time to spend on this, sorry.
If I were in a position to download the pull request and properly
review and test it out, I may want to negotiate changes with the
original contributor, or failing that, make edits myself, but i?m not
intending to do this right now.

> On Tue, Apr 11, 2017 at 11:30 AM, Terry Reedy <tjreedy at udel.edu> wrote:
>> I think committers should always be responsible for the commit message.
>> This will usually mean editing submissions from non-committers.  Since
>> message is truncated to first line in some displays, the latter should
>> summarize main point of commit.

From ncoghlan at gmail.com  Fri Apr 14 10:02:11 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 15 Apr 2017 00:02:11 +1000
Subject: [python-committers] Regarding reviewing test cases written for
 tabnanny module
In-Reply-To: <CAP7+vJ+MBTazvAyXrvUNFfaooTpi8CbbsdGK13BvOLM=_1ZtJg@mail.gmail.com>
References: <235331dd-4f42-dae9-9f94-a87dc3ee4184@gmail.com>
 <CAP7+vJKm6SU-6et8T_AQ2U0r6fz1yoEw5jSTy9B8kqk6q++iuw@mail.gmail.com>
 <865fb3dc-2985-9dc5-a00e-e0ffb10863aa@udel.edu>
 <CAP7+vJJjNok8nOsUhkVy7BbUGVDduBmseo=BeGkkyu6Z5pbyhA@mail.gmail.com>
 <F3B07F73-C257-4F4B-8177-CFD0426D9C61@stufft.io>
 <CAGbohnZQYxDxDP8ipcLdPdmF+FrMmTGnTkYD2fzWL43Sk1aCZQ@mail.gmail.com>
 <CA+eR4cG817mTN5d-DFOkuFuxQ1CzCGHtX4ouw9xWou+DzqAcnQ@mail.gmail.com>
 <CAP7+vJ+PGtLSW7yh4=Q0dNj0nJicr=vK+b+DmMPE=F_SSwYzYA@mail.gmail.com>
 <20170411142149.5912C1310017@webabinitio.net>
 <CADiSq7d4gu3jSvV7xRwQ7_phdjabwR_QKCArV8hcmXqL2ngUvg@mail.gmail.com>
 <CAP7+vJ+MBTazvAyXrvUNFfaooTpi8CbbsdGK13BvOLM=_1ZtJg@mail.gmail.com>
Message-ID: <CADiSq7d89ty1Bre6c3SER8AH_ubztz-CMAERbZcXdsEH1aqpag@mail.gmail.com>

On 12 April 2017 at 01:57, Guido van Rossum <guido at python.org> wrote:
> On Tue, Apr 11, 2017 at 7:42 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> Since we do the squash & merge to get an atomic commit at the end, it
>> doesn't make sense to do any force pushes along the way.
>
>
> I was going to argue with this, but then I realized you're right. We
> shouldn't need rebase any more, merge should be fine for all situations. (I
> can think of exceptions but they aren't worth mentioning.)

That was exactly my reaction when Serhiy pointed it out - I started to
argue the point, but then invalidated all my own arguments before
actually posting anything :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From storchaka at gmail.com  Fri Apr 14 13:15:07 2017
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Fri, 14 Apr 2017 20:15:07 +0300
Subject: [python-committers] Regarding reviewing test cases written for
 tabnanny module
In-Reply-To: <CADiSq7d89ty1Bre6c3SER8AH_ubztz-CMAERbZcXdsEH1aqpag@mail.gmail.com>
References: <235331dd-4f42-dae9-9f94-a87dc3ee4184@gmail.com>
 <CAP7+vJKm6SU-6et8T_AQ2U0r6fz1yoEw5jSTy9B8kqk6q++iuw@mail.gmail.com>
 <865fb3dc-2985-9dc5-a00e-e0ffb10863aa@udel.edu>
 <CAP7+vJJjNok8nOsUhkVy7BbUGVDduBmseo=BeGkkyu6Z5pbyhA@mail.gmail.com>
 <F3B07F73-C257-4F4B-8177-CFD0426D9C61@stufft.io>
 <CAGbohnZQYxDxDP8ipcLdPdmF+FrMmTGnTkYD2fzWL43Sk1aCZQ@mail.gmail.com>
 <CA+eR4cG817mTN5d-DFOkuFuxQ1CzCGHtX4ouw9xWou+DzqAcnQ@mail.gmail.com>
 <CAP7+vJ+PGtLSW7yh4=Q0dNj0nJicr=vK+b+DmMPE=F_SSwYzYA@mail.gmail.com>
 <20170411142149.5912C1310017@webabinitio.net>
 <CADiSq7d4gu3jSvV7xRwQ7_phdjabwR_QKCArV8hcmXqL2ngUvg@mail.gmail.com>
 <CAP7+vJ+MBTazvAyXrvUNFfaooTpi8CbbsdGK13BvOLM=_1ZtJg@mail.gmail.com>
 <CADiSq7d89ty1Bre6c3SER8AH_ubztz-CMAERbZcXdsEH1aqpag@mail.gmail.com>
Message-ID: <ocr02l$r0u$1@blaine.gmane.org>

On 14.04.17 17:02, Nick Coghlan wrote:
> On 12 April 2017 at 01:57, Guido van Rossum <guido at python.org> wrote:
>> On Tue, Apr 11, 2017 at 7:42 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>>
>>> Since we do the squash & merge to get an atomic commit at the end, it
>>> doesn't make sense to do any force pushes along the way.
>>
>>
>> I was going to argue with this, but then I realized you're right. We
>> shouldn't need rebase any more, merge should be fine for all situations. (I
>> can think of exceptions but they aren't worth mentioning.)
>
> That was exactly my reaction when Serhiy pointed it out - I started to
> argue the point, but then invalidated all my own arguments before
> actually posting anything :)

I don't remember I said anything about this.



From mariatta.wijaya at gmail.com  Fri Apr 14 21:24:03 2017
From: mariatta.wijaya at gmail.com (Mariatta Wijaya)
Date: Fri, 14 Apr 2017 18:24:03 -0700
Subject: [python-committers] cherry_picker.py updated
Message-ID: <CAGbohnYnPv+Uc6WPXwqPTj2euTbRWn7O3Lnbet-kjKvDoRcawA@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170414/fa151359/attachment.html>

From ncoghlan at gmail.com  Sat Apr 15 02:09:14 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 15 Apr 2017 16:09:14 +1000
Subject: [python-committers] Regarding reviewing test cases written for
 tabnanny module
In-Reply-To: <ocr02l$r0u$1@blaine.gmane.org>
References: <235331dd-4f42-dae9-9f94-a87dc3ee4184@gmail.com>
 <CAP7+vJKm6SU-6et8T_AQ2U0r6fz1yoEw5jSTy9B8kqk6q++iuw@mail.gmail.com>
 <865fb3dc-2985-9dc5-a00e-e0ffb10863aa@udel.edu>
 <CAP7+vJJjNok8nOsUhkVy7BbUGVDduBmseo=BeGkkyu6Z5pbyhA@mail.gmail.com>
 <F3B07F73-C257-4F4B-8177-CFD0426D9C61@stufft.io>
 <CAGbohnZQYxDxDP8ipcLdPdmF+FrMmTGnTkYD2fzWL43Sk1aCZQ@mail.gmail.com>
 <CA+eR4cG817mTN5d-DFOkuFuxQ1CzCGHtX4ouw9xWou+DzqAcnQ@mail.gmail.com>
 <CAP7+vJ+PGtLSW7yh4=Q0dNj0nJicr=vK+b+DmMPE=F_SSwYzYA@mail.gmail.com>
 <20170411142149.5912C1310017@webabinitio.net>
 <CADiSq7d4gu3jSvV7xRwQ7_phdjabwR_QKCArV8hcmXqL2ngUvg@mail.gmail.com>
 <CAP7+vJ+MBTazvAyXrvUNFfaooTpi8CbbsdGK13BvOLM=_1ZtJg@mail.gmail.com>
 <CADiSq7d89ty1Bre6c3SER8AH_ubztz-CMAERbZcXdsEH1aqpag@mail.gmail.com>
 <ocr02l$r0u$1@blaine.gmane.org>
Message-ID: <CADiSq7eXxjbNHUnk8-v4hr_u3dsRNuiUQVyu51n2piECLmDTSA@mail.gmail.com>

On 15 April 2017 at 03:15, Serhiy Storchaka <storchaka at gmail.com> wrote:
> On 14.04.17 17:02, Nick Coghlan wrote:
>> That was exactly my reaction when Serhiy pointed it out - I started to
>> argue the point, but then invalidated all my own arguments before
>> actually posting anything :)
>
> I don't remember I said anything about this.

My apologies, I misremembered who pointed that out to me. It was
actually Inada-san, here:
https://github.com/python/devguide/issues/129#issuecomment-281910027

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From ncoghlan at gmail.com  Sat Apr 15 02:10:07 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 15 Apr 2017 16:10:07 +1000
Subject: [python-committers] cherry_picker.py updated
In-Reply-To: <CAGbohnYnPv+Uc6WPXwqPTj2euTbRWn7O3Lnbet-kjKvDoRcawA@mail.gmail.com>
References: <CAGbohnYnPv+Uc6WPXwqPTj2euTbRWn7O3Lnbet-kjKvDoRcawA@mail.gmail.com>
Message-ID: <CADiSq7f7go4bY+wZSCL_NyXVO-f9v_=bitzd2OMnqm-VpvrnTA@mail.gmail.com>

On 15 April 2017 at 11:24, Mariatta Wijaya <mariatta.wijaya at gmail.com> wrote:
> 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.

Thank you for the enhancements!

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From victor.stinner at gmail.com  Fri Apr 21 18:29:25 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Sat, 22 Apr 2017 00:29:25 +0200
Subject: [python-committers] Codecov and PR
In-Reply-To: <CAMpsgwZrmBbF7bWWf2zzvgWN=o0iWgriVuPJi2t1j0CrwTYYJA@mail.gmail.com>
References: <CAMpsgwYB4J1u0kF7pAu_SjEHXNET3r45N=kHA4s8MD8fb4OD_Q@mail.gmail.com>
 <CAMpsgwZ8+tYgta1zWih4Yoewn4zAfBZ4wi1uB+f7itMToc53nQ@mail.gmail.com>
 <CAMpsgwZmSYzfmLwcAj+KpnsayUSFsQ4qdz83i3YGL=5zh6eSng@mail.gmail.com>
 <CAMpsgwa1rc0hiGDzvHkUzKB-8quD34yHVDE7UKYQfkPZvSHBqQ@mail.gmail.com>
 <CAMpsgwYFBC1qgEMV6MMBB1QwY0gb+B6xBhYiQqHPx66LNs8uzg@mail.gmail.com>
 <CAMpsgwY5yjsVeCy+Cmr_-5uuf6mvs=djPMFc6PidNdTnXVbABQ@mail.gmail.com>
 <CAMpsgwYPvnVna2N-b6CzqQkUYMMLcKOKa0L8Cbq=oUXfDFpYDg@mail.gmail.com>
 <CAMpsgwZ-vPGJ+zQPzkRPrAs2=VNSQKPhDgz4xngcuD8NOgc3tQ@mail.gmail.com>
 <CAMpsgwaBp_iH7Tb=LL1xmQDahxV9P4QZK_rdDrAVbUvnZc5_oA@mail.gmail.com>
 <CAMpsgwb6byWRV0R3NtpKpTOXsafYkJ9L6HRaHVTP+3vhBG8TCA@mail.gmail.com>
 <CAMpsgwZzY8pRj9cJdDR8d74yomO2wDq-S0h=GijQLvEUUvNk9w@mail.gmail.com>
 <CAMpsgwaxb3P3nEP6XK6=wcVGVgJP-sdFSR20GxHqpjGSOUTtKw@mail.gmail.com>
 <CAMpsgwbFENwyaMjzGEFwUQGE7zHVbuiq81n2gr5DJj9xsuvMDg@mail.gmail.com>
 <CAMpsgwYCFV4ka_RAW1XufhVE1GSXqBh+YPJKhWkH=iRsukkf+A@mail.gmail.com>
 <CAMpsgwZ7cAUaAwsxYrhbfbNVWw0S8JXALhv8HsKGbrKFyvQteg@mail.gmail.com>
 <CAMpsgwaCf1h00C0WurfOZthgC1ncD5=_DPWpNKg_gczuqixTxg@mail.gmail.com>
 <CAMpsgwafQq-GDOGy108hK7gJMRsnFCPmMHhDmX+A2WRm2TBGfQ@mail.gmail.com>
 <CAMpsgwaAu70zKkQz8NOmkcCXm-9rShmrYrRZkgb_d48_Po-WEw@mail.gmail.com>
 <CAMpsgwYC-rR9aePxRH84RUOhKNrG=DzK9q5NvrV3Lgp3qEV7cw@mail.gmail.com>
 <CAMpsgwaJAzqpdN2JwSS-wxt8gGbf=BX1ubp4Kk4U5EuZg3N+6A@mail.gmail.com>
 <CAMpsgwZrmBbF7bWWf2zzvgWN=o0iWgriVuPJi2t1j0CrwTYYJA@mail.gmail.com>
Message-ID: <CAMpsgwY1Tqd6iX2SWYY0u=4uDp=YB5AFYUr=AsUBFO2otwCijg@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170422/4f84a9b9/attachment.html>

From victor.stinner at gmail.com  Fri Apr 21 18:33:20 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Sat, 22 Apr 2017 00:33:20 +0200
Subject: [python-committers] Codecov and PR
In-Reply-To: <CAMpsgwY1Tqd6iX2SWYY0u=4uDp=YB5AFYUr=AsUBFO2otwCijg@mail.gmail.com>
References: <CAMpsgwYB4J1u0kF7pAu_SjEHXNET3r45N=kHA4s8MD8fb4OD_Q@mail.gmail.com>
 <CAMpsgwZ8+tYgta1zWih4Yoewn4zAfBZ4wi1uB+f7itMToc53nQ@mail.gmail.com>
 <CAMpsgwZmSYzfmLwcAj+KpnsayUSFsQ4qdz83i3YGL=5zh6eSng@mail.gmail.com>
 <CAMpsgwa1rc0hiGDzvHkUzKB-8quD34yHVDE7UKYQfkPZvSHBqQ@mail.gmail.com>
 <CAMpsgwYFBC1qgEMV6MMBB1QwY0gb+B6xBhYiQqHPx66LNs8uzg@mail.gmail.com>
 <CAMpsgwY5yjsVeCy+Cmr_-5uuf6mvs=djPMFc6PidNdTnXVbABQ@mail.gmail.com>
 <CAMpsgwYPvnVna2N-b6CzqQkUYMMLcKOKa0L8Cbq=oUXfDFpYDg@mail.gmail.com>
 <CAMpsgwZ-vPGJ+zQPzkRPrAs2=VNSQKPhDgz4xngcuD8NOgc3tQ@mail.gmail.com>
 <CAMpsgwaBp_iH7Tb=LL1xmQDahxV9P4QZK_rdDrAVbUvnZc5_oA@mail.gmail.com>
 <CAMpsgwb6byWRV0R3NtpKpTOXsafYkJ9L6HRaHVTP+3vhBG8TCA@mail.gmail.com>
 <CAMpsgwZzY8pRj9cJdDR8d74yomO2wDq-S0h=GijQLvEUUvNk9w@mail.gmail.com>
 <CAMpsgwaxb3P3nEP6XK6=wcVGVgJP-sdFSR20GxHqpjGSOUTtKw@mail.gmail.com>
 <CAMpsgwbFENwyaMjzGEFwUQGE7zHVbuiq81n2gr5DJj9xsuvMDg@mail.gmail.com>
 <CAMpsgwYCFV4ka_RAW1XufhVE1GSXqBh+YPJKhWkH=iRsukkf+A@mail.gmail.com>
 <CAMpsgwZ7cAUaAwsxYrhbfbNVWw0S8JXALhv8HsKGbrKFyvQteg@mail.gmail.com>
 <CAMpsgwaCf1h00C0WurfOZthgC1ncD5=_DPWpNKg_gczuqixTxg@mail.gmail.com>
 <CAMpsgwafQq-GDOGy108hK7gJMRsnFCPmMHhDmX+A2WRm2TBGfQ@mail.gmail.com>
 <CAMpsgwaAu70zKkQz8NOmkcCXm-9rShmrYrRZkgb_d48_Po-WEw@mail.gmail.com>
 <CAMpsgwYC-rR9aePxRH84RUOhKNrG=DzK9q5NvrV3Lgp3qEV7cw@mail.gmail.com>
 <CAMpsgwaJAzqpdN2JwSS-wxt8gGbf=BX1ubp4Kk4U5EuZg3N+6A@mail.gmail.com>
 <CAMpsgwZrmBbF7bWWf2zzvgWN=o0iWgriVuPJi2t1j0CrwTYYJA@mail.gmail.com>
 <CAMpsgwY1Tqd6iX2SWYY0u=4uDp=YB5AFYUr=AsUBFO2otwCijg@mail.gmail.com>
Message-ID: <CAMpsgwYfhaj45H69UO91Y9QPZFbc0wCATFgsM=NAToKOAzbx=w@mail.gmail.com>

Ah, I found a workaround: Firefox on Android has a "[x] See the computer
version" option which allows the merge!?

Victor

Le 22 avr. 2017 12:29 AM, "Victor Stinner" <victor.stinner at gmail.com> a
?crit :

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170422/cefb6df1/attachment.html>

From brett at python.org  Sat Apr 22 12:43:42 2017
From: brett at python.org (Brett Cannon)
Date: Sat, 22 Apr 2017 16:43:42 +0000
Subject: [python-committers] Codecov and PR
In-Reply-To: <CAMpsgwYfhaj45H69UO91Y9QPZFbc0wCATFgsM=NAToKOAzbx=w@mail.gmail.com>
References: <CAMpsgwYB4J1u0kF7pAu_SjEHXNET3r45N=kHA4s8MD8fb4OD_Q@mail.gmail.com>
 <CAMpsgwZ8+tYgta1zWih4Yoewn4zAfBZ4wi1uB+f7itMToc53nQ@mail.gmail.com>
 <CAMpsgwZmSYzfmLwcAj+KpnsayUSFsQ4qdz83i3YGL=5zh6eSng@mail.gmail.com>
 <CAMpsgwa1rc0hiGDzvHkUzKB-8quD34yHVDE7UKYQfkPZvSHBqQ@mail.gmail.com>
 <CAMpsgwYFBC1qgEMV6MMBB1QwY0gb+B6xBhYiQqHPx66LNs8uzg@mail.gmail.com>
 <CAMpsgwY5yjsVeCy+Cmr_-5uuf6mvs=djPMFc6PidNdTnXVbABQ@mail.gmail.com>
 <CAMpsgwYPvnVna2N-b6CzqQkUYMMLcKOKa0L8Cbq=oUXfDFpYDg@mail.gmail.com>
 <CAMpsgwZ-vPGJ+zQPzkRPrAs2=VNSQKPhDgz4xngcuD8NOgc3tQ@mail.gmail.com>
 <CAMpsgwaBp_iH7Tb=LL1xmQDahxV9P4QZK_rdDrAVbUvnZc5_oA@mail.gmail.com>
 <CAMpsgwb6byWRV0R3NtpKpTOXsafYkJ9L6HRaHVTP+3vhBG8TCA@mail.gmail.com>
 <CAMpsgwZzY8pRj9cJdDR8d74yomO2wDq-S0h=GijQLvEUUvNk9w@mail.gmail.com>
 <CAMpsgwaxb3P3nEP6XK6=wcVGVgJP-sdFSR20GxHqpjGSOUTtKw@mail.gmail.com>
 <CAMpsgwbFENwyaMjzGEFwUQGE7zHVbuiq81n2gr5DJj9xsuvMDg@mail.gmail.com>
 <CAMpsgwYCFV4ka_RAW1XufhVE1GSXqBh+YPJKhWkH=iRsukkf+A@mail.gmail.com>
 <CAMpsgwZ7cAUaAwsxYrhbfbNVWw0S8JXALhv8HsKGbrKFyvQteg@mail.gmail.com>
 <CAMpsgwaCf1h00C0WurfOZthgC1ncD5=_DPWpNKg_gczuqixTxg@mail.gmail.com>
 <CAMpsgwafQq-GDOGy108hK7gJMRsnFCPmMHhDmX+A2WRm2TBGfQ@mail.gmail.com>
 <CAMpsgwaAu70zKkQz8NOmkcCXm-9rShmrYrRZkgb_d48_Po-WEw@mail.gmail.com>
 <CAMpsgwYC-rR9aePxRH84RUOhKNrG=DzK9q5NvrV3Lgp3qEV7cw@mail.gmail.com>
 <CAMpsgwaJAzqpdN2JwSS-wxt8gGbf=BX1ubp4Kk4U5EuZg3N+6A@mail.gmail.com>
 <CAMpsgwZrmBbF7bWWf2zzvgWN=o0iWgriVuPJi2t1j0CrwTYYJA@mail.gmail.com>
 <CAMpsgwY1Tqd6iX2SWYY0u=4uDp=YB5AFYUr=AsUBFO2otwCijg@mail.gmail.com>
 <CAMpsgwYfhaj45H69UO91Y9QPZFbc0wCATFgsM=NAToKOAzbx=w@mail.gmail.com>
Message-ID: <CAP1=2W4jhvXnQ4vkpTjf9wc3GAG8+xRi0j05jKmBQcFvL8rUWQ@mail.gmail.com>

On Fri, 21 Apr 2017 at 15:33 Victor Stinner <victor.stinner at gmail.com>
wrote:

> Ah, I found a workaround: Firefox on Android has a "[x] See the computer
> version" option which allows the merge!?
>
> Victor
>
> Le 22 avr. 2017 12:29 AM, "Victor Stinner" <victor.stinner at gmail.com> a
> ?crit :
>
>> 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."
>>
>
Well that's annoying.


>
>> 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.
>>
>
https://github.com/python/core-workflow/issues/38 is tracking trying to fix
the inconsistency problem and
https://github.com/python/core-workflow/issues/18 is tracking getting a
more complete coverage report.

I would like to see this fixed and it's on my workflow todo list, but
obviously that list is not short so I don't know when I will get to it
(especially since at some point I will need to take a workflow break and
actually write code and review PRs again ;) .


> 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?
>>
>
We might be able to turn off the status check. The config file is
https://github.com/python/cpython/blob/master/.codecov.yml and the docs are
at https://docs.codecov.io/docs/codecov-yaml (I'm on vacation so I don't
have time to look up the exact config change since I really shouldn't even
be replying to this email ;) .


>
>> 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?
>>
>
Codecov actually only runs under Travis, so it's only testing on Linux.


>
>> 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.
>>
>
I personally disagree as code that isn't tested isn't checked that at least
some semblance of backwards-compatibility is being kept. Now I'm not
advocating we must have explicit tests for every line or code, but I think
we should somehow exercise as much code as possible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170422/bfbb58b0/attachment.html>

From victor.stinner at gmail.com  Sat Apr 22 18:14:43 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Sun, 23 Apr 2017 00:14:43 +0200
Subject: [python-committers] Codecov and PR
In-Reply-To: <CAP1=2W4jhvXnQ4vkpTjf9wc3GAG8+xRi0j05jKmBQcFvL8rUWQ@mail.gmail.com>
References: <CAMpsgwYB4J1u0kF7pAu_SjEHXNET3r45N=kHA4s8MD8fb4OD_Q@mail.gmail.com>
 <CAMpsgwZ8+tYgta1zWih4Yoewn4zAfBZ4wi1uB+f7itMToc53nQ@mail.gmail.com>
 <CAMpsgwZmSYzfmLwcAj+KpnsayUSFsQ4qdz83i3YGL=5zh6eSng@mail.gmail.com>
 <CAMpsgwa1rc0hiGDzvHkUzKB-8quD34yHVDE7UKYQfkPZvSHBqQ@mail.gmail.com>
 <CAMpsgwYFBC1qgEMV6MMBB1QwY0gb+B6xBhYiQqHPx66LNs8uzg@mail.gmail.com>
 <CAMpsgwY5yjsVeCy+Cmr_-5uuf6mvs=djPMFc6PidNdTnXVbABQ@mail.gmail.com>
 <CAMpsgwYPvnVna2N-b6CzqQkUYMMLcKOKa0L8Cbq=oUXfDFpYDg@mail.gmail.com>
 <CAMpsgwZ-vPGJ+zQPzkRPrAs2=VNSQKPhDgz4xngcuD8NOgc3tQ@mail.gmail.com>
 <CAMpsgwaBp_iH7Tb=LL1xmQDahxV9P4QZK_rdDrAVbUvnZc5_oA@mail.gmail.com>
 <CAMpsgwb6byWRV0R3NtpKpTOXsafYkJ9L6HRaHVTP+3vhBG8TCA@mail.gmail.com>
 <CAMpsgwZzY8pRj9cJdDR8d74yomO2wDq-S0h=GijQLvEUUvNk9w@mail.gmail.com>
 <CAMpsgwaxb3P3nEP6XK6=wcVGVgJP-sdFSR20GxHqpjGSOUTtKw@mail.gmail.com>
 <CAMpsgwbFENwyaMjzGEFwUQGE7zHVbuiq81n2gr5DJj9xsuvMDg@mail.gmail.com>
 <CAMpsgwYCFV4ka_RAW1XufhVE1GSXqBh+YPJKhWkH=iRsukkf+A@mail.gmail.com>
 <CAMpsgwZ7cAUaAwsxYrhbfbNVWw0S8JXALhv8HsKGbrKFyvQteg@mail.gmail.com>
 <CAMpsgwaCf1h00C0WurfOZthgC1ncD5=_DPWpNKg_gczuqixTxg@mail.gmail.com>
 <CAMpsgwafQq-GDOGy108hK7gJMRsnFCPmMHhDmX+A2WRm2TBGfQ@mail.gmail.com>
 <CAMpsgwaAu70zKkQz8NOmkcCXm-9rShmrYrRZkgb_d48_Po-WEw@mail.gmail.com>
 <CAMpsgwYC-rR9aePxRH84RUOhKNrG=DzK9q5NvrV3Lgp3qEV7cw@mail.gmail.com>
 <CAMpsgwaJAzqpdN2JwSS-wxt8gGbf=BX1ubp4Kk4U5EuZg3N+6A@mail.gmail.com>
 <CAMpsgwZrmBbF7bWWf2zzvgWN=o0iWgriVuPJi2t1j0CrwTYYJA@mail.gmail.com>
 <CAMpsgwY1Tqd6iX2SWYY0u=4uDp=YB5AFYUr=AsUBFO2otwCijg@mail.gmail.com>
 <CAMpsgwYfhaj45H69UO91Y9QPZFbc0wCATFgsM=NAToKOAzbx=w@mail.gmail.com>
 <CAP1=2W4jhvXnQ4vkpTjf9wc3GAG8+xRi0j05jKmBQcFvL8rUWQ@mail.gmail.com>
Message-ID: <CAMpsgwaHdFkhVHVRq7zLr31xvoFsa4kpcL-RP2ehnCCa=EtWYg@mail.gmail.com>

Oh, I forgot something about Codecov: it took me 2 minutes to understand
why a PR gets the red icon whereas all tests pass and the merge button was
waiting for my click. In fact, Codecov failed but the test isn't blocking.
I would expect the green icon on the overall list of PR.

Well, it's not blocking, just surprising the first time.

It may be annoying when you really want to list PR where tests fail, for
example to reschedule Travis jobs if we fix a bug in master (which caused a
test failure).

Victor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170423/38c3a5fa/attachment.html>

From victor.stinner at gmail.com  Sat Apr 22 18:16:05 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Sun, 23 Apr 2017 00:16:05 +0200
Subject: [python-committers] Codecov and PR
In-Reply-To: <CAP1=2W4jhvXnQ4vkpTjf9wc3GAG8+xRi0j05jKmBQcFvL8rUWQ@mail.gmail.com>
References: <CAMpsgwYB4J1u0kF7pAu_SjEHXNET3r45N=kHA4s8MD8fb4OD_Q@mail.gmail.com>
 <CAMpsgwZ8+tYgta1zWih4Yoewn4zAfBZ4wi1uB+f7itMToc53nQ@mail.gmail.com>
 <CAMpsgwZmSYzfmLwcAj+KpnsayUSFsQ4qdz83i3YGL=5zh6eSng@mail.gmail.com>
 <CAMpsgwa1rc0hiGDzvHkUzKB-8quD34yHVDE7UKYQfkPZvSHBqQ@mail.gmail.com>
 <CAMpsgwYFBC1qgEMV6MMBB1QwY0gb+B6xBhYiQqHPx66LNs8uzg@mail.gmail.com>
 <CAMpsgwY5yjsVeCy+Cmr_-5uuf6mvs=djPMFc6PidNdTnXVbABQ@mail.gmail.com>
 <CAMpsgwYPvnVna2N-b6CzqQkUYMMLcKOKa0L8Cbq=oUXfDFpYDg@mail.gmail.com>
 <CAMpsgwZ-vPGJ+zQPzkRPrAs2=VNSQKPhDgz4xngcuD8NOgc3tQ@mail.gmail.com>
 <CAMpsgwaBp_iH7Tb=LL1xmQDahxV9P4QZK_rdDrAVbUvnZc5_oA@mail.gmail.com>
 <CAMpsgwb6byWRV0R3NtpKpTOXsafYkJ9L6HRaHVTP+3vhBG8TCA@mail.gmail.com>
 <CAMpsgwZzY8pRj9cJdDR8d74yomO2wDq-S0h=GijQLvEUUvNk9w@mail.gmail.com>
 <CAMpsgwaxb3P3nEP6XK6=wcVGVgJP-sdFSR20GxHqpjGSOUTtKw@mail.gmail.com>
 <CAMpsgwbFENwyaMjzGEFwUQGE7zHVbuiq81n2gr5DJj9xsuvMDg@mail.gmail.com>
 <CAMpsgwYCFV4ka_RAW1XufhVE1GSXqBh+YPJKhWkH=iRsukkf+A@mail.gmail.com>
 <CAMpsgwZ7cAUaAwsxYrhbfbNVWw0S8JXALhv8HsKGbrKFyvQteg@mail.gmail.com>
 <CAMpsgwaCf1h00C0WurfOZthgC1ncD5=_DPWpNKg_gczuqixTxg@mail.gmail.com>
 <CAMpsgwafQq-GDOGy108hK7gJMRsnFCPmMHhDmX+A2WRm2TBGfQ@mail.gmail.com>
 <CAMpsgwaAu70zKkQz8NOmkcCXm-9rShmrYrRZkgb_d48_Po-WEw@mail.gmail.com>
 <CAMpsgwYC-rR9aePxRH84RUOhKNrG=DzK9q5NvrV3Lgp3qEV7cw@mail.gmail.com>
 <CAMpsgwaJAzqpdN2JwSS-wxt8gGbf=BX1ubp4Kk4U5EuZg3N+6A@mail.gmail.com>
 <CAMpsgwZrmBbF7bWWf2zzvgWN=o0iWgriVuPJi2t1j0CrwTYYJA@mail.gmail.com>
 <CAMpsgwY1Tqd6iX2SWYY0u=4uDp=YB5AFYUr=AsUBFO2otwCijg@mail.gmail.com>
 <CAMpsgwYfhaj45H69UO91Y9QPZFbc0wCATFgsM=NAToKOAzbx=w@mail.gmail.com>
 <CAP1=2W4jhvXnQ4vkpTjf9wc3GAG8+xRi0j05jKmBQcFvL8rUWQ@mail.gmail.com>
Message-ID: <CAMpsgwa+6N7F7UgEoHZB4_Qg5ZTDu+JL6ncTxrU3iR-x_bVQzQ@mail.gmail.com>

Thank you, I will take a look and see if I can help.

Victor

Le 22 avr. 2017 6:43 PM, "Brett Cannon" <brett at python.org> a ?crit :

>
>
> On Fri, 21 Apr 2017 at 15:33 Victor Stinner <victor.stinner at gmail.com>
> wrote:
>
>> Ah, I found a workaround: Firefox on Android has a "[x] See the computer
>> version" option which allows the merge!?
>>
>> Victor
>>
>> Le 22 avr. 2017 12:29 AM, "Victor Stinner" <victor.stinner at gmail.com> a
>> ?crit :
>>
>>> 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."
>>>
>>
> Well that's annoying.
>
>
>>
>>> 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.
>>>
>>
> https://github.com/python/core-workflow/issues/38 is tracking trying to
> fix the inconsistency problem and https://github.com/python/
> core-workflow/issues/18 is tracking getting a more complete coverage
> report.
>
> I would like to see this fixed and it's on my workflow todo list, but
> obviously that list is not short so I don't know when I will get to it
> (especially since at some point I will need to take a workflow break and
> actually write code and review PRs again ;) .
>
>
>> 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?
>>>
>>
> We might be able to turn off the status check. The config file is
> https://github.com/python/cpython/blob/master/.codecov.yml and the docs
> are at https://docs.codecov.io/docs/codecov-yaml (I'm on vacation so I
> don't have time to look up the exact config change since I really shouldn't
> even be replying to this email ;) .
>
>
>>
>>> 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?
>>>
>>
> Codecov actually only runs under Travis, so it's only testing on Linux.
>
>
>>
>>> 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.
>>>
>>
> I personally disagree as code that isn't tested isn't checked that at
> least some semblance of backwards-compatibility is being kept. Now I'm not
> advocating we must have explicit tests for every line or code, but I think
> we should somehow exercise as much code as possible.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170423/4c4c2b01/attachment-0001.html>

From ethan at stoneleaf.us  Tue Apr 25 00:32:03 2017
From: ethan at stoneleaf.us (Ethan Furman)
Date: Mon, 24 Apr 2017 21:32:03 -0700
Subject: [python-committers] Codecov and PR
In-Reply-To: <CAMpsgwY1Tqd6iX2SWYY0u=4uDp=YB5AFYUr=AsUBFO2otwCijg@mail.gmail.com>
References: <CAMpsgwYB4J1u0kF7pAu_SjEHXNET3r45N=kHA4s8MD8fb4OD_Q@mail.gmail.com>
 <CAMpsgwb6byWRV0R3NtpKpTOXsafYkJ9L6HRaHVTP+3vhBG8TCA@mail.gmail.com>
 <CAMpsgwZzY8pRj9cJdDR8d74yomO2wDq-S0h=GijQLvEUUvNk9w@mail.gmail.com>
 <CAMpsgwaxb3P3nEP6XK6=wcVGVgJP-sdFSR20GxHqpjGSOUTtKw@mail.gmail.com>
 <CAMpsgwbFENwyaMjzGEFwUQGE7zHVbuiq81n2gr5DJj9xsuvMDg@mail.gmail.com>
 <CAMpsgwYCFV4ka_RAW1XufhVE1GSXqBh+YPJKhWkH=iRsukkf+A@mail.gmail.com>
 <CAMpsgwZ7cAUaAwsxYrhbfbNVWw0S8JXALhv8HsKGbrKFyvQteg@mail.gmail.com>
 <CAMpsgwaCf1h00C0WurfOZthgC1ncD5=_DPWpNKg_gczuqixTxg@mail.gmail.com>
 <CAMpsgwafQq-GDOGy108hK7gJMRsnFCPmMHhDmX+A2WRm2TBGfQ@mail.gmail.com>
 <CAMpsgwaAu70zKkQz8NOmkcCXm-9rShmrYrRZkgb_d48_Po-WEw@mail.gmail.com>
 <CAMpsgwYC-rR9aePxRH84RUOhKNrG=DzK9q5NvrV3Lgp3qEV7cw@mail.gmail.com>
 <CAMpsgwaJAzqpdN2JwSS-wxt8gGbf=BX1ubp4Kk4U5EuZg3N+6A@mail.gmail.com>
 <CAMpsgwZrmBbF7bWWf2zzvgWN=o0iWgriVuPJi2t1j0CrwTYYJA@mail.gmail.com>
 <CAMpsgwY1Tqd6iX2SWYY0u=4uDp=YB5AFYUr=AsUBFO2otwCijg@mail.gmail.com>
Message-ID: <58FED143.1010109@stoneleaf.us>

On 04/21/2017 03:29 PM, Victor Stinner wrote:

> 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.

If it's not important enough to require tests it's not important enough to be in Python.  ;)

--
~Ethan~

From barry at python.org  Tue Apr 25 11:00:49 2017
From: barry at python.org (Barry Warsaw)
Date: Tue, 25 Apr 2017 11:00:49 -0400
Subject: [python-committers] Codecov and PR
In-Reply-To: <58FED143.1010109@stoneleaf.us>
References: <CAMpsgwYB4J1u0kF7pAu_SjEHXNET3r45N=kHA4s8MD8fb4OD_Q@mail.gmail.com>
 <CAMpsgwZzY8pRj9cJdDR8d74yomO2wDq-S0h=GijQLvEUUvNk9w@mail.gmail.com>
 <CAMpsgwaxb3P3nEP6XK6=wcVGVgJP-sdFSR20GxHqpjGSOUTtKw@mail.gmail.com>
 <CAMpsgwbFENwyaMjzGEFwUQGE7zHVbuiq81n2gr5DJj9xsuvMDg@mail.gmail.com>
 <CAMpsgwYCFV4ka_RAW1XufhVE1GSXqBh+YPJKhWkH=iRsukkf+A@mail.gmail.com>
 <CAMpsgwZ7cAUaAwsxYrhbfbNVWw0S8JXALhv8HsKGbrKFyvQteg@mail.gmail.com>
 <CAMpsgwaCf1h00C0WurfOZthgC1ncD5=_DPWpNKg_gczuqixTxg@mail.gmail.com>
 <CAMpsgwafQq-GDOGy108hK7gJMRsnFCPmMHhDmX+A2WRm2TBGfQ@mail.gmail.com>
 <CAMpsgwaAu70zKkQz8NOmkcCXm-9rShmrYrRZkgb_d48_Po-WEw@mail.gmail.com>
 <CAMpsgwYC-rR9aePxRH84RUOhKNrG=DzK9q5NvrV3Lgp3qEV7cw@mail.gmail.com>
 <CAMpsgwaJAzqpdN2JwSS-wxt8gGbf=BX1ubp4Kk4U5EuZg3N+6A@mail.gmail.com>
 <CAMpsgwZrmBbF7bWWf2zzvgWN=o0iWgriVuPJi2t1j0CrwTYYJA@mail.gmail.com>
 <CAMpsgwY1Tqd6iX2SWYY0u=4uDp=YB5AFYUr=AsUBFO2otwCijg@mail.gmail.com>
 <58FED143.1010109@stoneleaf.us>
Message-ID: <20170425110049.29300fb4@subdivisions.wooz.org>

On Apr 24, 2017, at 09:32 PM, Ethan Furman wrote:

>> 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.
>
>If it's not important enough to require tests it's not important enough to be
>in Python.  ;)

"Untested code is broken code" :)

-Barry

From tjreedy at udel.edu  Tue Apr 25 20:00:36 2017
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 25 Apr 2017 20:00:36 -0400
Subject: [python-committers] Codecov and PR
In-Reply-To: <20170425110049.29300fb4@subdivisions.wooz.org>
References: <CAMpsgwYB4J1u0kF7pAu_SjEHXNET3r45N=kHA4s8MD8fb4OD_Q@mail.gmail.com>
 <CAMpsgwZzY8pRj9cJdDR8d74yomO2wDq-S0h=GijQLvEUUvNk9w@mail.gmail.com>
 <CAMpsgwaxb3P3nEP6XK6=wcVGVgJP-sdFSR20GxHqpjGSOUTtKw@mail.gmail.com>
 <CAMpsgwbFENwyaMjzGEFwUQGE7zHVbuiq81n2gr5DJj9xsuvMDg@mail.gmail.com>
 <CAMpsgwYCFV4ka_RAW1XufhVE1GSXqBh+YPJKhWkH=iRsukkf+A@mail.gmail.com>
 <CAMpsgwZ7cAUaAwsxYrhbfbNVWw0S8JXALhv8HsKGbrKFyvQteg@mail.gmail.com>
 <CAMpsgwaCf1h00C0WurfOZthgC1ncD5=_DPWpNKg_gczuqixTxg@mail.gmail.com>
 <CAMpsgwafQq-GDOGy108hK7gJMRsnFCPmMHhDmX+A2WRm2TBGfQ@mail.gmail.com>
 <CAMpsgwaAu70zKkQz8NOmkcCXm-9rShmrYrRZkgb_d48_Po-WEw@mail.gmail.com>
 <CAMpsgwYC-rR9aePxRH84RUOhKNrG=DzK9q5NvrV3Lgp3qEV7cw@mail.gmail.com>
 <CAMpsgwaJAzqpdN2JwSS-wxt8gGbf=BX1ubp4Kk4U5EuZg3N+6A@mail.gmail.com>
 <CAMpsgwZrmBbF7bWWf2zzvgWN=o0iWgriVuPJi2t1j0CrwTYYJA@mail.gmail.com>
 <CAMpsgwY1Tqd6iX2SWYY0u=4uDp=YB5AFYUr=AsUBFO2otwCijg@mail.gmail.com>
 <58FED143.1010109@stoneleaf.us>
 <20170425110049.29300fb4@subdivisions.wooz.org>
Message-ID: <0eb1ac43-061f-77ab-aca4-cadd4aa18c45@udel.edu>

On 4/25/2017 11:00 AM, Barry Warsaw wrote:
> On Apr 24, 2017, at 09:32 PM, Ethan Furman wrote:
>>On 04/21/2017 03:29 PM, Victor Stinner wrote:

(In the context of having a patch blocked by the blind Codecov robot ...)

>>> I dislike code coverage because there is a temptation to write artificial
>>> tests whereas the code is tested indirectly or the code is not important
>>> enough to *require* tests.

While I use code coverage to improve automated unittesting, I am opposed 
to turning a usable but limited and sometime faulty tool into a blind 
robotic master that blocks improvements.  The prospect of this being 
done has discouraged me from learning the new system.  (More on 'faulty 
tool' later.)

The temptation to write artificial tests to satisfy an artificial goal 
is real.  Doing so can eat valuable time better used for something else. 
  For instance:

     def meth(self, arg):
         mod.inst.meth(arg, True, ob=self, kw='cut')

Mocking mod.class.meth, calling meth, and checking that the mock is 
called will satisfy the robot, but does not contribute much to the goal 
of providing a language that people can use to solve problems.

Victor, can you explain 'tested indirectly' and perhaps give an example?

As used here,'whereas' is incorrect English and a bit confusing.  I 
believe Victor meant something more like 'even when'.

For the last clause, I believe he meant "the code change is not 
complicated enough to *require* automated unit test coverage for the 
changed line(s)".  If I change a comment or add missing spaces, I don't 
think I should be forced to write a missing test to make the improvement.

A less trivial example: on IDLE's menu, Options => Configure IDLE opens 
a dialog with a font size widget that when clicked opens a list of font 
sizes.  I recently added 4 larger sizes to the tuple in 
idlelib.configdialog.ConfigDialog.LoadFontCfg, as requested, I think, by 
at least 2 people.  I tested manually by clicking until the list was 
displayed.  As I remember, I did not immediately worry about automated 
testing, let alone line coverage, and I do not think I should have had 
to to get the change into 3.6.0.

That line may or may not by covered by the current minimal test that 
simply creates a ConfigDialog instance.  But this gets back to what I 
think is Viktor's point.  This minimal test 'covers' 46% of the file, 
but it only tests that 46% of the lines run without raising.  This is 
useful, but does not test that the lines are really correct.  (For GUI 
display code, human eyeballing is required.)  This would remain true 
even if all the other code were moved to a new module, making the 
coverage of configdialog the magical ***100%***.

>> If it's not important enough to require tests >> it's not important enough to be in Python.  ;)

Modules in the test package are mostly not tested. ;)

If 'test' means 'line coverage test for new or changed lines', then as a 
practical matter, I disagree, as explained above.  So, in effect, did 
the people who committed untested lines.

In the wider sense of 'test', there is no real argument.  Each statement 
written should be mentally tested both when written and when reviewed. 
Code should be manually tested, preferably by someone in addition to the 
author. Automated testing is more than nice, but not everything.  Ditto 
for unit testing.

Some practical issues with coverage and CodeCov:

1. A Python module is comprised of statements but coverage module counts 
physical lines.  This is good for development, but not for gating.  The 
number of physical lines comprising a statement can change without 
changing or with only trivially changing the compiled run code.  So if 
coverage is not 100%, it can vary without a real change in statement 
coverage.

2. Some statements are only intended to run on certain systems, making 
100% coverage impossible unless one carefully puts all system-specific 
code in "if system == 'xyz'" statements and uses system-specific 
.coveragerc files to exclude code for 'other' systems.

3. Some tests required extended resources.  Statements that are only 
covered by such tests will be seen as uncovered when coverage is run on 
a system lacking the resources.  As far as I know, all non-Windows 
buildbots and CodeCov are run on systems lacking the 'gui' resource.  So 
patches to gui code will be seen as uncovered.

4. As I explained in a post on the core-workflow list, IDLE needs the 
following added to the 'exclude_lines' item of .coveragerc.
     .*# htest #
     if not _utest:
The mechanism behind these would also be useful for testing any other 
modules, scripts, or demos that use tkinter GUIs.

There seems to be other issues too.

> "Untested code is broken code" :)

Most of CPython, including IDLE, has been pretty thoroughly tested.  And 
we have heaps of bug reports to show for it.  What's more important is 
that even code that is tested, by whatever means, may still bugs.  Hence 
  However, obscure bugs are still found.  And even correct code can be 
corrupted (repressed) by attempt fix and improve.

--
Terry Jan Reedy

From songofacandy at gmail.com  Wed Apr 26 01:15:00 2017
From: songofacandy at gmail.com (INADA Naoki)
Date: Wed, 26 Apr 2017 14:15:00 +0900
Subject: [python-committers] Codecov and PR
In-Reply-To: <0eb1ac43-061f-77ab-aca4-cadd4aa18c45@udel.edu>
References: <CAMpsgwYB4J1u0kF7pAu_SjEHXNET3r45N=kHA4s8MD8fb4OD_Q@mail.gmail.com>
 <CAMpsgwZzY8pRj9cJdDR8d74yomO2wDq-S0h=GijQLvEUUvNk9w@mail.gmail.com>
 <CAMpsgwaxb3P3nEP6XK6=wcVGVgJP-sdFSR20GxHqpjGSOUTtKw@mail.gmail.com>
 <CAMpsgwbFENwyaMjzGEFwUQGE7zHVbuiq81n2gr5DJj9xsuvMDg@mail.gmail.com>
 <CAMpsgwYCFV4ka_RAW1XufhVE1GSXqBh+YPJKhWkH=iRsukkf+A@mail.gmail.com>
 <CAMpsgwZ7cAUaAwsxYrhbfbNVWw0S8JXALhv8HsKGbrKFyvQteg@mail.gmail.com>
 <CAMpsgwaCf1h00C0WurfOZthgC1ncD5=_DPWpNKg_gczuqixTxg@mail.gmail.com>
 <CAMpsgwafQq-GDOGy108hK7gJMRsnFCPmMHhDmX+A2WRm2TBGfQ@mail.gmail.com>
 <CAMpsgwaAu70zKkQz8NOmkcCXm-9rShmrYrRZkgb_d48_Po-WEw@mail.gmail.com>
 <CAMpsgwYC-rR9aePxRH84RUOhKNrG=DzK9q5NvrV3Lgp3qEV7cw@mail.gmail.com>
 <CAMpsgwaJAzqpdN2JwSS-wxt8gGbf=BX1ubp4Kk4U5EuZg3N+6A@mail.gmail.com>
 <CAMpsgwZrmBbF7bWWf2zzvgWN=o0iWgriVuPJi2t1j0CrwTYYJA@mail.gmail.com>
 <CAMpsgwY1Tqd6iX2SWYY0u=4uDp=YB5AFYUr=AsUBFO2otwCijg@mail.gmail.com>
 <58FED143.1010109@stoneleaf.us>
 <20170425110049.29300fb4@subdivisions.wooz.org>
 <0eb1ac43-061f-77ab-aca4-cadd4aa18c45@udel.edu>
Message-ID: <CAEfz+TytxyNCGNDAcdmaddERTSw7ew+xjc2UKdejW=Z0Qk6Ksg@mail.gmail.com>

> While I use code coverage to improve automated unittesting, I am opposed to
> turning a usable but limited and sometime faulty tool into a blind robotic
> master that blocks improvements.  The prospect of this being done has
> discouraged me from learning the new system.  (More on 'faulty tool' later.)
>
> The temptation to write artificial tests to satisfy an artificial goal is
> real.  Doing so can eat valuable time better used for something else.  For
> instance:
>
>     def meth(self, arg):
>         mod.inst.meth(arg, True, ob=self, kw='cut')
>
> Mocking mod.class.meth, calling meth, and checking that the mock is called
> will satisfy the robot, but does not contribute much to the goal of
> providing a language that people can use to solve problems.
>
> Victor, can you explain 'tested indirectly' and perhaps give an example?
>

This is one examples I merged "untested line of code".
https://github.com/python/cpython/pull/162/files#diff-0ad86c44e7866421ecaa5ad2c0edb0e2R552

+            file_object = builtins.open(f, 'wb')
+            try:
+                self.initfp(file_object)
+            except:
+                file_object.close()
+                raise

`self.initfp()` is very unlikely raise exceptions.  But MemoryError,
KeyboardInterrupt or
other rare exceptions may be happen.
Test didn't cover this except clause.  But I merged it because:

* this code is simple enough.
* I can write test for it with mocking `self.initfp()` to raise
exception.  But such test code
  have significant maintenance cost.  I don't think this except clause
is important enough
  to maintain such code.

If I remove the except clause, all lines are tested, but there is
(very unlikely)
leaking unclosed file.  Which are "broken"?

Coverage is very nice information to find code which should be tested,
but not tested.
But I don't think "all code should be tested".
It may make hard to improve Python.

So I agree with Victor and Terry.

Regards,

From victor.stinner at gmail.com  Wed Apr 26 02:05:52 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Wed, 26 Apr 2017 08:05:52 +0200
Subject: [python-committers] Codecov and PR
In-Reply-To: <CAMpsgwZ=WQYTmUdCZDGT72vWbYUqaNOW+6duRnqX6UNBxCHULQ@mail.gmail.com>
References: <CAMpsgwYB4J1u0kF7pAu_SjEHXNET3r45N=kHA4s8MD8fb4OD_Q@mail.gmail.com>
 <CAMpsgwZzY8pRj9cJdDR8d74yomO2wDq-S0h=GijQLvEUUvNk9w@mail.gmail.com>
 <CAMpsgwaxb3P3nEP6XK6=wcVGVgJP-sdFSR20GxHqpjGSOUTtKw@mail.gmail.com>
 <CAMpsgwbFENwyaMjzGEFwUQGE7zHVbuiq81n2gr5DJj9xsuvMDg@mail.gmail.com>
 <CAMpsgwYCFV4ka_RAW1XufhVE1GSXqBh+YPJKhWkH=iRsukkf+A@mail.gmail.com>
 <CAMpsgwZ7cAUaAwsxYrhbfbNVWw0S8JXALhv8HsKGbrKFyvQteg@mail.gmail.com>
 <CAMpsgwaCf1h00C0WurfOZthgC1ncD5=_DPWpNKg_gczuqixTxg@mail.gmail.com>
 <CAMpsgwafQq-GDOGy108hK7gJMRsnFCPmMHhDmX+A2WRm2TBGfQ@mail.gmail.com>
 <CAMpsgwaAu70zKkQz8NOmkcCXm-9rShmrYrRZkgb_d48_Po-WEw@mail.gmail.com>
 <CAMpsgwYC-rR9aePxRH84RUOhKNrG=DzK9q5NvrV3Lgp3qEV7cw@mail.gmail.com>
 <CAMpsgwaJAzqpdN2JwSS-wxt8gGbf=BX1ubp4Kk4U5EuZg3N+6A@mail.gmail.com>
 <CAMpsgwZrmBbF7bWWf2zzvgWN=o0iWgriVuPJi2t1j0CrwTYYJA@mail.gmail.com>
 <CAMpsgwY1Tqd6iX2SWYY0u=4uDp=YB5AFYUr=AsUBFO2otwCijg@mail.gmail.com>
 <58FED143.1010109@stoneleaf.us>
 <20170425110049.29300fb4@subdivisions.wooz.org>
 <0eb1ac43-061f-77ab-aca4-cadd4aa18c45@udel.edu>
 <CAEfz+TytxyNCGNDAcdmaddERTSw7ew+xjc2UKdejW=Z0Qk6Ksg@mail.gmail.com>
 <CAMpsgwZ=WQYTmUdCZDGT72vWbYUqaNOW+6duRnqX6UNBxCHULQ@mail.gmail.com>
Message-ID: <CAMpsgwZfpc1MsoQJ9VNLU-9zBb=oyff_9nrRYVD93SNUKgse2g@mail.gmail.com>

`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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170426/fc87914c/attachment.html>

From ethan at stoneleaf.us  Wed Apr 26 11:21:34 2017
From: ethan at stoneleaf.us (Ethan Furman)
Date: Wed, 26 Apr 2017 08:21:34 -0700
Subject: [python-committers] Codecov and PR
In-Reply-To: <CAEfz+TytxyNCGNDAcdmaddERTSw7ew+xjc2UKdejW=Z0Qk6Ksg@mail.gmail.com>
References: <CAMpsgwYB4J1u0kF7pAu_SjEHXNET3r45N=kHA4s8MD8fb4OD_Q@mail.gmail.com>
 <CAMpsgwbFENwyaMjzGEFwUQGE7zHVbuiq81n2gr5DJj9xsuvMDg@mail.gmail.com>
 <CAMpsgwYCFV4ka_RAW1XufhVE1GSXqBh+YPJKhWkH=iRsukkf+A@mail.gmail.com>
 <CAMpsgwZ7cAUaAwsxYrhbfbNVWw0S8JXALhv8HsKGbrKFyvQteg@mail.gmail.com>
 <CAMpsgwaCf1h00C0WurfOZthgC1ncD5=_DPWpNKg_gczuqixTxg@mail.gmail.com>
 <CAMpsgwafQq-GDOGy108hK7gJMRsnFCPmMHhDmX+A2WRm2TBGfQ@mail.gmail.com>
 <CAMpsgwaAu70zKkQz8NOmkcCXm-9rShmrYrRZkgb_d48_Po-WEw@mail.gmail.com>
 <CAMpsgwYC-rR9aePxRH84RUOhKNrG=DzK9q5NvrV3Lgp3qEV7cw@mail.gmail.com>
 <CAMpsgwaJAzqpdN2JwSS-wxt8gGbf=BX1ubp4Kk4U5EuZg3N+6A@mail.gmail.com>
 <CAMpsgwZrmBbF7bWWf2zzvgWN=o0iWgriVuPJi2t1j0CrwTYYJA@mail.gmail.com>
 <CAMpsgwY1Tqd6iX2SWYY0u=4uDp=YB5AFYUr=AsUBFO2otwCijg@mail.gmail.com>
 <58FED143.1010109@stoneleaf.us>
 <20170425110049.29300fb4@subdivisions.wooz.org>
 <0eb1ac43-061f-77ab-aca4-cadd4aa18c45@udel.edu>
 <CAEfz+TytxyNCGNDAcdmaddERTSw7ew+xjc2UKdejW=Z0Qk6Ksg@mail.gmail.com>
Message-ID: <5900BAFE.7010507@stoneleaf.us>

On 04/25/2017 10:15 PM, INADA Naoki wrote:

> This is one examples I merged "untested line of code".
> https://github.com/python/cpython/pull/162/files#diff-0ad86c44e7866421ecaa5ad2c0edb0e2R552
>
> +            file_object = builtins.open(f, 'wb')
> +            try:
> +                self.initfp(file_object)
> +            except:
> +                file_object.close()
> +                raise
>
> `self.initfp()` is very unlikely raise exceptions.  But MemoryError,
> KeyboardInterrupt or
> other rare exceptions may be happen.
> Test didn't cover this except clause.  But I merged it because:
>
> * this code is simple enough.
> * I can write test for it with mocking `self.initfp()` to raise
> exception.  But such test code
>    have significant maintenance cost.  I don't think this except clause
> is important enough
>    to maintain such code.

I'm curious as to the maintenance cost -- surely it's write once, forget until you have to change that method again? 
How often are we changing that method?

> If I remove the except clause, all lines are tested, but there is
> (very unlikely)
> leaking unclosed file.  Which are "broken"?

Definitely the (unlikely) leaking of a file, possibly the untested closing of an otherwise leaked file.

> Coverage is very nice information to find code which should be tested,
> but not tested.
> But I don't think "all code should be tested".

All code should be tested.  Doesn't mean we can, but that should be the goal.

> It may make hard to improve Python.

Adding missing tests _is_ improving Python.

--
~Ethan~

From ethan at stoneleaf.us  Wed Apr 26 11:23:58 2017
From: ethan at stoneleaf.us (Ethan Furman)
Date: Wed, 26 Apr 2017 08:23:58 -0700
Subject: [python-committers] Codecov and PR
In-Reply-To: <CAMpsgwZfpc1MsoQJ9VNLU-9zBb=oyff_9nrRYVD93SNUKgse2g@mail.gmail.com>
References: <CAMpsgwYB4J1u0kF7pAu_SjEHXNET3r45N=kHA4s8MD8fb4OD_Q@mail.gmail.com>
 <CAMpsgwZ7cAUaAwsxYrhbfbNVWw0S8JXALhv8HsKGbrKFyvQteg@mail.gmail.com>
 <CAMpsgwaCf1h00C0WurfOZthgC1ncD5=_DPWpNKg_gczuqixTxg@mail.gmail.com>
 <CAMpsgwafQq-GDOGy108hK7gJMRsnFCPmMHhDmX+A2WRm2TBGfQ@mail.gmail.com>
 <CAMpsgwaAu70zKkQz8NOmkcCXm-9rShmrYrRZkgb_d48_Po-WEw@mail.gmail.com>
 <CAMpsgwYC-rR9aePxRH84RUOhKNrG=DzK9q5NvrV3Lgp3qEV7cw@mail.gmail.com>
 <CAMpsgwaJAzqpdN2JwSS-wxt8gGbf=BX1ubp4Kk4U5EuZg3N+6A@mail.gmail.com>
 <CAMpsgwZrmBbF7bWWf2zzvgWN=o0iWgriVuPJi2t1j0CrwTYYJA@mail.gmail.com>
 <CAMpsgwY1Tqd6iX2SWYY0u=4uDp=YB5AFYUr=AsUBFO2otwCijg@mail.gmail.com>
 <58FED143.1010109@stoneleaf.us>
 <20170425110049.29300fb4@subdivisions.wooz.org>
 <0eb1ac43-061f-77ab-aca4-cadd4aa18c45@udel.edu>
 <CAEfz+TytxyNCGNDAcdmaddERTSw7ew+xjc2UKdejW=Z0Qk6Ksg@mail.gmail.com>
 <CAMpsgwZ=WQYTmUdCZDGT72vWbYUqaNOW+6duRnqX6UNBxCHULQ@mail.gmail.com>
 <CAMpsgwZfpc1MsoQJ9VNLU-9zBb=oyff_9nrRYVD93SNUKgse2g@mail.gmail.com>
Message-ID: <5900BB8E.6060205@stoneleaf.us>

On 04/25/2017 11:05 PM, Victor Stinner wrote:
> On 04/25/2017 10:15 PM, INADA Naoki wrote:

>>     `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?

That application -- specifically, the except clause of the application.  There should be other tests for the non-except 
clause portions.

--
~Ethan~

From brett at python.org  Wed Apr 26 13:45:32 2017
From: brett at python.org (Brett Cannon)
Date: Wed, 26 Apr 2017 17:45:32 +0000
Subject: [python-committers] Codecov and PR
In-Reply-To: <0eb1ac43-061f-77ab-aca4-cadd4aa18c45@udel.edu>
References: <CAMpsgwYB4J1u0kF7pAu_SjEHXNET3r45N=kHA4s8MD8fb4OD_Q@mail.gmail.com>
 <CAMpsgwZzY8pRj9cJdDR8d74yomO2wDq-S0h=GijQLvEUUvNk9w@mail.gmail.com>
 <CAMpsgwaxb3P3nEP6XK6=wcVGVgJP-sdFSR20GxHqpjGSOUTtKw@mail.gmail.com>
 <CAMpsgwbFENwyaMjzGEFwUQGE7zHVbuiq81n2gr5DJj9xsuvMDg@mail.gmail.com>
 <CAMpsgwYCFV4ka_RAW1XufhVE1GSXqBh+YPJKhWkH=iRsukkf+A@mail.gmail.com>
 <CAMpsgwZ7cAUaAwsxYrhbfbNVWw0S8JXALhv8HsKGbrKFyvQteg@mail.gmail.com>
 <CAMpsgwaCf1h00C0WurfOZthgC1ncD5=_DPWpNKg_gczuqixTxg@mail.gmail.com>
 <CAMpsgwafQq-GDOGy108hK7gJMRsnFCPmMHhDmX+A2WRm2TBGfQ@mail.gmail.com>
 <CAMpsgwaAu70zKkQz8NOmkcCXm-9rShmrYrRZkgb_d48_Po-WEw@mail.gmail.com>
 <CAMpsgwYC-rR9aePxRH84RUOhKNrG=DzK9q5NvrV3Lgp3qEV7cw@mail.gmail.com>
 <CAMpsgwaJAzqpdN2JwSS-wxt8gGbf=BX1ubp4Kk4U5EuZg3N+6A@mail.gmail.com>
 <CAMpsgwZrmBbF7bWWf2zzvgWN=o0iWgriVuPJi2t1j0CrwTYYJA@mail.gmail.com>
 <CAMpsgwY1Tqd6iX2SWYY0u=4uDp=YB5AFYUr=AsUBFO2otwCijg@mail.gmail.com>
 <58FED143.1010109@stoneleaf.us>
 <20170425110049.29300fb4@subdivisions.wooz.org>
 <0eb1ac43-061f-77ab-aca4-cadd4aa18c45@udel.edu>
Message-ID: <CAP1=2W69VK_8WXJ83Nh6p43mWN_YeTMLm_SFBF5oe8XwdiV_DA@mail.gmail.com>

On Tue, 25 Apr 2017 at 17:00 Terry Reedy <tjreedy at udel.edu> wrote:

> On 4/25/2017 11:00 AM, Barry Warsaw wrote:
> > On Apr 24, 2017, at 09:32 PM, Ethan Furman wrote:
> >>On 04/21/2017 03:29 PM, Victor Stinner wrote:
>
> (In the context of having a patch blocked by the blind Codecov robot ...)
>
> >>> I dislike code coverage because there is a temptation to write
> artificial
> >>> tests whereas the code is tested indirectly or the code is not
> important
> >>> enough to *require* tests.
>
> While I use code coverage to improve automated unittesting, I am opposed
> to turning a usable but limited and sometime faulty tool into a blind
> robotic master that blocks improvements.  The prospect of this being
> done has discouraged me from learning the new system.  (More on 'faulty
> tool' later.)
>

It should be stated that code coverage is not a blocking status check for
merging from our perspective (the **only** required check is that Travis
pass with it's test run). The only reason Victor ran into it at a blocker
is because he tried to do a merge over his phone where GitHub apparently
prevents merging if any failing check exists, required or not (I assume
this is because reviewing code on a small screen raises the chances of
overlooking a failing check that one actually cared about).

I'm on vacation until tomorrow so I've been off of GitHub since last
Thursday, but it's possible there's already a PR out there to turn off the
status checks. If there is still no such PR I'm still fine with turning off
the status checks for Codecov.


>
> The temptation to write artificial tests to satisfy an artificial goal
> is real.  Doing so can eat valuable time better used for something else.
>   For instance:
>
>      def meth(self, arg):
>          mod.inst.meth(arg, True, ob=self, kw='cut')
>
> Mocking mod.class.meth, calling meth, and checking that the mock is
> called will satisfy the robot, but does not contribute much to the goal
> of providing a language that people can use to solve problems.
>

My assumption is that there will be a test that meth() does the right
thing, mock or not. If we provide an API there should be some test for it;
using a mock or something else to do the test is an implementation detail.


>
> Victor, can you explain 'tested indirectly' and perhaps give an example?
>
> As used here,'whereas' is incorrect English and a bit confusing.  I
> believe Victor meant something more like 'even when'.
>
> For the last clause, I believe he meant "the code change is not
> complicated enough to *require* automated unit test coverage for the
> changed line(s)".  If I change a comment or add missing spaces, I don't
> think I should be forced to write a missing test to make the improvement.
>

Agreed.


>
> A less trivial example: on IDLE's menu, Options => Configure IDLE opens
> a dialog with a font size widget that when clicked opens a list of font
> sizes.  I recently added 4 larger sizes to the tuple in
> idlelib.configdialog.ConfigDialog.LoadFontCfg, as requested, I think, by
> at least 2 people.  I tested manually by clicking until the list was
> displayed.  As I remember, I did not immediately worry about automated
> testing, let alone line coverage, and I do not think I should have had
> to to get the change into 3.6.0.
>
> That line may or may not by covered by the current minimal test that
> simply creates a ConfigDialog instance.  But this gets back to what I
> think is Viktor's point.  This minimal test 'covers' 46% of the file,
> but it only tests that 46% of the lines run without raising.  This is
> useful, but does not test that the lines are really correct.  (For GUI
> display code, human eyeballing is required.)  This would remain true
> even if all the other code were moved to a new module, making the
> coverage of configdialog the magical ***100%***.
>
> >> If it's not important enough to require tests >> it's not important
> enough to be in Python.  ;)
>
> Modules in the test package are mostly not tested. ;)
>

:) But they are at least executed which is what we're really measuring here
and I think all Ethan and I are advocating for. E.g. I don't expect
test_importlib to be directly responsible for exercising all code in
importlib, just that Python's entire test suite exercise importlib as much
as possible as a whole.


>
> If 'test' means 'line coverage test for new or changed lines', then as a
> practical matter, I disagree, as explained above.  So, in effect, did
> the people who committed untested lines.
>
> In the wider sense of 'test', there is no real argument.  Each statement
> written should be mentally tested both when written and when reviewed.
> Code should be manually tested, preferably by someone in addition to the
> author. Automated testing is more than nice, but not everything.  Ditto
> for unit testing.
>

The problem I have with just doing manual testing for things that can
easily be covered by a unit test -- directly or indirectly -- is there are
technically 85 people who can change CPython today. That means there's
potentially 85 different people who can screw up the code ;) . Making sure
code is exercised somehow by tests at least minimizes how badly someone
like me might mess something thanks to me not realizing I broke the code.


>
> Some practical issues with coverage and CodeCov:
>
> 1. A Python module is comprised of statements but coverage module counts
> physical lines.  This is good for development, but not for gating.  The
> number of physical lines comprising a statement can change without
> changing or with only trivially changing the compiled run code.  So if
> coverage is not 100%, it can vary without a real change in statement
> coverage.
>

As I said earlier, no one here is gating PRs on code coverage.


>
> 2. Some statements are only intended to run on certain systems, making
> 100% coverage impossible unless one carefully puts all system-specific
> code in "if system == 'xyz'" statements and uses system-specific
> .coveragerc files to exclude code for 'other' systems.
>

True. We could have a discussion as to whether we want to use Coverage.py's
pragmas -- e.g. `# pragma: no cover` -- to flag code as known to be
untested. Depending on how far we wanted to take this we could also set up
pragmas that flag when a test is OS-specific (I found
https://bitbucket.org/ned/coveragepy/issues/563/platform-specific-configuration
while
looking for a solution and I'm sure we could discuss things with Ned
Batchelder if we needed some functionality in coverage.py for our needs).


>
> 3. Some tests required extended resources.  Statements that are only
> covered by such tests will be seen as uncovered when coverage is run on
> a system lacking the resources.  As far as I know, all non-Windows
> buildbots and CodeCov are run on systems lacking the 'gui' resource.  So
> patches to gui code will be seen as uncovered.
>

I view 100% coverage as aspirational, not attainable. But if we want an
attainable goal, what should we aim for? We're at 83.44% now so we could
say that 80% is something we never want to drop below and be done with it.
We could up it to 85% or 90% in recognizing that there is more testing to
do but that we will never cover all Python code (all of this is
configurable in Codecov, hence why I'm asking).


>
> 4. As I explained in a post on the core-workflow list, IDLE needs the
> following added to the 'exclude_lines' item of .coveragerc.
>      .*# htest #
>      if not _utest:
> The mechanism behind these would also be useful for testing any other
> modules, scripts, or demos that use tkinter GUIs.
>
> There seems to be other issues too.
>
> > "Untested code is broken code" :)
>
> Most of CPython, including IDLE, has been pretty thoroughly tested.  And
> we have heaps of bug reports to show for it.  What's more important is
> that even code that is tested, by whatever means, may still bugs.  Hence
>   However, obscure bugs are still found.  And even correct code can be
> corrupted (repressed) by attempt fix and improve.
>
> --
> Terry Jan Reedy
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170426/a9807cf1/attachment.html>

From tjreedy at udel.edu  Thu Apr 27 01:35:50 2017
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 27 Apr 2017 01:35:50 -0400
Subject: [python-committers] Codecov and PR
In-Reply-To: <CAP1=2W69VK_8WXJ83Nh6p43mWN_YeTMLm_SFBF5oe8XwdiV_DA@mail.gmail.com>
References: <CAMpsgwYB4J1u0kF7pAu_SjEHXNET3r45N=kHA4s8MD8fb4OD_Q@mail.gmail.com>
 <CAMpsgwbFENwyaMjzGEFwUQGE7zHVbuiq81n2gr5DJj9xsuvMDg@mail.gmail.com>
 <CAMpsgwYCFV4ka_RAW1XufhVE1GSXqBh+YPJKhWkH=iRsukkf+A@mail.gmail.com>
 <CAMpsgwZ7cAUaAwsxYrhbfbNVWw0S8JXALhv8HsKGbrKFyvQteg@mail.gmail.com>
 <CAMpsgwaCf1h00C0WurfOZthgC1ncD5=_DPWpNKg_gczuqixTxg@mail.gmail.com>
 <CAMpsgwafQq-GDOGy108hK7gJMRsnFCPmMHhDmX+A2WRm2TBGfQ@mail.gmail.com>
 <CAMpsgwaAu70zKkQz8NOmkcCXm-9rShmrYrRZkgb_d48_Po-WEw@mail.gmail.com>
 <CAMpsgwYC-rR9aePxRH84RUOhKNrG=DzK9q5NvrV3Lgp3qEV7cw@mail.gmail.com>
 <CAMpsgwaJAzqpdN2JwSS-wxt8gGbf=BX1ubp4Kk4U5EuZg3N+6A@mail.gmail.com>
 <CAMpsgwZrmBbF7bWWf2zzvgWN=o0iWgriVuPJi2t1j0CrwTYYJA@mail.gmail.com>
 <CAMpsgwY1Tqd6iX2SWYY0u=4uDp=YB5AFYUr=AsUBFO2otwCijg@mail.gmail.com>
 <58FED143.1010109@stoneleaf.us>
 <20170425110049.29300fb4@subdivisions.wooz.org>
 <0eb1ac43-061f-77ab-aca4-cadd4aa18c45@udel.edu>
 <CAP1=2W69VK_8WXJ83Nh6p43mWN_YeTMLm_SFBF5oe8XwdiV_DA@mail.gmail.com>
Message-ID: <fb47b574-6cc8-73d1-1de1-2ae307b6e5ac@udel.edu>

On 4/26/2017 1:45 PM, Brett Cannon wrote:
> 
> On Tue, 25 Apr 2017 at 17:00 Terry Reedy <tjreedy at udel.edu 
> <mailto:tjreedy at udel.edu>> wrote:

>     While I use code coverage to improve automated unittesting, I am opposed
>     to turning a usable but limited and sometime faulty tool into a blind
>     robotic master that blocks improvements.  The prospect of this being
>     done has discouraged me from learning the new system.  (More on 'faulty
>     tool' later.)
> 
> It should be stated that code coverage is not a blocking status check 
> for merging from our perspective (the **only** required check is that 
> Travis pass with it's test run).

I have the impression that at one time you hoped to make it blocking. 
If that was wrong, I apologize for misunderstanding.  If you have 
changed your mind, then I am happy.

I am otherwise in favor of both the measurement and report of coverage 
being improved.

>     The temptation to write artificial tests to satisfy an artificial goal
>     is real.  Doing so can eat valuable time better used for something else.
>        For instance:
> 
>           def meth(self, arg):
>               mod.inst.meth(arg, True, ob=self, kw='cut')
> 
>     Mocking mod.class.meth, calling meth, and checking that the mock is
>     called will satisfy the robot, but does not contribute much to the goal
>     of providing a language that people can use to solve problems.

> My assumption is that there will be a test that meth() does the right 
> thing, mock or not. If we provide an API there should be some test for 
> it; using a mock or something else to do the test is an implementation 
> detail.

My impression is that default mocks have a generic signature, so that 
merely checking that the mock is called will not catch an invalid call. 
I presume that one can do better with mocks, and I have with custom 
mocks I have written, but my point above was that coverage does not care.

>      >> If it's not important enough to require tests >> it's not
>     important enough to be in Python.  ;)
> 
>     Modules in the test package are mostly not tested. ;)
> 
> 
> :) But they are at least executed which is what we're really measuring 
> here and I think all Ethan and I are advocating for.

I thought Ethan was advocating for more -- a specific unittest for each 
line.

> E.g. I don't expect 
> test_importlib to be directly responsible for exercising all code in 
> importlib, just that Python's entire test suite exercise importlib as 
> much as possible as a whole.

The advantage for importlib in this respect is that import statements 
cannot be mocked; only the objects imported, after importlib is finished.

There is lots of interaction between idlelib modules, but I would still 
like direct tests of each idlelib.xyz with a test_xyz.py.  Three years 
ago, there was no test.test_idle.  There now is, and it runs 35 
idlelib.idle_test.text_* files.  (There are 60 idlelib modules.)

> The problem I have with just doing manual testing for things that can 
> easily be covered by a unit test -- directly or indirectly -- is there 
> are technically 85 people who can change CPython today. That means 
> there's potentially 85 different people who can screw up the code ;) . 

At the moment, I am the only one pushing idlelib patches, except when it 
gets included in one of Serhiy's multi-module refactoring patches (and 
he always nosies me).  That skews my view a bit.  However, with most of 
the critical issues fixed, I am anxious to automate what I can of what I 
now do by hand.

> Making sure code is exercised somehow by tests at least minimizes how 
> badly someone like me might mess something thanks to me not realizing I 
> broke the code.

I had not thought about the issue that way.  I should add a test_module 
for each remaining module, import the module, and at least create an 
instance of every tkinter widget defined therein, and see what other 
classes could be easily instantiated and what functions easily run.
>     Some practical issues with coverage and CodeCov:

>     2. Some statements are only intended to run on certain systems, making
>     100% coverage impossible unless one carefully puts all system-specific
>     code in "if system == 'xyz'" statements and uses system-specific
>     .coveragerc files to exclude code for 'other' systems.

> True. We could have a discussion as to whether we want to use 
> Coverage.py's pragmas ... I'm sure we could discuss things with Ned 
> Batchelder if we needed some functionality in coverage.py for our needs).

Let's skip this for now.

>     3. Some tests required extended resources.  Statements that are only
>     covered by such tests will be seen as uncovered when coverage is run on
>     a system lacking the resources.  As far as I know, all non-Windows
>     buildbots and CodeCov are run on systems lacking the 'gui' resource.  So
>     patches to gui code will be seen as uncovered.
> 
> I view 100% coverage as aspirational, not attainable. But if we want an 
> attainable goal, what should we aim for? We're at 83.44% now

On what system?  I suspect that Tkinter, ttk, turtle, and IDLE 
GUI-dependent tests make at least a 2% difference on GUI Windows versus 
no-GUI *nix.

   we could
> say that 80% is something we never want to drop below and be done with 
> it. We could up it to 85% or 90% in recognizing that there is more 
> testing to do but that we will never cover all Python code (all of this 
> is configurable in Codecov, hence why I'm asking).

Since I think we actually are at 85%, and certainly will be when I add 
minimal easy tests for the rest of IDLELIB, I think 90% would be a 
reasonable goal.

One way to increase coverage is to push a bit harder on fulfilling the 
'test needed' stage.  Theoretically, every substantive 
(behavior-changing) patch should start with a test that fails.  Since 
PRs are separate from the main repository and can be patched separately, 
a PR could start with a test that should immediately fail but should 
pass before merging.  It would be nice if the test runner knew to only 
run the new test and not the entire suite.  It would be even nicer if it 
know that initial failure is success.  Is there at least a 'New Test' 
label on PRs?

>     4. As I explained in a post on the core-workflow list, IDLE needs the
>     following added to the 'exclude_lines' item of .coveragerc.
>           .*# htest #
>           if not _utest:

These additions would remove, I think, at least 400 lines from the 
uncovered category.  Both only occur in idlelib.

--
Terry Jan Reedy

From ethan at stoneleaf.us  Thu Apr 27 01:52:30 2017
From: ethan at stoneleaf.us (Ethan Furman)
Date: Wed, 26 Apr 2017 22:52:30 -0700
Subject: [python-committers] Codecov and PR
In-Reply-To: <fb47b574-6cc8-73d1-1de1-2ae307b6e5ac@udel.edu>
References: <CAMpsgwYB4J1u0kF7pAu_SjEHXNET3r45N=kHA4s8MD8fb4OD_Q@mail.gmail.com>
 <CAMpsgwYCFV4ka_RAW1XufhVE1GSXqBh+YPJKhWkH=iRsukkf+A@mail.gmail.com>
 <CAMpsgwZ7cAUaAwsxYrhbfbNVWw0S8JXALhv8HsKGbrKFyvQteg@mail.gmail.com>
 <CAMpsgwaCf1h00C0WurfOZthgC1ncD5=_DPWpNKg_gczuqixTxg@mail.gmail.com>
 <CAMpsgwafQq-GDOGy108hK7gJMRsnFCPmMHhDmX+A2WRm2TBGfQ@mail.gmail.com>
 <CAMpsgwaAu70zKkQz8NOmkcCXm-9rShmrYrRZkgb_d48_Po-WEw@mail.gmail.com>
 <CAMpsgwYC-rR9aePxRH84RUOhKNrG=DzK9q5NvrV3Lgp3qEV7cw@mail.gmail.com>
 <CAMpsgwaJAzqpdN2JwSS-wxt8gGbf=BX1ubp4Kk4U5EuZg3N+6A@mail.gmail.com>
 <CAMpsgwZrmBbF7bWWf2zzvgWN=o0iWgriVuPJi2t1j0CrwTYYJA@mail.gmail.com>
 <CAMpsgwY1Tqd6iX2SWYY0u=4uDp=YB5AFYUr=AsUBFO2otwCijg@mail.gmail.com>
 <58FED143.1010109@stoneleaf.us>
 <20170425110049.29300fb4@subdivisions.wooz.org>
 <0eb1ac43-061f-77ab-aca4-cadd4aa18c45@udel.edu>
 <CAP1=2W69VK_8WXJ83Nh6p43mWN_YeTMLm_SFBF5oe8XwdiV_DA@mail.gmail.com>
 <fb47b574-6cc8-73d1-1de1-2ae307b6e5ac@udel.edu>
Message-ID: <5901871E.7070107@stoneleaf.us>

On 04/26/2017 10:35 PM, Terry Reedy wrote:
> On 4/26/2017 1:45 PM, Brett Cannon wrote:

>> :) But they are at least executed which is what we're really measuring here and I think all Ethan and I are advocating
>> for.
>
> I thought Ethan was advocating for more -- a specific unittest for each line.

I'm hoping that's just poor wording, or each module would need hundreds of tests.  ;)

What I am advocating is to have 100% test coverage -- but as Brett said, that's an aspirational goal.  Said a different 
way:  all code in Python is important enough to test; whether we can write those tests with our limited resources is a 
different matter.

I am well aware that writing good tests is hard.  I am painfully aware of the frustration of having error-reporting code 
error out because it wasn't tested.

I agree that we shouldn't deny core developers from merging because of coverage statistics.

--
~Ethan~

From tjreedy at udel.edu  Thu Apr 27 02:51:46 2017
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 27 Apr 2017 02:51:46 -0400
Subject: [python-committers] Codecov and PR
In-Reply-To: <5901871E.7070107@stoneleaf.us>
References: <CAMpsgwYB4J1u0kF7pAu_SjEHXNET3r45N=kHA4s8MD8fb4OD_Q@mail.gmail.com>
 <CAMpsgwYCFV4ka_RAW1XufhVE1GSXqBh+YPJKhWkH=iRsukkf+A@mail.gmail.com>
 <CAMpsgwZ7cAUaAwsxYrhbfbNVWw0S8JXALhv8HsKGbrKFyvQteg@mail.gmail.com>
 <CAMpsgwaCf1h00C0WurfOZthgC1ncD5=_DPWpNKg_gczuqixTxg@mail.gmail.com>
 <CAMpsgwafQq-GDOGy108hK7gJMRsnFCPmMHhDmX+A2WRm2TBGfQ@mail.gmail.com>
 <CAMpsgwaAu70zKkQz8NOmkcCXm-9rShmrYrRZkgb_d48_Po-WEw@mail.gmail.com>
 <CAMpsgwYC-rR9aePxRH84RUOhKNrG=DzK9q5NvrV3Lgp3qEV7cw@mail.gmail.com>
 <CAMpsgwaJAzqpdN2JwSS-wxt8gGbf=BX1ubp4Kk4U5EuZg3N+6A@mail.gmail.com>
 <CAMpsgwZrmBbF7bWWf2zzvgWN=o0iWgriVuPJi2t1j0CrwTYYJA@mail.gmail.com>
 <CAMpsgwY1Tqd6iX2SWYY0u=4uDp=YB5AFYUr=AsUBFO2otwCijg@mail.gmail.com>
 <58FED143.1010109@stoneleaf.us>
 <20170425110049.29300fb4@subdivisions.wooz.org>
 <0eb1ac43-061f-77ab-aca4-cadd4aa18c45@udel.edu>
 <CAP1=2W69VK_8WXJ83Nh6p43mWN_YeTMLm_SFBF5oe8XwdiV_DA@mail.gmail.com>
 <fb47b574-6cc8-73d1-1de1-2ae307b6e5ac@udel.edu>
 <5901871E.7070107@stoneleaf.us>
Message-ID: <3fbd3041-efb3-6967-5316-b13100ac04a2@udel.edu>

On 4/27/2017 1:52 AM, Ethan Furman wrote:
> On 04/26/2017 10:35 PM, Terry Reedy wrote:
>> On 4/26/2017 1:45 PM, Brett Cannon wrote:
> 
>>> :) But they are at least executed which is what we're really 
>>> measuring here and I think all Ethan and I are advocating
>>> for.
>>
>> I thought Ethan was advocating for more -- a specific unittest for 
>> each line.
> 
> I'm hoping that's just poor wording, or each module would need hundreds 
> of tests.  ;)

Poor wording, but I was wrong in any case.  An aspirational goal is that 
each line of of each function be exercised for correctness by at least 
one unittest.  For top-level code not in a function or class, we mostly 
have to settle for compile and run without error.

From brett at python.org  Thu Apr 27 15:44:08 2017
From: brett at python.org (Brett Cannon)
Date: Thu, 27 Apr 2017 19:44:08 +0000
Subject: [python-committers] Codecov and PR
In-Reply-To: <fb47b574-6cc8-73d1-1de1-2ae307b6e5ac@udel.edu>
References: <CAMpsgwYB4J1u0kF7pAu_SjEHXNET3r45N=kHA4s8MD8fb4OD_Q@mail.gmail.com>
 <CAMpsgwbFENwyaMjzGEFwUQGE7zHVbuiq81n2gr5DJj9xsuvMDg@mail.gmail.com>
 <CAMpsgwYCFV4ka_RAW1XufhVE1GSXqBh+YPJKhWkH=iRsukkf+A@mail.gmail.com>
 <CAMpsgwZ7cAUaAwsxYrhbfbNVWw0S8JXALhv8HsKGbrKFyvQteg@mail.gmail.com>
 <CAMpsgwaCf1h00C0WurfOZthgC1ncD5=_DPWpNKg_gczuqixTxg@mail.gmail.com>
 <CAMpsgwafQq-GDOGy108hK7gJMRsnFCPmMHhDmX+A2WRm2TBGfQ@mail.gmail.com>
 <CAMpsgwaAu70zKkQz8NOmkcCXm-9rShmrYrRZkgb_d48_Po-WEw@mail.gmail.com>
 <CAMpsgwYC-rR9aePxRH84RUOhKNrG=DzK9q5NvrV3Lgp3qEV7cw@mail.gmail.com>
 <CAMpsgwaJAzqpdN2JwSS-wxt8gGbf=BX1ubp4Kk4U5EuZg3N+6A@mail.gmail.com>
 <CAMpsgwZrmBbF7bWWf2zzvgWN=o0iWgriVuPJi2t1j0CrwTYYJA@mail.gmail.com>
 <CAMpsgwY1Tqd6iX2SWYY0u=4uDp=YB5AFYUr=AsUBFO2otwCijg@mail.gmail.com>
 <58FED143.1010109@stoneleaf.us>
 <20170425110049.29300fb4@subdivisions.wooz.org>
 <0eb1ac43-061f-77ab-aca4-cadd4aa18c45@udel.edu>
 <CAP1=2W69VK_8WXJ83Nh6p43mWN_YeTMLm_SFBF5oe8XwdiV_DA@mail.gmail.com>
 <fb47b574-6cc8-73d1-1de1-2ae307b6e5ac@udel.edu>
Message-ID: <CAP1=2W5LuXy0OkRqeOdBxPdr-WUZAFyMitSN02oiQ7ZOANu=nA@mail.gmail.com>

On Wed, 26 Apr 2017 at 22:36 Terry Reedy <tjreedy at udel.edu> wrote:

> On 4/26/2017 1:45 PM, Brett Cannon wrote:
> >
> > On Tue, 25 Apr 2017 at 17:00 Terry Reedy <tjreedy at udel.edu
> > <mailto:tjreedy at udel.edu>> wrote:
>
> >     While I use code coverage to improve automated unittesting, I am
> opposed
> >     to turning a usable but limited and sometime faulty tool into a blind
> >     robotic master that blocks improvements.  The prospect of this being
> >     done has discouraged me from learning the new system.  (More on
> 'faulty
> >     tool' later.)
> >
> > It should be stated that code coverage is not a blocking status check
> > for merging from our perspective (the **only** required check is that
> > Travis pass with it's test run).
>
> I have the impression that at one time you hoped to make it blocking.
> If that was wrong, I apologize for misunderstanding.  If you have
> changed your mind, then I am happy.
>

"Hope", sure; "currently plan to", no. IOW I have said a lot of things over
the 2.5 years I've been leading this workflow shift and I don't expect all
of them to pan out.


>
> I am otherwise in favor of both the measurement and report of coverage
> being improved.
>
> >     The temptation to write artificial tests to satisfy an artificial
> goal
> >     is real.  Doing so can eat valuable time better used for something
> else.
> >        For instance:
> >
> >           def meth(self, arg):
> >               mod.inst.meth(arg, True, ob=self, kw='cut')
> >
> >     Mocking mod.class.meth, calling meth, and checking that the mock is
> >     called will satisfy the robot, but does not contribute much to the
> goal
> >     of providing a language that people can use to solve problems.
>
> > My assumption is that there will be a test that meth() does the right
> > thing, mock or not. If we provide an API there should be some test for
> > it; using a mock or something else to do the test is an implementation
> > detail.
>
> My impression is that default mocks have a generic signature, so that
> merely checking that the mock is called will not catch an invalid call.
> I presume that one can do better with mocks, and I have with custom
> mocks I have written, but my point above was that coverage does not care.
>
> >      >> If it's not important enough to require tests >> it's not
> >     important enough to be in Python.  ;)
> >
> >     Modules in the test package are mostly not tested. ;)
> >
> >
> > :) But they are at least executed which is what we're really measuring
> > here and I think all Ethan and I are advocating for.
>
> I thought Ethan was advocating for more -- a specific unittest for each
> line.
>
> > E.g. I don't expect
> > test_importlib to be directly responsible for exercising all code in
> > importlib, just that Python's entire test suite exercise importlib as
> > much as possible as a whole.
>
> The advantage for importlib in this respect is that import statements
> cannot be mocked; only the objects imported, after importlib is finished.
>

Oh, you can mock import statements. :)


>
> There is lots of interaction between idlelib modules, but I would still
> like direct tests of each idlelib.xyz with a test_xyz.py.  Three years
> ago, there was no test.test_idle.  There now is, and it runs 35
> idlelib.idle_test.text_* files.  (There are 60 idlelib modules.)
>
> > The problem I have with just doing manual testing for things that can
> > easily be covered by a unit test -- directly or indirectly -- is there
> > are technically 85 people who can change CPython today. That means
> > there's potentially 85 different people who can screw up the code ;) .
>
> At the moment, I am the only one pushing idlelib patches, except when it
> gets included in one of Serhiy's multi-module refactoring patches (and
> he always nosies me).  That skews my view a bit.  However, with most of
> the critical issues fixed, I am anxious to automate what I can of what I
> now do by hand.
>
> > Making sure code is exercised somehow by tests at least minimizes how
> > badly someone like me might mess something thanks to me not realizing I
> > broke the code.
>
> I had not thought about the issue that way.  I should add a test_module
> for each remaining module, import the module, and at least create an
> instance of every tkinter widget defined therein, and see what other
> classes could be easily instantiated and what functions easily run.
>

That seems like a good starting point. Kind of like test_sundry but with
class instantiation on top of it.


> >     Some practical issues with coverage and CodeCov:
>
> >     2. Some statements are only intended to run on certain systems,
> making
> >     100% coverage impossible unless one carefully puts all
> system-specific
> >     code in "if system == 'xyz'" statements and uses system-specific
> >     .coveragerc files to exclude code for 'other' systems.
>
> > True. We could have a discussion as to whether we want to use
> > Coverage.py's pragmas ... I'm sure we could discuss things with Ned
> > Batchelder if we needed some functionality in coverage.py for our needs).
>
> Let's skip this for now.
>
> >     3. Some tests required extended resources.  Statements that are only
> >     covered by such tests will be seen as uncovered when coverage is run
> on
> >     a system lacking the resources.  As far as I know, all non-Windows
> >     buildbots and CodeCov are run on systems lacking the 'gui'
> resource.  So
> >     patches to gui code will be seen as uncovered.
> >
> > I view 100% coverage as aspirational, not attainable. But if we want an
> > attainable goal, what should we aim for? We're at 83.44% now
>
> On what system?


Travis, where the Codecov run is driven from.


>   I suspect that Tkinter, ttk, turtle, and IDLE
> GUI-dependent tests make at least a 2% difference on GUI Windows versus
> no-GUI *nix.


>    we could
> > say that 80% is something we never want to drop below and be done with
> > it. We could up it to 85% or 90% in recognizing that there is more
> > testing to do but that we will never cover all Python code (all of this
> > is configurable in Codecov, hence why I'm asking).
>
> Since I think we actually are at 85%, and certainly will be when I add
> minimal easy tests for the rest of IDLELIB, I think 90% would be a
> reasonable goal.
>

Seems reasonable to me. Opened
https://github.com/python/core-workflow/issues/75 to remind me to tweak
Codecov's config so that we are aiming for 90% overall.

-Brett


>
> One way to increase coverage is to push a bit harder on fulfilling the
> 'test needed' stage.  Theoretically, every substantive
> (behavior-changing) patch should start with a test that fails.  Since
> PRs are separate from the main repository and can be patched separately,
> a PR could start with a test that should immediately fail but should
> pass before merging.  It would be nice if the test runner knew to only
> run the new test and not the entire suite.  It would be even nicer if it
> know that initial failure is success.  Is there at least a 'New Test'
> label on PRs?
>
> >     4. As I explained in a post on the core-workflow list, IDLE needs the
> >     following added to the 'exclude_lines' item of .coveragerc.
> >           .*# htest #
> >           if not _utest:
>
> These additions would remove, I think, at least 400 lines from the
> uncovered category.  Both only occur in idlelib.
>
> --
> Terry Jan Reedy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170427/e8ccfa6f/attachment.html>

From tjreedy at udel.edu  Thu Apr 27 20:49:11 2017
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 27 Apr 2017 20:49:11 -0400
Subject: [python-committers] Codecov and PR
In-Reply-To: <CAP1=2W5LuXy0OkRqeOdBxPdr-WUZAFyMitSN02oiQ7ZOANu=nA@mail.gmail.com>
References: <CAMpsgwYB4J1u0kF7pAu_SjEHXNET3r45N=kHA4s8MD8fb4OD_Q@mail.gmail.com>
 <CAMpsgwZ7cAUaAwsxYrhbfbNVWw0S8JXALhv8HsKGbrKFyvQteg@mail.gmail.com>
 <CAMpsgwaCf1h00C0WurfOZthgC1ncD5=_DPWpNKg_gczuqixTxg@mail.gmail.com>
 <CAMpsgwafQq-GDOGy108hK7gJMRsnFCPmMHhDmX+A2WRm2TBGfQ@mail.gmail.com>
 <CAMpsgwaAu70zKkQz8NOmkcCXm-9rShmrYrRZkgb_d48_Po-WEw@mail.gmail.com>
 <CAMpsgwYC-rR9aePxRH84RUOhKNrG=DzK9q5NvrV3Lgp3qEV7cw@mail.gmail.com>
 <CAMpsgwaJAzqpdN2JwSS-wxt8gGbf=BX1ubp4Kk4U5EuZg3N+6A@mail.gmail.com>
 <CAMpsgwZrmBbF7bWWf2zzvgWN=o0iWgriVuPJi2t1j0CrwTYYJA@mail.gmail.com>
 <CAMpsgwY1Tqd6iX2SWYY0u=4uDp=YB5AFYUr=AsUBFO2otwCijg@mail.gmail.com>
 <58FED143.1010109@stoneleaf.us>
 <20170425110049.29300fb4@subdivisions.wooz.org>
 <0eb1ac43-061f-77ab-aca4-cadd4aa18c45@udel.edu>
 <CAP1=2W69VK_8WXJ83Nh6p43mWN_YeTMLm_SFBF5oe8XwdiV_DA@mail.gmail.com>
 <fb47b574-6cc8-73d1-1de1-2ae307b6e5ac@udel.edu>
 <CAP1=2W5LuXy0OkRqeOdBxPdr-WUZAFyMitSN02oiQ7ZOANu=nA@mail.gmail.com>
Message-ID: <f7779841-6ae5-a708-3f95-5374a7e70f2d@udel.edu>

On 4/27/2017 3:44 PM, Brett Cannon wrote:
> 
> 
> On Wed, 26 Apr 2017 at 22:36 Terry Reedy <tjreedy at udel.edu 
> <mailto:tjreedy at udel.edu>> wrote:
> 
>     On 4/26/2017 1:45 PM, Brett Cannon wrote:

>      > E.g. I don't expect
>      > test_importlib to be directly responsible for exercising all code in
>      > importlib, just that Python's entire test suite exercise importlib as
>      > much as possible as a whole.
> 
>     The advantage for importlib in this respect is that import statements
>     cannot be mocked; only the objects imported, after importlib is
>     finished.
> 
> 
> Oh, you can mock import statements. :)

Other than by pre-loading a mock module into sys.modules?
If so, please give a hint, as this could be useful to me.

>     At the moment, I am the only one pushing idlelib patches, except when it
>     gets included in one of Serhiy's multi-module refactoring patches (and
>     he always nosies me).

It turns out that Louie Lu's new tool revealed a couple of other 
patches, though just to tests that started failing.

>     I had not thought about the issue that way.  I should add a test_module
>     for each remaining module, import the module, and at least create an
>     instance of every tkinter widget defined therein, and see what other
>     classes could be easily instantiated and what functions easily run.
> 
> 
> That seems like a good starting point. Kind of like test_sundry but with 
> class instantiation on top of it.

I looked and saw that bdb is in 'untested'.  I also discovered
https://bugs.python.org/issue19417
to change that, with a 3+ year-old-patch.  I plan to review it.

>      > I view 100% coverage as aspirational, not attainable. But if we
>     want an
>      > attainable goal, what should we aim for? We're at 83.44% now
> 
>     On what system?

> Travis, where the Codecov run is driven from.

I meant OS, because

>        I suspect that Tkinter, ttk, turtle, and IDLE
>     GUI-dependent tests make at least a 2% difference on GUI Windows versus
>     no-GUI *nix.

--
Terry Jan Reedy


From michael at voidspace.org.uk  Fri Apr 28 05:19:33 2017
From: michael at voidspace.org.uk (Michael Foord)
Date: Fri, 28 Apr 2017 10:19:33 +0100
Subject: [python-committers] Codecov and PR
In-Reply-To: <f7779841-6ae5-a708-3f95-5374a7e70f2d@udel.edu>
References: <CAMpsgwYB4J1u0kF7pAu_SjEHXNET3r45N=kHA4s8MD8fb4OD_Q@mail.gmail.com>
 <CAMpsgwZ7cAUaAwsxYrhbfbNVWw0S8JXALhv8HsKGbrKFyvQteg@mail.gmail.com>
 <CAMpsgwaCf1h00C0WurfOZthgC1ncD5=_DPWpNKg_gczuqixTxg@mail.gmail.com>
 <CAMpsgwafQq-GDOGy108hK7gJMRsnFCPmMHhDmX+A2WRm2TBGfQ@mail.gmail.com>
 <CAMpsgwaAu70zKkQz8NOmkcCXm-9rShmrYrRZkgb_d48_Po-WEw@mail.gmail.com>
 <CAMpsgwYC-rR9aePxRH84RUOhKNrG=DzK9q5NvrV3Lgp3qEV7cw@mail.gmail.com>
 <CAMpsgwaJAzqpdN2JwSS-wxt8gGbf=BX1ubp4Kk4U5EuZg3N+6A@mail.gmail.com>
 <CAMpsgwZrmBbF7bWWf2zzvgWN=o0iWgriVuPJi2t1j0CrwTYYJA@mail.gmail.com>
 <CAMpsgwY1Tqd6iX2SWYY0u=4uDp=YB5AFYUr=AsUBFO2otwCijg@mail.gmail.com>
 <58FED143.1010109@stoneleaf.us>
 <20170425110049.29300fb4@subdivisions.wooz.org>
 <0eb1ac43-061f-77ab-aca4-cadd4aa18c45@udel.edu>
 <CAP1=2W69VK_8WXJ83Nh6p43mWN_YeTMLm_SFBF5oe8XwdiV_DA@mail.gmail.com>
 <fb47b574-6cc8-73d1-1de1-2ae307b6e5ac@udel.edu>
 <CAP1=2W5LuXy0OkRqeOdBxPdr-WUZAFyMitSN02oiQ7ZOANu=nA@mail.gmail.com>
 <f7779841-6ae5-a708-3f95-5374a7e70f2d@udel.edu>
Message-ID: <9835c37d-4662-9172-70bd-9afa83192789@voidspace.org.uk>



On 28/04/17 01:49, Terry Reedy wrote:
> On 4/27/2017 3:44 PM, Brett Cannon wrote:
>>
>>
>> On Wed, 26 Apr 2017 at 22:36 Terry Reedy <tjreedy at udel.edu 
>> <mailto:tjreedy at udel.edu>> wrote:
>>
>>     On 4/26/2017 1:45 PM, Brett Cannon wrote:
>
>>      > E.g. I don't expect
>>      > test_importlib to be directly responsible for exercising all 
>> code in
>>      > importlib, just that Python's entire test suite exercise 
>> importlib as
>>      > much as possible as a whole.
>>
>>     The advantage for importlib in this respect is that import 
>> statements
>>     cannot be mocked; only the objects imported, after importlib is
>>     finished.
>>
>>
>> Oh, you can mock import statements. :)
>
> Other than by pre-loading a mock module into sys.modules?
> If so, please give a hint, as this could be useful to me.

https://docs.python.org/3/library/unittest.mock-examples.html#mocking-imports-with-patch-dict

>
>>     At the moment, I am the only one pushing idlelib patches, except 
>> when it
>>     gets included in one of Serhiy's multi-module refactoring patches 
>> (and
>>     he always nosies me).
>
> It turns out that Louie Lu's new tool revealed a couple of other 
> patches, though just to tests that started failing.
>
>>     I had not thought about the issue that way.  I should add a 
>> test_module
>>     for each remaining module, import the module, and at least create an
>>     instance of every tkinter widget defined therein, and see what other
>>     classes could be easily instantiated and what functions easily run.
>>
>>
>> That seems like a good starting point. Kind of like test_sundry but 
>> with class instantiation on top of it.
>
> I looked and saw that bdb is in 'untested'.  I also discovered
> https://bugs.python.org/issue19417
> to change that, with a 3+ year-old-patch.  I plan to review it.
>
>>      > I view 100% coverage as aspirational, not attainable. But if we
>>     want an
>>      > attainable goal, what should we aim for? We're at 83.44% now
>>
>>     On what system?
>
>> Travis, where the Codecov run is driven from.
>
> I meant OS, because
>
>>        I suspect that Tkinter, ttk, turtle, and IDLE
>>     GUI-dependent tests make at least a 2% difference on GUI Windows 
>> versus
>>     no-GUI *nix.
>
> -- 
> Terry Jan Reedy
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/


From brett at python.org  Fri Apr 28 12:45:45 2017
From: brett at python.org (Brett Cannon)
Date: Fri, 28 Apr 2017 16:45:45 +0000
Subject: [python-committers] Codecov and PR
In-Reply-To: <9835c37d-4662-9172-70bd-9afa83192789@voidspace.org.uk>
References: <CAMpsgwYB4J1u0kF7pAu_SjEHXNET3r45N=kHA4s8MD8fb4OD_Q@mail.gmail.com>
 <CAMpsgwZ7cAUaAwsxYrhbfbNVWw0S8JXALhv8HsKGbrKFyvQteg@mail.gmail.com>
 <CAMpsgwaCf1h00C0WurfOZthgC1ncD5=_DPWpNKg_gczuqixTxg@mail.gmail.com>
 <CAMpsgwafQq-GDOGy108hK7gJMRsnFCPmMHhDmX+A2WRm2TBGfQ@mail.gmail.com>
 <CAMpsgwaAu70zKkQz8NOmkcCXm-9rShmrYrRZkgb_d48_Po-WEw@mail.gmail.com>
 <CAMpsgwYC-rR9aePxRH84RUOhKNrG=DzK9q5NvrV3Lgp3qEV7cw@mail.gmail.com>
 <CAMpsgwaJAzqpdN2JwSS-wxt8gGbf=BX1ubp4Kk4U5EuZg3N+6A@mail.gmail.com>
 <CAMpsgwZrmBbF7bWWf2zzvgWN=o0iWgriVuPJi2t1j0CrwTYYJA@mail.gmail.com>
 <CAMpsgwY1Tqd6iX2SWYY0u=4uDp=YB5AFYUr=AsUBFO2otwCijg@mail.gmail.com>
 <58FED143.1010109@stoneleaf.us>
 <20170425110049.29300fb4@subdivisions.wooz.org>
 <0eb1ac43-061f-77ab-aca4-cadd4aa18c45@udel.edu>
 <CAP1=2W69VK_8WXJ83Nh6p43mWN_YeTMLm_SFBF5oe8XwdiV_DA@mail.gmail.com>
 <fb47b574-6cc8-73d1-1de1-2ae307b6e5ac@udel.edu>
 <CAP1=2W5LuXy0OkRqeOdBxPdr-WUZAFyMitSN02oiQ7ZOANu=nA@mail.gmail.com>
 <f7779841-6ae5-a708-3f95-5374a7e70f2d@udel.edu>
 <9835c37d-4662-9172-70bd-9afa83192789@voidspace.org.uk>
Message-ID: <CAP1=2W6M4H1B=SFydNxu0atdHeSRXD3yZ8mG6wK3zhp1ohHAfw@mail.gmail.com>

On Fri, 28 Apr 2017 at 02:19 Michael Foord <michael at voidspace.org.uk> wrote:

>
>
> On 28/04/17 01:49, Terry Reedy wrote:
> > On 4/27/2017 3:44 PM, Brett Cannon wrote:
> >>
> >>
> >> On Wed, 26 Apr 2017 at 22:36 Terry Reedy <tjreedy at udel.edu
> >> <mailto:tjreedy at udel.edu>> wrote:
> >>
> >>     On 4/26/2017 1:45 PM, Brett Cannon wrote:
> >
> >>      > E.g. I don't expect
> >>      > test_importlib to be directly responsible for exercising all
> >> code in
> >>      > importlib, just that Python's entire test suite exercise
> >> importlib as
> >>      > much as possible as a whole.
> >>
> >>     The advantage for importlib in this respect is that import
> >> statements
> >>     cannot be mocked; only the objects imported, after importlib is
> >>     finished.
> >>
> >>
> >> Oh, you can mock import statements. :)
> >
> > Other than by pre-loading a mock module into sys.modules?
> > If so, please give a hint, as this could be useful to me.
>
>
> https://docs.python.org/3/library/unittest.mock-examples.html#mocking-imports-with-patch-dict


The other option is to stub out __import__() itself.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170428/5f0138ff/attachment.html>