On Mon, Jan 17, 2011 at 22:14, Ezio Melotti wrote:

Hi,

On Thu, Jan 13, 2011 at 12:44 AM, brett.cannon wrote:

...

brett.cannon pushed 75300a08c6d7 to devguide:

http://hg.python.org/devguide/rev/75300a08c6d7 changeset:   88:75300a08c6d7 tag:         tip user:        Brett Cannon date:        Wed Jan 12 15:44:04 2011 -0800 summary:  Write a guide to committing a patch.

files:  committing.rst  faq.rst  index.rst

diff --git a/committing.rst b/committing.rst new file mode 100644 --- /dev/null +++ b/committing.rst @@ -0,0 +1,47 @@ +.. _committing: + +Committing Patches +================== + +As a core developer you will occasionally want to commit a patch created by +someone else. When doing so you will want to make sure of some things. + +First, make sure the patch in a good state. Both :ref:`patch` and :ref:`triage` +explain what is to be expected of a patch. Typically patches that get passed by +triagers are good to go except maybe lacking ``Misc/ACKS`` and ``Misc/NEWS`` +entries. + +Second, make sure the patch does not break backwards-compatibility without a +good reason. This means :ref:`running the test suite <runtests>` to make sure +everything still passes. It also means that if semantics do change there must +be a good reason for the the breakage of code the change will cause (and it +**will** break someone's code). If you are unsure if the breakage is worth it, +ask on python-dev. + +Third, backport as necessary. If the patch is a bugfix and it does not break +backwards-compatibility *at all*, then backport it to the branch(es) in +maintenance mode. The easiest way to do this is to apply the patch in the +development branch, commit, and then use svnmerge.py_ to backport the patch. + +For example, let us assume you just made commit 42 in the development branch +and you want to backport it to the ``release31-maint`` branch. You would change +your working directory to the maintenance branch and run the command:: + +    svnmerge.py merge -r 42 + +This will try to apply the patch to the current patch and generate a commit

s/current patch/current branch/

Fixed in a previous commit.

...

+message. You will need to revert ``Misc/NEWS`` and do a new entry (the file +changes too much between releases to ever have a merge succeed). Once your +checkout is ready to be committed, do::

Here you could mention that there are two ways to deal with files that have conflicts (marked with 'C' by svn): 1) revert them with 'svn revert filename' and then change them manually; 2) edit the file directly to resolve the conflict and then use 'svn resolved filename'; until there are no more files marked with 'C' in 'svn stat'. It's also a good idea to cat svnmerge-commit-message.txt and double check that the message is correct.

Done.

...

+ +    svn ci -F svnmerge-commit-message.txt + +This will commit the bacport along with using the commit message created by

s/bacport/backport/

Fixed in a previous commit.

...

+``svnmerge.py`` for you. + +If it turns out you do not have the time to do a backport, then at least leave +the proper issue open on the tracker with a note specifying that the change +should be backported so someone else can do it.

Maybe a short paragraph about "svnmerge block" can be included here.

No because I have not seen people bother with svnmerge block in a while. -Brett

...

+ + +.. _svnmerge.py: http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svnmerg... diff --git a/faq.rst b/faq.rst --- a/faq.rst +++ b/faq.rst @@ -44,65 +44,6 @@  =========== ============================================================== ==========================================================================

-How do I prepare a new branch for merging? ------------------------------------------- - -You need to initialize a new branch by having ``svnmerge.py`` discover the -revision number that the branch was created with.  Do this with the command:: - -    svnmerge.py init - -Then check in the change to the root of the branch.  This is a one-time -operation (i.e. only when the branch is originally created, not when each -developer creates a local checkout for the branch). - - -How do I merge between branches? --------------------------------- - -In the current situation for Python there are four branches under development, -meaning that there are three branches to merge into. Assuming a change is -committed into ``trunk`` as revision 0001, you merge into the 2.x maintenance -by doing:: - -    # In the 2.x maintenance branch checkout. -    svnmerge.py merge -r 0001 -    svn commit -F svnmerge-commit-message.txt  # r0002 - -To pull into py3k:: - -    # In a py3k checkout. -    svnmerge.py merge -r 0001 -    svn commit -F svnmerge-commit-message.txt  # r0003 - -The 3.x maintenance branch is a special case as you must pull from the py3k -branch revision, *not* trunk:: - -    # In a 3.x maintenance checkout. -    svnmerge.py merge -r 0003  # Notice the rev is the one from py3k! -    svn resolved . -    svn commit -F svnmerge-commit-message.txt - - -How do I block a specific revision from being merged into a branch? -------------------------------------------------------------------- - -With the revision number that you want to block handy and ``svnmerge.py``, go -to your checkout of the branch where you want to block the revision and run:: - -    svnmerge.py block -r - -This will modify the repository's top directory (which should be your current -directory) and create ``svnmerge-commit-message.txt`` which contains a -generated log message. - -If the command says "no available revisions to block", then it means someone -already merged the revision. - -To check in the new metadata, run:: - -    svn ci -F svnmerge-commit-message.txt -

 SSH  ======= @@ -158,21 +99,6 @@

 .. _Pageant: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

-Can I make check-ins from machines other than the one I generated the keys on?

------------------------------------------------------------------------------- - -Yes, all you need is to make sure that the machine you want to check -in code from has both the public and private keys in the standard -place that ssh will look for them (i.e. ~/.ssh on Unix machines). -Please note that although the key file ending in .pub contains your -user name and machine name in it, that information is not used by the -verification process, therefore these key files can be moved to a -different computer and used for verification.  Please guard your keys -and never share your private key with anyone.  If you lose the media -on which your keys are stored or the machine on which your keys are -stored, be sure to report this to pydotorg@python.org at the same time -that you change your keys. -

 Editors and Tools diff --git a/index.rst b/index.rst --- a/index.rst +++ b/index.rst @@ -16,6 +16,7 @@    languishing    communication    coredev +   committing

 .. todolist:: @@ -48,7 +49,7 @@     * :ref:`languishing`  * :ref:`communication`  * :ref:`coredev` -    * `Committing patches <XXX>`_ +    * :ref:`committing`

 Proposing changes to Python itself

-- Repository URL: http://hg.python.org/devguide _______________________________________________ Python-checkins mailing list Python-checkins@python.org http://mail.python.org/mailman/listinfo/python-checkins

Best Regards, Ezio Melotti

_______________________________________________ Python-checkins mailing list Python-checkins@python.org http://mail.python.org/mailman/listinfo/python-checkins