Workflow PEP proposals are now closed
The PEPs under consideration are PEPs 474 <https://www.python.org/dev/peps/pep-0474/> and 462 <https://www.python.org/dev/peps/pep-0462/> from Nick Coghlan to use Kallithea and do self-hosting, and PEP 481 <https://www.python.org/dev/peps/pep-0481/> from Donald Stufft that proposes using GitHub. At this point I expect final PEPs by PyCon US so I can try and make a decision by May 1. Longer still is to hopefully have whatever solution we choose in place right after Python 3.5 is released. And just a reminder to people, the lofty goal is to improve the overall workflow for CPython itself such that our patch submission queue can actually be cleared regularly. This not only benefits core devs by letting us be more effective, but also contributors by making sure their hard work gets addressed quickly and thus doesn't languish on the issue tracker for very long. If we can't find a solution for fixing our CPython workflow I will then be willing to entertain these PEPs narrowing their scopes and only focus on ancillary repos like the devguide, etc. where the workflows are simple. I know the absolute worst case is nothing changes, but honestly I think the worst case is Nick's work gets us off of Rietveld, the ancillary repos move to GitHub, and we make the GitHub and Bitbucket mirrors of CPython official ones for people to work from (bonus points if we get the issue tracker to have push button patch pulling from GitHub; Bitbucket is already covered thanks to our remote hg repo support). IOW I see nothing but a win for contributors and core devs as well as everyone proposing solutions which is a nice place to start from. =)
On Feb 2, 2015, at 9:35 AM, Brett Cannon <bcannon@gmail.com> wrote:
The PEPs under consideration are PEPs 474 <https://www.python.org/dev/peps/pep-0474/> and 462 <https://www.python.org/dev/peps/pep-0462/> from Nick Coghlan to use Kallithea and do self-hosting, and PEP 481 <https://www.python.org/dev/peps/pep-0481/> from Donald Stufft that proposes using GitHub.
At this point I expect final PEPs by PyCon US so I can try and make a decision by May 1. Longer still is to hopefully have whatever solution we choose in place right after Python 3.5 is released.
And just a reminder to people, the lofty goal is to improve the overall workflow for CPython itself such that our patch submission queue can actually be cleared regularly. This not only benefits core devs by letting us be more effective, but also contributors by making sure their hard work gets addressed quickly and thus doesn't languish on the issue tracker for very long.
If we can't find a solution for fixing our CPython workflow I will then be willing to entertain these PEPs narrowing their scopes and only focus on ancillary repos like the devguide, etc. where the workflows are simple.
I know the absolute worst case is nothing changes, but honestly I think the worst case is Nick's work gets us off of Rietveld, the ancillary repos move to GitHub, and we make the GitHub and Bitbucket mirrors of CPython official ones for people to work from (bonus points if we get the issue tracker to have push button patch pulling from GitHub; Bitbucket is already covered thanks to our remote hg repo support). IOW I see nothing but a win for contributors and core devs as well as everyone proposing solutions which is a nice place to start from. =)
Is there going to be discussion between the two approaches or should the PEPs themselves address each other? --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Mon Feb 02 2015 at 10:00:30 AM Donald Stufft <donald@stufft.io> wrote:
On Feb 2, 2015, at 9:35 AM, Brett Cannon <bcannon@gmail.com> wrote:
The PEPs under consideration are PEPs 474 <https://www.python.org/dev/peps/pep-0474/> and 462 <https://www.python.org/dev/peps/pep-0462/> from Nick Coghlan to use Kallithea and do self-hosting, and PEP 481 <https://www.python.org/dev/peps/pep-0481/> from Donald Stufft that proposes using GitHub.
At this point I expect final PEPs by PyCon US so I can try and make a decision by May 1. Longer still is to hopefully have whatever solution we choose in place right after Python 3.5 is released.
And just a reminder to people, the lofty goal is to improve the overall workflow for CPython itself such that our patch submission queue can actually be cleared regularly. This not only benefits core devs by letting us be more effective, but also contributors by making sure their hard work gets addressed quickly and thus doesn't languish on the issue tracker for very long.
If we can't find a solution for fixing our CPython workflow I will then be willing to entertain these PEPs narrowing their scopes and only focus on ancillary repos like the devguide, etc. where the workflows are simple.
I know the absolute worst case is nothing changes, but honestly I think the worst case is Nick's work gets us off of Rietveld, the ancillary repos move to GitHub, and we make the GitHub and Bitbucket mirrors of CPython official ones for people to work from (bonus points if we get the issue tracker to have push button patch pulling from GitHub; Bitbucket is already covered thanks to our remote hg repo support). IOW I see nothing but a win for contributors and core devs as well as everyone proposing solutions which is a nice place to start from. =)
Is there going to be discussion between the two approaches or should the PEPs themselves address each other?
Since PEPs are meant to act as a record of what was discussed on a topic then it probably wouldn't hurt to incorporate why your approach is better than the other one in the PEP itself. We can obviously talk openly here when you feel the PEP is ready for it.
Hi, What does "closed" mean in this context? Regards Antoine. On Mon, 02 Feb 2015 14:35:47 +0000 Brett Cannon <bcannon@gmail.com> wrote:
The PEPs under consideration are PEPs 474 <https://www.python.org/dev/peps/pep-0474/> and 462 <https://www.python.org/dev/peps/pep-0462/> from Nick Coghlan to use Kallithea and do self-hosting, and PEP 481 <https://www.python.org/dev/peps/pep-0481/> from Donald Stufft that proposes using GitHub.
At this point I expect final PEPs by PyCon US so I can try and make a decision by May 1. Longer still is to hopefully have whatever solution we choose in place right after Python 3.5 is released.
And just a reminder to people, the lofty goal is to improve the overall workflow for CPython itself such that our patch submission queue can actually be cleared regularly. This not only benefits core devs by letting us be more effective, but also contributors by making sure their hard work gets addressed quickly and thus doesn't languish on the issue tracker for very long.
If we can't find a solution for fixing our CPython workflow I will then be willing to entertain these PEPs narrowing their scopes and only focus on ancillary repos like the devguide, etc. where the workflows are simple.
I know the absolute worst case is nothing changes, but honestly I think the worst case is Nick's work gets us off of Rietveld, the ancillary repos move to GitHub, and we make the GitHub and Bitbucket mirrors of CPython official ones for people to work from (bonus points if we get the issue tracker to have push button patch pulling from GitHub; Bitbucket is already covered thanks to our remote hg repo support). IOW I see nothing but a win for contributors and core devs as well as everyone proposing solutions which is a nice place to start from. =)
On Mon Feb 02 2015 at 2:40:21 PM Antoine Pitrou <solipsis@pitrou.net> wrote:
Hi,
What does "closed" mean in this context?
No new PEPs on this topic will be taken under consideration, so submissions are now "closed" to new participants. -Brett
Regards
Antoine.
The PEPs under consideration are PEPs 474 <https://www.python.org/dev/peps/pep-0474/> and 462 <https://www.python.org/dev/peps/pep-0462/> from Nick Coghlan to use Kallithea and do self-hosting, and PEP 481 <https://www.python.org/dev/peps/pep-0481/> from Donald Stufft that proposes using GitHub.
At this point I expect final PEPs by PyCon US so I can try and make a decision by May 1. Longer still is to hopefully have whatever solution we choose in place right after Python 3.5 is released.
And just a reminder to people, the lofty goal is to improve the overall workflow for CPython itself such that our patch submission queue can actually be cleared regularly. This not only benefits core devs by letting us be more effective, but also contributors by making sure their hard work gets addressed quickly and thus doesn't languish on the issue tracker for very long.
If we can't find a solution for fixing our CPython workflow I will then be willing to entertain these PEPs narrowing their scopes and only focus on ancillary repos like the devguide, etc. where the workflows are simple.
I know the absolute worst case is nothing changes, but honestly I think
On Mon, 02 Feb 2015 14:35:47 +0000 Brett Cannon <bcannon@gmail.com> wrote: the
worst case is Nick's work gets us off of Rietveld, the ancillary repos move to GitHub, and we make the GitHub and Bitbucket mirrors of CPython official ones for people to work from (bonus points if we get the issue tracker to have push button patch pulling from GitHub; Bitbucket is already covered thanks to our remote hg repo support). IOW I see nothing but a win for contributors and core devs as well as everyone proposing solutions which is a nice place to start from. =)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ brett%40python.org
Is there going to be discussion between the two approaches or should the PEPs themselves address each other?
Since PEPs are meant to act as a record of what was discussed on a topic
On 3 Feb 2015 01:26, "Brett Cannon" <bcannon@gmail.com> wrote: then it probably wouldn't hurt to incorporate why your approach is better than the other one in the PEP itself. We can obviously talk openly here when you feel the PEP is ready for it. One key point worth noting is that the addition of Phabricator to Donald's proposal actually addresses my most critical concerns regarding workflow lock-in to a proprietary platform. While I'm genuinely unreasonable on that particular topic in an upstream context, part of my vehemence in the original thread was due to bleedover from arguments in other contexts that happened to be running concurrently, so my belated apologies for that. In my view, this is now a contest between two different proposals where I think both represent significant improvements over the status quo. I obviously still prefer mine, though :) Cheers, Nick.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
participants (5)
-
Antoine Pitrou -
Brett Cannon -
Brett Cannon -
Donald Stufft -
Nick Coghlan