From brett at python.org  Fri Jan  1 14:24:53 2016
From: brett at python.org (Brett Cannon)
Date: Fri, 01 Jan 2016 19:24:53 +0000
Subject: [python-committers] We will be moving to GitHub (hopefully) in 2016
Message-ID: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>

If you want to read the reasons I chose GitHub over GitLab, see
https://mail.python.org/pipermail/core-workflow/2016-January/000345.html .
If you want to discuss the decision or help with the transition, please
subscribe to the core-workflow mailing list.

Happy 2016 everyone, and here is to hoping we will have an easier developer
workflow by the end of this year!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160101/40c11e66/attachment.html>

From alex.gaynor at gmail.com  Fri Jan  1 15:06:37 2016
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Fri, 1 Jan 2016 15:06:37 -0500
Subject: [python-committers] We will be moving to GitHub (hopefully) in
 2016
In-Reply-To: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
Message-ID: <CAFRnB2Ub+fbrsJhcFnRzE8LTx+war-8ycGAvBmYYFp9C2F3mWw@mail.gmail.com>

Brett (and everyone else),

Thanks so much for all the time you put into working through this decision!

Alex

On Fri, Jan 1, 2016 at 2:24 PM, Brett Cannon <brett at python.org> wrote:

> If you want to read the reasons I chose GitHub over GitLab, see
> https://mail.python.org/pipermail/core-workflow/2016-January/000345.html .
> If you want to discuss the decision or help with the transition, please
> subscribe to the core-workflow mailing list.
>
> Happy 2016 everyone, and here is to hoping we will have an easier
> developer workflow by the end of this year!
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
>
>


-- 
"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: 125F 5C67 DFE9 4084
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160101/2fc62c51/attachment.html>

From benjamin at python.org  Fri Jan  1 17:53:07 2016
From: benjamin at python.org (Benjamin Peterson)
Date: Fri, 01 Jan 2016 14:53:07 -0800
Subject: [python-committers] We will be moving to GitHub (hopefully) in
 2016
In-Reply-To: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
Message-ID: <1451688787.2787495.480704786.55C95E97@webmail.messagingengine.com>

Brett, thank you very much for putting your (vacation!) time into this.

On Fri, Jan 1, 2016, at 11:24, Brett Cannon wrote:
> If you want to read the reasons I chose GitHub over GitLab, see
> https://mail.python.org/pipermail/core-workflow/2016-January/000345.html
> .
> If you want to discuss the decision or help with the transition, please
> subscribe to the core-workflow mailing list.
> 
> Happy 2016 everyone, and here is to hoping we will have an easier
> developer
> workflow by the end of this year!
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers

From ethan at stoneleaf.us  Fri Jan  1 23:31:12 2016
From: ethan at stoneleaf.us (Ethan Furman)
Date: Fri, 01 Jan 2016 20:31:12 -0800
Subject: [python-committers] We will be moving to GitHub (hopefully) in
 2016
In-Reply-To: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
Message-ID: <56875290.10006@stoneleaf.us>

On 01/01/2016 11:24 AM, Brett Cannon wrote:

> Happy 2016 everyone, and here is to hoping we will have an easier
> developer workflow by the end of this year!

Thanks for doing this, Brett!

I'm looking forward to an easier work flow.

--
~Ethan~


From andymac at bullseye.apana.org.au  Sat Jan  2 07:06:38 2016
From: andymac at bullseye.apana.org.au (Andrew MacIntyre)
Date: Sat, 2 Jan 2016 23:06:38 +1100
Subject: [python-committers] formalising retirement as a Python committer
Message-ID: <5687BD4E.5060600@bullseye.apana.org.au>

Sadly I have come to the conclusion that there is no realistic prospect 
of my being able to actively contribute to Python development in the 
foreseeable future given my current pursuits and interests, though I 
rely heavily on Python both personally and professionally.

As a practical matter I have not actively participated in Python 
development in some years and as a consequence I don't think I have any 
valid keys still on record.  Nor do I now have any operational OS/2 
systems to support the Python port to that platform that was my primary 
interest and contribution.

I would therefore request that appropriate administrative action be 
taken to close off any commit privileges previously granted to me that 
may still be active.

Beyond the OS/2 port, it pleases me that I was able to make several 
small contributions of more general utility.

While the announcement today of the planned move of the Python 
repository to GitHub has no bearing whatsoever on my decision, I would 
note that GitHub's requirement that a person only have one account - to 
be used for both personal activity and any activity on behalf of an 
employer - is of sufficient concern to me that had I decided to continue 
as a committer I would be seeking legal advice concerning my position. 
I say this as to date I have been able to satisfy my employer's 
requirements for clear separation of my personal activities, including 
my participation in Python development, from my activities as an 
employee.  This has been possible by exclusively using only provably 
personal resources, including accounts and internet access, for personal 
activities.  Such clear separation becomes much more difficult when 
resources such as accounts are shared between personal and employee 
roles, especially when being seen to do the right thing is as important 
as actually doing the right thing.

My best wishes to all who have made Python what it is and for Python's 
future!

Andrew MacIntyre.

-- 
-------------------------------------------------------------------------
Andrew I MacIntyre                     "These thoughts are mine alone..."
E-mail: andymac at bullseye.apana.org.au  (pref) | Snail: PO Box 370
         andymac at pcug.org.au             (alt) |        Belconnen ACT 2616
Web:    http://www.andymac.org/               |        Australia

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


From mal at egenix.com  Sat Jan  2 08:46:43 2016
From: mal at egenix.com (M.-A. Lemburg)
Date: Sat, 2 Jan 2016 14:46:43 +0100
Subject: [python-committers] Github accounts (was: formalising
 retirement as a Python committer)
In-Reply-To: <5687BD4E.5060600@bullseye.apana.org.au>
References: <5687BD4E.5060600@bullseye.apana.org.au>
Message-ID: <5687D4C3.7050305@egenix.com>

On 02.01.2016 13:06, Andrew MacIntyre wrote:
> While the announcement today of the planned move of the Python repository to GitHub has no bearing
> whatsoever on my decision, I would note that GitHub's requirement that a person only have one
> account - to be used for both personal activity and any activity on behalf of an employer - is of
> sufficient concern to me that had I decided to continue as a committer I would be seeking legal
> advice concerning my position. I say this as to date I have been able to satisfy my employer's
> requirements for clear separation of my personal activities, including my participation in Python
> development, from my activities as an employee.  This has been possible by exclusively using only
> provably personal resources, including accounts and internet access, for personal activities.  Such
> clear separation becomes much more difficult when resources such as accounts are shared between
> personal and employee roles, especially when being seen to do the right thing is as important as
> actually doing the right thing.

You are making a good point which I believe we have not yet discussed.

Github requires that "One person or legal entity may not maintain more
than one free account." in A.7. of their ToCs:

https://help.github.com/articles/github-terms-of-service/

So if you are using a free account for company purposes, you'd
have to get a paid account for personal use to e.g. contribute
to Python and clearly separate personal contributions from
ones you make as employee.

By using just one account, such a separation would be difficult
or could cause problems for employees of companies which require
clear separation of activities from personal ones. It would also
create a problem for the PSF, since without a clear separation,
we'd need a contrib form from the employer to be able to legally
accept the contributions in such situations.

Would any of the existing committers run into such a problem ?

I guess the PSF could refund any Github charges incurred to
remedy the situation. Their smallest plan is USD 7 per month
and account, so that would mean costs of USD 84 per year and
committer - this certainly within range of what the PSF can
provide without problem.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Jan 02 2016)
>>> 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  Sat Jan  2 09:12:07 2016
From: p.f.moore at gmail.com (Paul Moore)
Date: Sat, 2 Jan 2016 14:12:07 +0000
Subject: [python-committers] Github accounts (was: formalising
 retirement as a Python committer)
In-Reply-To: <5687D4C3.7050305@egenix.com>
References: <5687BD4E.5060600@bullseye.apana.org.au>
 <5687D4C3.7050305@egenix.com>
Message-ID: <CACac1F8+LHgqhHvEds=zhtCU9TpNvkhwXMy8pXLiROEQLZZcug@mail.gmail.com>

On 2 January 2016 at 13:46, M.-A. Lemburg <mal at egenix.com> wrote:
> I guess the PSF could refund any Github charges incurred to
> remedy the situation. Their smallest plan is USD 7 per month
> and account, so that would mean costs of USD 84 per year and
> committer - this certainly within range of what the PSF can
> provide without problem.

Alternatively, would it be worth reaching out to Github to ask if they
would be willing to allow an exception? The condition seems intended
to disallow spamming or camping of accounts, which clearly isn't the
case here.

Note: I have no direct interest in this, as I only use my github
account for personal activities, so the issue doesn't affect me.

Paul

From senthil at uthcode.com  Sat Jan  2 09:44:20 2016
From: senthil at uthcode.com (Senthil Kumaran)
Date: Sat, 2 Jan 2016 06:44:20 -0800
Subject: [python-committers] Github accounts (was: formalising
 retirement as a Python committer)
In-Reply-To: <5687D4C3.7050305@egenix.com>
References: <5687BD4E.5060600@bullseye.apana.org.au>
 <5687D4C3.7050305@egenix.com>
Message-ID: <CAPOVWOTkZ2XyxDwFjRsje4oJXNJzqPymjHRDPh+qD3VqBKT9PA@mail.gmail.com>

On Sat, Jan 2, 2016 at 5:46 AM, M.-A. Lemburg <mal at egenix.com> wrote:

> So if you are using a free account for company purposes, you'd
> have to get a paid account for personal use to e.g. contribute
> to Python and clearly separate personal contributions from
> ones you make as employee.
>

In practice, I have seen the following common scenarios.

* Companies and businesses, most often have a paid account with GitHub.
This allows them use Github with the code which is not yet open source or
will never be open source. It is simply using Github.com as an
Infrastructure as a   Service, which many companies will willingly do. If
it is using this paid account is unsuitable for contributing to open source
projects then a free account could be created by the contributor.

* If the company encourages to use to free account, then I think, the
company realizes that the person may contribute to, not just it's open
source projects, but to other open source projects hosted in Github using
that account and should be open to that.

* A third scenario was mentioned by M.-A. Lemburg, wherein the company uses
free account, but the company or the individual, more likely the latter,
for some reason will not like to use the same account or other project
contribution. In that situation, the choice is to buy a paid account.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160102/536763a3/attachment.html>

From ncoghlan at gmail.com  Sat Jan  2 10:14:24 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 3 Jan 2016 01:14:24 +1000
Subject: [python-committers] Github accounts (was: formalising
 retirement as a Python committer)
In-Reply-To: <CACac1F8+LHgqhHvEds=zhtCU9TpNvkhwXMy8pXLiROEQLZZcug@mail.gmail.com>
References: <5687BD4E.5060600@bullseye.apana.org.au>
 <5687D4C3.7050305@egenix.com>
 <CACac1F8+LHgqhHvEds=zhtCU9TpNvkhwXMy8pXLiROEQLZZcug@mail.gmail.com>
Message-ID: <CADiSq7f=Z0UgHw5SV6sB8Cbet32i76KbpHJLJN=32t_MxyK9bw@mail.gmail.com>

On 3 January 2016 at 00:12, Paul Moore <p.f.moore at gmail.com> wrote:
> On 2 January 2016 at 13:46, M.-A. Lemburg <mal at egenix.com> wrote:
>> I guess the PSF could refund any Github charges incurred to
>> remedy the situation. Their smallest plan is USD 7 per month
>> and account, so that would mean costs of USD 84 per year and
>> committer - this certainly within range of what the PSF can
>> provide without problem.
>
> Alternatively, would it be worth reaching out to Github to ask if they
> would be willing to allow an exception? The condition seems intended
> to disallow spamming or camping of accounts, which clearly isn't the
> case here.
>
> Note: I have no direct interest in this, as I only use my github
> account for personal activities, so the issue doesn't affect me.

I use my own GitHub account for both personal projects and for work,
but Red Hat's open source contribution policies are probably the most
liberal on the planet, so I don't have any need to separate them.

However, it's also the case that if an employer is simultaneously:

1. Expecting employees to maintain a clear separation between personal
and paid activity on GitHub; and
2. Refusing to pay for dedicated GitHub work accounts for their employees

Then there's a contradiction between their expectations and their
failure to provide employees with the resources needed to meet those
expectations.

Regards,
Nick.

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

From brett at python.org  Sat Jan  2 12:49:30 2016
From: brett at python.org (Brett Cannon)
Date: Sat, 02 Jan 2016 17:49:30 +0000
Subject: [python-committers] Github accounts (was: formalising
 retirement as a Python committer)
In-Reply-To: <CADiSq7f=Z0UgHw5SV6sB8Cbet32i76KbpHJLJN=32t_MxyK9bw@mail.gmail.com>
References: <5687BD4E.5060600@bullseye.apana.org.au>
 <5687D4C3.7050305@egenix.com>
 <CACac1F8+LHgqhHvEds=zhtCU9TpNvkhwXMy8pXLiROEQLZZcug@mail.gmail.com>
 <CADiSq7f=Z0UgHw5SV6sB8Cbet32i76KbpHJLJN=32t_MxyK9bw@mail.gmail.com>
Message-ID: <CAP1=2W51QAqmB=CiqzTeV4wKJe7+_ipGmQvj2wLoiuooHThkHw@mail.gmail.com>

On Sat, 2 Jan 2016 at 07:14 Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 3 January 2016 at 00:12, Paul Moore <p.f.moore at gmail.com> wrote:
> > On 2 January 2016 at 13:46, M.-A. Lemburg <mal at egenix.com> wrote:
> >> I guess the PSF could refund any Github charges incurred to
> >> remedy the situation. Their smallest plan is USD 7 per month
> >> and account, so that would mean costs of USD 84 per year and
> >> committer - this certainly within range of what the PSF can
> >> provide without problem.
> >
> > Alternatively, would it be worth reaching out to Github to ask if they
> > would be willing to allow an exception? The condition seems intended
> > to disallow spamming or camping of accounts, which clearly isn't the
> > case here.
> >
> > Note: I have no direct interest in this, as I only use my github
> > account for personal activities, so the issue doesn't affect me.
>
> I use my own GitHub account for both personal projects and for work,
> but Red Hat's open source contribution policies are probably the most
> liberal on the planet, so I don't have any need to separate them.
>

Ditto for me and Microsoft.


>
> However, it's also the case that if an employer is simultaneously:
>
> 1. Expecting employees to maintain a clear separation between personal
> and paid activity on GitHub; and
> 2. Refusing to pay for dedicated GitHub work accounts for their employees
>
> Then there's a contradiction between their expectations and their
> failure to provide employees with the resources needed to meet those
> expectations.
>

I also know of people whose company is being mean to them by saying "we
expect you to use your single free account for us and it's your problem if
you want a clean separation because we're too cheap to pay for your own
account" getting around this by ignoring the ToS restriction. Obviously not
everyone will feel comfortable doing that, but I have never known anyone to
have their GitHub account shut down because they had separate work and
personal accounts that were both on the free tier.

But as MAL said, the PSF could easily cover the fee for a core dev to get a
paid micro account if someone felt they really wanted it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160102/42d01ba5/attachment.html>

From brett at python.org  Sat Jan  2 13:24:45 2016
From: brett at python.org (Brett Cannon)
Date: Sat, 02 Jan 2016 18:24:45 +0000
Subject: [python-committers] Github accounts (was: formalising
 retirement as a Python committer)
In-Reply-To: <CAP1=2W51QAqmB=CiqzTeV4wKJe7+_ipGmQvj2wLoiuooHThkHw@mail.gmail.com>
References: <5687BD4E.5060600@bullseye.apana.org.au>
 <5687D4C3.7050305@egenix.com>
 <CACac1F8+LHgqhHvEds=zhtCU9TpNvkhwXMy8pXLiROEQLZZcug@mail.gmail.com>
 <CADiSq7f=Z0UgHw5SV6sB8Cbet32i76KbpHJLJN=32t_MxyK9bw@mail.gmail.com>
 <CAP1=2W51QAqmB=CiqzTeV4wKJe7+_ipGmQvj2wLoiuooHThkHw@mail.gmail.com>
Message-ID: <CAP1=2W6j45OxAqobby2=xkdbrt83UVf_-vXLBK0+E9LvZX01Sw@mail.gmail.com>

Another idea I had is could someone reach out to another project like
Django or Go that switched to GitHub and see how they handled this
situation for contributors? I don't feel I'm in a good position to ask
about this since I personally don't have this issue so I don't think I
could judge what would be an acceptable solution beyond the paid micro
account solution.

On Sat, 2 Jan 2016 at 09:49 Brett Cannon <brett at python.org> wrote:

> On Sat, 2 Jan 2016 at 07:14 Nick Coghlan <ncoghlan at gmail.com> wrote:
>
>> On 3 January 2016 at 00:12, Paul Moore <p.f.moore at gmail.com> wrote:
>> > On 2 January 2016 at 13:46, M.-A. Lemburg <mal at egenix.com> wrote:
>> >> I guess the PSF could refund any Github charges incurred to
>> >> remedy the situation. Their smallest plan is USD 7 per month
>> >> and account, so that would mean costs of USD 84 per year and
>> >> committer - this certainly within range of what the PSF can
>> >> provide without problem.
>> >
>> > Alternatively, would it be worth reaching out to Github to ask if they
>> > would be willing to allow an exception? The condition seems intended
>> > to disallow spamming or camping of accounts, which clearly isn't the
>> > case here.
>> >
>> > Note: I have no direct interest in this, as I only use my github
>> > account for personal activities, so the issue doesn't affect me.
>>
>> I use my own GitHub account for both personal projects and for work,
>> but Red Hat's open source contribution policies are probably the most
>> liberal on the planet, so I don't have any need to separate them.
>>
>
> Ditto for me and Microsoft.
>
>
>>
>> However, it's also the case that if an employer is simultaneously:
>>
>> 1. Expecting employees to maintain a clear separation between personal
>> and paid activity on GitHub; and
>> 2. Refusing to pay for dedicated GitHub work accounts for their employees
>>
>> Then there's a contradiction between their expectations and their
>> failure to provide employees with the resources needed to meet those
>> expectations.
>>
>
> I also know of people whose company is being mean to them by saying "we
> expect you to use your single free account for us and it's your problem if
> you want a clean separation because we're too cheap to pay for your own
> account" getting around this by ignoring the ToS restriction. Obviously not
> everyone will feel comfortable doing that, but I have never known anyone to
> have their GitHub account shut down because they had separate work and
> personal accounts that were both on the free tier.
>
> But as MAL said, the PSF could easily cover the fee for a core dev to get
> a paid micro account if someone felt they really wanted it.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160102/62f10ace/attachment.html>

From alex.gaynor at gmail.com  Sat Jan  2 13:36:16 2016
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Sat, 2 Jan 2016 13:36:16 -0500
Subject: [python-committers] Github accounts (was: formalising
 retirement as a Python committer)
In-Reply-To: <CAP1=2W6j45OxAqobby2=xkdbrt83UVf_-vXLBK0+E9LvZX01Sw@mail.gmail.com>
References: <5687BD4E.5060600@bullseye.apana.org.au>
 <5687D4C3.7050305@egenix.com>
 <CACac1F8+LHgqhHvEds=zhtCU9TpNvkhwXMy8pXLiROEQLZZcug@mail.gmail.com>
 <CADiSq7f=Z0UgHw5SV6sB8Cbet32i76KbpHJLJN=32t_MxyK9bw@mail.gmail.com>
 <CAP1=2W51QAqmB=CiqzTeV4wKJe7+_ipGmQvj2wLoiuooHThkHw@mail.gmail.com>
 <CAP1=2W6j45OxAqobby2=xkdbrt83UVf_-vXLBK0+E9LvZX01Sw@mail.gmail.com>
Message-ID: <CAFRnB2W9g-RL4QX5ij+MUefqJ-NAVtSneFcaZPzDMuDuvf0zpw@mail.gmail.com>

For Django this has literally never come up.

Alex

On Sat, Jan 2, 2016 at 1:24 PM, Brett Cannon <brett at python.org> wrote:

