From christian at python.org  Mon May  1 18:32:43 2017
From: christian at python.org (Christian Heimes)
Date: Tue, 2 May 2017 00:32:43 +0200
Subject: [python-committers] Github reviews are cannibalizing BPO
Message-ID: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>

Hi all,

since our move to Github I noticed a major increase in incoming patches.
I like it. It clearly shows that it was a good decision.

But I don't like the fact that Github reviews are cannibalizing issues
on BPO. Before the migration decisions regarding a new feature or bug
fix were made on the ticket system. For larger changes we used mailing
lists or the PEP process. Rietveld, our previous code review tool, was
just used to discuss code and implementation details. All important
decisions still happened on BPO. We also used BPO to keep the experts or
module maintainers in the loop.

With Github I'm seeing a major paradigm shift. New contributors tend to
use BPO as ticket number dispenser. Actual discussion seems to happen
mostly on Github PRs. For me it makes it harder to follow discussion or
to see discussions at all. I find Github notifications inferior to
compared BPO's email notification -- mostly because Github spams me with
notifications. For me it's not uncommon to have more than 1,000 open
notifications waiting for my attention.

This brings me to my questions

1) Should we try to move discussion back to BPO or are we fine with
having major decisions just in Github PRs?

2) How can we retain enough information on BPO to keep it useful as
research database for past decisions?

3) How can we keep module maintainers and experts in the loop? For
example I don't have the resources to read all Github PRs, but I still
like to keep an eye on the ssl and hashlib module.

Christian

From senthil at uthcode.com  Mon May  1 19:01:22 2017
From: senthil at uthcode.com (Senthil Kumaran)
Date: Mon, 1 May 2017 16:01:22 -0700
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
Message-ID: <CAPOVWOSMud+55e20kvvOoAebnjRr=3C=Thxqtk95PD646Bemhw@mail.gmail.com>

On Mon, May 1, 2017 at 3:32 PM, Christian Heimes <christian at python.org> wrote:
>
> 1) Should we try to move discussion back to BPO or are we fine with
> having major decisions just in Github PRs?

How will you do that? For Github,  a PR and issue request ( an
equivalent of BPO issue) is same.
And we cannot disable review comments in Github PR and force people to
discuss in BPO only.

-- 
Senthil

From donald at stufft.io  Mon May  1 19:05:22 2017
From: donald at stufft.io (Donald Stufft)
Date: Mon, 1 May 2017 19:05:22 -0400
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
Message-ID: <46C91366-CDB5-4B38-9734-22400FAB929D@stufft.io>


> On May 1, 2017, at 6:32 PM, Christian Heimes <christian at python.org> wrote:
> 
> 3) How can we keep module maintainers and experts in the loop? For
> example I don't have the resources to read all Github PRs, but I still
> like to keep an eye on the ssl and hashlib module.
> 



Add yourself to https://github.com/python/cpython/blob/master/.mention-bot <https://github.com/python/cpython/blob/master/.mention-bot> using:

"alwaysNotifyForPaths": [
  {"name": "tiran", "files": ["Lib/ssl.py", "Lib/hashlib.py"]}
]

Include all the paths you want to _always_ be notified for globbing works as well.

Then anytime someone sends a PR that touches that, the mention bot with @tiran you (unless we turned it off?.).

?
Donald Stufft



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

From ethan at stoneleaf.us  Mon May  1 21:43:02 2017
From: ethan at stoneleaf.us (Ethan Furman)
Date: Mon, 01 May 2017 18:43:02 -0700
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
Message-ID: <5907E426.5090901@stoneleaf.us>

On 05/01/2017 03:32 PM, Christian Heimes wrote:

> With Github I'm seeing a major paradigm shift. New contributors tend to
> use BPO as ticket number dispenser. Actual discussion seems to happen
> mostly on Github PRs. For me it makes it harder to follow discussion
 > [...]

I don't have any answers, but I will chime in with a "me, too" comment about the difficulty of following Github PRs with 
code and comments intertwined.

--
~Ethan~


From ncoghlan at gmail.com  Mon May  1 22:25:08 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 2 May 2017 12:25:08 +1000
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
Message-ID: <CADiSq7euVJ5dwz-g4cKOq5m=2U5DvAVyekcNaLbyhy8zY5+JEA@mail.gmail.com>

On 2 May 2017 at 08:32, Christian Heimes <christian at python.org> wrote:
> This brings me to my questions
>
> 1) Should we try to move discussion back to BPO or are we fine with
> having major decisions just in Github PRs?
>
> 2) How can we retain enough information on BPO to keep it useful as
> research database for past decisions?

It's OK to have the discussions on GitHub, but one of the
responsibilities of reviewers is to ensure that significant design
decisions are summarised on the related tracker issue for future
reference.

If GitHub looks like it is at risk of disappearing as a public
historical archive at some point in the future (or if the problem
bothers someone enough in the meantime for them to spend time on
addressing it), then it should be possible to use
https://www.githubarchive.org/ to maintain a full streaming mirror of
a GitHub repository in a self-hosted GitLab instance.

> 3) How can we keep module maintainers and experts in the loop? For
> example I don't have the resources to read all Github PRs, but I still
> like to keep an eye on the ssl and hashlib module.

As Donald describes, mention-bot should be able to handle this (and
more reliably than the nosy list on BPO, since it's based on the
actual files touched by a PR).

Cheers,
Nick.

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

From mal at egenix.com  Tue May  2 03:34:10 2017
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 2 May 2017 09:34:10 +0200
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
Message-ID: <43b711fe-c40a-21b9-1b57-7dbae2b80368@egenix.com>

On 02.05.2017 00:32, Christian Heimes wrote:
> This brings me to my questions
> 
> 1) Should we try to move discussion back to BPO or are we fine with
> having major decisions just in Github PRs?

We've had that discussion before: discussions always should
happen on BPO, not Github PRs. PRs are just for code review,
nothing more.

AFAIK, there's no good way to enforce this except core devs
pointing people to BPO instead of commenting on PRs.

> 2) How can we retain enough information on BPO to keep it useful as
> research database for past decisions?

See above.

> 3) How can we keep module maintainers and experts in the loop? For
> example I don't have the resources to read all Github PRs, but I still
> like to keep an eye on the ssl and hashlib module.

See above :-)

I have muted all Github notifications since it became impossible
to follow them.

-- 
Marc-Andre Lemburg
eGenix.com

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


From mal at egenix.com  Tue May  2 03:36:02 2017
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 2 May 2017 09:36:02 +0200
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <CADiSq7euVJ5dwz-g4cKOq5m=2U5DvAVyekcNaLbyhy8zY5+JEA@mail.gmail.com>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
 <CADiSq7euVJ5dwz-g4cKOq5m=2U5DvAVyekcNaLbyhy8zY5+JEA@mail.gmail.com>
Message-ID: <75286ac5-bf71-d660-f8ee-b060a2595a86@egenix.com>

On 02.05.2017 04:25, Nick Coghlan wrote:
> On 2 May 2017 at 08:32, Christian Heimes <christian at python.org> wrote:
>> This brings me to my questions
>>
>> 1) Should we try to move discussion back to BPO or are we fine with
>> having major decisions just in Github PRs?
>>
>> 2) How can we retain enough information on BPO to keep it useful as
>> research database for past decisions?
> 
> It's OK to have the discussions on GitHub, but one of the
> responsibilities of reviewers is to ensure that significant design
> decisions are summarised on the related tracker issue for future
> reference.

I don't think that's a good idea, since the core devs then
have to check what's good discussion to have on Github PRs
and what not.

IMO, it's much easier for everyone to just always point people
to BPO for discussions and keep PRs reserved for code reviews.

-- 
Marc-Andre Lemburg
eGenix.com

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


From rdmurray at bitdance.com  Tue May  2 10:07:53 2017
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 02 May 2017 10:07:53 -0400
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <75286ac5-bf71-d660-f8ee-b060a2595a86@egenix.com>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
 <CADiSq7euVJ5dwz-g4cKOq5m=2U5DvAVyekcNaLbyhy8zY5+JEA@mail.gmail.com>
 <75286ac5-bf71-d660-f8ee-b060a2595a86@egenix.com>
Message-ID: <20170502140754.50FE71310014@webabinitio.net>

On Tue, 02 May 2017 09:36:02 +0200, "M.-A. Lemburg" <mal at egenix.com> wrote:
> On 02.05.2017 04:25, Nick Coghlan wrote:
> > On 2 May 2017 at 08:32, Christian Heimes <christian at python.org> wrote:
> >> This brings me to my questions
> >>
> >> 1) Should we try to move discussion back to BPO or are we fine with
> >> having major decisions just in Github PRs?
> >>
> >> 2) How can we retain enough information on BPO to keep it useful as
> >> research database for past decisions?
> > 
> > It's OK to have the discussions on GitHub, but one of the
> > responsibilities of reviewers is to ensure that significant design
> > decisions are summarised on the related tracker issue for future
> > reference.
> 
> I don't think that's a good idea, since the core devs then
> have to check what's good discussion to have on Github PRs
> and what not.
> 
> IMO, it's much easier for everyone to just always point people
> to BPO for discussions and keep PRs reserved for code reviews.

I agree with Mark-Andre here.  It will take effort on our part to
make our culture be "discuss on BPO", but it will produce a much
superior history to what github PRs produce, so I think it is worth it.

--David

From eric at trueblade.com  Tue May  2 13:24:22 2017
From: eric at trueblade.com (Eric V. Smith)
Date: Tue, 2 May 2017 13:24:22 -0400
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <20170502140754.50FE71310014@webabinitio.net>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
 <CADiSq7euVJ5dwz-g4cKOq5m=2U5DvAVyekcNaLbyhy8zY5+JEA@mail.gmail.com>
 <75286ac5-bf71-d660-f8ee-b060a2595a86@egenix.com>
 <20170502140754.50FE71310014@webabinitio.net>
Message-ID: <4c720030-9633-a53c-cee3-39b5bcbad7cb@trueblade.com>

On 5/2/17 10:07 AM, R. David Murray wrote:
> On Tue, 02 May 2017 09:36:02 +0200, "M.-A. Lemburg" <mal at egenix.com> wrote:
>> On 02.05.2017 04:25, Nick Coghlan wrote:
>>> On 2 May 2017 at 08:32, Christian Heimes <christian at python.org> wrote:
>>>> This brings me to my questions
>>>>
>>>> 1) Should we try to move discussion back to BPO or are we fine with
>>>> having major decisions just in Github PRs?
>>>>
>>>> 2) How can we retain enough information on BPO to keep it useful as
>>>> research database for past decisions?
>>>
>>> It's OK to have the discussions on GitHub, but one of the
>>> responsibilities of reviewers is to ensure that significant design
>>> decisions are summarised on the related tracker issue for future
>>> reference.
>>
>> I don't think that's a good idea, since the core devs then
>> have to check what's good discussion to have on Github PRs
>> and what not.
>>
>> IMO, it's much easier for everyone to just always point people
>> to BPO for discussions and keep PRs reserved for code reviews.
>
> I agree with Mark-Andre here.  It will take effort on our part to
> make our culture be "discuss on BPO", but it will produce a much
> superior history to what github PRs produce, so I think it is worth it.

I agree with David and MAL. github PR's should replace Rietveld for code 
reviews, and should not replace BPO for discussions.

Eric.


From guido at python.org  Tue May  2 14:13:12 2017
From: guido at python.org (Guido van Rossum)
Date: Tue, 2 May 2017 11:13:12 -0700
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <4c720030-9633-a53c-cee3-39b5bcbad7cb@trueblade.com>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
 <CADiSq7euVJ5dwz-g4cKOq5m=2U5DvAVyekcNaLbyhy8zY5+JEA@mail.gmail.com>
 <75286ac5-bf71-d660-f8ee-b060a2595a86@egenix.com>
 <20170502140754.50FE71310014@webabinitio.net>
 <4c720030-9633-a53c-cee3-39b5bcbad7cb@trueblade.com>
Message-ID: <CAP7+vJJoxw-nUZKfAf+pX-=wVuQmgZHn7hXSkQyOR-pkBUxvWg@mail.gmail.com>

I'm not necessarily disagreeing, I'm just skeptical that we can stop this
tide. New contributors are familiar with GitHub and GitHub only, and for
them, BPO looks and feels like a legacy system. And honestly, for smaller
projects, I've found GitHub a very effective place to have discussions
(e.g. most mypy design work is done there). Though I agree that GitHub
currently doesn't scale to the size of CPython unless you work hard on
setting up filtering (which *is* possible, just done very differently).

On Tue, May 2, 2017 at 10:24 AM, Eric V. Smith <eric at trueblade.com> wrote:

> On 5/2/17 10:07 AM, R. David Murray wrote:
>
>> On Tue, 02 May 2017 09:36:02 +0200, "M.-A. Lemburg" <mal at egenix.com>
>> wrote:
>>
>>> On 02.05.2017 04:25, Nick Coghlan wrote:
>>>
>>>> On 2 May 2017 at 08:32, Christian Heimes <christian at python.org> wrote:
>>>>
>>>>> This brings me to my questions
>>>>>
>>>>> 1) Should we try to move discussion back to BPO or are we fine with
>>>>> having major decisions just in Github PRs?
>>>>>
>>>>> 2) How can we retain enough information on BPO to keep it useful as
>>>>> research database for past decisions?
>>>>>
>>>>
>>>> It's OK to have the discussions on GitHub, but one of the
>>>> responsibilities of reviewers is to ensure that significant design
>>>> decisions are summarised on the related tracker issue for future
>>>> reference.
>>>>
>>>
>>> I don't think that's a good idea, since the core devs then
>>> have to check what's good discussion to have on Github PRs
>>> and what not.
>>>
>>> IMO, it's much easier for everyone to just always point people
>>> to BPO for discussions and keep PRs reserved for code reviews.
>>>
>>
>> I agree with Mark-Andre here.  It will take effort on our part to
>> make our culture be "discuss on BPO", but it will produce a much
>> superior history to what github PRs produce, so I think it is worth it.
>>
>
> I agree with David and MAL. github PR's should replace Rietveld for code
> reviews, and should not replace BPO for discussions.
>
> Eric.
>
>
> _______________________________________________
> 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/
>



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

From tjreedy at udel.edu  Tue May  2 14:28:44 2017
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 2 May 2017 14:28:44 -0400
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <20170502140754.50FE71310014@webabinitio.net>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
 <CADiSq7euVJ5dwz-g4cKOq5m=2U5DvAVyekcNaLbyhy8zY5+JEA@mail.gmail.com>
 <75286ac5-bf71-d660-f8ee-b060a2595a86@egenix.com>
 <20170502140754.50FE71310014@webabinitio.net>
Message-ID: <bae9bffd-8329-740c-c903-a27550589ceb@udel.edu>

On 5/2/2017 10:07 AM, R. David Murray wrote:
> On Tue, 02 May 2017 09:36:02 +0200, "M.-A. Lemburg" <mal at egenix.com> wrote:

>> IMO, it's much easier for everyone to just always point people
>> to BPO for discussions and keep PRs reserved for code reviews.
> 
> I agree with Mark-Andre here.  It will take effort on our part to
> make our culture be "discuss on BPO", but it will produce a much
> superior history to what github PRs produce, so I think it is worth it.

It would easier to move discussion to bpo if there were a clickable link 
from PR to bpo, just as there is in the opposite direction.  I believe 
that there is a workflow issue to add this, but last I knew, it was 
bogged down in where to put the link, or something.

tjr


From christian at python.org  Tue May  2 14:36:44 2017
From: christian at python.org (Christian Heimes)
Date: Tue, 2 May 2017 20:36:44 +0200
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <bae9bffd-8329-740c-c903-a27550589ceb@udel.edu>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
 <CADiSq7euVJ5dwz-g4cKOq5m=2U5DvAVyekcNaLbyhy8zY5+JEA@mail.gmail.com>
 <75286ac5-bf71-d660-f8ee-b060a2595a86@egenix.com>
 <20170502140754.50FE71310014@webabinitio.net>
 <bae9bffd-8329-740c-c903-a27550589ceb@udel.edu>
Message-ID: <5233f06c-8b76-e4cc-893f-1c8cf9089d04@python.org>

On 2017-05-02 20:28, Terry Reedy wrote:
> On 5/2/2017 10:07 AM, R. David Murray wrote:
>> On Tue, 02 May 2017 09:36:02 +0200, "M.-A. Lemburg" <mal at egenix.com>
>> wrote:
> 
>>> IMO, it's much easier for everyone to just always point people
>>> to BPO for discussions and keep PRs reserved for code reviews.
>>
>> I agree with Mark-Andre here.  It will take effort on our part to
>> make our culture be "discuss on BPO", but it will produce a much
>> superior history to what github PRs produce, so I think it is worth it.
> 
> It would easier to move discussion to bpo if there were a clickable link
> from PR to bpo, just as there is in the opposite direction.  I believe
> that there is a workflow issue to add this, but last I knew, it was
> bogged down in where to put the link, or something.

All recent PRs have a clickable link to BPO. It's in the box with CI
results. Click on "Details" for "bedevere/issue-number".

Christian

From eric at trueblade.com  Tue May  2 14:37:29 2017
From: eric at trueblade.com (Eric V. Smith)
Date: Tue, 2 May 2017 14:37:29 -0400
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <CAP7+vJJoxw-nUZKfAf+pX-=wVuQmgZHn7hXSkQyOR-pkBUxvWg@mail.gmail.com>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
 <CADiSq7euVJ5dwz-g4cKOq5m=2U5DvAVyekcNaLbyhy8zY5+JEA@mail.gmail.com>
 <75286ac5-bf71-d660-f8ee-b060a2595a86@egenix.com>
 <20170502140754.50FE71310014@webabinitio.net>
 <4c720030-9633-a53c-cee3-39b5bcbad7cb@trueblade.com>
 <CAP7+vJJoxw-nUZKfAf+pX-=wVuQmgZHn7hXSkQyOR-pkBUxvWg@mail.gmail.com>
Message-ID: <896d9003-2385-1194-bb22-03ed3439d2d4@trueblade.com>

On 5/2/17 2:13 PM, Guido van Rossum wrote:
> I'm not necessarily disagreeing, I'm just skeptical that we can stop
> this tide. New contributors are familiar with GitHub and GitHub only,
> and for them, BPO looks and feels like a legacy system. And honestly,
> for smaller projects, I've found GitHub a very effective place to have
> discussions (e.g. most mypy design work is done there). Though I agree
> that GitHub currently doesn't scale to the size of CPython unless you
> work hard on setting up filtering (which *is* possible, just done very
> differently).

I grant that it's an uphill battle. But even github has a separate issue 
tracker, we're just not using it. So even github black belts should be 
familiar with the concept of an issue tracker being used for a different 
purpose than code reviews are.

Eric.

From donald at stufft.io  Tue May  2 14:44:29 2017
From: donald at stufft.io (Donald Stufft)
Date: Tue, 2 May 2017 14:44:29 -0400
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <896d9003-2385-1194-bb22-03ed3439d2d4@trueblade.com>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
 <CADiSq7euVJ5dwz-g4cKOq5m=2U5DvAVyekcNaLbyhy8zY5+JEA@mail.gmail.com>
 <75286ac5-bf71-d660-f8ee-b060a2595a86@egenix.com>
 <20170502140754.50FE71310014@webabinitio.net>
 <4c720030-9633-a53c-cee3-39b5bcbad7cb@trueblade.com>
 <CAP7+vJJoxw-nUZKfAf+pX-=wVuQmgZHn7hXSkQyOR-pkBUxvWg@mail.gmail.com>
 <896d9003-2385-1194-bb22-03ed3439d2d4@trueblade.com>
Message-ID: <E390CB63-C021-4CDC-B7F6-3B3C5687A185@stufft.io>


> On May 2, 2017, at 2:37 PM, Eric V. Smith <eric at trueblade.com> wrote:
> 
> On 5/2/17 2:13 PM, Guido van Rossum wrote:
>> I'm not necessarily disagreeing, I'm just skeptical that we can stop
>> this tide. New contributors are familiar with GitHub and GitHub only,
>> and for them, BPO looks and feels like a legacy system. And honestly,
>> for smaller projects, I've found GitHub a very effective place to have
>> discussions (e.g. most mypy design work is done there). Though I agree
>> that GitHub currently doesn't scale to the size of CPython unless you
>> work hard on setting up filtering (which *is* possible, just done very
>> differently).
> 
> I grant that it's an uphill battle. But even github has a separate issue tracker, we're just not using it. So even github black belts should be familiar with the concept of an issue tracker being used for a different purpose than code reviews are.
> 


I suspect part of it may simply be that mucking around with b.p.o is far less streamlined then GitHub issues or PRs. One thing we might want to look at is making it possible to login with GitHub to b.p.o, as that is one possible hurdle for someone to cross when looking at making a comment on a PR/issue.

The flip side of that is even prior to using GitHub it wasn?t like all of the discussion was happening on b.p.o either, some of it happened in Reitveld (though less of it than is happening on GitHub because using Reitveld is/was more frustrating than a GitHub comment) and a lot of it happened in random back channels between individuals.

Ultimately, it?s likely to be a Sisyphean battle to stop it from happening unless b.p.o gets updated to have a UX on par with GitHub and the integration between the two of them makes it as low friction as possible.


?
Donald Stufft



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

From mal at egenix.com  Tue May  2 15:09:33 2017
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 2 May 2017 21:09:33 +0200
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <E390CB63-C021-4CDC-B7F6-3B3C5687A185@stufft.io>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
 <CADiSq7euVJ5dwz-g4cKOq5m=2U5DvAVyekcNaLbyhy8zY5+JEA@mail.gmail.com>
 <75286ac5-bf71-d660-f8ee-b060a2595a86@egenix.com>
 <20170502140754.50FE71310014@webabinitio.net>
 <4c720030-9633-a53c-cee3-39b5bcbad7cb@trueblade.com>
 <CAP7+vJJoxw-nUZKfAf+pX-=wVuQmgZHn7hXSkQyOR-pkBUxvWg@mail.gmail.com>
 <896d9003-2385-1194-bb22-03ed3439d2d4@trueblade.com>
 <E390CB63-C021-4CDC-B7F6-3B3C5687A185@stufft.io>
Message-ID: <dd70d99d-a553-a3b9-13b2-e666964a3c60@egenix.com>

On 02.05.2017 20:44, Donald Stufft wrote:
> 
> I suspect part of it may simply be that mucking around with b.p.o is far less streamlined then GitHub issues or PRs. One thing we might want to look at is making it possible to login with GitHub to b.p.o, as that is one possible hurdle for someone to cross when looking at making a comment on a PR/issue.
> 
> The flip side of that is even prior to using GitHub it wasn?t like all of the discussion was happening on b.p.o either, some of it happened in Reitveld (though less of it than is happening on GitHub because using Reitveld is/was more frustrating than a GitHub comment) and a lot of it happened in random back channels between individuals.

I don't think that's a good characterization of what we used
to have. We had discussions on bpo and when we felt that things
were of a more general nature, we actively moved those discussions
to the MLs.

This resulted in a healthy approach to OSS software development,
since we had many different people take part in those discussions.

We're losing this if we move away from bpo and towards having
PR discussions. Github's notification system is simply not
geared up for the high volume Python generates.

This doesn't have much to do with UX/UI. It's mainly a questions
of culture. Github is more geared up for a culture of quick chat
style comments, whereas bpo has traditionally seen a more elaborate
in-depth discussions style.

Personally, I prefer the latter, since chats are great for getting
quick feedback or notifications, but much less so for discussions
that go into more detail.

-- 
Marc-Andre Lemburg
eGenix.com

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


From tjreedy at udel.edu  Tue May  2 15:16:44 2017
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 2 May 2017 15:16:44 -0400
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <5233f06c-8b76-e4cc-893f-1c8cf9089d04@python.org>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
 <CADiSq7euVJ5dwz-g4cKOq5m=2U5DvAVyekcNaLbyhy8zY5+JEA@mail.gmail.com>
 <75286ac5-bf71-d660-f8ee-b060a2595a86@egenix.com>
 <20170502140754.50FE71310014@webabinitio.net>
 <bae9bffd-8329-740c-c903-a27550589ceb@udel.edu>
 <5233f06c-8b76-e4cc-893f-1c8cf9089d04@python.org>
Message-ID: <d69d2313-4c5b-f300-a5ce-1d9db532ac20@udel.edu>

On 5/2/2017 2:36 PM, Christian Heimes wrote:
> On 2017-05-02 20:28, Terry Reedy wrote:
>> On 5/2/2017 10:07 AM, R. David Murray wrote:
>>> On Tue, 02 May 2017 09:36:02 +0200, "M.-A. Lemburg" <mal at egenix.com>
>>> wrote:
>>
>>>> IMO, it's much easier for everyone to just always point people
>>>> to BPO for discussions and keep PRs reserved for code reviews.
>>>
>>> I agree with Mark-Andre here.  It will take effort on our part to
>>> make our culture be "discuss on BPO", but it will produce a much
>>> superior history to what github PRs produce, so I think it is worth it.
>>
>> It would easier to move discussion to bpo if there were a clickable link
>> from PR to bpo, just as there is in the opposite direction.  I believe
>> that there is a workflow issue to add this, but last I knew, it was
>> bogged down in where to put the link, or something.
> 
> All recent PRs have a clickable link to BPO. It's in the box with CI
> results.

Not until one clicks 'Show all checks'.  This is rather obscure.  Who 
would know?  Thanks for the info.

> Click on "Details" for "bedevere/issue-number".

Neither was it obvious to me that 'details' takes me to the issue, 
rather than revealing a clickable issue-number, so that I need to middle 
click to open a new tab.

So this is still considerable friction.

tjr

From donald at stufft.io  Tue May  2 15:42:24 2017
From: donald at stufft.io (Donald Stufft)
Date: Tue, 2 May 2017 15:42:24 -0400
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <dd70d99d-a553-a3b9-13b2-e666964a3c60@egenix.com>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
 <CADiSq7euVJ5dwz-g4cKOq5m=2U5DvAVyekcNaLbyhy8zY5+JEA@mail.gmail.com>
 <75286ac5-bf71-d660-f8ee-b060a2595a86@egenix.com>
 <20170502140754.50FE71310014@webabinitio.net>
 <4c720030-9633-a53c-cee3-39b5bcbad7cb@trueblade.com>
 <CAP7+vJJoxw-nUZKfAf+pX-=wVuQmgZHn7hXSkQyOR-pkBUxvWg@mail.gmail.com>
 <896d9003-2385-1194-bb22-03ed3439d2d4@trueblade.com>
 <E390CB63-C021-4CDC-B7F6-3B3C5687A185@stufft.io>
 <dd70d99d-a553-a3b9-13b2-e666964a3c60@egenix.com>
Message-ID: <52F733A6-5E1C-4BBB-A9D1-3D48DA3256FC@stufft.io>


> On May 2, 2017, at 3:09 PM, M.-A. Lemburg <mal at egenix.com> wrote:
> 
> This doesn't have much to do with UX/UI. It's mainly a questions
> of culture. Github is more geared up for a culture of quick chat
> style comments, whereas bpo has traditionally seen a more elaborate
> in-depth discussions style.


This is not really accurate to my experience using GitHub. In pip for example while we have distutils-sig and a pypa-dev mailing list we hardly ever use them for pip focused discussion. The vast bulk of our discussion (including quite long ones, and I think most folks who end up in a discussion with me know I can produce a fair amount of content in one) occur entirely within GitHub and it works just fine. I don?t think this is unique to pip either. Pretty much the only time we use anything but GitHub are when the blast radius for a change is larger then pip itself (e.g. something that touches pip, setuptools, and pypi) which we use distutils-sig for, or when something is just a notice that doesn?t require discussion, which we use pypa-dev for.

I agree that there are benefits to separating code review and issue tracking (although I?m not a purist about it, I think some PRs are too small to warrant an issue for instance) and I think that without some effort to automate and write a bot GitHub issues are not a good fit for replacing bpo. However I think it?s going to be a regular struggle to get people to try and primarily use bpo for issue discussion (vs code review) because the friction of doing so is fairly high. I think if you want to encourage people to utilize bpo better, your best bet is to do everything you can to reduce that friction.

?
Donald Stufft



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170502/25c5f4bc/attachment-0001.html>

From donald at stufft.io  Tue May  2 15:54:10 2017
From: donald at stufft.io (Donald Stufft)
Date: Tue, 2 May 2017 15:54:10 -0400
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <52F733A6-5E1C-4BBB-A9D1-3D48DA3256FC@stufft.io>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
 <CADiSq7euVJ5dwz-g4cKOq5m=2U5DvAVyekcNaLbyhy8zY5+JEA@mail.gmail.com>
 <75286ac5-bf71-d660-f8ee-b060a2595a86@egenix.com>
 <20170502140754.50FE71310014@webabinitio.net>
 <4c720030-9633-a53c-cee3-39b5bcbad7cb@trueblade.com>
 <CAP7+vJJoxw-nUZKfAf+pX-=wVuQmgZHn7hXSkQyOR-pkBUxvWg@mail.gmail.com>
 <896d9003-2385-1194-bb22-03ed3439d2d4@trueblade.com>
 <E390CB63-C021-4CDC-B7F6-3B3C5687A185@stufft.io>
 <dd70d99d-a553-a3b9-13b2-e666964a3c60@egenix.com>
 <52F733A6-5E1C-4BBB-A9D1-3D48DA3256FC@stufft.io>
Message-ID: <AADF6B50-5FE9-4A89-BC76-86B8678D40F4@stufft.io>


> On May 2, 2017, at 3:42 PM, Donald Stufft <donald at stufft.io> wrote:
> 
> 
>> On May 2, 2017, at 3:09 PM, M.-A. Lemburg <mal at egenix.com <mailto:mal at egenix.com>> wrote:
>> 
>> This doesn't have much to do with UX/UI. It's mainly a questions
>> of culture. Github is more geared up for a culture of quick chat
>> style comments, whereas bpo has traditionally seen a more elaborate
>> in-depth discussions style.
> 
> 
> This is not really accurate to my experience using GitHub. In pip for example while we have distutils-sig and a pypa-dev mailing list we hardly ever use them for pip focused discussion. The vast bulk of our discussion (including quite long ones, and I think most folks who end up in a discussion with me know I can produce a fair amount of content in one) occur entirely within GitHub and it works just fine. I don?t think this is unique to pip either. Pretty much the only time we use anything but GitHub are when the blast radius for a change is larger then pip itself (e.g. something that touches pip, setuptools, and pypi) which we use distutils-sig for, or when something is just a notice that doesn?t require discussion, which we use pypa-dev for.
> 
> I agree that there are benefits to separating code review and issue tracking (although I?m not a purist about it, I think some PRs are too small to warrant an issue for instance) and I think that without some effort to automate and write a bot GitHub issues are not a good fit for replacing bpo. However I think it?s going to be a regular struggle to get people to try and primarily use bpo for issue discussion (vs code review) because the friction of doing so is fairly high. I think if you want to encourage people to utilize bpo better, your best bet is to do everything you can to reduce that friction.
> 


To touch on this a bit more, arguably GitHub is *more* suited to long form discussion, given that it includes the ability to format your text which is an incredibly important part of producing readable content more then a few sentences long. You can attempt to apply some of this with bpo using ASCII representations, but an inlined URL or a footnote to the URL is never going to be as good as a hyperlink, or an inlined image, or bold, italics, etc.


?
Donald Stufft



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

From p.f.moore at gmail.com  Tue May  2 15:59:42 2017
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 2 May 2017 20:59:42 +0100
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <52F733A6-5E1C-4BBB-A9D1-3D48DA3256FC@stufft.io>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
 <CADiSq7euVJ5dwz-g4cKOq5m=2U5DvAVyekcNaLbyhy8zY5+JEA@mail.gmail.com>
 <75286ac5-bf71-d660-f8ee-b060a2595a86@egenix.com>
 <20170502140754.50FE71310014@webabinitio.net>
 <4c720030-9633-a53c-cee3-39b5bcbad7cb@trueblade.com>
 <CAP7+vJJoxw-nUZKfAf+pX-=wVuQmgZHn7hXSkQyOR-pkBUxvWg@mail.gmail.com>
 <896d9003-2385-1194-bb22-03ed3439d2d4@trueblade.com>
 <E390CB63-C021-4CDC-B7F6-3B3C5687A185@stufft.io>
 <dd70d99d-a553-a3b9-13b2-e666964a3c60@egenix.com>
 <52F733A6-5E1C-4BBB-A9D1-3D48DA3256FC@stufft.io>
Message-ID: <CACac1F9ha9Y22htU_GKDp9GOCcfF0iADehwbomAsC+EgX2xsSA@mail.gmail.com>

On 2 May 2017 at 20:42, Donald Stufft <donald at stufft.io> wrote:
>
> On May 2, 2017, at 3:09 PM, M.-A. Lemburg <mal at egenix.com> wrote:
>
>> This doesn't have much to do with UX/UI. It's mainly a questions
>> of culture. Github is more geared up for a culture of quick chat
>> style comments, whereas bpo has traditionally seen a more elaborate
>> in-depth discussions style.
>
> This is not really accurate to my experience using GitHub. In pip for
> example while we have distutils-sig and a pypa-dev mailing list we hardly
> ever use them for pip focused discussion. The vast bulk of our discussion
> (including quite long ones, and I think most folks who end up in a
> discussion with me know I can produce a fair amount of content in one) occur
> entirely within GitHub and it works just fine. I don?t think this is unique
> to pip either. Pretty much the only time we use anything but GitHub are when
> the blast radius for a change is larger then pip itself (e.g. something that
> touches pip, setuptools, and pypi) which we use distutils-sig for, or when
> something is just a notice that doesn?t require discussion, which we use
> pypa-dev for.
>
> I agree that there are benefits to separating code review and issue tracking
> (although I?m not a purist about it, I think some PRs are too small to
> warrant an issue for instance) and I think that without some effort to
> automate and write a bot GitHub issues are not a good fit for replacing bpo.
> However I think it?s going to be a regular struggle to get people to try and
> primarily use bpo for issue discussion (vs code review) because the friction
> of doing so is fairly high. I think if you want to encourage people to
> utilize bpo better, your best bet is to do everything you can to reduce that
> friction.

I have to agree here. I'm not sufficiently involved in bpo discussions
to have a strong opinion, but my experience with pip is the same as
Donald's - it's pretty easy to have complex design decisions on
github, as well as having review style comments. I'd have to say the
new "create a review" interface in github can make conversations
harder to follow, particularly if you're reading the emails rather
than reading on the github site itself, but I tend to work by reading
emails to spot the interesting topics, then go to GH for the full
story.

One other huge win for me with github over bpo is that the former
allows formatted text. I find having to read plaintext discussions on
bpo *much* more tiring than reading github formatted content.

But the big problem for me with github discussions in Python is the
sheer volume. My normal github workflow (which works fine for pip)
collapses under the volume of Python traffic. That's not to say that
bpo is any better - I basically ignore the majority of bpo traffic
that I['m not automatically nosied on, for exactly the same reason,
that my approach doesn't scale.

To summarise:

1. The traffic for CPython is the biggest issue - expecting people
with established workflows that cope with it to rework those workflows
to work with gh rather than bpo is a big ask.
2. Having formatted text for the discussions is (IMO) a huge win.
3. Apart from familiarity, I don't think there's much difference in
the ability to have design discussions (as long as you don't hide
design comments in the GH review notes, of course, but that's just a
matter of using the tool correctly).
4. Neither interface (in my experience) does a wonderful job of making
the discussion transparent via email. But I tend to see email as a
transient notification medium - we should probably concentrate more on
the UX when interacting with the website directly.

I can't really weight these factors, so I'll leave that to the people
who interact with the trackers more often than I do.

Paul

From barry at python.org  Tue May  2 16:02:09 2017
From: barry at python.org (Barry Warsaw)
Date: Tue, 2 May 2017 16:02:09 -0400
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <AADF6B50-5FE9-4A89-BC76-86B8678D40F4@stufft.io>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
 <CADiSq7euVJ5dwz-g4cKOq5m=2U5DvAVyekcNaLbyhy8zY5+JEA@mail.gmail.com>
 <75286ac5-bf71-d660-f8ee-b060a2595a86@egenix.com>
 <20170502140754.50FE71310014@webabinitio.net>
 <4c720030-9633-a53c-cee3-39b5bcbad7cb@trueblade.com>
 <CAP7+vJJoxw-nUZKfAf+pX-=wVuQmgZHn7hXSkQyOR-pkBUxvWg@mail.gmail.com>
 <896d9003-2385-1194-bb22-03ed3439d2d4@trueblade.com>
 <E390CB63-C021-4CDC-B7F6-3B3C5687A185@stufft.io>
 <dd70d99d-a553-a3b9-13b2-e666964a3c60@egenix.com>
 <52F733A6-5E1C-4BBB-A9D1-3D48DA3256FC@stufft.io>
 <AADF6B50-5FE9-4A89-BC76-86B8678D40F4@stufft.io>
Message-ID: <20170502160209.01d30207@subdivisions.wooz.org>

On May 02, 2017, at 03:54 PM, Donald Stufft wrote:

>To touch on this a bit more, arguably GitHub is *more* suited to long form
>discussion, given that it includes the ability to format your text which is
>an incredibly important part of producing readable content more then a few
>sentences long. You can attempt to apply some of this with bpo using ASCII
>representations, but an inlined URL or a footnote to the URL is never going
>to be as good as a hyperlink, or an inlined image, or bold, italics, etc.

This might be true w.r.t. GH vs. bpo, but both of them are inferior IMHO to
mailing lists or other types of threaded discussions.  Personally, I find
GitLab to have a better conversational UX than GitHub, but neither is threaded
so it forces the discussions to be linear.  That's okay for many discussions,
but far inferior to more wide ranging discussions.

-Barry

From antoine at python.org  Tue May  2 17:35:50 2017
From: antoine at python.org (Antoine Pitrou)
Date: Tue, 2 May 2017 23:35:50 +0200
Subject: [python-committers] No Travis-CI on OS X?
Message-ID: <dc452095-efd2-ed92-567c-20378189ac32@python.org>


Hi,

Perhaps it would be possible to set up a Travis CI matrix entry for OS
X, those builds are often quite slow but at least it could be part of
the "allowed failures" suite.  That would help detect platform issues at
PR time rather than later :-)

Regards

Antoine.

From donald at stufft.io  Tue May  2 17:37:13 2017
From: donald at stufft.io (Donald Stufft)
Date: Tue, 2 May 2017 17:37:13 -0400
Subject: [python-committers] No Travis-CI on OS X?
In-Reply-To: <dc452095-efd2-ed92-567c-20378189ac32@python.org>
References: <dc452095-efd2-ed92-567c-20378189ac32@python.org>
Message-ID: <44176935-4216-48FC-9189-2036C25AA3EF@stufft.io>



> On May 2, 2017, at 5:35 PM, Antoine Pitrou <antoine at python.org> wrote:
> 
> 
> Hi,
> 
> Perhaps it would be possible to set up a Travis CI matrix entry for OS
> X, those builds are often quite slow but at least it could be part of
> the "allowed failures" suite.  That would help detect platform issues at
> PR time rather than later :-)
> 


I think the only reason we don?t have them on is because the macOS builds on Travis are _Super_ slow and regularly get a large backlog. Fast Finish and Allowed Failures would help with that though.

?
Donald Stufft



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

From victor.stinner at gmail.com  Tue May  2 17:40:28 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Tue, 2 May 2017 23:40:28 +0200
Subject: [python-committers] No Travis-CI on OS X?
In-Reply-To: <44176935-4216-48FC-9189-2036C25AA3EF@stufft.io>
References: <dc452095-efd2-ed92-567c-20378189ac32@python.org>
 <44176935-4216-48FC-9189-2036C25AA3EF@stufft.io>
Message-ID: <CAMpsgwYnwug0Pt8f5Z2uDJv3_2GXK75WgFC158ie47+rgSK=qw@mail.gmail.com>

2017-05-02 23:37 GMT+02:00 Donald Stufft <donald at stufft.io>:
> I think the only reason we don?t have them on is because the macOS builds on
> Travis are _Super_ slow and regularly get a large backlog. Fast Finish and
> Allowed Failures would help with that though.

Maybe we can start with a small subset of tests and enlarge it later?

I may help to catch the most obvious failures.

Sadly, in my experience, on macOS, I only saw subtle failures, no
obvious bug in very common tests.

Victor

From antoine at python.org  Tue May  2 17:38:48 2017
From: antoine at python.org (Antoine Pitrou)
Date: Tue, 2 May 2017 23:38:48 +0200
Subject: [python-committers] No Travis-CI on OS X?
In-Reply-To: <44176935-4216-48FC-9189-2036C25AA3EF@stufft.io>
References: <dc452095-efd2-ed92-567c-20378189ac32@python.org>
 <44176935-4216-48FC-9189-2036C25AA3EF@stufft.io>
Message-ID: <c4c57f4d-1dfb-1c6c-bfc9-a850b76aac6e@python.org>



Is there a way to get faster OS X builds with our connections at Travis-CI?
I agree that OS X builds are usually very slow (though it depends on
daytime, see https://www.traviscistatus.com/#week), but perhaps it's
possible to improve on that :-)

Regards

Antoine.


Le 02/05/2017 ? 23:37, Donald Stufft a ?crit :
> 
> 
>> On May 2, 2017, at 5:35 PM, Antoine Pitrou <antoine at python.org
>> <mailto:antoine at python.org>> wrote:
>>
>>
>> Hi,
>>
>> Perhaps it would be possible to set up a Travis CI matrix entry for OS
>> X, those builds are often quite slow but at least it could be part of
>> the "allowed failures" suite.  That would help detect platform issues at
>> PR time rather than later :-)
>>
> 
> 
> I think the only reason we don?t have them on is because the macOS
> builds on Travis are _Super_ slow and regularly get a large backlog.
> Fast Finish and Allowed Failures would help with that though.
> 
> ?
> Donald Stufft
> 
> 
> 

From alex.gaynor at gmail.com  Tue May  2 19:43:17 2017
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Tue, 2 May 2017 19:43:17 -0400
Subject: [python-committers] No Travis-CI on OS X?
In-Reply-To: <c4c57f4d-1dfb-1c6c-bfc9-a850b76aac6e@python.org>
References: <dc452095-efd2-ed92-567c-20378189ac32@python.org>
 <44176935-4216-48FC-9189-2036C25AA3EF@stufft.io>
 <c4c57f4d-1dfb-1c6c-bfc9-a850b76aac6e@python.org>
Message-ID: <CAFRnB2WGf9FsUD4kXG-Uc0tWxjif1+VuKkEx9XjuHFVFx99jPQ@mail.gmail.com>

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

Alex

On Tue, May 2, 2017 at 5:38 PM, Antoine Pitrou <antoine at python.org> wrote:

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

From ncoghlan at gmail.com  Wed May  3 04:06:59 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 3 May 2017 18:06:59 +1000
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <dd70d99d-a553-a3b9-13b2-e666964a3c60@egenix.com>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
 <CADiSq7euVJ5dwz-g4cKOq5m=2U5DvAVyekcNaLbyhy8zY5+JEA@mail.gmail.com>
 <75286ac5-bf71-d660-f8ee-b060a2595a86@egenix.com>
 <20170502140754.50FE71310014@webabinitio.net>
 <4c720030-9633-a53c-cee3-39b5bcbad7cb@trueblade.com>
 <CAP7+vJJoxw-nUZKfAf+pX-=wVuQmgZHn7hXSkQyOR-pkBUxvWg@mail.gmail.com>
 <896d9003-2385-1194-bb22-03ed3439d2d4@trueblade.com>
 <E390CB63-C021-4CDC-B7F6-3B3C5687A185@stufft.io>
 <dd70d99d-a553-a3b9-13b2-e666964a3c60@egenix.com>
Message-ID: <CADiSq7cgKMUOb8toNDx3Rur8cvWvk26EsnxifP208qsk4WOsxQ@mail.gmail.com>

On 3 May 2017 at 05:09, M.-A. Lemburg <mal at egenix.com> wrote:
> This doesn't have much to do with UX/UI. It's mainly a questions
> of culture.

It's about the UI/UX for me, as Roundup is missing a few modern
collaboration features:

1. Easy user mentions: I can't just mention someone inline based on
autocompletion, I have to go up and add them to the nosy list
2. Easy issue mentions: I don't get autocompletion pop-ups for issue
cross-references to help fill in the right ones
3. Easy editing: if I post incorrect information, or the goal of an
issue changes, that gets buried in a subsequent correction post
4. Easy formatting: RoundUp is plaintext only, with no ReST or Markdown support
5. Easy reactions: no native +1 support to avoid "Usenet nod syndrome"
without spamming folks following the issue

None of them are particularly significant in isolation, but
collectively they and similar reductions in UX friction add up to a
significantly more fluid collaboration experience in the modern,
commercially supported, tools.

That said, those are also all straightforward enough to add that I
think the right question to ask is "How can we get them added to
either upstream Roundup, or at least our instance of it?", but
claiming that these kinds of UI/UX limitations don't matter or don't
currently exist won't help anyone.

> Github is more geared up for a culture of quick chat
> style comments, whereas bpo has traditionally seen a more elaborate
> in-depth discussions style.

This simply isn't an accurate characterisation of the way people use
GitHub - I participate in several GitHub and GitLab hosted projects,
and the issues and the PR level comments get used exactly the same way
that we use bugs.python.org.

The rationale for retaining the latter relates to maintaining URL
stability, avoiding breaking our own and third party integrations,
preserving current email-based individual workflows, and maintaining a
PSF controlled archive of significant design decisions, rather than
any particular flaws in alternative issue trackers.

Cheers,
Nick.

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

From antoine at python.org  Wed May  3 04:18:28 2017
From: antoine at python.org (Antoine Pitrou)
Date: Wed, 3 May 2017 10:18:28 +0200
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <CADiSq7cgKMUOb8toNDx3Rur8cvWvk26EsnxifP208qsk4WOsxQ@mail.gmail.com>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
 <CADiSq7euVJ5dwz-g4cKOq5m=2U5DvAVyekcNaLbyhy8zY5+JEA@mail.gmail.com>
 <75286ac5-bf71-d660-f8ee-b060a2595a86@egenix.com>
 <20170502140754.50FE71310014@webabinitio.net>
 <4c720030-9633-a53c-cee3-39b5bcbad7cb@trueblade.com>
 <CAP7+vJJoxw-nUZKfAf+pX-=wVuQmgZHn7hXSkQyOR-pkBUxvWg@mail.gmail.com>
 <896d9003-2385-1194-bb22-03ed3439d2d4@trueblade.com>
 <E390CB63-C021-4CDC-B7F6-3B3C5687A185@stufft.io>
 <dd70d99d-a553-a3b9-13b2-e666964a3c60@egenix.com>
 <CADiSq7cgKMUOb8toNDx3Rur8cvWvk26EsnxifP208qsk4WOsxQ@mail.gmail.com>
Message-ID: <87ac26c3-c1db-2c1d-47b6-0a5724963daf@python.org>


Le 03/05/2017 ? 10:06, Nick Coghlan a ?crit :
> On 3 May 2017 at 05:09, M.-A. Lemburg <mal at egenix.com> wrote:
>> This doesn't have much to do with UX/UI. It's mainly a questions
>> of culture.
> 
> It's about the UI/UX for me, as Roundup is missing a few modern
> collaboration features:
> 
> 1. Easy user mentions: I can't just mention someone inline based on
> autocompletion, I have to go up and add them to the nosy list
> 2. Easy issue mentions: I don't get autocompletion pop-ups for issue
> cross-references to help fill in the right ones
> 3. Easy editing: if I post incorrect information, or the goal of an
> issue changes, that gets buried in a subsequent correction post
> 4. Easy formatting: RoundUp is plaintext only, with no ReST or Markdown support
> 5. Easy reactions: no native +1 support to avoid "Usenet nod syndrome"
> without spamming folks following the issue

One growing gripe I have with Github is that their UI has become quite
slow to load and render in recent years.  It's become a bit grinding to
navigate through issues or load long-winded discussions.  bpo by
contrast is quite snappy (probably by virtue of having a more
rudimentary UI, of course).

As for "native" +1 mentions in Github, I tend to find them unhelpful, as
I don't know why people say "+1" at all.  So I usually ignore them.

Regards

Antoine.

From p.f.moore at gmail.com  Wed May  3 04:31:56 2017
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 3 May 2017 09:31:56 +0100
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <87ac26c3-c1db-2c1d-47b6-0a5724963daf@python.org>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
 <CADiSq7euVJ5dwz-g4cKOq5m=2U5DvAVyekcNaLbyhy8zY5+JEA@mail.gmail.com>
 <75286ac5-bf71-d660-f8ee-b060a2595a86@egenix.com>
 <20170502140754.50FE71310014@webabinitio.net>
 <4c720030-9633-a53c-cee3-39b5bcbad7cb@trueblade.com>
 <CAP7+vJJoxw-nUZKfAf+pX-=wVuQmgZHn7hXSkQyOR-pkBUxvWg@mail.gmail.com>
 <896d9003-2385-1194-bb22-03ed3439d2d4@trueblade.com>
 <E390CB63-C021-4CDC-B7F6-3B3C5687A185@stufft.io>
 <dd70d99d-a553-a3b9-13b2-e666964a3c60@egenix.com>
 <CADiSq7cgKMUOb8toNDx3Rur8cvWvk26EsnxifP208qsk4WOsxQ@mail.gmail.com>
 <87ac26c3-c1db-2c1d-47b6-0a5724963daf@python.org>
Message-ID: <CACac1F9F-Kv661Mcy9ebvviqgAJmXvOEpjVQc3MUJ0zK5pVinA@mail.gmail.com>

On 3 May 2017 at 09:18, Antoine Pitrou <antoine at python.org> wrote:
>
> As for "native" +1 mentions in Github, I tend to find them unhelpful, as
> I don't know why people say "+1" at all.  So I usually ignore them.

The point is that it's easier to ignore +1s in github, because they
don't trigger notification emails, and they don't add an extra
conversation element :-) On bpo, +1's are indistinguishable (except
for content) from substantive comments.

Paul

From mal at egenix.com  Wed May  3 05:30:39 2017
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 3 May 2017 11:30:39 +0200
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <CADiSq7cgKMUOb8toNDx3Rur8cvWvk26EsnxifP208qsk4WOsxQ@mail.gmail.com>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
 <CADiSq7euVJ5dwz-g4cKOq5m=2U5DvAVyekcNaLbyhy8zY5+JEA@mail.gmail.com>
 <75286ac5-bf71-d660-f8ee-b060a2595a86@egenix.com>
 <20170502140754.50FE71310014@webabinitio.net>
 <4c720030-9633-a53c-cee3-39b5bcbad7cb@trueblade.com>
 <CAP7+vJJoxw-nUZKfAf+pX-=wVuQmgZHn7hXSkQyOR-pkBUxvWg@mail.gmail.com>
 <896d9003-2385-1194-bb22-03ed3439d2d4@trueblade.com>
 <E390CB63-C021-4CDC-B7F6-3B3C5687A185@stufft.io>
 <dd70d99d-a553-a3b9-13b2-e666964a3c60@egenix.com>
 <CADiSq7cgKMUOb8toNDx3Rur8cvWvk26EsnxifP208qsk4WOsxQ@mail.gmail.com>
Message-ID: <1e574acc-6454-7dbb-6a20-c1c827588593@egenix.com>

I've had another look at some of the PRs we do have on Github and
must say, that it seems we're discussing a problem which doesn't
really exist predominantly on our PR tracker:

https://github.com/python/cpython/pulls?page=2&q=is%3Apr+is%3Aopen

I haven't checked all PRs, but the ones which have a few more
comments do mostly deal with code reviews.

On 03.05.2017 10:06, Nick Coghlan wrote:
> On 3 May 2017 at 05:09, M.-A. Lemburg <mal at egenix.com> wrote:
>> This doesn't have much to do with UX/UI. It's mainly a questions
>> of culture.
> 
> It's about the UI/UX for me, as Roundup is missing a few modern
> collaboration features:
> 
> 1. Easy user mentions: I can't just mention someone inline based on
> autocompletion, I have to go up and add them to the nosy list
> 2. Easy issue mentions: I don't get autocompletion pop-ups for issue
> cross-references to help fill in the right ones
> 3. Easy editing: if I post incorrect information, or the goal of an
> issue changes, that gets buried in a subsequent correction post
> 4. Easy formatting: RoundUp is plaintext only, with no ReST or Markdown support
> 5. Easy reactions: no native +1 support to avoid "Usenet nod syndrome"
> without spamming folks following the issue
> 
> None of them are particularly significant in isolation, but
> collectively they and similar reductions in UX friction add up to a
> significantly more fluid collaboration experience in the modern,
> commercially supported, tools.
> 
> That said, those are also all straightforward enough to add that I
> think the right question to ask is "How can we get them added to
> either upstream Roundup, or at least our instance of it?", but
> claiming that these kinds of UI/UX limitations don't matter or don't
> currently exist won't help anyone.

For the quality of discussions, I don't think the UI/UX matters
much. Having a better UI will help simplify discussions, but not
necessarily result in better content :-)

>> Github is more geared up for a culture of quick chat
>> style comments, whereas bpo has traditionally seen a more elaborate
>> in-depth discussions style.
> 
> This simply isn't an accurate characterisation of the way people use
> GitHub - I participate in several GitHub and GitLab hosted projects,
> and the issues and the PR level comments get used exactly the same way
> that we use bugs.python.org.

Well, it's my personal experience with Github. The UI often attracts
a lot of noise, causing the experience to not always be great. They
have added the +1 feature to at least reduce the number of me-too
comments.

And BTW: you do have the same problem we're discussing here on Github
as well: design discussions happening on the PRs instead of on the
issue tracker :-) Github supports this even more, since the distinction
between a PR thread and an issue discussion is not all that
clear - both are "issues" in the context of Github and can be
referenced using the same #ticket logic.

> The rationale for retaining the latter relates to maintaining URL
> stability, avoiding breaking our own and third party integrations,
> preserving current email-based individual workflows, and maintaining a
> PSF controlled archive of significant design decisions, rather than
> any particular flaws in alternative issue trackers.

I don't think we should open a discussion of whether to move away
from bpo or not.

The thread topic only refers to how we deal with
discussions which should be had on bpo rather than Github PRs
and I think we mostly agree that having them on bpo is better,
regardless of how we view Github discussions in general.

-- 
Marc-Andre Lemburg
eGenix.com

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


From p.f.moore at gmail.com  Wed May  3 05:51:19 2017
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 3 May 2017 10:51:19 +0100
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <1e574acc-6454-7dbb-6a20-c1c827588593@egenix.com>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
 <CADiSq7euVJ5dwz-g4cKOq5m=2U5DvAVyekcNaLbyhy8zY5+JEA@mail.gmail.com>
 <75286ac5-bf71-d660-f8ee-b060a2595a86@egenix.com>
 <20170502140754.50FE71310014@webabinitio.net>
 <4c720030-9633-a53c-cee3-39b5bcbad7cb@trueblade.com>
 <CAP7+vJJoxw-nUZKfAf+pX-=wVuQmgZHn7hXSkQyOR-pkBUxvWg@mail.gmail.com>
 <896d9003-2385-1194-bb22-03ed3439d2d4@trueblade.com>
 <E390CB63-C021-4CDC-B7F6-3B3C5687A185@stufft.io>
 <dd70d99d-a553-a3b9-13b2-e666964a3c60@egenix.com>
 <CADiSq7cgKMUOb8toNDx3Rur8cvWvk26EsnxifP208qsk4WOsxQ@mail.gmail.com>
 <1e574acc-6454-7dbb-6a20-c1c827588593@egenix.com>
Message-ID: <CACac1F_2d2c0arpwLYJwvHB125LT7YeqKjTekMiWYTTAUqvUBw@mail.gmail.com>

On 3 May 2017 at 10:30, M.-A. Lemburg <mal at egenix.com> wrote:
> I don't think we should open a discussion of whether to move away
> from bpo or not.

Agreed...

> The thread topic only refers to how we deal with
> discussions which should be had on bpo rather than Github PRs
> and I think we mostly agree that having them on bpo is better,
> regardless of how we view Github discussions in general.

I don't agree, but as you said above, that's not the topic of this thread.

Paul

From stefan at bytereef.org  Wed May  3 07:07:53 2017
From: stefan at bytereef.org (Stefan Krah)
Date: Wed, 3 May 2017 13:07:53 +0200
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <CADiSq7cgKMUOb8toNDx3Rur8cvWvk26EsnxifP208qsk4WOsxQ@mail.gmail.com>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
 <CADiSq7euVJ5dwz-g4cKOq5m=2U5DvAVyekcNaLbyhy8zY5+JEA@mail.gmail.com>
 <75286ac5-bf71-d660-f8ee-b060a2595a86@egenix.com>
 <20170502140754.50FE71310014@webabinitio.net>
 <4c720030-9633-a53c-cee3-39b5bcbad7cb@trueblade.com>
 <CAP7+vJJoxw-nUZKfAf+pX-=wVuQmgZHn7hXSkQyOR-pkBUxvWg@mail.gmail.com>
 <896d9003-2385-1194-bb22-03ed3439d2d4@trueblade.com>
 <E390CB63-C021-4CDC-B7F6-3B3C5687A185@stufft.io>
 <dd70d99d-a553-a3b9-13b2-e666964a3c60@egenix.com>
 <CADiSq7cgKMUOb8toNDx3Rur8cvWvk26EsnxifP208qsk4WOsxQ@mail.gmail.com>
Message-ID: <20170503110753.GA2819@bytereef.org>

On Wed, May 03, 2017 at 06:06:59PM +1000, Nick Coghlan wrote:
> 5. Easy reactions: no native +1 support to avoid "Usenet nod syndrome"
> without spamming folks following the issue

All platforms (except maybe Stackoverflow) who have voting use +1 more in a
"high five" sense than for actual agreement.

A lot of folks don't use these buttons out of principle so one will never
get an accurate "popular opinion".

Other people don't post at all because they don't like downvoting (there
goes the often cited inclusiveness).


Would you have liked those buttons in a memorable mailing list thread
about a trivial unittest change a couple of years ago? I wouldn't.


Voting should be reserved for concrete finished proposals.



Stefan Krah




From brett at python.org  Wed May  3 13:07:44 2017
From: brett at python.org (Brett Cannon)
Date: Wed, 03 May 2017 17:07:44 +0000
Subject: [python-committers] No Travis-CI on OS X?
In-Reply-To: <CAFRnB2WGf9FsUD4kXG-Uc0tWxjif1+VuKkEx9XjuHFVFx99jPQ@mail.gmail.com>
References: <dc452095-efd2-ed92-567c-20378189ac32@python.org>
 <44176935-4216-48FC-9189-2036C25AA3EF@stufft.io>
 <c4c57f4d-1dfb-1c6c-bfc9-a850b76aac6e@python.org>
 <CAFRnB2WGf9FsUD4kXG-Uc0tWxjif1+VuKkEx9XjuHFVFx99jPQ@mail.gmail.com>
Message-ID: <CAP1=2W4rAxuPJsWvbePMR+jQPj4i599uOY83ZUYTk4CCqVj11A@mail.gmail.com>

So Donald is right that the reason we don't have macOS builds through
Travis is due to the fact that back in February they had a horrible backlog
and added too much time to the total build.

But as Alex pointed out, Travis has subsequently increased their macOS
fleet and given the Python organization a better capacity (it should be
mentioned all we can get from travis without money is the ability to run
more concurrent jobs, but that doesn't solve the problem if the macOS fleet
in Travis is itself the bottleneck).

If someone wants to author a PR we could test the time on the master branch
and see what tweaks (if any) make the time added acceptable to everyone.

On Tue, 2 May 2017 at 16:43 Alex Gaynor <alex.gaynor at gmail.com> wrote:

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

From brett at python.org  Wed May  3 13:54:49 2017
From: brett at python.org (Brett Cannon)
Date: Wed, 03 May 2017 17:54:49 +0000
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
Message-ID: <CAP1=2W4uLLmbtzi4sc1W71eBY7Q-WQU=4t5bQmO-W5k1wpaBPA@mail.gmail.com>

I just touched up
https://github.com/python/cpython/blob/master/.github/CONTRIBUTING.rst to
explicitly mention that only code review issues should be discussed on
GitHub.

On Mon, 1 May 2017 at 15:32 Christian Heimes <christian at python.org> wrote:

> Hi all,
>
> since our move to Github I noticed a major increase in incoming patches.
> I like it. It clearly shows that it was a good decision.
>
> But I don't like the fact that Github reviews are cannibalizing issues
> on BPO. Before the migration decisions regarding a new feature or bug
> fix were made on the ticket system. For larger changes we used mailing
> lists or the PEP process. Rietveld, our previous code review tool, was
> just used to discuss code and implementation details. All important
> decisions still happened on BPO. We also used BPO to keep the experts or
> module maintainers in the loop.
>
> With Github I'm seeing a major paradigm shift. New contributors tend to
> use BPO as ticket number dispenser. Actual discussion seems to happen
> mostly on Github PRs. For me it makes it harder to follow discussion or
> to see discussions at all. I find Github notifications inferior to
> compared BPO's email notification -- mostly because Github spams me with
> notifications. For me it's not uncommon to have more than 1,000 open
> notifications waiting for my attention.
>
> This brings me to my questions
>
> 1) Should we try to move discussion back to BPO or are we fine with
> having major decisions just in Github PRs?
>
> 2) How can we retain enough information on BPO to keep it useful as
> research database for past decisions?
>
> 3) How can we keep module maintainers and experts in the loop? For
> example I don't have the resources to read all Github PRs, but I still
> like to keep an eye on the ssl and hashlib module.
>
> Christian
> _______________________________________________
> 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/20170503/a45fda91/attachment.html>

From christian at python.org  Wed May  3 14:20:00 2017
From: christian at python.org (Christian Heimes)
Date: Wed, 3 May 2017 20:20:00 +0200
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <CAP1=2W4uLLmbtzi4sc1W71eBY7Q-WQU=4t5bQmO-W5k1wpaBPA@mail.gmail.com>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
 <CAP1=2W4uLLmbtzi4sc1W71eBY7Q-WQU=4t5bQmO-W5k1wpaBPA@mail.gmail.com>
Message-ID: <71ac4a21-9f0b-4fd7-f657-d0a0cb4257da@python.org>

On 2017-05-03 19:54, Brett Cannon wrote:
> I just touched
> up https://github.com/python/cpython/blob/master/.github/CONTRIBUTING.rst to
> explicitly mention that only code review issues should be discussed on
> GitHub.

Thanks Brett!

I followed Donalds' advice and just pushed a modification to
.mention-bot
https://github.com/python/cpython/commit/feec3dc9c308052754f9e4848c1c1ddb007e9f66
. Let's wait and see if it actually works. :)

Christian

From brett at python.org  Wed May  3 13:25:18 2017
From: brett at python.org (Brett Cannon)
Date: Wed, 03 May 2017 17:25:18 +0000
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <bae9bffd-8329-740c-c903-a27550589ceb@udel.edu>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
 <CADiSq7euVJ5dwz-g4cKOq5m=2U5DvAVyekcNaLbyhy8zY5+JEA@mail.gmail.com>
 <75286ac5-bf71-d660-f8ee-b060a2595a86@egenix.com>
 <20170502140754.50FE71310014@webabinitio.net>
 <bae9bffd-8329-740c-c903-a27550589ceb@udel.edu>
Message-ID: <CAP1=2W5uDCGbQHEk0=Qk0L2sHb_OcDj3=643=e_9J=aowgskxA@mail.gmail.com>

On Tue, 2 May 2017 at 11:29 Terry Reedy <tjreedy at udel.edu> wrote:

> On 5/2/2017 10:07 AM, R. David Murray wrote:
> > On Tue, 02 May 2017 09:36:02 +0200, "M.-A. Lemburg" <mal at egenix.com>
> wrote:
>
> >> IMO, it's much easier for everyone to just always point people
> >> to BPO for discussions and keep PRs reserved for code reviews.
> >
> > I agree with Mark-Andre here.  It will take effort on our part to
> > make our culture be "discuss on BPO", but it will produce a much
> > superior history to what github PRs produce, so I think it is worth it.
>
> It would easier to move discussion to bpo if there were a clickable link
> from PR to bpo, just as there is in the opposite direction.  I believe
> that there is a workflow issue to add this, but last I knew, it was
> bogged down in where to put the link, or something.
>

The idea is being tracked at https://github.com/python/bedevere/issues/3 and
it isn't bogged down so much as the people typically writing these
bots/integrations having the time to implement the idea. I should also
mention I'm hoping to have the link be accompanied with a short blurb
reminding people to keep discussions on GH to just code reviewing and
everything else going to bpo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170503/1d3cf069/attachment-0001.html>

From mariatta.wijaya at gmail.com  Wed May  3 15:28:03 2017
From: mariatta.wijaya at gmail.com (Mariatta Wijaya)
Date: Wed, 3 May 2017 12:28:03 -0700
Subject: [python-committers] Proposal for procedures regarding CoC
 actions
In-Reply-To: <CADiSq7dV3ZSsYbrm=skOOd5K4CY5op-s-KdZUZjH-HGq=SM_eQ@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>
 <CADiSq7dV3ZSsYbrm=skOOd5K4CY5op-s-KdZUZjH-HGq=SM_eQ@mail.gmail.com>
Message-ID: <CAGbohnYp7YQ9iD1q8m8Sqn7zOYqdDmb6YMgfzSgvrOgmP4ox0Q@mail.gmail.com>

Hi,

First of all, sorry for bringing up an old thread.
I know this is an uncomfortable topic, and I also wish that we can just
avoid it, but ... I think we gotta do something about it.

I understand why Brett did what he did, and I support his decision.

I do agree with Raymond's point, that going forward, we should have
a procedure in place, we all need to know what the rules are, and how to
play by the rules.

Communities like Django Project and Write The Docs have clear enforcement
manuals on what to do in case of CoC violation:
https://www.djangoproject.com/conduct/enforcement-manual/
http://www.writethedocs.org/code-of-conduct-response/

Can we adopt something like that to our community, or do we have this
already?
If it requires involvement with the PSF board, who could bring this to
their attention? (I'm new I don't know how these things work yet)

Brett's step-by-step guide above based on Raymond's proposal seems like a
good start.
Does that need to be approved by the board first? Or can we start by
creating a PR to the devguide, and continue the discussion there?

I also want to discuss what the different actions to be taken in case
someone is being negative.
In one of the mailing lists, the violator gets a warning for their first
offense.
What if their first offense is severe enough, maybe a warning may not be
suitable?
Do we (core developers) want to decide all of these ourselves, or do we
leave it PSF board to decide?

I just want to make sure that we are taking some actions going forward.



Mariatta Wijaya

On Sun, Apr 2, 2017 at 8:04 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> 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
> _______________________________________________
> 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/20170503/5cde8845/attachment.html>

From brian at python.org  Wed May  3 15:39:20 2017
From: brian at python.org (Brian Curtin)
Date: Wed, 3 May 2017 15:39:20 -0400
Subject: [python-committers] Proposal for procedures regarding CoC
 actions
In-Reply-To: <CAGbohnYp7YQ9iD1q8m8Sqn7zOYqdDmb6YMgfzSgvrOgmP4ox0Q@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>
 <CADiSq7dV3ZSsYbrm=skOOd5K4CY5op-s-KdZUZjH-HGq=SM_eQ@mail.gmail.com>
 <CAGbohnYp7YQ9iD1q8m8Sqn7zOYqdDmb6YMgfzSgvrOgmP4ox0Q@mail.gmail.com>
Message-ID: <CAD+XWwrEyCjjSb=acv918KpK-+-HwPxAoq1-yVT1bh7n0D5qrg@mail.gmail.com>

On Wed, May 3, 2017 at 3:28 PM, Mariatta Wijaya <mariatta.wijaya at gmail.com>
wrote:

> Hi,
>
> First of all, sorry for bringing up an old thread.
> I know this is an uncomfortable topic, and I also wish that we can just
> avoid it, but ... I think we gotta do something about it.
>
> I understand why Brett did what he did, and I support his decision.
>
> I do agree with Raymond's point, that going forward, we should have
> a procedure in place, we all need to know what the rules are, and how to
> play by the rules.
>
> Communities like Django Project and Write The Docs have clear enforcement
> manuals on what to do in case of CoC violation:
> https://www.djangoproject.com/conduct/enforcement-manual/
> http://www.writethedocs.org/code-of-conduct-response/
>
> Can we adopt something like that to our community, or do we have this
> already?
> If it requires involvement with the PSF board, who could bring this to
> their attention? (I'm new I don't know how these things work yet)
>

It should not require PSF involvement. Enforcing violation of the CoC is up
whichever group applied the CoC and how it factors into the medium it's
being applied to, so I think we just do that right here. That's partly why
the CoC itself says nothing about consequences, as the myriad of
environments this could be (and is) applied to vary, so there is no
one-size-fits-all answer to what happens when it's violated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170503/a9e742ec/attachment.html>

From mal at egenix.com  Wed May  3 15:48:15 2017
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 3 May 2017 21:48:15 +0200
Subject: [python-committers] Proposal for procedures regarding CoC
 actions
In-Reply-To: <CAGbohnYp7YQ9iD1q8m8Sqn7zOYqdDmb6YMgfzSgvrOgmP4ox0Q@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>
 <CADiSq7dV3ZSsYbrm=skOOd5K4CY5op-s-KdZUZjH-HGq=SM_eQ@mail.gmail.com>
 <CAGbohnYp7YQ9iD1q8m8Sqn7zOYqdDmb6YMgfzSgvrOgmP4ox0Q@mail.gmail.com>
Message-ID: <c4c16b2a-5897-017d-034e-c6fea5b9920b@egenix.com>

Since this is a matter outside the realm of committers, the
PSF board will have to ultimately decide on any actions taken.

The committers can report issues to the board and provide
information useful for their decisions, the bad actor also has
to be given a chance to respond to allegations and be heard.
Then the board can decide what to do.

The two manuals should not be used or proposed as a guideline
for CoC handling, since they completely ignore the basic rights
of the alleged bad actors to a fair process.

When I was a board member, we had already discussed this at the board
level and used to deal with such issues on a case by case basis,
which always included trying to contact the persons
in questions either directly or via a mediator.

This has worked well and I don't see a good reason to suggest
using a less open and fair approach.

Cheers,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, May 03 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 03.05.2017 21:28, Mariatta Wijaya wrote:
> Hi,
> 
> First of all, sorry for bringing up an old thread.
> I know this is an uncomfortable topic, and I also wish that we can just
> avoid it, but ... I think we gotta do something about it.
> 
> I understand why Brett did what he did, and I support his decision.
> 
> I do agree with Raymond's point, that going forward, we should have
> a procedure in place, we all need to know what the rules are, and how to
> play by the rules.
> 
> Communities like Django Project and Write The Docs have clear enforcement
> manuals on what to do in case of CoC violation:
> https://www.djangoproject.com/conduct/enforcement-manual/
> http://www.writethedocs.org/code-of-conduct-response/
> 
> Can we adopt something like that to our community, or do we have this
> already?
> If it requires involvement with the PSF board, who could bring this to
> their attention? (I'm new I don't know how these things work yet)
> 
> Brett's step-by-step guide above based on Raymond's proposal seems like a
> good start.
> Does that need to be approved by the board first? Or can we start by
> creating a PR to the devguide, and continue the discussion there?
> 
> I also want to discuss what the different actions to be taken in case
> someone is being negative.
> In one of the mailing lists, the violator gets a warning for their first
> offense.
> What if their first offense is severe enough, maybe a warning may not be
> suitable?
> Do we (core developers) want to decide all of these ourselves, or do we
> leave it PSF board to decide?
> 
> I just want to make sure that we are taking some actions going forward.
> 
> 
> 
> Mariatta Wijaya
> 
> On Sun, Apr 2, 2017 at 8:04 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
>> 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
>> _______________________________________________
>> 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/
>>
> 
> 
> 
> _______________________________________________
> 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 guido at python.org  Wed May  3 16:10:16 2017
From: guido at python.org (Guido van Rossum)
Date: Wed, 3 May 2017 13:10:16 -0700
Subject: [python-committers] Proposal for procedures regarding CoC
 actions
In-Reply-To: <c4c16b2a-5897-017d-034e-c6fea5b9920b@egenix.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>
 <CADiSq7dV3ZSsYbrm=skOOd5K4CY5op-s-KdZUZjH-HGq=SM_eQ@mail.gmail.com>
 <CAGbohnYp7YQ9iD1q8m8Sqn7zOYqdDmb6YMgfzSgvrOgmP4ox0Q@mail.gmail.com>
 <c4c16b2a-5897-017d-034e-c6fea5b9920b@egenix.com>
Message-ID: <CAP7+vJ+gCpXk7tfjc4zoj7m4HGUuo==1tmyPvc2gNUTd+ApKYQ@mail.gmail.com>

Two ex-board members disagree. I have to side with Brian; the PSF board
should have minimal say in how the developers develop.

Note, I'm fine with the board being the arbiter when someone disagrees with
their ban though -- there's got to be a "higher authority" for appeals. But
I don't agree that the board should be the decider on the initial ban.
Maybe for additional oversight bans should be required to be reported to
the board in a timely fashion. (Ain't I the lawyer. ;-)

On Wed, May 3, 2017 at 12:48 PM, M.-A. Lemburg <mal at egenix.com> wrote:

> Since this is a matter outside the realm of committers, the
> PSF board will have to ultimately decide on any actions taken.
>
> The committers can report issues to the board and provide
> information useful for their decisions, the bad actor also has
> to be given a chance to respond to allegations and be heard.
> Then the board can decide what to do.
>
> The two manuals should not be used or proposed as a guideline
> for CoC handling, since they completely ignore the basic rights
> of the alleged bad actors to a fair process.
>
> When I was a board member, we had already discussed this at the board
> level and used to deal with such issues on a case by case basis,
> which always included trying to contact the persons
> in questions either directly or via a mediator.
>
> This has worked well and I don't see a good reason to suggest
> using a less open and fair approach.
>
> Cheers,
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Experts (#1, May 03 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 03.05.2017 21:28, Mariatta Wijaya wrote:
> > Hi,
> >
> > First of all, sorry for bringing up an old thread.
> > I know this is an uncomfortable topic, and I also wish that we can just
> > avoid it, but ... I think we gotta do something about it.
> >
> > I understand why Brett did what he did, and I support his decision.
> >
> > I do agree with Raymond's point, that going forward, we should have
> > a procedure in place, we all need to know what the rules are, and how to
> > play by the rules.
> >
> > Communities like Django Project and Write The Docs have clear enforcement
> > manuals on what to do in case of CoC violation:
> > https://www.djangoproject.com/conduct/enforcement-manual/
> > http://www.writethedocs.org/code-of-conduct-response/
> >
> > Can we adopt something like that to our community, or do we have this
> > already?
> > If it requires involvement with the PSF board, who could bring this to
> > their attention? (I'm new I don't know how these things work yet)
> >
> > Brett's step-by-step guide above based on Raymond's proposal seems like a
> > good start.
> > Does that need to be approved by the board first? Or can we start by
> > creating a PR to the devguide, and continue the discussion there?
> >
> > I also want to discuss what the different actions to be taken in case
> > someone is being negative.
> > In one of the mailing lists, the violator gets a warning for their first
> > offense.
> > What if their first offense is severe enough, maybe a warning may not be
> > suitable?
> > Do we (core developers) want to decide all of these ourselves, or do we
> > leave it PSF board to decide?
> >
> > I just want to make sure that we are taking some actions going forward.
> >
> >
> >
> > Mariatta Wijaya
> >
> > On Sun, Apr 2, 2017 at 8:04 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> >
> >> 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
> >> _______________________________________________
> >> 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/
> >>
> >
> >
> >
> > _______________________________________________
> > 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/
> >
>
> _______________________________________________
> 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/
>



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

From tjreedy at udel.edu  Wed May  3 16:42:28 2017
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 3 May 2017 16:42:28 -0400
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <CAP1=2W5uDCGbQHEk0=Qk0L2sHb_OcDj3=643=e_9J=aowgskxA@mail.gmail.com>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
 <CADiSq7euVJ5dwz-g4cKOq5m=2U5DvAVyekcNaLbyhy8zY5+JEA@mail.gmail.com>
 <75286ac5-bf71-d660-f8ee-b060a2595a86@egenix.com>
 <20170502140754.50FE71310014@webabinitio.net>
 <bae9bffd-8329-740c-c903-a27550589ceb@udel.edu>
 <CAP1=2W5uDCGbQHEk0=Qk0L2sHb_OcDj3=643=e_9J=aowgskxA@mail.gmail.com>
Message-ID: <02d518f4-cd60-a9d4-a18c-c4a05da154d3@udel.edu>

On 5/3/2017 1:25 PM, Brett Cannon wrote:
> 
> On Tue, 2 May 2017 at 11:29 Terry Reedy <tjreedy at udel.edu 
> <mailto:tjreedy at udel.edu>> wrote:

>     It would easier to move discussion to bpo if there were a clickable link
>     from PR to bpo, just as there is in the opposite direction.  I believe
>     that there is a workflow issue to add this, but last I knew, it was
>     bogged down in where to put the link, or something.
> 
> The idea is being tracked at 
> https://github.com/python/bedevere/issues/3 and it isn't bogged down so 
> much as the people typically writing these bots/integrations having the 
> time to implement the idea. I should also mention I'm hoping to have the 
> link be accompanied with a short blurb reminding people to keep 
> discussions on GH to just code reviewing and everything else going to bpo.

I saw that and like the idea.

Moving on ...  The next issue I have run into is that people can submit, 
review, or otherwise comment on the PR without being nosy on the issue. 
They will thus miss any further bpo discussion.  One could not submit or 
comment on a bpo patch without becoming nosy on the issue (and the same 
might have been true for Rietveld reviews).  Is there any possibility of 
making people nosy on bpo automatically if nosy on a PR?


From ncoghlan at gmail.com  Thu May  4 09:53:51 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 4 May 2017 23:53:51 +1000
Subject: [python-committers] Proposal for procedures regarding CoC
 actions
In-Reply-To: <CAP7+vJ+gCpXk7tfjc4zoj7m4HGUuo==1tmyPvc2gNUTd+ApKYQ@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>
 <CADiSq7dV3ZSsYbrm=skOOd5K4CY5op-s-KdZUZjH-HGq=SM_eQ@mail.gmail.com>
 <CAGbohnYp7YQ9iD1q8m8Sqn7zOYqdDmb6YMgfzSgvrOgmP4ox0Q@mail.gmail.com>
 <c4c16b2a-5897-017d-034e-c6fea5b9920b@egenix.com>
 <CAP7+vJ+gCpXk7tfjc4zoj7m4HGUuo==1tmyPvc2gNUTd+ApKYQ@mail.gmail.com>
Message-ID: <CADiSq7d7bOaDLi5Z7fxh242VN8+cAoDrS5zOetfT0vjqGNWBrQ@mail.gmail.com>

On 4 May 2017 at 06:10, Guido van Rossum <guido at python.org> wrote:
> Two ex-board members disagree. I have to side with Brian; the PSF board
> should have minimal say in how the developers develop.
>
> Note, I'm fine with the board being the arbiter when someone disagrees with
> their ban though -- there's got to be a "higher authority" for appeals. But
> I don't agree that the board should be the decider on the initial ban.

I think initial temporary suspensions should definitely be handled
without involving the Board (just as they are for any other PSF
provided channel).

I also think there are two cases that can definitely only be handled
at the board level:

- folks that feel they've been treated unfairly by the core
development team appealing to the Board for reconsideration
- the core development team recommending that a ban from our channels
(python-dev, python-ideas, core-workflow, bugs.python.org, GitHub
python org) be extended to other PSF provided channels

I'd previously said that I thought conversion of temporary suspensions
to permanent bans should also go to the Board, but I now think it
makes more sense to handle that as:

- the Board gets notified if a temporary suspension is now considered
a permanent ban
- they only need to get further involved if the ban is appealed

Cheers,
Nick.

P.S. Don't forget that the specific context here is *public* behaviour
that is the domain of channel moderators, rather than confidentially
reported Code of Conduct concerns. Handling of the latter will remain
with the PSF Board or their appointed representatives, independently
of how we handle moderation of the development channels.

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

From antoine at python.org  Thu May  4 10:44:30 2017
From: antoine at python.org (Antoine Pitrou)
Date: Thu, 4 May 2017 16:44:30 +0200
Subject: [python-committers] Coverage build broken?
Message-ID: <37aab3f1-8a99-2ced-17c9-33626019bece@python.org>


Hello,

I'm getting the following error on the Travis-CI coverage job:
(from https://travis-ci.org/python/cpython/jobs/228758363#L837 )

Collecting coverage
  Downloading coverage-4.3.4.tar.gz (361kB)
    Complete output from command python setup.py egg_info:
    running egg_info
    creating pip-egg-info/coverage.egg-info
    writing pip-egg-info/coverage.egg-info/PKG-INFO
    writing dependency_links to
pip-egg-info/coverage.egg-info/dependency_links.txt
    writing entry points to pip-egg-info/coverage.egg-info/entry_points.txt
    writing top-level names to pip-egg-info/coverage.egg-info/top_level.txt
    writing manifest file 'pip-egg-info/coverage.egg-info/SOURCES.txt'
    warning: manifest_maker: standard file '-c' not found

    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/tmp/pip-build-ewtgqc2r/coverage/setup.py", line 204, in
<module>
        main()
      File "/tmp/pip-build-ewtgqc2r/coverage/setup.py", line 194, in main
        setup(**setup_args)
      File "/home/travis/build/python/cpython/Lib/distutils/core.py",
line 148, in setup
        dist.run_commands()
      File "/home/travis/build/python/cpython/Lib/distutils/dist.py",
line 955, in run_commands
        self.run_command(cmd)
      File "/home/travis/build/python/cpython/Lib/distutils/dist.py",
line 974, in run_command
        cmd_obj.run()
      File
"/home/travis/build/python/cpython/venv/lib/python3.7/site-packages/setuptools/command/egg_info.py",
line 279, in run
        self.find_sources()
      File
"/home/travis/build/python/cpython/venv/lib/python3.7/site-packages/setuptools/command/egg_info.py",
line 306, in find_sources
        mm.run()
      File
"/home/travis/build/python/cpython/venv/lib/python3.7/site-packages/setuptools/command/egg_info.py",
line 533, in run
        self.add_defaults()
      File
"/home/travis/build/python/cpython/venv/lib/python3.7/site-packages/setuptools/command/egg_info.py",
line 562, in add_defaults
        sdist.add_defaults(self)
      File
"/home/travis/build/python/cpython/Lib/distutils/command/sdist.py", line
228, in add_defaults
        self._add_defaults_ext()
      File
"/home/travis/build/python/cpython/Lib/distutils/command/sdist.py", line
311, in _add_defaults_ext
        build_ext = self.get_finalized_command('build_ext')
      File "/home/travis/build/python/cpython/Lib/distutils/cmd.py",
line 299, in get_finalized_command
        cmd_obj.ensure_finalized()
      File "/home/travis/build/python/cpython/Lib/distutils/cmd.py",
line 107, in ensure_finalized
        self.finalize_options()
      File
"/home/travis/build/python/cpython/Lib/distutils/command/build_ext.py",
line 150, in finalize_options
        py_include = sysconfig.get_python_inc()
      File
"/home/travis/build/python/cpython/Lib/distutils/sysconfig.py", line
100, in get_python_inc
        incdir = os.path.join(_sys_home, get_config_var('AST_H_DIR'))
      File "/home/travis/build/python/cpython/Lib/posixpath.py", line
92, in join
        genericpath._check_arg_types('join', a, *p)
      File "/home/travis/build/python/cpython/Lib/genericpath.py", line
149, in _check_arg_types
        (funcname, s.__class__.__name__)) from None
    TypeError: join() argument must be str or bytes, not 'NoneType'

    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in
/tmp/pip-build-ewtgqc2r/coverage/


Regards

Antoine.

From brett at python.org  Thu May  4 13:44:46 2017
From: brett at python.org (Brett Cannon)
Date: Thu, 04 May 2017 17:44:46 +0000
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <02d518f4-cd60-a9d4-a18c-c4a05da154d3@udel.edu>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
 <CADiSq7euVJ5dwz-g4cKOq5m=2U5DvAVyekcNaLbyhy8zY5+JEA@mail.gmail.com>
 <75286ac5-bf71-d660-f8ee-b060a2595a86@egenix.com>
 <20170502140754.50FE71310014@webabinitio.net>
 <bae9bffd-8329-740c-c903-a27550589ceb@udel.edu>
 <CAP1=2W5uDCGbQHEk0=Qk0L2sHb_OcDj3=643=e_9J=aowgskxA@mail.gmail.com>
 <02d518f4-cd60-a9d4-a18c-c4a05da154d3@udel.edu>
Message-ID: <CAP1=2W4MDmhcHeMaCzX-dyP7B4SB8Nk70_5bVxGxLfWEtJfTZA@mail.gmail.com>

On Wed, 3 May 2017 at 13:42 Terry Reedy <tjreedy at udel.edu> wrote:

> On 5/3/2017 1:25 PM, Brett Cannon wrote:
> >
> > On Tue, 2 May 2017 at 11:29 Terry Reedy <tjreedy at udel.edu
> > <mailto:tjreedy at udel.edu>> wrote:
>
> >     It would easier to move discussion to bpo if there were a clickable
> link
> >     from PR to bpo, just as there is in the opposite direction.  I
> believe
> >     that there is a workflow issue to add this, but last I knew, it was
> >     bogged down in where to put the link, or something.
> >
> > The idea is being tracked at
> > https://github.com/python/bedevere/issues/3 and it isn't bogged down so
> > much as the people typically writing these bots/integrations having the
> > time to implement the idea. I should also mention I'm hoping to have the
> > link be accompanied with a short blurb reminding people to keep
> > discussions on GH to just code reviewing and everything else going to
> bpo.
>
> I saw that and like the idea.
>
> Moving on ...  The next issue I have run into is that people can submit,
> review, or otherwise comment on the PR without being nosy on the issue.
> They will thus miss any further bpo discussion.  One could not submit or
> comment on a bpo patch without becoming nosy on the issue (and the same
> might have been true for Rietveld reviews).  Is there any possibility of
> making people nosy on bpo automatically if nosy on a PR?
>

Possible, yes. Trick with this is getting the change made. People need to
realize that basically Maciej and Ezio have done all of the bugs.python.org
code changes as of late (although a lot of the initial work was done by
Anish Shah as a GSoC project). So you basically need to either convince one
of those two to make this work or it's time to start learning the Roundup
code base :)

(And just so I can claim I stated this publicly at some point; our Roundup
installation I think runs on Python 2.6 and Roundup itself has not been
ported to Python 3, so I don't know what we want to do if Roundup doesn't
make the switch by 2020.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170504/15d486af/attachment.html>

From brett at python.org  Thu May  4 13:54:18 2017
From: brett at python.org (Brett Cannon)
Date: Thu, 04 May 2017 17:54:18 +0000
Subject: [python-committers] Coverage build broken?
In-Reply-To: <37aab3f1-8a99-2ced-17c9-33626019bece@python.org>
References: <37aab3f1-8a99-2ced-17c9-33626019bece@python.org>
Message-ID: <CAP1=2W7=X1RjzqAVSOD2d5Tf7kBVbpGLOeDgauAYbKojvKjV5g@mail.gmail.com>

I newer didn't have that issue (it failed for testing reasons):
https://travis-ci.org/python/cpython/jobs/228820650.

I tried to re-run the build step to see if I could reproduce but the PR is
already merged so I can't check. But I'm a little surprised it tried to
build the sdist since coverage.py should have the appropriate wheel (
https://pypi.org/project/coverage/#files).

So I guess my answer is "I don't know what happened, but it seems to be an
isolated case".

On Thu, 4 May 2017 at 07:47 Antoine Pitrou <antoine at python.org> wrote:

>
> Hello,
>
> I'm getting the following error on the Travis-CI coverage job:
> (from https://travis-ci.org/python/cpython/jobs/228758363#L837 )
>
> Collecting coverage
>   Downloading coverage-4.3.4.tar.gz (361kB)
> ?    Complete output from command python setup.py egg_info:
>     running egg_info
>     creating pip-egg-info/coverage.egg-info
>     writing pip-egg-info/coverage.egg-info/PKG-INFO
>     writing dependency_links to
> pip-egg-info/coverage.egg-info/dependency_links.txt
>     writing entry points to pip-egg-info/coverage.egg-info/entry_points.txt
>     writing top-level names to pip-egg-info/coverage.egg-info/top_level.txt
>     writing manifest file 'pip-egg-info/coverage.egg-info/SOURCES.txt'
>     warning: manifest_maker: standard file '-c' not found
>
>     Traceback (most recent call last):
>       File "<string>", line 1, in <module>
>       File "/tmp/pip-build-ewtgqc2r/coverage/setup.py", line 204, in
> <module>
>         main()
>       File "/tmp/pip-build-ewtgqc2r/coverage/setup.py", line 194, in main
>         setup(**setup_args)
>       File "/home/travis/build/python/cpython/Lib/distutils/core.py",
> line 148, in setup
>         dist.run_commands()
>       File "/home/travis/build/python/cpython/Lib/distutils/dist.py",
> line 955, in run_commands
>         self.run_command(cmd)
>       File "/home/travis/build/python/cpython/Lib/distutils/dist.py",
> line 974, in run_command
>         cmd_obj.run()
>       File
>
> "/home/travis/build/python/cpython/venv/lib/python3.7/site-packages/setuptools/command/egg_info.py",
> line 279, in run
>         self.find_sources()
>       File
>
> "/home/travis/build/python/cpython/venv/lib/python3.7/site-packages/setuptools/command/egg_info.py",
> line 306, in find_sources
>         mm.run()
>       File
>
> "/home/travis/build/python/cpython/venv/lib/python3.7/site-packages/setuptools/command/egg_info.py",
> line 533, in run
>         self.add_defaults()
>       File
>
> "/home/travis/build/python/cpython/venv/lib/python3.7/site-packages/setuptools/command/egg_info.py",
> line 562, in add_defaults
>         sdist.add_defaults(self)
>       File
> "/home/travis/build/python/cpython/Lib/distutils/command/sdist.py", line
> 228, in add_defaults
>         self._add_defaults_ext()
>       File
> "/home/travis/build/python/cpython/Lib/distutils/command/sdist.py", line
> 311, in _add_defaults_ext
>         build_ext = self.get_finalized_command('build_ext')
>       File "/home/travis/build/python/cpython/Lib/distutils/cmd.py",
> line 299, in get_finalized_command
>         cmd_obj.ensure_finalized()
>       File "/home/travis/build/python/cpython/Lib/distutils/cmd.py",
> line 107, in ensure_finalized
>         self.finalize_options()
>       File
> "/home/travis/build/python/cpython/Lib/distutils/command/build_ext.py",
> line 150, in finalize_options
>         py_include = sysconfig.get_python_inc()
>       File
> "/home/travis/build/python/cpython/Lib/distutils/sysconfig.py", line
> 100, in get_python_inc
>         incdir = os.path.join(_sys_home, get_config_var('AST_H_DIR'))
>       File "/home/travis/build/python/cpython/Lib/posixpath.py", line
> 92, in join
>         genericpath._check_arg_types('join', a, *p)
>       File "/home/travis/build/python/cpython/Lib/genericpath.py", line
> 149, in _check_arg_types
>         (funcname, s.__class__.__name__)) from None
>     TypeError: join() argument must be str or bytes, not 'NoneType'
>
>     ----------------------------------------
> ?Command "python setup.py egg_info" failed with error code 1 in
> /tmp/pip-build-ewtgqc2r/coverage/?
>
>
> Regards
>
> Antoine.
> _______________________________________________
> 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/20170504/b7f881ae/attachment.html>

From brett at python.org  Thu May  4 14:08:05 2017
From: brett at python.org (Brett Cannon)
Date: Thu, 04 May 2017 18:08:05 +0000
Subject: [python-committers] Coverage build broken?
In-Reply-To: <CAP1=2W7=X1RjzqAVSOD2d5Tf7kBVbpGLOeDgauAYbKojvKjV5g@mail.gmail.com>
References: <37aab3f1-8a99-2ced-17c9-33626019bece@python.org>
 <CAP1=2W7=X1RjzqAVSOD2d5Tf7kBVbpGLOeDgauAYbKojvKjV5g@mail.gmail.com>
Message-ID: <CAP1=2W4X1fjh0kDgSqj9PA4ibg12L7jWT-=jcBWeCsZaGMLfpg@mail.gmail.com>

Nevermind, I found a more recent failure, e.g.
https://travis-ci.org/python/cpython/jobs/228773144 (I was looking at a 3.6
build).

Whatever the cause it seems to be limited to master and the first failure
is https://travis-ci.org/python/cpython/jobs/228409786 which corresponds to
Victor's regen-all change
https://github.com/python/cpython/commit/a5c62a8e9f0de6c4133825a5710984a3cd5e102b
.
I'm not quite sure how the build changes broke distutils, though.

On Thu, 4 May 2017 at 10:54 Brett Cannon <brett at python.org> wrote:

> I newer didn't have that issue (it failed for testing reasons):
> https://travis-ci.org/python/cpython/jobs/228820650.
>
> I tried to re-run the build step to see if I could reproduce but the PR is
> already merged so I can't check. But I'm a little surprised it tried to
> build the sdist since coverage.py should have the appropriate wheel (
> https://pypi.org/project/coverage/#files).
>
> So I guess my answer is "I don't know what happened, but it seems to be an
> isolated case".
>
> On Thu, 4 May 2017 at 07:47 Antoine Pitrou <antoine at python.org> wrote:
>
>>
>> Hello,
>>
>> I'm getting the following error on the Travis-CI coverage job:
>> (from https://travis-ci.org/python/cpython/jobs/228758363#L837 )
>>
>> Collecting coverage
>>   Downloading coverage-4.3.4.tar.gz (361kB)
>> ?    Complete output from command python setup.py egg_info:
>>     running egg_info
>>     creating pip-egg-info/coverage.egg-info
>>     writing pip-egg-info/coverage.egg-info/PKG-INFO
>>     writing dependency_links to
>> pip-egg-info/coverage.egg-info/dependency_links.txt
>>     writing entry points to
>> pip-egg-info/coverage.egg-info/entry_points.txt
>>     writing top-level names to
>> pip-egg-info/coverage.egg-info/top_level.txt
>>     writing manifest file 'pip-egg-info/coverage.egg-info/SOURCES.txt'
>>     warning: manifest_maker: standard file '-c' not found
>>
>>     Traceback (most recent call last):
>>       File "<string>", line 1, in <module>
>>       File "/tmp/pip-build-ewtgqc2r/coverage/setup.py", line 204, in
>> <module>
>>         main()
>>       File "/tmp/pip-build-ewtgqc2r/coverage/setup.py", line 194, in main
>>         setup(**setup_args)
>>       File "/home/travis/build/python/cpython/Lib/distutils/core.py",
>> line 148, in setup
>>         dist.run_commands()
>>       File "/home/travis/build/python/cpython/Lib/distutils/dist.py",
>> line 955, in run_commands
>>         self.run_command(cmd)
>>       File "/home/travis/build/python/cpython/Lib/distutils/dist.py",
>> line 974, in run_command
>>         cmd_obj.run()
>>       File
>>
>> "/home/travis/build/python/cpython/venv/lib/python3.7/site-packages/setuptools/command/egg_info.py",
>> line 279, in run
>>         self.find_sources()
>>       File
>>
>> "/home/travis/build/python/cpython/venv/lib/python3.7/site-packages/setuptools/command/egg_info.py",
>> line 306, in find_sources
>>         mm.run()
>>       File
>>
>> "/home/travis/build/python/cpython/venv/lib/python3.7/site-packages/setuptools/command/egg_info.py",
>> line 533, in run
>>         self.add_defaults()
>>       File
>>
>> "/home/travis/build/python/cpython/venv/lib/python3.7/site-packages/setuptools/command/egg_info.py",
>> line 562, in add_defaults
>>         sdist.add_defaults(self)
>>       File
>> "/home/travis/build/python/cpython/Lib/distutils/command/sdist.py", line
>> 228, in add_defaults
>>         self._add_defaults_ext()
>>       File
>> "/home/travis/build/python/cpython/Lib/distutils/command/sdist.py", line
>> 311, in _add_defaults_ext
>>         build_ext = self.get_finalized_command('build_ext')
>>       File "/home/travis/build/python/cpython/Lib/distutils/cmd.py",
>> line 299, in get_finalized_command
>>         cmd_obj.ensure_finalized()
>>       File "/home/travis/build/python/cpython/Lib/distutils/cmd.py",
>> line 107, in ensure_finalized
>>         self.finalize_options()
>>       File
>> "/home/travis/build/python/cpython/Lib/distutils/command/build_ext.py",
>> line 150, in finalize_options
>>         py_include = sysconfig.get_python_inc()
>>       File
>> "/home/travis/build/python/cpython/Lib/distutils/sysconfig.py", line
>> 100, in get_python_inc
>>         incdir = os.path.join(_sys_home, get_config_var('AST_H_DIR'))
>>       File "/home/travis/build/python/cpython/Lib/posixpath.py", line
>> 92, in join
>>         genericpath._check_arg_types('join', a, *p)
>>       File "/home/travis/build/python/cpython/Lib/genericpath.py", line
>> 149, in _check_arg_types
>>         (funcname, s.__class__.__name__)) from None
>>     TypeError: join() argument must be str or bytes, not 'NoneType'
>>
>>     ----------------------------------------
>> ?Command "python setup.py egg_info" failed with error code 1 in
>> /tmp/pip-build-ewtgqc2r/coverage/?
>>
>>
>> Regards
>>
>> Antoine.
>> _______________________________________________
>> 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/20170504/44d22adc/attachment-0001.html>

From victor.stinner at gmail.com  Thu May  4 16:51:33 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Thu, 4 May 2017 22:51:33 +0200
Subject: [python-committers] Coverage build broken?
In-Reply-To: <37aab3f1-8a99-2ced-17c9-33626019bece@python.org>
References: <37aab3f1-8a99-2ced-17c9-33626019bece@python.org>
Message-ID: <CAMpsgwZjJqpoXF8C980Sz=gYGNAQVbAiqfkq7uEkWYa+yQ5U7w@mail.gmail.com>

It seems like a real bug and a regression, I opened an issue to track it:
http://bugs.python.org/issue30273

Victor

2017-05-04 16:44 GMT+02:00 Antoine Pitrou <antoine at python.org>:
>
> Hello,
>
> I'm getting the following error on the Travis-CI coverage job:
> (from https://travis-ci.org/python/cpython/jobs/228758363#L837 )
>
> Collecting coverage
>   Downloading coverage-4.3.4.tar.gz (361kB)
> ?    Complete output from command python setup.py egg_info:
>     running egg_info
>     creating pip-egg-info/coverage.egg-info
>     writing pip-egg-info/coverage.egg-info/PKG-INFO
>     writing dependency_links to
> pip-egg-info/coverage.egg-info/dependency_links.txt
>     writing entry points to pip-egg-info/coverage.egg-info/entry_points.txt
>     writing top-level names to pip-egg-info/coverage.egg-info/top_level.txt
>     writing manifest file 'pip-egg-info/coverage.egg-info/SOURCES.txt'
>     warning: manifest_maker: standard file '-c' not found
>
>     Traceback (most recent call last):
>       File "<string>", line 1, in <module>
>       File "/tmp/pip-build-ewtgqc2r/coverage/setup.py", line 204, in
> <module>
>         main()
>       File "/tmp/pip-build-ewtgqc2r/coverage/setup.py", line 194, in main
>         setup(**setup_args)
>       File "/home/travis/build/python/cpython/Lib/distutils/core.py",
> line 148, in setup
>         dist.run_commands()
>       File "/home/travis/build/python/cpython/Lib/distutils/dist.py",
> line 955, in run_commands
>         self.run_command(cmd)
>       File "/home/travis/build/python/cpython/Lib/distutils/dist.py",
> line 974, in run_command
>         cmd_obj.run()
>       File
> "/home/travis/build/python/cpython/venv/lib/python3.7/site-packages/setuptools/command/egg_info.py",
> line 279, in run
>         self.find_sources()
>       File
> "/home/travis/build/python/cpython/venv/lib/python3.7/site-packages/setuptools/command/egg_info.py",
> line 306, in find_sources
>         mm.run()
>       File
> "/home/travis/build/python/cpython/venv/lib/python3.7/site-packages/setuptools/command/egg_info.py",
> line 533, in run
>         self.add_defaults()
>       File
> "/home/travis/build/python/cpython/venv/lib/python3.7/site-packages/setuptools/command/egg_info.py",
> line 562, in add_defaults
>         sdist.add_defaults(self)
>       File
> "/home/travis/build/python/cpython/Lib/distutils/command/sdist.py", line
> 228, in add_defaults
>         self._add_defaults_ext()
>       File
> "/home/travis/build/python/cpython/Lib/distutils/command/sdist.py", line
> 311, in _add_defaults_ext
>         build_ext = self.get_finalized_command('build_ext')
>       File "/home/travis/build/python/cpython/Lib/distutils/cmd.py",
> line 299, in get_finalized_command
>         cmd_obj.ensure_finalized()
>       File "/home/travis/build/python/cpython/Lib/distutils/cmd.py",
> line 107, in ensure_finalized
>         self.finalize_options()
>       File
> "/home/travis/build/python/cpython/Lib/distutils/command/build_ext.py",
> line 150, in finalize_options
>         py_include = sysconfig.get_python_inc()
>       File
> "/home/travis/build/python/cpython/Lib/distutils/sysconfig.py", line
> 100, in get_python_inc
>         incdir = os.path.join(_sys_home, get_config_var('AST_H_DIR'))
>       File "/home/travis/build/python/cpython/Lib/posixpath.py", line
> 92, in join
>         genericpath._check_arg_types('join', a, *p)
>       File "/home/travis/build/python/cpython/Lib/genericpath.py", line
> 149, in _check_arg_types
>         (funcname, s.__class__.__name__)) from None
>     TypeError: join() argument must be str or bytes, not 'NoneType'
>
>     ----------------------------------------
> ?Command "python setup.py egg_info" failed with error code 1 in
> /tmp/pip-build-ewtgqc2r/coverage/?
>
>
> Regards
>
> Antoine.
> _______________________________________________
> 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 victor.stinner at gmail.com  Thu May  4 17:31:54 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Thu, 4 May 2017 23:31:54 +0200
Subject: [python-committers] Coverage build broken?
In-Reply-To: <CAMpsgwZjJqpoXF8C980Sz=gYGNAQVbAiqfkq7uEkWYa+yQ5U7w@mail.gmail.com>
References: <37aab3f1-8a99-2ced-17c9-33626019bece@python.org>
 <CAMpsgwZjJqpoXF8C980Sz=gYGNAQVbAiqfkq7uEkWYa+yQ5U7w@mail.gmail.com>
Message-ID: <CAMpsgwbjOQBv-Vuv3E84xVZJjMX=+_3=9W7f_E66mc_yaO8bhQ@mail.gmail.com>

2017-05-04 22:51 GMT+02:00 Victor Stinner <victor.stinner at gmail.com>:
> It seems like a real bug and a regression, I opened an issue to track it:
> http://bugs.python.org/issue30273

Ok, it should be fixed by my commit:
https://github.com/python/cpython/commit/b109a1d3360fc4bb87b9887264e3634632d392ca

Victor

From brett at python.org  Thu May  4 17:56:31 2017
From: brett at python.org (Brett Cannon)
Date: Thu, 04 May 2017 21:56:31 +0000
Subject: [python-committers] Coverage build broken?
In-Reply-To: <CAMpsgwbjOQBv-Vuv3E84xVZJjMX=+_3=9W7f_E66mc_yaO8bhQ@mail.gmail.com>
References: <37aab3f1-8a99-2ced-17c9-33626019bece@python.org>
 <CAMpsgwZjJqpoXF8C980Sz=gYGNAQVbAiqfkq7uEkWYa+yQ5U7w@mail.gmail.com>
 <CAMpsgwbjOQBv-Vuv3E84xVZJjMX=+_3=9W7f_E66mc_yaO8bhQ@mail.gmail.com>
Message-ID: <CAP1=2W7hECpiaUxwhVLZrB=8fFLzzUrwYpekCowDS24gqMCARQ@mail.gmail.com>

Thanks, Victor!

On Thu, 4 May 2017 at 14:32 Victor Stinner <victor.stinner at gmail.com> wrote:

> 2017-05-04 22:51 GMT+02:00 Victor Stinner <victor.stinner at gmail.com>:
> > It seems like a real bug and a regression, I opened an issue to track it:
> > http://bugs.python.org/issue30273
>
> Ok, it should be fixed by my commit:
>
> https://github.com/python/cpython/commit/b109a1d3360fc4bb87b9887264e3634632d392ca
>
> Victor
> _______________________________________________
> 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/20170504/e885a2fc/attachment.html>

From victor.stinner at gmail.com  Thu May  4 18:49:39 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Fri, 5 May 2017 00:49:39 +0200
Subject: [python-committers] Coverage build broken?
In-Reply-To: <CAP1=2W7hECpiaUxwhVLZrB=8fFLzzUrwYpekCowDS24gqMCARQ@mail.gmail.com>
References: <37aab3f1-8a99-2ced-17c9-33626019bece@python.org>
 <CAMpsgwZjJqpoXF8C980Sz=gYGNAQVbAiqfkq7uEkWYa+yQ5U7w@mail.gmail.com>
 <CAMpsgwbjOQBv-Vuv3E84xVZJjMX=+_3=9W7f_E66mc_yaO8bhQ@mail.gmail.com>
 <CAP1=2W7hECpiaUxwhVLZrB=8fFLzzUrwYpekCowDS24gqMCARQ@mail.gmail.com>
Message-ID: <CAMpsgwZ_q82v7GO8e0TQe1UFR5HLdkxKLK7OgApG_-BynoAujA@mail.gmail.com>

2017-05-04 23:56 GMT+02:00 Brett Cannon <brett at python.org>:
> Thanks, Victor!

Well, I was also responsible of the breakage :-) But maybe it wasn't a
good idea in the first place to use AST_H_DIR in
distutils/sysconfig.py to get the "Include" string? ;-)

Or maybe I missed a feature: is it possible to change the Include
directory, or something like that? (the string was hardcoded)

Victor

From steve at pearwood.info  Thu May  4 20:58:30 2017
From: steve at pearwood.info (Steven D'Aprano)
Date: Fri, 5 May 2017 10:58:30 +1000
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <CAP1=2W4MDmhcHeMaCzX-dyP7B4SB8Nk70_5bVxGxLfWEtJfTZA@mail.gmail.com>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
 <CADiSq7euVJ5dwz-g4cKOq5m=2U5DvAVyekcNaLbyhy8zY5+JEA@mail.gmail.com>
 <75286ac5-bf71-d660-f8ee-b060a2595a86@egenix.com>
 <20170502140754.50FE71310014@webabinitio.net>
 <bae9bffd-8329-740c-c903-a27550589ceb@udel.edu>
 <CAP1=2W5uDCGbQHEk0=Qk0L2sHb_OcDj3=643=e_9J=aowgskxA@mail.gmail.com>
 <02d518f4-cd60-a9d4-a18c-c4a05da154d3@udel.edu>
 <CAP1=2W4MDmhcHeMaCzX-dyP7B4SB8Nk70_5bVxGxLfWEtJfTZA@mail.gmail.com>
Message-ID: <20170505005829.GX22525@ando.pearwood.info>

On Thu, May 04, 2017 at 05:44:46PM +0000, Brett Cannon wrote:

> (And just so I can claim I stated this publicly at some point; our Roundup
> installation I think runs on Python 2.6 and Roundup itself has not been
> ported to Python 3, so I don't know what we want to do if Roundup doesn't
> make the switch by 2020.)

Perhaps that's a good use-case for the PSF to (partially?) fund the 
porting effort.

On the other hand... I can imagine some developers thinking "I just 
spent all this time porting my library to Python 3 for free, if I had 
known I would have waited".


-- 
Steve

From rdmurray at bitdance.com  Thu May  4 22:32:11 2017
From: rdmurray at bitdance.com (R. David Murray)
Date: Thu, 04 May 2017 22:32:11 -0400
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <CAP1=2W4MDmhcHeMaCzX-dyP7B4SB8Nk70_5bVxGxLfWEtJfTZA@mail.gmail.com>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
 <CADiSq7euVJ5dwz-g4cKOq5m=2U5DvAVyekcNaLbyhy8zY5+JEA@mail.gmail.com>
 <75286ac5-bf71-d660-f8ee-b060a2595a86@egenix.com>
 <20170502140754.50FE71310014@webabinitio.net>
 <bae9bffd-8329-740c-c903-a27550589ceb@udel.edu>
 <CAP1=2W5uDCGbQHEk0=Qk0L2sHb_OcDj3=643=e_9J=aowgskxA@mail.gmail.com>
 <02d518f4-cd60-a9d4-a18c-c4a05da154d3@udel.edu>
 <CAP1=2W4MDmhcHeMaCzX-dyP7B4SB8Nk70_5bVxGxLfWEtJfTZA@mail.gmail.com>
Message-ID: <20170505023212.467261B10001@webabinitio.net>

On Thu, 04 May 2017 17:44:46 -0000, Brett Cannon <brett at python.org> wrote:
> (And just so I can claim I stated this publicly at some point; our Roundup
> installation I think runs on Python 2.6 and Roundup itself has not been
> ported to Python 3, so I don't know what we want to do if Roundup doesn't
> make the switch by 2020.)

There is intent to port, and some movement, but the number of people
actively working on Roundup is small.  As in single digits small.  Of
one hand.

--David

PS: our roundup runs on 2.6 because that's what the host OS version
provides.  Roundup is planning to drop 2.6 support in the next release,
so we're going to have to deal with *that* *before* 2020 :)

From barry at python.org  Thu May  4 22:53:59 2017
From: barry at python.org (Barry Warsaw)
Date: Thu, 4 May 2017 19:53:59 -0700
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <20170505005829.GX22525@ando.pearwood.info>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
 <CADiSq7euVJ5dwz-g4cKOq5m=2U5DvAVyekcNaLbyhy8zY5+JEA@mail.gmail.com>
 <75286ac5-bf71-d660-f8ee-b060a2595a86@egenix.com>
 <20170502140754.50FE71310014@webabinitio.net>
 <bae9bffd-8329-740c-c903-a27550589ceb@udel.edu>
 <CAP1=2W5uDCGbQHEk0=Qk0L2sHb_OcDj3=643=e_9J=aowgskxA@mail.gmail.com>
 <02d518f4-cd60-a9d4-a18c-c4a05da154d3@udel.edu>
 <CAP1=2W4MDmhcHeMaCzX-dyP7B4SB8Nk70_5bVxGxLfWEtJfTZA@mail.gmail.com>
 <20170505005829.GX22525@ando.pearwood.info>
Message-ID: <20170504195359.5b3da285.barry@wooz.org>

On May 05, 2017, at 10:58 AM, Steven D'Aprano wrote:

>On the other hand... I can imagine some developers thinking "I just 
>spent all this time porting my library to Python 3 for free, if I had 
>known I would have waited".

Except, think of the costs in mental anguish staying on Python 2. :)

-Barry

From ncoghlan at gmail.com  Fri May  5 00:08:54 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 5 May 2017 14:08:54 +1000
Subject: [python-committers] Github reviews are cannibalizing BPO
In-Reply-To: <20170505005829.GX22525@ando.pearwood.info>
References: <2f4e6ac1-4f43-3087-5f34-12b6ee66704c@python.org>
 <CADiSq7euVJ5dwz-g4cKOq5m=2U5DvAVyekcNaLbyhy8zY5+JEA@mail.gmail.com>
 <75286ac5-bf71-d660-f8ee-b060a2595a86@egenix.com>
 <20170502140754.50FE71310014@webabinitio.net>
 <bae9bffd-8329-740c-c903-a27550589ceb@udel.edu>
 <CAP1=2W5uDCGbQHEk0=Qk0L2sHb_OcDj3=643=e_9J=aowgskxA@mail.gmail.com>
 <02d518f4-cd60-a9d4-a18c-c4a05da154d3@udel.edu>
 <CAP1=2W4MDmhcHeMaCzX-dyP7B4SB8Nk70_5bVxGxLfWEtJfTZA@mail.gmail.com>
 <20170505005829.GX22525@ando.pearwood.info>
Message-ID: <CADiSq7dzuPO5dvjKFVO4n7VDPHM7Zx1r-KNGGjKo58NiTu6fjg@mail.gmail.com>

On 5 May 2017 at 10:58, Steven D'Aprano <steve at pearwood.info> wrote:
> On Thu, May 04, 2017 at 05:44:46PM +0000, Brett Cannon wrote:
>
>> (And just so I can claim I stated this publicly at some point; our Roundup
>> installation I think runs on Python 2.6 and Roundup itself has not been
>> ported to Python 3, so I don't know what we want to do if Roundup doesn't
>> make the switch by 2020.)
>
> Perhaps that's a good use-case for the PSF to (partially?) fund the
> porting effort.
>
> On the other hand... I can imagine some developers thinking "I just
> spent all this time porting my library to Python 3 for free, if I had
> known I would have waited".

Funded Python 3 ports aren't a new idea, as the PSF has been offering
& facilitating Python 3 porting grants since 2011:
http://pyfound.blogspot.com.au/2011/12/psf-proffers-payment-to-port-to-python.html

I know at least one former upstream Roundup developer recently moved
into freelance software development & consulting, so I'll chat to him
to see if he has any suggestions for possible ways forward here.

Cheers,
Nick.

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

From mariatta.wijaya at gmail.com  Fri May  5 14:44:22 2017
From: mariatta.wijaya at gmail.com (Mariatta Wijaya)
Date: Fri, 5 May 2017 11:44:22 -0700
Subject: [python-committers] Proposal for procedures regarding CoC
 actions
In-Reply-To: <CADiSq7d7bOaDLi5Z7fxh242VN8+cAoDrS5zOetfT0vjqGNWBrQ@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>
 <CADiSq7dV3ZSsYbrm=skOOd5K4CY5op-s-KdZUZjH-HGq=SM_eQ@mail.gmail.com>
 <CAGbohnYp7YQ9iD1q8m8Sqn7zOYqdDmb6YMgfzSgvrOgmP4ox0Q@mail.gmail.com>
 <c4c16b2a-5897-017d-034e-c6fea5b9920b@egenix.com>
 <CAP7+vJ+gCpXk7tfjc4zoj7m4HGUuo==1tmyPvc2gNUTd+ApKYQ@mail.gmail.com>
 <CADiSq7d7bOaDLi5Z7fxh242VN8+cAoDrS5zOetfT0vjqGNWBrQ@mail.gmail.com>
Message-ID: <CAGbohnb+50r11rMf9ZJPVn4yFm-PCQOJB4zYyeUW80zakvLDLw@mail.gmail.com>

Thanks everyone for the input.


It is still unclear to me how one can report when someone is being rude on
GitHub.
In the mailing lists we can email the administrators. But what about on
GitHub?
Do I write to python-committers?
What if it was a core developer who was being rude, where can a non
core-dev contributor report such behavior?



Mariatta Wijaya

On Thu, May 4, 2017 at 6:53 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 4 May 2017 at 06:10, Guido van Rossum <guido at python.org> wrote:
> > Two ex-board members disagree. I have to side with Brian; the PSF board
> > should have minimal say in how the developers develop.
> >
> > Note, I'm fine with the board being the arbiter when someone disagrees
> with
> > their ban though -- there's got to be a "higher authority" for appeals.
> But
> > I don't agree that the board should be the decider on the initial ban.
>
> I think initial temporary suspensions should definitely be handled
> without involving the Board (just as they are for any other PSF
> provided channel).
>
> I also think there are two cases that can definitely only be handled
> at the board level:
>
> - folks that feel they've been treated unfairly by the core
> development team appealing to the Board for reconsideration
> - the core development team recommending that a ban from our channels
> (python-dev, python-ideas, core-workflow, bugs.python.org, GitHub
> python org) be extended to other PSF provided channels
>
> I'd previously said that I thought conversion of temporary suspensions
> to permanent bans should also go to the Board, but I now think it
> makes more sense to handle that as:
>
> - the Board gets notified if a temporary suspension is now considered
> a permanent ban
> - they only need to get further involved if the ban is appealed
>
> Cheers,
> Nick.
>
> P.S. Don't forget that the specific context here is *public* behaviour
> that is the domain of channel moderators, rather than confidentially
> reported Code of Conduct concerns. Handling of the latter will remain
> with the PSF Board or their appointed representatives, independently
> of how we handle moderation of the development channels.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170505/6fd58d9a/attachment.html>

From guido at python.org  Fri May  5 14:51:15 2017
From: guido at python.org (Guido van Rossum)
Date: Fri, 5 May 2017 11:51:15 -0700
Subject: [python-committers] Proposal for procedures regarding CoC
 actions
In-Reply-To: <CAGbohnb+50r11rMf9ZJPVn4yFm-PCQOJB4zYyeUW80zakvLDLw@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>
 <CADiSq7dV3ZSsYbrm=skOOd5K4CY5op-s-KdZUZjH-HGq=SM_eQ@mail.gmail.com>
 <CAGbohnYp7YQ9iD1q8m8Sqn7zOYqdDmb6YMgfzSgvrOgmP4ox0Q@mail.gmail.com>
 <c4c16b2a-5897-017d-034e-c6fea5b9920b@egenix.com>
 <CAP7+vJ+gCpXk7tfjc4zoj7m4HGUuo==1tmyPvc2gNUTd+ApKYQ@mail.gmail.com>
 <CADiSq7d7bOaDLi5Z7fxh242VN8+cAoDrS5zOetfT0vjqGNWBrQ@mail.gmail.com>
 <CAGbohnb+50r11rMf9ZJPVn4yFm-PCQOJB4zYyeUW80zakvLDLw@mail.gmail.com>
Message-ID: <CAP7+vJLvK+b_CuK1PTL_J7zV6rwNA-W0KwNsH_zkNhxwKR2Lpg@mail.gmail.com>

Maybe there should be a published list of moderators (not a mailing list,
just a list of people to mail!) where you can send such reports. If a
moderator is being rude it's probably time to escalate to the PSF.

Thanks for pushing for a definite process on this issue!

On Fri, May 5, 2017 at 11:44 AM, Mariatta Wijaya <mariatta.wijaya at gmail.com>
wrote:

> Thanks everyone for the input.
>
>
> It is still unclear to me how one can report when someone is being rude on
> GitHub.
> In the mailing lists we can email the administrators. But what about on
> GitHub?
> Do I write to python-committers?
> What if it was a core developer who was being rude, where can a non
> core-dev contributor report such behavior?
>
>
>
> Mariatta Wijaya
>
> On Thu, May 4, 2017 at 6:53 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
>> On 4 May 2017 at 06:10, Guido van Rossum <guido at python.org> wrote:
>> > Two ex-board members disagree. I have to side with Brian; the PSF board
>> > should have minimal say in how the developers develop.
>> >
>> > Note, I'm fine with the board being the arbiter when someone disagrees
>> with
>> > their ban though -- there's got to be a "higher authority" for appeals.
>> But
>> > I don't agree that the board should be the decider on the initial ban.
>>
>> I think initial temporary suspensions should definitely be handled
>> without involving the Board (just as they are for any other PSF
>> provided channel).
>>
>> I also think there are two cases that can definitely only be handled
>> at the board level:
>>
>> - folks that feel they've been treated unfairly by the core
>> development team appealing to the Board for reconsideration
>> - the core development team recommending that a ban from our channels
>> (python-dev, python-ideas, core-workflow, bugs.python.org, GitHub
>> python org) be extended to other PSF provided channels
>>
>> I'd previously said that I thought conversion of temporary suspensions
>> to permanent bans should also go to the Board, but I now think it
>> makes more sense to handle that as:
>>
>> - the Board gets notified if a temporary suspension is now considered
>> a permanent ban
>> - they only need to get further involved if the ban is appealed
>>
>> Cheers,
>> Nick.
>>
>> P.S. Don't forget that the specific context here is *public* behaviour
>> that is the domain of channel moderators, rather than confidentially
>> reported Code of Conduct concerns. Handling of the latter will remain
>> with the PSF Board or their appointed representatives, independently
>> of how we handle moderation of the development channels.
>>
>> --
>> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>>
>
>


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

From brett at python.org  Tue May  9 19:17:22 2017
From: brett at python.org (Brett Cannon)
Date: Tue, 09 May 2017 23:17:22 +0000
Subject: [python-committers] Created a Bedevere bot account on GitHub
Message-ID: <CAP1=2W55XOiU1p8Y7chwWTf7kY4jqj8AOa0Cwtews5-tJ6JJjA@mail.gmail.com>

Just so no one thinks anything fishy is going on, I wanted to let the team
know that I created https://github.com/bedevere-bot and now have Bedevere
using this account instead of piggybacking off of
https://github.com/the-knights-who-say-ni. I figured they should be
separate for security reasons as the Ni bot accesses many more accounts
than Bedevere. Plus I wanted an appropriate profile photo for Bedevere. :)

