From brett at python.org  Tue Dec  1 18:24:44 2015
From: brett at python.org (Brett Cannon)
Date: Tue, 01 Dec 2015 23:24:44 +0000
Subject: [core-workflow] Questions about the proposed workflows
Message-ID: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>

It's Dec 1, which means it's time for any questions people have about the
proposed workflows so we can get answers by Dec 15.

I have one question that applies to both proposals and one specific to
GitLab. The general one is whether both Guido and me can both be happy. :)
Guido doesn't want intermediate commits nor what he calls "merge turds" to
show up in the history. I want to be able to do merges from the browser. Do
either GitHub or GitLab provide a way through the web UI to give Guido what
he wants, or will it always require having a checkout and SSH keys set up
in order to do a PR merge? If only Guido can be made happy then that means
either proposal becomes an easy way for people to get code hosting for
their forks and a review tool but not a PR management platform since merges
would occur outside the website and merges would simply be a `git push`
which is basically what we do now to do the final merge for a patch.

The GitLab-specific question is what, if anything, is GitLab prepared to
offer us? Both Nick and Barry have hinted that GitLab would host us, listen
to our needs, etc., but it has always seemed to be speculation. Do we have
concrete information as to what GitLab is willing to do for us?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151201/0978a94d/attachment.html>

From donald at stufft.io  Tue Dec  1 18:32:03 2015
From: donald at stufft.io (Donald Stufft)
Date: Tue, 1 Dec 2015 18:32:03 -0500
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
Message-ID: <40000AA6-F77C-4867-94BF-9618DF1F5A15@stufft.io>


> On Dec 1, 2015, at 6:24 PM, Brett Cannon <brett at python.org> wrote:
> 
> It's Dec 1, which means it's time for any questions people have about the proposed workflows so we can get answers by Dec 15.
> 
> I have one question that applies to both proposals and one specific to GitLab. The general one is whether both Guido and me can both be happy. :) Guido doesn't want intermediate commits nor what he calls "merge turds" to show up in the history. I want to be able to do merges from the browser. Do either GitHub or GitLab provide a way through the web UI to give Guido what he wants, or will it always require having a checkout and SSH keys set up in order to do a PR merge? If only Guido can be made happy then that means either proposal becomes an easy way for people to get code hosting for their forks and a review tool but not a PR management platform since merges would occur outside the website and merges would simply be a `git push` which is basically what we do now to do the final merge for a patch.

As far as I am aware, when you merge with the browser in GitHub it essentially does ``git merge ?no-ff`` which means there will *always* be a merge commit. There?s no support for a rebase workflow (where you rebase the branch ontop of master) or for squash merges or for FF merges.

> 
> The GitLab-specific question is what, if anything, is GitLab prepared to offer us? Both Nick and Barry have hinted that GitLab would host us, listen to our needs, etc., but it has always seemed to be speculation. Do we have concrete information as to what GitLab is willing to do for us?


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151201/0ad98225/attachment.sig>

From guido at python.org  Tue Dec  1 18:53:08 2015
From: guido at python.org (Guido van Rossum)
Date: Tue, 1 Dec 2015 15:53:08 -0800
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
Message-ID: <CAP7+vJJitsOkwyDba-mWfP-o0Ek15w=wQRgoB1EHsDy4TdCjJg@mail.gmail.com>

On Tue, Dec 1, 2015 at 3:24 PM, Brett Cannon <brett at python.org> wrote:

> It's Dec 1, which means it's time for any questions people have about the
> proposed workflows so we can get answers by Dec 15.
>
> I have one question that applies to both proposals and one specific to
> GitLab. The general one is whether both Guido and me can both be happy. :)
> Guido doesn't want intermediate commits nor what he calls "merge turds" to
> show up in the history. I want to be able to do merges from the browser. Do
> either GitHub or GitLab provide a way through the web UI to give Guido what
> he wants, or will it always require having a checkout and SSH keys set up
> in order to do a PR merge? If only Guido can be made happy then that means
> either proposal becomes an easy way for people to get code hosting for
> their forks and a review tool but not a PR management platform since merges
> would occur outside the website and merges would simply be a `git push`
> which is basically what we do now to do the final merge for a patch.
>

Honestly I don't want to stand in the way of progress here. As long as
there is a way to avoid the merge turds when doing the merge from the
command line, I am okay with merge turds existing for merges done from the
website. (A bigger question might be if merging a patch across three
branches will become any easier. At this point I'm reluctant to accept
small asyncio PRs because I have to merge then into 3.4, 3.5 and 3.6. But I
expect that this would be a matter of git command line tricks regardless of
the hosting platform.)


> The GitLab-specific question is what, if anything, is GitLab prepared to
> offer us? Both Nick and Barry have hinted that GitLab would host us, listen
> to our needs, etc., but it has always seemed to be speculation. Do we have
> concrete information as to what GitLab is willing to do for us?
>

in the past we've had such arrangements, and IIRC typically over the years
the hosting company has lost interest. We're better off being hosted on the
default terms by a thriving company than by a company that's just scraping
by offering us an incentive.

Ignoring that, what might GitHub offer?

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151201/c7a75dbf/attachment.html>

From donald at stufft.io  Tue Dec  1 18:58:13 2015
From: donald at stufft.io (Donald Stufft)
Date: Tue, 1 Dec 2015 18:58:13 -0500
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <CAP7+vJJitsOkwyDba-mWfP-o0Ek15w=wQRgoB1EHsDy4TdCjJg@mail.gmail.com>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <CAP7+vJJitsOkwyDba-mWfP-o0Ek15w=wQRgoB1EHsDy4TdCjJg@mail.gmail.com>
Message-ID: <80BD0B71-9C58-4B22-A0A5-E5D8E9D86F3A@stufft.io>


> On Dec 1, 2015, at 6:53 PM, Guido van Rossum <guido at python.org> wrote:
> 
> (A bigger question might be if merging a patch across three branches will become any easier. At this point I'm reluctant to accept small asyncio PRs because I have to merge then into 3.4, 3.5 and 3.6. But I expect that this would be a matter of git command line tricks regardless of the hosting platform.)

If the original PR was to the 3.4 branch, once you merge it you can, in the web ui, create a new PR that merges 3.4 into 3.5, then 3.5 into 3.6. That?s about the best that?s available right now.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151201/a5489262/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151201/a5489262/attachment-0001.sig>

From barry at python.org  Tue Dec  1 20:47:57 2015
From: barry at python.org (Barry Warsaw)
Date: Tue, 1 Dec 2015 20:47:57 -0500
Subject: [core-workflow] Questions about the proposed workflows
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
Message-ID: <20151201204757.1c743395@anarchist.wooz.org>

On Dec 01, 2015, at 11:24 PM, Brett Cannon wrote:

>Guido doesn't want intermediate commits nor what he calls "merge turds" to
>show up in the history. I want to be able to do merges from the browser. Do
>either GitHub or GitLab provide a way through the web UI to give Guido what
>he wants, or will it always require having a checkout and SSH keys set up in
>order to do a PR merge?

I think "merge turds" and intermediate commits are kind of two separate
things and GitLab makes some of what you want possible.

If you don't want a merge commit, you'll want a fast-forward merge, which
basically just moves the HEAD ref forward to the commit at the end of the
source branch.  This might require a rebase if the source branch is behind the
target branch.

With GitLab, under a project's settings, you have an option to only accept
fast-forward merges.  If you enable this, you get a second option to present a
rebase button on accepted merge proposals.  We could enable them both, and
this would allow (but not force) a merge proposal which applies cleanly
(e.g. no conflicts) to be rebased and then fast-forward merged through the web
into the target branch.  Thus, no merge commit.

However I think removing the intermediate commits require an interactive
rebase to squash commits on the source branch.  GitLab doesn't provide a
through-the-web interface to interactive rebases.  You'd have to use the
command line for this, and I often do that when I want to make local cleanups
to the source branch.

>The GitLab-specific question is what, if anything, is GitLab prepared to
>offer us? Both Nick and Barry have hinted that GitLab would host us, listen
>to our needs, etc., but it has always seemed to be speculation. Do we have
>concrete information as to what GitLab is willing to do for us?

I think partly it depends on what we want.  I've thought we wanted a dedicated
VM, running a GitLab CE or EE instance, responding to git{,lab}.python.org.
But I don't know whether we want console/sudo access, we want to run our own
backups, whether that VM would be in our DC or theirs, etc.  Where does the
dial between completely hands-off to self-hosted point?

I've traded a few emails with the CEO of GitLab, who certainly seems eager to
help us, but we haven't sussed out any of these details.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151201/95062305/attachment.sig>

From barry at python.org  Tue Dec  1 20:56:52 2015
From: barry at python.org (Barry Warsaw)
Date: Tue, 1 Dec 2015 20:56:52 -0500
Subject: [core-workflow] Questions about the proposed workflows
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <20151201204757.1c743395@anarchist.wooz.org>
Message-ID: <20151201205652.26f0d41e@anarchist.wooz.org>

On Dec 01, 2015, at 08:47 PM, Barry Warsaw wrote:

>However I think removing the intermediate commits require an interactive
>rebase to squash commits on the source branch.  GitLab doesn't provide a
>through-the-web interface to interactive rebases.  You'd have to use the
>command line for this, and I often do that when I want to make local cleanups
>to the source branch.

Oops, I'm wrong about that.  `git merge` allows for --squash and a quick
search found some reference to this for GitLab, but I don't know whether this
happens automatically or not when the merge is accepted.  I don't see an
option to squash or not squash though, so I'd have to ask.

Cheers,
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151201/8844f185/attachment.sig>

From barry at python.org  Tue Dec  1 21:04:55 2015
From: barry at python.org (Barry Warsaw)
Date: Tue, 1 Dec 2015 21:04:55 -0500
Subject: [core-workflow] Questions about the proposed workflows
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <CAP7+vJJitsOkwyDba-mWfP-o0Ek15w=wQRgoB1EHsDy4TdCjJg@mail.gmail.com>
Message-ID: <20151201210455.2d934ad8@anarchist.wooz.org>

On Dec 01, 2015, at 03:53 PM, Guido van Rossum wrote:

>(A bigger question might be if merging a patch across three branches will
>become any easier. At this point I'm reluctant to accept small asyncio PRs
>because I have to merge then into 3.4, 3.5 and 3.6. But I expect that this
>would be a matter of git command line tricks regardless of the hosting
>platform.)

I think that's true, but I'd love to be wrong about that.  In Mailman 3 we
have the maintenance branch and the devel branch.  Usually bugs get fixed on
devel first, and then I have to manually cherry-pick those comments from the
master branch to the release-3.0 branch.  This usually goes pretty smoothly
except for (dum dum DUMM....) the NEWS file.  I have to resolve those
conflicts manually (Emacs' smerge-mode to the rescue), commit that, and then
push to the origin.

I've found it's usually easier to rebase the original commit onto master so
there's just one commit that needs to be cherry-picked, and I find it's
usually safer to do all this on a topic branch, get that all nice and clean,
and then fast-forward merge onto the maintenance branch.  Git branches are
cheap so this works well - you just don't want to push those temporary topic
branches.

>in the past we've had such arrangements, and IIRC typically over the years
>the hosting company has lost interest. We're better off being hosted on the
>default terms by a thriving company than by a company that's just scraping
>by offering us an incentive.

There are more than a few assumptions in that paragraph that make it difficult
to respond to <wink>.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151201/f4be89c8/attachment.sig>

From barry at python.org  Tue Dec  1 21:09:07 2015
From: barry at python.org (Barry Warsaw)
Date: Tue, 1 Dec 2015 21:09:07 -0500
Subject: [core-workflow] Questions about the proposed workflows
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <CAP7+vJJitsOkwyDba-mWfP-o0Ek15w=wQRgoB1EHsDy4TdCjJg@mail.gmail.com>
 <80BD0B71-9C58-4B22-A0A5-E5D8E9D86F3A@stufft.io>
Message-ID: <20151201210907.1049f34e@anarchist.wooz.org>

On Dec 01, 2015, at 06:58 PM, Donald Stufft wrote:

>If the original PR was to the 3.4 branch, once you merge it you can, in the
>web ui, create a new PR that merges 3.4 into 3.5, then 3.5 into 3.6. That?s
>about the best that?s available right now.

I haven't had much luck with this, but it might be because my bug fixes go to
devel first and then get selectively backported to the maintenance branches.
So a merge in that direction pulls way to much stuff into the latter branch.
Maybe it works better if you go in the other direction (essentially what the
current hg workflow encourages), but the problem is that overwhelmingly
contributions get proposed to the master, i.e. development, branch.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151201/541d4bd9/attachment.sig>

From ncoghlan at gmail.com  Tue Dec  1 23:36:44 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 2 Dec 2015 14:36:44 +1000
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
Message-ID: <CADiSq7fd68kCVeydDx+eF5CYA+A8R92TxooOyBsKFutPfuxy2w@mail.gmail.com>

On 2 December 2015 at 09:24, Brett Cannon <brett at python.org> wrote:
> It's Dec 1, which means it's time for any questions people have about the
> proposed workflows so we can get answers by Dec 15.
>
> I have one question that applies to both proposals and one specific to
> GitLab. The general one is whether both Guido and me can both be happy. :)
> Guido doesn't want intermediate commits nor what he calls "merge turds" to
> show up in the history. I want to be able to do merges from the browser. Do
> either GitHub or GitLab provide a way through the web UI to give Guido what
> he wants, or will it always require having a checkout and SSH keys set up in
> order to do a PR merge? If only Guido can be made happy then that means
> either proposal becomes an easy way for people to get code hosting for their
> forks and a review tool but not a PR management platform since merges would
> occur outside the website and merges would simply be a `git push` which is
> basically what we do now to do the final merge for a patch.

GitLab Enterprise Edition has a fast-forward-only merge option that
disallows merge commits on the target branch:
http://doc.gitlab.com/ee/workflow/ff_merge.html
That then further enables rebasing of merge requests via the browser:
http://doc.gitlab.com/ee/workflow/rebase_before_merge.html

> The GitLab-specific question is what, if anything, is GitLab prepared to
> offer us? Both Nick and Barry have hinted that GitLab would host us, listen
> to our needs, etc., but it has always seemed to be speculation. Do we have
> concrete information as to what GitLab is willing to do for us?

I'll leave answering that to Barry, since he's the one that's actually
been talking to the GitLab folks :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From berker.peksag at gmail.com  Wed Dec  2 06:42:13 2015
From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=)
Date: Wed, 2 Dec 2015 13:42:13 +0200
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
Message-ID: <CAF4280+J=gELqzX5mpEGFif5DposF1+Bw5PDkpPmhcbxKMOdDA@mail.gmail.com>

On Wed, Dec 2, 2015 at 1:24 AM, Brett Cannon <brett at python.org> wrote:
> It's Dec 1, which means it's time for any questions people have about the
> proposed workflows so we can get answers by Dec 15.
>
> I have one question that applies to both proposals and one specific to
> GitLab. The general one is whether both Guido and me can both be happy. :)
> Guido doesn't want intermediate commits nor what he calls "merge turds" to
> show up in the history. I want to be able to do merges from the browser. Do

I agree with Guido. --no-ff merge is probably the only GitHub feature
that I really dislike. It would be good to have a GitHub bot to handle
ff merges.

For example, with a bot, a core developer can add one of the following
comments to merge the PR;

    @biggles merge  # merges into master

    @biggles merge 3.5+  # merges into 3.5 and master (or merges into
master then cherry-pick it to 3.5)

This will also solve the pull request and email flood problem since a
contributor won't have to open N pull requests if their patch needs to
be backported to maintenance branches.

I will have some spare time to work on such a tool in the next months.

--Berker

From brett at python.org  Wed Dec  2 13:34:49 2015
From: brett at python.org (Brett Cannon)
Date: Wed, 02 Dec 2015 18:34:49 +0000
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <CAF4280+J=gELqzX5mpEGFif5DposF1+Bw5PDkpPmhcbxKMOdDA@mail.gmail.com>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <CAF4280+J=gELqzX5mpEGFif5DposF1+Bw5PDkpPmhcbxKMOdDA@mail.gmail.com>
Message-ID: <CAP1=2W6LSdDx0aHHomSy+Ldb3PBHnX5K1RN_xa06CN5UqH7nPA@mail.gmail.com>

On Wed, 2 Dec 2015 at 03:42 Berker Peksa? <berker.peksag at gmail.com> wrote:

> On Wed, Dec 2, 2015 at 1:24 AM, Brett Cannon <brett at python.org> wrote:
> > It's Dec 1, which means it's time for any questions people have about the
> > proposed workflows so we can get answers by Dec 15.
> >
> > I have one question that applies to both proposals and one specific to
> > GitLab. The general one is whether both Guido and me can both be happy.
> :)
> > Guido doesn't want intermediate commits nor what he calls "merge turds"
> to
> > show up in the history. I want to be able to do merges from the browser.
> Do
>
> I agree with Guido. --no-ff merge is probably the only GitHub feature
> that I really dislike. It would be good to have a GitHub bot to handle
> ff merges.
>
> For example, with a bot, a core developer can add one of the following
> comments to merge the PR;
>
>     @biggles merge  # merges into master
>
>     @biggles merge 3.5+  # merges into 3.5 and master (or merges into
> master then cherry-pick it to 3.5)
>
> This will also solve the pull request and email flood problem since a
> contributor won't have to open N pull requests if their patch needs to
> be backported to maintenance branches.
>

I was actually wondering if this was possible just last night. :) Do both
GitHub and GitLab have the appropriate APIs to support something like this?
It would be fantastic if a bot can get Guido the style of commits he wants
while letting us trigger the merges through the browser (especially since a
bot is nice, but we don't have to feel like we are stranded if it goes down
since old-school solution of manual merges would still be possible). And
could the bot, when told to cherry-pick/merge into another branch, create a
PR if there is a merge conflict so that it can be fixed in a checkout and
not lost track of? Otherwise at least leave a message in the PR that stated
what versions to commit to that failed and hence not close the PR until all
branches are properly handled?

And this bot doesn't have to do it, but we should definitely make sure we
have at least automated testing of all PRs on *some* OS and also a way to
verify the PR contributor signed the CLA (the testing should be easy enough
on either and the CLA should be doable somehow).


>
> I will have some spare time to work on such a tool in the next months.
>

Great! Let's choose the platform first -- I'm aiming for Jan 1 -- and then
if you still have time, Berker, it would be great if you can help with the
tool. But we can definitely discuss potential workflows and what the bot
would need to do now since that's probably platform-agnostic to make sure
this is a tenable solution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151202/b245f3d6/attachment.html>

From rdmurray at bitdance.com  Wed Dec  2 13:50:07 2015
From: rdmurray at bitdance.com (R. David Murray)
Date: Wed, 02 Dec 2015 13:50:07 -0500
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <CAP1=2W6LSdDx0aHHomSy+Ldb3PBHnX5K1RN_xa06CN5UqH7nPA@mail.gmail.com>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <CAF4280+J=gELqzX5mpEGFif5DposF1+Bw5PDkpPmhcbxKMOdDA@mail.gmail.com>
 <CAP1=2W6LSdDx0aHHomSy+Ldb3PBHnX5K1RN_xa06CN5UqH7nPA@mail.gmail.com>
Message-ID: <20151202185007.6190DB1408E@webabinitio.net>

On Wed, 02 Dec 2015 18:34:49 +0000, Brett Cannon <brett at python.org> wrote:
> And this bot doesn't have to do it, but we should definitely make sure we
> have at least automated testing of all PRs on *some* OS and also a way to

Kushal did some work in this direction (for unix builds), but we haven't
done anything with it for a while.

> verify the PR contributor signed the CLA (the testing should be easy enough
> on either and the CLA should be doable somehow).

This should be easy enough to do via the xmlrpc interface to the tracker, or
(better) the rest interface if/when it lands.

--David

From brett at python.org  Wed Dec  2 13:58:34 2015
From: brett at python.org (Brett Cannon)
Date: Wed, 02 Dec 2015 18:58:34 +0000
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <20151202185007.6190DB1408E@webabinitio.net>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <CAF4280+J=gELqzX5mpEGFif5DposF1+Bw5PDkpPmhcbxKMOdDA@mail.gmail.com>
 <CAP1=2W6LSdDx0aHHomSy+Ldb3PBHnX5K1RN_xa06CN5UqH7nPA@mail.gmail.com>
 <20151202185007.6190DB1408E@webabinitio.net>
Message-ID: <CAP1=2W5UqpBUQezvdEPX6x0Z9W9McTNZ4vtO3y2fygzKVW5J+A@mail.gmail.com>

On Wed, 2 Dec 2015 at 10:50 R. David Murray <rdmurray at bitdance.com> wrote:

> On Wed, 02 Dec 2015 18:34:49 +0000, Brett Cannon <brett at python.org> wrote:
> > And this bot doesn't have to do it, but we should definitely make sure we
> > have at least automated testing of all PRs on *some* OS and also a way to
>
> Kushal did some work in this direction (for unix builds), but we haven't
> done anything with it for a while.
>

Donald hooked up Travis to the GitHub test instance and runs the PRs using
both gcc and clang, so I know at least GitHub + Travis has us covered.
Barry has said that GitLab supports runners but you have to run them
yourselves. I would also be curious to know if we could get a test coverage
report somehow (e.g., can coveralls.io support be added and have it use
https://bitbucket.org/ned/coveragepy/src/787158b1da024fd57b9a4f05c35042b7cdbe74a1/coverage/fullcoverage/encodings.py
which
requires a checkout of coverage.py).


>
> > verify the PR contributor signed the CLA (the testing should be easy
> enough
> > on either and the CLA should be doable somehow).
>
> This should be easy enough to do via the xmlrpc interface to the tracker,
> or
> (better) the rest interface if/when it lands.
>

I guess it would simply require people to add their GitHub IDs to their
issue tracker profile. We probably should also make sure the process gets
as automated as possible as I think Ewa still flips some bits manually.

-Brett


>
> --David
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct:
> https://www.python.org/psf/codeofconduct
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151202/38ccca7b/attachment.html>

