I'm not subscribed to this list directly, but I read it through Gmane. I've just published PEP 507 which proposes to move CPython development to Git and a hosted (donated or self TBD) GitLab instance. https://www.python.org/dev/peps/pep-0507/ All feedback is of course welcome, and if anybody else wants to hitch their ride to this pony, let me know and I'd be happy to add you as co-author of the PEP. Cheers, -Barry
On 1 October 2015 at 07:08, Barry Warsaw <barry@python.org> wrote:
I'm not subscribed to this list directly, but I read it through Gmane.
I've just published PEP 507 which proposes to move CPython development to Git and a hosted (donated or self TBD) GitLab instance.
https://www.python.org/dev/peps/pep-0507/
All feedback is of course welcome, and if anybody else wants to hitch their ride to this pony, let me know and I'd be happy to add you as co-author of the PEP.
Thanks Barry. I'd already mentioned this to Brett and Barry, but for the public record: now that there's a second open source alternative in the mix, I'm going to be withdrawing my own Kallithea based workflow proposals. With BitBucket pursuing a similarly proprietary model to GitHub's, RhodeCode also switching to a proprietary business model, and the dubious business practices over at SourceForge making me reluctant to recommend the use of Allura, I don't see any currently credible open source vendors offering supported Mercurial hosting. Kallithea itself would require a lot of work to bring it's usability up to the same standard as GitHub or GitLab (let alone upgrading from the current Python 2 only Pylons codebase to a Python 3 compatible Pyramid stack), and, honestly, there are other ways I'd prefer to be spending my time (e.g. I'd like to finally get back to working on the startup sequence refactoring at some point). Furthermore, if the PSF were to invest further in contract development for web applications, those funds would be better directed towards more critical community services like the Python Package Index than to tools specific to the core development process. So while I'd love to see us sticking with Mercurial and a Python based hosting solution, I think the benefits of switching to a commercially supported open source solution like GitLab outweigh those considerations. Regards, Nick. P.S. If anyone is really keen to continue advocating for the Kallithea+Mercurial based solution, I'd be happy to cede authorship of the relevant PEPs. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 01.10.2015 08:02, Nick Coghlan wrote:
On 1 October 2015 at 07:08, Barry Warsaw <barry@python.org> wrote:
I'm not subscribed to this list directly, but I read it through Gmane.
I've just published PEP 507 which proposes to move CPython development to Git and a hosted (donated or self TBD) GitLab instance.
https://www.python.org/dev/peps/pep-0507/
All feedback is of course welcome, and if anybody else wants to hitch their ride to this pony, let me know and I'd be happy to add you as co-author of the PEP.
Thanks Barry.
I'd already mentioned this to Brett and Barry, but for the public record: now that there's a second open source alternative in the mix, I'm going to be withdrawing my own Kallithea based workflow proposals.
With BitBucket pursuing a similarly proprietary model to GitHub's, RhodeCode also switching to a proprietary business model, and the dubious business practices over at SourceForge making me reluctant to recommend the use of Allura, I don't see any currently credible open source vendors offering supported Mercurial hosting.
Kallithea itself would require a lot of work to bring it's usability up to the same standard as GitHub or GitLab (let alone upgrading from the current Python 2 only Pylons codebase to a Python 3 compatible Pyramid stack), and, honestly, there are other ways I'd prefer to be spending my time (e.g. I'd like to finally get back to working on the startup sequence refactoring at some point).
Furthermore, if the PSF were to invest further in contract development for web applications, those funds would be better directed towards more critical community services like the Python Package Index than to tools specific to the core development process.
So while I'd love to see us sticking with Mercurial and a Python based hosting solution, I think the benefits of switching to a commercially supported open source solution like GitLab outweigh those considerations.
Thanks for kicking off the whole discussion, Nick. I think that by moving to a PR based workflow, we'll achieve better efficiency in the long run, so regardless of which technology gets chosen, it will be for the better. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Oct 01 2015)
Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/
2015-09-25: Started a Python blog ... ... http://malemburg.com/ 2015-10-21: Python Meeting Duesseldorf ... 20 days to go ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: 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/
participants (3)
-
Barry Warsaw -
M.-A. Lemburg -
Nick Coghlan