P.S. In case anyone cares, core-workflow-owner@ is set up as the email
address for both accounts, so the accounts can be recovered by others if
need be.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170509/4eeb061b/attachment.html>

From brett at python.org  Sat May 13 15:59:17 2017
From: brett at python.org (Brett Cannon)
Date: Sat, 13 May 2017 19:59:17 +0000
Subject: [python-committers] The "cherry-pick to *" labels on GitHub are gone
Message-ID: <CAP1=2W5WWOGV_Pdi0aO3qPsGtMBGYVv9t4TuAn7zEfz_JTcp1w@mail.gmail.com>

People didn't always remember to add the labels and they were redundant
with people specifying the branch in the title along with the PR that the
cherry-pick originated from (e.g. "[3.6] Something changed (GH-12345)").
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170513/3233734d/attachment.html>

From brett at python.org  Sat May 13 17:15:07 2017
From: brett at python.org (Brett Cannon)
Date: Sat, 13 May 2017 21:15:07 +0000
Subject: [python-committers] The "cherry-pick to *" labels on GitHub are
 gone
In-Reply-To: <CAP1=2W5WWOGV_Pdi0aO3qPsGtMBGYVv9t4TuAn7zEfz_JTcp1w@mail.gmail.com>
References: <CAP1=2W5WWOGV_Pdi0aO3qPsGtMBGYVv9t4TuAn7zEfz_JTcp1w@mail.gmail.com>
Message-ID: <CAP1=2W43nouYF+gr0HGBs50uYmJsT54GadjL=ugeojsZ0W0yXQ@mail.gmail.com>

On Sat, 13 May 2017 at 12:59 Brett Cannon <brett at python.org> wrote:

> People didn't always remember to add the labels and they were redundant
> with people specifying the branch in the title along with the PR that the
> cherry-pick originated from (e.g. "[3.6] Something changed (GH-12345)").
>

I should mention that you can still differentiate between a PR that is
specifically targeted at a older branch and a cherry-pick PR. E.g. "[2.7]
Did something" is a PR specifically for Python 2.7 while "[2.7] Did
something (GH-12345)" is a backport based on the fact that "(GH-12345)" is
at the end of the title.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170513/c6008bbe/attachment.html>

From brett at python.org  Tue May 16 13:31:07 2017
From: brett at python.org (Brett Cannon)
Date: Tue, 16 May 2017 17:31:07 +0000
Subject: [python-committers] Sphinx 1.6.1 is causing Travis to fail
Message-ID: <CAP1=2W7D7tTvUNb-abkt3O6t9x5knpSCu9JCMO054fRAXaY_sQ@mail.gmail.com>

