On Tue, Jan 5, 2016 at 8:13 PM, Brett Cannon <br...@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
_______________________________________________
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
