Brett has asked for feedback until Dec 1st, so here are my quick random thoughts:
1) GitHub's UI is more polished than GitLab's.
2) GitHub pull requests are not universally liked (see famous Torvalds rant "... pull requests and the online commit editing, are just pure ...").
3) Attracting contributors? This was also an argument for the svn -> hg change, but it did not happen IMO. On the contrary, patches like https://bugs.python.org/issue3526 seem to be more rare.
4) Personally, I probably would not have contributed to Python if a GitHub account had been required back in 2012. But the time may come when one is excluded entirely from any Open Source contributions without a GitHub account...
5) The "do-nothing" option hasn't been mentioned: The current setup is actually quite nice compared to almost 99% of other projects. I like it better than both GitHub/GitLab.
Stefan Krah
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.
On Sat, 28 Nov 2015 at 12:22 Stefan Krah skrah.temporarily@gmail.com wrote:
Brett has asked for feedback until Dec 1st, so here are my quick random thoughts:
GitHub's UI is more polished than GitLab's.
GitHub pull requests are not universally liked (see famous Torvalds rant "... pull requests and the online commit editing, are just pure ...").
Attracting contributors? This was also an argument for the svn -> hg change, but it did not happen IMO. On the contrary, patches like https://bugs.python.org/issue3526 seem to be more rare.
Personally, I probably would not have contributed to Python if a GitHub account had been required back in 2012. But the time may come when one is excluded entirely from any Open Source contributions without a GitHub account...
The "do-nothing" option hasn't been mentioned: The current setup is actually quite nice compared to almost 99% of other projects. I like it better than both GitHub/GitLab.
Stefan Krah
core-workflow mailing list core-workflow@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
On 30 November 2015 at 03:12, Brett Cannon brett@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.
There are also tools like git-pulls (Ruby: https://github.com/schacon/git-pulls) and hub (Go: 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/, 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)
Cheers, Nick.
On Sun, Nov 29, 2015 at 7:54 PM, Nick Coghlan ncoghlan@gmail.com wrote:
On 30 November 2015 at 03:12, Brett Cannon brett@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).
There are also tools like git-pulls (Ruby: https://github.com/schacon/git-pulls) and hub (Go: 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/, 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.
On Nov 29, 2015, at 11:08 PM, Guido van Rossum guido@python.org wrote:
On Sun, Nov 29, 2015 at 7:54 PM, Nick Coghlan <ncoghlan@gmail.com mailto:ncoghlan@gmail.com> wrote: On 30 November 2015 at 03:12, Brett Cannon <brett@python.org mailto:brett@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
On Sun, 29 Nov 2015 at 21:08 Guido van Rossum guido@python.org wrote:
On Sun, Nov 29, 2015 at 7:54 PM, Nick Coghlan ncoghlan@gmail.com wrote:
On 30 November 2015 at 03:12, Brett Cannon brett@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).
Donald addressed the protected branch bits, but the web-based PR merging will be discussed as a possible allowed workflow. It doesn't have to be settled now but just so you know my position, I like the web-based merging as it means I don't have to worry about being on a machine with a repo and SSH keys in order to do a merge (e.g., I could do a merge from my Chromebook while on vacation or at work on my lunch break without issue). I also don't mind the intermediate merges as it gives contributors proper attribution for their work (you can use I believe `git log --merges` to only see git merge logs which would be written by core devs).
-Brett
There are also tools like git-pulls (Ruby: https://github.com/schacon/git-pulls) and hub (Go: 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/, 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.
-- --Guido van Rossum (python.org/~guido)
When I said intermediate merges, I meant additional detail like "fix typos and remove dead code" in this PR to asyncio: https://github.com/python/asyncio/pull/290/commits . And I don't like to see merge turds like these in my history (we've experimented with this a bunch in the asyncio repo):
* b516e80 Merge pull request #231 from haypo/issue_222 |\ | * b08ee40 Fix @coroutine for functions without __name__ * | cd10ff2 Merge pull request #237 from ajdavis/update-queue-join-tests |\ \ | * | 70d8856 Fix queue join tests for CPython's test runner. |/ / * | bcb7ec4 Merge pull request #236 from ajdavis/queue-join-fix |\ \ | * | e496c7c Fix LifoQueue's and PriorityQueue's put() and task_done(). | * | a943b49 Test LifoQueue's and PriorityQueue's put() and task_done(). |/ / * | 7718675 #230: Change official URL from tulip to asyncio in README.rst |/ * 173ff86 Update README.rst * 4f9099e Merge pull request #225 from Eyepea/add_pycharm_in_gitignore |\ | * 30f4788 add in .gitignore pyvenv and Pycharm files |/ * 3582e11 Merge pull request #224 from Eyepea/readme_improvement |\ | * bf4b2ce Rename README file to have rst render on Github * | 1888b1d Switch hgignore and hgeol to git equivalents |/
But of course I would love a web-based merge flow that doesn't create such turds! (It must be possible, since I can do it manually. :-)
Also, AFAIK git keeps separate track of who authored a change and who committed it, so credit to contributors should still be maintainable.
On Sun, Nov 29, 2015 at 8:54 PM, Brett Cannon brett@python.org wrote:
On Sun, 29 Nov 2015 at 21:08 Guido van Rossum guido@python.org wrote:
On Sun, Nov 29, 2015 at 7:54 PM, Nick Coghlan ncoghlan@gmail.com wrote:
On 30 November 2015 at 03:12, Brett Cannon brett@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).
Donald addressed the protected branch bits, but the web-based PR merging will be discussed as a possible allowed workflow. It doesn't have to be settled now but just so you know my position, I like the web-based merging as it means I don't have to worry about being on a machine with a repo and SSH keys in order to do a merge (e.g., I could do a merge from my Chromebook while on vacation or at work on my lunch break without issue). I also don't mind the intermediate merges as it gives contributors proper attribution for their work (you can use I believe `git log --merges` to only see git merge logs which would be written by core devs).
-Brett
There are also tools like git-pulls (Ruby: https://github.com/schacon/git-pulls) and hub (Go: 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/, 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.
-- --Guido van Rossum (python.org/~guido)
On 30 November 2015 at 14:31, Donald Stufft donald@stufft.io wrote:
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).
You're right, I was thinking of the GitLab variant of protected branches, where you can turn off pushing entirely for folks with Developer permissions in order to require that all changes go through the review process: http://doc.gitlab.com/ce/workflow/protected_branches.html
Cheers, Nick.
On Nov 29, 2015, at 08:08 PM, Guido van Rossum wrote:
What?! I've never worked with a GitHub-based project where you *had* to use the web-based merge process.
All GitLab merge requests have a button that pops up the commands you can copy and paste into your terminal to do a local, manual merge. There are several reasons why I'll do it that way:
* I might want to clean up the branch a little bit and not bog the submitter down with style nits or whitespace issues. * I might have to add a NEWS entry. * I might want want run the test suite with a fix not applied, just to prove that the test actually exposes the problem. * I might want to manually rebase all those commits for cleaner history or easier cherry-picking to stable branches.
OTOH, when something looks pretty clean, I'll just hit the auto-merge button, perhaps telling it to rebase first.
I don't think there's anything special about GitLab here. Either GitHub has something similar, or it's just as easy to do via command line git if you can remember the incantations.
Cheers, -Barry
On Nov 29, 2015, at 11:31 PM, Donald Stufft wrote:
I don’t know about Gitlab, but GitHub exposes PRs as heads in the remote repository.
Yes, GitLab has essentially the same thing. I personally recommend fetching the merge request branch, and then switching to it locally via some name, e.g.
$ git fetch https://gitlab.com/person/mailman.git branch-to-merge $ git checkout -b person/27 FETCH_HEAD
Now I clean up the person/27 branch, maybe make more comments, rebase, etc. Once I'm happy with the branch, it's simple to
$ git co master $ git merge person/27 $ git push
I generally let it fast-forward merge if possible (which it usually is if I rebase).
Cheers, -Barry
On Nov 29, 2015, at 09:19 PM, Guido van Rossum wrote:
But of course I would love a web-based merge flow that doesn't create such turds! (It must be possible, since I can do it manually. :-)
`git rebase -i` is a great tool (especially nice with Emacs :) so I usually fixup or squash those little clean ups I do to someone else's merge proposal.
Cheers, -Barry
participants (6)
-
Barry Warsaw -
Brett Cannon -
Donald Stufft -
Guido van Rossum -
Nick Coghlan -
Stefan Krah