[Python-Dev] Python 3.4: Cherry-picking into rc2 and final

[Stephen J. Turnbull]

Larry Hastings writes:

 > Someone could still inadvertently push those revisions back to
 > trunk, and then we'd have a real mess on our hands.  Publishing
 > tarballs drops the possibility down to about zero.

Note: I see no reason for you to change your process for the 3.4.0
release.  I just want to record my comments in this thread for
future reference.

I don't think any of the above is true.  First, although
"possibility of inadvertant push" as written is obviously correct,
I don't think the implication that the *probability* of an
*inadvertant* push is any higher is correct (somebody else --
Antoine? Guido? -- already pointed this out).  The reasoning is
that if somebody clones from a mirror of your release branch, they
will have to make a deliberate decision to push to trunk, or a
deliberate decision to merge or cherrypick from your branch into a
branch destined for trunk, to cause a problem.  That's actually
safer than if they apply a patch from the tracker by hand, since
in the case of a patch there will be no metadata to indicate that
the conflict was caused by concurrent cherrypicks, and if they're
sufficiently incautious, the actual change data may be different.
That is messy.

Second, what "real mess"?  "VCS means never having to say 'Oh,
shit!'"  If such a thing happens, you just take your branch, do an
"ours" merge with trunk obsoleting the trunk, and then cherrypick
everything appropriate from obs-trunk.  Tedious, yes.  Somewhat
error-prone, I suppose.  Keep the buildbots very busy for a while,
for sure.  Real mess?  IMHO, no.  The fact that the repair procedure
uses only "proper merges" (vs. rebase) means that rebase confusion
can't propagate silently, nor can committed changes (in anybody's
branch) be inadvertantly lost.  (There are better strategies than
the above, which I'll be happy to discuss if and when necessary.
And for tedium reduction, there are features like git's filter-branch,
which a Mercurial dev assures me can be done with hg too.)

Third, tarballs don't drop the possibility to zero.  We know that
patch reviewers have those patches in local workspaces.  In some
cases you can diff a file from the tarball and get the patch you
want (mostly, as mentioned above) and apply that to your feature
branch.  In the case of asyncio, some such path to a duplicate
cherrypick seems quite probable (compared with "near zero",
anyway).

 > I haven't seen anything that makes me think we're in trouble.

Your evaluation is plenty good enough for me.  But the actual
information that your assessment is based on is almost private to
you, and that's the reason other folks want access to a repo.  By
"almost private" I mean that the manipulation of revision
information that DVCSes make so convenient is unavailable to them.