From donald at stufft.io  Wed Dec  2 14:03:33 2015
From: donald at stufft.io (Donald Stufft)
Date: Wed, 2 Dec 2015 14:03:33 -0500
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <CAP1=2W5UqpBUQezvdEPX6x0Z9W9McTNZ4vtO3y2fygzKVW5J+A@mail.gmail.com>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <CAF4280+J=gELqzX5mpEGFif5DposF1+Bw5PDkpPmhcbxKMOdDA@mail.gmail.com>
 <CAP1=2W6LSdDx0aHHomSy+Ldb3PBHnX5K1RN_xa06CN5UqH7nPA@mail.gmail.com>
 <20151202185007.6190DB1408E@webabinitio.net>
 <CAP1=2W5UqpBUQezvdEPX6x0Z9W9McTNZ4vtO3y2fygzKVW5J+A@mail.gmail.com>
Message-ID: <E74AADF4-9177-4EB4-84B2-7430EA7043C9@stufft.io>


> On Dec 2, 2015, at 1:58 PM, Brett Cannon <brett at python.org> wrote:
> 
> 
> 
> On Wed, 2 Dec 2015 at 10:50 R. David Murray <rdmurray at bitdance.com <mailto:rdmurray at bitdance.com>> wrote:
> On Wed, 02 Dec 2015 18:34:49 +0000, Brett Cannon <brett at python.org <mailto:brett at python.org>> wrote:
> > And this bot doesn't have to do it, but we should definitely make sure we
> > have at least automated testing of all PRs on *some* OS and also a way to
> 
> Kushal did some work in this direction (for unix builds), but we haven't
> done anything with it for a while.
> 
> Donald hooked up Travis to the GitHub test instance and runs the PRs using both gcc and clang, so I know at least GitHub + Travis has us covered. Barry has said that GitLab supports runners but you have to run them yourselves. I would also be curious to know if we could get a test coverage report somehow (e.g., can coveralls.io <http://coveralls.io/> support be added and have it use https://bitbucket.org/ned/coveragepy/src/787158b1da024fd57b9a4f05c35042b7cdbe74a1/coverage/fullcoverage/encodings.py <https://bitbucket.org/ned/coveragepy/src/787158b1da024fd57b9a4f05c35042b7cdbe74a1/coverage/fullcoverage/encodings.py> which requires a checkout of coverage.py).

I tried to setup coverage reports via https://codecov.io but I didn?t know how to make it work with CPython. It looked like there was some support in the Makefile but that didn?t seem to work out so well. It also supports C coverage too but I?ve never used it.

> 
> 
> > verify the PR contributor signed the CLA (the testing should be easy enough
> > on either and the CLA should be doable somehow).
> 
> This should be easy enough to do via the xmlrpc interface to the tracker, or
> (better) the rest interface if/when it lands.
> 
> I guess it would simply require people to add their GitHub IDs to their issue tracker profile. We probably should also make sure the process gets as automated as possible as I think Ewa still flips some bits manually.

With a tiny little shim server, you?d be able to make a status check that shows whether or not a PR is covered by the CLA or not. It?d be similar to Travis except instead of checking out the code and running tests, it?d just check for CLA status and report back.

> 
> -Brett
> 
> 
> --David
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org <mailto:core-workflow at python.org>
> https://mail.python.org/mailman/listinfo/core-workflow <https://mail.python.org/mailman/listinfo/core-workflow>
> This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct <https://www.python.org/psf/codeofconduct>
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151202/c7c858ba/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151202/c7c858ba/attachment-0001.sig>

From barry at python.org  Wed Dec  2 14:17:32 2015
From: barry at python.org (Barry Warsaw)
Date: Wed, 2 Dec 2015 14:17:32 -0500
Subject: [core-workflow] Questions about the proposed workflows
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <CAF4280+J=gELqzX5mpEGFif5DposF1+Bw5PDkpPmhcbxKMOdDA@mail.gmail.com>
 <CAP1=2W6LSdDx0aHHomSy+Ldb3PBHnX5K1RN_xa06CN5UqH7nPA@mail.gmail.com>
 <20151202185007.6190DB1408E@webabinitio.net>
 <CAP1=2W5UqpBUQezvdEPX6x0Z9W9McTNZ4vtO3y2fygzKVW5J+A@mail.gmail.com>
Message-ID: <20151202141732.32cf7a2c@anarchist.wooz.org>

On Dec 02, 2015, at 06:58 PM, Brett Cannon wrote:

>Barry has said that GitLab supports runners but you have to run them
>yourselves.

There are now some shared runners that we can probably use.  I haven't had
much time to investigate them though.

Cheers,
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151202/4d857a54/attachment.sig>

From rdmurray at bitdance.com  Wed Dec  2 14:21:44 2015
From: rdmurray at bitdance.com (R. David Murray)
Date: Wed, 02 Dec 2015 14:21:44 -0500
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <CAP1=2W5UqpBUQezvdEPX6x0Z9W9McTNZ4vtO3y2fygzKVW5J+A@mail.gmail.com>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <CAF4280+J=gELqzX5mpEGFif5DposF1+Bw5PDkpPmhcbxKMOdDA@mail.gmail.com>
 <CAP1=2W6LSdDx0aHHomSy+Ldb3PBHnX5K1RN_xa06CN5UqH7nPA@mail.gmail.com>
 <20151202185007.6190DB1408E@webabinitio.net>
 <CAP1=2W5UqpBUQezvdEPX6x0Z9W9McTNZ4vtO3y2fygzKVW5J+A@mail.gmail.com>
Message-ID: <20151202192145.4688BB1408E@webabinitio.net>

On Wed, 02 Dec 2015 18:58:34 +0000, Brett Cannon <brett at python.org> wrote:
> On Wed, 2 Dec 2015 at 10:50 R. David Murray <rdmurray at bitdance.com> wrote:
> 
> > On Wed, 02 Dec 2015 18:34:49 +0000, Brett Cannon <brett at python.org> wrote:
> > > And this bot doesn't have to do it, but we should definitely make sure we
> > > have at least automated testing of all PRs on *some* OS and also a way to
> >
> > Kushal did some work in this direction (for unix builds), but we haven't
> > done anything with it for a while.
> 
> Donald hooked up Travis to the GitHub test instance and runs the PRs using
> both gcc and clang, so I know at least GitHub + Travis has us covered.
> Barry has said that GitLab supports runners but you have to run them
> yourselves. I would also be curious to know if we could get a test coverage
> report somehow (e.g., can coveralls.io support be added and have it use
> https://bitbucket.org/ned/coveragepy/src/787158b1da024fd57b9a4f05c35042b7cdbe74a1/coverage/fullcoverage/encodings.py
> which
> requires a checkout of coverage.py).

That's interesting.  I thought someone had already tried travis and our
test suite took too long to run.  Sounds like Kushal's stuff could be
hooked up to gitlab.

> > > verify the PR contributor signed the CLA (the testing should be easy
> > enough
> > > on either and the CLA should be doable somehow).
> >
> > This should be easy enough to do via the xmlrpc interface to the tracker,
> > or
> > (better) the rest interface if/when it lands.
> >
> 
> I guess it would simply require people to add their GitHub IDs to their
> issue tracker profile. We probably should also make sure the process gets

I don't think so.  For doing the commit-to-contrib association it seems to
me we should be looking at the VCS id, not the github id.  Since the VCS
id is supposed to be an email address, it can just go in the 'additional
email address' box in the tracker profile.  Or the primary.

> as automated as possible as I think Ewa still flips some bits manually.

Last I heard this was more policy than lack of infrastructure; I don't
know if that has changed.  But even if it is policy that Ewa (or her
delegate; I think someone else is doing the actual data entry now)
has to push the button, we could at least make it a single button.

--David

From donald at stufft.io  Wed Dec  2 14:23:41 2015
From: donald at stufft.io (Donald Stufft)
Date: Wed, 2 Dec 2015 14:23:41 -0500
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <20151202192145.4688BB1408E@webabinitio.net>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <CAF4280+J=gELqzX5mpEGFif5DposF1+Bw5PDkpPmhcbxKMOdDA@mail.gmail.com>
 <CAP1=2W6LSdDx0aHHomSy+Ldb3PBHnX5K1RN_xa06CN5UqH7nPA@mail.gmail.com>
 <20151202185007.6190DB1408E@webabinitio.net>
 <CAP1=2W5UqpBUQezvdEPX6x0Z9W9McTNZ4vtO3y2fygzKVW5J+A@mail.gmail.com>
 <20151202192145.4688BB1408E@webabinitio.net>
Message-ID: <A30D5E59-F24D-4050-99D3-2A5E924495B0@stufft.io>


> On Dec 2, 2015, at 2:21 PM, R. David Murray <rdmurray at bitdance.com> wrote:
> 
> That's interesting.  I thought someone had already tried travis and our
> test suite took too long to run.  Sounds like Kushal's stuff could be
> hooked up to gitlab.

Unless I did it wrong, the tests took 11 minutes to run, Travis allows up to 50.

https://travis-ci.org/fake-python/cpython/jobs/89432399

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151202/0965ea47/attachment.sig>

From rdmurray at bitdance.com  Wed Dec  2 14:45:28 2015
From: rdmurray at bitdance.com (R. David Murray)
Date: Wed, 02 Dec 2015 14:45:28 -0500
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <A30D5E59-F24D-4050-99D3-2A5E924495B0@stufft.io>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <CAF4280+J=gELqzX5mpEGFif5DposF1+Bw5PDkpPmhcbxKMOdDA@mail.gmail.com>
 <CAP1=2W6LSdDx0aHHomSy+Ldb3PBHnX5K1RN_xa06CN5UqH7nPA@mail.gmail.com>
 <20151202185007.6190DB1408E@webabinitio.net>
 <CAP1=2W5UqpBUQezvdEPX6x0Z9W9McTNZ4vtO3y2fygzKVW5J+A@mail.gmail.com>
 <20151202192145.4688BB1408E@webabinitio.net>
 <A30D5E59-F24D-4050-99D3-2A5E924495B0@stufft.io>
Message-ID: <20151202194534.4B347B1408E@webabinitio.net>

On Wed, 02 Dec 2015 14:23:41 -0500, Donald Stufft <donald at stufft.io> wrote:
> 
> > On Dec 2, 2015, at 2:21 PM, R. David Murray <rdmurray at bitdance.com> wrote:
> > 
> > That's interesting.  I thought someone had already tried travis and our
> > test suite took too long to run.  Sounds like Kushal's stuff could be
> > hooked up to gitlab.
> 
> Unless I did it wrong, the tests took 11 minutes to run, Travis allows up to 50.
> 
> https://travis-ci.org/fake-python/cpython/jobs/89432399

That looks OK.  Maybe they changed their limits?  50 sounds way longer
than I remember whoever it was (Kushal?) quoting.

--David

From donald at stufft.io  Wed Dec  2 14:47:31 2015
From: donald at stufft.io (Donald Stufft)
Date: Wed, 2 Dec 2015 14:47:31 -0500
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <20151202194534.4B347B1408E@webabinitio.net>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <CAF4280+J=gELqzX5mpEGFif5DposF1+Bw5PDkpPmhcbxKMOdDA@mail.gmail.com>
 <CAP1=2W6LSdDx0aHHomSy+Ldb3PBHnX5K1RN_xa06CN5UqH7nPA@mail.gmail.com>
 <20151202185007.6190DB1408E@webabinitio.net>
 <CAP1=2W5UqpBUQezvdEPX6x0Z9W9McTNZ4vtO3y2fygzKVW5J+A@mail.gmail.com>
 <20151202192145.4688BB1408E@webabinitio.net>
 <A30D5E59-F24D-4050-99D3-2A5E924495B0@stufft.io>
 <20151202194534.4B347B1408E@webabinitio.net>
Message-ID: <68B240FB-B011-440B-9128-E09AEDCC2A59@stufft.io>


> On Dec 2, 2015, at 2:45 PM, R. David Murray <rdmurray at bitdance.com> wrote:
> 
> On Wed, 02 Dec 2015 14:23:41 -0500, Donald Stufft <donald at stufft.io> wrote:
>> 
>>> On Dec 2, 2015, at 2:21 PM, R. David Murray <rdmurray at bitdance.com> wrote:
>>> 
>>> That's interesting.  I thought someone had already tried travis and our
>>> test suite took too long to run.  Sounds like Kushal's stuff could be
>>> hooked up to gitlab.
>> 
>> Unless I did it wrong, the tests took 11 minutes to run, Travis allows up to 50.
>> 
>> https://travis-ci.org/fake-python/cpython/jobs/89432399
> 
> That looks OK.  Maybe they changed their limits?  50 sounds way longer
> than I remember whoever it was (Kushal?) quoting.
> 

It?s been 50 minutes for as long as I can remember, but there is an additional limit of 10 minutes without any output, so if it was being run in a way that didn?t cause output to occur for 10 minutes it?d get killed.


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151202/3825038f/attachment.sig>

From ncoghlan at gmail.com  Mon Dec  7 21:46:29 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 8 Dec 2015 12:46:29 +1000
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
Message-ID: <CADiSq7e2-X7JPihXy1Wxuc9tBa+NO=S+1xuo25d9uymenehxtA@mail.gmail.com>

On 2 December 2015 at 09:24, Brett Cannon <brett at python.org> wrote:
> The GitLab-specific question is what, if anything, is GitLab prepared to
> offer us? Both Nick and Barry have hinted that GitLab would host us, listen
> to our needs, etc., but it has always seemed to be speculation. Do we have
> concrete information as to what GitLab is willing to do for us?

Something I've been pondering recently is whether we might be able to
"have our cake and eat it too", by setting up the workflow to use
GitHub to facilitate easy contributions by folks with a GitHub account
(and allowing folks that don't want a GitHub account to continue
uploading patches to the tracker), while using GitLab to continue to
host the master repository used to make releases on a *.python.org
subdomain.

The main prompt for that thought is the fact that, with the 8.2
release, GitLab introduced repository mirroring as a first class
feature in the Enterprise Edition:
https://about.gitlab.com/2015/11/22/gitlab-8-2-released/

With that setup, development work would happen on GitHub and Roundup,
while release management work would mostly happen on GitLab,
docs.python.org and www.python.org.

The question for GitLab then would be whether or not bidirectional
syncing of pull requests/merge requests between GitHub & GitLab is on
their radar as a possible future feature (one-way syncing is already
possible, through projects like
https://pypi.python.org/pypi/github2gitlab )

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From barry at python.org  Tue Dec  8 10:41:57 2015
From: barry at python.org (Barry Warsaw)
Date: Tue, 8 Dec 2015 10:41:57 -0500
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <CADiSq7e2-X7JPihXy1Wxuc9tBa+NO=S+1xuo25d9uymenehxtA@mail.gmail.com>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <CADiSq7e2-X7JPihXy1Wxuc9tBa+NO=S+1xuo25d9uymenehxtA@mail.gmail.com>
Message-ID: <20151208104157.450b0069@anarchist.wooz.org>

On Dec 08, 2015, at 12:46 PM, Nick Coghlan wrote:

>Something I've been pondering recently is whether we might be able to
>"have our cake and eat it too", by setting up the workflow to use
>GitHub to facilitate easy contributions by folks with a GitHub account
>(and allowing folks that don't want a GitHub account to continue
>uploading patches to the tracker), while using GitLab to continue to
>host the master repository used to make releases on a *.python.org
>subdomain.
>
>The main prompt for that thought is the fact that, with the 8.2
>release, GitLab introduced repository mirroring as a first class
>feature in the Enterprise Edition:
>https://about.gitlab.com/2015/11/22/gitlab-8-2-released/
>
>With that setup, development work would happen on GitHub and Roundup,
>while release management work would mostly happen on GitLab,
>docs.python.org and www.python.org.
>
>The question for GitLab then would be whether or not bidirectional
>syncing of pull requests/merge requests between GitHub & GitLab is on
>their radar as a possible future feature (one-way syncing is already
>possible, through projects like
>https://pypi.python.org/pypi/github2gitlab )

I don't know the answer to the latter, but I do think the repository mirroring
feature could help us here.  If we do this though, why wouldn't we also accept
merge requests on the gitlab instance?

I guess the problem is that if only gitlab can mirror, then commits to the
gitlab repo have to be manually pushed to github.  Maybe a webhook can
automate that for us.  The trick will be ensuring that we don't get into a
situation where there are conflicts when mirroring.  That can happen if
changes are merged to both the github and gitlab repos.  So I think one of
them has to the be the canonical origin and the other a mirror.

As far as processing pull requests or merge requests, I don't think it much
matters.  Someone could submit a pull request on github and it can be easily
(though, not automatically) merged into a gitlab origin repo.  What we can't
do (I think) is let Alice commit and push to github while Bob commits and
pushes to gitlab.  Now we've got DAGs that probably needs manual
reconciliation.  I think we could handle that with protected branches so
*only* mirroring will be allowed in the unofficial direction.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151208/379ca9ea/attachment.sig>

From brett at python.org  Thu Dec 10 22:27:16 2015
From: brett at python.org (Brett Cannon)
Date: Fri, 11 Dec 2015 03:27:16 +0000
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <20151201204757.1c743395@anarchist.wooz.org>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <20151201204757.1c743395@anarchist.wooz.org>
Message-ID: <CAP1=2W7NBCgX-NU6HmB2cLiBkEK5oxbJ_FZbNC7KzcjKqHA_SQ@mail.gmail.com>

Any news from the gitlab CEO about what they will offer and what the plan
is? I'm still aiming to get everything squared away by Dec 15 so I have 2
weeks to think things through.

On Tue, 1 Dec 2015, 17:48 Barry Warsaw <barry at python.org> wrote:

> On Dec 01, 2015, at 11:24 PM, Brett Cannon wrote:
>
> >Guido doesn't want intermediate commits nor what he calls "merge turds" to
> >show up in the history. I want to be able to do merges from the browser.
> Do
> >either GitHub or GitLab provide a way through the web UI to give Guido
> what
> >he wants, or will it always require having a checkout and SSH keys set up
> in
> >order to do a PR merge?
>
> I think "merge turds" and intermediate commits are kind of two separate
> things and GitLab makes some of what you want possible.
>
> If you don't want a merge commit, you'll want a fast-forward merge, which
> basically just moves the HEAD ref forward to the commit at the end of the
> source branch.  This might require a rebase if the source branch is behind
> the
> target branch.
>
> With GitLab, under a project's settings, you have an option to only accept
> fast-forward merges.  If you enable this, you get a second option to
> present a
> rebase button on accepted merge proposals.  We could enable them both, and
> this would allow (but not force) a merge proposal which applies cleanly
> (e.g. no conflicts) to be rebased and then fast-forward merged through the
> web
> into the target branch.  Thus, no merge commit.
>
> However I think removing the intermediate commits require an interactive
> rebase to squash commits on the source branch.  GitLab doesn't provide a
> through-the-web interface to interactive rebases.  You'd have to use the
> command line for this, and I often do that when I want to make local
> cleanups
> to the source branch.
>
> >The GitLab-specific question is what, if anything, is GitLab prepared to
> >offer us? Both Nick and Barry have hinted that GitLab would host us,
> listen
> >to our needs, etc., but it has always seemed to be speculation. Do we have
> >concrete information as to what GitLab is willing to do for us?
>
> I think partly it depends on what we want.  I've thought we wanted a
> dedicated
> VM, running a GitLab CE or EE instance, responding to git{,lab}.python.org
> .
> But I don't know whether we want console/sudo access, we want to run our
> own
> backups, whether that VM would be in our DC or theirs, etc.  Where does the
> dial between completely hands-off to self-hosted point?
>
> I've traded a few emails with the CEO of GitLab, who certainly seems eager
> to
> help us, but we haven't sussed out any of these details.
>
> Cheers,
> -Barry
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct:
> https://www.python.org/psf/codeofconduct
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151211/e2142405/attachment.html>

From ncoghlan at gmail.com  Fri Dec 11 02:26:51 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 11 Dec 2015 17:26:51 +1000
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <20151208104157.450b0069@anarchist.wooz.org>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <CADiSq7e2-X7JPihXy1Wxuc9tBa+NO=S+1xuo25d9uymenehxtA@mail.gmail.com>
 <20151208104157.450b0069@anarchist.wooz.org>
Message-ID: <CADiSq7dBMw=Hpynw-XhGZE3wPhnjwUwzi_g7vNSkP-=LKd2yoA@mail.gmail.com>

On 9 December 2015 at 01:41, Barry Warsaw <barry at python.org> wrote:
> As far as processing pull requests or merge requests, I don't think it much
> matters.  Someone could submit a pull request on github and it can be easily
> (though, not automatically) merged into a gitlab origin repo.  What we can't
> do (I think) is let Alice commit and push to github while Bob commits and
> pushes to gitlab.  Now we've got DAGs that probably needs manual
> reconciliation.  I think we could handle that with protected branches so
> *only* mirroring will be allowed in the unofficial direction.

The github2gitlab project I linked automatically converts GitHub PRs
to GitLab MRs, so if we have GitLab as the master, then people would
still be able to submit PRs on GitHub, core developers just couldn't
accept them there (acceptance would need to happen in GitLab).

The two simplest approaches being considered are "all GitHub" and "all
GitLab". Any hybrid approach would necessarily be more complex, but
may be worth it if it lets us gain the pros of both GitHub and GitLab,
while also mitigating their cons.

For the "one-off patch" case, I think we want to support at least the following:

* upload a patch to bugs.python.org (as today)
* submit a PR on GitHub (since that's what many intro workshops teach people)

If GitLab is in the mix, then we'd have to ask whether or not we also
wanted to support "submit an MR on GitLab". The reason that question
matters, is that there are two main approaches to combining the two
solutions:

* GitHub-as-origin with read-only GitLab mirror
* GitLab-as-origin with GitHub mirror (and mirrored PRs)

GitHub-as-origin triggers the main con of that approach: every
contributor (including core developers) needs a GitHub account if they
want to benefit from the streamlined workflow. With that approach, I'm
not sure we'd gain enough over the "GitHub only" approach for it to be
worth the additional hassle.

GitLab-as-origin, however, at least mitigates the main con of the
GitLab approach, by still enabling casual contributions (e.g. to fix
typos) from folks with GitHub accounts that don't want to learn a new
workflow. Actually setting that up would require two additions:

1. A git hook installed on the GitLab server to push commits to the
main branches back to GitHub
2. A script akin to the PR->MR component of github2gitlab to create
and update MRs based on GitHub PRs

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From barry at python.org  Fri Dec 11 10:32:51 2015
From: barry at python.org (Barry Warsaw)
Date: Fri, 11 Dec 2015 10:32:51 -0500
Subject: [core-workflow] Questions about the proposed workflows
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <20151201204757.1c743395@anarchist.wooz.org>
 <CAP1=2W7NBCgX-NU6HmB2cLiBkEK5oxbJ_FZbNC7KzcjKqHA_SQ@mail.gmail.com>
Message-ID: <20151211103251.11d3a389@anarchist.wooz.org>

On Dec 11, 2015, at 03:27 AM, Brett Cannon wrote:

>Any news from the gitlab CEO about what they will offer and what the plan
>is? I'm still aiming to get everything squared away by Dec 15 so I have 2
>weeks to think things through.

Brett, see my question from 01-Dec - I think we should still try to outline
what we want before we approach GitLab with our detailed request.  I want to
avoid the inevitable "What will you offer us?"  "Well, what do you want?"
back and forth.

Also, as PEP 481 is still in contention as the alternative, it still mentions
Phabricator which I believe is off the table, so that PEP needs an update.

And afaik, none of the workflow PEPs actually describe Nick's HOCAEIT
suggestion for getting the best out of both GitLab and GitHub.

I know you want to make a decision soon, but IMHO we need to get these issues
resolved before we can move forward.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151211/9906f897/attachment.sig>

From brett at python.org  Fri Dec 11 19:24:59 2015
From: brett at python.org (Brett Cannon)
Date: Sat, 12 Dec 2015 00:24:59 +0000
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <20151211103251.11d3a389@anarchist.wooz.org>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <20151201204757.1c743395@anarchist.wooz.org>
 <CAP1=2W7NBCgX-NU6HmB2cLiBkEK5oxbJ_FZbNC7KzcjKqHA_SQ@mail.gmail.com>
 <20151211103251.11d3a389@anarchist.wooz.org>
Message-ID: <CAP1=2W4YVRu9w1Y-XAA7ibtcpGrpONhfdTD83ZW3zG06xWPq-Q@mail.gmail.com>

On Fri, 11 Dec 2015 at 07:33 Barry Warsaw <barry at python.org> wrote:

> On Dec 11, 2015, at 03:27 AM, Brett Cannon wrote:
>
> >Any news from the gitlab CEO about what they will offer and what the plan
> >is? I'm still aiming to get everything squared away by Dec 15 so I have 2
> >weeks to think things through.
>
> Brett, see my question from 01-Dec -


I think you mean this:
"""
I think partly it depends on what we want.  I've thought we wanted a
dedicated
VM, running a GitLab CE or EE instance, responding to git{,lab}.python.org.
But I don't know whether we want console/sudo access, we want to run our own
backups, whether that VM would be in our DC or theirs, etc.  Where does the
dial between completely hands-off to self-hosted point?
"""


> I think we should still try to outline
> what we want before we approach GitLab with our detailed request.  I want
> to
> avoid the inevitable "What will you offer us?"  "Well, what do you want?"
> back and forth.
>

The whole point of this process of having champions is you and Nick were
supposed to figure that out and present to me the best solution. :)

If you want some input from me, then I want to know if they will give us
professional hosting and would they give us an EE license (hosted by them
or self-hosted by us).


>
> Also, as PEP 481 is still in contention as the alternative, it still
> mentions
> Phabricator which I believe is off the table, so that PEP needs an update.
>

Donald already mentioned Phabricator was yanked; I basically just consider
it "GitHub" anyway. Donald's bought a new house and just moved so I won't
hold it against him for not taking the time to rush to update the PEP when
I personally know what he is currently proposing.


>
> And afaik, none of the workflow PEPs actually describe Nick's HOCAEIT
>

The what now? I don't know that acronym and Inbox couldn't find any other
reference to it in any other email.


> suggestion for getting the best out of both GitLab and GitHub.
>
> I know you want to make a decision soon, but IMHO we need to get these
> issues
> resolved before we can move forward.
>

Yes, but we have all known Nick long enough to know that he will just keep
coming up with ideas so I can't leave it open indefinitely. :) I can push
out the discussions for longer but I'm still aiming to make my decision by
January 1.

If people want a quick summary of what's bouncing around in my brain at the
moment (which means you can't hold me to this):

   -  People are familiar with GitHub (although obviously people can learn)
   - github.com has much better performance than gitlab.com (but that might
   be moot if we get professional hosting)
   - Guido prefers GitHub (which I know Guido will say shouldn't really
   matter too much but it matters to me somewhat)
   - GitLab does offer more account login flexibility (this is weak,
   though, since practically everyone has a GitHub account already, and if we
   still accept patches via bugs.python.org then it really doesn't matter)
   - GitLab's enterprise features for fast-forward and rebasing is
   intriguing (although solving the long-lived branch problem will probably
   require some bot work which makes the built-in FF/rebase stuff a lot less
   useful on their own)
   - I'm not enthralled with the idea of trying to attempt any
   bi-directional coordination between GitHub and GitLab
   - Even uni-directional coordination seems like it might be more hassle
   than it's worth (what's the point of telling people "GitHub is totally
   fine" and then having it all mirrored to GitLab, along with all of the
   technical maintenance and complications? Just to avoid upsetting some
   people from having to use GitHub since the existence of the tooling means
   we don't have to worry about vendor lock-in?)

As you can see, pretty much everything has an exception to make this all
very murky. Pity me. :P
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151212/d421d5cb/attachment.html>

From ncoghlan at gmail.com  Fri Dec 11 23:57:57 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 12 Dec 2015 14:57:57 +1000
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <CAP1=2W4YVRu9w1Y-XAA7ibtcpGrpONhfdTD83ZW3zG06xWPq-Q@mail.gmail.com>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <20151201204757.1c743395@anarchist.wooz.org>
 <CAP1=2W7NBCgX-NU6HmB2cLiBkEK5oxbJ_FZbNC7KzcjKqHA_SQ@mail.gmail.com>
 <20151211103251.11d3a389@anarchist.wooz.org>
 <CAP1=2W4YVRu9w1Y-XAA7ibtcpGrpONhfdTD83ZW3zG06xWPq-Q@mail.gmail.com>
Message-ID: <CADiSq7ed0JG7JV3RBiZPiDk1zJ5aGqeNOpBcffZUVScF+4VFmA@mail.gmail.com>

On 12 December 2015 at 10:24, Brett Cannon <brett at python.org> wrote:
> On Fri, 11 Dec 2015 at 07:33 Barry Warsaw <barry at python.org> wrote:
>> I know you want to make a decision soon, but IMHO we need to get these
>> issues
>> resolved before we can move forward.
>
> Yes, but we have all known Nick long enough to know that he will just keep
> coming up with ideas so I can't leave it open indefinitely. :)

Hey, I resemble that remark! :)

The HOCAEIT comment from Barry was a reference to "Have Our Cake, And
Eat It Too", but I don't agree we need to write that up before you
make a decision - that was mostly me thinking out loud about possible
alternatives, rather than an offer to do the work to set it up.
However, the emails about it may be a useful reference if Barry wanted
to discuss it directly with GitLab (since they're clearly already
moving in that direction given the Repository Mirroring additions in
GitLab EE 8.2).

> I'm not enthralled with the idea of trying to attempt any bi-directional
> coordination between GitHub and GitLab
> Even uni-directional coordination seems like it might be more hassle than
> it's worth (what's the point of telling people "GitHub is totally fine" and
> then having it all mirrored to GitLab, along with all of the technical
> maintenance and complications? Just to avoid upsetting some people from
> having to use GitHub since the existence of the tooling means we don't have
> to worry about vendor lock-in?)

An analogy I've been pondering to help explain the
inclusiveness/exclusiveness aspects of decisions to use proprietary
services as part of an open source project's infrastructure is to
compare it to vegetarianism & veganism: when "Sign up to this
proprietary service" is a precondition for participation, there are
going to be folks who opt out, just as there will be folks who opt out
of community events that don't offer vegetarian or vegan meal options.
>From a practical community management perspective, the relevant part
of the analogy in relation to development tools is that when choosing
a fixed menu for a community event you either:

a. offer the vegetarian/vegan option as the only option, and aim to
make sure that even the non-vegetarians enjoy it; or
b. offer a non-vegetarian option by default, but aim to make sure the
vegetarian/vegan option is still a decent one

Switching from the analogy back to the question at hand, unless you're
actually the Free Software Foundation, being inclusive of free
software and privacy advocates when choosing workflow tools doesn't
mean adopting a categorical ban on the use of proprietary software
services, but it does mean considering what the impact will be on the
folks that choose to opt out of the proprietary dependency, and
ensuring that that alternative workflow is still a reasonable one.

In the case of a GitHub-only CPython core workflow, nothing would
change for strict free software advocates that aren't core developers:
the process will be to upload patches to Roundup as they do today.
>From there, we'll either continue reviewing them in Rietveld, or else
change those scripts to submit a PR on GitHub instead.

However, folks that are both current core developers *and* strict free
software/privacy advocates would effectively have their commit
privileges revoked if they didn't sign up for a GitHub account, as you
need one in order to upload your SSH keys. Since the goal of the
workflow changes is to make more effective use of limited core
developer time, reducing the size of that pool as a side effect really
wouldn't be a good outcome. As such, it might be worth your while to
try to quantify that more precisely by asking current core developers
their views on getting a GitHub account:

a. I already have one (happily)
b. I already have one (begrudgingly)
c. I'd happily get one
d. I'd begrudgingly get one
e. I wouldn't get one

And make it clear that failing to fill in the survey will be
interpreted as "not e".

The folks that would potentially benefit from a GitLab instance being
part of the setup are then those that fall into categories "b", "d",
and "e", and you could ask a follow-up question regarding alternatives
which they considered a preferable solution to signing up for a GitHub
account:

a. GitLab EE instance hosted and managed by GitLab, Inc
b. GitLab EE instance hosted by the PSF, and managed by GitLab, Inc
c. GitLab EE instance hosted and managed by the PSF
d. GitLab CE instance hosted and managed by the PSF

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From donald at stufft.io  Sat Dec 12 08:39:50 2015
From: donald at stufft.io (Donald Stufft)
Date: Sat, 12 Dec 2015 08:39:50 -0500
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <CADiSq7ed0JG7JV3RBiZPiDk1zJ5aGqeNOpBcffZUVScF+4VFmA@mail.gmail.com>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <20151201204757.1c743395@anarchist.wooz.org>
 <CAP1=2W7NBCgX-NU6HmB2cLiBkEK5oxbJ_FZbNC7KzcjKqHA_SQ@mail.gmail.com>
 <20151211103251.11d3a389@anarchist.wooz.org>
 <CAP1=2W4YVRu9w1Y-XAA7ibtcpGrpONhfdTD83ZW3zG06xWPq-Q@mail.gmail.com>
 <CADiSq7ed0JG7JV3RBiZPiDk1zJ5aGqeNOpBcffZUVScF+4VFmA@mail.gmail.com>
Message-ID: <6FC92C0D-B921-4A3D-A4BD-C811E74CD19A@stufft.io>

It seems pretty hypocritical to be against GitHub because it's proprietary and hosted by a company that can sell your data (both things I've seen people say against GitHub) and be pro GitLab EE (either hosted by Gitlab or ourselves) or pro using a Hosted Gitlab. I don't personally have a problem with it, I'm fine with the tooling not being free but it seems disingenuous to treat Gitlab EE (as opposed CE) as if it's free software. I'm particularly interested in a managed option of some kind to reduce to load on the infra team. 

Sent from my iPhone

> On Dec 11, 2015, at 11:57 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> a. GitLab EE instance hosted and managed by GitLab, Inc
> b. GitLab EE instance hosted by the PSF, and managed by GitLab, Inc
> c. GitLab EE instance hosted and managed by the PSF
> d. GitLab CE instance hosted and managed by the PSF

From ncoghlan at gmail.com  Sat Dec 12 10:28:33 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 13 Dec 2015 01:28:33 +1000
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <6FC92C0D-B921-4A3D-A4BD-C811E74CD19A@stufft.io>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <20151201204757.1c743395@anarchist.wooz.org>
 <CAP1=2W7NBCgX-NU6HmB2cLiBkEK5oxbJ_FZbNC7KzcjKqHA_SQ@mail.gmail.com>
 <20151211103251.11d3a389@anarchist.wooz.org>
 <CAP1=2W4YVRu9w1Y-XAA7ibtcpGrpONhfdTD83ZW3zG06xWPq-Q@mail.gmail.com>
 <CADiSq7ed0JG7JV3RBiZPiDk1zJ5aGqeNOpBcffZUVScF+4VFmA@mail.gmail.com>
 <6FC92C0D-B921-4A3D-A4BD-C811E74CD19A@stufft.io>
Message-ID: <CADiSq7ew7Nirq+UFt3q2++cpWttmdRwTzwUryvR6=UrPPeFu6w@mail.gmail.com>

On 12 December 2015 at 23:39, Donald Stufft <donald at stufft.io> wrote:
> It seems pretty hypocritical to be against GitHub because it's proprietary and hosted by a company that can sell your data (both things I've seen people say against GitHub) and be pro GitLab EE (either hosted by Gitlab or ourselves) or pro using a Hosted Gitlab. I don't personally have a problem with it, I'm fine with the tooling not being free but it seems disingenuous to treat Gitlab EE (as opposed CE) as if it's free software. I'm particularly interested in a managed option of some kind to reduce to load on the infra team.

Yeah, that's why I suggested there'd need to be at least four options
in a useful survey question (if Brett decides a survey is worth doing
at all), since those would help tease out what folks are actually
worried about, similar to the way that presenting a vegetarian option
for a meal may still not be sufficient for vegans.

Running through them:

a. GitLab EE instance hosted and managed by GitLab, Inc

* Being happier with this option than with the use of GitHub would
indicate someone was bothered by GitHub specifically, rather than the
use of proprietary software. Given the tech industry's propensity for
flocking to proprietary vendors who then turn around to attempt to
extract monopoly rents (cf. IBM, legacy UNIX vendors, Microsoft,
Oracle, etc), this is certainly one of the factors in my own concerns
- Silicon Valley venture capitalists are deliberately running a
"ubiquity first, revenue later" strategy for GitHub, which means it's
important to plan for an exit strategy if the flow of free money (and
the associated free services) dries up when investors start getting
impatient for their returns. While I've personally come to the
conclusion that
"Migrate-to-GitLab-or-some-other-service-if-the-need-arises"
adequately addresses such concerns (along with the general market
forces of GitHub doing battle with incumbents like Microsoft's Team
Foundation Server and Atlassian's software lifecycle management
portfolio), it may be that not everyone feels the same way.

b. GitLab EE instance hosted by the PSF, and managed by GitLab, Inc

* This gets into cases where folks are mainly concerned about having
permanent copies of everything important from GitHub always ready to
go on PSF controlled infrastructure, even if we're not using it
actively. It's essentially the "GitLab-as-GitHub-exit-strategy"
approach, with an additional hedge where PSF admins have direct
control over the data, even if GitLab have been tasked with the
day-to-day operation of the service.

c. GitLab EE instance hosted and managed by the PSF

* Similar to the previous option, this option would likely indicate
that someone is more concerned by privacy and data control issues than
they are by the use of proprietary software. Both GitLab and GitHub
are private for profit entities, answerable to their investors moreso
than to their users, so monetisation of user data, including becoming
a data broker for information on user's online activities, is well
within the prospective scope of corporate activities (even if neither
company is pursuing such activities today). By contrast, the PSF is a
non-profit entity, answerable to its members. If the PSF controls the
identity information needed to participate in the core development
process, then we can categorically assure participants that we're not
selling their information to data brokers, whereas if we use third
party services, we'll have to both tell people to check the Terms &
Conditions for those services, as well as consider defining trigger
conditions for what we consider to be unacceptable barriers to entry
for participation in the core development process.

d. GitLab CE instance hosted and managed by the PSF

* This is the only option that gets all the way to "Free software
needs free tools" - it denies even GitLab's open core development
model as a legitimate revenue raising tactic, since it's still using
the proprietary model to exercise coercive control over customers. The
main advantage GitLab EE has over GitHub in that context is that the
exit strategy from EE to CE is even simpler than that from GitHub to
GitLab EE.

I honestly don't know how the different areas of concern break down
across the core contributor base, and I've seen enough demands for
free software and privacy advocates to "stop being unreasonable" in
various contexts to suspect that an anonymous survey (that is still
somehow restricted to core developers) would be the only way to get an
even halfway accurate assessment.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From donald at stufft.io  Sat Dec 12 10:37:42 2015
From: donald at stufft.io (Donald Stufft)
Date: Sat, 12 Dec 2015 10:37:42 -0500
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <CADiSq7ew7Nirq+UFt3q2++cpWttmdRwTzwUryvR6=UrPPeFu6w@mail.gmail.com>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <20151201204757.1c743395@anarchist.wooz.org>
 <CAP1=2W7NBCgX-NU6HmB2cLiBkEK5oxbJ_FZbNC7KzcjKqHA_SQ@mail.gmail.com>
 <20151211103251.11d3a389@anarchist.wooz.org>
 <CAP1=2W4YVRu9w1Y-XAA7ibtcpGrpONhfdTD83ZW3zG06xWPq-Q@mail.gmail.com>
 <CADiSq7ed0JG7JV3RBiZPiDk1zJ5aGqeNOpBcffZUVScF+4VFmA@mail.gmail.com>
 <6FC92C0D-B921-4A3D-A4BD-C811E74CD19A@stufft.io>
 <CADiSq7ew7Nirq+UFt3q2++cpWttmdRwTzwUryvR6=UrPPeFu6w@mail.gmail.com>
Message-ID: <8081301D-7E29-4294-89C8-BCA20E7E8084@stufft.io>

I don't think GitHub took any VC money until just recently and they only took VC money after they had been successful, ubiquitous, and profitable. The money was taken to be able to build an enterprise sales team / pipeline for GitHub:FI (Github's self hosted option). 

