From ncoghlan at gmail.com  Thu Oct  1 08:02:42 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 1 Oct 2015 16:02:42 +1000
Subject: [core-workflow] PEP 507 - Git & GitLab
In-Reply-To: <20150930170810.0b609d74@limelight.wooz.org>
References: <20150930170810.0b609d74@limelight.wooz.org>
Message-ID: <CADiSq7dWUEniQ8WvjEtH-=L8uqok3xgX+0Ct7q4pRzHZGkNdow@mail.gmail.com>

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.

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 at gmail.com   |   Brisbane, Australia

From mal at egenix.com  Thu Oct  1 09:20:00 2015
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 01 Oct 2015 09:20:00 +0200
Subject: [core-workflow] PEP 507 - Git & GitLab
In-Reply-To: <CADiSq7dWUEniQ8WvjEtH-=L8uqok3xgX+0Ct7q4pRzHZGkNdow@mail.gmail.com>
References: <20150930170810.0b609d74@limelight.wooz.org>
 <CADiSq7dWUEniQ8WvjEtH-=L8uqok3xgX+0Ct7q4pRzHZGkNdow@mail.gmail.com>
Message-ID: <560CDEA0.9020208@egenix.com>

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/

From ncoghlan at gmail.com  Wed Oct 28 04:50:43 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 28 Oct 2015 09:50:43 +0100
Subject: [core-workflow] Testing out proposed new workflows
In-Reply-To: <CAP1=2W50MBf9TrNJYoy+m6BhfE09z7VMwE=v6aD=3ZSG5Mwx6w@mail.gmail.com>
References: <CAP1=2W50MBf9TrNJYoy+m6BhfE09z7VMwE=v6aD=3ZSG5Mwx6w@mail.gmail.com>
Message-ID: <CADiSq7dx0sWHYzJXz33joW7LpYXrp_mqk8UZGihWw16dciWeug@mail.gmail.com>

On 5 Aug 2015 00:35, "Brett Cannon" <bcannon at gmail.com> wrote:
>
> Nick and Donald, do you think you can have such a test setup up and
running by October 31 (Halloween, 88 days away)? If you honestly need more
time I am willing to extend to November 15 (the cut-off in the retail
industry to consider something in stores for Christmas, 113 days away), but
I only want to do that if you honestly think the 15 extra days will make a
difference.

I'm not sure where we're at with this timeline, but I wanted to raise a
request from some recent distutils-sig process discussions: we have some
participants that *strongly* prefer to only need accounts with PSF provided
services in order to participate in PEP design discussions. (The context
was using the PyPA's "interoperability PEPs" repo on GitHub as part of the
detailed review process for packaging interoperability PEPs)

Cheers,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151028/2c5bd928/attachment.html>