Re: [Python-Dev] PEP 385: pruning/reorganizing branches
empty: keep-clone? I use that as a branch to tell build slaves to clean out their current checkouts. So keep-clone sounds right, assuming it is possible to target buildslaves at either clones or branches (which, IIUC, would be necessary anyway, since we are using a mix of branches and clones). amk-mailbox: keep-clone? twouters-dictviews-backport: keep-clone? bcannon-sandboxing: keep-clone? bippolito-newstruct: merges? You'll probably need to explicitly ping the specific owners (Andrew Kuchling, Thomas Wouters, Brett Cannon, Bob Ippolito) to understand the fate of these branches. This also raises the question how developers should publish their own branches. For the bzr setup, there was apparently a proposal to use directories for that, i.e. giving each developer a directory on code.python.org to publish branches. Not doing that, but keeping owner information encoded in the clone name, would be fine as well. release23-branch: merges? r23b2-branch: merges? r22rc1-branch: strip r22b1-branch: merges? r22a4-branch: merges? r22a3-branch: merges? r161-branch: merges? It seems we had been creating CVS branches for every release around that time; I don't remember the details. Each such branch should end up in a tag. For example, release23-branch should (and does) ultimately lead to tags/r23. cvs2svn wasn't able to recognize this correctly (as CVS branches apply to each file individually), so it created the r23 tag out of various copies that were current when the tag was made. I don't know what your plan is wrt. release tags, i.e. whether you want to keep them all. If you are stripping out some of the branches, but plan to keep the release tags, I wonder what the tags look like. release22-branch: merged-r24921 Not really. Jack Jansen merged some changes that got first applied to the 2.2 r22b2-branch: merges? merged-r24426 r22b2-branch: merges? merged-r24426 release20-maint: keep-named See above. So you do plan to keep all past releases? release152p1-patches: merges? Probably merged. I don't recall whether 1.5.2p1 really happened; in r14966, Fred claims that he merged all changes from 1.5.2p2 (!). Hopefully I got all this right! I surely hope the same - I doubt anybody would go back and check whether anything is missing. 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 385: pruning/reorganizing branches
On Tue, Aug 4, 2009 at 08:06, Martin v. Löwismar...@v.loewis.de wrote: I use that as a branch to tell build slaves to clean out their current checkouts. So keep-clone sounds right, assuming it is possible to target buildslaves at either clones or branches (which, IIUC, would be necessary anyway, since we are using a mix of branches and clones). Yes, that should be straightforward. amk-mailbox: keep-clone? twouters-dictviews-backport: keep-clone? bcannon-sandboxing: keep-clone? bippolito-newstruct: merges? You'll probably need to explicitly ping the specific owners (Andrew Kuchling, Thomas Wouters, Brett Cannon, Bob Ippolito) to understand the fate of these branches. Will do. This also raises the question how developers should publish their own branches. For the bzr setup, there was apparently a proposal to use directories for that, i.e. giving each developer a directory on code.python.org to publish branches. User repositories has apparently worked well for Mozilla, so yeah, it's worth discussing. Not doing that, but keeping owner information encoded in the clone name, would be fine as well. release23-branch: merges? r23b2-branch: merges? r22rc1-branch: strip r22b1-branch: merges? r22a4-branch: merges? r22a3-branch: merges? r161-branch: merges? It seems we had been creating CVS branches for every release around that time; I don't remember the details. Each such branch should end up in a tag. For example, release23-branch should (and does) ultimately lead to tags/r23. cvs2svn wasn't able to recognize this correctly (as CVS branches apply to each file individually), so it created the r23 tag out of various copies that were current when the tag was made. I don't know what your plan is wrt. release tags, i.e. whether you want to keep them all. If you are stripping out some of the branches, but plan to keep the release tags, I wonder what the tags look like. The plan was to keep all maintenance branches and all release tags but not all release branches (since they seem to contain few commits anyway). release22-branch: merged-r24921 Not really. Jack Jansen merged some changes that got first applied to the 2.2 r22b2-branch: merges? merged-r24426 r22b2-branch: merges? merged-r24426 release20-maint: keep-named See above. So you do plan to keep all past releases? release152p1-patches: merges? Probably merged. I don't recall whether 1.5.2p1 really happened; in r14966, Fred claims that he merged all changes from 1.5.2p2 (!). Hopefully I got all this right! I surely hope the same - I doubt anybody would go back and check whether anything is missing. Thanks for the thorough review, Dirkjan ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 385: pruning/reorganizing branches
Comments on some of the branches I've had involvement with... On Mon, Aug 3, 2009 at 11:51 AM, Dirkjan Ochtmandirk...@ochtman.nl wrote: py3k-short-float-repr: strip streamed-merge Sounds fine. py3k-issue1717: keep-clone I don't think there's any need to keep this branch; its contents were all merged (in pieces) to py3k (various revisions with numbers in the range 69188--69225). So I think 'strip streamed-merge' is appropriate here, if I'm understanding your terminology. trunk-math: I think this one can go down as 'strip', too; there's nothing there of interest that isn't already in trunk and py3k. It was merged to trunk in r62380. -- Mark ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 385: the eol-type issue
Dirkjan Ochtman wrote: * commit hooks be implemented to enforce this - but this should not be necessary if the above was implemented and socially enforced. You seem to advocate a two-step approach: enforce line endings through win32text, catch any errors that slipped through in a hook (commit hook is an optional first line of defense, changegroup hooks on the server to protect the rest of the world). I think inverting that approach would be better: have strict hooks on the server to prevent people from pushing inappropriate EOLs, and provide help on configuring win32text as an extra help for developers on Windows who use editors that work better with \r\n. That leaves people to pick their own weapon of choice against propagation of \r\n (e.g. better editor, commit hooks, whatever) while still making sure no inappropriate line endings land in the python.org repositories. It also seems to fit well with the whole consenting adults thing (but that might just be me). It's about not treating Windows developers as second class citizens. Their platform uses \r\n as its native line ending format, so they should be able to work in that format without any hassles by following some simple instructions (such as ensure you have version X of the Windows hg client, enable the win32text extension and configure it in such-and-such a way). Not oh, yeah, that's an issue but if you search the Intarwebs there are a few different things you can do that kinda sorta work but are a bit fragile and klunky. The precise order the two issues (server side enforcement and client side assistance) are dealt with doesn't really matter because *both* issues need to be addressed before we migrate. win32text needs to be usable on non-Windows clients so that tarballs generated on a *nix machine get the line endings right in the Windows-only files. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Functionality in subprocess.Popen.terminate()
Eric Pruitt wrote: In my GSoC project, I have implemented asnychronous I/O in subprocess.Popen. Since the read/write operations are asynchronous, the program may have already exited by the time one calls the asyncread function I have implemented. While it returns the data just fine, I have come across an issue with the TerminateProcess function in Windows: if the program has already exited, when subprocess.Popen.Terminate calls the Windows built-in TerminateProcess function, an access denied error will occur. Should I just make it so that this exception is simply ignored or perform some kind of check to see if the process exists beforehand? If the latter, I have been unable to find a way to do so, to my liking at least. The solutions I saw would require code that seems a bit excessive to me. I'm pretty sure we already ignore some spurious error messages in cases like calling flush() in file.close(). I would suggest checking what the io module does in such cases and see what kind of precedent it sets. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 385: pruning/reorganizing branches
Dirkjan Ochtman wrote: On Tue, Aug 4, 2009 at 08:06, Martin v. Löwismar...@v.loewis.de wrote: I don't know what your plan is wrt. release tags, i.e. whether you want to keep them all. If you are stripping out some of the branches, but plan to keep the release tags, I wonder what the tags look like. The plan was to keep all maintenance branches and all release tags but not all release branches (since they seem to contain few commits anyway). I think I share Martin's confusion here - how can you keep a release tag (e.g. 2.2.2) without also keeping the release branch where that tag was created? Yes, the maintenance branches contain a comparatively small number of commits, but they're still the sources of the maintenance release tags. Or is this a case where Mercurial's DAG allows you to handle those old branches as abandoned leaves of the DAG in the history of the affected files, with the tags picking out the relevant versions of the files? Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 385: pruning/reorganizing branches
On Mon, Aug 03, 2009 at 12:51:36PM +0200, Dirkjan Ochtman wrote: amk-mailbox: keep-clone? strip -- this branch was for working on a fix for http://bugs.python.org/issue1599254, but the actual work in the branch is available as the patches attached to that item. --amk ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 385: pruning/reorganizing branches
Dirkjan Ochtman wrote: okkoto-sizeof strip - It's an 2008 Google Summer of Code project. The important changes have been applied in r63856. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Functionality in subprocess.Popen.terminate()
On Tue, Aug 4, 2009 at 04:27, Nick Coghlanncogh...@gmail.com wrote: Eric Pruitt wrote: In my GSoC project, I have implemented asnychronous I/O in subprocess.Popen. Since the read/write operations are asynchronous, the program may have already exited by the time one calls the asyncread function I have implemented. While it returns the data just fine, I have come across an issue with the TerminateProcess function in Windows: if the program has already exited, when subprocess.Popen.Terminate calls the Windows built-in TerminateProcess function, an access denied error will occur. Should I just make it so that this exception is simply ignored or perform some kind of check to see if the process exists beforehand? If the latter, I have been unable to find a way to do so, to my liking at least. The solutions I saw would require code that seems a bit excessive to me. I'm pretty sure we already ignore some spurious error messages in cases like calling flush() in file.close(). I would suggest checking what the io module does in such cases and see what kind of precedent it sets. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- Sounds good enough to me but I was wondering if it might be a good idea to add a function like pidinuse to subprocess as a whole that would determine if a process ID was being used and return a simple boolean value. I came across a number of people searching for a way to determine if a PID was running (Google python check if pid exists) so it seems like the implemented functionality would be of use to the community as a whole, not just my wrapper class. Eric ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Functionality in subprocess.Popen.terminate()
Eric Pruitt wrote: On Tue, Aug 4, 2009 at 04:27, Nick Coghlanncogh...@gmail.com wrote: Eric Pruitt wrote: In my GSoC project, I have implemented asnychronous I/O in subprocess.Popen. Since the read/write operations are asynchronous, the program may have already exited by the time one calls the asyncread function I have implemented. While it returns the data just fine, I have come across an issue with the TerminateProcess function in Windows: if the program has already exited, when subprocess.Popen.Terminate calls the Windows built-in TerminateProcess function, an access denied error will occur. Should I just make it so that this exception is simply ignored or perform some kind of check to see if the process exists beforehand? If the latter, I have been unable to find a way to do so, to my liking at least. The solutions I saw would require code that seems a bit excessive to me. I'm pretty sure we already ignore some spurious error messages in cases like calling flush() in file.close(). I would suggest checking what the io module does in such cases and see what kind of precedent it sets. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- Sounds good enough to me but I was wondering if it might be a good idea to add a function like pidinuse to subprocess as a whole that would determine if a process ID was being used and return a simple boolean value. I came across a number of people searching for a way to determine if a PID was running (Google python check if pid exists) so it seems like the implemented functionality would be of use to the community as a whole, not just my wrapper class. Eric I'm not sure of the actual details but it seems from your description that even if you check first a race condition will still exist. Specifically the subprocess could terminate after the check and before the TerminateProcess call. So it seems better just to call TerminateProcess and then correctly handle any possible error. Janzert ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 385: pruning/reorganizing branches
On Mon, Aug 3, 2009 at 23:06, Martin v. Löwis mar...@v.loewis.de wrote: empty: keep-clone? I use that as a branch to tell build slaves to clean out their current checkouts. So keep-clone sounds right, assuming it is possible to target buildslaves at either clones or branches (which, IIUC, would be necessary anyway, since we are using a mix of branches and clones). amk-mailbox: keep-clone? twouters-dictviews-backport: keep-clone? bcannon-sandboxing: keep-clone? bippolito-newstruct: merges? keep-clone bcannon-objcap, strip bcannon-sandboxing. You'll probably need to explicitly ping the specific owners (Andrew Kuchling, Thomas Wouters, Brett Cannon, Bob Ippolito) to understand the fate of these branches. This also raises the question how developers should publish their own branches. For the bzr setup, there was apparently a proposal to use directories for that, i.e. giving each developer a directory on code.python.org to publish branches. Yeah, I thought I brought this up and people liked the idea of keeping some user directory on hg.python.org. I am fine with code.python.org as well. But having some place would be really handy (although having bitbucket and Google Code makes this not quite as important). Not doing that, but keeping owner information encoded in the clone name, would be fine as well. release23-branch: merges? r23b2-branch: merges? r22rc1-branch: strip r22b1-branch: merges? r22a4-branch: merges? r22a3-branch: merges? r161-branch: merges? It seems we had been creating CVS branches for every release around that time; I don't remember the details. Each such branch should end up in a tag. For example, release23-branch should (and does) ultimately lead to tags/r23. cvs2svn wasn't able to recognize this correctly (as CVS branches apply to each file individually), so it created the r23 tag out of various copies that were current when the tag was made. I don't know what your plan is wrt. release tags, i.e. whether you want to keep them all. If you are stripping out some of the branches, but plan to keep the release tags, I wonder what the tags look like. release22-branch: merged-r24921 Not really. Jack Jansen merged some changes that got first applied to the 2.2 r22b2-branch: merges? merged-r24426 r22b2-branch: merges? merged-r24426 release20-maint: keep-named See above. So you do plan to keep all past releases? release152p1-patches: merges? Probably merged. I don't recall whether 1.5.2p1 really happened; in r14966, Fred claims that he merged all changes from 1.5.2p2 (!). Hopefully I got all this right! I surely hope the same - I doubt anybody would go back and check whether anything is missing. 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/brett%40python.org ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 385: the eol-type issue
On 4/08/2009 7:20 PM, Nick Coghlan wrote: Dirkjan Ochtman wrote: * commit hooks be implemented to enforce this - but this should not be necessary if the above was implemented and socially enforced. You seem to advocate a two-step approach: enforce line endings through win32text, catch any errors that slipped through in a hook (commit hook is an optional first line of defense, changegroup hooks on the server to protect the rest of the world). I think inverting that approach would be better: have strict hooks on the server to prevent people from pushing inappropriate EOLs, and provide help on configuring win32text as an extra help for developers on Windows who use editors that work better with \r\n. That leaves people to pick their own weapon of choice against propagation of \r\n (e.g. better editor, commit hooks, whatever) while still making sure no inappropriate line endings land in the python.org repositories. It also seems to fit well with the whole consenting adults thing (but that might just be me). It's about not treating Windows developers as second class citizens. Their platform uses \r\n as its native line ending format, so they Thanks Nick; I didn't want to be the only one saying that. There is a fine line between asserting reasonable requirements for Windows users and being obstructionist and unhelpful, and I'm trying to stay on the former side :) should be able to work in that format without any hassles by following some simple instructions (such as ensure you have version X of the Windows hg client, enable the win32text extension and configure it in such-and-such a way). Not oh, yeah, that's an issue but if you search the Intarwebs there are a few different things you can do that kinda sorta work but are a bit fragile and klunky. The precise order the two issues (server side enforcement and client side assistance) are dealt with doesn't really matter because *both* issues need to be addressed before we migrate. I'm not that happy with the server being the primary line of defense. Let's say I make a branch of the hg repo, myself and a few others work on it committing as we go, then attempt to merge back upstream. Let's say some of the early commits on that clone introduced bad line endings. I'm guessing I would be forced to make a number of whitespace-only checkins to normalize the line-endings before it could merge - and these checkins would then be in the history forever. Or I could attempt to recreate the clone by somehow replaying the commits with line endings corrected. Either way, the situation doesn't seem good. win32text needs to be usable on non-Windows clients so that tarballs generated on a *nix machine get the line endings right in the Windows-only files. I agree. It isn't fair to make this windows users problem. It would be like me proposing the repo get imported with \r\n line endings, enforce that with server side hooks, and let non-Windows users worry about the ramifications of that - somehow I doubt that would fly - so neither should it fly for Windows users... I'm more than willing to help on this; I haven't resurrected my stale patch because I find win32text only 1/2 a solution that doesn't work in practice. Therefore that patch is as stale for me as it is anyone. However, if a plan is put in place which offers a full solution and the hg developers are committed to it, I promise I'll put my hand up to help with implementation in a fairly timely manner... Cheers, Mark ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 385: the eol-type issue
Mark Hammond: Thanks Nick; I didn't want to be the only one saying that. There is a fine line between asserting reasonable requirements for Windows users and being obstructionist and unhelpful, and I'm trying to stay on the former side :) I haven't commented on this issue before because I can't really be helpful. I just don't understand why hg is being considered before it's Windows support is roughly equivalent to svn and cvs. There has been some similar experience with the main repository for the Cocoa port of Scintilla which is in bzr on launchpad. Several times in that repository, files were checked in with wrong line ends making every line appear changed when looking through history. There are several causes for this including user error but bzr (and hg) should default to more helpful behaviour on text files. Neil ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 385: the eol-type issue
Mark Hammond mhamm...@skippinet.com.au writes: Let's say I make a branch of the hg repo, myself and a few others work on it committing as we go, then attempt to merge back upstream. Let's say some of the early commits on that clone introduced bad line endings. I'm guessing I would be forced to make a number of whitespace-only checkins to normalize the line-endings before it could merge - and these checkins would then be in the history forever. What is wrong with that? I mean, if that is the actual sequence of events, why should the history not reflect that? Either way, the situation doesn't seem good. I see this assertion made often, so I'm not saying you are necessarily wrong to make it. I just don't see a justification for making it (and, without justification, I would say it *is* wrong to make it). -- \ “Our products just aren't engineered for security.” —Brian | `\ Valentine, senior vice-president of Microsoft Windows | _o__) development | Ben Finney ___ 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/archive%40mail-archive.com