Sent from my iPhone

> On Dec 12, 2015, at 10:28 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> - Silicon Valley venture capitalists are deliberately running a
> "ubiquity first, revenue later" strategy for GitHub, which means it's
> important to plan for an exit strategy if the flow of free money (and
> the associated free services) dries up when investors start getting
> impatient for their returns.

From guido at python.org  Sat Dec 12 13:07:14 2015
From: guido at python.org (Guido van Rossum)
Date: Sat, 12 Dec 2015 10:07:14 -0800
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <CAP7+vJJ4aqQSKHmJby_VcKNjxkqsQa4zu2DQL2Z+4UUYsopkKg@mail.gmail.com>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <20151201204757.1c743395@anarchist.wooz.org>
 <CAP1=2W7NBCgX-NU6HmB2cLiBkEK5oxbJ_FZbNC7KzcjKqHA_SQ@mail.gmail.com>
 <20151211103251.11d3a389@anarchist.wooz.org>
 <CAP1=2W4YVRu9w1Y-XAA7ibtcpGrpONhfdTD83ZW3zG06xWPq-Q@mail.gmail.com>
 <CADiSq7ed0JG7JV3RBiZPiDk1zJ5aGqeNOpBcffZUVScF+4VFmA@mail.gmail.com>
 <6FC92C0D-B921-4A3D-A4BD-C811E74CD19A@stufft.io>
 <CADiSq7ew7Nirq+UFt3q2++cpWttmdRwTzwUryvR6=UrPPeFu6w@mail.gmail.com>
 <8081301D-7E29-4294-89C8-BCA20E7E8084@stufft.io>
 <CAP7+vJKvW3XBzam4eAV0pz49B5W9pa4FD+AJ55g9Vmv5xVDjLQ@mail.gmail.com>
 <CAP7+vJJ4aqQSKHmJby_VcKNjxkqsQa4zu2DQL2Z+4UUYsopkKg@mail.gmail.com>
Message-ID: <CAP7+vJLFEq8Tc+=-MgoOzwnzYy9_wSrPbq6UHnntqtEv+g9s8w@mail.gmail.com>

One more repost from guido at python.org. Why is this list so picky?

On Sat, Dec 12, 2015 at 9:59 AM, Guido van Rossum <gvanrossum at gmail.com>
wrote:

> [Repeating to the list, as this was bounced by the modbot]
>
> Honestly, to cut things short, I think we should go with GitHub and pay
> them for enterprise support, if they'll take our money.
>
> --
> --Guido van Rossum (python.org/~guido)
>
> --
> --Guido van Rossum (python.org/~guido)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151212/b53afbde/attachment.html>

From skrah.temporarily at gmail.com  Sat Dec 12 13:17:18 2015
From: skrah.temporarily at gmail.com (Stefan Krah)
Date: Sat, 12 Dec 2015 18:17:18 +0000 (UTC)
Subject: [core-workflow] Questions about the proposed workflow
Message-ID: <loom.20151212T185544-63@post.gmane.org>


[D. Stufft]
> It seems pretty hypocritical to be against GitHub because it's proprietary
and hosted by a company that can sell your data (both things I've seen
people say against GitHub) and be pro GitLab EE [...]

Only in the abstract.  GitHub has an reported investment of 350.000.000,
while GitLab only has a very small fraction of that.  If selling private
repos doesn't justify that kind of money, it's pretty clear what will
happen!

To be fair, GitLab also has a rudimentary version of the annoying
per-developer statistics.

I'm also not claiming that GitHub already has a secret business plan
to turn evil -- development there seems to be a bit ad hoc, meandering
and informal.  The point is that they may *have* to turn evil, because
the private repo market simply isn't big enough.

Lastly, GitHub is to my knowledge the only one of RhodeCode, GitLab,
etc. that had at least one absolutely glaring own-the-world (write
access to all repos) security hole.


Stefan Krah


From skrah.temporarily at gmail.com  Sat Dec 12 13:36:43 2015
From: skrah.temporarily at gmail.com (Stefan Krah)
Date: Sat, 12 Dec 2015 18:36:43 +0000 (UTC)
Subject: [core-workflow] Questions about the core workflow
Message-ID: <loom.20151212T193618-754@post.gmane.org>

[Nick]
> I honestly don't know how the different areas of concern break down
across the core contributor base, and I've seen enough demands for
free software and privacy advocates to "stop being unreasonable" in
various contexts to suspect that an anonymous survey (that is still
somehow restricted to core developers) would be the only way to get an
even halfway accurate assessment.