> Another idea I had is could someone reach out to another project like
> Django or Go that switched to GitHub and see how they handled this
> situation for contributors? I don't feel I'm in a good position to ask
> about this since I personally don't have this issue so I don't think I
> could judge what would be an acceptable solution beyond the paid micro
> account solution.
>
> On Sat, 2 Jan 2016 at 09:49 Brett Cannon <brett at python.org> wrote:
>
>> On Sat, 2 Jan 2016 at 07:14 Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>>> On 3 January 2016 at 00:12, Paul Moore <p.f.moore at gmail.com> wrote:
>>> > On 2 January 2016 at 13:46, M.-A. Lemburg <mal at egenix.com> wrote:
>>> >> I guess the PSF could refund any Github charges incurred to
>>> >> remedy the situation. Their smallest plan is USD 7 per month
>>> >> and account, so that would mean costs of USD 84 per year and
>>> >> committer - this certainly within range of what the PSF can
>>> >> provide without problem.
>>> >
>>> > Alternatively, would it be worth reaching out to Github to ask if they
>>> > would be willing to allow an exception? The condition seems intended
>>> > to disallow spamming or camping of accounts, which clearly isn't the
>>> > case here.
>>> >
>>> > Note: I have no direct interest in this, as I only use my github
>>> > account for personal activities, so the issue doesn't affect me.
>>>
>>> I use my own GitHub account for both personal projects and for work,
>>> but Red Hat's open source contribution policies are probably the most
>>> liberal on the planet, so I don't have any need to separate them.
>>>
>>
>> Ditto for me and Microsoft.
>>
>>
>>>
>>> However, it's also the case that if an employer is simultaneously:
>>>
>>> 1. Expecting employees to maintain a clear separation between personal
>>> and paid activity on GitHub; and
>>> 2. Refusing to pay for dedicated GitHub work accounts for their employees
>>>
>>> Then there's a contradiction between their expectations and their
>>> failure to provide employees with the resources needed to meet those
>>> expectations.
>>>
>>
>> I also know of people whose company is being mean to them by saying "we
>> expect you to use your single free account for us and it's your problem if
>> you want a clean separation because we're too cheap to pay for your own
>> account" getting around this by ignoring the ToS restriction. Obviously not
>> everyone will feel comfortable doing that, but I have never known anyone to
>> have their GitHub account shut down because they had separate work and
>> personal accounts that were both on the free tier.
>>
>> But as MAL said, the PSF could easily cover the fee for a core dev to get
>> a paid micro account if someone felt they really wanted it.
>>
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
>
>


-- 
"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: 125F 5C67 DFE9 4084
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160102/ac0f8f95/attachment-0001.html>

From guido at python.org  Sat Jan  2 23:19:04 2016
From: guido at python.org (Guido van Rossum)
Date: Sat, 2 Jan 2016 21:19:04 -0700
Subject: [python-committers] Github accounts (was: formalising
 retirement as a Python committer)
In-Reply-To: <CAFRnB2W9g-RL4QX5ij+MUefqJ-NAVtSneFcaZPzDMuDuvf0zpw@mail.gmail.com>
References: <5687BD4E.5060600@bullseye.apana.org.au>
 <5687D4C3.7050305@egenix.com>
 <CACac1F8+LHgqhHvEds=zhtCU9TpNvkhwXMy8pXLiROEQLZZcug@mail.gmail.com>
 <CADiSq7f=Z0UgHw5SV6sB8Cbet32i76KbpHJLJN=32t_MxyK9bw@mail.gmail.com>
 <CAP1=2W51QAqmB=CiqzTeV4wKJe7+_ipGmQvj2wLoiuooHThkHw@mail.gmail.com>
 <CAP1=2W6j45OxAqobby2=xkdbrt83UVf_-vXLBK0+E9LvZX01Sw@mail.gmail.com>
 <CAFRnB2W9g-RL4QX5ij+MUefqJ-NAVtSneFcaZPzDMuDuvf0zpw@mail.gmail.com>
Message-ID: <CAP7+vJL7D56+c5ateygJxASbvMOfR+3uHD+Rjeg25GohaAj3nQ@mail.gmail.com>

This hardly seems like a real problem, so let's not worry more about it
until someone actually needs help solving this.

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

From guido at python.org  Sat Jan  2 23:34:53 2016
From: guido at python.org (Guido van Rossum)
Date: Sat, 2 Jan 2016 21:34:53 -0700
Subject: [python-committers] formalising retirement as a Python committer
In-Reply-To: <5687BD4E.5060600@bullseye.apana.org.au>
References: <5687BD4E.5060600@bullseye.apana.org.au>
Message-ID: <CAP7+vJ+7Zi6X89Qpj_re8eLLLjFCz8VTdycXVv2g6hjTLMN47g@mail.gmail.com>

Andrew,

Thanks for your contributions. You will be missed. Enjoy your new pursuits
and interests! If you ever want to come back we'll make sure to accommodate
you somehow.

--Guido

On Sat, Jan 2, 2016 at 5:06 AM, Andrew MacIntyre <
andymac at bullseye.apana.org.au> wrote:

> Sadly I have come to the conclusion that there is no realistic prospect of
> my being able to actively contribute to Python development in the
> foreseeable future given my current pursuits and interests, though I rely
> heavily on Python both personally and professionally.
>
> As a practical matter I have not actively participated in Python
> development in some years and as a consequence I don't think I have any
> valid keys still on record.  Nor do I now have any operational OS/2 systems
> to support the Python port to that platform that was my primary interest
> and contribution.
>
> I would therefore request that appropriate administrative action be taken
> to close off any commit privileges previously granted to me that may still
> be active.
>
> Beyond the OS/2 port, it pleases me that I was able to make several small
> contributions of more general utility.
>
> While the announcement today of the planned move of the Python repository
> to GitHub has no bearing whatsoever on my decision, I would note that
> GitHub's requirement that a person only have one account - to be used for
> both personal activity and any activity on behalf of an employer - is of
> sufficient concern to me that had I decided to continue as a committer I
> would be seeking legal advice concerning my position. I say this as to date
> I have been able to satisfy my employer's requirements for clear separation
> of my personal activities, including my participation in Python
> development, from my activities as an employee.  This has been possible by
> exclusively using only provably personal resources, including accounts and
> internet access, for personal activities.  Such clear separation becomes
> much more difficult when resources such as accounts are shared between
> personal and employee roles, especially when being seen to do the right
> thing is as important as actually doing the right thing.
>
> My best wishes to all who have made Python what it is and for Python's
> future!
>
> Andrew MacIntyre.
>
> --
> -------------------------------------------------------------------------
> Andrew I MacIntyre                     "These thoughts are mine alone..."
> E-mail: andymac at bullseye.apana.org.au  (pref) | Snail: PO Box 370
>         andymac at pcug.org.au             (alt) |        Belconnen ACT 2616
> Web:    http://www.andymac.org/               |        Australia
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
>



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

From guido at python.org  Sat Jan  2 23:39:21 2016
From: guido at python.org (Guido van Rossum)
Date: Sat, 2 Jan 2016 21:39:21 -0700
Subject: [python-committers] We will be moving to GitHub (hopefully) in
 2016
In-Reply-To: <56875290.10006@stoneleaf.us>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
 <56875290.10006@stoneleaf.us>
Message-ID: <CAP7+vJLZvN1AGRMYrmr8TRTP97nH2phe7iOyLA_XJs7j5-bYCA@mail.gmail.com>

Happy 2016 Brett! Thanks for all the care you've put into this decision. I
should also mention that I am happy that as a community we're always
willing to learn -- we've switched VCSes many times before and I expect we
will again in the future. Each time things get better, and I'm looking
forward to the implementation of this iteration, now that the decision is
made.

On Fri, Jan 1, 2016 at 9:31 PM, Ethan Furman <ethan at stoneleaf.us> wrote:

> On 01/01/2016 11:24 AM, Brett Cannon wrote:
>
> Happy 2016 everyone, and here is to hoping we will have an easier
>> developer workflow by the end of this year!
>>
>
> Thanks for doing this, Brett!
>
> I'm looking forward to an easier work flow.
>
> --
> ~Ethan~
>
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
>



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

From ncoghlan at gmail.com  Sun Jan  3 01:12:52 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 3 Jan 2016 16:12:52 +1000
Subject: [python-committers] We will be moving to GitHub (hopefully) in
 2016
In-Reply-To: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
Message-ID: <CADiSq7d40DzWYEEkNaXjhSeLdntbc_UaQ7RbkGT+Qa_o8G1TjA@mail.gmail.com>

On 2 January 2016 at 05:24, Brett Cannon <brett at python.org> wrote:
> If you want to read the reasons I chose GitHub over GitLab, see
> https://mail.python.org/pipermail/core-workflow/2016-January/000345.html .
> If you want to discuss the decision or help with the transition, please
> subscribe to the core-workflow mailing list.

Thanks for spearheading the decision making process here Brett - your
involvement really helped me clarify the problems I was trying to
solve back when I first wrote PEP 462, and also helped me make some
important decisions about prioritisation of my own activities.

Cheers,
Nick.

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

From mal at egenix.com  Sun Jan  3 08:38:12 2016
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun, 3 Jan 2016 14:38:12 +0100
Subject: [python-committers] Github accounts
In-Reply-To: <CAP7+vJL7D56+c5ateygJxASbvMOfR+3uHD+Rjeg25GohaAj3nQ@mail.gmail.com>
References: <5687BD4E.5060600@bullseye.apana.org.au>
 <5687D4C3.7050305@egenix.com>
 <CACac1F8+LHgqhHvEds=zhtCU9TpNvkhwXMy8pXLiROEQLZZcug@mail.gmail.com>
 <CADiSq7f=Z0UgHw5SV6sB8Cbet32i76KbpHJLJN=32t_MxyK9bw@mail.gmail.com>
 <CAP1=2W51QAqmB=CiqzTeV4wKJe7+_ipGmQvj2wLoiuooHThkHw@mail.gmail.com>
 <CAP1=2W6j45OxAqobby2=xkdbrt83UVf_-vXLBK0+E9LvZX01Sw@mail.gmail.com>
 <CAFRnB2W9g-RL4QX5ij+MUefqJ-NAVtSneFcaZPzDMuDuvf0zpw@mail.gmail.com>
 <CAP7+vJL7D56+c5ateygJxASbvMOfR+3uHD+Rjeg25GohaAj3nQ@mail.gmail.com>
Message-ID: <56892444.4070505@egenix.com>

On 03.01.2016 05:19, Guido van Rossum wrote:
> This hardly seems like a real problem, so let's not worry more about it
> until someone actually needs help solving this.

For Andrew, it would have been a real problem, so IMO it's better
to be prepared for it and let potential new contributors know that
we can help resolve the issue.

Otherwise, people who potentially have a problem wouldn't even
consider contributing via the new Github workflow, which can't
really be in our interest.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Jan 03 2016)
>>> 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 guido at python.org  Sun Jan  3 16:06:04 2016
From: guido at python.org (Guido van Rossum)
Date: Sun, 3 Jan 2016 13:06:04 -0800
Subject: [python-committers] Github accounts
In-Reply-To: <56892444.4070505@egenix.com>
References: <5687BD4E.5060600@bullseye.apana.org.au>
 <5687D4C3.7050305@egenix.com>
 <CACac1F8+LHgqhHvEds=zhtCU9TpNvkhwXMy8pXLiROEQLZZcug@mail.gmail.com>
 <CADiSq7f=Z0UgHw5SV6sB8Cbet32i76KbpHJLJN=32t_MxyK9bw@mail.gmail.com>
 <CAP1=2W51QAqmB=CiqzTeV4wKJe7+_ipGmQvj2wLoiuooHThkHw@mail.gmail.com>
 <CAP1=2W6j45OxAqobby2=xkdbrt83UVf_-vXLBK0+E9LvZX01Sw@mail.gmail.com>
 <CAFRnB2W9g-RL4QX5ij+MUefqJ-NAVtSneFcaZPzDMuDuvf0zpw@mail.gmail.com>
 <CAP7+vJL7D56+c5ateygJxASbvMOfR+3uHD+Rjeg25GohaAj3nQ@mail.gmail.com>
 <56892444.4070505@egenix.com>
Message-ID: <CAP7+vJJv20UwXuAT5ETZvisKNxfEQ+sJa2KLDrd5n7GGJ5cdGg@mail.gmail.com>

On Sun, Jan 3, 2016 at 5:38 AM, M.-A. Lemburg <mal at egenix.com> wrote:

> On 03.01.2016 05:19, Guido van Rossum wrote:
> > This hardly seems like a real problem, so let's not worry more about it
> > until someone actually needs help solving this.
>
> For Andrew, it would have been a real problem, so IMO it's better
> to be prepared for it and let potential new contributors know that
> we can help resolve the issue.
>
> Otherwise, people who potentially have a problem wouldn't even
> consider contributing via the new Github workflow, which can't
> really be in our interest.
>

The problem can hardly be unique to Python, can it? Thousands of well-known
open source projects are now on GitHub. Also note Alex's comment that it
has literally never come up for Django (which IMO has a healthier ration of
contributors than core Python).

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

From mal at egenix.com  Sun Jan  3 16:43:30 2016
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun, 3 Jan 2016 22:43:30 +0100
Subject: [python-committers] Github accounts
In-Reply-To: <CAP7+vJJv20UwXuAT5ETZvisKNxfEQ+sJa2KLDrd5n7GGJ5cdGg@mail.gmail.com>
References: <5687BD4E.5060600@bullseye.apana.org.au>
 <5687D4C3.7050305@egenix.com>
 <CACac1F8+LHgqhHvEds=zhtCU9TpNvkhwXMy8pXLiROEQLZZcug@mail.gmail.com>
 <CADiSq7f=Z0UgHw5SV6sB8Cbet32i76KbpHJLJN=32t_MxyK9bw@mail.gmail.com>
 <CAP1=2W51QAqmB=CiqzTeV4wKJe7+_ipGmQvj2wLoiuooHThkHw@mail.gmail.com>
 <CAP1=2W6j45OxAqobby2=xkdbrt83UVf_-vXLBK0+E9LvZX01Sw@mail.gmail.com>
 <CAFRnB2W9g-RL4QX5ij+MUefqJ-NAVtSneFcaZPzDMuDuvf0zpw@mail.gmail.com>
 <CAP7+vJL7D56+c5ateygJxASbvMOfR+3uHD+Rjeg25GohaAj3nQ@mail.gmail.com>
 <56892444.4070505@egenix.com>
 <CAP7+vJJv20UwXuAT5ETZvisKNxfEQ+sJa2KLDrd5n7GGJ5cdGg@mail.gmail.com>
Message-ID: <56899602.1050206@egenix.com>

On 03.01.2016 22:06, Guido van Rossum wrote:
> On Sun, Jan 3, 2016 at 5:38 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> 
>> On 03.01.2016 05:19, Guido van Rossum wrote:
>>> This hardly seems like a real problem, so let's not worry more about it
>>> until someone actually needs help solving this.
>>
>> For Andrew, it would have been a real problem, so IMO it's better
>> to be prepared for it and let potential new contributors know that
>> we can help resolve the issue.
>>
>> Otherwise, people who potentially have a problem wouldn't even
>> consider contributing via the new Github workflow, which can't
>> really be in our interest.
>>
> 
> The problem can hardly be unique to Python, can it? Thousands of well-known
> open source projects are now on GitHub. Also note Alex's comment that it
> has literally never come up for Django (which IMO has a healthier ration of
> contributors than core Python).

Right, but people who have such a problem won't become contributors
if a Github account is the prerequisite for this and most likely
also won't bother asking for help. Others will either silently
accept violating Github terms by using multiple accounts or
ignore potential problems they might run into with their employers.

I think we should be pro-active and tell people that we are aware
of the problem, do care and will offer help where needed.

Who knows, perhaps this will trigger some rethinking on behalf of
Github to remove the restriction in their ToCs.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Jan 03 2016)
>>> 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 stefan at bytereef.org  Sun Jan  3 17:10:54 2016
From: stefan at bytereef.org (s.krah)
Date: Sun, 03 Jan 2016 23:10:54 +0100
Subject: [python-committers] Github accounts
In-Reply-To: <56899602.1050206@egenix.com>
References: <5687BD4E.5060600@bullseye.apana.org.au>
 <5687D4C3.7050305@egenix.com>
 <CACac1F8+LHgqhHvEds=zhtCU9TpNvkhwXMy8pXLiROEQLZZcug@mail.gmail.com>
 <CADiSq7f=Z0UgHw5SV6sB8Cbet32i76KbpHJLJN=32t_MxyK9bw@mail.gmail.com>
 <CAP1=2W51QAqmB=CiqzTeV4wKJe7+_ipGmQvj2wLoiuooHThkHw@mail.gmail.com>
 <CAP1=2W6j45OxAqobby2=xkdbrt83UVf_-vXLBK0+E9LvZX01Sw@mail.gmail.com>
 <CAFRnB2W9g-RL4QX5ij+MUefqJ-NAVtSneFcaZPzDMuDuvf0zpw@mail.gmail.com>
 <CAP7+vJL7D56+c5ateygJxASbvMOfR+3uHD+Rjeg25GohaAj3nQ@mail.gmail.com>
 <56892444.4070505@egenix.com>
 <CAP7+vJJv20UwXuAT5ETZvisKNxfEQ+sJa2KLDrd5n7GGJ5cdGg@mail.gmail.com>
 <56899602.1050206@egenix.com>
Message-ID: <152098b0f7a.ce88468892687.9195606248612696645@bytereef.org>


M.-A. Lemburg <mal at egenix.com> wrote:
> Right, but people who have such a problem won't become contributors
> if a Github account is the prerequisite for this and most likely
> also won't bother asking for help. Others will either silently
> accept violating Github terms by using multiple accounts or
>A ignore potential problems they might run into with their employers.

This is exactly what will happen, especially when new committers don't
dare to ask.