Looks like they added some new warnings that are causing the docs build to
fail (e.g. https://travis-ci.org/python/cpython/jobs/232903226 and
https://travis-ci.org/python/cpython/jobs/232897796).

I will see if I have time to fix this before I leave for PyCon US today,
but there's no guarantee. If someone has time to fix this then I've opened
https://bugs.python.org/issue30380 to track the problem and give my take on
a solution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170516/e5852610/attachment.html>

From mariatta.wijaya at gmail.com  Tue May 16 14:09:41 2017
From: mariatta.wijaya at gmail.com (Mariatta Wijaya)
Date: Tue, 16 May 2017 11:09:41 -0700
Subject: [python-committers] Sphinx 1.6.1 is causing Travis to fail
In-Reply-To: <CAP1=2W7D7tTvUNb-abkt3O6t9x5knpSCu9JCMO054fRAXaY_sQ@mail.gmail.com>
References: <CAP1=2W7D7tTvUNb-abkt3O6t9x5knpSCu9JCMO054fRAXaY_sQ@mail.gmail.com>
Message-ID: <CAGbohnbpH+7V+=wxTaUoEuZLpOPMQWB5DqWdqJw8buzO3dm49g@mail.gmail.com>

It passes now : https://github.com/python/cpython/pull/1612

Ok to merge?

Mariatta Wijaya

On Tue, May 16, 2017 at 10:31 AM, Brett Cannon <brett at python.org> wrote:

> Looks like they added some new warnings that are causing the docs build to
> fail (e.g. https://travis-ci.org/python/cpython/jobs/232903226 and
> https://travis-ci.org/python/cpython/jobs/232897796).
>
> I will see if I have time to fix this before I leave for PyCon US today,
> but there's no guarantee. If someone has time to fix this then I've opened
> https://bugs.python.org/issue30380 to track the problem and give my take
> on a solution.
>
> _______________________________________________
> 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/20170516/d755f8bd/attachment.html>

From brett at python.org  Tue May 16 15:09:29 2017
From: brett at python.org (Brett Cannon)
Date: Tue, 16 May 2017 19:09:29 +0000
Subject: [python-committers] Sphinx 1.6.1 is causing Travis to fail
In-Reply-To: <CAGbohnbpH+7V+=wxTaUoEuZLpOPMQWB5DqWdqJw8buzO3dm49g@mail.gmail.com>
References: <CAP1=2W7D7tTvUNb-abkt3O6t9x5knpSCu9JCMO054fRAXaY_sQ@mail.gmail.com>
 <CAGbohnbpH+7V+=wxTaUoEuZLpOPMQWB5DqWdqJw8buzO3dm49g@mail.gmail.com>
Message-ID: <CAP1=2W6Spag9=WJ4-QSSYEs39h_ffGmVLyJreT9fd_shhRFN0A@mail.gmail.com>

I replied on the PR.

On Tue, 16 May 2017 at 11:09 Mariatta Wijaya <mariatta.wijaya at gmail.com>
wrote:

> It passes now : https://github.com/python/cpython/pull/1612
>
> Ok to merge?
>
> Mariatta Wijaya
>
> On Tue, May 16, 2017 at 10:31 AM, Brett Cannon <brett at python.org> wrote:
>
>> Looks like they added some new warnings that are causing the docs build
>> to fail (e.g. https://travis-ci.org/python/cpython/jobs/232903226 and
>> https://travis-ci.org/python/cpython/jobs/232897796).
>>
>> I will see if I have time to fix this before I leave for PyCon US today,
>> but there's no guarantee. If someone has time to fix this then I've opened
>> https://bugs.python.org/issue30380 to track the problem and give my take
>> on a solution.
>>
>> _______________________________________________
>> 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/20170516/ba12b4dd/attachment.html>

From brett at python.org  Tue May 16 17:49:24 2017
From: brett at python.org (Brett Cannon)
Date: Tue, 16 May 2017 21:49:24 +0000
Subject: [python-committers] Sphinx 1.6.1 is causing Travis to fail
In-Reply-To: <CAP1=2W7D7tTvUNb-abkt3O6t9x5knpSCu9JCMO054fRAXaY_sQ@mail.gmail.com>
References: <CAP1=2W7D7tTvUNb-abkt3O6t9x5knpSCu9JCMO054fRAXaY_sQ@mail.gmail.com>
Message-ID: <CAP1=2W5CJEwRd1m=+8EfT4NHBDwtt+N0yRa8htQyX-OA39pEAg@mail.gmail.com>

I just wanted to let everyone know that all branches are green again. We
now pin to a specific major.minor version of Sphinx in our .travis.yml file
to help prevent this from happening again in the future. (All branches but
2.7 are pinned to 1.6.1 while 2.7 stays on 1.5.6 until Serhiy has a chance
to update his PR to fix it.)

Thanks to Mariatta, Kushal, Zachary, Senthil, and Serhiy for all chipping
in to help fix this in a timely manner and contain the number of broken PRs
because of it.

On Tue, 16 May 2017 at 10:31 Brett Cannon <brett at python.org> wrote:

> Looks like they added some new warnings that are causing the docs build to
> fail (e.g. https://travis-ci.org/python/cpython/jobs/232903226 and
> https://travis-ci.org/python/cpython/jobs/232897796).
>
> I will see if I have time to fix this before I leave for PyCon US today,
> but there's no guarantee. If someone has time to fix this then I've opened
> https://bugs.python.org/issue30380 to track the problem and give my take
> on a solution.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170516/40161434/attachment.html>

From victor.stinner at gmail.com  Wed May 17 14:26:36 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Wed, 17 May 2017 11:26:36 -0700
Subject: [python-committers] Feedback on the new CPython workflow
Message-ID: <CAMpsgwY6=kiTWTP_JV12sNRPpGLr68vDYTB3E-cnuo2_qWYDhQ@mail.gmail.com>

Hi,

I wanted to wait a little bit before giving back my feedback on the
new workflow. I just attend Brett Canon's talk at the Language Summit.
So here are my misc notes on the new workflow.

* Is there anyone already working on the workflow who would like to
get a grant (money!) from the PSF?

* If I want to share a change to review but it must not be merged,
would it be possible to prevent merge by mistake? Maybe add [WIP] to
the title and modify our bot to mark the "build" as failed? For
example, I wrote a patch which depends on a different patch but I
didn't want to create a patch serie since it didn't make sense.

* AppVeyor is now quite stable. I fixed a few unstable tests. I
suggest to mark this CI as mandatory. The CI is as fast or even faster
than Travis CI! But it seems like it accepts less jobs in parallel :-/
It might be an issue if we get a huge number of PR in a short period
(ex: during an event like Pycon US).

* Currently, cherry-picker works a single step. It would be nice to
have at least 2 steps: first cherry-pick locally, then allow to review
the patch locally and run some specific tests, and then send the PR.
By the way, instead of only using the sha1 to build the branch name,
it would be nice to add also the bpo number.

* I suggest to track backports at bpo since an issue tracks all PR and
it seems like most core developers want to put most informations in
the issue rather than GitHub.

* Find a way to keep the Code coverage job, but don't mark the PR as
failed if the coverage is considered as "failed"? It's strange to see
a long list of PR with the red sign (failed) whereas Travis and
AppVeyor passed.

I have a lot of other minor remarks, but I prefer to stop here ;-)

Victor

From mariatta.wijaya at gmail.com  Wed May 17 14:35:29 2017
From: mariatta.wijaya at gmail.com (Mariatta Wijaya)
Date: Wed, 17 May 2017 11:35:29 -0700
Subject: [python-committers] Feedback on the new CPython workflow
In-Reply-To: <CAMpsgwY6=kiTWTP_JV12sNRPpGLr68vDYTB3E-cnuo2_qWYDhQ@mail.gmail.com>
References: <CAMpsgwY6=kiTWTP_JV12sNRPpGLr68vDYTB3E-cnuo2_qWYDhQ@mail.gmail.com>
Message-ID: <CAGbohna8F0zZQxY-ot_5BYv9=wpwLQK+2LZGrLq3PUj0WnZrFg@mail.gmail.com>

>
> * Currently, cherry-picker works a single step. It would be nice to
> have at least 2 steps: first cherry-pick locally, then allow to review
> the patch locally and run some specific tests, and then send the PR.


The --no-push parameter allows you to test changes locally first. Then you
can use --continue to finish the backport and open the PR:

Discussion: https://github.com/python/core-workflow/issues/78
Implementation: https://github.com/python/core-workflow/pull/84


By the way, instead of only using the sha1 to build the branch name,
> it would be nice to add also the bpo number.


It's possible, but remember not all PRs have bpo-issue, eg those with
trivial label.
In that case, what should the backport branch be?
So we might end up with two backport branch name patterns, eg
`backport-bpo-NNNN-` and `backport-sha1` for the trivial PRs ?

Thanks :)

Mariatta Wijaya

On Wed, May 17, 2017 at 11:26 AM, Victor Stinner <victor.stinner at gmail.com>
wrote:

> Hi,
>
> I wanted to wait a little bit before giving back my feedback on the
> new workflow. I just attend Brett Canon's talk at the Language Summit.
> So here are my misc notes on the new workflow.
>
> * Is there anyone already working on the workflow who would like to
> get a grant (money!) from the PSF?
>
> * If I want to share a change to review but it must not be merged,
> would it be possible to prevent merge by mistake? Maybe add [WIP] to
> the title and modify our bot to mark the "build" as failed? For
> example, I wrote a patch which depends on a different patch but I
> didn't want to create a patch serie since it didn't make sense.
>
> * AppVeyor is now quite stable. I fixed a few unstable tests. I
> suggest to mark this CI as mandatory. The CI is as fast or even faster
> than Travis CI! But it seems like it accepts less jobs in parallel :-/
> It might be an issue if we get a huge number of PR in a short period
> (ex: during an event like Pycon US).
>
> * Currently, cherry-picker works a single step. It would be nice to
> have at least 2 steps: first cherry-pick locally, then allow to review
> the patch locally and run some specific tests, and then send the PR.
> By the way, instead of only using the sha1 to build the branch name,
> it would be nice to add also the bpo number.
>
> * I suggest to track backports at bpo since an issue tracks all PR and
> it seems like most core developers want to put most informations in
> the issue rather than GitHub.
>
> * Find a way to keep the Code coverage job, but don't mark the PR as
> failed if the coverage is considered as "failed"? It's strange to see
> a long list of PR with the red sign (failed) whereas Travis and
> AppVeyor passed.
>
> I have a lot of other minor remarks, but I prefer to stop here ;-)
>
> Victor
> _______________________________________________
> 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/20170517/6cdd7008/attachment.html>

From rdmurray at bitdance.com  Wed May 17 18:59:55 2017
From: rdmurray at bitdance.com (R. David Murray)
Date: Wed, 17 May 2017 18:59:55 -0400
Subject: [python-committers] Feedback on the new CPython workflow
In-Reply-To: <CAGbohna8F0zZQxY-ot_5BYv9=wpwLQK+2LZGrLq3PUj0WnZrFg@mail.gmail.com>
References: <CAMpsgwY6=kiTWTP_JV12sNRPpGLr68vDYTB3E-cnuo2_qWYDhQ@mail.gmail.com>
 <CAGbohna8F0zZQxY-ot_5BYv9=wpwLQK+2LZGrLq3PUj0WnZrFg@mail.gmail.com>
Message-ID: <20170517225956.54797131001B@webabinitio.net>

On Wed, 17 May 2017 11:35:29 -0700, Mariatta Wijaya <mariatta.wijaya at gmail.com> wrote:
> It's possible, but remember not all PRs have bpo-issue, eg those with
> trivial label.
> In that case, what should the backport branch be?
> So we might end up with two backport branch name patterns, eg
> `backport-bpo-NNNN-` and `backport-sha1` for the trivial PRs ?

I don't think it is a problem for the bpo issue number to be missing if
there isn't one.  (I presume you meant 'backport-bpo-NNNN-sha1` for the
BPO alternative.)  But how abut using the github PR number in that case?

--David

From mariatta.wijaya at gmail.com  Thu May 18 12:01:22 2017
From: mariatta.wijaya at gmail.com (Mariatta Wijaya)
Date: Thu, 18 May 2017 09:01:22 -0700
Subject: [python-committers] Feedback on the new CPython workflow
In-Reply-To: <20170517225956.54797131001B@webabinitio.net>
References: <CAMpsgwY6=kiTWTP_JV12sNRPpGLr68vDYTB3E-cnuo2_qWYDhQ@mail.gmail.com>
 <CAGbohna8F0zZQxY-ot_5BYv9=wpwLQK+2LZGrLq3PUj0WnZrFg@mail.gmail.com>
 <20170517225956.54797131001B@webabinitio.net>
Message-ID: <CAGbohnYnJp9hSscKNUzN4JoeV8LYuQUeZQKYY3aydwbw10hjCQ@mail.gmail.com>

>
> I don't think it is a problem for the bpo issue number to be missing if
>
there isn't one.  (I presume you meant 'backport-bpo-NNNN-sha1` for the
> BPO alternative.)  But how abut using the github PR number in that case?


Sure, provided the commit hash, we can get the bpo number and GH pr number
by doing:

 git log -n 1 --pretty=format:%B <commit_hash>

The question is: since backport branch is temporary and gets deleted once
PR is created, is this even important? If so, please open an issue in
core-workflow :)

I'm actually not even sure if I should bother with improving
cherry_picker.py now knowing a bot is coming soon.

> * If I want to share a change to review but it must not be merged,
> would it be possible to prevent merge by mistake? Maybe add [WIP] to
> the title and modify our bot to mark the "build" as failed? For
> example, I wrote a patch which depends on a different patch but I
> didn't want to create a patch serie since it didn't make sense.


One thing we can do is to apply "don't merge" label, and it can be a status
check for bedevere. This is just my suggestion :)  bedevere isn't doing
this yet. There was talk yesterday about having a bot that can apply
labels. Maybe this can be part of that.


* I suggest to track backports at bpo since an issue tracks all PR and
> it seems like most core developers want to put most informations in
> the issue rather than GitHub.


Hmm, what do you mean by tracking backports at bpo? We already have the
`needs backport` status in bpo.



Mariatta Wijaya

On Wed, May 17, 2017 at 3:59 PM, R. David Murray <rdmurray at bitdance.com>
wrote:

