[core-workflow] Other thoughts on the workflow

[Donald Stufft]

> On Nov 29, 2015, at 11:08 PM, Guido van Rossum <guido at python.org> wrote:
> 
> On Sun, Nov 29, 2015 at 7:54 PM, Nick Coghlan <ncoghlan at gmail.com <mailto:ncoghlan at gmail.com>> wrote:
> On 30 November 2015 at 03:12, Brett Cannon <brett at python.org <mailto:brett at python.org>> wrote:
> > Thanks for the feedback. And the "do nothing" option is there, although it's
> > so disliked by so many people that the chances of us not changing our
> > workflow is pretty slim.
> 
> The interests of folks that prefer the terminal focused
> "commit-locally-and-push" workflow can still be taken into account in
> the evaluation though - while it appears likely either GitHub or
> GitLab will be adopted as the repository management service, whether
> or not the maintenance branches and the default branch are marked as
> protected so even core developers *have* to go through the web based
> merge process is a separate question.
> 
> What?! I've never worked with a GitHub-based project where you *had* to use the web-based merge process. Hopefully that's not really on the table. In fact I'm not a big fan of GitHub's web-based merge process at all -- I much prefer seeing a simple linear history in the master (and I don't like preserving  intermediate commits made during the PR review process).

I don’t believe Github even has an option where you *have* to use the web-based merge process. The closest thing they have is protected branches (disables force pushes, but not regular pushes) and required status checks (PRs have to pass certain pre merge tests before the merge button lights up).

Maybe the required status checks disables pushes all together but I don’t think it does and even if it did that feature (as currently implemented anyways) doesn’t make sense for us because it essentially requires all PRs to get rebased or have master merged into them before they can be merged via the merge button which is a massive pain for OSS teams of any size or velocity.

> 
> There are also tools like git-pulls (Ruby:
> https://github.com/schacon/git-pulls <https://github.com/schacon/git-pulls>) and hub (Go:
> https://hub.github.com/ <https://hub.github.com/>) that let folks review and merge GitHub PRs
> from the terminal. (I had a quick look through some of the command
> line clients listed at https://about.gitlab.com/applications/ <https://about.gitlab.com/applications/>, but
> didn't see anything as workflow focused as git-pulls or hub, so "good
> support for terminal based usage" may count as a concrete technical
> differentiator here)
> 
> Review and merge process should be separable. After 10+ years of using web-based review tools I personally wouldn't dream of using a terminal-based *review* (as opposed to merge) process. Though of course if that's your preference you should be able to do it.
> 

I don’t know about Gitlab, but GitHub exposes PRs as heads in the remote repository. You have to add a single line to your .git/config in that repository, but once you do they are available to use any regular git command against (check them out, diff them, whatever). Doing that won’t get the comments on the PR and the pre merge test status and such of course, but someone can merge a PR just by doing (if configured):

$ git merge upstream/pr/XXXX

Here’s my configuration for the pip repository on GitHub that is configured in this way: https://bpaste.net/show/77b17a2571f0 <https://bpaste.net/show/77b17a2571f0> Line #14 is the important part. This also makes my local master and develop branch track the upstream repository, while my own branches get pushed to my fork which is the origin remote.


-----------------
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/20151129/b9226225/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/20151129/b9226225/attachment.sig>