Given that the PSF protects itself with upload terms [1] that exceed the
regular level (e.g. Google's terms are far less strict), it only seems fair
that the software authors who make all this happen receive equal legal
protection.


Stefan Krah


[1] https://bitbucket.org/pypa/pypi/src/3f152fc78f36784ed8c3cecce050c46779a9c939/templates/confirm.pt?at=default&fileviewer=file-view-default






From andymac at bullseye.apana.org.au  Mon Jan  4 09:57:06 2016
From: andymac at bullseye.apana.org.au (Andrew MacIntyre)
Date: Tue, 5 Jan 2016 01:57:06 +1100
Subject: [python-committers] Github accounts
In-Reply-To: <56892444.4070505@egenix.com>
References: <5687BD4E.5060600@bullseye.apana.org.au>
 <5687D4C3.7050305@egenix.com>
 <CACac1F8+LHgqhHvEds=zhtCU9TpNvkhwXMy8pXLiROEQLZZcug@mail.gmail.com>
 <CADiSq7f=Z0UgHw5SV6sB8Cbet32i76KbpHJLJN=32t_MxyK9bw@mail.gmail.com>
 <CAP1=2W51QAqmB=CiqzTeV4wKJe7+_ipGmQvj2wLoiuooHThkHw@mail.gmail.com>
 <CAP1=2W6j45OxAqobby2=xkdbrt83UVf_-vXLBK0+E9LvZX01Sw@mail.gmail.com>
 <CAFRnB2W9g-RL4QX5ij+MUefqJ-NAVtSneFcaZPzDMuDuvf0zpw@mail.gmail.com>
 <CAP7+vJL7D56+c5ateygJxASbvMOfR+3uHD+Rjeg25GohaAj3nQ@mail.gmail.com>
 <56892444.4070505@egenix.com>
Message-ID: <568A8842.2000604@bullseye.apana.org.au>

On 4/01/2016 12:38 AM, M.-A. Lemburg wrote:
> On 03.01.2016 05:19, Guido van Rossum wrote:
>> This hardly seems like a real problem, so let's not worry more about it
>> until someone actually needs help solving this.
>
> For Andrew, it would have been a real problem, so IMO it's better
> to be prepared for it and let potential new contributors know that
> we can help resolve the issue.

My concern related to a potential situation rather than an existing 
situation, fortunately, and was partly based on incomplete information.

For my personal circumstances I've now concluded that if it had become 
necessary I think the separation requirements I need to comply with 
could be satisfied by:
- using a free GitHub account exclusively for personal activities; and
- using paid GitHub accounts exclusively for any employment related 
activities even in the unlikely event I have to cover costs myself.

If the scenario eventuated I would still seek formal advice to validate 
this assessment.  It is also fortunate that I've not compromised a free 
GitHub account by employment related use before reaching these conclusions.

> Otherwise, people who potentially have a problem wouldn't even
> consider contributing via the new Github workflow, which can't
> really be in our interest.

Having clear information about handling conflict of interest situations, 
particularly between personal and employment related activities in the 
context of both the PSF's contribution requirements and GitHub's ToS 
requirements (especially in relation to free accounts), can only be a 
help in my view.

All the best,
Andrew.

-- 
-------------------------------------------------------------------------
Andrew I MacIntyre                     "These thoughts are mine alone..."
E-mail: andymac at bullseye.apana.org.au  (pref) | Snail: PO Box 370
         andymac at pcug.org.au             (alt) |        Belconnen ACT 2616
Web:    http://www.andymac.org/               |        Australia

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


From eliben at gmail.com  Mon Jan  4 12:49:57 2016
From: eliben at gmail.com (Eli Bendersky)
Date: Mon, 4 Jan 2016 09:49:57 -0800
Subject: [python-committers] We will be moving to GitHub (hopefully) in
 2016
In-Reply-To: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
Message-ID: <CAF-Rda-XaGtidGsWi1aCOtdpqodDttcc8kiCukJAdv8xz7_ghw@mail.gmail.com>

On Fri, Jan 1, 2016 at 11:24 AM, Brett Cannon <brett at python.org> wrote:

> If you want to read the reasons I chose GitHub over GitLab, see
> https://mail.python.org/pipermail/core-workflow/2016-January/000345.html .
> If you want to discuss the decision or help with the transition, please
> subscribe to the core-workflow mailing list.
>
> Happy 2016 everyone, and here is to hoping we will have an easier
> developer workflow by the end of this year!
>

That sounds like a great idea.

I suppose you'll want to use https://github.com/python/cpython, which I'm
currently maintaining as a read-only mirror. Let me know when you want to
take control of that repo - I think since it belongs to the "python" Github
org already, it should be easy to do.

I have to admit that I'm not a big expert on Mercurial --> Git converters
and the way I maintain this mirror may not be the best approach, so I
encourage you folks to find a VCS guru to look into this for the "real"
transition.

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160104/325caca4/attachment.html>

From brett at python.org  Mon Jan  4 13:18:02 2016
From: brett at python.org (Brett Cannon)
Date: Mon, 04 Jan 2016 18:18:02 +0000
Subject: [python-committers] We will be moving to GitHub (hopefully) in
 2016
In-Reply-To: <CAF-Rda-XaGtidGsWi1aCOtdpqodDttcc8kiCukJAdv8xz7_ghw@mail.gmail.com>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
 <CAF-Rda-XaGtidGsWi1aCOtdpqodDttcc8kiCukJAdv8xz7_ghw@mail.gmail.com>
Message-ID: <CAP1=2W6nY3Qc4NCdqeyj5mJ=tr=rGo-0HsBO8qE4KFSv0t9e3w@mail.gmail.com>

On Mon, 4 Jan 2016 at 09:50 Eli Bendersky <eliben at gmail.com> wrote:

> On Fri, Jan 1, 2016 at 11:24 AM, Brett Cannon <brett at python.org> wrote:
>
>> If you want to read the reasons I chose GitHub over GitLab, see
>> https://mail.python.org/pipermail/core-workflow/2016-January/000345.html .
>> If you want to discuss the decision or help with the transition, please
>> subscribe to the core-workflow mailing list.
>>
>> Happy 2016 everyone, and here is to hoping we will have an easier
>> developer workflow by the end of this year!
>>
>
> That sounds like a great idea.
>
> I suppose you'll want to use https://github.com/python/cpython, which I'm
> currently maintaining as a read-only mirror. Let me know when you want to
> take control of that repo - I think since it belongs to the "python" Github
> org already, it should be easy to do.
>

I suspect we will want to use it, Eli, so thanks for the offer! I will let
you know if we end up choosing to use it.


>
> I have to admit that I'm not a big expert on Mercurial --> Git converters
> and the way I maintain this mirror may not be the best approach, so I
> encourage you folks to find a VCS guru to look into this for the "real"
> transition.
>

That will be one of the early steps of the transition. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160104/80732d41/attachment.html>

From rdmurray at bitdance.com  Mon Jan  4 15:33:51 2016
From: rdmurray at bitdance.com (R. David Murray)
Date: Mon, 04 Jan 2016 15:33:51 -0500
Subject: [python-committers] We will be moving to GitHub (hopefully) in
 2016
In-Reply-To: <CAP1=2W6nY3Qc4NCdqeyj5mJ=tr=rGo-0HsBO8qE4KFSv0t9e3w@mail.gmail.com>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
 <CAF-Rda-XaGtidGsWi1aCOtdpqodDttcc8kiCukJAdv8xz7_ghw@mail.gmail.com>
 <CAP1=2W6nY3Qc4NCdqeyj5mJ=tr=rGo-0HsBO8qE4KFSv0t9e3w@mail.gmail.com>
Message-ID: <20160104203353.034FCB1408D@webabinitio.net>

On Mon, 04 Jan 2016 18:18:02 +0000, Brett Cannon <brett at python.org> wrote:
> On Mon, 4 Jan 2016 at 09:50 Eli Bendersky <eliben at gmail.com> wrote:
> >
> > I have to admit that I'm not a big expert on Mercurial --> Git converters
> > and the way I maintain this mirror may not be the best approach, so I
> > encourage you folks to find a VCS guru to look into this for the "real"
> > transition.
> >
> 
> That will be one of the early steps of the transition. :)

Maybe The PSF could fund Eric Raymond to do this?  He's got
beyond-the-basics tooling, and a fair bit of experience converting
large projects.  He might even be able to clean up the older (svn)
history along the way, although that might be too much to hope for ;)

(Oh, and let me mention this while I'm thinking about it: we're going
to have to do some extra work to make the hash links work in the bug
tracker, since I don't think there's any a priori way to distinguish
between hg hashes and git hashes.)

--David

From barry at python.org  Mon Jan  4 15:51:54 2016
From: barry at python.org (Barry Warsaw)
Date: Mon, 4 Jan 2016 15:51:54 -0500
Subject: [python-committers] We will be moving to GitHub (hopefully) in
 2016
In-Reply-To: <20160104203353.034FCB1408D@webabinitio.net>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
 <CAF-Rda-XaGtidGsWi1aCOtdpqodDttcc8kiCukJAdv8xz7_ghw@mail.gmail.com>
 <CAP1=2W6nY3Qc4NCdqeyj5mJ=tr=rGo-0HsBO8qE4KFSv0t9e3w@mail.gmail.com>
 <20160104203353.034FCB1408D@webabinitio.net>
Message-ID: <20160104155154.22b488ec@limelight.wooz.org>

On Jan 04, 2016, at 03:33 PM, R. David Murray wrote:

>Maybe The PSF could fund Eric Raymond to do this?

reposurgeon is the tool he developed to port Emacs's bzr repository to git,
and it successfully handled all the previous vcses Emacs was ever developed
under (after, IIRC, much tweaking).

http://www.catb.org/esr/reposurgeon/

Looks like it at least claims to support hg.

I once looked at it and decided it wasn't something I wanted to touch ;) so
paying Eric to do it might not be a bad idea.

Cheers,
-Barry

From donald at stufft.io  Mon Jan  4 16:07:49 2016
From: donald at stufft.io (Donald Stufft)
Date: Mon, 4 Jan 2016 16:07:49 -0500
Subject: [python-committers] We will be moving to GitHub (hopefully) in
 2016
In-Reply-To: <20160104155154.22b488ec@limelight.wooz.org>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
 <CAF-Rda-XaGtidGsWi1aCOtdpqodDttcc8kiCukJAdv8xz7_ghw@mail.gmail.com>
 <CAP1=2W6nY3Qc4NCdqeyj5mJ=tr=rGo-0HsBO8qE4KFSv0t9e3w@mail.gmail.com>
 <20160104203353.034FCB1408D@webabinitio.net>
 <20160104155154.22b488ec@limelight.wooz.org>
Message-ID: <C4270861-BBEB-4D71-946B-3A91E20FBE1A@stufft.io>


> On Jan 4, 2016, at 3:51 PM, Barry Warsaw <barry at python.org> wrote:
> 
> I once looked at it and decided it wasn't something I wanted to touch ;) so
> paying Eric to do it might not be a bad idea.


I?d prefer it if we didn?t financially support ESR since he likes to spout off racist and misogynistic garbage. I?m sure we can figure out how to successfully migrate from Hg to git. I?ve already done it once on the demo repo, if that?s not good enough I?ll work on it some more if need be.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160104/bb06dbde/attachment-0001.sig>

From alex.gaynor at gmail.com  Mon Jan  4 16:08:16 2016
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Mon, 4 Jan 2016 16:08:16 -0500
Subject: [python-committers] We will be moving to GitHub (hopefully) in
 2016
In-Reply-To: <C4270861-BBEB-4D71-946B-3A91E20FBE1A@stufft.io>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
 <CAF-Rda-XaGtidGsWi1aCOtdpqodDttcc8kiCukJAdv8xz7_ghw@mail.gmail.com>
 <CAP1=2W6nY3Qc4NCdqeyj5mJ=tr=rGo-0HsBO8qE4KFSv0t9e3w@mail.gmail.com>
 <20160104203353.034FCB1408D@webabinitio.net>
 <20160104155154.22b488ec@limelight.wooz.org>
 <C4270861-BBEB-4D71-946B-3A91E20FBE1A@stufft.io>
Message-ID: <CAFRnB2XthppPAaDO9666DDbOwcV4eN8yx5AVX1kEFqJS5XdP9A@mail.gmail.com>

+1

Alex

On Mon, Jan 4, 2016 at 4:07 PM, Donald Stufft <donald at stufft.io> wrote:

>
> > On Jan 4, 2016, at 3:51 PM, Barry Warsaw <barry at python.org> wrote:
> >
> > I once looked at it and decided it wasn't something I wanted to touch ;)
> so
> > paying Eric to do it might not be a bad idea.
>
>
> I?d prefer it if we didn?t financially support ESR since he likes to spout
> off racist and misogynistic garbage. I?m sure we can figure out how to
> successfully migrate from Hg to git. I?ve already done it once on the demo
> repo, if that?s not good enough I?ll work on it some more if need be.
>
> -----------------
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
> DCFA
>
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
>
>


-- 
"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: 125F 5C67 DFE9 4084
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160104/77f71d18/attachment.html>

From steve.dower at python.org  Mon Jan  4 15:49:11 2016
From: steve.dower at python.org (Steve Dower)
Date: Tue, 5 Jan 2016 07:49:11 +1100
Subject: [python-committers] We will be moving to GitHub (hopefully)
 in2016
In-Reply-To: <20160104203353.034FCB1408D@webabinitio.net>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
 <CAF-Rda-XaGtidGsWi1aCOtdpqodDttcc8kiCukJAdv8xz7_ghw@mail.gmail.com>
 <CAP1=2W6nY3Qc4NCdqeyj5mJ=tr=rGo-0HsBO8qE4KFSv0t9e3w@mail.gmail.com>
 <20160104203353.034FCB1408D@webabinitio.net>
Message-ID: <E1aGCMf-0007Dh-AF@se2-syd.hostedmail.net.au>

I've found that hggit works very well - I used it to migrate my work project to github and still use it to avoid having to deal with git. (My intent is to keep using it for Python as well.)

Is the plan to migrate the entire history or just master?

Top-posted from my Windows Phone

-----Original Message-----
From: "R. David Murray" <rdmurray at bitdance.com>
Sent: ?1/?5/?2016 7:34
To: "python-committers" <python-committers at python.org>
Subject: Re: [python-committers] We will be moving to GitHub (hopefully) in2016

On Mon, 04 Jan 2016 18:18:02 +0000, Brett Cannon <brett at python.org> wrote:
> On Mon, 4 Jan 2016 at 09:50 Eli Bendersky <eliben at gmail.com> wrote:
> >
> > I have to admit that I'm not a big expert on Mercurial --> Git converters
> > and the way I maintain this mirror may not be the best approach, so I
> > encourage you folks to find a VCS guru to look into this for the "real"
> > transition.
> >
> 
> That will be one of the early steps of the transition. :)

Maybe The PSF could fund Eric Raymond to do this?  He's got
beyond-the-basics tooling, and a fair bit of experience converting
large projects.  He might even be able to clean up the older (svn)
history along the way, although that might be too much to hope for ;)

(Oh, and let me mention this while I'm thinking about it: we're going
to have to do some extra work to make the hash links work in the bug
tracker, since I don't think there's any a priori way to distinguish
between hg hashes and git hashes.)

--David
_______________________________________________
python-committers mailing list
python-committers at python.org
https://mail.python.org/mailman/listinfo/python-committers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160105/5cbfc475/attachment.html>

From brett at python.org  Mon Jan  4 16:11:53 2016
From: brett at python.org (Brett Cannon)
Date: Mon, 04 Jan 2016 21:11:53 +0000
Subject: [python-committers] We will be moving to GitHub (hopefully)
 in2016
In-Reply-To: <E1aGCMf-0007Dh-AF@se2-syd.hostedmail.net.au>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
 <CAF-Rda-XaGtidGsWi1aCOtdpqodDttcc8kiCukJAdv8xz7_ghw@mail.gmail.com>
 <CAP1=2W6nY3Qc4NCdqeyj5mJ=tr=rGo-0HsBO8qE4KFSv0t9e3w@mail.gmail.com>
 <20160104203353.034FCB1408D@webabinitio.net>
 <E1aGCMf-0007Dh-AF@se2-syd.hostedmail.net.au>
Message-ID: <CAP1=2W4pZtA3RqpAeNLanHGzR_ZfQQS3xUox7XaSd2XCuANiiA@mail.gmail.com>

On Mon, 4 Jan 2016 at 13:08 Steve Dower <steve.dower at python.org> wrote:

> I've found that hggit works very well - I used it to migrate my work
> project to github and still use it to avoid having to deal with git. (My
> intent is to keep using it for Python as well.)
>
> Is the plan to migrate the entire history or just master?
>

TBD. Email beginning to outline the dependency graph for the transition
forthcoming once I finish a code review at work that some co-worker handed
to me when he went off to Australia for an extended holiday. ;)

-Brett


>
> Top-posted from my Windows Phone
> ------------------------------
> From: R. David Murray <rdmurray at bitdance.com>
> Sent: ?1/?5/?2016 7:34
> To: python-committers <python-committers at python.org>
> Subject: Re: [python-committers] We will be moving to GitHub (hopefully)
> in2016
>
> On Mon, 04 Jan 2016 18:18:02 +0000, Brett Cannon <brett at python.org> wrote:
> > On Mon, 4 Jan 2016 at 09:50 Eli Bendersky <eliben at gmail.com> wrote:
> > >
> > > I have to admit that I'm not a big expert on Mercurial --> Git
> converters
> > > and the way I maintain this mirror may not be the best approach, so I
> > > encourage you folks to find a VCS guru to look into this for the "real"
> > > transition.
> > >
> >
> > That will be one of the early steps of the transition. :)
>
> Maybe The PSF could fund Eric Raymond to do this?  He's got
> beyond-the-basics tooling, and a fair bit of experience converting
> large projects.  He might even be able to clean up the older (svn)
> history along the way, although that might be too much to hope for ;)
>
> (Oh, and let me mention this while I'm thinking about it: we're going
> to have to do some extra work to make the hash links work in the bug
> tracker, since I don't think there's any a priori way to distinguish
> between hg hashes and git hashes.)
>
> --David
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160104/f66c7da0/attachment-0001.html>

From donald at stufft.io  Mon Jan  4 16:14:23 2016
From: donald at stufft.io (Donald Stufft)
Date: Mon, 4 Jan 2016 16:14:23 -0500
Subject: [python-committers] We will be moving to GitHub (hopefully)
 in2016
In-Reply-To: <CAP1=2W4pZtA3RqpAeNLanHGzR_ZfQQS3xUox7XaSd2XCuANiiA@mail.gmail.com>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
 <CAF-Rda-XaGtidGsWi1aCOtdpqodDttcc8kiCukJAdv8xz7_ghw@mail.gmail.com>
 <CAP1=2W6nY3Qc4NCdqeyj5mJ=tr=rGo-0HsBO8qE4KFSv0t9e3w@mail.gmail.com>
 <20160104203353.034FCB1408D@webabinitio.net>
 <E1aGCMf-0007Dh-AF@se2-syd.hostedmail.net.au>
 <CAP1=2W4pZtA3RqpAeNLanHGzR_ZfQQS3xUox7XaSd2XCuANiiA@mail.gmail.com>
Message-ID: <FEF41E6B-54B3-4D74-AC23-0C040EDDEFEE@stufft.io>


> On Jan 4, 2016, at 4:11 PM, Brett Cannon <brett at python.org> wrote:
> 
> 
> 
> On Mon, 4 Jan 2016 at 13:08 Steve Dower <steve.dower at python.org <mailto:steve.dower at python.org>> wrote:
> I've found that hggit works very well - I used it to migrate my work project to github and still use it to avoid having to deal with git. (My intent is to keep using it for Python as well.)
> 
> Is the plan to migrate the entire history or just master?
> 
> TBD. Email beginning to outline the dependency graph for the transition forthcoming once I finish a code review at work that some co-worker handed to me when he went off to Australia for an extended holiday. ;)
> 


It?s pretty easy to migrate the entire history (at least what?s in Hg) including all branches and tags.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160104/f39ff531/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160104/f39ff531/attachment.sig>

From brett at python.org  Mon Jan  4 16:18:39 2016
From: brett at python.org (Brett Cannon)
Date: Mon, 04 Jan 2016 21:18:39 +0000
Subject: [python-committers] We will be moving to GitHub (hopefully)
 in2016
In-Reply-To: <FEF41E6B-54B3-4D74-AC23-0C040EDDEFEE@stufft.io>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
 <CAF-Rda-XaGtidGsWi1aCOtdpqodDttcc8kiCukJAdv8xz7_ghw@mail.gmail.com>
 <CAP1=2W6nY3Qc4NCdqeyj5mJ=tr=rGo-0HsBO8qE4KFSv0t9e3w@mail.gmail.com>
 <20160104203353.034FCB1408D@webabinitio.net>
 <E1aGCMf-0007Dh-AF@se2-syd.hostedmail.net.au>
 <CAP1=2W4pZtA3RqpAeNLanHGzR_ZfQQS3xUox7XaSd2XCuANiiA@mail.gmail.com>
 <FEF41E6B-54B3-4D74-AC23-0C040EDDEFEE@stufft.io>
Message-ID: <CAP1=2W7-qc3vN7gy5zDoH3E1wQCgd78hq3vGbBhyo8XM5BNcDw@mail.gmail.com>

On Mon, 4 Jan 2016 at 13:14 Donald Stufft <donald at stufft.io> wrote:

>
> On Jan 4, 2016, at 4:11 PM, Brett Cannon <brett at python.org> wrote:
>
>
>
> On Mon, 4 Jan 2016 at 13:08 Steve Dower <steve.dower at python.org> wrote:
>
>> I've found that hggit works very well - I used it to migrate my work
>> project to github and still use it to avoid having to deal with git. (My
>> intent is to keep using it for Python as well.)
>>
>> Is the plan to migrate the entire history or just master?
>>
>
> TBD. Email beginning to outline the dependency graph for the transition
> forthcoming once I finish a code review at work that some co-worker handed
> to me when he went off to Australia for an extended holiday. ;)
>
>
> It?s pretty easy to migrate the entire history (at least what?s in Hg)
> including all branches and tags.
>

It's not about the difficulty as the size of the clone. E.g., if we make
Python 2 a separate repo does it buy us a lot of space savings (we need to
remember not everyone has broadband, so there is some potential balance to
be had between history vs. clone size)?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160104/546364db/attachment.html>

From donald at stufft.io  Mon Jan  4 16:50:13 2016
From: donald at stufft.io (Donald Stufft)
Date: Mon, 4 Jan 2016 16:50:13 -0500
Subject: [python-committers] We will be moving to GitHub (hopefully)
 in2016
