The peps repo is now on GitHub!
I don't think anything has fallen over, so I'm calling this a successful migration! The peps repo is now https://github.com/python/peps .
I have given the Python core team on GitHub write access to the repository so people can add/update their own PEPs. There is also an issue tracker there, seeded with some enhancements we could make to have the PEPs be nicer to work with.
I should also mention that the CLA bot is turned on for this repo as per our lawyer's advice, so people will need to have signed the CLA and have their GitHub username associated with their bugs.python.org account to have their pull request cleared for acceptance.
And can someone delete hg.python.org/peps?
On 16.06.2016 00:42, Brett Cannon wrote:
I don't think anything has fallen over, so I'm calling this a successful migration! The peps repo is now https://github.com/python/peps .
Thanks for putting so much hard work into this !
I have given the Python core team on GitHub write access to the repository so people can add/update their own PEPs. There is also an issue tracker there, seeded with some enhancements we could make to have the PEPs be nicer to work with.
I should also mention that the CLA bot is turned on for this repo as per our lawyer's advice, so people will need to have signed the CLA and have their GitHub username associated with their bugs.python.org account to have their pull request cleared for acceptance.
This part is a bit weird: Most PEPs are in the public domain, so why should we need a CLA for contributing to PEPs ?
And can someone delete hg.python.org/peps?
Hmm, isn't it better to make this read-only to avoid breaking links to it ?
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Jun 16 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/
On Wed, 15 Jun 2016 at 15:49 M.-A. Lemburg mal@egenix.com wrote:
On 16.06.2016 00:42, Brett Cannon wrote:
I don't think anything has fallen over, so I'm calling this a successful migration! The peps repo is now https://github.com/python/peps .
Thanks for putting so much hard work into this !
Welcome!
I have given the Python core team on GitHub write access to the repository so people can add/update their own PEPs. There is also an issue tracker there, seeded with some enhancements we could make to have the PEPs be nicer to work with.
I should also mention that the CLA bot is turned on for this repo as per our lawyer's advice, so people will need to have signed the CLA and have their GitHub username associated with their bugs.python.org account to have their pull request cleared for acceptance.
This part is a bit weird: Most PEPs are in the public domain, so why should we need a CLA for contributing to PEPs ?
Van explicitly told me that contributions to PEPs should be covered by the CLA. IANAL so I'm not going to guess as to why we need to do this.
And can someone delete hg.python.org/peps?
Hmm, isn't it better to make this read-only to avoid breaking links to it ?
If you want. My only worry is people forgoing GitHub and sending us outdated patches. But if people want it left up for now we can (I can't guarantee we will keep hg.python.org around forever, though). As long as people can't commit to the peps repo that's the most critical thing in the short-term.
On 15 June 2016 at 15:54, Brett Cannon brett@python.org wrote:
On Wed, 15 Jun 2016 at 15:49 M.-A. Lemburg mal@egenix.com wrote:
Hmm, isn't it better to make this read-only to avoid breaking links to it ?
If you want. My only worry is people forgoing GitHub and sending us outdated patches. But if people want it left up for now we can (I can't guarantee we will keep hg.python.org around forever, though). As long as people can't commit to the peps repo that's the most critical thing in the short-term.
We should keep hg.python.org around, just as we kept svn.python.org.
We may want to add banners to point people at the GitHub repos for the latest versions, though.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 16.06.2016 00:48, M.-A. Lemburg wrote:
On 16.06.2016 00:42, Brett Cannon wrote:
I don't think anything has fallen over, so I'm calling this a successful migration! The peps repo is now https://github.com/python/peps .
Thanks for putting so much hard work into this !
BTW: Is it ok to push directly into the PEP repo or should we (as PEP authors) always go through PRs which we then merge into the repo ?
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Jun 16 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/
On Jun 15, 2016, at 6:55 PM, M.-A. Lemburg mal@egenix.com wrote:
On 16.06.2016 00:48, M.-A. Lemburg wrote:
On 16.06.2016 00:42, Brett Cannon wrote:
I don't think anything has fallen over, so I'm calling this a successful migration! The peps repo is now https://github.com/python/peps .
Thanks for putting so much hard work into this !
BTW: Is it ok to push directly into the PEP repo or should we (as PEP authors) always go through PRs which we then merge into the repo ?
Currently there’s nothing preventing people from pushing directly to the PEP repository, in https://github.com/python/peps/issues/5 there’s talk of setting up Travis to ensure the PEPs are always building and if the flag is set to require a +1 from Travis, then all changes will need to go through PRs.
— Donald Stufft
On Jun 15, 2016, at 06:59 PM, Donald Stufft wrote:
Currently there’s nothing preventing people from pushing directly to the PEP repository, in https://github.com/python/peps/issues/5 there’s talk of setting up Travis to ensure the PEPs are always building and if the flag is set to require a +1 from Travis, then all changes will need to go through PRs.
Yes, I agree that's where we want to end up. It might make sense to allow PEP editors to push directly for $reasons, but I don't know if that's possible.
-Barry
On Jun 16, 2016, at 1:38 AM, Barry Warsaw barry@python.org wrote:
On Jun 15, 2016, at 06:59 PM, Donald Stufft wrote:
Currently there’s nothing preventing people from pushing directly to the PEP repository, in https://github.com/python/peps/issues/5 there’s talk of setting up Travis to ensure the PEPs are always building and if the flag is set to require a +1 from Travis, then all changes will need to go through PRs.
Yes, I agree that's where we want to end up. It might make sense to allow PEP editors to push directly for $reasons, but I don't know if that's possible.
If we want to give a group of people the ability to override the status check we just need to give that group of people Administrator access to the repository so we could add a “PEP Editors” group if we didn’t want to give the entire Python Core team such permission.
I’m unsure if that means that they can push directly or not, or if that only means they can merge a PR that doesn’t have the requisite passing status checks.
— Donald Stufft
Folk can't argue with robots: I think its useful to have an escape valve for dealing with spurious failures - the Python Core team is pretty responsible, and I think we should permit bypassing robots, at least until we have lots of run-time to learn about any flakiness present.
-Rob
On 16 June 2016 at 22:08, Donald Stufft donald@stufft.io wrote:
On Jun 16, 2016, at 1:38 AM, Barry Warsaw barry@python.org wrote:
On Jun 15, 2016, at 06:59 PM, Donald Stufft wrote:
Currently there’s nothing preventing people from pushing directly to the PEP repository, in https://github.com/python/peps/issues/5 there’s talk of setting up Travis to ensure the PEPs are always building and if the flag is set to require a +1 from Travis, then all changes will need to go through PRs.
Yes, I agree that's where we want to end up. It might make sense to allow PEP editors to push directly for $reasons, but I don't know if that's possible.
If we want to give a group of people the ability to override the status check we just need to give that group of people Administrator access to the repository so we could add a “PEP Editors” group if we didn’t want to give the entire Python Core team such permission.
I’m unsure if that means that they can push directly or not, or if that only means they can merge a PR that doesn’t have the requisite passing status checks.
— Donald Stufft
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
On Jun 15, 2016, at 10:42 PM, Brett Cannon wrote:
I don't think anything has fallen over, so I'm calling this a successful migration! The peps repo is now https://github.com/python/peps .
Really great work Brett, thanks!
-Barry
participants (6)
-
Barry Warsaw -
Brett Cannon -
Donald Stufft -
M.-A. Lemburg -
Nick Coghlan -
Robert Collins