<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
Now that we're in the "release candidate" phase of Python 3.5.0, the
workflow<br>
has changed a little. We're trying an experiment using Bitbucket
and pull<br>
requests. You can read about that workflow, here:<br>
<br>
<a class="moz-txt-link-freetext" href="https://mail.python.org/pipermail/python-dev/2015-August/141167.html">https://mail.python.org/pipermail/python-dev/2015-August/141167.html</a><br>
<br>
But the instructions for that workflow are pretty hazy on what you
do after<br>
your pull request is accepted. This message is an addendum to those<br>
instructions, describing exactly what you should do after your pull<br>
request is accepted.<br>
<br>
To save wear and tear on my hands (and your eyes), for the rest of
these<br>
instructions, I'm going to refer to each
place-you-can-check-things-in-to<br>
by version number as follows:<br>
<br>
3.4 : hg.python.org/cpython (branch "3.4")<br>
3.5.0 : <a class="moz-txt-link-freetext" href="https://bitbucket.org/larry/cpython350">https://bitbucket.org/larry/cpython350</a> (branch
"3.5")<br>
3.5.1 : hg.python.org/cpython (branch "3.5")<br>
3.6 : hg.python.org/cpython (branch "default")<br>
<br>
With that nomenclature established I can now precisely say: when
your pull<br>
request is accepted into 3.5.0, you need to merge from 3.5.0 into
3.5.1,<br>
and then from 3.5.1 into 3.6.<br>
<br>
Doing this is much like the existing workflow. You use "hg merge"
to merge<br>
your changes from previous versions into subsequent versions (what I
call<br>
"forward merging").<br>
<br>
What complicates matters is the fact that the 3.5.0 release
candidates don't<br>
live in the normal repo--they lives in a repo on Bitbucket which is
only<br>
writeable by me. In order to keep a tight lid on the changes
checked in to<br>
the 3.5.0 release candidates, I won't pull revisions from the normal
CPython<br>
repo. (If I did, I'd also pull in changes intended for 3.5.1,
and...<br>
it'd be a mess.)<br>
<br>
So here come the instructions. They look long, but that's just
because I go<br>
into a lot of detail to try and make them as foolproof as possible.
They<br>
aren't really much longer or more complicated than the steps you
already<br>
follow to perform forward-merges.<br>
<br>
Note that these are easy, guaranteed-clean instructions on how to
perform the<br>
merge. Are there shortcuts you could take that might speed things
up? Yes.<br>
But I encourage you to skip those shortcuts and stick to my
instructions.<br>
Working with multiple branches is complicated enough, and this
external repo<br>
makes things even more complicated. It's all too easy to make a
mistake.<br>
<br>
<br>
HOW TO FORWARD-MERGE FROM 3.5.0 TO 3.5.1<br>
----------------------------------------<br>
<br>
<br>
1: Wait until your pull request has been accepted.<br>
<br>
<br>
2: Make a *clean* local clone of the CPython tree, updated to the
"3.5"<br>
branch. In my instructions I'll call the clone
"cpython351-merge":<br>
<br>
% hg clone <a class="moz-txt-link-freetext" href="ssh://hg@hg.python.org/cpython">ssh://hg@hg.python.org/cpython</a> -u 3.5
cpython351-merge<br>
<br>
% cd cpython351-merge<br>
<br>
<br>
3: Confirm that you're in the correct branch. You should be in the<br>
"3.5" branch. Run this command:<br>
<br>
% hg id<br>
<br>
Let's assume that the current head in the "3.5" branch has
changeset<br>
ID "7890abcdef". If that were true, the output of "hg id" would
look<br>
like this:<br>
<br>
7890abcdef (3.5)<br>
<br>
It might also say "tip" on the end, like this:<br>
<br>
7890abcdef (3.5) tip<br>
<br>
If it doesn't say "3.5", switch to the 3.5 branch:<br>
<br>
% hg up -r 3.5<br>
<br>
and repeat this step.<br>
<br>
<br>
4: Pull from the 3.5.0 repo into your "cpython351-merge" directory.<br>
<br>
% hg pull <a class="moz-txt-link-freetext" href="ssh://hg@bitbucket.org/larry/cpython350">ssh://hg@bitbucket.org/larry/cpython350</a><br>
<br>
You should now have two "heads" in the 3.5 branch; the existing
head<br>
you saw in the previous step, and the new head you just pulled
in,<br>
which should be the changeset from your pull request.<br>
<br>
<br>
5: As an optional step: confirm you have the correct two heads.<br>
This command will print a list of all the heads in the current
repo:<br>
<br>
% hg heads<br>
<br>
Again, you should have exactly two identified as being on the
"3.5"<br>
branch; one should have the changeset ID shown by "hg id" in
step 3,<br>
the other should be your change from the pull request.<br>
<br>
<br>
6: Merge the two heads together:<br>
<br>
% hg merge<br>
<br>
If there are merge conflicts, Mercurial will guide you through
the<br>
conflict resolution process as normal.<br>
<br>
<br>
7: Make sure that all your changes merged properly and you didn't<br>
merge anything else by accident. I run these two commands:<br>
<br>
% hg stat<br>
<br>
% hg diff<br>
<br>
and read all the output.<br>
<br>
<br>
8: Make sure Misc/NEWS has your update in the right spot. (See
below.)<br>
<br>
<br>
9: Check in. The checkin comment should be something like<br>
<br>
Merge from 3.5.0 to 3.5.1.<br>
<br>
<br>
10: Push your changes back into the main CPython repo.<br>
<br>
% hg push<br>
<br>
<br>
11: Now forward-merge your change to 3.6 as normal, following the<br>
CPython Dev Guide instructions:<br>
<br>
<a class="moz-txt-link-freetext" href="https://docs.python.org/devguide/committing.html#merging-between-different-branches-within-the-same-major-version">https://docs.python.org/devguide/committing.html#merging-between-different-branches-within-the-same-major-version</a><br>
<br>
<br>
FREQUENTLY ASKED QUESTIONS<br>
--------------------------<br>
<br>
<br>
Q: I screwed something up! What do I do now?<br>
<br>
If you haven't pushed your changes out, it's no problem. Just
delete your<br>
repo and start over.<br>
<br>
If you *have* pushed your changes out, obviously we'll need to fix
the<br>
mistake. If you're not sure how to fix the problem, I suggest
logging<br>
in to the #python-dev IRC channel and asking for help.<br>
<br>
<br>
Q: What do I need to do about Misc/NEWS?<br>
<br>
I'm glad you asked!<br>
<br>
First, you *must* put your Misc/NEWS update into the correct
section. If<br>
you're creating a pull request for Python 3.5.0 rc-something, put it
in the<br>
3.5.0 rc-something section. If you're checking in to 3.5.1, put it
in the<br>
3.5.1 section. If you're just checking into 3.6, put it in the
3.6.0 alpha 1<br>
section.<br>
<br>
Second, when you merge forward, make sure the merge tool puts your
Misc/NEWS<br>
entry in the right section. The merge tool I seem to use isn't
particularly<br>
smart about this, so I've had to manually edit Misc/NEWS many times
to fix<br>
it. (When I released 3.5.0rc2, I had to do a lot of cleanup on
Misc/NEWS,<br>
and again in the 3.5.1 branch, and again in 3.6.) Every time you
merge<br>
forward, make sure your Misc/NEWS entry is in the right spot.<br>
<br>
<br>
Q: What if a second pull request is accepted before I get around to
doing<br>
the merge?<br>
<br>
Well, *someone* needs to merge, and they're going to have to merge
*both*<br>
changes. I can't come up with a good general policy here.
Hopefully this<br>
won't happen often; for now let's just handle it on a case-by-case
basis.<br>
<br>
<br>
Q: What if I have a bugfix for 3.4 that I want to ship with 3.5.0?<br>
<br>
You have to check in twice, and merge-forward twice. First, check
in to 3.4,<br>
then merge forward into 3.5.1 and 3.6. Then, once your pull request
is<br>
accepted into 3.5.0, do a "null merge" (a merge where no files are
changed)<br>
from 3.5.0 into 3.5.1 and 3.6.<br>
<br>
<br>
Q: What if my pull request is turned down?<br>
<br>
If your bug fix isn't critical enough to merit shipping with 3.5.0,
just check<br>
it into the normal 3.5 branch on hg.python.org and it'll ship with
3.5.1.<br>
(And, naturally, forward-merge it into 3.6.)<br>
<br>
<br>
<i>/arry</i>
</body>
</html>