In-Reply-To: <CAP1=2W7-qc3vN7gy5zDoH3E1wQCgd78hq3vGbBhyo8XM5BNcDw@mail.gmail.com>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
 <CAF-Rda-XaGtidGsWi1aCOtdpqodDttcc8kiCukJAdv8xz7_ghw@mail.gmail.com>
 <CAP1=2W6nY3Qc4NCdqeyj5mJ=tr=rGo-0HsBO8qE4KFSv0t9e3w@mail.gmail.com>
 <20160104203353.034FCB1408D@webabinitio.net>
 <E1aGCMf-0007Dh-AF@se2-syd.hostedmail.net.au>
 <CAP1=2W4pZtA3RqpAeNLanHGzR_ZfQQS3xUox7XaSd2XCuANiiA@mail.gmail.com>
 <FEF41E6B-54B3-4D74-AC23-0C040EDDEFEE@stufft.io>
 <CAP1=2W7-qc3vN7gy5zDoH3E1wQCgd78hq3vGbBhyo8XM5BNcDw@mail.gmail.com>
Message-ID: <C236DC7C-97DE-47E1-8926-31AF792CE681@stufft.io>

I'm not sure that you'd see much savings. You'd only get deltas that were never merged to master excluded. Point taken though. 

Sent from my iPhone

> On Jan 4, 2016, at 4:18 PM, Brett Cannon <brett at python.org> wrote:
> 
> 
> 
>> On Mon, 4 Jan 2016 at 13:14 Donald Stufft <donald at stufft.io> wrote:
>> 
>>> On Jan 4, 2016, at 4:11 PM, Brett Cannon <brett at python.org> wrote:
>>> 
>>> 
>>> 
>>> On Mon, 4 Jan 2016 at 13:08 Steve Dower <steve.dower at python.org> wrote:
>>>> I've found that hggit works very well - I used it to migrate my work project to github and still use it to avoid having to deal with git. (My intent is to keep using it for Python as well.)
>>>> 
>>>> Is the plan to migrate the entire history or just master?
>>> 
>>> TBD. Email beginning to outline the dependency graph for the transition forthcoming once I finish a code review at work that some co-worker handed to me when he went off to Australia for an extended holiday. ;)
>> 
>> 
>> It?s pretty easy to migrate the entire history (at least what?s in Hg) including all branches and tags.
> 
> It's not about the difficulty as the size of the clone. E.g., if we make Python 2 a separate repo does it buy us a lot of space savings (we need to remember not everyone has broadband, so there is some potential balance to be had between history vs. clone size)?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160104/de5019e8/attachment.html>

From guido at python.org  Mon Jan  4 17:09:31 2016
From: guido at python.org (Guido van Rossum)
Date: Mon, 4 Jan 2016 14:09:31 -0800
Subject: [python-committers] We will be moving to GitHub (hopefully)
 in2016
In-Reply-To: <C236DC7C-97DE-47E1-8926-31AF792CE681@stufft.io>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
 <CAF-Rda-XaGtidGsWi1aCOtdpqodDttcc8kiCukJAdv8xz7_ghw@mail.gmail.com>
 <CAP1=2W6nY3Qc4NCdqeyj5mJ=tr=rGo-0HsBO8qE4KFSv0t9e3w@mail.gmail.com>
 <20160104203353.034FCB1408D@webabinitio.net>
 <E1aGCMf-0007Dh-AF@se2-syd.hostedmail.net.au>
 <CAP1=2W4pZtA3RqpAeNLanHGzR_ZfQQS3xUox7XaSd2XCuANiiA@mail.gmail.com>
 <FEF41E6B-54B3-4D74-AC23-0C040EDDEFEE@stufft.io>
 <CAP1=2W7-qc3vN7gy5zDoH3E1wQCgd78hq3vGbBhyo8XM5BNcDw@mail.gmail.com>
 <C236DC7C-97DE-47E1-8926-31AF792CE681@stufft.io>
Message-ID: <CAP7+vJLDMOiFduGtk3uf6K3_arUTo_2Wq+a_Snkggi8KdNPHHw@mail.gmail.com>

On Mon, Jan 4, 2016 at 1:50 PM, Donald Stufft <donald at stufft.io> wrote:

> I'm not sure that you'd see much savings. You'd only get deltas that were
> never merged to master excluded. Point taken though.
>

Is the expectation that a Git clone would be significantly larger than an
Hg clone of an equivalent repo? I currently often rely on a single Hg clone
containing all branches.

+1 on not supporting ESR, for the stated reason.

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

From barry at python.org  Mon Jan  4 17:15:59 2016
From: barry at python.org (Barry Warsaw)
Date: Mon, 4 Jan 2016 17:15:59 -0500
Subject: [python-committers] We will be moving to GitHub (hopefully)
 in2016
In-Reply-To: <CAP7+vJLDMOiFduGtk3uf6K3_arUTo_2Wq+a_Snkggi8KdNPHHw@mail.gmail.com>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
 <CAF-Rda-XaGtidGsWi1aCOtdpqodDttcc8kiCukJAdv8xz7_ghw@mail.gmail.com>
 <CAP1=2W6nY3Qc4NCdqeyj5mJ=tr=rGo-0HsBO8qE4KFSv0t9e3w@mail.gmail.com>
 <20160104203353.034FCB1408D@webabinitio.net>
 <E1aGCMf-0007Dh-AF@se2-syd.hostedmail.net.au>
 <CAP1=2W4pZtA3RqpAeNLanHGzR_ZfQQS3xUox7XaSd2XCuANiiA@mail.gmail.com>
 <FEF41E6B-54B3-4D74-AC23-0C040EDDEFEE@stufft.io>
 <CAP1=2W7-qc3vN7gy5zDoH3E1wQCgd78hq3vGbBhyo8XM5BNcDw@mail.gmail.com>
 <C236DC7C-97DE-47E1-8926-31AF792CE681@stufft.io>
 <CAP7+vJLDMOiFduGtk3uf6K3_arUTo_2Wq+a_Snkggi8KdNPHHw@mail.gmail.com>
Message-ID: <20160104171559.570fcc2e@limelight.wooz.org>

On Jan 04, 2016, at 02:09 PM, Guido van Rossum wrote:

>I currently often rely on a single Hg clone containing all branches.

I do hope that a single repo will contain all the branches, though I wouldn't
mind too much if we split Python 2 and 3 into separate repos.  git worktree is
a nice tool if you want separate file system directories for the different
branches.

Cheers,
-Barry

From g.brandl at gmx.net  Mon Jan  4 17:38:42 2016
From: g.brandl at gmx.net (Georg Brandl)
Date: Mon, 4 Jan 2016 23:38:42 +0100
Subject: [python-committers] We will be moving to GitHub (hopefully) in
 2016
In-Reply-To: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
Message-ID: <n6es9i$1d0$1@ger.gmane.org>

On 01/01/2016 08:24 PM, Brett Cannon wrote:
> If you want to read the reasons I chose GitHub over GitLab,
> see https://mail.python.org/pipermail/core-workflow/2016-January/000345.html .
> If you want to discuss the decision or help with the transition, please
> subscribe to the core-workflow mailing list.
> 
> Happy 2016 everyone, and here is to hoping we will have an easier developer
> workflow by the end of this year!

Thanks for pioneering all the work and discussion needed to come to this
decision.

I think that in combination with a homu-style bot we can get a very nice
improved workflow going.

Georg


From alex.gaynor at gmail.com  Mon Jan  4 17:53:29 2016
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Mon, 4 Jan 2016 17:53:29 -0500
Subject: [python-committers] We will be moving to GitHub (hopefully) in
 2016
In-Reply-To: <n6es9i$1d0$1@ger.gmane.org>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
 <n6es9i$1d0$1@ger.gmane.org>
Message-ID: <CAFRnB2UQ2a+pU0chDy0ikbGagMft5OwW5pyRAw0EcRRqPeBV=w@mail.gmail.com>

My git clone is 350MB (after a make clean), a fresh hg clone is 650MB.

Alex

On Mon, Jan 4, 2016 at 5:38 PM, Georg Brandl <g.brandl at gmx.net> wrote:

> On 01/01/2016 08:24 PM, Brett Cannon wrote:
> > If you want to read the reasons I chose GitHub over GitLab,
> > see
> https://mail.python.org/pipermail/core-workflow/2016-January/000345.html .
> > If you want to discuss the decision or help with the transition, please
> > subscribe to the core-workflow mailing list.
> >
> > Happy 2016 everyone, and here is to hoping we will have an easier
> developer
> > workflow by the end of this year!
>
> Thanks for pioneering all the work and discussion needed to come to this
> decision.
>
> I think that in combination with a homu-style bot we can get a very nice
> improved workflow going.
>
> Georg
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
>



-- 
"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: 125F 5C67 DFE9 4084
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160104/14c776d2/attachment.html>

From brett at python.org  Mon Jan  4 17:56:57 2016
From: brett at python.org (Brett Cannon)
Date: Mon, 04 Jan 2016 22:56:57 +0000
Subject: [python-committers] We will be moving to GitHub (hopefully)
 in2016
In-Reply-To: <CAP7+vJLDMOiFduGtk3uf6K3_arUTo_2Wq+a_Snkggi8KdNPHHw@mail.gmail.com>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
 <CAF-Rda-XaGtidGsWi1aCOtdpqodDttcc8kiCukJAdv8xz7_ghw@mail.gmail.com>
 <CAP1=2W6nY3Qc4NCdqeyj5mJ=tr=rGo-0HsBO8qE4KFSv0t9e3w@mail.gmail.com>
 <20160104203353.034FCB1408D@webabinitio.net>
 <E1aGCMf-0007Dh-AF@se2-syd.hostedmail.net.au>
 <CAP1=2W4pZtA3RqpAeNLanHGzR_ZfQQS3xUox7XaSd2XCuANiiA@mail.gmail.com>
 <FEF41E6B-54B3-4D74-AC23-0C040EDDEFEE@stufft.io>
 <CAP1=2W7-qc3vN7gy5zDoH3E1wQCgd78hq3vGbBhyo8XM5BNcDw@mail.gmail.com>
 <C236DC7C-97DE-47E1-8926-31AF792CE681@stufft.io>
 <CAP7+vJLDMOiFduGtk3uf6K3_arUTo_2Wq+a_Snkggi8KdNPHHw@mail.gmail.com>
Message-ID: <CAP1=2W52pjOyL5pkji79qEwTHXqDQ6MoRW0q4JH83U9o_RzvpA@mail.gmail.com>

On Mon, 4 Jan 2016 at 14:09 Guido van Rossum <guido at python.org> wrote:

> On Mon, Jan 4, 2016 at 1:50 PM, Donald Stufft <donald at stufft.io> wrote:
>
>> I'm not sure that you'd see much savings. You'd only get deltas that were
>> never merged to master excluded. Point taken though.
>>
>
> Is the expectation that a Git clone would be significantly larger than an
> Hg clone of an equivalent repo? I currently often rely on a single Hg clone
> containing all branches.
>

I'm not sure, which is why I'm asking what difference it would make if we
separated out Python 2 branches into their own clone from Python 3 branches.


>
> +1 on not supporting ESR, for the stated reason.
>

+1 from me as well for not supporting ESR.

-Brett


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

From trent at snakebite.org  Mon Jan  4 19:06:33 2016
From: trent at snakebite.org (Trent Nelson)
Date: Mon, 4 Jan 2016 19:06:33 -0500
Subject: [python-committers] We will be moving to GitHub (hopefully) in
 2016
In-Reply-To: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
Message-ID: <20160105000633.GA2636@trent.me>

Hey Brett, all,

I?m playing a bit of catch-up with e-mail, but it occurred to me some of the
work I did getting PyParallel switched over to github could be of benefit.
First thing that comes to mind is this wiki page where I tried to capture the
steps I used for the conversion and subsequent keeping-in-sync:

https://github.com/pyparallel/pyparallel/wiki/Source-Control

They?re very rough notes but may prove useful.  Should *hopefully* be
repeatable.  One issue I noticed after the fact is that a couple of the renames
that happened when we went 2.x->3.x (like ConfigParser.py -> configparser.py)
didn?t get picked up by the hg->git conversion so I had to manually fix them
with commits like this:
https://github.com/pyparallel/pyparallel/commit/d3654f13048c8d6185a4c4b7953cbe8bd46b5d83

(I?ll be able to produce a proper list of the exact ones I had to fix? I just
wanted to get this e-mail out there for now.)

(That repo is sync?d up to around 3.5-ish (i.e. as of a few months ago)? all
the PyParallel stuff lived in separate *-px branches that originated from
3.3.x-ish.  Obviously we wouldn?t use that repo directly? or at least not
without git filtering out my PyParallel stuff.)

I also made some changes to things like the buildinfo glue to work with git
instead of hg:

https://github.com/pyparallel/pyparallel/blob/branches/3.3-px/diffs/PCbuild/make_buildinfo.c.patch

I also updated the installer/msi.py to work with git but Steve?s since
overhauled all this stuff so I?m not sure how useful it will be:

https://github.com/pyparallel/pyparallel/commit/ca64e60fd323875e2ca4af497d15d2f856f6c34d

What timeframe are we looking at?  There were some mentions of PSF funding in
later e-mails which I think this sort of work (once off but still needs high
precision) is well suited for.  I?ll throw my hat into the ring if the
PSF<->Continuum want to formally book out some time.  (I?m happy to help either
way, but doing it formally at least guarantees time availability.)

Regards,

        Trent.

On Fri, Jan 01, 2016 at 07:24:53PM +0000, Brett Cannon wrote:
> If you want to read the reasons I chose GitHub over GitLab, see
> https://mail.python.org/pipermail/core-workflow/2016-January/000345.html .
> If you want to discuss the decision or help with the transition, please
> subscribe to the core-workflow mailing list.
> 
> Happy 2016 everyone, and here is to hoping we will have an easier developer
> workflow by the end of this year!

> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers


From donald at stufft.io  Mon Jan  4 19:09:30 2016
From: donald at stufft.io (Donald Stufft)
Date: Mon, 4 Jan 2016 19:09:30 -0500
Subject: [python-committers] We will be moving to GitHub (hopefully) in
 2016
In-Reply-To: <20160105000633.GA2636@trent.me>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
 <20160105000633.GA2636@trent.me>
Message-ID: <97D64C1D-0A1E-4629-A251-84253F81782F@stufft.io>


> On Jan 4, 2016, at 7:06 PM, Trent Nelson <trent at snakebite.org> wrote:
> 
> Hey Brett, all,
> 
> I?m playing a bit of catch-up with e-mail, but it occurred to me some of the
> work I did getting PyParallel switched over to github could be of benefit.
> First thing that comes to mind is this wiki page where I tried to capture the
> steps I used for the conversion and subsequent keeping-in-sync:
> 
> https://github.com/pyparallel/pyparallel/wiki/Source-Control
> 
> They?re very rough notes but may prove useful.  Should *hopefully* be
> repeatable.  One issue I noticed after the fact is that a couple of the renames
> that happened when we went 2.x->3.x (like ConfigParser.py -> configparser.py)
> didn?t get picked up by the hg->git conversion so I had to manually fix them
> with commits like this:
> https://github.com/pyparallel/pyparallel/commit/d3654f13048c8d6185a4c4b7953cbe8bd46b5d83
> 
> (I?ll be able to produce a proper list of the exact ones I had to fix? I just
> wanted to get this e-mail out there for now.)

You probably did this on OS X or another case insensitive filesystem yea? I had the same problem the first time I did the CPython demo repository, until I did it on Linux instead.

> 
> (That repo is sync?d up to around 3.5-ish (i.e. as of a few months ago)? all
> the PyParallel stuff lived in separate *-px branches that originated from
> 3.3.x-ish.  Obviously we wouldn?t use that repo directly? or at least not
> without git filtering out my PyParallel stuff.)
> 
> I also made some changes to things like the buildinfo glue to work with git
> instead of hg:
> 
> https://github.com/pyparallel/pyparallel/blob/branches/3.3-px/diffs/PCbuild/make_buildinfo.c.patch
> 
> I also updated the installer/msi.py to work with git but Steve?s since
> overhauled all this stuff so I?m not sure how useful it will be:
> 
> https://github.com/pyparallel/pyparallel/commit/ca64e60fd323875e2ca4af497d15d2f856f6c34d
> 
> What timeframe are we looking at?  There were some mentions of PSF funding in
> later e-mails which I think this sort of work (once off but still needs high
> precision) is well suited for.  I?ll throw my hat into the ring if the
> PSF<->Continuum want to formally book out some time.  (I?m happy to help either
> way, but doing it formally at least guarantees time availability.)
> 
> Regards,
> 
>        Trent.
> 
> On Fri, Jan 01, 2016 at 07:24:53PM +0000, Brett Cannon wrote:
>> If you want to read the reasons I chose GitHub over GitLab, see
>> https://mail.python.org/pipermail/core-workflow/2016-January/000345.html .
>> If you want to discuss the decision or help with the transition, please
>> subscribe to the core-workflow mailing list.
>> 
>> Happy 2016 everyone, and here is to hoping we will have an easier developer
>> workflow by the end of this year!
> 
>> _______________________________________________
>> python-committers mailing list
>> python-committers at python.org
>> https://mail.python.org/mailman/listinfo/python-committers
> 
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160104/42b97953/attachment.sig>

From trent at snakebite.org  Mon Jan  4 19:24:07 2016
From: trent at snakebite.org (Trent Nelson)
Date: Mon, 4 Jan 2016 19:24:07 -0500
Subject: [python-committers] We will be moving to GitHub (hopefully) in
 2016
In-Reply-To: <97D64C1D-0A1E-4629-A251-84253F81782F@stufft.io>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
 <20160105000633.GA2636@trent.me>
 <97D64C1D-0A1E-4629-A251-84253F81782F@stufft.io>
Message-ID: <20160105002406.GB2636@trent.me>

On Mon, Jan 04, 2016 at 07:09:30PM -0500, Donald Stufft wrote:
> 
> > On Jan 4, 2016, at 7:06 PM, Trent Nelson <trent at snakebite.org>
> > wrote:
> > 
> > They?re very rough notes but may prove useful.  Should *hopefully*
> > be repeatable.  One issue I noticed after the fact is that a couple
> > of the renames that happened when we went 2.x->3.x (like
> > ConfigParser.py -> configparser.py) didn?t get picked up by the
> > hg->git conversion so I had to manually fix them with commits like
> > this:
> > https://github.com/pyparallel/pyparallel/commit/d3654f13048c8d6185a4c4b7953cbe8bd46b5d83
> > 
> > (I?ll be able to produce a proper list of the exact ones I had to
> > fix? I just wanted to get this e-mail out there for now.)
> 
> You probably did this on OS X or another case insensitive filesystem
> yea? I had the same problem the first time I did the CPython demo
> repository, until I did it on Linux instead.

    Yup, OS X.  That's great if it's just a matter of doing it on Linux!

        Trent.

From greg at krypto.org  Mon Jan  4 20:26:58 2016
From: greg at krypto.org (Gregory P. Smith)
Date: Tue, 05 Jan 2016 01:26:58 +0000
Subject: [python-committers] We will be moving to GitHub (hopefully) in
 2016
In-Reply-To: <20160104203353.034FCB1408D@webabinitio.net>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
 <CAF-Rda-XaGtidGsWi1aCOtdpqodDttcc8kiCukJAdv8xz7_ghw@mail.gmail.com>
 <CAP1=2W6nY3Qc4NCdqeyj5mJ=tr=rGo-0HsBO8qE4KFSv0t9e3w@mail.gmail.com>
 <20160104203353.034FCB1408D@webabinitio.net>
Message-ID: <CAGE7PNLSrd6oaidnXkBOh8zyrfu0+GtFLYJEYuoH0D1eqOHpYQ@mail.gmail.com>

On Mon, Jan 4, 2016 at 12:34 PM R. David Murray <rdmurray at bitdance.com>
wrote:

> to have to do some extra work to make the hash links work in the bug
> tracker, since I don't think there's any a priori way to distinguish
> between hg hashes and git hashes.
>

Just ignore the remote possibility of short 32-bit hash prefix collisions
(possible, but infrequent): the way to resolve that is when a hash lookup
fails, to look it up in a translation index of former hg hashes.
 practical.  good enough.

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

From rdmurray at bitdance.com  Mon Jan  4 20:33:39 2016
From: rdmurray at bitdance.com (R. David Murray)
Date: Mon, 04 Jan 2016 20:33:39 -0500
Subject: [python-committers] We will be moving to GitHub (hopefully) in
 2016
