For your information:
I won't have time to do another svn merge before the next alphas of 2.6 and 3.0 are to be released. Somebody else has to do the merge.
Christian
On Sun, Mar 30, 2008 at 3:51 PM, "Martin v. Löwis" martin@v.loewis.de wrote:
I won't have time to do another svn merge before the next alphas of 2.6 and 3.0 are to be released. Somebody else has to do the merge.
I merged a few revisions, but I'm done now (until Tuesday or so).
If you'd like, I can merge the rest.
Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.c...
On Sun, Mar 30, 2008 at 5:54 PM, "Martin v. Löwis" martin@v.loewis.de wrote:
If you have the time to figure it all out, sure. I found that quite a tedious task, and had to spent on some patches quite a long time to figure out what they do, and what the 3.x equivalent should be.
Is there any easy way that the burden of trunk -> py3k merging could be moved to the original committers of the trunk patches? Presumably the original committer of a patch is well-placed to understand what the patch does and how best to translate it to 3.0.
Mark
Is there any easy way that the burden of trunk -> py3k merging could be moved to the original committers of the trunk patches?
I'm not sure I understand the question. If the committer of the original patch would do the merge himself, then certainly the burden would be on him, and that's an easy way.
If you meant to say "an easy way to enforce...", then I cannot see how that could work, other than establishing that as a policy, and starting to revoke commit privileges to people who don't follow the policy.
Rather than actually merging changes, one could start sending out messages automatically to committers who don't either merge or block their changes within 24 hours (or send a summary message every day to python-dev).
Regards, Martin
On Sun, Mar 30, 2008 at 5:16 PM, "Martin v. Löwis" martin@v.loewis.de wrote:
Is there any easy way that the burden of trunk -> py3k merging could be moved to the original committers of the trunk patches?
I'm not sure I understand the question. If the committer of the original patch would do the merge himself, then certainly the burden would be on him, and that's an easy way.
If you meant to say "an easy way to enforce...", then I cannot see how that could work, other than establishing that as a policy, and starting to revoke commit privileges to people who don't follow the policy.
I think we could just ask politely and try it for a while. If things aren't working, we can reevaluate.
Rather than actually merging changes, one could start sending out messages automatically to committers who don't either merge or block their changes within 24 hours (or send a summary message every day to python-dev).
Like above, let's try a little before we start setting up new infrastructure left and right.
Regards, Martin
On Sun, Mar 30, 2008 at 6:16 PM, "Martin v. Löwis" martin@v.loewis.de wrote:
Is there any easy way that the burden of trunk -> py3k merging could be moved to the original committers of the trunk patches?
I'm not sure I understand the question. If the committer of the original patch would do the merge himself, then certainly the burden would be on him, and that's an easy way.
Yes, that's all I meant: make it the committer's job to merge or block as appropriate. I just wasn't sure if there was some reason that this would be difficult or undesirable.
I'm not suggesting that this be enforced (mechanically or otherwise); just that it might be worth considering instituting a policy to encourage individual committers to take responsibility for forward porting their commits.
Mark
Yes, that's all I meant: make it the committer's job to merge or block as appropriate. I just wasn't sure if there was some reason that this would be difficult or undesirable.
Ah, yes. It is indeed difficult or undesirable, or was so in the past: Some committers don't care (didn't care) at all about 3k. They would have to setup sandboxes, learn what the nature of changes is, and invest some regular time into forward-porting.
Regards, Martin
Yes, that's all I meant: make it the committer's job to merge or block as appropriate. I just wasn't sure if there was some reason that this would be difficult or undesirable.
Ah, yes. It is indeed difficult or undesirable, or was so in the past: Some committers don't care (didn't care) at all about 3k. They would have to setup sandboxes, learn what the nature of changes is, and invest some regular time into forward-porting.
Is this *really* the case still? Who are these rogue committers? ;-)
I think holding a developer accountable for merging or blocking to py3k when they commit to trunk is a great idea. Who better to pass judgement on such an activity than the person closest to it?
Trent.
Trent Nelson schrieb:
I think holding a developer accountable for merging or blocking to py3k when they commit to trunk is a great idea. Who better to pass judgement on such an activity than the person closest to it?
Blocking a revision makes my job as The Merger easier.
I'm not so sure about the merging part. It takes some experience with the Python 3.0 code base to know the subtle differences in the C API. Most merges are straight forward for me. If you enforce the forward merging on every developer it may slow down development. Each regular merge takes me about 45 minutes of computer time but less than 15 supervisor time. The computer time is mostly compile and test time in the background. If everybody merges her own code to 3.0 it still takes *everybody* about 10 minutes of time and 45 minutes of computer time.
Christian
Christian Heimes [mailto:lists@cheimes.de]:
Trent Nelson schrieb:
I think holding a developer accountable for merging or blocking to
py3k when they commit to trunk is a great idea. Who better to pass judgement on such an activity than the person closest to it?
Blocking a revision makes my job as The Merger easier.
I'm not so sure about the merging part. It takes some experience with the Python 3.0 code base to know the subtle differences in the C API. Most merges are straight forward for me. If you enforce the forward merging on every developer it may slow down development. Each regular merge takes me about 45 minutes of computer time but less than 15 supervisor time. The computer time is mostly compile and test time in the background. If everybody merges her own code to 3.0 it still takes *everybody* about 10 minutes of time and 45 minutes of computer time.
Ah, right, I wasn't thinking about the implication of code affecting the C base for some reason, but that's entirely reasonable. Perhaps each developer should be accountable for either:
a) blocking b) merging, if they're able to do so c) if they're unable to merge, replying to the relevant python-checkins@ e-mail indicating that they're unable to handle trunk -> py3k for whatever reason (e.g. not familiar with py3k code base)
Other developers could then pitch in and help merge if someone requests it via e-mail. I'd think that would make The Merger's life easier.
Trent.
On Wed, Apr 2, 2008 at 7:16 AM, Trent Nelson tnelson@onresolve.com wrote:
Christian Heimes [mailto:lists@cheimes.de]:
Trent Nelson schrieb:
I think holding a developer accountable for merging or blocking to
py3k when they commit to trunk is a great idea. Who better to pass judgement on such an activity than the person closest to it?
Blocking a revision makes my job as The Merger easier.
I'm not so sure about the merging part. It takes some experience with the Python 3.0 code base to know the subtle differences in the C API. Most merges are straight forward for me. If you enforce the forward merging on every developer it may slow down development. Each regular merge takes me about 45 minutes of computer time but less than 15 supervisor time. The computer time is mostly compile and test time in the background. If everybody merges her own code to 3.0 it still takes *everybody* about 10 minutes of time and 45 minutes of
computer
time.
Ah, right, I wasn't thinking about the implication of code affecting the C base for some reason, but that's entirely reasonable. Perhaps each developer should be accountable for either:
a) blocking b) merging, if they're able to do so c) if they're unable to merge, replying to the relevant python-checkins@ e-mail indicating that they're unable to handle trunk -> py3k for whatever reason (e.g. not familiar with py3k code base)
Other developers could then pitch in and help merge if someone requests it via e-mail. I'd think that would make The Merger's life easier.
I think we should let The Merger decide what makes his life easier. :)
Trent.
Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.c...
On Sun, Mar 30, 2008 at 4:54 PM, "Martin v. Löwis" martin@v.loewis.de wrote:
If you'd like, I can merge the rest.
If you have the time to figure it all out, sure. I found that quite a tedious task, and had to spent on some patches quite a long time to figure out what they do, and what the 3.x equivalent should be.
Ok. I merged some more of the low hanging fruit. Somebody who understands AST better than me should probably do the merges with that.
Regards, Martin
On Sun, Mar 30, 2008 at 7:41 PM, Benjamin Peterson musiccomposition@gmail.com wrote:
On Sun, Mar 30, 2008 at 4:54 PM, "Martin v. Löwis" martin@v.loewis.de wrote:
If you'd like, I can merge the rest.
If you have the time to figure it all out, sure. I found that quite a tedious task, and had to spent on some patches quite a long time to figure out what they do, and what the 3.x equivalent should be.
Ok. I merged some more of the low hanging fruit. Somebody who understands AST better than me should probably do the merges with that.
Are you done for today/tonight? If so, I can merge the rest.
The last checkin to regrtest I saw looked like it doesn't work. I thought it had print foo without parens. Did I miss something?
n
On Sun, Mar 30, 2008 at 9:43 PM, Neal Norwitz nnorwitz@gmail.com wrote:
On Sun, Mar 30, 2008 at 7:41 PM, Benjamin Peterson musiccomposition@gmail.com wrote:
On Sun, Mar 30, 2008 at 4:54 PM, "Martin v. Löwis" martin@v.loewis.de wrote:
If you'd like, I can merge the rest.
If you have the time to figure it all out, sure. I found that quite a tedious task, and had to spent on some patches quite a long time to figure out what they do, and what the 3.x equivalent should be.
Ok. I merged some more of the low hanging fruit. Somebody who
understands
AST better than me should probably do the merges with that.
Are you done for today/tonight? If so, I can merge the rest.
Be my guest! I'm going to bed.
The last checkin to regrtest I saw looked like it doesn't work. I thought it had print foo without parens. Did I miss something?
I just merged it incorrectly, so I reverted it.
n
2008/3/30, "Martin v. Löwis" martin@v.loewis.de:
If you'd like, I can merge the rest.
If you have the time to figure it all out, sure. I found that quite a tedious task, and had to spent on some patches quite a long time to figure out what they do, and what the 3.x equivalent should be.
Me for myself, I thought that the trunk -> 3k merge was easier!
Sometimes I commited changes to the trunk, don't worrying about 3k at all, thinking it was a mostly automatic process.
Now that I know this, I will start patching both trunk & 3k simultaneously...
Regards,
Facundo Batista schrieb:
Me for myself, I thought that the trunk -> 3k merge was easier!
Sometimes I commited changes to the trunk, don't worrying about 3k at all, thinking it was a mostly automatic process.
Now that I know this, I will start patching both trunk & 3k simultaneously...
In most cases it's easy. Usually it takes me less than 20 minutes per day to merge the chances from trunk -> py3k. In this particular case several obstacles come together. The changes in the AST and parser code aren't trivial, I'm not familiar with the internals of the AST and parser code and my free time is very limited.
Please don't patch trunk and py3k simultaneously. It may confuse svn and may make future merges harder. You should apply the patch to the trunk and either merge or block the revision with svnmerge.
Example:
# Commit a patch to the trunk ~$ cd python/trunk trunk$ svn ci -m "Message" ... Committed revision 1234.
# Merge the revision to the py3k branch trunk $ cd ../py3k py3k $ svnmerge.py merge -r 1234 ...
# resolve conflicts ...
# commit the merge py3k $ svn ci -F svnmerge-commit-message.txt
Christian
2008/3/31, Christian Heimes lists@cheimes.de:
In most cases it's easy. Usually it takes me less than 20 minutes per day to merge the chances from trunk -> py3k. In this particular case several obstacles come together. The changes in the AST and parser code aren't trivial, I'm not familiar with the internals of the AST and parser code and my free time is very limited.
Please don't patch trunk and py3k simultaneously. It may confuse svn and may make future merges harder. You should apply the patch to the trunk and either merge or block the revision with svnmerge.
Mmmm... so, I'll do this. I'll just commit on the trunk, but know people that I'm here if you need to ask anything about commited stuff or whatever ("here" means through IM, and normally hanging around in #python-dev or #pyar in freenode).
Regards,
participants (7)
-
"Martin v. Löwis" -
Benjamin Peterson -
Christian Heimes -
Facundo Batista -
Mark Dickinson -
Neal Norwitz -
Trent Nelson