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