I fully agree. Since 5 years or so stating any kind of opinion that
remotely resembles the original free software principles (by that I
don't mean necessarily Stallman's views, just a basic desire for
decency, privacy, and a free and open atmosphere) is shouted down
vigorously.

Here, we are still fortunate enough to have people like you who at
least tried the open Kallithea approach!


[For the record, I'll need a work related GitHub account from next
year on.  I'll probably give up and move my private projects there,
too, because honestly I'm tired of constantly defending minority
opinions.]



Stefan Krah




From guido at python.org  Sat Dec 12 14:00:22 2015
From: guido at python.org (Guido van Rossum)
Date: Sat, 12 Dec 2015 11:00:22 -0800
Subject: [core-workflow] Questions about the core workflow
In-Reply-To: <loom.20151212T193618-754@post.gmane.org>
References: <loom.20151212T193618-754@post.gmane.org>
Message-ID: <CAP7+vJJu40JKR+qy22EqYkj2ZgcOXnRUrGKHAox5xNLRV2o0og@mail.gmail.com>

On Sat, Dec 12, 2015 at 10:36 AM, Stefan Krah <skrah.temporarily at gmail.com>
wrote:

> Since 5 years or so stating any kind of opinion that
> remotely resembles the original free software principles (by that I
> don't mean necessarily Stallman's views, just a basic desire for
> decency, privacy, and a free and open atmosphere) is shouted down
> vigorously.
>

Who is shouting you down here? We listen, but AFAICT few agree. There's not
much of a chance to change anybody's mind on a loaded topic like this, so a
further discussion does not seem very useful.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151212/c25fd4fd/attachment.html>

From donald at stufft.io  Sat Dec 12 14:07:03 2015
From: donald at stufft.io (Donald Stufft)
Date: Sat, 12 Dec 2015 14:07:03 -0500
Subject: [core-workflow] Questions about the proposed workflow
In-Reply-To: <loom.20151212T185544-63@post.gmane.org>
References: <loom.20151212T185544-63@post.gmane.org>
Message-ID: <285A0C9D-5815-4383-83F7-DAA0BF5D887E@stufft.io>

Reminder that Github existed many years before they took outside investments and they were successful and profitable long before they did. They took investment to expand an already profitable company into enterprise, not to cover expenses while they figured out how to make money. 

Sent from my iPhone

> On Dec 12, 2015, at 1:17 PM, Stefan Krah <skrah.temporarily at gmail.com> wrote:
> 
> Only in the abstract.  GitHub has an reported investment of 350.000.000,
> while GitLab only has a very small fraction of that.  If selling private
> repos doesn't justify that kind of money, it's pretty clear what will
> happen!

From skrah.temporarily at gmail.com  Sat Dec 12 14:32:32 2015
From: skrah.temporarily at gmail.com (Stefan Krah)
Date: Sat, 12 Dec 2015 19:32:32 +0000 (UTC)
Subject: [core-workflow] Questions about the core workflow
Message-ID: <loom.20151212T201334-895@post.gmane.org>


[Guido]
> On Sat, Dec 12, 2015 at 10:36 AM, Stefan Krah <skrah.temporarily <at>
gmail.com> wrote:

    >> Since 5 years or so stating any kind of opinion that
    >> remotely resembles the original free software principles (by that I
    >> don't mean necessarily Stallman's views, just a basic desire for
    >> decency, privacy, and a free and open atmosphere) is shouted down
    >> vigorously.


> Who is shouting you down here?

Sorry if I wasn't clear: I thought that Nick's paragraph was about
*general* tendencies in open-source land that might necessitate an
anonymous survey in order to get an accurate assessment of
developer's opinions.

I fully agree that *here* there was no shouting-down.


> We listen, but AFAICT few agree.

Are you sure? I got the impression that at least Nick, Barry and
myself would favor GitLab. And there seem to be six active people
in this discussion.


Stefan Krah



From gvanrossum at gmail.com  Sat Dec 12 12:59:38 2015
From: gvanrossum at gmail.com (Guido van Rossum)
Date: Sat, 12 Dec 2015 09:59:38 -0800
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <CAP7+vJKvW3XBzam4eAV0pz49B5W9pa4FD+AJ55g9Vmv5xVDjLQ@mail.gmail.com>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <20151201204757.1c743395@anarchist.wooz.org>
 <CAP1=2W7NBCgX-NU6HmB2cLiBkEK5oxbJ_FZbNC7KzcjKqHA_SQ@mail.gmail.com>
 <20151211103251.11d3a389@anarchist.wooz.org>
 <CAP1=2W4YVRu9w1Y-XAA7ibtcpGrpONhfdTD83ZW3zG06xWPq-Q@mail.gmail.com>
 <CADiSq7ed0JG7JV3RBiZPiDk1zJ5aGqeNOpBcffZUVScF+4VFmA@mail.gmail.com>
 <6FC92C0D-B921-4A3D-A4BD-C811E74CD19A@stufft.io>
 <CADiSq7ew7Nirq+UFt3q2++cpWttmdRwTzwUryvR6=UrPPeFu6w@mail.gmail.com>
 <8081301D-7E29-4294-89C8-BCA20E7E8084@stufft.io>
 <CAP7+vJKvW3XBzam4eAV0pz49B5W9pa4FD+AJ55g9Vmv5xVDjLQ@mail.gmail.com>
Message-ID: <CAP7+vJJ4aqQSKHmJby_VcKNjxkqsQa4zu2DQL2Z+4UUYsopkKg@mail.gmail.com>

[Repeating to the list, as this was bounced by the modbot]

Honestly, to cut things short, I think we should go with GitHub and pay
them for enterprise support, if they'll take our money.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151212/56d80e75/attachment.html>

From rdmurray at bitdance.com  Sat Dec 12 15:05:20 2015
From: rdmurray at bitdance.com (R. David Murray)
Date: Sat, 12 Dec 2015 15:05:20 -0500
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <CAP7+vJLFEq8Tc+=-MgoOzwnzYy9_wSrPbq6UHnntqtEv+g9s8w@mail.gmail.com>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <20151201204757.1c743395@anarchist.wooz.org>
 <CAP1=2W7NBCgX-NU6HmB2cLiBkEK5oxbJ_FZbNC7KzcjKqHA_SQ@mail.gmail.com>
 <20151211103251.11d3a389@anarchist.wooz.org>
 <CAP1=2W4YVRu9w1Y-XAA7ibtcpGrpONhfdTD83ZW3zG06xWPq-Q@mail.gmail.com>
 <CADiSq7ed0JG7JV3RBiZPiDk1zJ5aGqeNOpBcffZUVScF+4VFmA@mail.gmail.com>
 <6FC92C0D-B921-4A3D-A4BD-C811E74CD19A@stufft.io>
 <CADiSq7ew7Nirq+UFt3q2++cpWttmdRwTzwUryvR6=UrPPeFu6w@mail.gmail.com>
 <8081301D-7E29-4294-89C8-BCA20E7E8084@stufft.io>
 <CAP7+vJKvW3XBzam4eAV0pz49B5W9pa4FD+AJ55g9Vmv5xVDjLQ@mail.gmail.com>
 <CAP7+vJJ4aqQSKHmJby_VcKNjxkqsQa4zu2DQL2Z+4UUYsopkKg@mail.gmail.com>
 <CAP7+vJLFEq8Tc+=-MgoOzwnzYy9_wSrPbq6UHnntqtEv+g9s8w@mail.gmail.com>
Message-ID: <20151212200521.AAE00B18088@webabinitio.net>

On Sat, 12 Dec 2015 10:07:14 -0800, Guido van Rossum <guido at python.org> wrote:
> One more repost from guido at python.org. Why is this list so picky?

I added your gmail address to the accept filter.  I presume that means
it will now allow you to post from there in the future.

--David

From barry at python.org  Sat Dec 12 16:11:38 2015
From: barry at python.org (Barry Warsaw)
Date: Sat, 12 Dec 2015 16:11:38 -0500
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <CAP7+vJKvW3XBzam4eAV0pz49B5W9pa4FD+AJ55g9Vmv5xVDjLQ@mail.gmail.com>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <20151201204757.1c743395@anarchist.wooz.org>
 <CAP1=2W7NBCgX-NU6HmB2cLiBkEK5oxbJ_FZbNC7KzcjKqHA_SQ@mail.gmail.com>
 <20151211103251.11d3a389@anarchist.wooz.org>
 <CAP1=2W4YVRu9w1Y-XAA7ibtcpGrpONhfdTD83ZW3zG06xWPq-Q@mail.gmail.com>
 <CADiSq7ed0JG7JV3RBiZPiDk1zJ5aGqeNOpBcffZUVScF+4VFmA@mail.gmail.com>
 <6FC92C0D-B921-4A3D-A4BD-C811E74CD19A@stufft.io>
 <CADiSq7ew7Nirq+UFt3q2++cpWttmdRwTzwUryvR6=UrPPeFu6w@mail.gmail.com>
 <8081301D-7E29-4294-89C8-BCA20E7E8084@stufft.io>
 <CAP7+vJKvW3XBzam4eAV0pz49B5W9pa4FD+AJ55g9Vmv5xVDjLQ@mail.gmail.com>
Message-ID: <20151212161138.10307112@limelight.wooz.org>

On Dec 12, 2015, at 09:52 AM, Guido van Rossum wrote:

>Honestly, to cut things short, I think we should go with GitHub and pay
>them for enterprise support, if they'll take our money.

This sounds like a pronouncement.

I really don't mean this to sound snarky, but let's not waste Brett's time, my
time, and the GitLab CEO's time if PEP 507 doesn't have a realistic chance of
being accepted.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151212/57ff3177/attachment.sig>

From brett at python.org  Sat Dec 12 17:49:40 2015
From: brett at python.org (Brett Cannon)
Date: Sat, 12 Dec 2015 22:49:40 +0000
Subject: [core-workflow] Questions about the core workflow
In-Reply-To: <loom.20151212T201334-895@post.gmane.org>
References: <loom.20151212T201334-895@post.gmane.org>
Message-ID: <CAP1=2W4_Udb7iiobMXExmygRwo-uwfUPWYhEiSF5vCid47p+dg@mail.gmail.com>

On Sat, 12 Dec 2015 at 11:32 Stefan Krah <skrah.temporarily at gmail.com>
wrote:

>
> [Guido]
> > On Sat, Dec 12, 2015 at 10:36 AM, Stefan Krah <skrah.temporarily <at>
> gmail.com> wrote:
>
>     >> Since 5 years or so stating any kind of opinion that
>     >> remotely resembles the original free software principles (by that I
>     >> don't mean necessarily Stallman's views, just a basic desire for
>     >> decency, privacy, and a free and open atmosphere) is shouted down
>     >> vigorously.
>
>
> > Who is shouting you down here?
>
> Sorry if I wasn't clear: I thought that Nick's paragraph was about
> *general* tendencies in open-source land that might necessitate an
> anonymous survey in order to get an accurate assessment of
> developer's opinions.
>
> I fully agree that *here* there was no shouting-down.
>
>
> > We listen, but AFAICT few agree.
>
> Are you sure? I got the impression that at least Nick, Barry and
> myself would favor GitLab. And there seem to be six active people
> in this discussion.
>

That's true, but I think the three of you seem to care the most to the
point of bringing up the perspective of open source. Absolutely no one has
privately or publicly expressed any problems with GitHub when I have
brought it up on python-committers or python-dev. Yes, some people have
said they would prefer GitLab, but I have yet to hear anyone say that they
are anti-GitHub (you're the closest, Stefan).

I have an idea in my head about settling this. Stay tuned.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151212/c947141a/attachment.html>

From brett at python.org  Sat Dec 12 17:56:14 2015
From: brett at python.org (Brett Cannon)
Date: Sat, 12 Dec 2015 22:56:14 +0000
Subject: [core-workflow] Questions about the proposed workflow
In-Reply-To: <285A0C9D-5815-4383-83F7-DAA0BF5D887E@stufft.io>
References: <loom.20151212T185544-63@post.gmane.org>
 <285A0C9D-5815-4383-83F7-DAA0BF5D887E@stufft.io>
Message-ID: <CAP1=2W7OFaCpTauqjc+++SBb+QJ8u6HVNhp1AqJMOALmZJB7KA@mail.gmail.com>

This line of argument about what GitHub *might *do if they run out of money
is not persuading me in the slightest, so I consider this line of argument
closed.

On Sat, 12 Dec 2015 at 11:07 Donald Stufft <donald at stufft.io> wrote:

> Reminder that Github existed many years before they took outside
> investments and they were successful and profitable long before they did.
> They took investment to expand an already profitable company into
> enterprise, not to cover expenses while they figured out how to make money.
>
> Sent from my iPhone
>
> > On Dec 12, 2015, at 1:17 PM, Stefan Krah <skrah.temporarily at gmail.com>
> wrote:
> >
> > Only in the abstract.  GitHub has an reported investment of 350.000.000,
> > while GitLab only has a very small fraction of that.  If selling private
> > repos doesn't justify that kind of money, it's pretty clear what will
> > happen!
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct:
> https://www.python.org/psf/codeofconduct
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151212/5696a706/attachment-0001.html>

From brett at python.org  Sat Dec 12 18:00:53 2015
From: brett at python.org (Brett Cannon)
Date: Sat, 12 Dec 2015 23:00:53 +0000
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <20151212161138.10307112@limelight.wooz.org>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <20151201204757.1c743395@anarchist.wooz.org>
 <CAP1=2W7NBCgX-NU6HmB2cLiBkEK5oxbJ_FZbNC7KzcjKqHA_SQ@mail.gmail.com>
 <20151211103251.11d3a389@anarchist.wooz.org>
 <CAP1=2W4YVRu9w1Y-XAA7ibtcpGrpONhfdTD83ZW3zG06xWPq-Q@mail.gmail.com>
 <CADiSq7ed0JG7JV3RBiZPiDk1zJ5aGqeNOpBcffZUVScF+4VFmA@mail.gmail.com>
 <6FC92C0D-B921-4A3D-A4BD-C811E74CD19A@stufft.io>
 <CADiSq7ew7Nirq+UFt3q2++cpWttmdRwTzwUryvR6=UrPPeFu6w@mail.gmail.com>
 <8081301D-7E29-4294-89C8-BCA20E7E8084@stufft.io>
 <CAP7+vJKvW3XBzam4eAV0pz49B5W9pa4FD+AJ55g9Vmv5xVDjLQ@mail.gmail.com>
 <20151212161138.10307112@limelight.wooz.org>
Message-ID: <CAP1=2W5B5R8EoNFMUTvDUaOqNWpzpJfgJu0V_+5j8cgKSBHbQA@mail.gmail.com>

On Sat, 12 Dec 2015 at 13:11 Barry Warsaw <barry at python.org> wrote:

> On Dec 12, 2015, at 09:52 AM, Guido van Rossum wrote:
>
> >Honestly, to cut things short, I think we should go with GitHub and pay
> >them for enterprise support, if they'll take our money.
>
> This sounds like a pronouncement.
>
> I really don't mean this to sound snarky, but let's not waste Brett's
> time, my
> time, and the GitLab CEO's time if PEP 507 doesn't have a realistic chance
> of
> being accepted.
>

Don't worry about my time; I was prepared to spend this time on this topic
and put in this amount of effort. Let me ask python-committers a question
before we call this, so if you want to hold off asking GitLab's CEO any
questions until I get my answers from python-committers that's fine.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151212/1a60e7d9/attachment.html>

From guido at python.org  Sat Dec 12 18:38:26 2015
From: guido at python.org (Guido van Rossum)
Date: Sat, 12 Dec 2015 15:38:26 -0800
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <20151212161138.10307112@limelight.wooz.org>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <20151201204757.1c743395@anarchist.wooz.org>
 <CAP1=2W7NBCgX-NU6HmB2cLiBkEK5oxbJ_FZbNC7KzcjKqHA_SQ@mail.gmail.com>
 <20151211103251.11d3a389@anarchist.wooz.org>
 <CAP1=2W4YVRu9w1Y-XAA7ibtcpGrpONhfdTD83ZW3zG06xWPq-Q@mail.gmail.com>
 <CADiSq7ed0JG7JV3RBiZPiDk1zJ5aGqeNOpBcffZUVScF+4VFmA@mail.gmail.com>
 <6FC92C0D-B921-4A3D-A4BD-C811E74CD19A@stufft.io>
 <CADiSq7ew7Nirq+UFt3q2++cpWttmdRwTzwUryvR6=UrPPeFu6w@mail.gmail.com>
 <8081301D-7E29-4294-89C8-BCA20E7E8084@stufft.io>
 <CAP7+vJKvW3XBzam4eAV0pz49B5W9pa4FD+AJ55g9Vmv5xVDjLQ@mail.gmail.com>
 <20151212161138.10307112@limelight.wooz.org>
Message-ID: <CAP7+vJKJkk+Aq5CQxWbXfOG1HYyVCvWBuR+_JOPQqi-nWbnFUg@mail.gmail.com>

On Sat, Dec 12, 2015 at 1:11 PM, Barry Warsaw <barry at python.org> wrote:

> On Dec 12, 2015, at 09:52 AM, Guido van Rossum wrote:
>
> >Honestly, to cut things short, I think we should go with GitHub and pay
> >them for enterprise support, if they'll take our money.
>
> This sounds like a pronouncement.
>
> I really don't mean this to sound snarky, but let's not waste Brett's
> time, my
> time, and the GitLab CEO's time if PEP 507 doesn't have a realistic chance
> of
> being accepted.
>

Maybe GitLab's CEO would see this as a challenge? To me, it just doesn't
sound like there's much difference in functionality between the two, and
then the vast name recognition of GitHub makes it the default choice.
"Nobody ever got fired for choosing IBM." (Beware irony. I think by now
it's probably been said about Python too. :-)

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151212/0044056b/attachment.html>

From barry at python.org  Sat Dec 12 20:25:58 2015
From: barry at python.org (Barry Warsaw)
Date: Sat, 12 Dec 2015 20:25:58 -0500
Subject: [core-workflow] Questions about the proposed workflows
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <20151201204757.1c743395@anarchist.wooz.org>
 <CAP1=2W7NBCgX-NU6HmB2cLiBkEK5oxbJ_FZbNC7KzcjKqHA_SQ@mail.gmail.com>
 <20151211103251.11d3a389@anarchist.wooz.org>
 <CAP1=2W4YVRu9w1Y-XAA7ibtcpGrpONhfdTD83ZW3zG06xWPq-Q@mail.gmail.com>
 <CADiSq7ed0JG7JV3RBiZPiDk1zJ5aGqeNOpBcffZUVScF+4VFmA@mail.gmail.com>
 <6FC92C0D-B921-4A3D-A4BD-C811E74CD19A@stufft.io>
 <CADiSq7ew7Nirq+UFt3q2++cpWttmdRwTzwUryvR6=UrPPeFu6w@mail.gmail.com>
 <8081301D-7E29-4294-89C8-BCA20E7E8084@stufft.io>
 <CAP7+vJKvW3XBzam4eAV0pz49B5W9pa4FD+AJ55g9Vmv5xVDjLQ@mail.gmail.com>
 <20151212161138.10307112@limelight.wooz.org>
 <CAP7+vJKJkk+Aq5CQxWbXfOG1HYyVCvWBuR+_JOPQqi-nWbnFUg@mail.gmail.com>
Message-ID: <20151212202558.493e434b@anarchist.wooz.org>

On Dec 12, 2015, at 03:38 PM, Guido van Rossum wrote:

>Maybe GitLab's CEO would see this as a challenge?

Possibly, but I'm not sure how valuable (to us?) that would be.  They
certainly have to be conscious of differentiation from their major competitor.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151212/4427ae85/attachment.sig>

From christian at python.org  Sun Dec 13 07:55:57 2015
From: christian at python.org (Christian Heimes)
Date: Sun, 13 Dec 2015 13:55:57 +0100
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <40000AA6-F77C-4867-94BF-9618DF1F5A15@stufft.io>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <40000AA6-F77C-4867-94BF-9618DF1F5A15@stufft.io>
Message-ID: <566D6ADD.7020309@python.org>

On 2015-12-02 00:32, Donald Stufft wrote:
> 
>> On Dec 1, 2015, at 6:24 PM, Brett Cannon <brett at python.org> wrote:
>>
>> It's Dec 1, which means it's time for any questions people have about the proposed workflows so we can get answers by Dec 15.
>>
>> I have one question that applies to both proposals and one specific to GitLab. The general one is whether both Guido and me can both be happy. :) Guido doesn't want intermediate commits nor what he calls "merge turds" to show up in the history. I want to be able to do merges from the browser. Do either GitHub or GitLab provide a way through the web UI to give Guido what he wants, or will it always require having a checkout and SSH keys set up in order to do a PR merge? If only Guido can be made happy then that means either proposal becomes an easy way for people to get code hosting for their forks and a review tool but not a PR management platform since merges would occur outside the website and merges would simply be a `git push` which is basically what we do now to do the final merge for a patch.
> 
> As far as I am aware, when you merge with the browser in GitHub it essentially does ``git merge ?no-ff`` which means there will *always* be a merge commit. There?s no support for a rebase workflow (where you rebase the branch ontop of master) or for squash merges or for FF merges.

Merge commits are the single most idiotic feature in GitHub because
GitHub enforces non fast-forward merges. Merge commits bloat and clutter
the revision history with useless junk, e.g.
http://ariya.ofilabs.com/2013/09/fast-forward-git-merge.html . We either
have to live with the fact that CPython's revision history is going to
contain lots of superfluous checkins or we cannot use the green merge
button at all. By the way it is not possible to disable or hide the
merge button. This means that we have to teach all committers to resist
the temptation and do a manual merge.

GitHub claims that non-ff merges are superior because they add context
information to merges. The same can be accomplished with mandatory links
to tickets and Reviewed-by, Tested-by and Signed-off-by lines.

I'm -1 on GitHub as long as GitHub doesn't support fast-forward merges.

Christian

From donald at stufft.io  Sun Dec 13 08:39:18 2015
From: donald at stufft.io (Donald Stufft)
Date: Sun, 13 Dec 2015 08:39:18 -0500
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <566D6ADD.7020309@python.org>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <40000AA6-F77C-4867-94BF-9618DF1F5A15@stufft.io>
 <566D6ADD.7020309@python.org>
Message-ID: <375A219B-EAB0-4B97-81A8-594C53CC2C2C@stufft.io>


> On Dec 13, 2015, at 7:55 AM, Christian Heimes <christian at python.org> wrote:
> 
> On 2015-12-02 00:32, Donald Stufft wrote:
>> 
>>> On Dec 1, 2015, at 6:24 PM, Brett Cannon <brett at python.org> wrote:
>>> 
>>> It's Dec 1, which means it's time for any questions people have about the proposed workflows so we can get answers by Dec 15.
>>> 
>>> I have one question that applies to both proposals and one specific to GitLab. The general one is whether both Guido and me can both be happy. :) Guido doesn't want intermediate commits nor what he calls "merge turds" to show up in the history. I want to be able to do merges from the browser. Do either GitHub or GitLab provide a way through the web UI to give Guido what he wants, or will it always require having a checkout and SSH keys set up in order to do a PR merge? If only Guido can be made happy then that means either proposal becomes an easy way for people to get code hosting for their forks and a review tool but not a PR management platform since merges would occur outside the website and merges would simply be a `git push` which is basically what we do now to do the final merge for a patch.
>> 
>> As far as I am aware, when you merge with the browser in GitHub it essentially does ``git merge ?no-ff`` which means there will *always* be a merge commit. There?s no support for a rebase workflow (where you rebase the branch ontop of master) or for squash merges or for FF merges.
> 
> Merge commits are the single most idiotic feature in GitHub because
> GitHub enforces non fast-forward merges. Merge commits bloat and clutter
> the revision history with useless junk, e.g.
> http://ariya.ofilabs.com/2013/09/fast-forward-git-merge.html . We either
> have to live with the fact that CPython's revision history is going to
> contain lots of superfluous checkins or we cannot use the green merge
> button at all. By the way it is not possible to disable or hide the
> merge button. This means that we have to teach all committers to resist
> the temptation and do a manual merge.
> 
> GitHub claims that non-ff merges are superior because they add context
> information to merges. The same can be accomplished with mandatory links
> to tickets and Reviewed-by, Tested-by and Signed-off-by lines.
> 
> I'm -1 on GitHub as long as GitHub doesn't support fast-forward merges.
> 
> Christian