> On Wed, 17 May 2017 11:35:29 -0700, Mariatta Wijaya <
> mariatta.wijaya at gmail.com> wrote:
> > It's possible, but remember not all PRs have bpo-issue, eg those with
> > trivial label.
> > In that case, what should the backport branch be?
> > So we might end up with two backport branch name patterns, eg
> > `backport-bpo-NNNN-` and `backport-sha1` for the trivial PRs ?
>
> I don't think it is a problem for the bpo issue number to be missing if
> there isn't one.  (I presume you meant 'backport-bpo-NNNN-sha1` for the
> BPO alternative.)  But how abut using the github PR number in that case?
>
> --David
> _______________________________________________
> 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/20170518/767dd9cb/attachment.html>

From victor.stinner at gmail.com  Thu May 18 13:00:27 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Thu, 18 May 2017 10:00:27 -0700
Subject: [python-committers] Feedback on the new CPython workflow
In-Reply-To: <CAGbohnYnJp9hSscKNUzN4JoeV8LYuQUeZQKYY3aydwbw10hjCQ@mail.gmail.com>
References: <CAMpsgwY6=kiTWTP_JV12sNRPpGLr68vDYTB3E-cnuo2_qWYDhQ@mail.gmail.com>
 <CAGbohna8F0zZQxY-ot_5BYv9=wpwLQK+2LZGrLq3PUj0WnZrFg@mail.gmail.com>
 <20170517225956.54797131001B@webabinitio.net>
 <CAGbohnYnJp9hSscKNUzN4JoeV8LYuQUeZQKYY3aydwbw10hjCQ@mail.gmail.com>
Message-ID: <CAMpsgwb=LG5jLXDCYsdp4JQydF=yg66inZ2XM4VvOkAenRzmJQ@mail.gmail.com>

2017-05-18 9:01 GMT-07:00 Mariatta Wijaya <mariatta.wijaya at gmail.com>:
> The question is: since backport branch is temporary and gets deleted once PR
> is created, is this even important?

I stopped using cherry-picker.py to use a simple shell script for the
last step, create a PR from a local branch, because I had too many
branches with "random" names. I also like keeping local branches until
they are merged.

My shell script ~/bin/gh_pr.sh:
---
set -e -x
if [[ "$1" = "-f" ]]; then
    force=-f
else
    force=
fi
local_branch=$(git name-rev --name-only HEAD)
ref_branch=$(basename $(pwd))
echo "branches: $local_branch -> $ref_branch"
project=cpython
git push haypo HEAD $force
URL="https://github.com/python/$project/compare/$ref_branch...haypo:$local_branch?expand=1"
python3 -m webbrowser $URL
---

> If so, please open an issue in core-workflow :)

I will retry cherry-picker.py and try implement my request :-)

Victor

From brett at python.org  Thu May 18 17:53:18 2017
From: brett at python.org (Brett Cannon)
Date: Thu, 18 May 2017 21:53:18 +0000
Subject: [python-committers] Feedback on the new CPython workflow
In-Reply-To: <CAMpsgwY6=kiTWTP_JV12sNRPpGLr68vDYTB3E-cnuo2_qWYDhQ@mail.gmail.com>
References: <CAMpsgwY6=kiTWTP_JV12sNRPpGLr68vDYTB3E-cnuo2_qWYDhQ@mail.gmail.com>
Message-ID: <CAP1=2W5tjLGt0JjZbfg0ihd4PavA_YJY69Jvtts9LemE6k2Tqg@mail.gmail.com>

On Wed, 17 May 2017 at 11:27 Victor Stinner <victor.stinner at gmail.com>
wrote:

> Hi,
>
> I wanted to wait a little bit before giving back my feedback on the
> new workflow. I just attend Brett Canon's talk at the Language Summit.
> So here are my misc notes on the new workflow.
>
> * Is there anyone already working on the workflow who would like to
> get a grant (money!) from the PSF?
>
> * If I want to share a change to review but it must not be merged,
> would it be possible to prevent merge by mistake? Maybe add [WIP] to
> the title and modify our bot to mark the "build" as failed? For
> example, I wrote a patch which depends on a different patch but I
> didn't want to create a patch serie since it didn't make sense.
>

So in this instance couldn't you just not submit the PR until the dependent
PR has been accepted? IOW could you just  keep the change in your fork
until it's ready for review?


>
> * AppVeyor is now quite stable. I fixed a few unstable tests. I
> suggest to mark this CI as mandatory. The CI is as fast or even faster
> than Travis CI! But it seems like it accepts less jobs in parallel :-/
> It might be an issue if we get a huge number of PR in a short period
> (ex: during an event like Pycon US).
>

https://github.com/python/core-workflow/issues/41 (I also have
https://github.com/python/core-workflow/issues/91 for turning on macOS
support in Travis to test it out, but this wouldn't be required to pass).


>
> * Currently, cherry-picker works a single step. It would be nice to
> have at least 2 steps: first cherry-pick locally, then allow to review
> the patch locally and run some specific tests, and then send the PR.
> By the way, instead of only using the sha1 to build the branch name,
> it would be nice to add also the bpo number.
>
> * I suggest to track backports at bpo since an issue tracks all PR and
> it seems like most core developers want to put most informations in
> the issue rather than GitHub.
>

The problem with that is the backport is about cherry-picking the submitted
change, not the issue under discussion so there's a disconnect there. Plus
we don't typically remove what versions of Python are affected by an issue
as we fix things so this would change how we track to what branch we
backport to.


>
> * Find a way to keep the Code coverage job, but don't mark the PR as
> failed if the coverage is considered as "failed"? It's strange to see
> a long list of PR with the red sign (failed) whereas Travis and
> AppVeyor passed.
>

That is already done for new PRs and should be true for all branches (and
if it isn't then https://github.com/python/core-workflow/issues/81 will
make that true for all branches).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170518/90d29244/attachment-0001.html>

From brett at python.org  Tue May 23 14:15:04 2017
From: brett at python.org (Brett Cannon)
Date: Tue, 23 May 2017 18:15:04 +0000
Subject: [python-committers] Proposing Carol Willing to become a core
 developer
Message-ID: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>

While at the PyCon US sprints the idea came up of offering Carol Willing
developer privileges. Everyone at the table -- about 6 of us -- liked the
idea and Carol also said she would happy to become a core dev, so I'm
officially putting her forward for consideration.

For those of you who don't know Carol, she basically knows our developer
workflow better than most of us. :) ; she's very active on the devguide and
core-mentorship. Carol has also attended the PyCon US language summit two
years in a row as a representative for the Jupyter project. She is actually
so good with new people that she managed to get my wife to make her first
open source contribution (something I never managed to do).

As usual, if you support/object to this idea, please say so. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170523/7d1c4fd6/attachment.html>

From alex.gaynor at gmail.com  Tue May 23 14:24:36 2017
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Tue, 23 May 2017 14:24:36 -0400
Subject: [python-committers] Proposing Carol Willing to become a core
 developer
In-Reply-To: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
References: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
Message-ID: <CAFRnB2XnHBdAhfkS-Jj0Qi=cab-UhqWy-VaTNX+RKKtmLUZUJQ@mail.gmail.com>

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

Alex

On Tue, May 23, 2017 at 2:15 PM, Brett Cannon <brett at python.org> wrote:

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

From mariatta.wijaya at gmail.com  Tue May 23 14:24:48 2017
From: mariatta.wijaya at gmail.com (Mariatta Wijaya)
Date: Tue, 23 May 2017 11:24:48 -0700
Subject: [python-committers] Proposing Carol Willing to become a core
 developer
In-Reply-To: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
References: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
Message-ID: <CAGbohnYfbTskLspB0XedYX2+bbRgPY5iOD_yNctzUXqVMbsOkg@mail.gmail.com>

+1_000_000

On May 23, 2017 11:23 AM, "Brett Cannon" <brett at python.org> wrote:

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

From jaraco at jaraco.com  Tue May 23 14:25:16 2017
From: jaraco at jaraco.com (Jason R. Coombs)
Date: Tue, 23 May 2017 18:25:16 +0000
Subject: [python-committers] Proposing Carol Willing to become a core
 developer
In-Reply-To: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
References: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
Message-ID: <B6BB8F70-64A4-434E-9350-C2953DE6ACE5@jaraco.com>

I was impressed with Carol?s leadership at HackIllinois

+1


> On 23 May, 2017, at 14:15, Brett Cannon <brett at python.org> wrote:
> 
> As usual, if you support/object to this idea, please say so. :)
> _______________________________________________
> 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 kushaldas at gmail.com  Tue May 23 14:27:36 2017
From: kushaldas at gmail.com (Kushal Das)
Date: Tue, 23 May 2017 11:27:36 -0700
Subject: [python-committers] Proposing Carol Willing to become a core
 developer
In-Reply-To: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
References: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
Message-ID: <CAAzeMbw5OiHBGCYzQ8QA+Zi1W7ewD4VvK+fxmNvL6JPiuwyDgQ@mail.gmail.com>

On Tue, May 23, 2017 at 11:15 AM, Brett Cannon <brett at python.org> wrote:
> While at the PyCon US sprints the idea came up of offering Carol Willing
> developer privileges. Everyone at the table -- about 6 of us -- liked the
> idea and Carol also said she would happy to become a core dev, so I'm
> officially putting her forward for consideration.
>
+1 to Carol.


Kushal
-- 
Fedora Cloud Engineer
CPython Core Developer
http://kushaldas.in

From zachary.ware+pydev at gmail.com  Tue May 23 14:31:44 2017
From: zachary.ware+pydev at gmail.com (Zachary Ware)
Date: Tue, 23 May 2017 11:31:44 -0700
Subject: [python-committers] Proposing Carol Willing to become a core
 developer
In-Reply-To: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
References: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
Message-ID: <CAKJDb-Mh9iUgS9bgxDr0e_f2xnT=0HFitw+ndALQ+URyfCp8fQ@mail.gmail.com>

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

+1

-- 
Zach

From ericsnowcurrently at gmail.com  Tue May 23 14:36:22 2017
From: ericsnowcurrently at gmail.com (Eric Snow)
Date: Tue, 23 May 2017 11:36:22 -0700
Subject: [python-committers] Proposing Carol Willing to become a core
 developer
In-Reply-To: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
References: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
Message-ID: <CALFfu7DuS6mm1+0mvqEseT3QtyJORUXKhaXAaqyS8htoZNb_yw@mail.gmail.com>

+1

On Tue, May 23, 2017 at 11:15 AM, Brett Cannon <brett at python.org> wrote:
> While at the PyCon US sprints the idea came up of offering Carol Willing
> developer privileges. Everyone at the table -- about 6 of us -- liked the
> idea and Carol also said she would happy to become a core dev, so I'm
> officially putting her forward for consideration.
>
> For those of you who don't know Carol, she basically knows our developer
> workflow better than most of us. :) ; she's very active on the devguide and
> core-mentorship. Carol has also attended the PyCon US language summit two
> years in a row as a representative for the Jupyter project. She is actually
> so good with new people that she managed to get my wife to make her first
> open source contribution (something I never managed to do).
>
> As usual, if you support/object to this idea, please say so. :)
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>

From steve.dower at python.org  Tue May 23 15:10:03 2017
From: steve.dower at python.org (Steve Dower)
Date: Tue, 23 May 2017 12:10:03 -0700
Subject: [python-committers] Proposing Carol Willing to become a core
 developer
In-Reply-To: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
References: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
Message-ID: <ba201117-72a8-330c-985f-7ac77170bbb0@python.org>

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

+1. Would love to have Carol in a position where she can mentor 
contributors all the way through to completion, and I trust that she'll 
use her powers for good :)

Cheers,
Steve

From barry at python.org  Tue May 23 15:24:18 2017
From: barry at python.org (Barry Warsaw)
Date: Tue, 23 May 2017 12:24:18 -0700
Subject: [python-committers] Proposing Carol Willing to become a core
 developer
In-Reply-To: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
References: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
Message-ID: <20170523122418.08b08f1b@presto>

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

>As usual, if you support/object to this idea, please say so. :)

Support!
-Barry

From victor.stinner at gmail.com  Tue May 23 15:51:11 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Tue, 23 May 2017 14:51:11 -0500
Subject: [python-committers] Proposing Carol Willing to become a core
 developer
In-Reply-To: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
References: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
Message-ID: <CAMpsgwbTBQa72bSm5s04zhKEt1DbSrnMBM3hdo3Wc4UjhEpNag@mail.gmail.com>

tl;dr +1 for me as well

2017-05-23 13:15 GMT-05:00 Brett Cannon <brett at python.org>:
> For those of you who don't know Carol, (...)

To be honest, I just met Carol at the Pycon US (yeah! that's the
purpose of such event, no?). I wasn't aware of her amazing work on
CPython. The thing is that I'm a "code" nerd: I basically ignore
everything related to CPython, except of the code in the CPython
repository.

With the amazing work done on the CPython workflow *leaded* by Brett
Cannon (Brett was also helped by a cool task force made of many people
doing many tasks all around), I realized that CPython is *much* larger
than just the code. Well, a friend is trying to explain me that for
years, but well, I'm slow :-)

Let me explain differently:

* if you remove the team who maintained bug tracker, users will be
unable to report new bugs or to reply -- sadly, issues on the
authentication occurs often (every 6 months?) for an unknown reason,
but hopefully it's always fixed quickly

* if you remove the core-workflow team, CPython would still be using
patch files attached to our bug tracker, we would still have to run
tests manually and hope (did I say pray?) that only a few buildbots
will break, etc. Well, I don't think that it's worth it to elaborate
on that part, the new workflow became so simple for contibutors *and*
core developers to publish, review and merge changes!

* if you remove the PyPI, haha... it's hard to imagine that, but ok,
let's say that pypi.python.org doesn't exist: trust me, the Python
community would simply not exist and Guido would have to serve his
lord Larry Wall (fear!).

* if you remove python.org... how would you get Python? how do you
find the documentation? where are the latest Python news? how can I
get information on Pycon events? etc.

* if you remove buildbots, Python wouldn't be at that quality level

* if you remove the security team, Python wouldn't be used in some
area for good reasons

* if you remove the Python infra team, say hello to PyPI down time,
"hey! is PyPI working for you?" -- do you recall this old time which
was no so long ago?

* if you remove Pycon events, ...

* if you remove mailing lists and our postmaster, ...

* ...

Sorry, I have to catch my flight, so I cannot finish my list, but I
guess that you now got my point :-)

So to come back to Carol: she is very active on mentoring newcomers,
guide them, take time to write kind emails, and obvious she helps a
lot on the devguide. Carol told me that she wants to start working on
the CPython documentation. Promoting her would only encourage that.

Same rationale for my previous vote to promote Mariatta, I expect that
mentoring and documentation would be a trampoline to extend their
interest in other areas. (I'm not saying that it's a requirement, just
that being recognize for our work gives good feeling and helps to
remain motivated since it's sometimes hard to write a change or to a
get a change merged.)

I hope that Carol would be an example for us to promote other people
working hard in CPython but remaing in the shadow of the "code" cloud.

I also expect that getting more core dev in other areas than the code
will help to notice active contributors to mentor them and maybe later
promote them as well as core dev.

As Barry reminded me in the keynote, the Python community is also kind
and welcome thanks to humour and the Monty Python. So I would like to
share that song with you:

   https://www.youtube.com/watch?v=SJUhlRoBL8M

/And...always look on the bright side of life.../
/Always look on the light side of life.../

Victor

From christian at cheimes.de  Tue May 23 16:12:11 2017
From: christian at cheimes.de (Christian Heimes)
Date: Tue, 23 May 2017 13:12:11 -0700
Subject: [python-committers] Proposing Carol Willing to become a core
 developer
In-Reply-To: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
References: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
Message-ID: <374213DF-7BD0-4EC9-98B2-71D807100D23@cheimes.de>

+1 from me
We need more experienced mentors and doc writers. 
Sent from my Android phone with K-9 Mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170523/88b458c3/attachment.html>

From p.f.moore at gmail.com  Tue May 23 16:17:09 2017
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 23 May 2017 21:17:09 +0100
Subject: [python-committers] Proposing Carol Willing to become a core
 developer
In-Reply-To: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
References: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
Message-ID: <CACac1F_sMOv16yLCFYu7eRrVEYkXgTm47BicMmDBhW-6EO8RmA@mail.gmail.com>

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

Definitely +1 from me.
Paul

From mal at egenix.com  Tue May 23 16:24:42 2017
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 23 May 2017 22:24:42 +0200
Subject: [python-committers] Proposing Carol Willing to become a core
 developer
In-Reply-To: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
References: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
Message-ID: <90d65228-8e8a-3f80-c5db-9f78fbb36721@egenix.com>

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

+1

-- 
Marc-Andre Lemburg
eGenix.com

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


From thomas at python.org  Tue May 23 16:36:21 2017
From: thomas at python.org (Thomas Wouters)
Date: Tue, 23 May 2017 22:36:21 +0200
Subject: [python-committers] Proposing Carol Willing to become a core
 developer
In-Reply-To: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
References: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
Message-ID: <CAPdQG2q6qggLWwunJJVkGej1Exacpod4b76F3G9txpQOidUoFw@mail.gmail.com>

On May 23, 2017 11:23, "Brett Cannon" <brett at python.org> wrote:

While at the PyCon US sprints the idea came up of offering Carol Willing
developer privileges. Everyone at the table -- about 6 of us -- liked the
idea and Carol also said she would happy to become a core dev, so I'm
officially putting her forward for consideration.

For those of you who don't know Carol, she basically knows our developer
workflow better than most of us. :) ; she's very active on the devguide and
core-mentorship. Carol has also attended the PyCon US language summit two
years in a row as a representative for the Jupyter project. She is actually
so good with new people that she managed to get my wife to make her first
open source contribution (something I never managed to do).

As usual, if you support/object to this idea, please say so. :)


Even when considering this is not a reward for her awesome work, but rather
enabling her to do more, as well as applying peer pressure to actually *do*
more... Yes, +1 ;-P
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170523/90d39bbd/attachment.html>

From senthil at uthcode.com  Tue May 23 17:42:09 2017
From: senthil at uthcode.com (Senthil Kumaran)
Date: Tue, 23 May 2017 14:42:09 -0700
Subject: [python-committers] Proposing Carol Willing to become a core
 developer
In-Reply-To: <CAMpsgwbTBQa72bSm5s04zhKEt1DbSrnMBM3hdo3Wc4UjhEpNag@mail.gmail.com>
References: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
 <CAMpsgwbTBQa72bSm5s04zhKEt1DbSrnMBM3hdo3Wc4UjhEpNag@mail.gmail.com>
Message-ID: <CAPOVWORUgdvhJN0cvKE9yR1HBmteLRnHCgKAh8EM8LpnZyyinQ@mail.gmail.com>

Support. :-)

On Tue, May 23, 2017 at 12:51 PM, Victor Stinner
<victor.stinner at gmail.com> wrote:

> Let me explain differently:
>

Also, liked reading Victor's email. :)

From victor.stinner at gmail.com  Tue May 23 20:12:16 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Tue, 23 May 2017 19:12:16 -0500
Subject: [python-committers] Proposing Carol Willing to become a core
 developer
In-Reply-To: <CAPOVWORUgdvhJN0cvKE9yR1HBmteLRnHCgKAh8EM8LpnZyyinQ@mail.gmail.com>
References: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
 <CAMpsgwbTBQa72bSm5s04zhKEt1DbSrnMBM3hdo3Wc4UjhEpNag@mail.gmail.com>
 <CAPOVWORUgdvhJN0cvKE9yR1HBmteLRnHCgKAh8EM8LpnZyyinQ@mail.gmail.com>
Message-ID: <CAMpsgwZOLrWq9t6+n0O6Sv10BOudTHY4Gpm0i-6XNjBM3uCChg@mail.gmail.com>

2017-05-23 16:42 GMT-05:00 Senthil Kumaran <senthil at uthcode.com>:
> Also, liked reading Victor's email. :)

Thank you. It's my feedback of constructive discussions about the
Python community at Pycon.

Victor

From rdmurray at bitdance.com  Tue May 23 20:55:19 2017
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 23 May 2017 20:55:19 -0400
Subject: [python-committers] Proposing Carol Willing to become a core
 developer
In-Reply-To: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
References: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
Message-ID: <20170524005519.785751310016@webabinitio.net>

+1

--David

From ethan at stoneleaf.us  Tue May 23 21:26:32 2017
From: ethan at stoneleaf.us (Ethan Furman)
Date: Tue, 23 May 2017 18:26:32 -0700
Subject: [python-committers] Proposing Carol Willing to become a core
 developer
In-Reply-To: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
References: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
Message-ID: <5924E148.8040706@stoneleaf.us>

On 05/23/2017 11:15 AM, Brett Cannon wrote:
> While at the PyCon US sprints the idea came up of offering Carol Willing developer privileges

I've always been impressed with her interactions.

+1

--
~Ethan~


From tjreedy at udel.edu  Tue May 23 21:29:26 2017
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 23 May 2017 21:29:26 -0400
Subject: [python-committers] Proposing Carol Willing to become a core
 developer
In-Reply-To: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
References: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
Message-ID: <5d917ba0-9b73-6d64-0caf-c68a2c6e48a5@udel.edu>

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

I have been wondering if the reason this had not yet been proposed were 
that she nixed the idea, perhaps because she contributes to python other 
ways.  In other words, +1.

Terry Jan Reedy


From ncoghlan at gmail.com  Wed May 24 03:25:18 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 24 May 2017 17:25:18 +1000
Subject: [python-committers] Proposing Carol Willing to become a core
 developer
In-Reply-To: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
References: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
Message-ID: <CADiSq7eqTo8fyKBy0mCNxgGnuZXfTM0BeTbZnQDiPQfjwGWJaw@mail.gmail.com>

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

Definite +1 from me (I was actually thinking of emailing Carol about
the idea before I saw this thread)

Cheers,
Nick.

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

From guido at python.org  Wed May 24 11:15:57 2017
From: guido at python.org (Guido van Rossum)
Date: Wed, 24 May 2017 08:15:57 -0700
Subject: [python-committers] Proposing Carol Willing to become a core
 developer
In-Reply-To: <CADiSq7eqTo8fyKBy0mCNxgGnuZXfTM0BeTbZnQDiPQfjwGWJaw@mail.gmail.com>
References: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
 <CADiSq7eqTo8fyKBy0mCNxgGnuZXfTM0BeTbZnQDiPQfjwGWJaw@mail.gmail.com>
Message-ID: <CAP7+vJKedQKDiobA1BckA-_GYikYs=jpBr3XVwUgT0AdDLkKMg@mail.gmail.com>

OK, I think we have enough +1 votes... Brett, will you make it happen?

On Wed, May 24, 2017 at 12:25 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 24 May 2017 at 04:15, Brett Cannon <brett at python.org> wrote:
> > While at the PyCon US sprints the idea came up of offering Carol Willing
> > developer privileges. Everyone at the table -- about 6 of us -- liked the
> > idea and Carol also said she would happy to become a core dev, so I'm
> > officially putting her forward for consideration.
> >
> > For those of you who don't know Carol, she basically knows our developer
> > workflow better than most of us. :) ; she's very active on the devguide
> and
> > core-mentorship. Carol has also attended the PyCon US language summit two
> > years in a row as a representative for the Jupyter project. She is
> actually
> > so good with new people that she managed to get my wife to make her first
> > open source contribution (something I never managed to do).
> >
> > As usual, if you support/object to this idea, please say so. :)
>
> Definite +1 from me (I was actually thinking of emailing Carol about
> the idea before I saw this thread)
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> 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/
>



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

From victor.stinner at gmail.com  Wed May 24 13:11:41 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Wed, 24 May 2017 12:11:41 -0500
Subject: [python-committers] Proposing Carol Willing to become a core
 developer
In-Reply-To: <CAP7+vJKedQKDiobA1BckA-_GYikYs=jpBr3XVwUgT0AdDLkKMg@mail.gmail.com>
References: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
 <CADiSq7eqTo8fyKBy0mCNxgGnuZXfTM0BeTbZnQDiPQfjwGWJaw@mail.gmail.com>
 <CAP7+vJKedQKDiobA1BckA-_GYikYs=jpBr3XVwUgT0AdDLkKMg@mail.gmail.com>
Message-ID: <CAMpsgwYLES4o44AouzPcfbx2EYetNxj1XRbn7Nosw1Cfx3shwg@mail.gmail.com>

Le 24 mai 2017 17:17, "Guido van Rossum" <guido at python.org> a ?crit :

OK, I think we have enough +1 votes... Brett, will you make it happen?


Well, that vote is just a world record in term of +1 in a short period of
time! (I also count +1 for Guido if I understood correctly ;-))

Victor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170524/0eb5aaac/attachment.html>

From brett at python.org  Wed May 24 13:15:43 2017
From: brett at python.org (Brett Cannon)
Date: Wed, 24 May 2017 17:15:43 +0000
Subject: [python-committers] Proposing Carol Willing to become a core
 developer
In-Reply-To: <CAP7+vJKedQKDiobA1BckA-_GYikYs=jpBr3XVwUgT0AdDLkKMg@mail.gmail.com>
References: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
 <CADiSq7eqTo8fyKBy0mCNxgGnuZXfTM0BeTbZnQDiPQfjwGWJaw@mail.gmail.com>
 <CAP7+vJKedQKDiobA1BckA-_GYikYs=jpBr3XVwUgT0AdDLkKMg@mail.gmail.com>
Message-ID: <CAP1=2W6owkDAHA=Jce05aAU2uGQxJ98dttXYSm4+BGgsAO=LzA@mail.gmail.com>

Done!

Carol, just accept the invitation to join the Python core team on GitHub at
https://github.com/python and that's it! (I already subscribed you to
python-committers under your Gmail account and Mariatta is taking care of
recording the granting of your commit privileges.)

On Wed, 24 May 2017 at 08:16 Guido van Rossum <guido at python.org> wrote:

> OK, I think we have enough +1 votes... Brett, will you make it happen?
>
> On Wed, May 24, 2017 at 12:25 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
>> On 24 May 2017 at 04:15, Brett Cannon <brett at python.org> wrote:
>> > While at the PyCon US sprints the idea came up of offering Carol Willing
>> > developer privileges. Everyone at the table -- about 6 of us -- liked
>> the
>> > idea and Carol also said she would happy to become a core dev, so I'm
>> > officially putting her forward for consideration.
>> >
>> > For those of you who don't know Carol, she basically knows our developer
>> > workflow better than most of us. :) ; she's very active on the devguide
>> and
>> > core-mentorship. Carol has also attended the PyCon US language summit
>> two
>> > years in a row as a representative for the Jupyter project. She is
>> actually
>> > so good with new people that she managed to get my wife to make her
>> first
>> > open source contribution (something I never managed to do).
>> >
>> > As usual, if you support/object to this idea, please say so. :)
>>
>> Definite +1 from me (I was actually thinking of emailing Carol about
>> the idea before I saw this thread)
>>
>> Cheers,
>> Nick.
>>
>> --
>> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>>
> _______________________________________________
>> 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/
>>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170524/1b257bc3/attachment.html>

From antoine at python.org  Thu May 25 04:01:39 2017
From: antoine at python.org (Antoine Pitrou)
Date: Thu, 25 May 2017 10:01:39 +0200
Subject: [python-committers] Guide to pushing to submitters' repo?
Message-ID: <531d76f4-c353-e5f3-42ac-25073d658b81@python.org>


Hi,

We now have a functionality to allow core developers to push to PR
repositories, but I can't find out how to make it work.

For example I have:

$ git remote -v
gescheit	git://github.com/gescheit/cpython.git (fetch)
gescheit	git://github.com/gescheit/cpython.git (push)
origin	https://github.com/python/cpython (fetch)
origin	https://github.com/python/cpython (push)
pitrou	git at github.com:pitrou/cpython.git (fetch)
pitrou	git at github.com:pitrou/cpython.git (push)

Then I try:

$ git push
fatal: remote error:
  You can't push to git://github.com/gescheit/cpython.git
  Use https://github.com/gescheit/cpython.git


So I try with the HTTPS URL instead:

$ git remote set-url gescheit https://github.com/gescheit/cpython.git
$ git push
Username for 'https://github.com': ^C


Did someone manage to make this work?  Can they post the entire
instructions they used? (including local branch setup)

(Context: trying to edit https://github.com/python/cpython/pull/1785)

Thank you

Antoine.

From victor.stinner at gmail.com  Thu May 25 07:16:09 2017
From: victor.stinner at gmail.com (Victor Stinner)
Date: Thu, 25 May 2017 13:16:09 +0200
Subject: [python-committers] Proposing Carol Willing to become a core
 developer
In-Reply-To: <CAP1=2W6owkDAHA=Jce05aAU2uGQxJ98dttXYSm4+BGgsAO=LzA@mail.gmail.com>
References: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
 <CADiSq7eqTo8fyKBy0mCNxgGnuZXfTM0BeTbZnQDiPQfjwGWJaw@mail.gmail.com>
 <CAP7+vJKedQKDiobA1BckA-_GYikYs=jpBr3XVwUgT0AdDLkKMg@mail.gmail.com>
 <CAP1=2W6owkDAHA=Jce05aAU2uGQxJ98dttXYSm4+BGgsAO=LzA@mail.gmail.com>
Message-ID: <CAMpsgwb4-BvpCzXRXkpzLRsNVwETP-vAYJU0tMoR6NLzsSDr8A@mail.gmail.com>

Welcome Carol!

Victor

Le 24 mai 2017 7:41 PM, "Brett Cannon" <brett at python.org> a ?crit :

> Done!
>
> Carol, just accept the invitation to join the Python core team on GitHub
> at https://github.com/python and that's it! (I already subscribed you to
> python-committers under your Gmail account and Mariatta is taking care of
> recording the granting of your commit privileges.)
>
> On Wed, 24 May 2017 at 08:16 Guido van Rossum <guido at python.org> wrote:
>
>> OK, I think we have enough +1 votes... Brett, will you make it happen?
>>
>> On Wed, May 24, 2017 at 12:25 AM, Nick Coghlan <ncoghlan at gmail.com>
>> wrote:
>>
>>> On 24 May 2017 at 04:15, Brett Cannon <brett at python.org> wrote:
>>> > While at the PyCon US sprints the idea came up of offering Carol
>>> Willing
>>> > developer privileges. Everyone at the table -- about 6 of us -- liked
>>> the
>>> > idea and Carol also said she would happy to become a core dev, so I'm
>>> > officially putting her forward for consideration.
>>> >
>>> > For those of you who don't know Carol, she basically knows our
>>> developer
>>> > workflow better than most of us. :) ; she's very active on the
>>> devguide and
>>> > core-mentorship. Carol has also attended the PyCon US language summit
>>> two
>>> > years in a row as a representative for the Jupyter project. She is
>>> actually
>>> > so good with new people that she managed to get my wife to make her
>>> first
>>> > open source contribution (something I never managed to do).
>>> >
>>> > As usual, if you support/object to this idea, please say so. :)
>>>
>>> Definite +1 from me (I was actually thinking of emailing Carol about
>>> the idea before I saw this thread)
>>>
>>> Cheers,
>>> Nick.
>>>
>>> --
>>> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>>>
>> _______________________________________________
>>> 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/
>>>
>>
>>
>>
>> --
>> --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/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170525/a38a610f/attachment-0001.html>

From willingc at gmail.com  Thu May 25 08:46:28 2017
From: willingc at gmail.com (Carol Willing)
Date: Thu, 25 May 2017 05:46:28 -0700
Subject: [python-committers] Proposing Carol Willing to become a core
 developer
In-Reply-To: <CAP1=2W6owkDAHA=Jce05aAU2uGQxJ98dttXYSm4+BGgsAO=LzA@mail.gmail.com>
References: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
 <CADiSq7eqTo8fyKBy0mCNxgGnuZXfTM0BeTbZnQDiPQfjwGWJaw@mail.gmail.com>
 <CAP7+vJKedQKDiobA1BckA-_GYikYs=jpBr3XVwUgT0AdDLkKMg@mail.gmail.com>
 <CAP1=2W6owkDAHA=Jce05aAU2uGQxJ98dttXYSm4+BGgsAO=LzA@mail.gmail.com>
Message-ID: <53BAAB46-D2FA-46DB-823A-B7855B1E9FE6@gmail.com>

Thank you for developing, supporting, and growing Python. Your impact on science and education is so valuable, and I hope to continue encouraging users and learners of Python.

Thanks for all of the kind words. (Victor, I loved your summary of all the ways that people contribute to making the Python community and language.)

In the spirit of a Monty Python introduction...

What is your name? Carol

What is your quest? To combine Python and Jupyter to inspire and teach others.

What is the air-speed velocity of an unladen swallow? For an African or European swallow, you can use Python, numpy, and Jupyter to calculate, explain, and share this information.

A special thank you to Guido for encouragement, kindness, and conversations about electronics tinkering. I look forward to working with the CPython team.

Warmly,

Carol

Carol Willing

Research Software Engineer
Project Jupyter at Cal Poly SLO

Director, Python Software Foundation

Signature Strengths
Empathy - Relator - Ideation - Strategic - Learner


> On May 24, 2017, at 10:15 AM, Brett Cannon <brett at python.org> wrote:
> 
> Done!
> 
> Carol, just accept the invitation to join the Python core team on GitHub at https://github.com/python <https://github.com/python> and that's it! (I already subscribed you to python-committers under your Gmail account and Mariatta is taking care of recording the granting of your commit privileges.)
> 
> On Wed, 24 May 2017 at 08:16 Guido van Rossum <guido at python.org <mailto:guido at python.org>> wrote:
> OK, I think we have enough +1 votes... Brett, will you make it happen?
> 
> On Wed, May 24, 2017 at 12:25 AM, Nick Coghlan <ncoghlan at gmail.com <mailto:ncoghlan at gmail.com>> wrote:
> On 24 May 2017 at 04:15, Brett Cannon <brett at python.org <mailto:brett at python.org>> wrote:
> > While at the PyCon US sprints the idea came up of offering Carol Willing
> > developer privileges. Everyone at the table -- about 6 of us -- liked the
> > idea and Carol also said she would happy to become a core dev, so I'm
> > officially putting her forward for consideration.
> >
> > For those of you who don't know Carol, she basically knows our developer
> > workflow better than most of us. :) ; she's very active on the devguide and
> > core-mentorship. Carol has also attended the PyCon US language summit two
> > years in a row as a representative for the Jupyter project. She is actually
> > so good with new people that she managed to get my wife to make her first
> > open source contribution (something I never managed to do).
> >
> > As usual, if you support/object to this idea, please say so. :)
> 
> Definite +1 from me (I was actually thinking of emailing Carol about
> the idea before I saw this thread)
> 
> Cheers,
> Nick.
> 
> --
> Nick Coghlan   |   ncoghlan at gmail.com <mailto:ncoghlan at gmail.com>   |   Brisbane, Australia
> _______________________________________________
> python-committers mailing list
> python-committers at python.org <mailto:python-committers at python.org>
> https://mail.python.org/mailman/listinfo/python-committers <https://mail.python.org/mailman/listinfo/python-committers>
> Code of Conduct: https://www.python.org/psf/codeofconduct/ <https://www.python.org/psf/codeofconduct/>
> 
> 
> 
> -- 
> --Guido van Rossum (python.org/~guido <http://python.org/~guido>)

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

From ncoghlan at gmail.com  Thu May 25 09:06:40 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 25 May 2017 23:06:40 +1000
Subject: [python-committers] Guide to pushing to submitters' repo?
In-Reply-To: <531d76f4-c353-e5f3-42ac-25073d658b81@python.org>
References: <531d76f4-c353-e5f3-42ac-25073d658b81@python.org>
Message-ID: <CADiSq7ehX6Hjb719AG2obOxYbNio3HSu-rpHW0fjqnvVU9CJ9g@mail.gmail.com>

On 25 May 2017 at 18:01, Antoine Pitrou <antoine at python.org> wrote:
> Did someone manage to make this work?  Can they post the entire
> instructions they used? (including local branch setup)

The minimal set of instructions some of us worked out are at
https://docs.python.org/devguide/gitbootcamp.html#editing-a-pull-request-prior-to-merging
(the initial draft was longer, but patch review found a few
opportunities for simplification)

However, that can still fail if the submitter hasn't checked the
"Allow edits by maintainers" option on their PR.

Cheers,
Nick.

P.S. the "git pr" alias mentioned there is detailed a few entries
earlier in the cheat sheet

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

From antoine at python.org  Thu May 25 09:27:03 2017
From: antoine at python.org (Antoine Pitrou)
Date: Thu, 25 May 2017 15:27:03 +0200
Subject: [python-committers] Guide to pushing to submitters' repo?
In-Reply-To: <CADiSq7ehX6Hjb719AG2obOxYbNio3HSu-rpHW0fjqnvVU9CJ9g@mail.gmail.com>
References: <531d76f4-c353-e5f3-42ac-25073d658b81@python.org>
 <CADiSq7ehX6Hjb719AG2obOxYbNio3HSu-rpHW0fjqnvVU9CJ9g@mail.gmail.com>
Message-ID: <724028e8-9845-6aee-b3e5-861b231bcabc@python.org>


Le 25/05/2017 ? 15:06, Nick Coghlan a ?crit :
> On 25 May 2017 at 18:01, Antoine Pitrou <antoine at python.org> wrote:
>> Did someone manage to make this work?  Can they post the entire
>> instructions they used? (including local branch setup)
> 
> The minimal set of instructions some of us worked out are at
> https://docs.python.org/devguide/gitbootcamp.html#editing-a-pull-request-prior-to-merging
> (the initial draft was longer, but patch review found a few
> opportunities for simplification)

Thank you.  Is it possible for the "git pr" alias to also edit the
branch tracking information?  Currently I get:

(master)$ git pr 1785
Depuis https://github.com/python/cpython
 * [nouvelle r?f?rence] refs/pull/1785/head -> pr_1785
Basculement sur la branche 'pr_1785'

(pr_1785)$ LANG=C git pull
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.

    git pull <remote> <branch>

If you wish to set tracking information for this branch you can do so with:

    git branch --set-upstream-to=<remote>/<branch> pr_1785


Regards

Antoine.

From mariatta.wijaya at gmail.com  Thu May 25 09:55:44 2017
From: mariatta.wijaya at gmail.com (Mariatta Wijaya)
Date: Thu, 25 May 2017 06:55:44 -0700
Subject: [python-committers] Guide to pushing to submitters' repo?
In-Reply-To: <724028e8-9845-6aee-b3e5-861b231bcabc@python.org>
References: <531d76f4-c353-e5f3-42ac-25073d658b81@python.org>
 <CADiSq7ehX6Hjb719AG2obOxYbNio3HSu-rpHW0fjqnvVU9CJ9g@mail.gmail.com>
 <724028e8-9845-6aee-b3e5-861b231bcabc@python.org>
Message-ID: <CAGbohnY_0Yws6xLRoxQ78Ov8SrfhAELqqz6mc64zxzKZCL7GPg@mail.gmail.com>

The git pr alias in the devguide assumes that you have origin and upstream
remote setup,
where origin is your own CPython fork, and upstream is python/CPython repo


On May 25, 2017 6:27 AM, "Antoine Pitrou" <antoine at python.org> wrote:


Le 25/05/2017 ? 15:06, Nick Coghlan a ?crit :
> On 25 May 2017 at 18:01, Antoine Pitrou <antoine at python.org> wrote:
>> Did someone manage to make this work?  Can they post the entire
>> instructions they used? (including local branch setup)
>
> The minimal set of instructions some of us worked out are at
> https://docs.python.org/devguide/gitbootcamp.html#
editing-a-pull-request-prior-to-merging
> (the initial draft was longer, but patch review found a few
> opportunities for simplification)

Thank you.  Is it possible for the "git pr" alias to also edit the
branch tracking information?  Currently I get:

(master)$ git pr 1785
Depuis https://github.com/python/cpython
 * [nouvelle r?f?rence] refs/pull/1785/head -> pr_1785
Basculement sur la branche 'pr_1785'

(pr_1785)$ LANG=C git pull
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.

    git pull <remote> <branch>

If you wish to set tracking information for this branch you can do so with:

    git branch --set-upstream-to=<remote>/<branch> pr_1785


Regards

Antoine.
_______________________________________________
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/20170525/7446228b/attachment-0001.html>

From zachary.ware+pydev at gmail.com  Thu May 25 10:05:31 2017
From: zachary.ware+pydev at gmail.com (Zachary Ware)
Date: Thu, 25 May 2017 07:05:31 -0700
Subject: [python-committers] Guide to pushing to submitters' repo?
In-Reply-To: <724028e8-9845-6aee-b3e5-861b231bcabc@python.org>
References: <531d76f4-c353-e5f3-42ac-25073d658b81@python.org>
 <CADiSq7ehX6Hjb719AG2obOxYbNio3HSu-rpHW0fjqnvVU9CJ9g@mail.gmail.com>
 <724028e8-9845-6aee-b3e5-861b231bcabc@python.org>
Message-ID: <CAKJDb-P67RB_dOFik+pjGhCCf6fm-dd1R6ahgP6E7RNoHf2ysA@mail.gmail.com>

On Thu, May 25, 2017 at 6:27 AM, Antoine Pitrou <antoine at python.org> wrote:
>
> Le 25/05/2017 ? 15:06, Nick Coghlan a ?crit :
>> On 25 May 2017 at 18:01, Antoine Pitrou <antoine at python.org> wrote:
>>> Did someone manage to make this work?  Can they post the entire
>>> instructions they used? (including local branch setup)
>>
>> The minimal set of instructions some of us worked out are at
>> https://docs.python.org/devguide/gitbootcamp.html#editing-a-pull-request-prior-to-merging
>> (the initial draft was longer, but patch review found a few
>> opportunities for simplification)
>
> Thank you.  Is it possible for the "git pr" alias to also edit the
> branch tracking information?  Currently I get:
>
> (master)$ git pr 1785
> Depuis https://github.com/python/cpython
>  * [nouvelle r?f?rence] refs/pull/1785/head -> pr_1785
> Basculement sur la branche 'pr_1785'
>
> (pr_1785)$ LANG=C git pull
> There is no tracking information for the current branch.
> Please specify which branch you want to merge with.
> See git-pull(1) for details.
>
>     git pull <remote> <branch>
>
> If you wish to set tracking information for this branch you can do so with:
>
>     git branch --set-upstream-to=<remote>/<branch> pr_1785

Unfortunately, GitHub does not allow pushing back to refs/pull/*.  To
get it to set you up to push back to the contributor's repo, you'd
need to provide the contributor's name and branch name, which is much
less convenient if you're just looking to try out a patch locally
without intending to push anything back.  If I can figure out a good
second alias for that, I'll be sure to share it.

You may be interested in the `hub` tool, which has a command for
'check out this PR and set up a remote for it' (though I can't
remember what it is at the moment).

-- 
Zach

From antoine at python.org  Thu May 25 10:41:22 2017
From: antoine at python.org (Antoine Pitrou)
Date: Thu, 25 May 2017 16:41:22 +0200
Subject: [python-committers] Guide to pushing to submitters' repo?
In-Reply-To: <CAKJDb-P67RB_dOFik+pjGhCCf6fm-dd1R6ahgP6E7RNoHf2ysA@mail.gmail.com>
References: <531d76f4-c353-e5f3-42ac-25073d658b81@python.org>
 <CADiSq7ehX6Hjb719AG2obOxYbNio3HSu-rpHW0fjqnvVU9CJ9g@mail.gmail.com>
 <724028e8-9845-6aee-b3e5-861b231bcabc@python.org>
 <CAKJDb-P67RB_dOFik+pjGhCCf6fm-dd1R6ahgP6E7RNoHf2ysA@mail.gmail.com>
Message-ID: <3a3cab58-849d-d92c-2a5e-dda66705a695@python.org>


Le 25/05/2017 ? 16:05, Zachary Ware a ?crit :
> 
> Unfortunately, GitHub does not allow pushing back to refs/pull/*.  To
> get it to set you up to push back to the contributor's repo, you'd
> need to provide the contributor's name and branch name, which is much
> less convenient if you're just looking to try out a patch locally
> without intending to push anything back.  If I can figure out a good
> second alias for that, I'll be sure to share it.

If I knew how to do that, I certainly would :-)

> You may be interested in the `hub` tool, which has a command for
> 'check out this PR and set up a remote for it' (though I can't
> remember what it is at the moment).

Thanks for the pointer.  Unfortunately, it seems that it really wants to
authenticate using username and password (even though browsing a public
project):

$ hub checkout https://github.com/python/cpython/pull/1785
github.com username: pitrou
github.com password for pitrou (never stored): ^C

Regards

Antoine.

From willingc at gmail.com  Thu May 25 11:52:29 2017
From: willingc at gmail.com (Carol Willing)
Date: Thu, 25 May 2017 08:52:29 -0700
Subject: [python-committers] Guide to pushing to submitters' repo?
In-Reply-To: <3a3cab58-849d-d92c-2a5e-dda66705a695@python.org>
References: <531d76f4-c353-e5f3-42ac-25073d658b81@python.org>
 <CADiSq7ehX6Hjb719AG2obOxYbNio3HSu-rpHW0fjqnvVU9CJ9g@mail.gmail.com>
 <724028e8-9845-6aee-b3e5-861b231bcabc@python.org>
 <CAKJDb-P67RB_dOFik+pjGhCCf6fm-dd1R6ahgP6E7RNoHf2ysA@mail.gmail.com>
 <3a3cab58-849d-d92c-2a5e-dda66705a695@python.org>
Message-ID: <05496BD4-F86B-4BB1-B7A9-02F4D12016AE@gmail.com>



> On May 25, 2017, at 7:41 AM, Antoine Pitrou <antoine at python.org> wrote:
> 
> 
> Le 25/05/2017 ? 16:05, Zachary Ware a ?crit :
>> 
>> Unfortunately, GitHub does not allow pushing back to refs/pull/*.  To
>> get it to set you up to push back to the contributor's repo, you'd
>> need to provide the contributor's name and branch name, which is much
>> less convenient if you're just looking to try out a patch locally
>> without intending to push anything back.  If I can figure out a good
>> second alias for that, I'll be sure to share it.
> 
> If I knew how to do that, I certainly would :-)
> 
>> You may be interested in the `hub` tool, which has a command for
>> 'check out this PR and set up a remote for it' (though I can't
>> remember what it is at the moment).
> 
> Thanks for the pointer.  Unfortunately, it seems that it really wants to
> authenticate using username and password (even though browsing a public
> project):
> 
> $ hub checkout https://github.com/python/cpython/pull/1785
> github.com username: pitrou
> github.com password for pitrou (never stored): ^C

Antoine, do you have an SSH key stored within your GitHub account settings?

You would still use the same command for hub to checkout the pull request, but GitHub would stop nagging for username/password.

> 
> Regards
> 
> Antoine.
> _______________________________________________
> 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 antoine at python.org  Thu May 25 11:59:01 2017
From: antoine at python.org (Antoine Pitrou)
Date: Thu, 25 May 2017 17:59:01 +0200
Subject: [python-committers] Guide to pushing to submitters' repo?
In-Reply-To: <05496BD4-F86B-4BB1-B7A9-02F4D12016AE@gmail.com>
References: <531d76f4-c353-e5f3-42ac-25073d658b81@python.org>
 <CADiSq7ehX6Hjb719AG2obOxYbNio3HSu-rpHW0fjqnvVU9CJ9g@mail.gmail.com>
 <724028e8-9845-6aee-b3e5-861b231bcabc@python.org>
 <CAKJDb-P67RB_dOFik+pjGhCCf6fm-dd1R6ahgP6E7RNoHf2ysA@mail.gmail.com>
 <3a3cab58-849d-d92c-2a5e-dda66705a695@python.org>
 <05496BD4-F86B-4BB1-B7A9-02F4D12016AE@gmail.com>
Message-ID: <1dc9cba4-4811-e0ea-a59d-823785191316@python.org>


Le 25/05/2017 ? 17:52, Carol Willing a ?crit :
>>
>> Thanks for the pointer.  Unfortunately, it seems that it really wants to
>> authenticate using username and password (even though browsing a public
>> project):
>>
>> $ hub checkout https://github.com/python/cpython/pull/1785
>> github.com username: pitrou
>> github.com password for pitrou (never stored): ^C
> 
> Antoine, do you have an SSH key stored within your GitHub account settings?

Yes, I do.

> You would still use the same command for hub to checkout the pull request, but GitHub would stop nagging for username/password.

Apparently not...

Regards

Antoine.

From ericsnowcurrently at gmail.com  Thu May 25 12:15:47 2017
From: ericsnowcurrently at gmail.com (Eric Snow)
Date: Thu, 25 May 2017 09:15:47 -0700
Subject: [python-committers] Proposing Carol Willing to become a core
 developer
In-Reply-To: <CAMpsgwb4-BvpCzXRXkpzLRsNVwETP-vAYJU0tMoR6NLzsSDr8A@mail.gmail.com>
References: <CAP1=2W7jcRhgUzj-mCD37QE9307Br1_nPMGGoRfZarfsPcie1A@mail.gmail.com>
 <CADiSq7eqTo8fyKBy0mCNxgGnuZXfTM0BeTbZnQDiPQfjwGWJaw@mail.gmail.com>
 <CAP7+vJKedQKDiobA1BckA-_GYikYs=jpBr3XVwUgT0AdDLkKMg@mail.gmail.com>
 <CAP1=2W6owkDAHA=Jce05aAU2uGQxJ98dttXYSm4+BGgsAO=LzA@mail.gmail.com>
 <CAMpsgwb4-BvpCzXRXkpzLRsNVwETP-vAYJU0tMoR6NLzsSDr8A@mail.gmail.com>
Message-ID: <CALFfu7A4tE48aEb7phka+ha5oGp=bD9eNydXKqZg4RoXDLY=Jg@mail.gmail.com>

On Thu, May 25, 2017 at 4:16 AM, Victor Stinner
<victor.stinner at gmail.com> wrote:
> Welcome Carol!

A giant +1 from me!  And a huge thank-you for how much you've already
been doing!  You are an excellent example of what makes this community
great.

-eric

From willingc at gmail.com  Thu May 25 13:07:24 2017
From: willingc at gmail.com (Carol Willing)
Date: Thu, 25 May 2017 10:07:24 -0700
Subject: [python-committers] Guide to pushing to submitters' repo?
In-Reply-To: <1dc9cba4-4811-e0ea-a59d-823785191316@python.org>
References: <531d76f4-c353-e5f3-42ac-25073d658b81@python.org>
 <CADiSq7ehX6Hjb719AG2obOxYbNio3HSu-rpHW0fjqnvVU9CJ9g@mail.gmail.com>
 <724028e8-9845-6aee-b3e5-861b231bcabc@python.org>
 <CAKJDb-P67RB_dOFik+pjGhCCf6fm-dd1R6ahgP6E7RNoHf2ysA@mail.gmail.com>
 <3a3cab58-849d-d92c-2a5e-dda66705a695@python.org>
 <05496BD4-F86B-4BB1-B7A9-02F4D12016AE@gmail.com>
 <1dc9cba4-4811-e0ea-a59d-823785191316@python.org>
Message-ID: <357275C2-2DE2-47D9-8C29-8B4DCEE1BC53@gmail.com>


> On May 25, 2017, at 8:59 AM, Antoine Pitrou <antoine at python.org> wrote:
> 
> 
> Le 25/05/2017 ? 17:52, Carol Willing a ?crit :
>>> 
>>> Thanks for the pointer.  Unfortunately, it seems that it really wants to
>>> authenticate using username and password (even though browsing a public
>>> project):
>>> 
>>> $ hub checkout https://github.com/python/cpython/pull/1785
>>> github.com username: pitrou
>>> github.com password for pitrou (never stored): ^C
>> 
>> Antoine, do you have an SSH key stored within your GitHub account settings?
> 
> Yes, I do.
> 
>> You would still use the same command for hub to checkout the pull request, but GitHub would stop nagging for username/password.
> 
> Apparently not...

Looking at the hub man page https://hub.github.com/hub.1.html <https://hub.github.com/hub.1.html>, hub uses an OAuth token which is probably not set or not being found by the hub app.

See Configuration section and GitHub OAuth subsection in the man page. Hope that helps.


> 
> Regards
> 
> Antoine.
> _______________________________________________
> 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/20170525/236e9619/attachment.html>

From brett at python.org  Sat May 27 14:52:36 2017
From: brett at python.org (Brett Cannon)
Date: Sat, 27 May 2017 18:52:36 +0000
Subject: [python-committers] Labels on GitHub now have classification
 prefixes
Message-ID: <CAP1=2W7PcghfveF9dxrzcrH6QQig1ozzTgKYf7jykaPS=bNB3w@mail.gmail.com>

https://github.com/python/cpython/labels now have prefixes for all labels
to make it easier to find the relevant labels for some kind of
classification. For instance, all the labels for the type of PR -- e.g.
bugfix, enhancement, etc. -- now all have a "type-" prefix so you know what
your options are (adding more labels is also always an option). This also
makes it easier to tell which PRs are lacking possible labels for each
classification (e.g. which PRs don't have a "type" label yet).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170527/ec5bf77f/attachment.html>

From brett at python.org  Sat May 27 18:33:08 2017
From: brett at python.org (Brett Cannon)
Date: Sat, 27 May 2017 22:33:08 +0000
Subject: [python-committers] Added a "sprint" label to GitHub
Message-ID: <CAP1=2W5GXEX-63ojhtadUgM15jv-kkgiehh57E5O0mOgc=kDfQ@mail.gmail.com>

After reading a tweet from Nick (
https://twitter.com/ncoghlan_dev/status/868343982698266624) I realized it
probably would have been good to label PRs from sprinters at PyCon US so
they could get priority while the contributor was in the room or at least
try to address them quickly after the sprint. So I added a "sprint" label
that can be added to any PRs created during a sprint.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170527/01594ac6/attachment.html>

From ncoghlan at gmail.com  Sun May 28 01:17:18 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 28 May 2017 15:17:18 +1000
Subject: [python-committers] Added a "sprint" label to GitHub
In-Reply-To: <CAP1=2W5GXEX-63ojhtadUgM15jv-kkgiehh57E5O0mOgc=kDfQ@mail.gmail.com>
References: <CAP1=2W5GXEX-63ojhtadUgM15jv-kkgiehh57E5O0mOgc=kDfQ@mail.gmail.com>
Message-ID: <CADiSq7ca-_PYxuZag-O3+ijU+dhLfMbB9-zApDWJpWNL9CyrJQ@mail.gmail.com>

On 28 May 2017 at 08:33, Brett Cannon <brett at python.org> wrote:
> After reading a tweet from Nick
> (https://twitter.com/ncoghlan_dev/status/868343982698266624) I realized it
> probably would have been good to label PRs from sprinters at PyCon US so
> they could get priority while the contributor was in the room or at least
> try to address them quickly after the sprint. So I added a "sprint" label
> that can be added to any PRs created during a sprint.

Handy!

I've gone through and backfilled the label on the PRs from the PyCon
Pune sprint [1], and also added a comment with the sprint name.

Cheers,
Nick.

[1] https://public.etherpad-mozilla.org/p/pycon-pune-2017-cpython-sprint

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

From alex.gaynor at gmail.com  Mon May 29 12:09:58 2017
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Mon, 29 May 2017 12:09:58 -0400
Subject: [python-committers] Appveyor tests failing for CPython?
Message-ID: <CAFRnB2VPawmhEadRTQhL3i7r-+GEb9GXOReV0vsyg1CoFdh5oA@mail.gmail.com>

Hi all,

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

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: D1B3 ADC0 E023 8CA6
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170529/df553cff/attachment.html>

From zachary.ware+pydev at gmail.com  Mon May 29 12:19:18 2017
From: zachary.ware+pydev at gmail.com (Zachary Ware)
Date: Mon, 29 May 2017 09:19:18 -0700
Subject: [python-committers] Appveyor tests failing for CPython?
In-Reply-To: <CAFRnB2VPawmhEadRTQhL3i7r-+GEb9GXOReV0vsyg1CoFdh5oA@mail.gmail.com>
References: <CAFRnB2VPawmhEadRTQhL3i7r-+GEb9GXOReV0vsyg1CoFdh5oA@mail.gmail.com>
Message-ID: <CAKJDb-OXiiJzsapmnYWTO5hEH2E5iRH-GcPgyn9NLUNxXCncFA@mail.gmail.com>

On Mon, May 29, 2017 at 9:09 AM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
> Hi all,
>
> It looks like appveyor tests are currently failing on all builds (something
> about UNC paths + imports). Was appveyor enabled recently, or did the test
> regress?

AppVeyor has been enabled for some time, but is not (yet) required.
It's possible that something has regressed, but it looks kind of like
AppVeyor changed something in the environment, particularly since all
of our Windows buildbots are fine.

-- 
Zach

From zachary.ware+pydev at gmail.com  Mon May 29 14:46:49 2017
From: zachary.ware+pydev at gmail.com (Zachary Ware)
Date: Mon, 29 May 2017 11:46:49 -0700
Subject: [python-committers] Appveyor tests failing for CPython?
In-Reply-To: <CAKJDb-OXiiJzsapmnYWTO5hEH2E5iRH-GcPgyn9NLUNxXCncFA@mail.gmail.com>
References: <CAFRnB2VPawmhEadRTQhL3i7r-+GEb9GXOReV0vsyg1CoFdh5oA@mail.gmail.com>
 <CAKJDb-OXiiJzsapmnYWTO5hEH2E5iRH-GcPgyn9NLUNxXCncFA@mail.gmail.com>
Message-ID: <CAKJDb-N_9LyeOtUYiwoz4gnE1RVM9R4i00v6VtB=5WQ2M5WGZw@mail.gmail.com>

On Mon, May 29, 2017 at 9:19 AM, Zachary Ware
<zachary.ware+pydev at gmail.com> wrote:
> On Mon, May 29, 2017 at 9:09 AM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
>> Hi all,
>>
>> It looks like appveyor tests are currently failing on all builds (something
>> about UNC paths + imports). Was appveyor enabled recently, or did the test
>> regress?
>
> AppVeyor has been enabled for some time, but is not (yet) required.
> It's possible that something has regressed, but it looks kind of like
> AppVeyor changed something in the environment, particularly since all
> of our Windows buildbots are fine.

AppVeyor is investigating, see
https://appveyor.tenderapp.com/discussions/problems/6765-environmental-change-blocking-unc-path-access
for updates.

-- 
Zach

From alex.gaynor at gmail.com  Mon May 29 14:47:54 2017
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Mon, 29 May 2017 14:47:54 -0400
Subject: [python-committers] Appveyor tests failing for CPython?
In-Reply-To: <CAKJDb-N_9LyeOtUYiwoz4gnE1RVM9R4i00v6VtB=5WQ2M5WGZw@mail.gmail.com>
References: <CAFRnB2VPawmhEadRTQhL3i7r-+GEb9GXOReV0vsyg1CoFdh5oA@mail.gmail.com>
 <CAKJDb-OXiiJzsapmnYWTO5hEH2E5iRH-GcPgyn9NLUNxXCncFA@mail.gmail.com>
 <CAKJDb-N_9LyeOtUYiwoz4gnE1RVM9R4i00v6VtB=5WQ2M5WGZw@mail.gmail.com>
Message-ID: <CAFRnB2X86OgcOavRyskEAKTTmdud5b8VJDUyR5VUdPve1OqG5g@mail.gmail.com>

Great, thanks for digging in!

Alex

On Mon, May 29, 2017 at 2:46 PM, Zachary Ware <zachary.ware+pydev at gmail.com>
wrote:

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



-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: D1B3 ADC0 E023 8CA6
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170529/429bca60/attachment.html>

From brett at python.org  Tue May 30 19:08:17 2017
From: brett at python.org (Brett Cannon)
Date: Tue, 30 May 2017 23:08:17 +0000
Subject: [python-committers] Travis skipping the test build
Message-ID: <CAP1=2W4TS7YQXT6AEWZ0AgeioxmNw7gSvehTBK38niO2ij=q7A@mail.gmail.com>

At the moment Travis is not running the test build (it's actually not even
listing it as a build). You can look at master, 3.6, or 3.5 to see that
only the docs and coverage builds are being run:
https://travis-ci.org/python/cpython/branches . I don't know why this is as
it was fine yesterday and then stopped working today. The last change was
from Antoine but its own Travis run ran fine so I don't think that caused
the problem: https://github.com/python/cpython/commits/master/.travis.yml .
If anyone can figure out if this is somehow our fault that would be great
(I can't see how it is).

But the key thing is to be aware that Travis being green just means the
docs built fine. So until this is resolved, try to remember to check if the
coverage test run passes if you want Travis to check your non-doc changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170530/9103ead2/attachment.html>

From mariatta.wijaya at gmail.com  Tue May 30 23:28:05 2017
From: mariatta.wijaya at gmail.com (Mariatta Wijaya)
Date: Tue, 30 May 2017 20:28:05 -0700
Subject: [python-committers] Travis skipping the test build
In-Reply-To: <CAP1=2W4TS7YQXT6AEWZ0AgeioxmNw7gSvehTBK38niO2ij=q7A@mail.gmail.com>
References: <CAP1=2W4TS7YQXT6AEWZ0AgeioxmNw7gSvehTBK38niO2ij=q7A@mail.gmail.com>
Message-ID: <CAGbohnboGB-iKR0y9p3r89TpKF_PT8mDoerw2946HZP6r_G50A@mail.gmail.com>

I think this PR takes care of it. https://github.com/python/
cpython/pull/1879



On May 30, 2017 4:08 PM, "Brett Cannon" <brett at python.org> wrote:

> At the moment Travis is not running the test build (it's actually not even
> listing it as a build). You can look at master, 3.6, or 3.5 to see that
> only the docs and coverage builds are being run: https://travis-ci.org/pyt
> hon/cpython/branches . I don't know why this is as it was fine yesterday
> and then stopped working today. The last change was from Antoine but its
> own Travis run ran fine so I don't think that caused the problem:
> https://github.com/python/cpython/commits/master/.travis.yml . If anyone
> can figure out if this is somehow our fault that would be great (I can't
> see how it is).
>
> But the key thing is to be aware that Travis being green just means the
> docs built fine. So until this is resolved, try to remember to check if the
> coverage test run passes if you want Travis to check your non-doc changes.
>
> _______________________________________________
> 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/20170530/260c28d5/attachment.html>

From brett at python.org  Wed May 31 13:42:35 2017
From: brett at python.org (Brett Cannon)
Date: Wed, 31 May 2017 17:42:35 +0000
Subject: [python-committers] Travis skipping the test build
In-Reply-To: <CAGbohnboGB-iKR0y9p3r89TpKF_PT8mDoerw2946HZP6r_G50A@mail.gmail.com>
References: <CAP1=2W4TS7YQXT6AEWZ0AgeioxmNw7gSvehTBK38niO2ij=q7A@mail.gmail.com>
 <CAGbohnboGB-iKR0y9p3r89TpKF_PT8mDoerw2946HZP6r_G50A@mail.gmail.com>
Message-ID: <CAP1=2W7NKPO-UVj290Jt3yxbrF-SqRGoo_wTsn99pUvBkRpXHA@mail.gmail.com>

Looks like it did fix the problem! Travis was also nice enough to reply to
me on Twitter about our problem:
https://twitter.com/travisci/status/869746712365150209.

On Tue, 30 May 2017 at 20:28 Mariatta Wijaya <mariatta.wijaya at gmail.com>
wrote:

> I think this PR takes care of it.
> https://github.com/python/cpython/pull/1879
>
>
>
> On May 30, 2017 4:08 PM, "Brett Cannon" <brett at python.org> wrote:
>
>> At the moment Travis is not running the test build (it's actually not
>> even listing it as a build). You can look at master, 3.6, or 3.5 to see
>> that only the docs and coverage builds are being run:
>> https://travis-ci.org/python/cpython/branches . I don't know why this is
>> as it was fine yesterday and then stopped working today. The last change
>> was from Antoine but its own Travis run ran fine so I don't think that
>> caused the problem:
>> https://github.com/python/cpython/commits/master/.travis.yml . If anyone
>> can figure out if this is somehow our fault that would be great (I can't
>> see how it is).
>>
>> But the key thing is to be aware that Travis being green just means the
>> docs built fine. So until this is resolved, try to remember to check if the
>> coverage test run passes if you want Travis to check your non-doc changes.
>>
>> _______________________________________________
>> 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/20170531/c43f5472/attachment.html>