In-Reply-To: <CAGE7PNLSrd6oaidnXkBOh8zyrfu0+GtFLYJEYuoH0D1eqOHpYQ@mail.gmail.com>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
 <CAF-Rda-XaGtidGsWi1aCOtdpqodDttcc8kiCukJAdv8xz7_ghw@mail.gmail.com>
 <CAP1=2W6nY3Qc4NCdqeyj5mJ=tr=rGo-0HsBO8qE4KFSv0t9e3w@mail.gmail.com>
 <20160104203353.034FCB1408D@webabinitio.net>
 <CAGE7PNLSrd6oaidnXkBOh8zyrfu0+GtFLYJEYuoH0D1eqOHpYQ@mail.gmail.com>
Message-ID: <20160105013340.34A2EB1408D@webabinitio.net>

On Tue, 05 Jan 2016 01:26:58 +0000, "Gregory P. Smith" <greg at krypto.org> wrote:
> On Mon, Jan 4, 2016 at 12:34 PM R. David Murray <rdmurray at bitdance.com>
> wrote:
> 
> > to have to do some extra work to make the hash links work in the bug
> > tracker, since I don't think there's any a priori way to distinguish
> > between hg hashes and git hashes.
> >
> 
> Just ignore the remote possibility of short 32-bit hash prefix collisions
> (possible, but infrequent): the way to resolve that is when a hash lookup
> fails, to look it up in a translation index of former hg hashes.
>  practical.  good enough.

Yes, collision is not the problem, it's that you can't distinguish them
without a lookup table or something.  Which means we have to do more
than just change the URL in the existing linkifier, which was my point.

--David

From alex.gaynor at gmail.com  Mon Jan  4 20:37:02 2016
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Mon, 4 Jan 2016 20:37:02 -0500
Subject: [python-committers] We will be moving to GitHub (hopefully) in
 2016
In-Reply-To: <20160105013340.34A2EB1408D@webabinitio.net>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
 <CAF-Rda-XaGtidGsWi1aCOtdpqodDttcc8kiCukJAdv8xz7_ghw@mail.gmail.com>
 <CAP1=2W6nY3Qc4NCdqeyj5mJ=tr=rGo-0HsBO8qE4KFSv0t9e3w@mail.gmail.com>
 <20160104203353.034FCB1408D@webabinitio.net>
 <CAGE7PNLSrd6oaidnXkBOh8zyrfu0+GtFLYJEYuoH0D1eqOHpYQ@mail.gmail.com>
 <20160105013340.34A2EB1408D@webabinitio.net>
Message-ID: <CAFRnB2XpRLUbCXEA4AtHUjgnhjAjyomJectRXiyCoKB=cr_eDQ@mail.gmail.com>

Probably the easiest thing is to point the linkifier at our own webservice
that just does:

if hash not in cache:
    try:
         requests.head("github.com/hash")
     except requests.error:
         try:
            request.head("hg.python.org/hash")
         except request.error:
            return 404
         else:
            cache[hash] = hg.python.org
     else:
         cache[hash] = github
return cache[hash]


I'll send you my consulting bill :-)
Alex

On Mon, Jan 4, 2016 at 8:33 PM, R. David Murray <rdmurray at bitdance.com>
wrote:

> On Tue, 05 Jan 2016 01:26:58 +0000, "Gregory P. Smith" <greg at krypto.org>
> wrote:
> > On Mon, Jan 4, 2016 at 12:34 PM R. David Murray <rdmurray at bitdance.com>
> > wrote:
> >
> > > to have to do some extra work to make the hash links work in the bug
> > > tracker, since I don't think there's any a priori way to distinguish
> > > between hg hashes and git hashes.
> > >
> >
> > Just ignore the remote possibility of short 32-bit hash prefix collisions
> > (possible, but infrequent): the way to resolve that is when a hash lookup
> > fails, to look it up in a translation index of former hg hashes.
> >  practical.  good enough.
>
> Yes, collision is not the problem, it's that you can't distinguish them
> without a lookup table or something.  Which means we have to do more
> than just change the URL in the existing linkifier, which was my point.
>
> --David
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
>



-- 
"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: 125F 5C67 DFE9 4084
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160104/3879c423/attachment.html>

From ezio.melotti at gmail.com  Tue Jan  5 00:07:33 2016
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Tue, 5 Jan 2016 07:07:33 +0200
Subject: [python-committers] We will be moving to GitHub (hopefully) in
 2016
In-Reply-To: <CAFRnB2XpRLUbCXEA4AtHUjgnhjAjyomJectRXiyCoKB=cr_eDQ@mail.gmail.com>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
 <CAF-Rda-XaGtidGsWi1aCOtdpqodDttcc8kiCukJAdv8xz7_ghw@mail.gmail.com>
 <CAP1=2W6nY3Qc4NCdqeyj5mJ=tr=rGo-0HsBO8qE4KFSv0t9e3w@mail.gmail.com>
 <20160104203353.034FCB1408D@webabinitio.net>
 <CAGE7PNLSrd6oaidnXkBOh8zyrfu0+GtFLYJEYuoH0D1eqOHpYQ@mail.gmail.com>
 <20160105013340.34A2EB1408D@webabinitio.net>
 <CAFRnB2XpRLUbCXEA4AtHUjgnhjAjyomJectRXiyCoKB=cr_eDQ@mail.gmail.com>
Message-ID: <CACBhJdG89oTwZbpw5o_WKm3YNdsTTqtZah2d68eqwky9FNdtug@mail.gmail.com>

The linkifier converts old svn revision numbers to links to e.g.
https://hg.python.org/lookup/r12345 , and this figures out the
equivalent hg changeset and redirects to the corresponding hg.p.o
page.
The linkifier should just create links to
https://hg.python.org/lookup/csid and let the page figure out if the
csid is from hg or git and redirect where more appropriate.

Best Regards,
Ezio Melotti

On Tue, Jan 5, 2016 at 3:37 AM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
> Probably the easiest thing is to point the linkifier at our own webservice
> that just does:
>
> if hash not in cache:
>     try:
>          requests.head("github.com/hash")
>      except requests.error:
>          try:
>             request.head("hg.python.org/hash")
>          except request.error:
>             return 404
>          else:
>             cache[hash] = hg.python.org
>      else:
>          cache[hash] = github
> return cache[hash]
>
>
> I'll send you my consulting bill :-)
> Alex
>
> On Mon, Jan 4, 2016 at 8:33 PM, R. David Murray <rdmurray at bitdance.com>
> wrote:
>>
>> On Tue, 05 Jan 2016 01:26:58 +0000, "Gregory P. Smith" <greg at krypto.org>
>> wrote:
>> > On Mon, Jan 4, 2016 at 12:34 PM R. David Murray <rdmurray at bitdance.com>
>> > wrote:
>> >
>> > > to have to do some extra work to make the hash links work in the bug
>> > > tracker, since I don't think there's any a priori way to distinguish
>> > > between hg hashes and git hashes.
>> > >
>> >
>> > Just ignore the remote possibility of short 32-bit hash prefix
>> > collisions
>> > (possible, but infrequent): the way to resolve that is when a hash
>> > lookup
>> > fails, to look it up in a translation index of former hg hashes.
>> >  practical.  good enough.
>>
>> Yes, collision is not the problem, it's that you can't distinguish them
>> without a lookup table or something.  Which means we have to do more
>> than just change the URL in the existing linkifier, which was my point.
>>
>> --David
>> _______________________________________________
>> python-committers mailing list
>> python-committers at python.org
>> https://mail.python.org/mailman/listinfo/python-committers
>
>
>
>
> --
> "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: 125F 5C67 DFE9 4084
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
>

From ncoghlan at gmail.com  Tue Jan  5 00:38:03 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 5 Jan 2016 15:38:03 +1000
Subject: [python-committers] We will be moving to GitHub (hopefully) in
 2016
In-Reply-To: <20160105013340.34A2EB1408D@webabinitio.net>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
 <CAF-Rda-XaGtidGsWi1aCOtdpqodDttcc8kiCukJAdv8xz7_ghw@mail.gmail.com>
 <CAP1=2W6nY3Qc4NCdqeyj5mJ=tr=rGo-0HsBO8qE4KFSv0t9e3w@mail.gmail.com>
 <20160104203353.034FCB1408D@webabinitio.net>
 <CAGE7PNLSrd6oaidnXkBOh8zyrfu0+GtFLYJEYuoH0D1eqOHpYQ@mail.gmail.com>
 <20160105013340.34A2EB1408D@webabinitio.net>
Message-ID: <CADiSq7eZBWCUadjFsSzsKceXH2s+bRDLmSihgd14DtHZE4Yoxg@mail.gmail.com>

On 5 January 2016 at 11:33, R. David Murray <rdmurray at bitdance.com> wrote:
> On Tue, 05 Jan 2016 01:26:58 +0000, "Gregory P. Smith" <greg at krypto.org> wrote:
>> On Mon, Jan 4, 2016 at 12:34 PM R. David Murray <rdmurray at bitdance.com>
>> wrote:
>>
>> > to have to do some extra work to make the hash links work in the bug
>> > tracker, since I don't think there's any a priori way to distinguish
>> > between hg hashes and git hashes.
>> >
>>
>> Just ignore the remote possibility of short 32-bit hash prefix collisions
>> (possible, but infrequent): the way to resolve that is when a hash lookup
>> fails, to look it up in a translation index of former hg hashes.
>>  practical.  good enough.
>
> Yes, collision is not the problem, it's that you can't distinguish them
> without a lookup table or something.  Which means we have to do more
> than just change the URL in the existing linkifier, which was my point.

In the specific case of Roundup, does the linkifier have the "date of
comment" info available? If so, it could fairly readily assume that
hashes prior to the cutover date are hg ones, and later ones are for
git.

Cheers,
Nick.

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

From ezio.melotti at gmail.com  Tue Jan  5 01:04:30 2016
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Tue, 5 Jan 2016 08:04:30 +0200
Subject: [python-committers] We will be moving to GitHub (hopefully) in
 2016
In-Reply-To: <CADiSq7eZBWCUadjFsSzsKceXH2s+bRDLmSihgd14DtHZE4Yoxg@mail.gmail.com>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
 <CAF-Rda-XaGtidGsWi1aCOtdpqodDttcc8kiCukJAdv8xz7_ghw@mail.gmail.com>
 <CAP1=2W6nY3Qc4NCdqeyj5mJ=tr=rGo-0HsBO8qE4KFSv0t9e3w@mail.gmail.com>
 <20160104203353.034FCB1408D@webabinitio.net>
 <CAGE7PNLSrd6oaidnXkBOh8zyrfu0+GtFLYJEYuoH0D1eqOHpYQ@mail.gmail.com>
 <20160105013340.34A2EB1408D@webabinitio.net>
 <CADiSq7eZBWCUadjFsSzsKceXH2s+bRDLmSihgd14DtHZE4Yoxg@mail.gmail.com>
Message-ID: <CACBhJdGYeE8CzChnO1r+7tojiD9hxZoq_8j2MD7HMcOkpoHgzQ@mail.gmail.com>

On Tue, Jan 5, 2016 at 7:38 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 5 January 2016 at 11:33, R. David Murray <rdmurray at bitdance.com> wrote:
>> On Tue, 05 Jan 2016 01:26:58 +0000, "Gregory P. Smith" <greg at krypto.org> wrote:
>>> On Mon, Jan 4, 2016 at 12:34 PM R. David Murray <rdmurray at bitdance.com>
>>> wrote:
>>>
>>> > to have to do some extra work to make the hash links work in the bug
>>> > tracker, since I don't think there's any a priori way to distinguish
>>> > between hg hashes and git hashes.
>>> >
>>>
>>> Just ignore the remote possibility of short 32-bit hash prefix collisions
>>> (possible, but infrequent): the way to resolve that is when a hash lookup
>>> fails, to look it up in a translation index of former hg hashes.
>>>  practical.  good enough.
>>
>> Yes, collision is not the problem, it's that you can't distinguish them
>> without a lookup table or something.  Which means we have to do more
>> than just change the URL in the existing linkifier, which was my point.
>
> In the specific case of Roundup, does the linkifier have the "date of
> comment" info available? If so, it could fairly readily assume that
> hashes prior to the cutover date are hg ones, and later ones are for
> git.

By looking at the code I don't see it readily available, but it might
be possible to retrieve it somehow.
However I think it's better to keep the linkifier simple and stupid
and just delegate to https://hg.python.org/lookup/ .

Best Regards,
Ezio Melotti

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

From storchaka at gmail.com  Tue Jan  5 01:35:28 2016
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Tue, 05 Jan 2016 08:35:28 +0200
Subject: [python-committers] We will be moving to GitHub (hopefully) in
 2016
In-Reply-To: <CAF-Rda-XaGtidGsWi1aCOtdpqodDttcc8kiCukJAdv8xz7_ghw@mail.gmail.com>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
 <CAF-Rda-XaGtidGsWi1aCOtdpqodDttcc8kiCukJAdv8xz7_ghw@mail.gmail.com>
Message-ID: <2282712.qxIC7vsNHV@raxxla>

?????????, 04-???-2016 09:49:57 Eli Bendersky ????????:
> I suppose you'll want to use https://github.com/python/cpython, which I'm
> currently maintaining as a read-only mirror. Let me know when you want to
> take control of that repo - I think since it belongs to the "python" Github
> org already, it should be easy to do.
> 
> I have to admit that I'm not a big expert on Mercurial --> Git converters
> and the way I maintain this mirror may not be the best approach, so I
> encourage you folks to find a VCS guru to look into this for the "real"
> transition.

I heard there is a problem with lost tags in this mirror:

https://github.com/python/cpython/pull/15


From senthil at uthcode.com  Tue Jan  5 01:36:24 2016
From: senthil at uthcode.com (Senthil Kumaran)
Date: Mon, 4 Jan 2016 22:36:24 -0800
Subject: [python-committers] We will be moving to GitHub (hopefully)
 in2016
In-Reply-To: <CAP1=2W52pjOyL5pkji79qEwTHXqDQ6MoRW0q4JH83U9o_RzvpA@mail.gmail.com>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
 <CAF-Rda-XaGtidGsWi1aCOtdpqodDttcc8kiCukJAdv8xz7_ghw@mail.gmail.com>
 <CAP1=2W6nY3Qc4NCdqeyj5mJ=tr=rGo-0HsBO8qE4KFSv0t9e3w@mail.gmail.com>
 <20160104203353.034FCB1408D@webabinitio.net>
 <E1aGCMf-0007Dh-AF@se2-syd.hostedmail.net.au>
 <CAP1=2W4pZtA3RqpAeNLanHGzR_ZfQQS3xUox7XaSd2XCuANiiA@mail.gmail.com>
 <FEF41E6B-54B3-4D74-AC23-0C040EDDEFEE@stufft.io>
 <CAP1=2W7-qc3vN7gy5zDoH3E1wQCgd78hq3vGbBhyo8XM5BNcDw@mail.gmail.com>
 <C236DC7C-97DE-47E1-8926-31AF792CE681@stufft.io>
 <CAP7+vJLDMOiFduGtk3uf6K3_arUTo_2Wq+a_Snkggi8KdNPHHw@mail.gmail.com>
 <CAP1=2W52pjOyL5pkji79qEwTHXqDQ6MoRW0q4JH83U9o_RzvpA@mail.gmail.com>
Message-ID: <CAPOVWOTV2=kXfPjZ-K-42BCWyrR6v_OugUvE72yJj2S-g1=9fg@mail.gmail.com>

On Mon, Jan 4, 2016 at 2:56 PM, Brett Cannon <brett at python.org> wrote:

> I'm not sure, which is why I'm asking what difference it would make if we
> separated out Python 2 branches into their own clone from Python 3 branches.


Irrespective of the size difference, separating Python2 repo from Python3
repo might be a good idea. It will help in reviewing patches and
concentrating on Python 3 more.
As a side effect, since GitHub is used by many developers, if we get many
pull requests (or patches) against python 2 only, we will know about this
from community participation.

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

From storchaka at gmail.com  Tue Jan  5 01:44:34 2016
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Tue, 05 Jan 2016 08:44:34 +0200
Subject: [python-committers] We will be moving to GitHub (hopefully)
 in2016
In-Reply-To: <CAP1=2W7-qc3vN7gy5zDoH3E1wQCgd78hq3vGbBhyo8XM5BNcDw@mail.gmail.com>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
 <FEF41E6B-54B3-4D74-AC23-0C040EDDEFEE@stufft.io>
 <CAP1=2W7-qc3vN7gy5zDoH3E1wQCgd78hq3vGbBhyo8XM5BNcDw@mail.gmail.com>
Message-ID: <4003250.hO5eoxSa0x@raxxla>

?????????, 04-???-2016 21:18:39 Brett Cannon ????????:
> On Mon, 4 Jan 2016 at 13:14 Donald Stufft <donald at stufft.io> wrote:
> > On Jan 4, 2016, at 4:11 PM, Brett Cannon <brett at python.org> wrote:
> > It?s pretty easy to migrate the entire history (at least what?s in Hg)
> > including all branches and tags.
> 
> It's not about the difficulty as the size of the clone. E.g., if we make
> Python 2 a separate repo does it buy us a lot of space savings (we need to
> remember not everyone has broadband, so there is some potential balance to
> be had between history vs. clone size)?

Please keep the full history. I often need it to search the source of the 
problem. The full history helps to find the original intention of the code, 
involved people and related discussions. A nation that forgets its past has no 
future.

From storchaka at gmail.com  Tue Jan  5 01:59:44 2016
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Tue, 05 Jan 2016 08:59:44 +0200
Subject: [python-committers] We will be moving to GitHub (hopefully) in
 2016
In-Reply-To: <20160104203353.034FCB1408D@webabinitio.net>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
 <CAP1=2W6nY3Qc4NCdqeyj5mJ=tr=rGo-0HsBO8qE4KFSv0t9e3w@mail.gmail.com>
 <20160104203353.034FCB1408D@webabinitio.net>
Message-ID: <76423167.53tLd9kano@raxxla>

?????????, 04-???-2016 15:33:51 R. David Murray ????????:
> (Oh, and let me mention this while I'm thinking about it: we're going
> to have to do some extra work to make the hash links work in the bug
> tracker, since I don't think there's any a priori way to distinguish
> between hg hashes and git hashes.)

Is it possible to keep the same hashes in both Mercurial and Git?
Or at least the same short hashes?

From g.brandl at gmx.net  Tue Jan  5 02:24:27 2016
From: g.brandl at gmx.net (Georg Brandl)
Date: Tue, 5 Jan 2016 08:24:27 +0100
Subject: [python-committers] We will be moving to GitHub (hopefully) in
 2016
In-Reply-To: <CAFRnB2UQ2a+pU0chDy0ikbGagMft5OwW5pyRAw0EcRRqPeBV=w@mail.gmail.com>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
 <n6es9i$1d0$1@ger.gmane.org>
 <CAFRnB2UQ2a+pU0chDy0ikbGagMft5OwW5pyRAw0EcRRqPeBV=w@mail.gmail.com>
Message-ID: <n6fr3b$o16$1@ger.gmane.org>

This is now a moot point, but with generaldelta (active by default in hg 3.7)
the hg clone size is at around 400 MB.

Georg

On 01/04/2016 11:53 PM, Alex Gaynor wrote:
> My git clone is 350MB (after a make clean), a fresh hg clone is 650MB.
> 
> Alex
> 
> On Mon, Jan 4, 2016 at 5:38 PM, Georg Brandl <g.brandl at gmx.net
> <mailto:g.brandl at gmx.net>> wrote:
> 
>     On 01/01/2016 08:24 PM, Brett Cannon wrote:
>     > If you want to read the reasons I chose GitHub over GitLab,
>     > see https://mail.python.org/pipermail/core-workflow/2016-January/000345.html .
>     > If you want to discuss the decision or help with the transition, please
>     > subscribe to the core-workflow mailing list.
>     >
>     > Happy 2016 everyone, and here is to hoping we will have an easier developer
>     > workflow by the end of this year!
> 
>     Thanks for pioneering all the work and discussion needed to come to this
>     decision.
> 
>     I think that in combination with a homu-style bot we can get a very nice
>     improved workflow going.
> 
>     Georg