I actually prefer non-ff merges, but that?s something that?s going to be very opinion driven (to ff or not to ff). Obviously going with GitHub is (at least currently) choosing to go with non-ff most of the time.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151213/3e9fcd52/attachment-0001.sig>

From barry at python.org  Sun Dec 13 12:03:57 2015
From: barry at python.org (Barry Warsaw)
Date: Sun, 13 Dec 2015 12:03:57 -0500
Subject: [core-workflow] Questions about the proposed workflows
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <40000AA6-F77C-4867-94BF-9618DF1F5A15@stufft.io>
 <566D6ADD.7020309@python.org>
Message-ID: <20151213120357.51ed4ad0@anarchist.wooz.org>

On Dec 13, 2015, at 01:55 PM, Christian Heimes wrote:

>Merge commits are the single most idiotic feature in GitHub because GitHub
>enforces non fast-forward merges. Merge commits bloat and clutter the
>revision history with useless junk, e.g.
>http://ariya.ofilabs.com/2013/09/fast-forward-git-merge.html . We either have
>to live with the fact that CPython's revision history is going to contain
>lots of superfluous checkins or we cannot use the green merge button at
>all. By the way it is not possible to disable or hide the merge button. This
>means that we have to teach all committers to resist the temptation and do a
>manual merge.
>
>GitHub claims that non-ff merges are superior because they add context
>information to merges. The same can be accomplished with mandatory links
>to tickets and Reviewed-by, Tested-by and Signed-off-by lines.

Coming from Bazaar, I was used to non-ff merges.  One thing commit merges
allows, which works well with bzr's strong main-line-of-development view of
the world[1] is that log and bisect feel more natural.  Meaning that when you
need to bisect to find a problem, or want to see mainline changes, you
generally won't see the branch author's intermediate commits.  But sometimes
you *do* want to dive into those sideline commits and of course there are
options that allow you to do so.

But the more I use git, and once I understood what they do to the graph, the
more I've come to like fast-forward merges, and on projects I host on GitLab,
I like having the ability to allow ff-merges.  Doing this through the web ui
usually requires rebasing though, either automatically (and GL has an option
to allow rebase-before-ff-merge) or manually by the original branch author.
The linear history is pretty nice.

There are a couple of trade-offs though.  If the rebase or merge doesn't
squash commits, then it's possible for a bisect to land inside an intermediate
commit, and if those intermediate commits don't always pass the test suite
then bisect will see test failures, which could make bisect more difficult to
use.

Also, in practice, I usually have to do *some* clean up of submitted branches
anyway (e.g. whitespace or add NEWS), so the choices are; 1) locally branch,
cleanup, test, rebase, ff-merge, push; 2) cleanup locally after automerging;
3) insist that the cleanups be done by the original author before the merge is
approved.  I've found #1 to be the least work for drive-by contributions, but
for core-contributor branches in Python, #3 will probably be more common and
then we might miss ff-merges more.

So bottom line, I like the *option* of ff-merging and it can often be the
cleanest way to move history forward.  At least with GL, you still have the
option of doing a merge commit when that's what you want.

Cheers,
-Barry

[1] which I'd argue correlates strongly to most project's reality, and is one
thing I miss in git.  Of course, with merge commits, you have `git log
--first-parent` although I'm not aware of a similar ability with bisect.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151213/a9c02cb8/attachment.sig>

From brett at python.org  Sun Dec 13 17:31:11 2015
From: brett at python.org (Brett Cannon)
Date: Sun, 13 Dec 2015 22:31:11 +0000
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <375A219B-EAB0-4B97-81A8-594C53CC2C2C@stufft.io>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <40000AA6-F77C-4867-94BF-9618DF1F5A15@stufft.io> <566D6ADD.7020309@python.org>
 <375A219B-EAB0-4B97-81A8-594C53CC2C2C@stufft.io>
Message-ID: <CAP1=2W7149F2LxYZZ-g9WyyJKGMujNh4Lk2UX_qek6WSs9rOLA@mail.gmail.com>

Berker also said a bot could do the ff workflow which could also handle the
NEWS problem as well as long term branches. Assuming that's true and we
choose to solve those problems that way then it will be true on either
platform.

On Sun, 13 Dec 2015, 05:39 Donald Stufft <donald at stufft.io> wrote:

>
> > On Dec 13, 2015, at 7:55 AM, Christian Heimes <christian at python.org>
> wrote:
> >
> > On 2015-12-02 00:32, Donald Stufft wrote:
> >>
> >>> On Dec 1, 2015, at 6:24 PM, Brett Cannon <brett at python.org> wrote:
> >>>
> >>> It's Dec 1, which means it's time for any questions people have about
> the proposed workflows so we can get answers by Dec 15.
> >>>
> >>> I have one question that applies to both proposals and one specific to
> GitLab. The general one is whether both Guido and me can both be happy. :)
> Guido doesn't want intermediate commits nor what he calls "merge turds" to
> show up in the history. I want to be able to do merges from the browser. Do
> either GitHub or GitLab provide a way through the web UI to give Guido what
> he wants, or will it always require having a checkout and SSH keys set up
> in order to do a PR merge? If only Guido can be made happy then that means
> either proposal becomes an easy way for people to get code hosting for
> their forks and a review tool but not a PR management platform since merges
> would occur outside the website and merges would simply be a `git push`
> which is basically what we do now to do the final merge for a patch.
> >>
> >> As far as I am aware, when you merge with the browser in GitHub it
> essentially does ``git merge ?no-ff`` which means there will *always* be a
> merge commit. There?s no support for a rebase workflow (where you rebase
> the branch ontop of master) or for squash merges or for FF merges.
> >
> > Merge commits are the single most idiotic feature in GitHub because
> > GitHub enforces non fast-forward merges. Merge commits bloat and clutter
> > the revision history with useless junk, e.g.
> > http://ariya.ofilabs.com/2013/09/fast-forward-git-merge.html . We either
> > have to live with the fact that CPython's revision history is going to
> > contain lots of superfluous checkins or we cannot use the green merge
> > button at all. By the way it is not possible to disable or hide the
> > merge button. This means that we have to teach all committers to resist
> > the temptation and do a manual merge.
> >
> > GitHub claims that non-ff merges are superior because they add context
> > information to merges. The same can be accomplished with mandatory links
> > to tickets and Reviewed-by, Tested-by and Signed-off-by lines.
> >
> > I'm -1 on GitHub as long as GitHub doesn't support fast-forward merges.
> >
> > Christian
>
> I actually prefer non-ff merges, but that?s something that?s going to be
> very opinion driven (to ff or not to ff). Obviously going with GitHub is
> (at least currently) choosing to go with non-ff most of the time.
>
> -----------------
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
> DCFA
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151213/3d3c9878/attachment.html>

From brett at python.org  Sun Dec 13 17:53:26 2015
From: brett at python.org (Brett Cannon)
Date: Sun, 13 Dec 2015 22:53:26 +0000
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <CAP1=2W7149F2LxYZZ-g9WyyJKGMujNh4Lk2UX_qek6WSs9rOLA@mail.gmail.com>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <40000AA6-F77C-4867-94BF-9618DF1F5A15@stufft.io> <566D6ADD.7020309@python.org>
 <375A219B-EAB0-4B97-81A8-594C53CC2C2C@stufft.io>
 <CAP1=2W7149F2LxYZZ-g9WyyJKGMujNh4Lk2UX_qek6WSs9rOLA@mail.gmail.com>
Message-ID: <CAP1=2W5FKdcHGsRUes9Nhg7FqPA6E+pXwWaUbU8CNK_QWFUV0w@mail.gmail.com>

And couldn't we have a pre-merge web hook that always rejected merges
through the browser if we chose to?

On Sun, 13 Dec 2015, 14:31 Brett Cannon <brett at python.org> wrote:

> Berker also said a bot could do the ff workflow which could also handle
> the NEWS problem as well as long term branches. Assuming that's true and we
> choose to solve those problems that way then it will be true on either
> platform.
>
> On Sun, 13 Dec 2015, 05:39 Donald Stufft <donald at stufft.io> wrote:
>
>>
>> > On Dec 13, 2015, at 7:55 AM, Christian Heimes <christian at python.org>
>> wrote:
>> >
>> > On 2015-12-02 00:32, Donald Stufft wrote:
>> >>
>> >>> On Dec 1, 2015, at 6:24 PM, Brett Cannon <brett at python.org> wrote:
>> >>>
>> >>> It's Dec 1, which means it's time for any questions people have about
>> the proposed workflows so we can get answers by Dec 15.
>> >>>
>> >>> I have one question that applies to both proposals and one specific
>> to GitLab. The general one is whether both Guido and me can both be happy.
>> :) Guido doesn't want intermediate commits nor what he calls "merge turds"
>> to show up in the history. I want to be able to do merges from the browser.
>> Do either GitHub or GitLab provide a way through the web UI to give Guido
>> what he wants, or will it always require having a checkout and SSH keys set
>> up in order to do a PR merge? If only Guido can be made happy then that
>> means either proposal becomes an easy way for people to get code hosting
>> for their forks and a review tool but not a PR management platform since
>> merges would occur outside the website and merges would simply be a `git
>> push` which is basically what we do now to do the final merge for a patch.
>> >>
>> >> As far as I am aware, when you merge with the browser in GitHub it
>> essentially does ``git merge ?no-ff`` which means there will *always* be a
>> merge commit. There?s no support for a rebase workflow (where you rebase
>> the branch ontop of master) or for squash merges or for FF merges.
>> >
>> > Merge commits are the single most idiotic feature in GitHub because
>> > GitHub enforces non fast-forward merges. Merge commits bloat and clutter
>> > the revision history with useless junk, e.g.
>> > http://ariya.ofilabs.com/2013/09/fast-forward-git-merge.html . We
>> either
>> > have to live with the fact that CPython's revision history is going to
>> > contain lots of superfluous checkins or we cannot use the green merge
>> > button at all. By the way it is not possible to disable or hide the
>> > merge button. This means that we have to teach all committers to resist
>> > the temptation and do a manual merge.
>> >
>> > GitHub claims that non-ff merges are superior because they add context
>> > information to merges. The same can be accomplished with mandatory links
>> > to tickets and Reviewed-by, Tested-by and Signed-off-by lines.
>> >
>> > I'm -1 on GitHub as long as GitHub doesn't support fast-forward merges.
>> >
>> > Christian
>>
>> I actually prefer non-ff merges, but that?s something that?s going to be
>> very opinion driven (to ff or not to ff). Obviously going with GitHub is
>> (at least currently) choosing to go with non-ff most of the time.
>>
>> -----------------
>> Donald Stufft
>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
>> DCFA
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151213/15534074/attachment-0001.html>

From donald at stufft.io  Sun Dec 13 18:11:10 2015
From: donald at stufft.io (Donald Stufft)
Date: Sun, 13 Dec 2015 18:11:10 -0500
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <CAP1=2W5FKdcHGsRUes9Nhg7FqPA6E+pXwWaUbU8CNK_QWFUV0w@mail.gmail.com>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <40000AA6-F77C-4867-94BF-9618DF1F5A15@stufft.io>
 <566D6ADD.7020309@python.org>
 <375A219B-EAB0-4B97-81A8-594C53CC2C2C@stufft.io>
 <CAP1=2W7149F2LxYZZ-g9WyyJKGMujNh4Lk2UX_qek6WSs9rOLA@mail.gmail.com>
 <CAP1=2W5FKdcHGsRUes9Nhg7FqPA6E+pXwWaUbU8CNK_QWFUV0w@mail.gmail.com>
Message-ID: <594DCB06-9AB7-4ECF-8571-ED1FB23EF45C@stufft.io>

For Github, Yes and No.

You can have status checks which will either prevent the merge, or will color it yellow to indicate that it shouldn?t be merged (but will still allow it). Unfortunately right now the implementation of preventing the merge unless all status checks pass ALSO makes it so that you cannot have any commits on the branch you?re merging into that are not contained within the PR. The practical implications of this is that anytime you merge a PR or push commits to master (or another branch), all PRs to that branch need to be rebased or have master merged back into them. They do provide a ?Update Branch? button to do this automatically if there are no conflicts, however you only get that button if you have write permission to the incoming repository (e.g. if I fork python/cpython to dstufft/python and make a PR, you?d need write permission to dstufft/cpython to get that button). This makes mandatory checks pretty useless for most OSS projects.

> On Dec 13, 2015, at 5:53 PM, Brett Cannon <brett at python.org> wrote:
> 
> And couldn't we have a pre-merge web hook that always rejected merges through the browser if we chose to?
> 
> On Sun, 13 Dec 2015, 14:31 Brett Cannon <brett at python.org <mailto:brett at python.org>> wrote:
> Berker also said a bot could do the ff workflow which could also handle the NEWS problem as well as long term branches. Assuming that's true and we choose to solve those problems that way then it will be true on either platform.
> 
> On Sun, 13 Dec 2015, 05:39 Donald Stufft <donald at stufft.io <mailto:donald at stufft.io>> wrote:
> 
> > On Dec 13, 2015, at 7:55 AM, Christian Heimes <christian at python.org <mailto:christian at python.org>> wrote:
> >
> > On 2015-12-02 00:32, Donald Stufft wrote:
> >>
> >>> On Dec 1, 2015, at 6:24 PM, Brett Cannon <brett at python.org <mailto:brett at python.org>> wrote:
> >>>
> >>> It's Dec 1, which means it's time for any questions people have about the proposed workflows so we can get answers by Dec 15.
> >>>
> >>> I have one question that applies to both proposals and one specific to GitLab. The general one is whether both Guido and me can both be happy. :) Guido doesn't want intermediate commits nor what he calls "merge turds" to show up in the history. I want to be able to do merges from the browser. Do either GitHub or GitLab provide a way through the web UI to give Guido what he wants, or will it always require having a checkout and SSH keys set up in order to do a PR merge? If only Guido can be made happy then that means either proposal becomes an easy way for people to get code hosting for their forks and a review tool but not a PR management platform since merges would occur outside the website and merges would simply be a `git push` which is basically what we do now to do the final merge for a patch.
> >>
> >> As far as I am aware, when you merge with the browser in GitHub it essentially does ``git merge ?no-ff`` which means there will *always* be a merge commit. There?s no support for a rebase workflow (where you rebase the branch ontop of master) or for squash merges or for FF merges.
> >
> > Merge commits are the single most idiotic feature in GitHub because
> > GitHub enforces non fast-forward merges. Merge commits bloat and clutter
> > the revision history with useless junk, e.g.
> > http://ariya.ofilabs.com/2013/09/fast-forward-git-merge.html <http://ariya.ofilabs.com/2013/09/fast-forward-git-merge.html> . We either
> > have to live with the fact that CPython's revision history is going to
> > contain lots of superfluous checkins or we cannot use the green merge
> > button at all. By the way it is not possible to disable or hide the
> > merge button. This means that we have to teach all committers to resist
> > the temptation and do a manual merge.
> >
> > GitHub claims that non-ff merges are superior because they add context
> > information to merges. The same can be accomplished with mandatory links
> > to tickets and Reviewed-by, Tested-by and Signed-off-by lines.
> >
> > I'm -1 on GitHub as long as GitHub doesn't support fast-forward merges.
> >
> > Christian
> 
> I actually prefer non-ff merges, but that?s something that?s going to be very opinion driven (to ff or not to ff). Obviously going with GitHub is (at least currently) choosing to go with non-ff most of the time.
> 
> -----------------
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
> 


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151213/a1b33034/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151213/a1b33034/attachment.sig>

From ncoghlan at gmail.com  Mon Dec 14 05:40:57 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 14 Dec 2015 20:40:57 +1000
Subject: [core-workflow] Questions about the core workflow
In-Reply-To: <CAP7+vJJu40JKR+qy22EqYkj2ZgcOXnRUrGKHAox5xNLRV2o0og@mail.gmail.com>
References: <loom.20151212T193618-754@post.gmane.org>
 <CAP7+vJJu40JKR+qy22EqYkj2ZgcOXnRUrGKHAox5xNLRV2o0og@mail.gmail.com>
Message-ID: <CADiSq7eL0xm6B90rhBKfLEt3vKXUJnUPjFuj=0_DKER7h6CARg@mail.gmail.com>

On 13 December 2015 at 05:00, Guido van Rossum <guido at python.org> wrote:
> On Sat, Dec 12, 2015 at 10:36 AM, Stefan Krah <skrah.temporarily at gmail.com>
> wrote:
>>
>> Since 5 years or so stating any kind of opinion that
>> remotely resembles the original free software principles (by that I
>> don't mean necessarily Stallman's views, just a basic desire for
>> decency, privacy, and a free and open atmosphere) is shouted down
>> vigorously.
>
>
> Who is shouting you down here? We listen, but AFAICT few agree. There's not
> much of a chance to change anybody's mind on a loaded topic like this, so a
> further discussion does not seem very useful.

The Python core lists are generally free of it, but the vitriol
directed at GPL and AGPL advocates on the internet at large can be
astonishing in its hostility (usually by people exploiting permissive
licenses to write proprietary software, and being upset when folks use
the legal system to create an obligation for reciprocal sharing).

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From ncoghlan at gmail.com  Mon Dec 14 06:16:15 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 14 Dec 2015 21:16:15 +1000
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <566D6ADD.7020309@python.org>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <40000AA6-F77C-4867-94BF-9618DF1F5A15@stufft.io>
 <566D6ADD.7020309@python.org>
Message-ID: <CADiSq7e0X5ojnpY9apMtKJ9CMYrbfe8kh1tUrPfLiBoVS4WwoA@mail.gmail.com>

On 13 December 2015 at 22:55, Christian Heimes <christian at python.org> wrote:
> Merge commits are the single most idiotic feature in GitHub because
> GitHub enforces non fast-forward merges. Merge commits bloat and clutter
> the revision history with useless junk, e.g.
> http://ariya.ofilabs.com/2013/09/fast-forward-git-merge.html . We either
> have to live with the fact that CPython's revision history is going to
> contain lots of superfluous checkins or we cannot use the green merge
> button at all. By the way it is not possible to disable or hide the
> merge button. This means that we have to teach all committers to resist
> the temptation and do a manual merge.
>
> GitHub claims that non-ff merges are superior because they add context
> information to merges. The same can be accomplished with mandatory links
> to tickets and Reviewed-by, Tested-by and Signed-off-by lines.
>
> I'm -1 on GitHub as long as GitHub doesn't support fast-forward merges.

GitLab actually have a useful page discussing some of the trade-offs
of different git workflows:
http://doc.gitlab.com/ee/workflow/gitlab_flow.html

One of the points they make regarding "no commits to master, only
merges" is that it means that regardless of whether you're working on
a simple change that can be handled on a single commit, or a
multi-commit feature branch, there will always be a single merge
commit at the end, and that's what you revert if you decide to back
out the change - you never need to ask the question "Are there
multiple commits I need to revert in order to back that change out?".

