Clarifications from the PyCon US 2016 language summit
This commit is contained in:
Brett Cannon
parent
6f2c9ab021
commit
7559bcde40
159
pep-0512.txt
159
pep-0512.txt
|
|
@ -162,8 +162,8 @@ Define commands to move a Mercurial repository to Git
|
|||
|
||||
Since moving to GitHub also entails moving to Git [#git]_, we must
|
||||
decide what tools and commands we will run to translate a Mercurial
|
||||
repository to Git. The exact tools and steps to use are an
|
||||
open issue; see `Tools and commands to move from Mercurial to Git`_.
|
||||
repository to Git. The tools developed specifically for this migration
|
||||
are hosted at https://github.com/orsenthil/cpython-hg-to-git .
|
||||
|
||||
|
||||
CLA enforcement
|
||||
|
|
@ -287,42 +287,6 @@ core developers is an open issue:
|
|||
`Git CLI commands for committing a pull request to cpython`_.
|
||||
|
||||
|
||||
Handling Misc/NEWS
|
||||
''''''''''''''''''
|
||||
|
||||
Traditionally the ``Misc/NEWS`` file [#news-file]_ has been problematic
|
||||
for changes which spanned Python releases. Often times there will be
|
||||
merge conflicts when committing a change between e.g., 3.5 and 3.6
|
||||
only in the ``Misc/NEWS`` file. It's so common, in fact, that the
|
||||
example instructions in the devguide explicitly mention how to
|
||||
resolve conflicts in the ``Misc/NEWS`` file
|
||||
[#devguide-merge-across-branches]_. As part of our tool
|
||||
modernization, working with the ``Misc/NEWS`` file will be
|
||||
simplified.
|
||||
|
||||
There are currently two competing approaches to solving the
|
||||
``Misc/NEWS`` problem which are discussed in an open issue:
|
||||
`How to handle the Misc/NEWS file`_.
|
||||
|
||||
|
||||
Handling Misc/ACKS
|
||||
''''''''''''''''''
|
||||
|
||||
Traditionally the ``Misc/ACKS`` file [#acks-file]_ has been managed
|
||||
by hand. But thanks to Git supporting an ``author`` value as well as
|
||||
a ``committer`` value per commit, authorship of a commit can be part
|
||||
of the history of the code itself.
|
||||
|
||||
As such, manual management of ``Misc/ACKS`` will become optional. A
|
||||
script will be written that will collect all author and committer
|
||||
names and merge them into ``Misc/ACKS`` with all of the names listed
|
||||
prior to the move to Git. Running this script will become part of the
|
||||
release process.
|
||||
|
||||
The script should also generate a list of all people who contributed
|
||||
since the last execution. This will allow having a list of those who
|
||||
contributed to a specific release so they can be explicitly thanked.
|
||||
|
||||
Linking pull requests to issues
|
||||
'''''''''''''''''''''''''''''''
|
||||
Historically, external contributions were attached to an issue on
|
||||
|
|
@ -355,11 +319,11 @@ could lead to incorrect associations if the wrong issue or
|
|||
referencing another issue was done, but these are rare occasions.
|
||||
|
||||
|
||||
Notify the issue if the pull request is committed
|
||||
+++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
Notify the issue if a commit is made
|
||||
++++++++++++++++++++++++++++++++++++
|
||||
|
||||
Once a pull request is closed (merged or not), the issue should be
|
||||
updated to reflect this fact.
|
||||
Once a commit is made, the corresponding issue should be updated to
|
||||
reflect this fact.
|
||||
|
||||
|
||||
Update linking service for mapping commit IDs to URLs
|
||||
|
|
@ -373,31 +337,6 @@ be updated to redirect to the Git repository and to support the new
|
|||
revision IDs created for the Git repository.
|
||||
|
||||
|
||||
Create https://git.python.org
|
||||
'''''''''''''''''''''''''''''
|
||||
|
||||
Just as hg.python.org [#h.p.o]_ currently points to the Mercurial
|
||||
repository for Python, git.python.org should do the equivalent for
|
||||
the Git repository.
|
||||
|
||||
|
||||
Backup of pull request data
|
||||
'''''''''''''''''''''''''''
|
||||
|
||||
Since GitHub [#github]_ is going to be used for code hosting and code
|
||||
review, those two things need to be backed up. In the case of code
|
||||
hosting, the backup is implicit as all non-shallow Git [#git]_ clones
|
||||
contain the full history of the repository, hence there will be many
|
||||
backups of the repository.
|
||||
|
||||
The code review history does not have the same implicit backup
|
||||
mechanism as the repository itself. That means a daily backup of code
|
||||
review history should be done so that it is not lost in case of any
|
||||
issues with GitHub. It also helps guarantee that a migration from
|
||||
GitHub to some other code review system is feasible were GitHub to
|
||||
disappear overnight.
|
||||
|
||||
|
||||
Deprecate sys._mercurial
|
||||
''''''''''''''''''''''''
|
||||
|
||||
|
|
@ -436,6 +375,68 @@ bugs.python.org [#b.p.o]_ -- which includes plans independent of this
|
|||
migration -- are tracked on their own wiki page [#tracker-plans]_.
|
||||
|
||||
|
||||
Handling Misc/NEWS
|
||||
''''''''''''''''''
|
||||
|
||||
Traditionally the ``Misc/NEWS`` file [#news-file]_ has been problematic
|
||||
for changes which spanned Python releases. Often times there will be
|
||||
merge conflicts when committing a change between e.g., 3.5 and 3.6
|
||||
only in the ``Misc/NEWS`` file. It's so common, in fact, that the
|
||||
example instructions in the devguide explicitly mention how to
|
||||
resolve conflicts in the ``Misc/NEWS`` file
|
||||
[#devguide-merge-across-branches]_. As part of our tool
|
||||
modernization, working with the ``Misc/NEWS`` file will be
|
||||
simplified.
|
||||
|
||||
There are currently two competing approaches to solving the
|
||||
``Misc/NEWS`` problem which are discussed in an open issue:
|
||||
`How to handle the Misc/NEWS file`_.
|
||||
|
||||
|
||||
Handling Misc/ACKS
|
||||
''''''''''''''''''
|
||||
|
||||
Traditionally the ``Misc/ACKS`` file [#acks-file]_ has been managed
|
||||
by hand. But thanks to Git supporting an ``author`` value as well as
|
||||
a ``committer`` value per commit, authorship of a commit can be part
|
||||
of the history of the code itself.
|
||||
|
||||
As such, manual management of ``Misc/ACKS`` will become optional. A
|
||||
script will be written that will collect all author and committer
|
||||
names and merge them into ``Misc/ACKS`` with all of the names listed
|
||||
prior to the move to Git. Running this script will become part of the
|
||||
release process.
|
||||
|
||||
The script should also generate a list of all people who contributed
|
||||
since the last execution. This will allow having a list of those who
|
||||
contributed to a specific release so they can be explicitly thanked.
|
||||
|
||||
|
||||
Create https://git.python.org
|
||||
'''''''''''''''''''''''''''''
|
||||
|
||||
Just as hg.python.org [#h.p.o]_ currently points to the Mercurial
|
||||
repository for Python, git.python.org should do the equivalent for
|
||||
the Git repository.
|
||||
|
||||
|
||||
Backup of pull request data
|
||||
'''''''''''''''''''''''''''
|
||||
|
||||
Since GitHub [#github]_ is going to be used for code hosting and code
|
||||
review, those two things need to be backed up. In the case of code
|
||||
hosting, the backup is implicit as all non-shallow Git [#git]_ clones
|
||||
contain the full history of the repository, hence there will be many
|
||||
backups of the repository.
|
||||
|
||||
The code review history does not have the same implicit backup
|
||||
mechanism as the repository itself. That means a daily backup of code
|
||||
review history should be done so that it is not lost in case of any
|
||||
issues with GitHub. It also helps guarantee that a migration from
|
||||
GitHub to some other code review system is feasible were GitHub to
|
||||
disappear overnight.
|
||||
|
||||
|
||||
Bot to handle pull request merging
|
||||
''''''''''''''''''''''''''''''''''
|
||||
|
||||
|
|
@ -613,12 +614,11 @@ Repositories whose build steps need updating:
|
|||
|
||||
* Not started
|
||||
|
||||
- peps [#peps-repo]_
|
||||
- devguide [#devguide-repo]_
|
||||
|
||||
* In progress
|
||||
|
||||
- None
|
||||
- peps [#peps-repo]_
|
||||
|
||||
* Completed
|
||||
|
||||
|
|
@ -629,13 +629,9 @@ Requirements to move over the cpython repo [#cpython-repo]_:
|
|||
* Not started
|
||||
|
||||
- `Document steps to commit a pull request`_
|
||||
- `Handling Misc/NEWS`_
|
||||
- `Handling Misc/ACKS`_
|
||||
- `Linking a pull request to an issue`_
|
||||
- `Notify the issue if the pull request is committed`_
|
||||
- `Notify the issue if a commit is made`_
|
||||
- `Update linking service for mapping commit IDs to URLs`_
|
||||
- `Create https://git.python.org`_
|
||||
- `Backup of pull request data`_
|
||||
- `Deprecate sys._mercurial`_
|
||||
- `Update the devguide`_
|
||||
- `Update PEP 101`_
|
||||
|
|
@ -652,6 +648,10 @@ Optional features:
|
|||
|
||||
* Not started
|
||||
|
||||
- `Create https://git.python.org`_
|
||||
- `Backup of pull request data`_
|
||||
- `Handling Misc/NEWS`_
|
||||
- `Handling Misc/ACKS`_
|
||||
- `Bot to handle pull request merging`_
|
||||
- `Continuous integration per pull request`_
|
||||
- `Test coverage report`_
|
||||
|
|
@ -699,17 +699,6 @@ either be forced to migration or they can choose to simply stay on
|
|||
hg.python.org.
|
||||
|
||||
|
||||
Tools and commands to move from Mercurial to Git
|
||||
------------------------------------------------
|
||||
|
||||
A decision needs to be made on exactly what tooling and what commands
|
||||
involving those tools will be used to convert a Mercurial repository
|
||||
to Git. Currently a suggestion has been made to use
|
||||
https://github.com/frej/fast-export. Another suggestion is to use
|
||||
https://github.com/felipec/git-remote-hg. Finally,
|
||||
http://hg-git.github.io/ has been suggested.
|
||||
|
||||
|
||||
Git CLI commands for committing a pull request to cpython
|
||||
---------------------------------------------------------
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue