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
|
Since moving to GitHub also entails moving to Git [#git]_, we must
|
||||||
decide what tools and commands we will run to translate a Mercurial
|
decide what tools and commands we will run to translate a Mercurial
|
||||||
repository to Git. The exact tools and steps to use are an
|
repository to Git. The tools developed specifically for this migration
|
||||||
open issue; see `Tools and commands to move from Mercurial to Git`_.
|
are hosted at https://github.com/orsenthil/cpython-hg-to-git .
|
||||||
|
|
||||||
|
|
||||||
CLA enforcement
|
CLA enforcement
|
||||||
|
|
@ -287,42 +287,6 @@ core developers is an open issue:
|
||||||
`Git CLI commands for committing a pull request to cpython`_.
|
`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
|
Linking pull requests to issues
|
||||||
'''''''''''''''''''''''''''''''
|
'''''''''''''''''''''''''''''''
|
||||||
Historically, external contributions were attached to an issue on
|
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.
|
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
|
Once a commit is made, the corresponding issue should be updated to
|
||||||
updated to reflect this fact.
|
reflect this fact.
|
||||||
|
|
||||||
|
|
||||||
Update linking service for mapping commit IDs to URLs
|
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.
|
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
|
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]_.
|
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
|
Bot to handle pull request merging
|
||||||
''''''''''''''''''''''''''''''''''
|
''''''''''''''''''''''''''''''''''
|
||||||
|
|
||||||
|
|
@ -613,12 +614,11 @@ Repositories whose build steps need updating:
|
||||||
|
|
||||||
* Not started
|
* Not started
|
||||||
|
|
||||||
- peps [#peps-repo]_
|
|
||||||
- devguide [#devguide-repo]_
|
- devguide [#devguide-repo]_
|
||||||
|
|
||||||
* In progress
|
* In progress
|
||||||
|
|
||||||
- None
|
- peps [#peps-repo]_
|
||||||
|
|
||||||
* Completed
|
* Completed
|
||||||
|
|
||||||
|
|
@ -629,13 +629,9 @@ Requirements to move over the cpython repo [#cpython-repo]_:
|
||||||
* Not started
|
* Not started
|
||||||
|
|
||||||
- `Document steps to commit a pull request`_
|
- `Document steps to commit a pull request`_
|
||||||
- `Handling Misc/NEWS`_
|
|
||||||
- `Handling Misc/ACKS`_
|
|
||||||
- `Linking a pull request to an issue`_
|
- `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`_
|
- `Update linking service for mapping commit IDs to URLs`_
|
||||||
- `Create https://git.python.org`_
|
|
||||||
- `Backup of pull request data`_
|
|
||||||
- `Deprecate sys._mercurial`_
|
- `Deprecate sys._mercurial`_
|
||||||
- `Update the devguide`_
|
- `Update the devguide`_
|
||||||
- `Update PEP 101`_
|
- `Update PEP 101`_
|
||||||
|
|
@ -652,6 +648,10 @@ Optional features:
|
||||||
|
|
||||||
* Not started
|
* Not started
|
||||||
|
|
||||||
|
- `Create https://git.python.org`_
|
||||||
|
- `Backup of pull request data`_
|
||||||
|
- `Handling Misc/NEWS`_
|
||||||
|
- `Handling Misc/ACKS`_
|
||||||
- `Bot to handle pull request merging`_
|
- `Bot to handle pull request merging`_
|
||||||
- `Continuous integration per pull request`_
|
- `Continuous integration per pull request`_
|
||||||
- `Test coverage report`_
|
- `Test coverage report`_
|
||||||
|
|
@ -699,17 +699,6 @@ either be forced to migration or they can choose to simply stay on
|
||||||
hg.python.org.
|
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
|
Git CLI commands for committing a pull request to cpython
|
||||||
---------------------------------------------------------
|
---------------------------------------------------------
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue