Skip to content

Update wording on committing.rst. #262

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Sep 6, 2017
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 16 additions & 13 deletions committing.rst
Original file line number Diff line number Diff line change
@@ -1,18 +1,17 @@
.. _committing:
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the filename and the label be updated too?


Committing and Pushing Changes
==============================
Accepting Pull Requests
=======================

Is the change ready for committing?
-----------------------------------
This page is aimed to core developers, and covers the steps required to
accept, merge, and possibly backport a pull request on the main repository.

Before a change is committed, you must make sure it is ready to enter the
public source tree. Draft commits are prohibited. Therefore, you must
ensure your changes fulfill several mandatory criteria.
Is the PR ready to be accepted?
-------------------------------

When working a pull request on GitHub, use the following as a checklist of
what to check for before merging (details of various steps can be found
later in this document):
Before a PR is accepted, you must make sure it is ready to enter the public
source tree. Use the following as a checklist of what to check for before
merging (details of various steps can be found later in this document):

#. Has the submitter signed the CLA?
(delineated by a label on the pull request)
Expand Down Expand Up @@ -40,14 +39,14 @@ Does the test suite still pass?
'''''''''''''''''''''''''''''''

You must :ref:`run the whole test suite <runtests>` to ensure that it
passes before pushing any code changes.
passes before merging any code changes.

.. note::
You really need to run the **entire** test suite. Running a single test
is not enough as your changes may have unforeseen effects on other tests
is not enough as the changes may have unforeseen effects on other tests
or library modules.

Running the entire test suite doesn't guarantee that your changes
Running the entire test suite doesn't guarantee that the changes
will pass the :ref:`continuous integration <buildbots>` tests, as those
will exercise more possibilities still (such as different platforms or
build options). But it will at least catch non-build specific,
Expand Down Expand Up @@ -93,6 +92,8 @@ making a complete patch.
Commit Style
------------

.. move this to pullrequest
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Committing is now done by contributors, so this section doesn't belong here anymore.
Something could be said about the commit message used while squashing.


Once a change patch is ready and tested, it can be committed to the repository.
We usually prefer to put a whole feature or bugfix into a single commit, but no
more. In particular:
Expand Down Expand Up @@ -240,6 +241,8 @@ unprocessed.)
Commit Messages
---------------

.. move to pullrequest

Every commit has a commit message to document why a change was made and to
communicate that reason to other core developers. Python core developers have
developed a standard way of formatting commit messages that everyone is
Expand Down