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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
