I believe I've reconciled the Python 2.6 hg and svn branches. I've committed the changes to 2.6svn and working on the null merges for the 2.6hg branch. I'll push the latter at some point soonish. Anyway, this means that I will cut 2.6.7rc2 today -- and actually announce it!
In the future, if you are going to apply patches to Python 2.6, please do so in both the hg and svn branches, since all 2.6 releases will be done from svn. If you're unsure or don't feel comfortable about doing that, please send me the diff and I'll apply it to 2.6svn. Or create/mark a bug as release blocker on 2.6 and attach the patch.
Thanks. I probably don't need to say, no commits to the 2.6svn branch for now please.
-Barry
On Fri, May 20, 2011 at 2:37 PM, Barry Warsaw <barry@python.org> wrote:
I believe I've reconciled the Python 2.6 hg and svn branches. I've committed the changes to 2.6svn and working on the null merges for the 2.6hg branch. I'll push the latter at some point soonish. Anyway, this means that I will cut 2.6.7rc2 today -- and actually announce it!
I hope you did copy the SimpleHTTPServer.py security fix that I just commented on in the tracker.
In the future, if you are going to apply patches to Python 2.6, please do so in both the hg and svn branches, since all 2.6 releases will be done from svn. If you're unsure or don't feel comfortable about doing that, please send me the diff and I'll apply it to 2.6svn. Or create/mark a bug as release blocker on 2.6 and attach the patch.
I'm not very happy with this requirement to do parallel checkins in hg and svn. IMO everyone except for the release managers should be able to live in the happy illusion that we've migrated to hg completely.
Of course I'm fine with having very restrictive policies about checkins to hg branches for old versions where the releases are done from svn. The more restricted the better. But requiring individual developers to maintain parallel svn and hg trees is going too far.
Thanks. I probably don't need to say, no commits to the 2.6svn branch for now please.
Happy releasing!
-- --Guido van Rossum (python.org/~guido)
On May 20, 2011, at 03:12 PM, Guido van Rossum wrote:
On Fri, May 20, 2011 at 2:37 PM, Barry Warsaw <barry@python.org> wrote:
I believe I've reconciled the Python 2.6 hg and svn branches. I've committed the changes to 2.6svn and working on the null merges for the 2.6hg branch. I'll push the latter at some point soonish. Anyway, this means that I will cut 2.6.7rc2 today -- and actually announce it!
I hope you did copy the SimpleHTTPServer.py security fix that I just commented on in the tracker.
I did. Right now I'm blocked on a test failure for test_urllib2, but it's failing in both the hg and svn branches, so at least it wasn't a result of a bogus merge by me. ;)
(I also have a problem with the line-ending changes to various .bat files that where only committed to hg26 but not svn26. I need to resolve those before I can push the reconciliation changes in Mercurial.)
In the future, if you are going to apply patches to Python 2.6, please do so in both the hg and svn branches, since all 2.6 releases will be done from svn. If you're unsure or don't feel comfortable about doing that, please send me the diff and I'll apply it to 2.6svn. Or create/mark a bug as release blocker on 2.6 and attach the patch.
I'm not very happy with this requirement to do parallel checkins in hg and svn. IMO everyone except for the release managers should be able to live in the happy illusion that we've migrated to hg completely.
Of course I'm fine with having very restrictive policies about checkins to hg branches for old versions where the releases are done from svn. The more restricted the better. But requiring individual developers to maintain parallel svn and hg trees is going too far.
I'm actually okay with that too, as long as the issue that precipitated the commit isn't closed until it's been merged to 2.6svn. Maybe that's the right way to handle this then -- when you commit a fix to 2.6hg, be sure there's an open release blocker issue on 2.6 with either a changeset or diff so that I can do the cross-port.
And yes, we should still be very conservative about what lands in 2.5 and 2.6.
Thanks. I probably don't need to say, no commits to the 2.6svn branch for now please.
Happy releasing!
Thanks! -Barry
I'm actually okay with that too, as long as the issue that precipitated the commit isn't closed until it's been merged to 2.6svn. Maybe that's the right way to handle this then -- when you commit a fix to 2.6hg, be sure there's an open release blocker issue on 2.6 with either a changeset or diff so that I can do the cross-port.
I still think this is asking too much. You can replay all changes to hg by looking at the hg log, and applying them change-for-change.
For verification, it might be sufficient to just look at the NEWS entries. Every change to that branch must have a NEWS entry (which is not a new requirement), so after synching, NEWS should be identical in svn and hg.
Regards, Martin
Am 20.05.2011 23:37, schrieb Barry Warsaw:
I believe I've reconciled the Python 2.6 hg and svn branches. I've committed the changes to 2.6svn and working on the null merges for the 2.6hg branch. I'll push the latter at some point soonish. Anyway, this means that I will cut 2.6.7rc2 today -- and actually announce it!
In the future, if you are going to apply patches to Python 2.6, please do so in both the hg and svn branches, since all 2.6 releases will be done from svn.
At the moment, this wouldn't be possible, since the svn is blocked from accepting commit unless they come from you or me.
It would be better, IMO, if there was a single developer who would migrate changes to svn, or to have some semi-automatic procedure for that.
Regards, Martin
On May 21, 2011, at 12:19 AM, Martin v. Löwis wrote:
Am 20.05.2011 23:37, schrieb Barry Warsaw:
I believe I've reconciled the Python 2.6 hg and svn branches. I've committed the changes to 2.6svn and working on the null merges for the 2.6hg branch. I'll push the latter at some point soonish. Anyway, this means that I will cut 2.6.7rc2 today -- and actually announce it!
In the future, if you are going to apply patches to Python 2.6, please do so in both the hg and svn branches, since all 2.6 releases will be done from svn.
At the moment, this wouldn't be possible, since the svn is blocked from accepting commit unless they come from you or me.
It would be better, IMO, if there was a single developer who would migrate changes to svn, or to have some semi-automatic procedure for that.
Yep. It's rather a pain to determine what those changes are though if the best you can do is a recursive diff on the two trees.
What do you think about my response to Guido, specifically: if you commit a change to 2.6hg, be sure there's a release blocker issue open on 2.6 so that I can easily find what needs to be cross-ported.
-Barry
On Fri, May 20, 2011 at 3:34 PM, Barry Warsaw <barry@python.org> wrote:
On May 21, 2011, at 12:19 AM, Martin v. Löwis wrote:
Am 20.05.2011 23:37, schrieb Barry Warsaw:
I believe I've reconciled the Python 2.6 hg and svn branches. I've committed the changes to 2.6svn and working on the null merges for the 2.6hg branch. I'll push the latter at some point soonish. Anyway, this means that I will cut 2.6.7rc2 today -- and actually announce it!
In the future, if you are going to apply patches to Python 2.6, please do so in both the hg and svn branches, since all 2.6 releases will be done from svn.
At the moment, this wouldn't be possible, since the svn is blocked from accepting commit unless they come from you or me.
It would be better, IMO, if there was a single developer who would migrate changes to svn, or to have some semi-automatic procedure for that.
Yep. It's rather a pain to determine what those changes are though if the best you can do is a recursive diff on the two trees.
What do you think about my response to Guido, specifically: if you commit a change to 2.6hg, be sure there's a release blocker issue open on 2.6 so that I can easily find what needs to be cross-ported.
That still requires developers to remember.
Isn't there some invocation of hg log --branch that would give you a list of changes on the branch?
-- --Guido van Rossum (python.org/~guido)
It would be better, IMO, if there was a single developer who would migrate changes to svn, or to have some semi-automatic procedure for that.
Yep. It's rather a pain to determine what those changes are though if the best you can do is a recursive diff on the two trees.
You can do better than that. If the hg and svn changes are in the same order, and have the same commit messages (as they should), you can look at the log of the hg branch to find out what the youngest change is that has been copied; all changes that are more recent then still have to be applied.
Regards, Martin
participants (3)
-
"Martin v. Löwis" -
Barry Warsaw -
Guido van Rossum