[Python-Dev] Workflow PEP proposals are now closed

[Brett Cannon]

On Mon Feb 02 2015 at 10:00:30 AM Donald Stufft <donald at stufft.io> wrote:

>
> On Feb 2, 2015, at 9:35 AM, Brett Cannon <bcannon at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150202/aab0e777/attachment.html>