[core-workflow] My initial thoughts on the steps/blockers of the transition

[Berker Peksağ]

On Tue, Jan 5, 2016 at 8:13 PM, Brett Cannon <brett at python.org> wrote:
> Day 1 summary
> ============
>
> Decisions made
> -----------------------
> - We will create a python-dev team in the python org and add that team to
> all of the relevant repos that get migrated
> - We will add a GitHub field to Roundup and then write/get a CLA bot that
> will query Roundup to check if someone has (not) signed the CLA
> - For ancillary repos, the merge-of-least-resistance workflow is fine, so no
> need to worry about maintaining a linear history
> - We are going to keep all of the cpython history in a single repo
> - We will have PRs go against master and then we will cherry pick into
> bugfix branches
> - Misc/ACKS will be kept and we will write code to update it on occasion --
> probably at release time -- based on git commit data
> - Seems like our current commit ID -> URL service can be updated to handle
> our transition
>
>
> Open issues
> -------------------
> - What tools and commands will we use to convert the repos?
> - How do we want to handle Misc/NEWS?
> - What are the exact commands we are going to expect core devs to run (which
> will be documented in the devguide)?

I use the following commands for python.org:

    $ git pr NNN

"git pr" is an alias and an equivalent of

    $ git fetch upstream pull/NNN/head:pr/NNN
    $ git checkout pr/NNN

For example, if I want to review
https://github.com/python/pythondotorg/pull/859, I use "git pr 859".

Run tests, tweak commit message, code style, and commit

    $ git commit -m "Update foo bar"

Squash commits

    $ git rebase -i HEAD~2

And merge

   $ git checkout master
   $ git merge --ff-only pr/NNN

(--ff-only can be added to .gitconfig)

Backport to 3.5 (the branch name is "release" for python.org)

   $ git checkout 3.5
   $ git cherry-pick `git rev-parse master`

And push to upstream

   $ git push --all upstream

We probably should mention the -u option (or create a new section for
Git configuration and best practices) in the devguide.

> - Who to use for CI (although Donald is the only one to speak up and likes
> Travis as do I, so this might be decided)?

+1 to use Travis as a pre-merge CI. I'd vote for keeping Travis
configuration simple (e.g. use only Linux and GCC, run rstlint in
Doc/)

--Berker