From larry at hastings.org  Tue Jan 12 00:45:34 2016
From: larry at hastings.org (Larry Hastings)
Date: Mon, 11 Jan 2016 21:45:34 -0800
Subject: [python-committers] We will be moving to GitHub (hopefully) in
 2016
In-Reply-To: <76423167.53tLd9kano@raxxla>
References: <CAP1=2W6sfgoyB4=DKMaS7OBR6H2kyPff74dxGcBAfww0OVHCyA@mail.gmail.com>
 <CAP1=2W6nY3Qc4NCdqeyj5mJ=tr=rGo-0HsBO8qE4KFSv0t9e3w@mail.gmail.com>
 <20160104203353.034FCB1408D@webabinitio.net> <76423167.53tLd9kano@raxxla>
Message-ID: <569492FE.3030605@hastings.org>



On 01/04/2016 10:59 PM, Serhiy Storchaka wrote:
> Is it possible to keep the same hashes in both Mercurial and Git? Or 
> at least the same short hashes?

tl;dr: it's impossible.

The hash is a SHA1 of the revision's "manifest", which contains all the 
metadata about the revision.  To preserve the Mercurial hashes would 
mean doing something vile like rewriting these hashes after populating 
the repo.  If this worked at all, it would be terribly fragile; my guess 
is that many git commands (e.g. "git fsck") would notice and view it as 
damage.

The short hashes are simply the unique leading part of the hash, so they 
would only be preserved if we could preserve the full hashes.


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

From steve.dower at python.org  Thu Jan 21 11:40:15 2016
From: steve.dower at python.org (Steve Dower)
Date: Thu, 21 Jan 2016 08:40:15 -0800
Subject: [python-committers] New Authenticode certificate
Message-ID: <56A109EF.5000704@python.org>

(I forget exactly who to contact about the certificate, so I'm going 
slightly more broad.)

The PSF's certificate we use to sign binaries and the installer for 
Windows is a SHA-1 certificate, which has been deprecated as of the 
start of the year: http://aka.ms/sha1

Already Windows may warn about the certificate on our current and past 
releases, but because the signature is timestamped prior to 01Jan2016 it 
will not be blocked. However, our next releases will be blocked (with a 
bypass available) unless we update the certificate to SHA-2.

Some sources have suggested that CAs will provide a SHA-2 certificate 
for free on request.

Supporting Windows Vista and Windows Server 2008 appears to be 
complicated, according to the link I gave above. I want to test the 
effect of only signing with SHA-2 on those platforms and make a 
recommendation based on that, rather than trying to guess what will 
happen (those OSs did not block downloaded files as aggressively as 
Windows 7+).

Happy to take this off list once I know who handles this certificate.

Cheers,
Steve

From mal at egenix.com  Thu Jan 21 13:31:46 2016
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 21 Jan 2016 19:31:46 +0100
Subject: [python-committers] New Authenticode certificate
In-Reply-To: <56A109EF.5000704@python.org>
References: <56A109EF.5000704@python.org>
Message-ID: <56A12412.3060406@egenix.com>

On 21.01.2016 17:40, Steve Dower wrote:
> (I forget exactly who to contact about the certificate, so I'm going slightly more broad.)
> 
> The PSF's certificate we use to sign binaries and the installer for Windows is a SHA-1 certificate,
> which has been deprecated as of the start of the year: http://aka.ms/sha1
> 
> Already Windows may warn about the certificate on our current and past releases, but because the
> signature is timestamped prior to 01Jan2016 it will not be blocked. However, our next releases will
> be blocked (with a bypass available) unless we update the certificate to SHA-2.
> 
> Some sources have suggested that CAs will provide a SHA-2 certificate for free on request.
> 
> Supporting Windows Vista and Windows Server 2008 appears to be complicated, according to the link I
> gave above. I want to test the effect of only signing with SHA-2 on those platforms and make a
> recommendation based on that, rather than trying to guess what will happen (those OSs did not block
> downloaded files as aggressively as Windows 7+).
> 
> Happy to take this off list once I know who handles this certificate.

I'm the one who handles the PSF StartSSL account and yes,
they also do code signing certificates.

I'd suggest to take this offlist.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Jan 21 2016)
>>> 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 steve.dower at python.org  Thu Jan 21 14:42:35 2016
From: steve.dower at python.org (Steve Dower)
Date: Thu, 21 Jan 2016 11:42:35 -0800
Subject: [python-committers] New Authenticode certificate
In-Reply-To: <56A12412.3060406@egenix.com>
References: <56A109EF.5000704@python.org> <56A12412.3060406@egenix.com>
Message-ID: <56A134AB.107@python.org>

On 21Jan2016 1031, M.-A. Lemburg wrote:
> I'm the one who handles the PSF StartSSL account and yes,
> they also do code signing certificates.

Did they provide our current certificate? The root CA is VeriSign, not 
StartCom.

I have no particular issue with changing CA, but I really don't want 
multiple PSF-labelled code signing certificates floating around out there.


From victor.stinner at gmail.com  Fri Jan 22 03:24:31 2016
From: victor.stinner at gmail.com (Victor Stinner)
Date: Fri, 22 Jan 2016 09:24:31 +0100
Subject: [python-committers] push to devguide: "abort: authorization failed"
Message-ID: <CAMpsgwbYQG3cU5Me1p_7yBHet44u3_WBUQOoB9dqcOjHcAWN3g@mail.gmail.com>

Hi,

I wanted to fix a small typo in the devguide, but I'm unable to push
this morning.


haypo at smithers$ hg push --debug
pushing to https://hg.python.org/devguide/
using https://hg.python.org/devguide/
sending capabilities command
hg.python.org certificate successfully verified
query 1; heads
sending batch command
searching for changes
all remote heads known locally
preparing listkeys for "phases"
sending listkeys command
received listkey for "phases": 15 bytes
checking for updated bookmarks
preparing listkeys for "bookmarks"
sending listkeys command
received listkey for "bookmarks": 0 bytes
sending branchmap command
sending branchmap command
preparing listkeys for "bookmarks"
sending listkeys command
received listkey for "bookmarks": 0 bytes
1 changesets found
list of changesets:
c7152e1accf8fae0037dbdd8221956f6f141219e
bundle2-output-bundle: "HG20", 4 parts total
bundle2-output-part: "replycaps" 155 bytes payload
bundle2-output-part: "check:heads" streamed payload
bundle2-output-part: "changegroup" (params: 1 mandatory) streamed payload
bundle2-output-part: "pushkey" (params: 4 mandatory) empty payload
sending unbundle command
sending 1073 bytes
abort: authorization failed
haypo at smithers$ hg path
default = https://hg.python.org/devguide/

From victor.stinner at gmail.com  Fri Jan 22 03:26:49 2016
From: victor.stinner at gmail.com (Victor Stinner)
Date: Fri, 22 Jan 2016 09:26:49 +0100
Subject: [python-committers] push to devguide: "abort: authorization
 failed"
In-Reply-To: <CAMpsgwbYQG3cU5Me1p_7yBHet44u3_WBUQOoB9dqcOjHcAWN3g@mail.gmail.com>
References: <CAMpsgwbYQG3cU5Me1p_7yBHet44u3_WBUQOoB9dqcOjHcAWN3g@mail.gmail.com>
Message-ID: <CAMpsgwYBusxX1-wFMDB7cskCfNThNBZS5yorc+vp34Vyo199zA@mail.gmail.com>

Sorry for the noise, I used the wrong URL for the repository. In fact,
the last time that I pushed a change, it was on another computer, so I
was confused.

I should use ssh://hg at hg.python.org/devguide to push ;-)

Victor

2016-01-22 9:24 GMT+01:00 Victor Stinner <victor.stinner at gmail.com>:
> Hi,
>
> I wanted to fix a small typo in the devguide, but I'm unable to push
> this morning.
>
>
> haypo at smithers$ hg push --debug
> pushing to https://hg.python.org/devguide/
> using https://hg.python.org/devguide/
> sending capabilities command
> hg.python.org certificate successfully verified
> query 1; heads
> sending batch command
> searching for changes
> all remote heads known locally
> preparing listkeys for "phases"
> sending listkeys command
> received listkey for "phases": 15 bytes
> checking for updated bookmarks
> preparing listkeys for "bookmarks"
> sending listkeys command
> received listkey for "bookmarks": 0 bytes
> sending branchmap command
> sending branchmap command
> preparing listkeys for "bookmarks"
> sending listkeys command
> received listkey for "bookmarks": 0 bytes
> 1 changesets found
> list of changesets:
> c7152e1accf8fae0037dbdd8221956f6f141219e
> bundle2-output-bundle: "HG20", 4 parts total
> bundle2-output-part: "replycaps" 155 bytes payload
> bundle2-output-part: "check:heads" streamed payload
> bundle2-output-part: "changegroup" (params: 1 mandatory) streamed payload
> bundle2-output-part: "pushkey" (params: 4 mandatory) empty payload
> sending unbundle command
> sending 1073 bytes
> abort: authorization failed
> haypo at smithers$ hg path
> default = https://hg.python.org/devguide/

From mal at egenix.com  Fri Jan 22 04:44:19 2016
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 22 Jan 2016 10:44:19 +0100
Subject: [python-committers] New Authenticode certificate
In-Reply-To: <56A134AB.107@python.org>
References: <56A109EF.5000704@python.org> <56A12412.3060406@egenix.com>
 <56A134AB.107@python.org>
Message-ID: <56A1F9F3.7010504@egenix.com>

On 21.01.2016 20:42, Steve Dower wrote:
> On 21Jan2016 1031, M.-A. Lemburg wrote:
>> I'm the one who handles the PSF StartSSL account and yes,
>> they also do code signing certificates.
> 
> Did they provide our current certificate? The root CA is VeriSign, not StartCom.
> 
> I have no particular issue with changing CA, but I really don't want multiple PSF-labelled code
> signing certificates floating around out there.

We have switched to StartSSL for most of our certificate needs.
Some certs are also created using Gandi (for a few
externally hosted python.org subdomains) or Digicert (for
fastly cached domains):

https://wiki.python.org/psf/PSF%20SSL%20Certificates
(you need a PSF wiki login to view the page)

The older Verisign ones were from before the PSF attempted to
centralize the certificate management.

I'll send you the instructions on how to create a CSR for the
cert offlist.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Jan 22 2016)
>>> 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 ezio.melotti at gmail.com  Fri Jan 29 12:11:24 2016
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Fri, 29 Jan 2016 19:11:24 +0200
Subject: [python-committers] Deprecation Policy PEP
Message-ID: <CACBhJdEat8gg8QqMA2frF=pKo8CondW-SjgGTAK4+-27nnrYhA@mail.gmail.com>

Hi,
in the past I suggested to document our deprecation policy on a PEP.
Since the issue came up again on a few issues on the tracker and on
#python-dev, I adapted the content of my previous email and wrote a
PEP.

Attached you can find the full text, including references to the
previous discussions on python-dev and related issues.

Best Regards,
Ezio Melotti

---------

PEP: XXX
Title: Deprecation Policy
Version: $Revision$
Last-Modified: $Date$
Author: Ezio Melotti <ezio.melotti at gmail.com>
Status: Draft
Type: Process
Content-Type: text/x-rst
Created: 29-Jan-2016
Post-History:


Abstract
========

The goal of this PEP is to document when and how to deprecate
APIs in the Python language and in the standard library.


Rationale
=========