Given GitHub (and GitLab's) origins in the continuous
integration/continuous deployment world of network service
development, it's easy to see how that's an attractive feature: when
committing to master triggers an automated deployment, you want the
rollback code to be able to automatically step back to the right place
if the initial deployments in a phased rollout indicate a bad update.

That's potentially useful to us as well, since we'll likely keep
cross-platform testing on the BuildBot fleet as a post-commit
activity, and use something easier to scale (like Travis CI) for
pre-commit testing.

If we were to adopt the "commit to master and backport" model for
maintenance branches, then filtering out merge commits to master
should also eliminate most of the clutter from "git log", while still
presenting the meaningful changes to each branch.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From barry at python.org  Mon Dec 14 11:23:51 2015
From: barry at python.org (Barry Warsaw)
Date: Mon, 14 Dec 2015 11:23:51 -0500
Subject: [core-workflow] Questions about the proposed workflows
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <40000AA6-F77C-4867-94BF-9618DF1F5A15@stufft.io>
 <566D6ADD.7020309@python.org>
 <CADiSq7e0X5ojnpY9apMtKJ9CMYrbfe8kh1tUrPfLiBoVS4WwoA@mail.gmail.com>
Message-ID: <20151214112351.559784d8@anarchist.wooz.org>

On Dec 14, 2015, at 09:16 PM, Nick Coghlan wrote:

>GitLab actually have a useful page discussing some of the trade-offs of
>different git workflows: http://doc.gitlab.com/ee/workflow/gitlab_flow.html

Yep, this is a good page for the start of a discussion we're going to need to
have.  IMO, it doesn't focus enough on projects like Python where we don't
deploy anything but instead release regular products like tarballs.

Picking a code hosting strategy will be the "easy" part of Brett's work <wink>.
Trying to figure out the best workflow for git-based CPython development will
be the "fun" part, and the current Mercurial flow is probably not the best
approach if and when git is adopted.

>One of the points they make regarding "no commits to master, only
>merges" is that it means that regardless of whether you're working on
>a simple change that can be handled on a single commit, or a
>multi-commit feature branch, there will always be a single merge
>commit at the end, and that's what you revert if you decide to back
>out the change - you never need to ask the question "Are there
>multiple commits I need to revert in order to back that change out?".

Right, that's definitely an advantage of no-ff merge commits.  It's less of a
concern when you have to branch locally to clean up contributions because at
the end of that process, you can rebase and squash on master, and then you've
only got one commit to ff.  This rebase is safe because it's never pushed.
E.g.

Alice submits a merge request that fixes bug #3.  She doesn't include a NEWS
item, and her branch has some minor style issues that need cleaning up, but
it's generally pretty good.  Rather than nitpick Alice's contribution, Bob
fetches Alice's branch, does a few more commits locally to clean things up,
and then rebases his local copy of Alice's branch onto master, squashing
commits.  Everything looks good to Bob so he ff-merges his local branch onto
master, and pushes master.  In this case, linear ff-merges are cleaner and
just as easy to revert as a merge-commit.  It also makes it easy to cherry
pick this change into stable release branches.

In fact, we may find that bug fixes typically work this way anyway because if
they need to be backported, it can be easier to work out all the cherry picks
and do local testing on all the stable branches, then only push master and the
stable branches once everything's sorted out.  CI and the buildbots would then
run on the results and ensure everything still works.

For this reason, I'm a fan of a master-first development for bug fixes, with
cherry picking to backport fixes to stable branches as appropriate.  I'm love
to hear about alternatives, but after a lot of experimentation, this seems to
be an approach that usually works smoothly and is the easiest to understand
what happened after the fact, but it's different than our current Mercurial
workflow.

Feature branches will work differently because they won't be backported.  In
those cases, an auto-merge with or without merge commits via the web ui
could be a cleaner workflow.

>If we were to adopt the "commit to master and backport" model for maintenance
>branches, then filtering out merge commits to master should also eliminate
>most of the clutter from "git log", while still presenting the meaningful
>changes to each branch.

There's probably no easy way to eliminate manual, local work on the part of
the final committer for backporting changes from master into stable branches,
but with a careful strategy, it's not that hard either.  Sometimes there's no
way around merge conflicts though.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151214/63aac1d5/attachment.sig>

From guido at python.org  Mon Dec 14 11:31:44 2015
From: guido at python.org (Guido van Rossum)
Date: Mon, 14 Dec 2015 08:31:44 -0800
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <CADiSq7e0X5ojnpY9apMtKJ9CMYrbfe8kh1tUrPfLiBoVS4WwoA@mail.gmail.com>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <40000AA6-F77C-4867-94BF-9618DF1F5A15@stufft.io> <566D6ADD.7020309@python.org>
 <CADiSq7e0X5ojnpY9apMtKJ9CMYrbfe8kh1tUrPfLiBoVS4WwoA@mail.gmail.com>
Message-ID: <CAP7+vJKCRgwaehfr+fB9P_0cjyMRPmW5cjzfyF_2wVt-74BWdg@mail.gmail.com>

That's all fine (and I still prefer GitHub), but in the mypy I recently saw
a log like this:
```
*   7c9b2a6 Merge branch 'xxx-xxx'
|\
| * c833d7e Tweak test case
| * e52f2ff Fix crash
| * ccca8c1 Add tests for #1234
| * e870d0c Fix #1234
|/
*
```
This is clearly just some local development commits -- the entire thing
should have been a single commit labeled 'Fix #1234' (and perhaps a better
description of how or what). I guess we could request contributors to
squash the commits in the PR. But that's definitely adding extra work for
most contributors (and may add a day to the commit cycle if they've already
gone to bed or off to work or play). I can do all this manually on the
command line, but the convenience of the Merge button is pretty high...

TBH the argument from being able to roll back things doesn't feel very
strong at Dropbox. We use a merge process where developers' commits are
always squashed into a single commit in master once code review is finished
(we have command-line tools for this based on Phabricator's Arcanist). And
of course we also have to roll back stuff. But I've never heard of a
problem where we had to roll back multiple commits to get back into a
reasonable state.

Of course there are long-running projects that are committed to master in
many smaller pieces. But we take care that ever partial commit is tested
properly and we have a dynamic database of feature flags that we can use to
turn features on or off per user or group of users so we can alpha-test
committed code with select groups of users (usually Dropbox employees are
the first guinea pigs :-). Rolling back multiple commits feels like it
would be precarious -- most likely there would be merge conflicts with
other code that came in between (a lot of people typically work on the same
modules and packages).

Python development feels different -- fewer committers, fewer commits. I'm
willing to live with history like I quoted above just to have the
convenience of using the GitHub PR process, which many potential
contributors have already experienced.

On Mon, Dec 14, 2015 at 3:16 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 13 December 2015 at 22:55, Christian Heimes <christian at python.org>
> wrote:
> > Merge commits are the single most idiotic feature in GitHub because
> > GitHub enforces non fast-forward merges. Merge commits bloat and clutter
> > the revision history with useless junk, e.g.
> > http://ariya.ofilabs.com/2013/09/fast-forward-git-merge.html . We either
> > have to live with the fact that CPython's revision history is going to
> > contain lots of superfluous checkins or we cannot use the green merge
> > button at all. By the way it is not possible to disable or hide the
> > merge button. This means that we have to teach all committers to resist
> > the temptation and do a manual merge.
> >
> > GitHub claims that non-ff merges are superior because they add context
> > information to merges. The same can be accomplished with mandatory links
> > to tickets and Reviewed-by, Tested-by and Signed-off-by lines.
> >
> > I'm -1 on GitHub as long as GitHub doesn't support fast-forward merges.
>
> GitLab actually have a useful page discussing some of the trade-offs
> of different git workflows:
> http://doc.gitlab.com/ee/workflow/gitlab_flow.html
>
> One of the points they make regarding "no commits to master, only
> merges" is that it means that regardless of whether you're working on
> a simple change that can be handled on a single commit, or a
> multi-commit feature branch, there will always be a single merge
> commit at the end, and that's what you revert if you decide to back
> out the change - you never need to ask the question "Are there
> multiple commits I need to revert in order to back that change out?".
>
> Given GitHub (and GitLab's) origins in the continuous
> integration/continuous deployment world of network service
> development, it's easy to see how that's an attractive feature: when
> committing to master triggers an automated deployment, you want the
> rollback code to be able to automatically step back to the right place
> if the initial deployments in a phased rollout indicate a bad update.
>
> That's potentially useful to us as well, since we'll likely keep
> cross-platform testing on the BuildBot fleet as a post-commit
> activity, and use something easier to scale (like Travis CI) for
> pre-commit testing.
>
> If we were to adopt the "commit to master and backport" model for
> maintenance branches, then filtering out merge commits to master
> should also eliminate most of the clutter from "git log", while still
> presenting the meaningful changes to each branch.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct:
> https://www.python.org/psf/codeofconduct
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151214/ceb927c3/attachment.html>

From donald at stufft.io  Mon Dec 14 11:35:10 2015
From: donald at stufft.io (Donald Stufft)
Date: Mon, 14 Dec 2015 11:35:10 -0500
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <CAP7+vJKCRgwaehfr+fB9P_0cjyMRPmW5cjzfyF_2wVt-74BWdg@mail.gmail.com>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <40000AA6-F77C-4867-94BF-9618DF1F5A15@stufft.io>
 <566D6ADD.7020309@python.org>
 <CADiSq7e0X5ojnpY9apMtKJ9CMYrbfe8kh1tUrPfLiBoVS4WwoA@mail.gmail.com>
 <CAP7+vJKCRgwaehfr+fB9P_0cjyMRPmW5cjzfyF_2wVt-74BWdg@mail.gmail.com>
Message-ID: <F54238D3-661C-4E4E-ABE7-3E6FD9734764@stufft.io>


> On Dec 14, 2015, at 11:31 AM, Guido van Rossum <guido at python.org> wrote:
> 
> TBH the argument from being able to roll back things doesn't feel very strong at Dropbox. We use a merge process where developers' commits are always squashed into a single commit in master once code review is finished (we have command-line tools for this based on Phabricator's Arcanist). And of course we also have to roll back stuff. But I've never heard of a problem where we had to roll back multiple commits to get back into a reasonable state.

You don?t really need the merge commit if you?re doing squash merges since you have a single atomic unit to roll back which is equal to the final, squashed, commit. It?s difficult to roll back the effect of merging an entire branch with multiple commits if you?re not squash merging but just regular merging if it was a FF merge without merge commits because there is no longer any record that a merge took place at all.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151214/3e2a27b5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151214/3e2a27b5/attachment-0001.sig>

From barry at python.org  Mon Dec 14 11:46:42 2015
From: barry at python.org (Barry Warsaw)
Date: Mon, 14 Dec 2015 11:46:42 -0500
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <F54238D3-661C-4E4E-ABE7-3E6FD9734764@stufft.io>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <40000AA6-F77C-4867-94BF-9618DF1F5A15@stufft.io>
 <566D6ADD.7020309@python.org>
 <CADiSq7e0X5ojnpY9apMtKJ9CMYrbfe8kh1tUrPfLiBoVS4WwoA@mail.gmail.com>
 <CAP7+vJKCRgwaehfr+fB9P_0cjyMRPmW5cjzfyF_2wVt-74BWdg@mail.gmail.com>
 <F54238D3-661C-4E4E-ABE7-3E6FD9734764@stufft.io>
Message-ID: <20151214114642.717a3755@limelight.wooz.org>

On Dec 14, 2015, at 11:35 AM, Donald Stufft wrote:

>You don?t really need the merge commit if you?re doing squash merges

Just to be clear though, with a GitHub choice, you'd either have to accept
merge commits, or do the squash merges locally and then push master because
they aren't supported by GH's u/i, right?

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151214/705471cd/attachment.sig>

From donald at stufft.io  Mon Dec 14 11:48:21 2015
From: donald at stufft.io (Donald Stufft)
Date: Mon, 14 Dec 2015 11:48:21 -0500
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <20151214114642.717a3755@limelight.wooz.org>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <40000AA6-F77C-4867-94BF-9618DF1F5A15@stufft.io>
 <566D6ADD.7020309@python.org>
 <CADiSq7e0X5ojnpY9apMtKJ9CMYrbfe8kh1tUrPfLiBoVS4WwoA@mail.gmail.com>
 <CAP7+vJKCRgwaehfr+fB9P_0cjyMRPmW5cjzfyF_2wVt-74BWdg@mail.gmail.com>
 <F54238D3-661C-4E4E-ABE7-3E6FD9734764@stufft.io>
 <20151214114642.717a3755@limelight.wooz.org>
Message-ID: <F622D2CB-74F7-484C-8BBF-5039FDE4FF08@stufft.io>


> On Dec 14, 2015, at 11:46 AM, Barry Warsaw <barry at python.org> wrote:
> 
> On Dec 14, 2015, at 11:35 AM, Donald Stufft wrote:
> 
>> You don?t really need the merge commit if you?re doing squash merges
> 
> Just to be clear though, with a GitHub choice, you'd either have to accept
> merge commits, or do the squash merges locally and then push master because
> they aren't supported by GH's u/i, right?
> 

Correct. Where ?locally? could also include a robot to do merges based on a comment left on the PR, like ?Ok to Merge?. There is no built in option to do anything but ``git merge ?no-ff`` in Github?s UI.


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151214/cc5ecd50/attachment.sig>

From brett at python.org  Mon Dec 14 15:48:56 2015
From: brett at python.org (Brett Cannon)
Date: Mon, 14 Dec 2015 20:48:56 +0000
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <F622D2CB-74F7-484C-8BBF-5039FDE4FF08@stufft.io>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <40000AA6-F77C-4867-94BF-9618DF1F5A15@stufft.io> <566D6ADD.7020309@python.org>
 <CADiSq7e0X5ojnpY9apMtKJ9CMYrbfe8kh1tUrPfLiBoVS4WwoA@mail.gmail.com>
 <CAP7+vJKCRgwaehfr+fB9P_0cjyMRPmW5cjzfyF_2wVt-74BWdg@mail.gmail.com>
 <F54238D3-661C-4E4E-ABE7-3E6FD9734764@stufft.io>
 <20151214114642.717a3755@limelight.wooz.org>
 <F622D2CB-74F7-484C-8BBF-5039FDE4FF08@stufft.io>
Message-ID: <CAP1=2W7n2B7dSsM1HBRxmYY9emM4Xg3G1BOnVw9J3tiv=8=WvA@mail.gmail.com>

On Mon, 14 Dec 2015 at 08:48 Donald Stufft <donald at stufft.io> wrote:

>
> > On Dec 14, 2015, at 11:46 AM, Barry Warsaw <barry at python.org> wrote:
> >
> > On Dec 14, 2015, at 11:35 AM, Donald Stufft wrote:
> >
> >> You don?t really need the merge commit if you?re doing squash merges
> >
> > Just to be clear though, with a GitHub choice, you'd either have to
> accept
> > merge commits, or do the squash merges locally and then push master
> because
> > they aren't supported by GH's u/i, right?
> >
>
> Correct. Where ?locally? could also include a robot to do merges based on
> a comment left on the PR, like ?Ok to Merge?. There is no built in option
> to do anything but ``git merge ?no-ff`` in Github?s UI.
>

A point I want to make here is that the motivating factor for all of this
potential dev workflow upheaval is to increase our patch review/acceptance
throughput. If this comes at the cost of a very clean log then I say so be
it; an open source project thrives or dies based on how well it can manage
its relationship with external contributors as they are the future core
contributors (and this is especially true for projects like Python where
there is no corporate sponsor making sure the project stays staffed). From
my perspective (and seemingly that of the community based on what people
said during Guido's PyCon keynote), we are not doing a good job at managing
this relationship. For me this is "practicality vs purity" in terms of
"patch throughput vs log cleanliness" and I think the former should trump
the latter if we are not going to end up being a project where only the
truly dedicated contribute and we persistently end up with only core devs
contributing (which won't help scale for bugfixes).

Having said that, I get the desire to have a clean history. Based on the
fact no one has said "I hate squashed commits" compared to "I hate merge
commits", I want to see if there is a way to make it so that everyone gets
what they want; ease-of-use through the browser while getting a clean
history. I think it may be possible if I'm not misunderstanding technical
possibilities of GitHub or GitLab using a bot-based workflow.

Let's say Alice submits a PR against master to fix a bug that should get
backported to 3.5  which I figure this is probably the most complicated
common-case we have (the PR starts off with the Merge button being yellow
because we just flag all PRs as not to be merged by GitHub's workflow). Eve
does a code review, leading to various commits being made by Alice in her
branch. Everything gets to a state where the *code* is in a state that Eve
is happy with the PR. At this point some CI has run to verify that all
tests (at least) pass on master. We still need to make an entry for
Misc/NEWS, get Alice's changes into master and into 3.5. We leave a comment
in the PR along the lines of:
```
/black-knight master 3.5

Issue #12345: Fixed some thingy somehow.

Through the magic of common sense the issue the bug was made as a dead as a
parrot.

/news Issue #213245: Fixed some thingy.
```
(we can squabble over the bot's name being something else like
non-shall-pass instead, but for my money if we have a bot that guards
Python's repo is has to be a Holy Grail & black knight reference)

What that comment would do is trigger a bot that would grab the patch for
the PR, apply it against master, generate a NEWS entry file for everything
following `/news` (i.e., using Larry's proposed file-per-change NEWS
solution to avoid conflicts), and commit to master using as a message
everything between `/black-knight` and `/news`. It would then cherry-pick
the new change in master and apply it to the 3.5 branch. After all of this,
the bot pushes the branches to origin and closes the PR with an appropriate
message. Had there been a merge problem with the cherry pick then it would
be dropped, the PR left open, and an appropriate message added to the PR
(and maybe even an appropriate label or milestone added so no one forgets
why the PR is open).

This kind of workflow gets us a clean history, unique NEWS entries per
commit, and merges/cherry picks across versions that are conflict-free.
There is also nothing stopping people from doing the work from the
command-line from a checkout if they want/need to. Heck, we can even have
black-knight add a comment to every PR that links to the devguide on how to
do it manually if we want.

I realize some things could be optimized and some niceties added, but what
I propose above I think would get us a workflow that's easy enough that one
could accept a patch on their lunch break without much issue and hence
increase our patch acceptance throughput.

This also means neither GitHub or GitLab offer any specific benefit over
each other from what I can tell (if we dropped unique NEWS entries and did
cherry picks manually then I think GitLab EE gets us web-based squashing if
I understand things properly). But this bot-based approach gets us the
common-case managed entirely in the browser with a clean history.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151214/8b911a04/attachment.html>

From donald at stufft.io  Mon Dec 14 15:54:37 2015
From: donald at stufft.io (Donald Stufft)
Date: Mon, 14 Dec 2015 15:54:37 -0500
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <CAP1=2W7n2B7dSsM1HBRxmYY9emM4Xg3G1BOnVw9J3tiv=8=WvA@mail.gmail.com>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <40000AA6-F77C-4867-94BF-9618DF1F5A15@stufft.io>
 <566D6ADD.7020309@python.org>
 <CADiSq7e0X5ojnpY9apMtKJ9CMYrbfe8kh1tUrPfLiBoVS4WwoA@mail.gmail.com>
 <CAP7+vJKCRgwaehfr+fB9P_0cjyMRPmW5cjzfyF_2wVt-74BWdg@mail.gmail.com>
 <F54238D3-661C-4E4E-ABE7-3E6FD9734764@stufft.io>
 <20151214114642.717a3755@limelight.wooz.org>
 <F622D2CB-74F7-484C-8BBF-5039FDE4FF08@stufft.io>
 <CAP1=2W7n2B7dSsM1HBRxmYY9emM4Xg3G1BOnVw9J3tiv=8=WvA@mail.gmail.com>
Message-ID: <54F25243-4516-4474-8015-BD7F4262EF43@stufft.io>


> On Dec 14, 2015, at 3:48 PM, Brett Cannon <brett at python.org> wrote:
> 
> This also means neither GitHub or GitLab offer any specific benefit over each other from what I can tell (if we dropped unique NEWS entries and did cherry picks manually then I think GitLab EE gets us web-based squashing if I understand things properly). But this bot-based approach gets us the common-case managed entirely in the browser with a clean history.

Correct. You?re down to more nebulous things like ?I like X?s UI better?, ?X is more Free?, ?X has a large community buy in? and such. Of course the downside is that we?d be diverging from the ?normal? process for either tool so we?d be a bit special snowflake which increases the overhead for potential core developers? but I don?t think a bot command is a particularly onerous requirement for core developers to learn, and since it?s limited to just core developers it doesn?t affect the (hopefully) larger pool of external contributors.

Since Gitlab CE is OSS you could potentially modify it to have these things baked directly into it, but that feels like a less optimal solution than a bot since we?d be essentially forking it and then maintaining it ourselves.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151214/2c298104/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151214/2c298104/attachment.sig>

From barry at python.org  Mon Dec 14 16:03:57 2015
From: barry at python.org (Barry Warsaw)
Date: Mon, 14 Dec 2015 16:03:57 -0500
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <CAP1=2W7n2B7dSsM1HBRxmYY9emM4Xg3G1BOnVw9J3tiv=8=WvA@mail.gmail.com>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <40000AA6-F77C-4867-94BF-9618DF1F5A15@stufft.io>
 <566D6ADD.7020309@python.org>
 <CADiSq7e0X5ojnpY9apMtKJ9CMYrbfe8kh1tUrPfLiBoVS4WwoA@mail.gmail.com>
 <CAP7+vJKCRgwaehfr+fB9P_0cjyMRPmW5cjzfyF_2wVt-74BWdg@mail.gmail.com>
 <F54238D3-661C-4E4E-ABE7-3E6FD9734764@stufft.io>
 <20151214114642.717a3755@limelight.wooz.org>
 <F622D2CB-74F7-484C-8BBF-5039FDE4FF08@stufft.io>
 <CAP1=2W7n2B7dSsM1HBRxmYY9emM4Xg3G1BOnVw9J3tiv=8=WvA@mail.gmail.com>
Message-ID: <20151214160357.71e62e49@limelight.wooz.org>

On Dec 14, 2015, at 08:48 PM, Brett Cannon wrote:

>What that comment would do is trigger a bot

As long as we a clear, responsive owner of the bot, and a plan for when it
inevitably dies or does the wrong thing.  If the bot is going to be in the
critical loop, we can't allow its failure to block our work.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151214/fa76ded6/attachment-0001.sig>

From rdmurray at bitdance.com  Mon Dec 14 16:46:07 2015
From: rdmurray at bitdance.com (R. David Murray)
Date: Mon, 14 Dec 2015 16:46:07 -0500
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <20151214160357.71e62e49@limelight.wooz.org>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <40000AA6-F77C-4867-94BF-9618DF1F5A15@stufft.io>
 <566D6ADD.7020309@python.org>
 <CADiSq7e0X5ojnpY9apMtKJ9CMYrbfe8kh1tUrPfLiBoVS4WwoA@mail.gmail.com>
 <CAP7+vJKCRgwaehfr+fB9P_0cjyMRPmW5cjzfyF_2wVt-74BWdg@mail.gmail.com>
 <F54238D3-661C-4E4E-ABE7-3E6FD9734764@stufft.io>
 <20151214114642.717a3755@limelight.wooz.org>
 <F622D2CB-74F7-484C-8BBF-5039FDE4FF08@stufft.io>
 <CAP1=2W7n2B7dSsM1HBRxmYY9emM4Xg3G1BOnVw9J3tiv=8=WvA@mail.gmail.com>
 <20151214160357.71e62e49@limelight.wooz.org>
Message-ID: <20151214214609.669DCB14089@webabinitio.net>

On Mon, 14 Dec 2015 16:03:57 -0500, Barry Warsaw <barry at python.org> wrote:
> On Dec 14, 2015, at 08:48 PM, Brett Cannon wrote:
> 
> >What that comment would do is trigger a bot
> 
> As long as we a clear, responsive owner of the bot, and a plan for when it
> inevitably dies or does the wrong thing.  If the bot is going to be in the
> critical loop, we can't allow its failure to block our work.

Well, the bot being down won't *block* anything, it will just remove the
level of added convenience we are looking for (ie: you can always fall
back to manual commit/push).  Likewise, mistakes will probably have
to be cleaned up manually, and we might have to shut it off until
the bug gets fixed in that situation.

That said, we really don't want the bot to have only a single
maintainer, though it may initially have a single author, and ideally
operations would be responsible for keeping it running.

There are a number of advantages to having a bot be the way this works
rather than depending on features of the provider's software, easier
integration with other tools (ie: the tracker) being a big one.
It would also presumably make switching providers somewhat easier.

--David

From guido at python.org  Mon Dec 14 17:51:22 2015
From: guido at python.org (Guido van Rossum)
Date: Mon, 14 Dec 2015 14:51:22 -0800
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <20151214214609.669DCB14089@webabinitio.net>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <40000AA6-F77C-4867-94BF-9618DF1F5A15@stufft.io> <566D6ADD.7020309@python.org>
 <CADiSq7e0X5ojnpY9apMtKJ9CMYrbfe8kh1tUrPfLiBoVS4WwoA@mail.gmail.com>
 <CAP7+vJKCRgwaehfr+fB9P_0cjyMRPmW5cjzfyF_2wVt-74BWdg@mail.gmail.com>
 <F54238D3-661C-4E4E-ABE7-3E6FD9734764@stufft.io>
 <20151214114642.717a3755@limelight.wooz.org>
 <F622D2CB-74F7-484C-8BBF-5039FDE4FF08@stufft.io>
 <CAP1=2W7n2B7dSsM1HBRxmYY9emM4Xg3G1BOnVw9J3tiv=8=WvA@mail.gmail.com>
 <20151214160357.71e62e49@limelight.wooz.org>
 <20151214214609.669DCB14089@webabinitio.net>
Message-ID: <CAP7+vJJBsDkVyxNNOyBr7OhrMcaZqZ71RuR93dqVzVEP4AJerA@mail.gmail.com>

FWIW we use a bot for commits at Dropbox. Its failure doesn't stop everyone
from doing work -- it just prevents a specific commit from going through
automatically (this won't stop other commits from going through). You can
always manually bypass the bot. So I'm not worried about bots much.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151214/f250ce1b/attachment.html>

From ncoghlan at gmail.com  Mon Dec 14 22:58:37 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 15 Dec 2015 13:58:37 +1000
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <20151214214609.669DCB14089@webabinitio.net>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <40000AA6-F77C-4867-94BF-9618DF1F5A15@stufft.io>
 <566D6ADD.7020309@python.org>
 <CADiSq7e0X5ojnpY9apMtKJ9CMYrbfe8kh1tUrPfLiBoVS4WwoA@mail.gmail.com>
 <CAP7+vJKCRgwaehfr+fB9P_0cjyMRPmW5cjzfyF_2wVt-74BWdg@mail.gmail.com>
 <F54238D3-661C-4E4E-ABE7-3E6FD9734764@stufft.io>
 <20151214114642.717a3755@limelight.wooz.org>
 <F622D2CB-74F7-484C-8BBF-5039FDE4FF08@stufft.io>
 <CAP1=2W7n2B7dSsM1HBRxmYY9emM4Xg3G1BOnVw9J3tiv=8=WvA@mail.gmail.com>
 <20151214160357.71e62e49@limelight.wooz.org>
 <20151214214609.669DCB14089@webabinitio.net>
Message-ID: <CADiSq7f54St4Pd4eXuDCjNX+Q0riFY6oK1sYr6+JzTe6N-SPRA@mail.gmail.com>

On 15 December 2015 at 07:46, R. David Murray <rdmurray at bitdance.com> wrote:
> That said, we really don't want the bot to have only a single
> maintainer, though it may initially have a single author, and ideally
> operations would be responsible for keeping it running.

There are a number of existing Python projects that provide the
scaffolding for handling GitHub webhook requests (e.g.
https://github.com/nickfrostatx/flask-hookserver is a project for
setting up a GitHub bot as a Flask web service), so getting something
up and running on Heroku should be relatively straightforward (Donald
has been looking at PaaS hosting options of late, and a GitHub bot
wouldn't benefit from a full VM in the Rackspace infrastructure).

> There are a number of advantages to having a bot be the way this works
> rather than depending on features of the provider's software, easier
> integration with other tools (ie: the tracker) being a big one.
> It would also presumably make switching providers somewhat easier.

Right, GitLab offers its own webhook support (although I assume the
event details are different), so going with a bot-based workflow even
means that we could even offer a read-write GitLab mirror in the
future, since the bot would handle the actual merge-and-commit process
based on review comments, regardless of which server was used to
submit the review.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From donald at stufft.io  Tue Dec 15 02:32:40 2015
From: donald at stufft.io (Donald Stufft)
Date: Tue, 15 Dec 2015 02:32:40 -0500
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <CADiSq7f54St4Pd4eXuDCjNX+Q0riFY6oK1sYr6+JzTe6N-SPRA@mail.gmail.com>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <40000AA6-F77C-4867-94BF-9618DF1F5A15@stufft.io>
 <566D6ADD.7020309@python.org>
 <CADiSq7e0X5ojnpY9apMtKJ9CMYrbfe8kh1tUrPfLiBoVS4WwoA@mail.gmail.com>
 <CAP7+vJKCRgwaehfr+fB9P_0cjyMRPmW5cjzfyF_2wVt-74BWdg@mail.gmail.com>
 <F54238D3-661C-4E4E-ABE7-3E6FD9734764@stufft.io>
 <20151214114642.717a3755@limelight.wooz.org>
 <F622D2CB-74F7-484C-8BBF-5039FDE4FF08@stufft.io>
 <CAP1=2W7n2B7dSsM1HBRxmYY9emM4Xg3G1BOnVw9J3tiv=8=WvA@mail.gmail.com>
 <20151214160357.71e62e49@limelight.wooz.org>
 <20151214214609.669DCB14089@webabinitio.net>
 <CADiSq7f54St4Pd4eXuDCjNX+Q0riFY6oK1sYr6+JzTe6N-SPRA@mail.gmail.com>
Message-ID: <5ADB254B-D315-42D9-80A1-C22D432E0953@stufft.io>

Only if the review system is used. You still have split brain problems for people merging manually or pushing direct to master. 

Sent from my iPhone

> On Dec 14, 2015, at 10:58 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> going with a bot-based workflow even
> means that we could even offer a read-write GitLab mirror in the
> future, since the bot would handle the actual merge-and-commit process
> based on review comments, regardless of which server was used to
> submit the review.

From ncoghlan at gmail.com  Tue Dec 15 03:09:47 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 15 Dec 2015 18:09:47 +1000
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <5ADB254B-D315-42D9-80A1-C22D432E0953@stufft.io>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <40000AA6-F77C-4867-94BF-9618DF1F5A15@stufft.io>
 <566D6ADD.7020309@python.org>
 <CADiSq7e0X5ojnpY9apMtKJ9CMYrbfe8kh1tUrPfLiBoVS4WwoA@mail.gmail.com>
 <CAP7+vJKCRgwaehfr+fB9P_0cjyMRPmW5cjzfyF_2wVt-74BWdg@mail.gmail.com>
 <F54238D3-661C-4E4E-ABE7-3E6FD9734764@stufft.io>
 <20151214114642.717a3755@limelight.wooz.org>
 <F622D2CB-74F7-484C-8BBF-5039FDE4FF08@stufft.io>
 <CAP1=2W7n2B7dSsM1HBRxmYY9emM4Xg3G1BOnVw9J3tiv=8=WvA@mail.gmail.com>
 <20151214160357.71e62e49@limelight.wooz.org>
 <20151214214609.669DCB14089@webabinitio.net>
 <CADiSq7f54St4Pd4eXuDCjNX+Q0riFY6oK1sYr6+JzTe6N-SPRA@mail.gmail.com>
 <5ADB254B-D315-42D9-80A1-C22D432E0953@stufft.io>
Message-ID: <CADiSq7ffDkgQnqLGXbt2FV4xBD640j0GNbB+Sxu8Y4bMNW2WJg@mail.gmail.com>

On 15 December 2015 at 17:32, Donald Stufft <donald at stufft.io> wrote:
> Only if the review system is used. You still have split brain problems for people merging manually or pushing direct to master.

Right, but that's just "git-with-a-different-host" regardless of the
specific web interface in use - if it was set up, any such mirror repo
would be read/write from a "you can submit and work with change
requests here", rather than "you can use git to push updates here".

Cheers,
Nick.

>
> Sent from my iPhone
>
>> On Dec 14, 2015, at 10:58 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> going with a bot-based workflow even
>> means that we could even offer a read-write GitLab mirror in the
>> future, since the bot would handle the actual merge-and-commit process
>> based on review comments, regardless of which server was used to
>> submit the review.



-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From barry at python.org  Tue Dec 15 10:02:33 2015
From: barry at python.org (Barry Warsaw)
Date: Tue, 15 Dec 2015 10:02:33 -0500
Subject: [core-workflow] PEP 481 repo URL branding
Message-ID: <20151215100233.47184a12@anarchist.wooz.org>

This isn't described in PEP 481.  I think this was briefly mentioned in a
previous message, but I can't find it so I'm starting a new thread.

If PEP 481 is accepted, will we be getting a GitHub enterprise instance that
we can run on git{,hub}.python.org, or will we just use
github.com/python/cpython?

(FTR, the intent of PEP 507 is that we would be getting a GitLab EE or CE
instance running on git{,lab}.python.org).

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151215/19ed78b8/attachment-0001.sig>

From donald at stufft.io  Tue Dec 15 10:31:53 2015
From: donald at stufft.io (Donald Stufft)
Date: Tue, 15 Dec 2015 10:31:53 -0500
Subject: [core-workflow] PEP 481 repo URL branding
In-Reply-To: <20151215100233.47184a12@anarchist.wooz.org>
References: <20151215100233.47184a12@anarchist.wooz.org>
Message-ID: <9B37678B-FC1F-4A27-A7D2-116554CB6CB2@stufft.io>

It's just github.com. We can do a read only mirror to git.python.org if we would like. 

Sent from my iPhone

> On Dec 15, 2015, at 10:02 AM, Barry Warsaw <barry at python.org> wrote:
> 
> This isn't described in PEP 481.  I think this was briefly mentioned in a
> previous message, but I can't find it so I'm starting a new thread.
> 
> If PEP 481 is accepted, will we be getting a GitHub enterprise instance that
> we can run on git{,hub}.python.org, or will we just use
> github.com/python/cpython?
> 
> (FTR, the intent of PEP 507 is that we would be getting a GitLab EE or CE
> instance running on git{,lab}.python.org).
> 
> Cheers,
> -Barry
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct

From guido at python.org  Tue Dec 15 12:15:13 2015
From: guido at python.org (Guido van Rossum)
Date: Tue, 15 Dec 2015 09:15:13 -0800
Subject: [core-workflow] PEP 481 repo URL branding
In-Reply-To: <9B37678B-FC1F-4A27-A7D2-116554CB6CB2@stufft.io>
References: <20151215100233.47184a12@anarchist.wooz.org>
 <9B37678B-FC1F-4A27-A7D2-116554CB6CB2@stufft.io>
Message-ID: <CAP7+vJKFZ4YmrAUmgq8hX19g8CEQhosXykKCpOX4FZBRnvimNg@mail.gmail.com>

I would hope it would be hosted on GitHub. Getting out of the sysadmin
business is one of my goals here.

On Tue, Dec 15, 2015 at 7:31 AM, Donald Stufft <donald at stufft.io> wrote:

> It's just github.com. We can do a read only mirror to git.python.org if
> we would like.
>
> Sent from my iPhone
>
> > On Dec 15, 2015, at 10:02 AM, Barry Warsaw <barry at python.org> wrote:
> >
> > This isn't described in PEP 481.  I think this was briefly mentioned in a
> > previous message, but I can't find it so I'm starting a new thread.
> >
> > If PEP 481 is accepted, will we be getting a GitHub enterprise instance
> that
> > we can run on git{,hub}.python.org, or will we just use
> > github.com/python/cpython?
> >
> > (FTR, the intent of PEP 507 is that we would be getting a GitLab EE or CE
> > instance running on git{,lab}.python.org).
> >
> > Cheers,
> > -Barry
> > _______________________________________________
> > core-workflow mailing list
> > core-workflow at python.org
> > https://mail.python.org/mailman/listinfo/core-workflow
> > This list is governed by the PSF Code of Conduct:
> https://www.python.org/psf/codeofconduct
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct:
> https://www.python.org/psf/codeofconduct
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151215/a5e6ab6d/attachment.html>

From barry at python.org  Tue Dec 15 13:03:50 2015
From: barry at python.org (Barry Warsaw)
Date: Tue, 15 Dec 2015 13:03:50 -0500
Subject: [core-workflow] PEP 481 repo URL branding
In-Reply-To: <CAP7+vJKFZ4YmrAUmgq8hX19g8CEQhosXykKCpOX4FZBRnvimNg@mail.gmail.com>
References: <20151215100233.47184a12@anarchist.wooz.org>
 <9B37678B-FC1F-4A27-A7D2-116554CB6CB2@stufft.io>
 <CAP7+vJKFZ4YmrAUmgq8hX19g8CEQhosXykKCpOX4FZBRnvimNg@mail.gmail.com>
Message-ID: <20151215130350.5859e58d@anarchist.wooz.org>

On Dec 15, 2015, at 09:15 AM, Guido van Rossum wrote:

>I would hope it would be hosted on GitHub. Getting out of the sysadmin
>business is one of my goals here.

The two aren't mutually exclusive.  For PEP 507, I propose a donated and
managed GitLab instance answering to git{,lab}.python.org.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151215/9b73ebdf/attachment.sig>

From barry at python.org  Tue Dec 15 16:19:04 2015
From: barry at python.org (Barry Warsaw)
Date: Tue, 15 Dec 2015 16:19:04 -0500
Subject: [core-workflow] Questions for GitHub's Director of Community
Message-ID: <20151215161904.27e0d89d@anarchist.wooz.org>

Over on the committers mailing list, I mentioned that Jono Bacon, a former
colleague of mine and former Ubuntu Community Manager is now Director of
Community at GitHub.  If you have specific questions about GitHub that you
think Jono can answer in his official capacity, please send them to me directly,
off-list in the next few days.  I'll compile them and forward them on.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151215/e29f9cb6/attachment.sig>

From ericsnowcurrently at gmail.com  Tue Dec 15 20:16:14 2015
From: ericsnowcurrently at gmail.com (Eric Snow)
Date: Tue, 15 Dec 2015 17:16:14 -0800
Subject: [core-workflow] Questions about the proposed workflows
In-Reply-To: <CAP1=2W7149F2LxYZZ-g9WyyJKGMujNh4Lk2UX_qek6WSs9rOLA@mail.gmail.com>
References: <CAP1=2W5BHHfX_qqrwUxAW3aqPnFOmKNXzSnxR2Jf9B+ESc0oOg@mail.gmail.com>
 <40000AA6-F77C-4867-94BF-9618DF1F5A15@stufft.io>
 <566D6ADD.7020309@python.org>
 <375A219B-EAB0-4B97-81A8-594C53CC2C2C@stufft.io>
 <CAP1=2W7149F2LxYZZ-g9WyyJKGMujNh4Lk2UX_qek6WSs9rOLA@mail.gmail.com>
Message-ID: <CALFfu7D6-+iZ7tdT_6iLc-obF8NMHe9f_gVnD1TpxmzqO=qutQ@mail.gmail.com>

On Sun, Dec 13, 2015 at 2:31 PM, Brett Cannon <brett at python.org> wrote:
> Berker also said a bot could do the ff workflow which could also handle the
> NEWS problem as well as long term branches. Assuming that's true and we
> choose to solve those problems that way then it will be true on either
> platform.

FWIW, for juju we've been using a merge bot with github for well over
a year and it's proven effective.  We also have a webhook set up that
interacts with reviewboard for reviews.  Take a look at any of the PRs
at github.com/juju/juju.

The merge button is only available to folks in the project's admin(?)
group.  I expect this could be set up relative to the org as well.
Merges by those in the committer group are initiated by leaving a
"$$some text here$$" comment on the PR, which the bot picks up.  In
the case of juju the merge bot effectively just pushes the merge
button when done, but I expect a merge bot could do other things like
ff or squashing.

-eric

From ncoghlan at gmail.com  Tue Dec 15 20:42:09 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 16 Dec 2015 11:42:09 +1000
Subject: [core-workflow] PEP 481 repo URL branding
In-Reply-To: <20151215130350.5859e58d@anarchist.wooz.org>
References: <20151215100233.47184a12@anarchist.wooz.org>
 <9B37678B-FC1F-4A27-A7D2-116554CB6CB2@stufft.io>
 <CAP7+vJKFZ4YmrAUmgq8hX19g8CEQhosXykKCpOX4FZBRnvimNg@mail.gmail.com>
 <20151215130350.5859e58d@anarchist.wooz.org>
Message-ID: <CADiSq7cV8gffvpf+Ht-tUhS6O8pP5-06WE1x_vweOkf4jC-srQ@mail.gmail.com>

On 16 December 2015 at 04:03, Barry Warsaw <barry at python.org> wrote:
> On Dec 15, 2015, at 09:15 AM, Guido van Rossum wrote:
>
>>I would hope it would be hosted on GitHub. Getting out of the sysadmin
>>business is one of my goals here.
>
> The two aren't mutually exclusive.  For PEP 507, I propose a donated and
> managed GitLab instance answering to git{,lab}.python.org.

>From an organisational branding perspective, the GitHub model tends to
be more focused around GitHub Pages, as in sites like
https://microsoft.github.io/ and simple redirects like
https://google.github.io.

Site markup for the latter arrangement:
https://github.com/google/google.github.io/blob/master/index.mkd

The major advantage of doing that (rather than just linking directly
to the project landing page URL) is that if an organisation's hosting
situation changes in the future, it's a lot easier to appropriately
update a GitHub Pages based microsite than it is direct links to the
project repository on github.com.

It's also possible to use the CNAME support in GitHub Pages to move
the landing page out to a subdomain of another site.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From mal at egenix.com  Wed Dec 16 03:56:05 2015
From: mal at egenix.com (M.-A. Lemburg)
Date: Wed, 16 Dec 2015 09:56:05 +0100
Subject: [core-workflow] PEP 481 repo URL branding
In-Reply-To: <20151215130350.5859e58d@anarchist.wooz.org>
References: <20151215100233.47184a12@anarchist.wooz.org>
 <9B37678B-FC1F-4A27-A7D2-116554CB6CB2@stufft.io>
 <CAP7+vJKFZ4YmrAUmgq8hX19g8CEQhosXykKCpOX4FZBRnvimNg@mail.gmail.com>
 <20151215130350.5859e58d@anarchist.wooz.org>
Message-ID: <56712725.1030505@egenix.com>

On 15.12.2015 19:03, Barry Warsaw wrote:
> On Dec 15, 2015, at 09:15 AM, Guido van Rossum wrote:
> 
>> I would hope it would be hosted on GitHub. Getting out of the sysadmin
>> business is one of my goals here.
> 
> The two aren't mutually exclusive.  For PEP 507, I propose a donated and
> managed GitLab instance answering to git{,lab}.python.org.

Is it possible to setup a CNAME git.python.org which then maps
to the Python github account page ? (*)

I'm not worried much about the github.com in the URLs, but if
we move there with the intent of moving somewhere else in a
few years, then it may be good to avoid breaking links by
using such a more generic URL which is under our control.

(*) FWIW: I've never heard of such a feature, but it would be
a great thing to have :-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Dec 16 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/
________________________________________________________________________

::: We implement business ideas - efficiently in both time and costs :::

   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/
                      http://www.malemburg.com/


From ncoghlan at gmail.com  Wed Dec 16 05:39:18 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 16 Dec 2015 20:39:18 +1000
Subject: [core-workflow] PEP 481 repo URL branding
In-Reply-To: <56712725.1030505@egenix.com>
References: <20151215100233.47184a12@anarchist.wooz.org>
 <9B37678B-FC1F-4A27-A7D2-116554CB6CB2@stufft.io>
 <CAP7+vJKFZ4YmrAUmgq8hX19g8CEQhosXykKCpOX4FZBRnvimNg@mail.gmail.com>
 <20151215130350.5859e58d@anarchist.wooz.org>
 <56712725.1030505@egenix.com>
Message-ID: <CADiSq7eCZAn6wtUeE+dAiuZ2vYsCyCCW=JJ=TGT_0xV4vkW+vw@mail.gmail.com>

On 16 December 2015 at 18:56, M.-A. Lemburg <mal at egenix.com> wrote:
> On 15.12.2015 19:03, Barry Warsaw wrote:
>> On Dec 15, 2015, at 09:15 AM, Guido van Rossum wrote:
>>
>>> I would hope it would be hosted on GitHub. Getting out of the sysadmin
>>> business is one of my goals here.
>>
>> The two aren't mutually exclusive.  For PEP 507, I propose a donated and
>> managed GitLab instance answering to git{,lab}.python.org.
>
> Is it possible to setup a CNAME git.python.org which then maps
> to the Python github account page ? (*)
>
> I'm not worried much about the github.com in the URLs, but if
> we move there with the intent of moving somewhere else in a
> few years, then it may be good to avoid breaking links by
> using such a more generic URL which is under our control.

While it would be possible to set something up using redirects, if
this is aimed at having a canonical *.python.org URL for code
references, that's the best argument I've heard in favour of the
GitHub-with-a-read-only-GitLab-mirror setup - keeping a mirror at a
stable URL regularly updated is straightforward to do indefinitely,
regardless of what else happens with the development workflow.

The idea also raises the question of how long we preserve
hg.python.org/cpython as a read-only Mercurial mirror of the new git
repo.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From brett at python.org  Mon Dec 21 14:45:23 2015
From: brett at python.org (Brett Cannon)
Date: Mon, 21 Dec 2015 19:45:23 +0000
Subject: [core-workflow] workflow proposal update: Xmas week edition
Message-ID: <CAP1=2W7eJTOzZwjFky4tiggZK-SNqZDPEtF7enELet+oLnF5hA@mail.gmail.com>

Just wanted to sum up where I think everything stands as we approach
January 1.

First, everyone seems to like the bot idea for managing pull requests. It
should buy us easier cherry-picking across branches as well as
fast-forward/rebasing PRs so we get a linear history. And all of this done
through the browser. It can also help automate things such as Misc/NEWS and
Misc/ACKS. Plus it buys us workflow independence from our hosting platform
since the bot will be what needs changing if we change hosts in the future
and not how our overall workflow works. Wins for everyone! It also won't be
a blocker on switching since everything being proposed can be done
manually. And I will be pushing for a Monty Python and the Holy Grail black
knight reference for the bot's name and trigger command (black-knight or
none-shall-pass are tied in my head).

Second, my email asking if anyone would walk away from contributing to
Python if we switched to GitHub resulted in *no one* stepping forward. I
actually got an equal number of "I'd prefer not to use GitHub, but I won't
stop contributing" compared to "please choose GitHub" emails. And in the
end there were more emails wanting clarification on the intended tone of
the email than on the topic itself. So switching to GitHub won't impede
development due to its closed source nature.

Third, Guido asked what GitLab offers over GitHub to win over the network
and familiarity effect that GitHub offers. I don't remember a direct reply
to that email yet so if there is something to be pointed out beyond
GitLab's open source nature or ability for us to host our own instance if
something were to happen to GitLab then please let it be known.

I think that's everything up to this point. I'm still hoping we can figure
out all the hosting issues before January 1 so I can make a decision by
then.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151221/107ecc90/attachment.html>

From skrah.temporarily at gmail.com  Wed Dec 30 09:18:12 2015
From: skrah.temporarily at gmail.com (Stefan Krah)
Date: Wed, 30 Dec 2015 14:18:12 +0000 (UTC)
Subject: [core-workflow] Software Factory
References: <loom.20151128T190256-101@post.gmane.org>
 <CAP1=2W79=6WH0g0JE6hTmhi_iytN=LMEQTF4OgB0ooSrk1B7uw@mail.gmail.com>
Message-ID: <loom.20151230T151005-790@post.gmane.org>


Brett Cannon <brett at ...> writes:
> I believe you have to make your profile public for that to be viewable.

I've just created a test account and cannot find any setting to
hide the profile.

On the other hand, there's a setting "Jobs profile: available for hire"...



Stefan Krah


From brett at python.org  Wed Dec 30 11:59:26 2015
From: brett at python.org (Brett Cannon)
Date: Wed, 30 Dec 2015 16:59:26 +0000
Subject: [core-workflow] Software Factory
In-Reply-To: <loom.20151230T151005-790@post.gmane.org>
References: <loom.20151128T190256-101@post.gmane.org>
 <CAP1=2W79=6WH0g0JE6hTmhi_iytN=LMEQTF4OgB0ooSrk1B7uw@mail.gmail.com>
 <loom.20151230T151005-790@post.gmane.org>
Message-ID: <CAP1=2W4FtFJz6DsaAS_BpZ_P5WU4aOt0RCi4uDzXSzJYQNt34g@mail.gmail.com>

Looks like I was wrong and what you can hide is your organization
memberships. As for the job profile, it basically shows job posting in your
news feed. Details on both options can be found at
https://help.github.com/categories/user-accounts/

On Wed, 30 Dec 2015, 06:18 Stefan Krah <skrah.temporarily at gmail.com> wrote:

>
> Brett Cannon <brett at ...> writes:
> > I believe you have to make your profile public for that to be viewable.
>
> I've just created a test account and cannot find any setting to
> hide the profile.
>
> On the other hand, there's a setting "Jobs profile: available for hire"...
>
>
>
> Stefan Krah
>
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct:
> https://www.python.org/psf/codeofconduct
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151230/c658adaf/attachment.html>

From skrah.temporarily at gmail.com  Wed Dec 30 14:03:53 2015
From: skrah.temporarily at gmail.com (Stefan Krah)
Date: Wed, 30 Dec 2015 19:03:53 +0000 (UTC)
Subject: [core-workflow] Software Factory
References: <loom.20151128T190256-101@post.gmane.org>
 <CAP1=2W79=6WH0g0JE6hTmhi_iytN=LMEQTF4OgB0ooSrk1B7uw@mail.gmail.com>
 <loom.20151230T151005-790@post.gmane.org>
 <CAP1=2W4FtFJz6DsaAS_BpZ_P5WU4aOt0RCi4uDzXSzJYQNt34g@mail.gmail.com>
Message-ID: <loom.20151230T193048-491@post.gmane.org>

Brett Cannon <brett at ...> writes:
> Looks like I was wrong and what you can hide is your organization
memberships. As for the job profile, it basically shows job posting in your
news feed. Details on both options can be found at
https://help.github.com/categories/user-accounts/

Ok, thanks.  But this means that GitHub already *is* in the job/recruiting
business. They start small with a news feed, at some point the feed will
become targeted, after that -- once people (esp. age group 14-18) get used
to it -- they can get even more "creative".

Additionally, they strongly encourage a single user account both for work
and volunteer projects, so they have a perfect history of every developer's
activities.


I don't care if they have been profitable by selling private repos on a
small/medium scale, the direction they're heading in is quite clear:

Get people (esp. young ones) to work for free on OSS projects using
gamification, cute icons, "social" coding, and a fake hero-of-work ethos
fueled by "longest streak" statistics.  When these people are ready to enter
the job market, they can <euphemism>be brought in contact with</euphemism>
employers.



Stefan Krah


From mal at egenix.com  Wed Dec 30 18:07:47 2015
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 31 Dec 2015 00:07:47 +0100
Subject: [core-workflow] Software Factory
In-Reply-To: <loom.20151230T193048-491@post.gmane.org>
References: <loom.20151128T190256-101@post.gmane.org>
 <CAP1=2W79=6WH0g0JE6hTmhi_iytN=LMEQTF4OgB0ooSrk1B7uw@mail.gmail.com>
 <loom.20151230T151005-790@post.gmane.org>
 <CAP1=2W4FtFJz6DsaAS_BpZ_P5WU4aOt0RCi4uDzXSzJYQNt34g@mail.gmail.com>
 <loom.20151230T193048-491@post.gmane.org>
Message-ID: <568463C3.2060500@egenix.com>

On 30.12.2015 20:03, Stefan Krah wrote:
> Brett Cannon <brett at ...> writes:
>> Looks like I was wrong and what you can hide is your organization
> memberships. As for the job profile, it basically shows job posting in your
> news feed. Details on both options can be found at
> https://help.github.com/categories/user-accounts/
> 
> Ok, thanks.  But this means that GitHub already *is* in the job/recruiting
> business. They start small with a news feed, at some point the feed will
> become targeted, after that -- once people (esp. age group 14-18) get used
> to it -- they can get even more "creative".
> 
> Additionally, they strongly encourage a single user account both for work
> and volunteer projects, so they have a perfect history of every developer's
> activities.
> 
> 
> I don't care if they have been profitable by selling private repos on a
> small/medium scale, the direction they're heading in is quite clear:
> 
> Get people (esp. young ones) to work for free on OSS projects using
> gamification, cute icons, "social" coding, and a fake hero-of-work ethos
> fueled by "longest streak" statistics.  When these people are ready to enter
> the job market, they can <euphemism>be brought in contact with</euphemism>
> employers.

FWIW: This business model is already being used by other companies
scraping Github repos, analyzing checkins and then matching what
they find against recruitment offers (basically automated head
hunting).

The same could be done with any other DVCS repo system, but Github
is currently the most popular one out there. Ohloh, now renamed to
Open Hub, has been doing such analysis for quite a while (with
a different focus, though):

https://www.openhub.net/p/python/contributors

That's simply a consequence of having repos out in the open
and not really specific to Github.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Dec 30 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/
________________________________________________________________________

::: We implement business ideas - efficiently in both time and costs :::

   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/
                      http://www.malemburg.com/


From skrah.temporarily at gmail.com  Wed Dec 30 19:00:36 2015
From: skrah.temporarily at gmail.com (Stefan Krah)
Date: Thu, 31 Dec 2015 00:00:36 +0000 (UTC)
Subject: [core-workflow] Software Factory
References: <loom.20151128T190256-101@post.gmane.org>
 <CAP1=2W79=6WH0g0JE6hTmhi_iytN=LMEQTF4OgB0ooSrk1B7uw@mail.gmail.com>
 <loom.20151230T151005-790@post.gmane.org>
 <CAP1=2W4FtFJz6DsaAS_BpZ_P5WU4aOt0RCi4uDzXSzJYQNt34g@mail.gmail.com>
 <loom.20151230T193048-491@post.gmane.org> <568463C3.2060500@egenix.com>
Message-ID: <loom.20151231T004320-11@post.gmane.org>


M.-A. Lemburg <mal at ...> writes:
> On 30.12.2015 20:03, Stefan Krah wrote:
> > I don't care if they have been profitable by selling private repos on a
> > small/medium scale, the direction they're heading in is quite clear:
> > 
> > Get people (esp. young ones) to work for free on OSS projects using
> > gamification, cute icons, "social" coding, and a fake hero-of-work ethos
> > fueled by "longest streak" statistics.  When these people are ready to enter
> > the job market, they can <euphemism>be brought in contact with</euphemism>
> > employers.
> 
> FWIW: This business model is already being used by other companies
> scraping Github repos, analyzing checkins and then matching what
> they find against recruitment offers (basically automated head
> hunting).
> 
> The same could be done with any other DVCS repo system, but Github
> is currently the most popular one out there. Ohloh, now renamed to
> Open Hub, has been doing such analysis for quite a while (with
> a different focus, though):
> 
> https://www.openhub.net/p/python/contributors
> 
> That's simply a consequence of having repos out in the open
> and not really specific to Github.

GitHub takes this to a new limit: When you create an account, you
are being told (gamification-style) how to get dark green squares
in your statistics, how to promote yourself using a picture, how
to use a single account for private and public repos, how to
keep the single account *even when switching companies*!


If you happen to work for a company that's on GitHub *and*
contribute to volunteer projects there, they basically have a
major part of your life on their servers. I don't think
OpenHub can match that in any way.


I'm not anti-corporate: If Microsoft would make us an offer
to manage our infrastructure, I'd rather have a Microsoft
account for Python development that a GitHub account.



Stefan Krah

















From ncoghlan at gmail.com  Wed Dec 30 23:21:26 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 31 Dec 2015 14:21:26 +1000
Subject: [core-workflow] Longer term idea: consider Rust's homu for CPython
 merge gating
Message-ID: <CADiSq7cNih+AS2DU__UXSYvT3Qe6vG8kym27nzJgcck1UNAzTg@mail.gmail.com>

(Note: near term, this probably isn't a useful idea, as the current
GitHub & GitLab proposals aren't proposing the introduction of merge
gating, merely advisory testing of PRs, so folks will remain free to
merge patches locally and push them up to the master repository.
However, I think pre-merge testing is a good idea long term, with
approving our own PRs taking the place of pushing directly to the
development and maintenance branches)

I recently came across an old article [1] by Rust's Graydon Hoare
regarding their approach to pre-merge testing of commits using GitHub
PRs and Buildbot. Following up on that brought me to a more up to date
explanation of their current bot setup [2], and the http://homu.io/
service for running it against a project without hosting your own
instance (in our case, if we did run a service like Homu, we'd likely
still want to host our own instance, as Mozilla do for Rust and
Servo).

Similar to OpenStack's Zuul, Homu serialises commits, ensuring that
the test suite is passing *before* code lands on the target branch.
The relevant differences are that Homu is designed to use GitHub PRs
rather than Gerrit reviews as the event source, and Travis CI and
Buildbot rather than Jenkins as the CI backends for actually running
the integration tests. (Homu is also currently missing Zuul's
"speculative test pipeline" feature, which allows it to test multiple
commits in parallel on the assumption that most of them will pass due
to prior testing in isolation, but has a separate feature that allows
PRs to be tagged for inclusion in "rollup" commits that land several
changes at once after testing them as a group)

The current merge queue for Rust itself can be seen at
http://buildbot.rust-lang.org/homu/queue/rust

Regards,
Nick.

[1] http://graydon2.dreamwidth.org/1597.html
[2] http://huonw.github.io/blog/2015/03/rust-infrastructure-can-be-your-infrastructure/

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From ncoghlan at gmail.com  Thu Dec 31 01:39:58 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 31 Dec 2015 16:39:58 +1000
Subject: [core-workflow] Software Factory
In-Reply-To: <loom.20151231T004320-11@post.gmane.org>
References: <loom.20151128T190256-101@post.gmane.org>
 <CAP1=2W79=6WH0g0JE6hTmhi_iytN=LMEQTF4OgB0ooSrk1B7uw@mail.gmail.com>
 <loom.20151230T151005-790@post.gmane.org>
 <CAP1=2W4FtFJz6DsaAS_BpZ_P5WU4aOt0RCi4uDzXSzJYQNt34g@mail.gmail.com>
 <loom.20151230T193048-491@post.gmane.org>
 <568463C3.2060500@egenix.com>
 <loom.20151231T004320-11@post.gmane.org>
Message-ID: <CADiSq7fX8jV2wBGx-cAnZe0bnEMH0UQ21N3FB0wyiTDvtq_W2w@mail.gmail.com>

On 31 December 2015 at 10:00, Stefan Krah <skrah.temporarily at gmail.com> wrote:
>
> M.-A. Lemburg <mal at ...> writes:
>> On 30.12.2015 20:03, Stefan Krah wrote:
>> > I don't care if they have been profitable by selling private repos on a
>> > small/medium scale, the direction they're heading in is quite clear:
>> >
>> > Get people (esp. young ones) to work for free on OSS projects using
>> > gamification, cute icons, "social" coding, and a fake hero-of-work ethos
>> > fueled by "longest streak" statistics.  When these people are ready to enter
>> > the job market, they can <euphemism>be brought in contact with</euphemism>
>> > employers.
>>
>> FWIW: This business model is already being used by other companies
>> scraping Github repos, analyzing checkins and then matching what
>> they find against recruitment offers (basically automated head
>> hunting).
>>
>> The same could be done with any other DVCS repo system, but Github
>> is currently the most popular one out there. Ohloh, now renamed to
>> Open Hub, has been doing such analysis for quite a while (with
>> a different focus, though):
>>
>> https://www.openhub.net/p/python/contributors
>>
>> That's simply a consequence of having repos out in the open
>> and not really specific to Github.
>
> GitHub takes this to a new limit: When you create an account, you
> are being told (gamification-style) how to get dark green squares
> in your statistics, how to promote yourself using a picture, how
> to use a single account for private and public repos, how to
> keep the single account *even when switching companies*!
>
> If you happen to work for a company that's on GitHub *and*
> contribute to volunteer projects there, they basically have a
> major part of your life on their servers. I don't think
> OpenHub can match that in any way.
>
> I'm not anti-corporate: If Microsoft would make us an offer
> to manage our infrastructure, I'd rather have a Microsoft
> account for Python development that a GitHub account.

I actually share a lot of Stefan's concerns regarding the potential
for exploitation of community volunteers that is involved in GitHub's
business model - being a late-entering competitor in an already
crowded Enterprise VCS market (where version control is just one piece
of the larger Application Lifecycle Management puzzle) doesn't justify
the kind of VC investment that GitHub has been receiving, while
GitHub's potential as the preferred platform for connecting open
source contributors with large organisations adopting and creating
open source software *does* justify that kind of investment. "Going
where the developers are" is certainly the justification I see used to
advocate for even established open source organisations setting up
shop there rather than hosting their own repositories on a more
obviously company or project branded site.

However, it's also important to acknowledge that corporate
exploitation of open source community volunteers is *already
happening* - it's a cultural norm for profitable companies to deploy
and run open source software without allocating even a single hour of
their employees' time to contributing back to the projects they use,
figuring out a way to compensate existing contributors to improve the
sustainability of upstream projects, or paying a non-profit foundation
or commercial redistributor to handle those problems on their behalf
(and even community non-profits and commercial redistributors aren't
as good at handling those tasks on behalf of sponsors, customers and
contributors as we should be).

As such, I've come to the conclusion that the potential for
exploitation of community members isn't a strong argument against
community projects like CPython adopting GitHub for code hosting and
review, as making contributions more readily visible actually has the
potential to *reduce* exploitation by helping contributors to
strengthen their negotiating position in various commercial contexts.

Since I'm also a strong advocate for tackling that problem at the
employer/employee boundary [1] rather than the vendor/customer one,
the case can even be made that GitHub's approach to changing that
dynamic (i.e. baking it in as an inherent feature of the way their
free-as-in-beer software hosting platform works) may prove to be more
effective than asking people to do it voluntarily [2] or leaving it to
foundations and companies to invest in their own data gathering [3,4].

Regards,
Nick.

[1] http://community.redhat.com/blog/2015/02/the-quid-pro-quo-of-open-infrastructure/
[2] https://docs.python.org/devguide/motivations.html
[3] http://stackalytics.com/
[4] https://www.rdoproject.org/stats/browser/

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From brett at python.org  Thu Dec 31 15:21:06 2015
From: brett at python.org (Brett Cannon)
Date: Thu, 31 Dec 2015 20:21:06 +0000
Subject: [core-workflow] Longer term idea: consider Rust's homu for
 CPython merge gating
In-Reply-To: <CADiSq7cNih+AS2DU__UXSYvT3Qe6vG8kym27nzJgcck1UNAzTg@mail.gmail.com>
References: <CADiSq7cNih+AS2DU__UXSYvT3Qe6vG8kym27nzJgcck1UNAzTg@mail.gmail.com>
Message-ID: <CAP1=2W4enSoKFOnsLDauXMyZuueirr6ZA4TiWATK+uP+2p=52g@mail.gmail.com>

Thanks for the link! For those that didn't look at the link, Homu is
actually written in Python and not Rust (the website for the project is
what's written in Rust).

Berker has actually said he is beginning to look into writing a bot for our
needs so he might be interested in this.

A quick perusal suggests it probably needs to be modified to understand
supporting multiple branches. I also don't know if it supports the
fast-forwarding/rebasing commits we want, but I doubt that would be
difficult to add. It probably also needs to grow an extension system
somehow to support custom NEWS entries for us.

But it probably would be really nice for the Python and Rust communities to
share some of the infrastructure burden by working on the same tooling
(especially if we even consider using their auto-assignment to help get
patches reviewed).

On Wed, 30 Dec 2015 at 20:21 Nick Coghlan <ncoghlan at gmail.com> wrote:

> (Note: near term, this probably isn't a useful idea, as the current
> GitHub & GitLab proposals aren't proposing the introduction of merge
> gating, merely advisory testing of PRs, so folks will remain free to
> merge patches locally and push them up to the master repository.
> However, I think pre-merge testing is a good idea long term, with
> approving our own PRs taking the place of pushing directly to the
> development and maintenance branches)
>
> I recently came across an old article [1] by Rust's Graydon Hoare
> regarding their approach to pre-merge testing of commits using GitHub
> PRs and Buildbot. Following up on that brought me to a more up to date
> explanation of their current bot setup [2], and the http://homu.io/
> service for running it against a project without hosting your own
> instance (in our case, if we did run a service like Homu, we'd likely
> still want to host our own instance, as Mozilla do for Rust and
> Servo).
>
> Similar to OpenStack's Zuul, Homu serialises commits, ensuring that
> the test suite is passing *before* code lands on the target branch.
> The relevant differences are that Homu is designed to use GitHub PRs
> rather than Gerrit reviews as the event source, and Travis CI and
> Buildbot rather than Jenkins as the CI backends for actually running
> the integration tests. (Homu is also currently missing Zuul's
> "speculative test pipeline" feature, which allows it to test multiple
> commits in parallel on the assumption that most of them will pass due
> to prior testing in isolation, but has a separate feature that allows
> PRs to be tagged for inclusion in "rollup" commits that land several
> changes at once after testing them as a group)
>
> The current merge queue for Rust itself can be seen at
> http://buildbot.rust-lang.org/homu/queue/rust
>
> Regards,
> Nick.
>
> [1] http://graydon2.dreamwidth.org/1597.html
> [2]
> http://huonw.github.io/blog/2015/03/rust-infrastructure-can-be-your-infrastructure/
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct:
> https://www.python.org/psf/codeofconduct
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151231/2698feda/attachment.html>

From ncoghlan at gmail.com  Thu Dec 31 23:47:23 2015
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 1 Jan 2016 14:47:23 +1000
Subject: [core-workflow] Longer term idea: consider Rust's homu for
 CPython merge gating
In-Reply-To: <CAP1=2W4enSoKFOnsLDauXMyZuueirr6ZA4TiWATK+uP+2p=52g@mail.gmail.com>
References: <CADiSq7cNih+AS2DU__UXSYvT3Qe6vG8kym27nzJgcck1UNAzTg@mail.gmail.com>
 <CAP1=2W4enSoKFOnsLDauXMyZuueirr6ZA4TiWATK+uP+2p=52g@mail.gmail.com>
Message-ID: <CADiSq7d6=0NpubKXN2pEGUj=B1cjDHzGdyLagtsSNCTVKKqeew@mail.gmail.com>

On 1 January 2016 at 06:21, Brett Cannon <brett at python.org> wrote:
> Thanks for the link! For those that didn't look at the link, Homu is
> actually written in Python and not Rust (the website for the project is
> what's written in Rust).
>
> Berker has actually said he is beginning to look into writing a bot for our
> needs so he might be interested in this.
>
> A quick perusal suggests it probably needs to be modified to understand
> supporting multiple branches. I also don't know if it supports the
> fast-forwarding/rebasing commits we want, but I doubt that would be
> difficult to add. It probably also needs to grow an extension system somehow
> to support custom NEWS entries for us.

Which reminds me, Amber Brown recently wrote a NEWS file generator
based on the file-per-issue model, later assembled into a NEWS file
section as part of the project's release process:
https://github.com/hawkowl/towncrier

It's aimed more at projects with a simple linear release history
rather than CPython's branching sprawl, though.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia