[core-workflow] Spelling out a suggested local workflow for sending PRs?

[Brett Cannon]

On Sun, 6 Mar 2016 at 07:24 Paul Hoffman <paul.hoffman at gmail.com> wrote:

> I suggest that this be added to the new devguide, not a PEP, because there
> are many workflows that work for different people.
>

Yep, this isn't policy but simply a suggestion, so it should go in the
devguide.


>
> One category of workflow is "make a clone on GitHub for each suggested
> patch, then nuke that clone and start over for the next patch". A different
> category of workflow is "clone on GitHub, clone from there to my local
> machine, and keep my local machine up-to-date with the origin so I can keep
> putting in patches easily". And there are other workflows that are
> supported by different small tooling.
>
> FWIW, I still don't know which I prefer. We are having this issue in the
> IETF, and it is clear that people don't all agree on what they prefer.
>
> I'm happy to write text up on this for the devguide when it gets time to
> do so.
>

Great! Thanks, Paul!

My hope is that we get the devguide moved over early so that we can create
a "github" branch to hold the GitHub-related changes so that as soon as
cpython is ready to switch it will take nothing more than a merge of the
branch into `master` to make the changes appear online.

-Brett


>
> --Paul Hoffman
>
> On Sun, Mar 6, 2016 at 1:27 AM, Oleg Broytman <phd at phdru.name> wrote:
>
>> That should be added to the new devguide or a PEP.
>>
>> On Sun, Mar 06, 2016 at 12:27:52PM +1000, Nick Coghlan <
>> ncoghlan at gmail.com> wrote:
>> > Something that came up at work recently was instructing people on how
>> best
>> > to configure local git clones for working with a "fork+PR" development
>> > model, where you have your own server-side fork for the project that you
>> > then use to submit pull requests. The trick is that there's an easy way
>> to
>> > do this and a hard way, and it isn't immediately obvious which is which
>> :)
>> >
>> > The easy way:
>> >
>> > * clone the upstream repo read-only
>> > * add your fork as an additional read/write remote:
>> >   * e.g. "git remote add pr <URL of fork>"
>> > * work in a branch
>> >   * e.g. "git checkout master && git checkout -b
>> issueNNNN-summary-of-issue"
>> > * publish via your fork, and then submit back to the main repo
>> >   * "git push pr"
>> >   * use the web UI to submit the PR
>> >
>> > The hard way:
>> >
>> > * clone your fork read/write
>> > * still work in topic branches
>> > * waste time keeping master in your fork up to date
>> > * forget the previous step, and submit PRs against a stale version of
>> master
>> >
>> > I bring it up as when I first started using GitHub, the second way
>> seemed
>> > intuitively obvious to me, but it actually makes things harder than they
>> > need to be.
>> >
>> > Cheers,
>> > Nick.
>> >
>> > --
>> > Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>>
>> Oleg.
>> --
>>      Oleg Broytman            http://phdru.name/
>> phd at phdru.name
>>            Programmers don't die, they just GOSUB without RETURN.
>> _______________________________________________
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160307/68f9b46a/attachment-0001.html>