Add more GH migration details (#136)

pep-0512.txt

@@ -332,6 +332,16 @@ revision in the Mercurial repository. The URL rewriter will need to
 be updated to redirect to the Git repository and to support the new
 revision IDs created for the Git repository.
 
+The most likely design is to statically know all the Mercurial
+changeset numbers once the migration has occurred. The lookup code
+will then be updated to accept hashes from 7 to 40 hexadecimal digits.
+Any hexadecimal of length 12 or 40 will be compared against the
+Mercurial changeset numbers. If the number doesn't match or is of some
+other length between 7 and 40 then it will be assumed to be a Git hash.
+
+The `bugs.python.org commit number rewriter <https://hg.python.org/tracker/python-dev/file/tip/extensions/local_replace.py#l76>`__
+will also need to be updated to accept hashes as short as 7 digits as
+Git will match on hashes that short or longer.
 
 Deprecate sys._mercurial
 ''''''''''''''''''''''''
@@ -468,19 +478,28 @@ GitHub to some other code review system is feasible were GitHub to
 disappear overnight.
 
 
-Bot to handle pull request merging
+Bot to generate cherry-pick pull requests
-''''''''''''''''''''''''''''''''''
+''''''''''''''''''''''''''''''''''''''''''
 
-To start, the bot should accept commands to commit a pull request
+Since the decision has been made to work with cherry-picks instead of
-against a list of branches. This allows for committing a pull request
+forward merging of branches, it would be convenient to have a bot that
-that fixes a bug in multiple versions of Python.
+would generate pull requests based on cherry-picking for any pull
+requests that affect multiple branches. The most likely design is a
+bot that monitors merged pull requests with key labels applied that
+delineate what branches the pull request should be cherry-picked into.
+The bot would then generate cherry-pick pull requests for each label
+and remove the labels as the pull requests are created (this allows
+for easy detection when automatic cherry-picking failed).
 
-More advanced features such as a commit queue can come later. This
+
-would linearly apply accepted pull requests and verify that the
+Pull request commit queue
+''''''''''''''''''''''''''
+
+This would linearly apply accepted pull requests and verify that the
 commits did not interfere with each other by running the test suite
 and backing out commits if the test run failed. To help facilitate
 the speed of testing, all patches committed since the last test run
-can be applied and run in a single test run as the optimistic
+can be applied at once under a single test run as the optimistic
 assumption is that the patches will work in tandem. Some mechanism to
 re-run the tests in case of test flakiness will be needed, whether it
 is from removing a "test failed" label, web interface for core
@@ -658,6 +677,7 @@ Required:
 * Not started
 
   - `Update the linking service for mapping commit IDs to URLs`_
+    (need to find out where the code lives)
   - `Update PEP 101`_ (commitment from Ned Deily to do this)
   - Email python-checkins for each commit (PR or direct)
     (https://help.github.com/articles/managing-notifications-for-pushes-to-a-repository/;
@@ -665,6 +685,8 @@ Required:
   - Message #python-dev for each commit (PR or direct)
     (https://github.com/python/cpython/settings/hooks/new?service=irc;
     commitment from R. David Murray)
+  - Migrate buildbots to be triggered and pull from GitHub
+    (looking into requirements)
 
 * In progress
 
@@ -693,8 +715,9 @@ Optional features:
   - `Backup of pull request data`_
   - `Handling Misc/NEWS`_
   - `Handling Misc/ACKS`_
-  - `Bot to handle pull request merging`_
+  - `Pull request commit queue`_
   - `Test coverage report`_
+  - `Bot to generate cherry-pick pull requests`_
   - `Allow bugs.python.org to use GitHub as a login provider`_
   - `Web hooks for re-generating web content`_
   - `Link web content back to files that it is generated from`_