Python doesn't currently have a documented policy regarding
deprecations.  This leads to repeated discussions and
inconsistencies in how we handle and document deprecations
[#]_ [#]_ [#]_ [#]_ [#]_ [#]_ [#]_.


What and when to deprecate
==========================

* An API can be deprecated if a better alternative exists, if the
  implementation is incorrect or obsolete, or if the name or module
  has been changed.  If possible, an alternative should be provided.
* If the API is public, it must go through the deprecation
  process.  If the API is private or provisional, it might.
* The number of releases before an API is removed is decided
  on a case-by-case basis depending on widely used the API is,
  in which Python versions the alternative is available, which
  Python versions are currently supported by different operating
  systems, distros, and projects, and how easy it is to replace
  the API.
* In general it's better to be conservative, and if the API is
  deprecated in ``3.X``, it shouldn't be removed before ``3.X+2``.
  This should also take into account which Python versions are
  currently .


Porting from 2.x to 3.x
-----------------------

Some APIs that are available in Python 2.7 might get deprecated
in Python 3, and people that upgrade directly from 2.7 to 3.X might
not see any warnings.

In order to make porting code to 3.X easier:

* nothing that is available and not deprecated in 2.7 should be
  removed from Python 3 as long as 2.7 is officially supported;
* deprecation warnings can be backported to 2.7 and enabled
  using the ``-3`` flag;


Deprecation Warnings
====================

Python offers two kinds of deprecation warnings:

* ``PendingDeprecationWarning``
* ``DeprecationWarning``

Initially, only ``PendingDeprecationWarning``\ s were silenced by
default.  Starting from Python 2.7, ``DeprecationWarning``\ s
are also silenced by default [#]_ [#]_.

Since this distinction is no longer true:

* ``PendingDeprecationWarning`` should not be used
* ``DeprecationWarning`` will be used for all deprecations

``PendingDeprecationWarning`` won't be removed, and 3rd-party
projects are allowed to use it as they see fit.


Deprecation Progression
=======================

In the past, the following deprecation progression has been used:

1. in release ``3.X`` a ``PendingDeprecationWarning`` is added
2. in release ``3.X+1`` it becomes a ``DeprecationWarning``
3. in release ``3.X+2`` the API is removed

The warning were occasionally left for more than one release,
either intentionally or because no one remembered to update them.

Since ``PendingDeprecationWarning`` should no longer be used, this
can be simplified to:

1. in release ``3.X`` a ``DeprecationWarning`` is added
2. in release ``3.X+N`` the API is removed

``N`` can be ``>=1``, should be decided beforehand, and should be
documented explicitly.


Deprecation Process
===================

These are the steps required to deprecate and remove an API:

1. propose to deprecate an API on a tracker issue or on python-dev
   and decide in which version it will be removed.

2. attach to the issue a patch to deprecate the API that:

  * adds a ``DeprecationWarning`` to the code
  * adds the deprecation to the documentation
  * adds a test to verify that the warning is raised
  * possibly updates code/examples that uses the deprecated API

3. after review, apply the patch to the current in-development
   branch and close the issue.

4. attach to a separate issue a patch to remove the API that:

  * removes the API and the warning
  * removes the tests for the API and for the deprecation
  * removes the API documentation

5. once the designated branch is available, apply the patch and
   close the issue.


Deprecation Messages
====================

When a deprecated API is used, a ``DeprecationWarning`` should
be raised.  The message should mention that the API is
deprecated, and if possible it should indicate when it will be
removed and what should be used instead.

These messages are intended for developers, and are therefore
hidden by default to prevent end-users to see them.

These messages should be enabled by default in places where only
developers will see them, such as tests [#]_ and in the interactive
interpreter [#]_.


Documenting the deprecations
============================

* All deprecations should be documented in the docs, using the
  ``deprecated-removed`` directive.
* If an alternative is available, it should be mentioned, possibly
  including examples.
* Each "what's new" document should include either a section or a
  link to a separate document [#]_ listing all the new deprecations,
  the APIs that have been removed and possibly the planned
  removals for the upcoming releases.  This could be generated
  automatically with Sphinx.
* Simply removing the documentation for deprecated APIs is
  not acceptable, since people that see the API used in the
  code won't know if they can still use the API or not.


Deprecation warnings rendering
------------------------------

On one hand deprecation warnings should be clearly visible, on the
other hand we want to avoid riddling the docs with red boxes [#]_.

In order to find a balance between the two:

* Individual functions/methods/attributes should have a label next
  to the name to indicate the deprecation, and a more verbose
  description underneath.  The label will be red, the description
  doesn't have to [#]_.
* Modules and classes can use a red warning box.  If the
  documentation spans more than a single screen of text, additional
  warning labels can be added to the individual functions/methods.
* Links to deprecated objects should be marked differently.

This will require some tweak to the ``deprecated-removed``
directive, in order to produce different CSS classes for
modules/classes, functions/methods/attributes, and links.


Updating deprecated code
========================

As mentioned above, the error messages and documentation should
provide an alternative whenever possible.  When the alternative
is not straightforward, more complex examples or a new section
can added to the documentation to explain how to convert the code.

Another option is to write scripts that can automatically update
Python code to use the new alternative.  This requires:

1. writing a 3to3 tool similar to (and possibly based on) 2to3;
2. documenting clearly its API and providing several examples;
3. providing fixers for deprecated APIs that can be used to
   automatically update deprecated code;

This can be done as a GSoC project, and if done correctly, it will
provide an easy way for people to upgrade their codebases.


See also
========

* :pep:`387` -- Backwards Compatibility Policy
* :pep:`4` -- Deprecation of Standard Modules


References
==========

.. [#] Deprecation Policy
   (https://mail.python.org/pipermail/python-dev/2011-October/114199.html)

.. [#] Deprecation Policy
   (https://mail.python.org/pipermail/python-dev/2014-January/132069.html)

.. [#] deprecated in 3.2/3.3, should be removed in 3.5 or ???
   (https://bugs.python.org/issue13248)

.. [#] DeprecationWarning for PEP 479 (generator_stop)
   (http://bugs.python.org/issue26136)

.. [#] Deprecate threading.Thread.isDaemon etc
   (http://bugs.python.org/issue24203)

.. [#] Remove the Deprecated API in trace module
   (http://bugs.python.org/issue26069)

.. [#] Resurrect inspect.getargspec() in 3.6
   (http://bugs.python.org/issue25486)

.. [#] What's New in Python 2.7 -- Changes to the Handling of
   Deprecation Warnings (https://docs.python.org/3/whatsnew/2.7.html)

.. [#] Silence DeprecationWarning by default
   (https://bugs.python.org/issue7319)

.. [#] Enable warnings by default in unittest
   (https://bugs.python.org/issue10535)

.. [#] DeprecationWarnings should be visible by default in the
   interactive REPL (https://bugs.python.org/issue24294)

.. [#] Django has a "Django Deprecation Timeline" page
   (https://docs.djangoproject.com/en/dev/internals/deprecation/)

.. [#] Consistent documentation practices for security concerns
   and considerations (https://bugs.python.org/issue13515)

.. [#] Put "deprecated" warnings first
   (http://bugs.python.org/issue25467)


Copyright
=========

This document has been placed in the public domain.

From senthil at uthcode.com  Fri Jan 29 12:33:50 2016
From: senthil at uthcode.com (Senthil Kumaran)
Date: Fri, 29 Jan 2016 09:33:50 -0800
Subject: [python-committers] Deprecation Policy PEP
In-Reply-To: <CACBhJdEat8gg8QqMA2frF=pKo8CondW-SjgGTAK4+-27nnrYhA@mail.gmail.com>
References: <CACBhJdEat8gg8QqMA2frF=pKo8CondW-SjgGTAK4+-27nnrYhA@mail.gmail.com>
Message-ID: <CAPOVWORWuaD72C-G-8gO5n9T5DUn_qNuhJ5KsSyUwD68P0D01A@mail.gmail.com>

+1 to this proposal. I reviewed the contents and I feel it is comprehensive.

It should be easy to follow for any deprecations. Also, we should give some
examples of how
the deprecated-removed directive will be used.

Since our policy itself is very subjective (for good reasons), I propose
that we be little rigorous in
documenting or implementing it. By that I mean.

.. deprecated-removed:

1. Should provide a) since and b) removed versions. It does it today.
2. Clarify what `versionmodified` option means. i don't know or can't
figure out in relation to point 1.
3. Provide alternative option for deprecated-removed directive. This is
going to be immensely helpful if folks are concerned with 2 to 3 migration
and will be eager to adopt the approach suggested by the documentation. We
don't do this today. This point is worth discussing.

-- 
Senthil




On Fri, Jan 29, 2016 at 9:11 AM, Ezio Melotti <ezio.melotti at gmail.com>
wrote:

> Hi,
> in the past I suggested to document our deprecation policy on a PEP.
> Since the issue came up again on a few issues on the tracker and on
> #python-dev, I adapted the content of my previous email and wrote a
> PEP.
>
> Attached you can find the full text, including references to the
> previous discussions on python-dev and related issues.
>
> Best Regards,
> Ezio Melotti
>
> ---------
>
> PEP: XXX
> Title: Deprecation Policy
> Version: $Revision$
> Last-Modified: $Date$
> Author: Ezio Melotti <ezio.melotti at gmail.com>
> Status: Draft
> Type: Process
> Content-Type: text/x-rst
> Created: 29-Jan-2016
> Post-History:
>
>
> Abstract
> ========
>
> The goal of this PEP is to document when and how to deprecate
> APIs in the Python language and in the standard library.
>
>
> Rationale
> =========
>
> Python doesn't currently have a documented policy regarding
> deprecations.  This leads to repeated discussions and
> inconsistencies in how we handle and document deprecations
> [#]_ [#]_ [#]_ [#]_ [#]_ [#]_ [#]_.
>
>
> What and when to deprecate
> ==========================
>
> * An API can be deprecated if a better alternative exists, if the
>   implementation is incorrect or obsolete, or if the name or module
>   has been changed.  If possible, an alternative should be provided.
> * If the API is public, it must go through the deprecation
>   process.  If the API is private or provisional, it might.
> * The number of releases before an API is removed is decided
>   on a case-by-case basis depending on widely used the API is,
>   in which Python versions the alternative is available, which
>   Python versions are currently supported by different operating
>   systems, distros, and projects, and how easy it is to replace
>   the API.
> * In general it's better to be conservative, and if the API is
>   deprecated in ``3.X``, it shouldn't be removed before ``3.X+2``.
>   This should also take into account which Python versions are
>   currently .
>
>
> Porting from 2.x to 3.x
> -----------------------
>
> Some APIs that are available in Python 2.7 might get deprecated
> in Python 3, and people that upgrade directly from 2.7 to 3.X might
> not see any warnings.
>
> In order to make porting code to 3.X easier:
>
> * nothing that is available and not deprecated in 2.7 should be
>   removed from Python 3 as long as 2.7 is officially supported;
> * deprecation warnings can be backported to 2.7 and enabled
>   using the ``-3`` flag;
>
>
> Deprecation Warnings
> ====================
>
> Python offers two kinds of deprecation warnings:
>
> * ``PendingDeprecationWarning``
> * ``DeprecationWarning``
>
> Initially, only ``PendingDeprecationWarning``\ s were silenced by
> default.  Starting from Python 2.7, ``DeprecationWarning``\ s
> are also silenced by default [#]_ [#]_.
>
> Since this distinction is no longer true:
>
> * ``PendingDeprecationWarning`` should not be used
> * ``DeprecationWarning`` will be used for all deprecations
>
> ``PendingDeprecationWarning`` won't be removed, and 3rd-party
> projects are allowed to use it as they see fit.
>
>
> Deprecation Progression
> =======================
>
> In the past, the following deprecation progression has been used:
>
> 1. in release ``3.X`` a ``PendingDeprecationWarning`` is added
> 2. in release ``3.X+1`` it becomes a ``DeprecationWarning``
> 3. in release ``3.X+2`` the API is removed
>
> The warning were occasionally left for more than one release,
> either intentionally or because no one remembered to update them.
>
> Since ``PendingDeprecationWarning`` should no longer be used, this
> can be simplified to:
>
> 1. in release ``3.X`` a ``DeprecationWarning`` is added
> 2. in release ``3.X+N`` the API is removed
>
> ``N`` can be ``>=1``, should be decided beforehand, and should be
> documented explicitly.
>
>
> Deprecation Process
> ===================
>
> These are the steps required to deprecate and remove an API:
>
> 1. propose to deprecate an API on a tracker issue or on python-dev
>    and decide in which version it will be removed.
>
> 2. attach to the issue a patch to deprecate the API that:
>
>   * adds a ``DeprecationWarning`` to the code
>   * adds the deprecation to the documentation
>   * adds a test to verify that the warning is raised
>   * possibly updates code/examples that uses the deprecated API
>
> 3. after review, apply the patch to the current in-development
>    branch and close the issue.
>
> 4. attach to a separate issue a patch to remove the API that:
>
>   * removes the API and the warning
>   * removes the tests for the API and for the deprecation
>   * removes the API documentation
>
> 5. once the designated branch is available, apply the patch and
>    close the issue.
>
>
> Deprecation Messages
> ====================
>
> When a deprecated API is used, a ``DeprecationWarning`` should
> be raised.  The message should mention that the API is
> deprecated, and if possible it should indicate when it will be
> removed and what should be used instead.
>
> These messages are intended for developers, and are therefore
> hidden by default to prevent end-users to see them.
>
> These messages should be enabled by default in places where only
> developers will see them, such as tests [#]_ and in the interactive
> interpreter [#]_.
>
>
> Documenting the deprecations
> ============================
>
> * All deprecations should be documented in the docs, using the
>   ``deprecated-removed`` directive.
> * If an alternative is available, it should be mentioned, possibly
>   including examples.
> * Each "what's new" document should include either a section or a
>   link to a separate document [#]_ listing all the new deprecations,
>   the APIs that have been removed and possibly the planned
>   removals for the upcoming releases.  This could be generated
>   automatically with Sphinx.
> * Simply removing the documentation for deprecated APIs is
>   not acceptable, since people that see the API used in the
>   code won't know if they can still use the API or not.
>
>
> Deprecation warnings rendering
> ------------------------------
>
> On one hand deprecation warnings should be clearly visible, on the
> other hand we want to avoid riddling the docs with red boxes [#]_.
>
> In order to find a balance between the two:
>
> * Individual functions/methods/attributes should have a label next
>   to the name to indicate the deprecation, and a more verbose
>   description underneath.  The label will be red, the description
>   doesn't have to [#]_.
> * Modules and classes can use a red warning box.  If the
>   documentation spans more than a single screen of text, additional
>   warning labels can be added to the individual functions/methods.
> * Links to deprecated objects should be marked differently.
>
> This will require some tweak to the ``deprecated-removed``
> directive, in order to produce different CSS classes for
> modules/classes, functions/methods/attributes, and links.
>
>
> Updating deprecated code
> ========================
>
> As mentioned above, the error messages and documentation should
> provide an alternative whenever possible.  When the alternative
> is not straightforward, more complex examples or a new section
> can added to the documentation to explain how to convert the code.
>
> Another option is to write scripts that can automatically update
> Python code to use the new alternative.  This requires:
>
> 1. writing a 3to3 tool similar to (and possibly based on) 2to3;
> 2. documenting clearly its API and providing several examples;
> 3. providing fixers for deprecated APIs that can be used to
>    automatically update deprecated code;
>
> This can be done as a GSoC project, and if done correctly, it will
> provide an easy way for people to upgrade their codebases.
>
>
> See also
> ========
>
> * :pep:`387` -- Backwards Compatibility Policy
> * :pep:`4` -- Deprecation of Standard Modules
>
>
> References
> ==========
>
> .. [#] Deprecation Policy
>    (https://mail.python.org/pipermail/python-dev/2011-October/114199.html)
>
> .. [#] Deprecation Policy
>    (https://mail.python.org/pipermail/python-dev/2014-January/132069.html)
>
> .. [#] deprecated in 3.2/3.3, should be removed in 3.5 or ???
>    (https://bugs.python.org/issue13248)
>
> .. [#] DeprecationWarning for PEP 479 (generator_stop)
>    (http://bugs.python.org/issue26136)
>
> .. [#] Deprecate threading.Thread.isDaemon etc
>    (http://bugs.python.org/issue24203)
>
> .. [#] Remove the Deprecated API in trace module
>    (http://bugs.python.org/issue26069)
>
> .. [#] Resurrect inspect.getargspec() in 3.6
>    (http://bugs.python.org/issue25486)
>
> .. [#] What's New in Python 2.7 -- Changes to the Handling of
>    Deprecation Warnings (https://docs.python.org/3/whatsnew/2.7.html)
>
> .. [#] Silence DeprecationWarning by default
>    (https://bugs.python.org/issue7319)
>
> .. [#] Enable warnings by default in unittest
>    (https://bugs.python.org/issue10535)
>
> .. [#] DeprecationWarnings should be visible by default in the
>    interactive REPL (https://bugs.python.org/issue24294)
>
> .. [#] Django has a "Django Deprecation Timeline" page
>    (https://docs.djangoproject.com/en/dev/internals/deprecation/)
>
> .. [#] Consistent documentation practices for security concerns
>    and considerations (https://bugs.python.org/issue13515)
>
> .. [#] Put "deprecated" warnings first
>    (http://bugs.python.org/issue25467)
>
>
> Copyright
> =========
>
> This document has been placed in the public domain.
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160129/b8a44aa9/attachment-0001.html>

From storchaka at gmail.com  Fri Jan 29 13:00:34 2016
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Fri, 29 Jan 2016 20:00:34 +0200
Subject: [python-committers] Deprecation Policy PEP
In-Reply-To: <CACBhJdEat8gg8QqMA2frF=pKo8CondW-SjgGTAK4+-27nnrYhA@mail.gmail.com>
References: <CACBhJdEat8gg8QqMA2frF=pKo8CondW-SjgGTAK4+-27nnrYhA@mail.gmail.com>
Message-ID: <n8g9c2$c8i$1@ger.gmane.org>

On 29.01.16 19:11, Ezio Melotti wrote:
> Deprecation Warnings
> ====================
>
> Python offers two kinds of deprecation warnings:
>
> * ``PendingDeprecationWarning``
> * ``DeprecationWarning``
>
> Initially, only ``PendingDeprecationWarning``\ s were silenced by
> default.  Starting from Python 2.7, ``DeprecationWarning``\ s
> are also silenced by default [#]_ [#]_.
>
> Since this distinction is no longer true:
>
> * ``PendingDeprecationWarning`` should not be used
> * ``DeprecationWarning`` will be used for all deprecations
>
> ``PendingDeprecationWarning`` won't be removed, and 3rd-party
> projects are allowed to use it as they see fit.

What about adding deprecations in bugfix releases? If current behavior 
is obviously incorrect and should be fixed in development branch, but 
this can break existing code that implicitly depends on current 
behavior. Can we add documentation-only warnings or use 
PendingDeprecationWarning if possible?

> Deprecation Process
> ===================
>
> These are the steps required to deprecate and remove an API:
>
> 1. propose to deprecate an API on a tracker issue or on python-dev
>     and decide in which version it will be removed.
>
> 2. attach to the issue a patch to deprecate the API that:
>
>    * adds a ``DeprecationWarning`` to the code

Some deprecation can be documentation-only.

May be worth to mention also ``FutureWarning``. AFAIK it is used if the 
method will not be removed in future, but it's behavior will be changed 
in incompatible way.

>    * adds the deprecation to the documentation

Needed explicit link to the "Documenting the deprecations" section.

>    * adds a test to verify that the warning is raised
>    * possibly updates code/examples that uses the deprecated API
>
> 3. after review, apply the patch to the current in-development
>     branch and close the issue.
>
> 4. attach to a separate issue a patch to remove the API that:
>
>    * removes the API and the warning
>    * removes the tests for the API and for the deprecation
>    * removes the API documentation
>
> 5. once the designated branch is available, apply the patch and
>     close the issue.

There is a special case for pickling. Existing pickle data created in 
old Python releases can contain references to deprecated classes or 
factory functions. Either we should keep old names (even non-public) as 
aliases to new names or add new mapping for 3 to 3 translation in 
_compat_pickle.py or new module.

> Documenting the deprecations
> ============================
>
> * All deprecations should be documented in the docs, using the
>    ``deprecated-removed`` directive.

When use ``deprecated`` and when use ``deprecated-removed``?



From brett at python.org  Fri Jan 29 13:11:27 2016
From: brett at python.org (Brett Cannon)
Date: Fri, 29 Jan 2016 18:11:27 +0000
Subject: [python-committers] Deprecation Policy PEP
In-Reply-To: <CAPOVWORWuaD72C-G-8gO5n9T5DUn_qNuhJ5KsSyUwD68P0D01A@mail.gmail.com>
References: <CACBhJdEat8gg8QqMA2frF=pKo8CondW-SjgGTAK4+-27nnrYhA@mail.gmail.com>
 <CAPOVWORWuaD72C-G-8gO5n9T5DUn_qNuhJ5KsSyUwD68P0D01A@mail.gmail.com>
Message-ID: <CAP1=2W6Vh3xr7erRSBqYu4MWtUht_LkMR2tmaQn3vnegu07=DA@mail.gmail.com>

On Fri, 29 Jan 2016 at 09:33 Senthil Kumaran <senthil at uthcode.com> wrote:

> +1 to this proposal. I reviewed the contents and I feel it is
> comprehensive.
>

+1 from me as well, especially once Serhiy's comments are addressed.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160129/5558101f/attachment.html>

From ezio.melotti at gmail.com  Fri Jan 29 14:56:55 2016
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Fri, 29 Jan 2016 21:56:55 +0200
Subject: [python-committers] Deprecation Policy PEP
In-Reply-To: <n8g9c2$c8i$1@ger.gmane.org>
References: <CACBhJdEat8gg8QqMA2frF=pKo8CondW-SjgGTAK4+-27nnrYhA@mail.gmail.com>
 <n8g9c2$c8i$1@ger.gmane.org>
Message-ID: <CACBhJdEeMuneri5Y+p93vKxQJ9A4cVgSkszEzRmkYZZwX6M_uA@mail.gmail.com>

On Fri, Jan 29, 2016 at 8:00 PM, Serhiy Storchaka <storchaka at gmail.com> wrote:
> On 29.01.16 19:11, Ezio Melotti wrote:
>>
>> Deprecation Warnings
>> ====================
>>
>> Python offers two kinds of deprecation warnings:
>>
>> * ``PendingDeprecationWarning``
>> * ``DeprecationWarning``
>>
>> Initially, only ``PendingDeprecationWarning``\ s were silenced by
>> default.  Starting from Python 2.7, ``DeprecationWarning``\ s
>> are also silenced by default [#]_ [#]_.
>>
>> Since this distinction is no longer true:
>>
>> * ``PendingDeprecationWarning`` should not be used
>> * ``DeprecationWarning`` will be used for all deprecations
>>
>> ``PendingDeprecationWarning`` won't be removed, and 3rd-party
>> projects are allowed to use it as they see fit.
>
>
> What about adding deprecations in bugfix releases? If current behavior is
> obviously incorrect and should be fixed in development branch, but this can
> break existing code that implicitly depends on current behavior. Can we add
> documentation-only warnings or use PendingDeprecationWarning if possible?
>

Usually deprecations are added in minor releases -- I don't know if we
added DeprecationWarnings in bugfix releases before.  Adding
documentation-only warnings in previous releases shouldn't be a
problem.  We already did this in the 2.7 docs for APIs that have been
deprecated/renamed/removed in 3.x.
If for example we deprecate something in 3.6, I see no harm in adding
a doc warning to the 2.7/3.5 docs stating that the feature is
deprecated starting from 3.6 and removed in 3.8.
I don't think we need to add DWs/PWDs though.

>> Deprecation Process
>> ===================
>>
>> These are the steps required to deprecate and remove an API:
>>
>> 1. propose to deprecate an API on a tracker issue or on python-dev
>>     and decide in which version it will be removed.
>>
>> 2. attach to the issue a patch to deprecate the API that:
>>
>>    * adds a ``DeprecationWarning`` to the code
>
>
> Some deprecation can be documentation-only.
>

Do you have examples where this has been done?
I don't see the point of telling doc readers that a feature is
deprecated but keeping the same information hidden to developers.  If
the actual warnings cause some issue, then the issue should be
addresses (the issue of being noisy has already been addressed by
silencing them by default), but having doc-only deprecation warnings
seems inconsistent and potentially confusing.

> May be worth to mention also ``FutureWarning``. AFAIK it is used if the
> method will not be removed in future, but it's behavior will be changed in
> incompatible way.
>

Good point. I'll investigate a bit and add it.

>>    * adds the deprecation to the documentation
>
>
> Needed explicit link to the "Documenting the deprecations" section.
>

OK.

>>    * adds a test to verify that the warning is raised
>>    * possibly updates code/examples that uses the deprecated API
>>
>> 3. after review, apply the patch to the current in-development
>>     branch and close the issue.
>>
>> 4. attach to a separate issue a patch to remove the API that:
>>
>>    * removes the API and the warning
>>    * removes the tests for the API and for the deprecation
>>    * removes the API documentation
>>
>> 5. once the designated branch is available, apply the patch and
>>     close the issue.
>
>
> There is a special case for pickling. Existing pickle data created in old
> Python releases can contain references to deprecated classes or factory
> functions. Either we should keep old names (even non-public) as aliases to
> new names or add new mapping for 3 to 3 translation in _compat_pickle.py or
> new module.
>

If I understand correctly, this only affects pickleable APIs that have
been moved/renamed.
You could argue that if we are willing to break code that uses the old
names, then we could do the same to old pickles.  Keeping the names
around will allow both code and pickles to keep working and we will
effectively have an indefinite deprecation without removal.  If it can
be done in a _compat_pickle.py it might be ok.

This is also another issue that I forgot to mention -- I would like to
always set a version where the API will be removed, but sometimes this
might mean Python 4.
(FTR the reason is not to "clean up" the language ASAP, but to provide
a clear timeline for both the API users and the core-devs.  This is
also based on the assumption that no deprecated code will stay around
forever; even if it's not remove in the immediate future, at some
point it will.)

Do you think it's fine using Python 4, or is it better to have
indefinite (for some value of indefinite) deprecations?
(Do we also expect to have 3.10, 3.11, etc. after 3.9, or will we just
move to 4.0 even though we might not have major incompatible changes?)

Regardless of the decision, I want the documentation to actually match
the code, so as long as the code is there and it is deprecated, the
doc should say that it is there and it is deprecated.  If the API is
deprecated indefinitely, the docs should say so (and possibly say why
too).

>> Documenting the deprecations
>> ============================
>>
>> * All deprecations should be documented in the docs, using the
>>    ``deprecated-removed`` directive.
>
>
> When use ``deprecated`` and when use ``deprecated-removed``?
>

If we agree to always specify when the API will be removed, then we
won't need to use "deprecated" anymore.
If we want to keep using indefinite deprecations we will use it for them.

This should be specified in the PEP once we reach a consensus.


Best Regards,
Ezio Melotti

From brett at python.org  Fri Jan 29 15:02:09 2016
From: brett at python.org (Brett Cannon)
Date: Fri, 29 Jan 2016 20:02:09 +0000
Subject: [python-committers] Deprecation Policy PEP
In-Reply-To: <CACBhJdEeMuneri5Y+p93vKxQJ9A4cVgSkszEzRmkYZZwX6M_uA@mail.gmail.com>
References: <CACBhJdEat8gg8QqMA2frF=pKo8CondW-SjgGTAK4+-27nnrYhA@mail.gmail.com>
 <n8g9c2$c8i$1@ger.gmane.org>
 <CACBhJdEeMuneri5Y+p93vKxQJ9A4cVgSkszEzRmkYZZwX6M_uA@mail.gmail.com>
Message-ID: <CAP1=2W7V0s+MUcT-4Dcn_fM8JsmNvvB1j=H775GxDynYBRH=6A@mail.gmail.com>

On Fri, 29 Jan 2016 at 11:57 Ezio Melotti <ezio.melotti at gmail.com> wrote:

> On Fri, Jan 29, 2016 at 8:00 PM, Serhiy Storchaka <storchaka at gmail.com>
> wrote:
> > On 29.01.16 19:11, Ezio Melotti wrote:
> [SNIP]
> >> Deprecation Process
> >> ===================
> >>
> >> These are the steps required to deprecate and remove an API:
> >>
> >> 1. propose to deprecate an API on a tracker issue or on python-dev
> >>     and decide in which version it will be removed.
> >>
> >> 2. attach to the issue a patch to deprecate the API that:
> >>
> >>    * adds a ``DeprecationWarning`` to the code
> >
> >
> > Some deprecation can be documentation-only.
> >
>
> Do you have examples where this has been done?
> I don't see the point of telling doc readers that a feature is
> deprecated but keeping the same information hidden to developers.  If
> the actual warnings cause some issue, then the issue should be
> addresses (the issue of being noisy has already been addressed by
> silencing them by default), but having doc-only deprecation warnings
> seems inconsistent and potentially confusing.
>

I have an example. When the concept of create_module()/exec_module() came
into being for importlib, we wanted to deprecate load_module(). The problem
is that while we had worked out the new API, we had not figured out how
best to update C extension modules yet to the new API. We knew that
load_module() usage should be discouraged, but we didn't want to trigger a
DeprecationWarning while the stdlib itself had not stopped using it. So we
documented it as deprecated without raising a DeprecationWarning.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160129/ab2d379e/attachment-0001.html>

From storchaka at gmail.com  Fri Jan 29 16:59:10 2016
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Fri, 29 Jan 2016 23:59:10 +0200
Subject: [python-committers] Deprecation Policy PEP
In-Reply-To: <CACBhJdEeMuneri5Y+p93vKxQJ9A4cVgSkszEzRmkYZZwX6M_uA@mail.gmail.com>
References: <CACBhJdEat8gg8QqMA2frF=pKo8CondW-SjgGTAK4+-27nnrYhA@mail.gmail.com>
 <n8g9c2$c8i$1@ger.gmane.org>
 <CACBhJdEeMuneri5Y+p93vKxQJ9A4cVgSkszEzRmkYZZwX6M_uA@mail.gmail.com>
Message-ID: <n8gnbf$fr3$1@ger.gmane.org>

On 29.01.16 21:56, Ezio Melotti wrote:
> On Fri, Jan 29, 2016 at 8:00 PM, Serhiy Storchaka <storchaka at gmail.com> wrote:
>> What about adding deprecations in bugfix releases? If current behavior is
>> obviously incorrect and should be fixed in development branch, but this can
>> break existing code that implicitly depends on current behavior. Can we add
>> documentation-only warnings or use PendingDeprecationWarning if possible?
>
> Usually deprecations are added in minor releases -- I don't know if we
> added DeprecationWarnings in bugfix releases before.  Adding
> documentation-only warnings in previous releases shouldn't be a
> problem.  We already did this in the 2.7 docs for APIs that have been
> deprecated/renamed/removed in 3.x.
> If for example we deprecate something in 3.6, I see no harm in adding
> a doc warning to the 2.7/3.5 docs stating that the feature is
> deprecated starting from 3.6 and removed in 3.8.
> I don't think we need to add DWs/PWDs though.

We already added DeprecationWarnings in bugfix releases of 2.7 (but only 
enabled using the ``-3`` flag). There is no such mechanism for 
backporting warnings in 3.x, but there is a need. I'm interesting 
wherever using PendingDeprecationWarning instead of DeprecationWarnings 
is good enough for this as well as they are less intrusive.

>> Some deprecation can be documentation-only.
>
> Do you have examples where this has been done?
> I don't see the point of telling doc readers that a feature is
> deprecated but keeping the same information hidden to developers.  If
> the actual warnings cause some issue, then the issue should be
> addresses (the issue of being noisy has already been addressed by
> silencing them by default), but having doc-only deprecation warnings
> seems inconsistent and potentially confusing.

An attribute of a module. While in theory we can add a warning using a 
hack with replacing a module with module subclass instance, nobody does 
this in the stdlib.

Removing some special behavior can be considered as needed a deprecation 
period. For example the change of datetime.time.__bool__ (made without a 
deprecation in issue13936) or ElementTree.Element.__bool__ (added 
indefinite FutureWarning).

> If I understand correctly, this only affects pickleable APIs that have
> been moved/renamed.

Since most Python classes are pickleable by default, this affects 
modules, Python classes with stable structure that doesn't have 
unpickleable attributes, classes specially designed for pickling, simple 
subclasses of pickleable classes, and factory functions or methods that 
are used for pickle representation.

> If it can be done in a _compat_pickle.py it might be ok.

Currently _compat_pickle.py is used only for pickles created in 2.x. We 
need parallel mechanism for 3.x pickles. I think this mechanism should 
be documented in the same document that specifies API removal, i.e. in 
this PEP.

>> When use ``deprecated`` and when use ``deprecated-removed``?
>
> If we agree to always specify when the API will be removed, then we
> won't need to use "deprecated" anymore.
> If we want to keep using indefinite deprecations we will use it for them.
>
> This should be specified in the PEP once we reach a consensus.

May be define that the "deprecated" directive has term to next change of 
mayor version number (Python 4 currently)? It can be prolonged further, 
but the existing of the API beyond this term shouldn't be expected.



From barry at python.org  Fri Jan 29 18:39:31 2016
From: barry at python.org (Barry Warsaw)
Date: Fri, 29 Jan 2016 18:39:31 -0500
Subject: [python-committers] Deprecation Policy PEP
In-Reply-To: <CAP1=2W6Vh3xr7erRSBqYu4MWtUht_LkMR2tmaQn3vnegu07=DA@mail.gmail.com>
References: <CACBhJdEat8gg8QqMA2frF=pKo8CondW-SjgGTAK4+-27nnrYhA@mail.gmail.com>
 <CAPOVWORWuaD72C-G-8gO5n9T5DUn_qNuhJ5KsSyUwD68P0D01A@mail.gmail.com>
 <CAP1=2W6Vh3xr7erRSBqYu4MWtUht_LkMR2tmaQn3vnegu07=DA@mail.gmail.com>
Message-ID: <20160129183931.3fa52938@subdivisions.wooz.org>

On Jan 29, 2016, at 06:11 PM, Brett Cannon wrote:

>+1 from me as well, especially once Serhiy's comments are addressed.

Me too, but only if you add a PendingDeprecationWarning to
PendingDeprecationWarning <wink>.

depreception-ly y'rs,
-Barry

From vadmium+py at gmail.com  Fri Jan 29 21:08:24 2016
From: vadmium+py at gmail.com (Martin Panter)
Date: Sat, 30 Jan 2016 02:08:24 +0000
Subject: [python-committers] Deprecation Policy PEP
In-Reply-To: <CACBhJdEat8gg8QqMA2frF=pKo8CondW-SjgGTAK4+-27nnrYhA@mail.gmail.com>
References: <CACBhJdEat8gg8QqMA2frF=pKo8CondW-SjgGTAK4+-27nnrYhA@mail.gmail.com>
Message-ID: <CA+eR4cG=ADtcyco=sf-GfARfMd2nbTe+PYuSKs-gyyJikFPUHA@mail.gmail.com>

> What and when to deprecate
> ==========================
>
> * The number of releases before an API is removed is decided
>   on a case-by-case basis depending on widely used the API is

depending on [how] widely used

> * In general it's better to be conservative, and if the API is
>   deprecated in ``3.X``, it shouldn't be removed before ``3.X+2``.
>   This should also take into account which Python versions are
>   currently .

which Python versions are [current].

More explicitly, I would say as a guideline, if the proposed
alternative is unavailable in 3.Y, consider waiting until 3.Y becomes
unsupported or unused before removing (or even fully deprecating) an
API.

> Porting from 2.x to 3.x
> -----------------------
>
> In order to make porting code to 3.X easier:
>
> * nothing that is available and not deprecated in 2.7 should be
>   removed from Python 3 as long as 2.7 is officially supported;

What about an API not documented in Python 3, like
http.client.HTTPMessage.getallmatchingheaders()
<https://bugs.python.org/issue5053>? In this case I think the method
was rendered useless in 3.0 and it is not worth fixing.

Also I presume you mean not originally deprecated in 2.7.0. In other
words adding a ?python2 -3? warning in the next 2.7 bug fix doesn?t
give me a license to remove an API from 3.6.

> Deprecation Progression
> =======================
>
> 1. in release ``3.X`` a ``DeprecationWarning`` is added
> 2. in release ``3.X+N`` the API is removed
>
> ``N`` can be ``>=1``, should be decided beforehand, and should be
> documented explicitly.

How do we decide on the value of N for something that has to wait
until 2.7 is dead? Just estimate based on anticipated future release
dates? E.g. inspect.getargspec(). In some cases I think indefinite
deprecation is better.

> Deprecation Process
> ===================

> 2. attach to the issue a patch to deprecate the API that:
>
>   * adds a ``DeprecationWarning`` to the code
>   * adds the deprecation to the documentation
>   * adds a test to verify that the warning is raised

Often people propose a test that will detect when the version changes
to >= X+N and complains if the API has not been removed. Should this
be encouraged or discouraged?

>   * possibly updates code/examples that uses the deprecated API

Also adjust any tests to suppress the new warning. Code to do this
typically looks like

with warnings.catch_warnings():
    warnings.simplefilter("ignore", DeprecationWarning)
    deprecated.api()

> 3. after review, apply the patch to the current in-development
>    branch and close the issue.

Also apply similar changes to 2.7 if applicable?

> Documenting the deprecations
> ============================
>
> * All deprecations should be documented in the docs, using the
>   ``deprecated-removed`` directive.

If an undocumented API is being deprecated, you may not have to touch
the main documentation (but still consider a notice in What?s New).

From vadmium+py at gmail.com  Fri Jan 29 22:28:44 2016
From: vadmium+py at gmail.com (Martin Panter)
Date: Sat, 30 Jan 2016 03:28:44 +0000
Subject: [python-committers] Deprecation Policy PEP
In-Reply-To: <n8gnbf$fr3$1@ger.gmane.org>
References: <CACBhJdEat8gg8QqMA2frF=pKo8CondW-SjgGTAK4+-27nnrYhA@mail.gmail.com>
 <n8g9c2$c8i$1@ger.gmane.org>
 <CACBhJdEeMuneri5Y+p93vKxQJ9A4cVgSkszEzRmkYZZwX6M_uA@mail.gmail.com>
 <n8gnbf$fr3$1@ger.gmane.org>
Message-ID: <CA+eR4cFcz4Q5ZeC0BTHhPRgqG4CKPGzOees71VYC-p+j5SvWpg@mail.gmail.com>

On 29 January 2016 at 21:59, Serhiy Storchaka <storchaka at gmail.com> wrote:
> On 29.01.16 21:56, Ezio Melotti wrote:
>> On Fri, Jan 29, 2016 at 8:00 PM, Serhiy Storchaka <storchaka at gmail.com>
>> wrote:
>>> Some deprecation can be documentation-only.
>>
>> Do you have examples where this has been done?
>
> An attribute of a module. [. . .]
> Removing some special behavior [. . .]

Sometimes people want to avoid raising a DeprecationWarning even where
it is technically possible. For example, the optparse module
<https://bugs.python.org/issue25521>, which is still widely used in
other modules. Brett?s load_module() situation also sounds similar.

[Serhiy]
> We already added DeprecationWarnings in bugfix releases of 2.7 (but only
> enabled using the ``-3`` flag). There is no such mechanism for backporting
> warnings in 3.x, but there is a need. I'm interesting wherever using
> PendingDeprecationWarning instead of DeprecationWarnings is good enough for
> this as well as they are less intrusive.

[Ezio]
>> I don't see the point of telling doc readers that a feature is
>> deprecated but keeping the same information hidden to developers.  If
>> the actual warnings cause some issue, then the issue should be
>> addresses (the issue of being noisy has already been addressed by
>> silencing them by default), but having doc-only deprecation warnings
>> seems inconsistent and potentially confusing.

Perhaps we could (re)purpose PendingDeprecationWarning to mean ?This
may not be the best API to use, but there is no immediate plan to
remove it?. It could go into bug fix releases as Serhiy suggested. A
full DeprecationWarning would mean ?Get your code in order; this API
will be removed soon!?.

>>> When use ``deprecated`` and when use ``deprecated-removed``?
>>
>> If we agree to always specify when the API will be removed, then we
>> won't need to use "deprecated" anymore.
>> If we want to keep using indefinite deprecations we will use it for them.
>>
>> This should be specified in the PEP once we reach a consensus.
>
> May be define that the "deprecated" directive has term to next change of
> mayor version number (Python 4 currently)? It can be prolonged further, but
> the existing of the API beyond this term shouldn't be expected.

I thought Python 4 was mainly a myth or fantasy at this stage?

From senthil at uthcode.com  Fri Jan 29 22:32:45 2016
From: senthil at uthcode.com (Senthil Kumaran)
Date: Fri, 29 Jan 2016 19:32:45 -0800
Subject: [python-committers] Deprecation Policy PEP
In-Reply-To: <CA+eR4cFcz4Q5ZeC0BTHhPRgqG4CKPGzOees71VYC-p+j5SvWpg@mail.gmail.com>
References: <CACBhJdEat8gg8QqMA2frF=pKo8CondW-SjgGTAK4+-27nnrYhA@mail.gmail.com>
 <n8g9c2$c8i$1@ger.gmane.org>
 <CACBhJdEeMuneri5Y+p93vKxQJ9A4cVgSkszEzRmkYZZwX6M_uA@mail.gmail.com>
 <n8gnbf$fr3$1@ger.gmane.org>
 <CA+eR4cFcz4Q5ZeC0BTHhPRgqG4CKPGzOees71VYC-p+j5SvWpg@mail.gmail.com>
Message-ID: <CAPOVWOTtHhie7hjOEfK6T9z+GBn6+66RNkeD4dd9f4iFQVLb=Q@mail.gmail.com>

On Fri, Jan 29, 2016 at 7:28 PM, Martin Panter <vadmium+py at gmail.com> wrote:

> I thought Python 4 was mainly a myth or fantasy at this stage?


We are already in Python 3.6.  If we go with a release every 1.5 years,
then Python 4 is probably 6 years away.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160129/aa311e98/attachment-0001.html>

From guido at python.org  Fri Jan 29 22:36:08 2016
From: guido at python.org (Guido van Rossum)
Date: Fri, 29 Jan 2016 19:36:08 -0800
Subject: [python-committers] Deprecation Policy PEP
In-Reply-To: <CAPOVWOTtHhie7hjOEfK6T9z+GBn6+66RNkeD4dd9f4iFQVLb=Q@mail.gmail.com>
References: <CACBhJdEat8gg8QqMA2frF=pKo8CondW-SjgGTAK4+-27nnrYhA@mail.gmail.com>
 <n8g9c2$c8i$1@ger.gmane.org>
 <CACBhJdEeMuneri5Y+p93vKxQJ9A4cVgSkszEzRmkYZZwX6M_uA@mail.gmail.com>
 <n8gnbf$fr3$1@ger.gmane.org>
 <CA+eR4cFcz4Q5ZeC0BTHhPRgqG4CKPGzOees71VYC-p+j5SvWpg@mail.gmail.com>
 <CAPOVWOTtHhie7hjOEfK6T9z+GBn6+66RNkeD4dd9f4iFQVLb=Q@mail.gmail.com>
Message-ID: <CAP7+vJ+VZt9AY0dsay1XPHs2rcE2VaUJOM8Tp+61marWezdBKg@mail.gmail.com>

Following the lead of 2.7.10 and 2.7.11 we could continue with 3.10, 3.11, etc.

I also want the 3->4 transition to feel like a non-event for most
users. How we'll do that I don't know yet, but I want it to be a lot
smoother than 2->3.

-- 
--Guido van Rossum (python.org/~guido)

From ncoghlan at gmail.com  Sat Jan 30 03:39:12 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 30 Jan 2016 18:39:12 +1000
Subject: [python-committers] Deprecation Policy PEP
In-Reply-To: <20160129183931.3fa52938@subdivisions.wooz.org>
References: <CACBhJdEat8gg8QqMA2frF=pKo8CondW-SjgGTAK4+-27nnrYhA@mail.gmail.com>
 <CAPOVWORWuaD72C-G-8gO5n9T5DUn_qNuhJ5KsSyUwD68P0D01A@mail.gmail.com>
 <CAP1=2W6Vh3xr7erRSBqYu4MWtUht_LkMR2tmaQn3vnegu07=DA@mail.gmail.com>
 <20160129183931.3fa52938@subdivisions.wooz.org>
Message-ID: <CADiSq7eSZrgK8tCsfnU=sHhyS03R9it_2BBK_Ec58Peumuc1UQ@mail.gmail.com>

On 30 January 2016 at 09:39, Barry Warsaw <barry at python.org> wrote:
> On Jan 29, 2016, at 06:11 PM, Brett Cannon wrote:
>
>>+1 from me as well, especially once Serhiy's comments are addressed.

Likewise - an additional proofreading pass would be useful, but the
overall content looks fine to me.

> Me too, but only if you add a PendingDeprecationWarning to
> PendingDeprecationWarning <wink>.

There were some discussions a while back of restoring a distinction
between the two by having code executed directly at the REPL (whether
at the command line or in IDLE) show DeprecationWarning by default,
but still hide PendingDeprecationWarning globally.

That idea actually seemed to garner general approval, so I suspect the
main reason the discussion died out was the fact that it's a bit
fiddly to implement.

Cheers,
Nick.

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

From ncoghlan at gmail.com  Sat Jan 30 03:41:51 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 30 Jan 2016 18:41:51 +1000
Subject: [python-committers] Deprecation Policy PEP
In-Reply-To: <CA+eR4cFcz4Q5ZeC0BTHhPRgqG4CKPGzOees71VYC-p+j5SvWpg@mail.gmail.com>
References: <CACBhJdEat8gg8QqMA2frF=pKo8CondW-SjgGTAK4+-27nnrYhA@mail.gmail.com>
 <n8g9c2$c8i$1@ger.gmane.org>
 <CACBhJdEeMuneri5Y+p93vKxQJ9A4cVgSkszEzRmkYZZwX6M_uA@mail.gmail.com>
 <n8gnbf$fr3$1@ger.gmane.org>
 <CA+eR4cFcz4Q5ZeC0BTHhPRgqG4CKPGzOees71VYC-p+j5SvWpg@mail.gmail.com>
Message-ID: <CADiSq7d6AhaeMvr9K1PWo=xeFsetTj4c_amZ9FCXLS9wJ1EAOA@mail.gmail.com>

On 30 January 2016 at 13:28, Martin Panter <vadmium+py at gmail.com> wrote:
> On 29 January 2016 at 21:59, Serhiy Storchaka <storchaka at gmail.com> wrote:
>> On 29.01.16 21:56, Ezio Melotti wrote:
>>> On Fri, Jan 29, 2016 at 8:00 PM, Serhiy Storchaka <storchaka at gmail.com>
>>> wrote:
>>>> Some deprecation can be documentation-only.
>>>
>>> Do you have examples where this has been done?
>>
>> An attribute of a module. [. . .]
>> Removing some special behavior [. . .]
>
> Sometimes people want to avoid raising a DeprecationWarning even where
> it is technically possible. For example, the optparse module
> <https://bugs.python.org/issue25521>, which is still widely used in
> other modules. Brett?s load_module() situation also sounds similar.

Another case where this arises is when an API has been deprecated for
pure Python 3 code, but is still needed in single source Python 2/3
code.

Cheers,
Nick.

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

From tjreedy at udel.edu  Sat Jan 30 04:24:44 2016
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 30 Jan 2016 04:24:44 -0500
Subject: [python-committers] Deprecation Policy PEP
In-Reply-To: <CADiSq7eSZrgK8tCsfnU=sHhyS03R9it_2BBK_Ec58Peumuc1UQ@mail.gmail.com>
References: <CACBhJdEat8gg8QqMA2frF=pKo8CondW-SjgGTAK4+-27nnrYhA@mail.gmail.com>
 <CAPOVWORWuaD72C-G-8gO5n9T5DUn_qNuhJ5KsSyUwD68P0D01A@mail.gmail.com>
 <CAP1=2W6Vh3xr7erRSBqYu4MWtUht_LkMR2tmaQn3vnegu07=DA@mail.gmail.com>
 <20160129183931.3fa52938@subdivisions.wooz.org>
 <CADiSq7eSZrgK8tCsfnU=sHhyS03R9it_2BBK_Ec58Peumuc1UQ@mail.gmail.com>
Message-ID: <56AC815C.1090709@udel.edu>

On 1/30/2016 3:39 AM, Nick Coghlan wrote:

>> Me too, but only if you add a PendingDeprecationWarning to
>> PendingDeprecationWarning <wink>.
>
> There were some discussions a while back of restoring a distinction
> between the two by having code executed directly at the REPL (whether
> at the command line or in IDLE) show DeprecationWarning by default,
> but still hide PendingDeprecationWarning globally.

What would you do for mixed start-batch, switch to interactive mode 
(-i)?  Turn DWs on at the beginning on the basis that -i is mainly for 
development?

> That idea actually seemed to garner general approval, so I suspect the
> main reason the discussion died out was the fact that it's a bit
> fiddly to implement.

IDLE executes usercode with, I believe, exec(code_object, pseudo_main). 
  Does exec simply use the current warnings setting?

-TJR