[core-workflow] PEP 507 - Git & GitLab

[M.-A. Lemburg]

On 01.10.2015 08:02, Nick Coghlan wrote:
> On 1 October 2015 at 07:08, Barry Warsaw <barry at 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/