[core-workflow] Other thoughts on the workflow

[Guido van Rossum]

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 at python.org> wrote:

>
>
> On Sun, 29 Nov 2015 at 21:08 Guido van Rossum <guido at python.org> wrote:
>
>> On Sun, Nov 29, 2015 at 7:54 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>>> On 30 November 2015 at 03:12, Brett Cannon <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).
>>
>
> 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)
>>
>


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