Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
Am 20.02.2014 02:24, schrieb Stephen J. Turnbull: [ ... ] Sure, but it *doesn't* help in knowing which ones are *correctly* addressed. These *are* ambitious changes; some of the remaining bugs may be very deep. The obvious fixes may do more harm than good. Ie, more eyes is (a) mostly a fallacy (as Heinlein put it, the wisdom of a group is less than or equal to the maximum of the wisdom of the members) and (b) in any case the more eyes effect is diluted if people are deliberately looking at different parts of the code. All depends from the way, a group is organized, composed etc. What might stiffle results in a group for example is hierarchy, resp. a fear to get chastised by the leader. After all I'm not in position to make a guess here - but rather would expect much higher results by groups-coop than from most gifted single person among. ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
Antoine Pitrou writes: On Thu, 20 Feb 2014 10:24:16 +0900 Stephen J. Turnbull step...@xemacs.org wrote: The argument that a read-only, no cherrypicking by committers repo is nothing but a better tarball is valid, but as I say, AFAICS the expected gain is pretty marginal. The conflict here is not Larry's process, it's the decision to make an ambitious release on a short time schedule. I don't really buy the short time schedule argument. The delay between 3.3 and 3.4 is ~18 months as usual. Short here isn't relative to calendar time nor to the development cycle length. It's relative to the time needed to properly beta and RC an ambitious set of changes, with more than the usual number of patches during RC AFAIK, and the time allowed for that testing. I'm not saying it isn't enough time, but I certainly think that more time or a less ambitious release would make folks feel more comfortable, and less apt to suggest changes in a release process at this late date. My point is that I don't think that changing Larry's process would make a big difference to our ability to test the release candidates, Ubuntu deadlines not withstanding. ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On Thu, 20 Feb 2014 10:24:16 +0900 Stephen J. Turnbull step...@xemacs.org wrote: The argument that a read-only, no cherrypicking by committers repo is nothing but a better tarball is valid, but as I say, AFAICS the expected gain is pretty marginal. The conflict here is not Larry's process, it's the decision to make an ambitious release on a short time schedule. I don't really buy the short time schedule argument. The delay between 3.3 and 3.4 is ~18 months as usual. Regards Antoine. ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On Wed, 19 Feb 2014 19:20:12 -0800 Larry Hastings la...@hastings.org wrote: As for a user beware clone: I worry about providing anything that looks/tastes/smells like a repo. Someone could still inadvertently push those revisions back to trunk, and then we'd have a real mess on our hands. If you're using a separate named branch for your release work, then the hg.python.org hooks will forbid pushing them back to the main repo. Regards Antoine. ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
Am 19.02.2014 22:18, schrieb Nick Coghlan: and the Ubuntu 14.04 deadline restricts our ability to add a 3rd rc. well, I think it would be wrong to restrict that for only that reason. I did object to delay the release cycle a second time for completing a feature. If the release has to be delayed for QA reasons, that's a good reason. Having a Debian background myself ;) I'm fine to ship with a rc3 too, and update it post-release, after wading through distribution bureaucracy ... but please don't use this as an example of a distribution influencing an upstream. There are better examples for this :-/ Matthias ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On 21 Feb 2014 08:38, Matthias Klose d...@ubuntu.com wrote: Am 19.02.2014 22:18, schrieb Nick Coghlan: and the Ubuntu 14.04 deadline restricts our ability to add a 3rd rc. well, I think it would be wrong to restrict that for only that reason. I did object to delay the release cycle a second time for completing a feature. If the release has to be delayed for QA reasons, that's a good reason. Having a Debian background myself ;) I'm fine to ship with a rc3 too, and update it post-release, after wading through distribution bureaucracy ... but please don't use this as an example of a distribution influencing an upstream. There are better examples for this :-/ Thanks for the clarification. That said, supporting someone else's external deadline can definitely help with resisting the urge to allow just one more little adjustment :) Cheers, Nick. Matthias ___ 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/ncoghlan%40gmail.com ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
Am 19.02.2014 01:07, schrieb Larry Hastings: On 02/18/2014 03:54 PM, Victor Stinner wrote: 2014-02-19 0:46 GMT+01:00 Larry Hastings la...@hastings.org: Is there *any* reason to make this branch public before 3.4.0 final? I'm a little bit worried by the fact that buildbots will not test it. fact? http://docs.python.org/devguide/buildbots.html#custom-builders And this works without a public repo on hg.python.org how? Georg ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
Am 19.02.2014 03:46, schrieb Guido van Rossum: I do think there's one legitimate concern -- someone might pull a diff from Larry's branch and then accidentally push it back to the public repo, and then Larry would be in trouble if he was planning to rebase that diff. (The joys of DVCS -- we never had this problem in the cvs or svn days...) Pushes to hg.python.org repos are fully reversible. If that is Larry's concern he can even put it on bitbucket, where only he can push by default. Georg ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
Am 19.02.2014 00:54, schrieb Barry Warsaw: On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote: Am 17.02.2014 00:25, schrieb Larry Hastings: And my local branch will remain private until 3.4.0 final ships! sorry, but this is so wrong. Is there *any* reason why to keep this branch private? IMO, no. read-only for !larry sure, but not private. I emphatically agree. There is no need at all for secrecy, or paranoia. And it is very understandable that vendors (or even just our binary building experts) want to make as many tests with what will be RC2 and then final as they can, to catch possible issues before release. Georg ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On Tue, 18 Feb 2014 18:54:23 -0500 Barry Warsaw ba...@python.org wrote: On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote: Am 17.02.2014 00:25, schrieb Larry Hastings: And my local branch will remain private until 3.4.0 final ships! sorry, but this is so wrong. Is there *any* reason why to keep this branch private? IMO, no. read-only for !larry sure, but not private. Agreed too. Python isn't developed in private. Regards Antoine. ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On Tue, 18 Feb 2014 18:46:16 -0800 Guido van Rossum gu...@python.org wrote: I do think there's one legitimate concern -- someone might pull a diff from Larry's branch and then accidentally push it back to the public repo, and then Larry would be in trouble if he was planning to rebase that diff. (The joys of DVCS -- we never had this problem in the cvs or svn days...) I don't think I understand the concern. Why is this different from any other mistake someone may make when pushing code? Also rebase is only really ok on private repos, as soon as something is published you should use merge. Regards Antoine. ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On 02/19/2014 01:20 PM, Antoine Pitrou wrote: On Tue, 18 Feb 2014 18:46:16 -0800 Guido van Rossum gu...@python.org wrote: I do think there's one legitimate concern -- someone might pull a diff from Larry's branch and then accidentally push it back to the public repo, and then Larry would be in trouble if he was planning to rebase that diff. (The joys of DVCS -- we never had this problem in the cvs or svn days...) I don't think I understand the concern. Why is this different from any other mistake someone may make when pushing code? Also rebase is only really ok on private repos, as soon as something is published you should use merge. If the branch were private, pushing to it would not count as publishing, but would still provide the benefit of having a redundant server-side backup of the data. Being able to rebase without fuss is a possible legitimate reason to keep the branch private, which Guido provided in response to Matthias's question: sorry, but this is so wrong. Is there *any* reason why to keep this branch private? ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On Wed, Feb 19, 2014 at 1:42 AM, Georg Brandl g.bra...@gmx.net wrote: Am 19.02.2014 00:54, schrieb Barry Warsaw: On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote: Am 17.02.2014 00:25, schrieb Larry Hastings: And my local branch will remain private until 3.4.0 final ships! sorry, but this is so wrong. Is there *any* reason why to keep this branch private? IMO, no. read-only for !larry sure, but not private. I emphatically agree. There is no need at all for secrecy, or paranoia. And it is very understandable that vendors (or even just our binary building experts) want to make as many tests with what will be RC2 and then final as they can, to catch possible issues before release. That's why it's RC2 and not 3.4final, right? Once Larry says it's baked, everyone *will* have a chance to test it. What value is a preview of the preview really going to add? Give Larry some trust and freedom to do things in the way that makes him comfortable. -- --Guido van Rossum (python.org/~guido) ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On Feb 19, 2014, at 07:50 AM, Guido van Rossum wrote: That's why it's RC2 and not 3.4final, right? Once Larry says it's baked, everyone *will* have a chance to test it. What value is a preview of the preview really going to add? Give Larry some trust and freedom to do things in the way that makes him comfortable. I totally agree that Larry should be given fairly wide discretion. He's also feeling out his first big release and deserves some slack. However, I think Matthias wants read access to the release repo because he's *also* cherry picking patches into Ubuntu's archive. We're already seeing some problems, which we want to investigate, and Matthias has also performed archive-wide test rebuilds to find Python 3.4 incompatibilities in 3rd party libraries, most of which we'd like to fix (e.g. main packages, if its not possible to get to everything in universe). Matthias just switched the default for Ubuntu 14.04 to Python 3.4 by default, so this is a great test bed to find problems. Cheers, -Barry ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On Wed, Feb 19, 2014 at 4:13 AM, Antoine Pitrou solip...@pitrou.net wrote: Agreed too. Python isn't developed in private. That's a ridiculous accusation, bordering on malicious. Larry isn't developing Python in private. He is simply working on something that he'll release when he feels comfortable releasing it. I don't think I understand the concern. Why is this different from any other mistake someone may make when pushing code? Maybe because 1000s of people are apparently ready to micro-manage and criticize Larry's work and waiting for him to screw up? Why are you trying to tell Larry how to use his tools? Larry *volunteered* to be the release manager and got widespread support when he did. If you don't trust him, go fucking fork the release yourself. Also rebase is only really ok on private repos, as soon as something is published you should use merge. And that's exactly why Larry is holding off pushing. -- --Guido van Rossum (python.org/~guido) ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On Wed, Feb 19, 2014 at 8:16 AM, Barry Warsaw ba...@python.org wrote: On Feb 19, 2014, at 07:50 AM, Guido van Rossum wrote: That's why it's RC2 and not 3.4final, right? Once Larry says it's baked, everyone *will* have a chance to test it. What value is a preview of the preview really going to add? Give Larry some trust and freedom to do things in the way that makes him comfortable. I totally agree that Larry should be given fairly wide discretion. He's also feeling out his first big release and deserves some slack. Thanks for the support! However, I think Matthias wants read access to the release repo because he's *also* cherry picking patches into Ubuntu's archive. We're already seeing some problems, which we want to investigate, and Matthias has also performed archive-wide test rebuilds to find Python 3.4 incompatibilities in 3rd party libraries, most of which we'd like to fix (e.g. main packages, if its not possible to get to everything in universe). Again, this is what RC2 is for (and RC1, for that matter; apart from 20+ asyncio patches there really isn't much of a difference between RC1 and RC2). Larry may legitimately feel uncomfortable with what he's got on his local drive and prefer to tweak some things before telling people go ahead test with this -- the difference is that if he was working on new *code*, he could just not commit his work-in-progress, but since here he is assembling the final sequence of *revisions*, he prefers just not to push. (Georg alluded to the fact that you can undo changes in a public repo after they've been pushed, but I suspect he's referring to hg backout, which creates extra revisions, rather than a remote version of hg strip, which would go against the philosophy of DVCS. Either way, Larry's use of Hg is a totally legitimate workflow.) Matthias just switched the default for Ubuntu 14.04 to Python 3.4 by default, so this is a great test bed to find problems. And that's great, of course. But what is really gained by giving Larry trouble over a few days' worth of delay, at most? -- --Guido van Rossum (python.org/~guido) ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
Am 19.02.2014 16:50, schrieb Guido van Rossum: On Wed, Feb 19, 2014 at 1:42 AM, Georg Brandl g.bra...@gmx.net mailto:g.bra...@gmx.net wrote: Am 19.02.2014 00:54, schrieb Barry Warsaw: On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote: Am 17.02.2014 00:25, schrieb Larry Hastings: And my local branch will remain private until 3.4.0 final ships! sorry, but this is so wrong. Is there *any* reason why to keep this branch private? IMO, no. read-only for !larry sure, but not private. I emphatically agree. There is no need at all for secrecy, or paranoia. And it is very understandable that vendors (or even just our binary building experts) want to make as many tests with what will be RC2 and then final as they can, to catch possible issues before release. That's why it's RC2 and not 3.4final, right? Once Larry says it's baked, everyone *will* have a chance to test it. What value is a preview of the preview really going to add? Ned told me just a few days ago that he does regular pre-tag builds of the OSX installers, and as for the Debian/Ubuntu side Barry can say more. The thing with the RCs is that as long as you add patches during the RC phase (which is more or less unavoidable if the schedule is to be kept), the state of the release branch can only profit from more eyes. Give Larry some trust and freedom to do things in the way that makes him comfortable. I have no doubts that Larry will make 3.4 the best Python yet :) So far he has discussed most of his procedures with us, so I don't see a reason not to weigh in here. Georg ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
Am 19.02.2014 19:00, schrieb Georg Brandl: Give Larry some trust and freedom to do things in the way that makes him comfortable. I have no doubts that Larry will make 3.4 the best Python yet :) So far he has discussed most of his procedures with us, so I don't see a reason not to weigh in here. NB, us being the previous release managers. Georg ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
Am 19.02.2014 19:00, schrieb Georg Brandl: Am 19.02.2014 16:50, schrieb Guido van Rossum: On Wed, Feb 19, 2014 at 1:42 AM, Georg Brandl g.bra...@gmx.net mailto:g.bra...@gmx.net wrote: Am 19.02.2014 00:54, schrieb Barry Warsaw: On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote: Am 17.02.2014 00:25, schrieb Larry Hastings: And my local branch will remain private until 3.4.0 final ships! sorry, but this is so wrong. Is there *any* reason why to keep this branch private? IMO, no. read-only for !larry sure, but not private. I emphatically agree. There is no need at all for secrecy, or paranoia. And it is very understandable that vendors (or even just our binary building experts) want to make as many tests with what will be RC2 and then final as they can, to catch possible issues before release. That's why it's RC2 and not 3.4final, right? Once Larry says it's baked, everyone *will* have a chance to test it. What value is a preview of the preview really going to add? Ned told me just a few days ago that he does regular pre-tag builds of the OSX installers, and as for the Debian/Ubuntu side Barry can say more. The thing with the RCs is that as long as you add patches during the RC phase (which is more or less unavoidable if the schedule is to be kept), the state of the release branch can only profit from more eyes. There's even some helpful people on #python-dev (like Arfrever from Gentoo) who frequently do post-push reviews, catching embarrassing bugs before they can sneak their way into a release (thank you Arfrever!). OK, that's my reasoning, I'm going to fucking shut up now. Georg ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On 20 Feb 2014 04:18, Georg Brandl g.bra...@gmx.net wrote: Am 19.02.2014 19:00, schrieb Georg Brandl: Am 19.02.2014 16:50, schrieb Guido van Rossum: On Wed, Feb 19, 2014 at 1:42 AM, Georg Brandl g.bra...@gmx.net mailto:g.bra...@gmx.net wrote: Am 19.02.2014 00:54, schrieb Barry Warsaw: On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote: Am 17.02.2014 00:25, schrieb Larry Hastings: And my local branch will remain private until 3.4.0 final ships! sorry, but this is so wrong. Is there *any* reason why to keep this branch private? IMO, no. read-only for !larry sure, but not private. I emphatically agree. There is no need at all for secrecy, or paranoia. And it is very understandable that vendors (or even just our binary building experts) want to make as many tests with what will be RC2 and then final as they can, to catch possible issues before release. That's why it's RC2 and not 3.4final, right? Once Larry says it's baked, everyone *will* have a chance to test it. What value is a preview of the preview really going to add? Ned told me just a few days ago that he does regular pre-tag builds of the OSX installers, and as for the Debian/Ubuntu side Barry can say more. The thing with the RCs is that as long as you add patches during the RC phase (which is more or less unavoidable if the schedule is to be kept), the state of the release branch can only profit from more eyes. There's even some helpful people on #python-dev (like Arfrever from Gentoo) who frequently do post-push reviews, catching embarrassing bugs before they can sneak their way into a release (thank you Arfrever!). OK, that's my reasoning, I'm going to fucking shut up now. I suspect everyone is also highly aware of the fact that there are some ambitious changes in 3.4, the release of rc1 is bringing the usual wave of additional third party testing that has picked up some interesting regressions and usability issues (e.g. the Alembic test suite found a fun one in the inspect module, while the pip installation doesn't currently play nice with UAC on Windows), and the Ubuntu 14.04 deadline restricts our ability to add a 3rd rc. That brings with it a strong desire to parallelise things as much as possible, and read only access to the upcoming release helps greatly in knowing which regressions have already been addressed, allowing third party testers to more easily focus on any remaining issues. A user beware, this may be rebased without warning clone would be fine for that purpose, and I suspect in most cases just running rc2 - final with such a clone available (preserving Larry's current workflow until rc2) would be sufficient to address most concerns. Regards, Nick. Georg ___ 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/ncoghlan%40gmail.com ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
Nick Coghlan writes: I suspect everyone is also highly aware of the fact that there are some ambitious changes in 3.4, Which is an argument for longer beta and RC periods than usual, or maybe some of the ambition should have been restrained. It's not necessarily a reason why more eyes help (see below). the release of rc1 is bringing the usual wave of additional third party testing that has picked up some interesting regressions and usability issues (e.g. the Alembic test suite found a fun one in the inspect module, while the pip installation doesn't currently play nice with UAC on Windows), and the Ubuntu 14.04 deadline restricts our ability to add a 3rd rc. OK, but that means we're screwed regardless. We've decided to release what we've got on a specific timeline, and a few extra days of testing is going to make a marginal difference on average. Remember that under time pressure in bugfixing, the average programmer introduces a new bug that gets through to a product every ten lines. OK, so we're[1] 100X better than average, and I suppose for some subset 1000X better. Still that means several new bugs, and some of them may be doozies. That brings with it a strong desire to parallelise things as much as possible, and read only access to the upcoming release helps greatly in knowing which regressions have already been addressed, allowing third party testers to more easily focus on any remaining issues. Sure, but it *doesn't* help in knowing which ones are *correctly* addressed. These *are* ambitious changes; some of the remaining bugs may be very deep. The obvious fixes may do more harm than good. Ie, more eyes is (a) mostly a fallacy (as Heinlein put it, the wisdom of a group is less than or equal to the maximum of the wisdom of the members) and (b) in any case the more eyes effect is diluted if people are deliberately looking at different parts of the code. A user beware, this may be rebased without warning clone would be fine for that purpose, and I suspect in most cases just running rc2 - final with such a clone available (preserving Larry's current workflow until rc2) would be sufficient to address most concerns. Larry's already providing tarballs as I understand it. The argument that a read-only, no cherrypicking by committers repo is nothing but a better tarball is valid, but as I say, AFAICS the expected gain is pretty marginal. The conflict here is not Larry's process, it's the decision to make an ambitious release on a short time schedule. I sympathize with Ubuntu to some extent -- they have a business to run, after all. But should Ubuntu desires be distorting a volunteer RE's process? Was Larry told that commercial interests should be respected in designing his process? Footnotes: [1] FVO we not containing me. You'll notice I'm not submitting patches.wink/ ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On Feb 20, 2014, at 10:24 AM, Stephen J. Turnbull wrote: But should Ubuntu desires be distorting a volunteer RE's process? Ubuntu 14.04 final freeze is April 10[1], so I think that's the drop dead date for getting 3.4 final into Ubuntu 14.04. Matthias may correct me, but I think if we can hit that date (well, maybe a day or two early to be safe) we're good. Missing that date probably isn't catastrophic, especially if there are few to no changes between the last Python 3.4 rc before our final freeze, and Python 3.4 final. What it means is that 14.04 won't ship with the final Python 3.4 and we'll have to do a stable release update after 14.04 to catch up to the Python 3.4 final release. It does mean that many Ubuntu users won't see it until 14.04.1, whenever that is, if at all. But if the only difference is a version string and sys.version_info, then I don't think that's so bad. And ultimately we'll have to do that anyway to get the LTS users Python 3.4.1, 3.4.2, and so on. Two notes: Matthias just enabled Python 3.4 as the default Python 3, and there's no going back. Also, we have aligned the Python release schedules with external schedules before, most notably Apple a couple of times. I think it's reasonable to do so *if* we can do it without sacrificing the quality of Python 3.4's final release. Cheers, -Barry [1] https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On 02/19/2014 05:24 PM, Stephen J. Turnbull wrote: The conflict here is not Larry's process, it's the decision to make an ambitious release on a short time schedule. I sympathize with Ubuntu to some extent -- they have a business to run, after all. But should Ubuntu desires be distorting a volunteer RE's process? Was Larry told that commercial interests should be respected in designing his process? When talk of slipping the final date again was discussed, Guido basically said no. -- ~Ethan~ ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On 20 Feb 2014 12:26, Ethan Furman et...@stoneleaf.us wrote: On 02/19/2014 05:24 PM, Stephen J. Turnbull wrote: The conflict here is not Larry's process, it's the decision to make an ambitious release on a short time schedule. I sympathize with Ubuntu to some extent -- they have a business to run, after all. But should Ubuntu desires be distorting a volunteer RE's process? Was Larry told that commercial interests should be respected in designing his process? When talk of slipping the final date again was discussed, Guido basically said no. Guido said no more to the additional Argument Clinic related changes, rather than to an extra rc in general. Note that I made my comment before Larry pointed out the existing schedule was a week longer than I thought, and Barry clarified that there *is* still room for a third rc if Larry decides that would be appropriate. Cheers, Nick. -- ~Ethan~ ___ 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/ncoghlan%40gmail.com ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On 02/19/2014 05:24 PM, Stephen J. Turnbull wrote: Nick Coghlan writes: A user beware, this may be rebased without warning clone would be fine for that purpose, and I suspect in most cases just running rc2 - final with such a clone available (preserving Larry's current workflow until rc2) would be sufficient to address most concerns. Larry's already providing tarballs as I understand it. Yep. Well, just tarball so far ;-) As for a user beware clone: I worry about providing anything that looks/tastes/smells like a repo. 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. The conflict here is not Larry's process, it's the decision to make an ambitious release on a short time schedule. I sympathize with Ubuntu to some extent -- they have a business to run, after all. But should Ubuntu desires be distorting a volunteer RE's process? Was Larry told that commercial interests should be respected in designing his process? I haven't seen anything that makes me think we're in trouble. Every release has its bumps; that's what the rc period is for. I remind you we're still a month away. I grant you asyncio is still evolving surprisingly rapidly for an rc. But it doesn't have an installed base yet, and it's provisional anyway, so it's not making me anxious. Worst case, we issue a 3.4.1 on a very accelerated schedule. But it doesn't seem like it'll be necessary. //arry/ ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
Am 17.02.2014 00:25, schrieb Larry Hastings: And my local branch will remain private until 3.4.0 final ships! sorry, but this is so wrong. Is there *any* reason why to keep this branch private? Matthias ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On 02/18/2014 03:38 PM, Matthias Klose wrote: Am 17.02.2014 00:25, schrieb Larry Hastings: And my local branch will remain private until 3.4.0 final ships! sorry, but this is so wrong. Is there *any* reason why to keep this branch private? Yes. It ensures that nobody can check something into it against my wishes. Also, in the event that I cherry-pick revisions out-of-order, it allows me to rebase, making merging easier. Is there *any* reason to make this branch public before 3.4.0 final? //arry/ ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
2014-02-19 0:46 GMT+01:00 Larry Hastings la...@hastings.org: Is there *any* reason to make this branch public before 3.4.0 final? I'm a little bit worried by the fact that buildbots will not test it. Cherry-picking many patches is complex. It's safe if you have a very short list of changes. Would it be insane to use default as the next RC2? It looks like there are too many changes between RC1 and RC2. Another release candidate is maybe needed. Victor ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
Am 19.02.2014 00:46, schrieb Larry Hastings: On 02/18/2014 03:38 PM, Matthias Klose wrote: Am 17.02.2014 00:25, schrieb Larry Hastings: And my local branch will remain private until 3.4.0 final ships! sorry, but this is so wrong. Is there *any* reason why to keep this branch private? Yes. It ensures that nobody can check something into it against my wishes. Also, in the event that I cherry-pick revisions out-of-order, it allows me to rebase, making merging easier. Is there *any* reason to make this branch public before 3.4.0 final? - Python is an open source project. Why do we need to hide development for a month or more? - Not even four eyes looking at the code seems to be odd. You can make mistakes too. This seems to be a social or a technical problem. I assume making this branch available read-only would address your concerns? Does hg allow this? And if not, why not create this branch in the upstream repository, and tell people not to commit to it? Why shouldn't such a social restriction work? Seems to work well for other projects. Matthias ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
2014-02-17 0:25 GMT+01:00 Larry Hastings la...@hastings.org: You might think that anything you check in to the default branch in Python trunk will go into 3.4.0 rc2, and after that ships, checkins would go into 3.4.0 final. Ho ho ho! That's not true! Instead, anything checked in to default between my last revision for rc1 (e64ae8b82672) and 3.4.0 final will by default go into 3.4.1. Only fixes that I cherry-pick into my local branch will go into 3.4.0 rc2 and final. And my local branch will remain private until 3.4.0 final ships! I'm a little bit lost with the Misc/NEWS file. The current title is still What's New in Python 3.4.0 release candidate 2?. Should we start a new Python 3.4.1 section? Victor ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On 02/18/2014 03:54 PM, Victor Stinner wrote: 2014-02-19 0:46 GMT+01:00 Larry Hastings la...@hastings.org: Is there *any* reason to make this branch public before 3.4.0 final? I'm a little bit worried by the fact that buildbots will not test it. fact? http://docs.python.org/devguide/buildbots.html#custom-builders Would it be insane to use default as the next RC2? Yes. //arry/ ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
Am 19.02.2014 01:05, schrieb Larry Hastings: On 02/18/2014 03:56 PM, Matthias Klose wrote: Am 19.02.2014 00:46, schrieb Larry Hastings: On 02/18/2014 03:38 PM, Matthias Klose wrote: Am 17.02.2014 00:25, schrieb Larry Hastings: And my local branch will remain private until 3.4.0 final ships! sorry, but this is so wrong. Is there *any* reason why to keep this branch private? Yes. It ensures that nobody can check something into it against my wishes. Also, in the event that I cherry-pick revisions out-of-order, it allows me to rebase, making merging easier. Is there *any* reason to make this branch public before 3.4.0 final? - Python is an open source project. Why do we need to hide development for a month or more? - Not even four eyes looking at the code seems to be odd. You can make mistakes too. This seems to be a social or a technical problem. I assume making this branch available read-only would address your concerns? Does hg allow this? And if not, why not create this branch in the upstream repository, and tell people not to commit to it? Why shouldn't such a social restriction work? Seems to work well for other projects. When you are release manager for Python, you may institute this policy if you like. Right now, I have enough to do as it is. is it too much to ask for a public mirror / tarball / something of this branch? This seems to be a minor effort compared to the clinic work that went into 3.4. Matthias ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On 02/18/2014 04:19 PM, Matthias Klose wrote: Am 19.02.2014 01:05, schrieb Larry Hastings: On 02/18/2014 03:56 PM, Matthias Klose wrote: Am 19.02.2014 00:46, schrieb Larry Hastings: On 02/18/2014 03:38 PM, Matthias Klose wrote: Am 17.02.2014 00:25, schrieb Larry Hastings: And my local branch will remain private until 3.4.0 final ships! sorry, but this is so wrong. Is there *any* reason why to keep this branch private? Yes. It ensures that nobody can check something into it against my wishes. Also, in the event that I cherry-pick revisions out-of-order, it allows me to rebase, making merging easier. Is there *any* reason to make this branch public before 3.4.0 final? - Python is an open source project. Why do we need to hide development for a month or more? - Not even four eyes looking at the code seems to be odd. You can make mistakes too. This seems to be a social or a technical problem. I assume making this branch available read-only would address your concerns? Does hg allow this? And if not, why not create this branch in the upstream repository, and tell people not to commit to it? Why shouldn't such a social restriction work? Seems to work well for other projects. When you are release manager for Python, you may institute this policy if you like. Right now, I have enough to do as it is. is it too much to ask for a public mirror / tarball / something of this branch? This seems to be a minor effort compared to the clinic work that went into 3.4. Why do you need this? What is your use case? //arry/ ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote: Am 17.02.2014 00:25, schrieb Larry Hastings: And my local branch will remain private until 3.4.0 final ships! sorry, but this is so wrong. Is there *any* reason why to keep this branch private? IMO, no. read-only for !larry sure, but not private. -Barry ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
I do think there's one legitimate concern -- someone might pull a diff from Larry's branch and then accidentally push it back to the public repo, and then Larry would be in trouble if he was planning to rebase that diff. (The joys of DVCS -- we never had this problem in the cvs or svn days...) Publishing tarballs would prevent this and still let people test the exact code Larry is assembling on their favorite obscure platform. On Tue, Feb 18, 2014 at 3:54 PM, Barry Warsaw ba...@python.org wrote: On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote: Am 17.02.2014 00:25, schrieb Larry Hastings: And my local branch will remain private until 3.4.0 final ships! sorry, but this is so wrong. Is there *any* reason why to keep this branch private? IMO, no. read-only for !larry sure, but not private. -Barry ___ 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/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
Sounds like you aren't exactly a DVCS fan... On Tue, Feb 18, 2014 at 8:46 PM, Guido van Rossum gu...@python.org wrote: I do think there's one legitimate concern -- someone might pull a diff from Larry's branch and then accidentally push it back to the public repo, and then Larry would be in trouble if he was planning to rebase that diff. (The joys of DVCS -- we never had this problem in the cvs or svn days...) Publishing tarballs would prevent this and still let people test the exact code Larry is assembling on their favorite obscure platform. On Tue, Feb 18, 2014 at 3:54 PM, Barry Warsaw ba...@python.org wrote: On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote: Am 17.02.2014 00:25, schrieb Larry Hastings: And my local branch will remain private until 3.4.0 final ships! sorry, but this is so wrong. Is there *any* reason why to keep this branch private? IMO, no. read-only for !larry sure, but not private. -Barry ___ 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/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ 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/rymg19%40gmail.com -- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated. ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On Tue, Feb 18, 2014, at 03:54 PM, Barry Warsaw wrote: On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote: Am 17.02.2014 00:25, schrieb Larry Hastings: And my local branch will remain private until 3.4.0 final ships! sorry, but this is so wrong. Is there *any* reason why to keep this branch private? IMO, no. read-only for !larry sure, but not private. I've always published my releasing repo on hg.p.o as releasing/2.7.X. I wasn't aware people actually used it; it's mostly a nice backup for when I rm rf * things in anger... :) ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On 02/16/2014 03:45 PM, Paul Moore wrote: http://bugs.python.org/issue20621 is significant enough to be resulting in a 3.3.5 release - can you make sure the 3.4 fix goes in? I'm not sure how to find the revision number that contains the fix to follow the process you outline above, so I'm just mentioning it here on the issue to make sure it's not missed... If it has an issue number like that, then generally Roundup Robot will notify the issue when something is checked in. And those comments will have the revision id in them. Also, you can scan the output of hg log to find the revision numbers. The first line of each stanza looks like changeset: 89231:75a12cf63f20 Here, 75a12cf63f20 is the revision id. //arry/ ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
Thanks, I see. Greg already filed a tracking issue, so it's covered anyway. On 17 February 2014 15:33, Larry Hastings la...@hastings.org wrote: On 02/16/2014 03:45 PM, Paul Moore wrote: http://bugs.python.org/issue20621 is significant enough to be resulting in a 3.3.5 release - can you make sure the 3.4 fix goes in? I'm not sure how to find the revision number that contains the fix to follow the process you outline above, so I'm just mentioning it here on the issue to make sure it's not missed... If it has an issue number like that, then generally Roundup Robot will notify the issue when something is checked in. And those comments will have the revision id in them. Also, you can scan the output of hg log to find the revision numbers. The first line of each stanza looks like changeset: 89231:75a12cf63f20 Here, 75a12cf63f20 is the revision id. /arry ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On 02/17/2014 03:20 PM, Victor Stinner wrote: 2014-02-17 0:25 GMT+01:00 Larry Hastings la...@hastings.org: You might think that anything you check in to the default branch in Python trunk will go into 3.4.0 rc2, and after that ships, checkins would go into 3.4.0 final. Ho ho ho! That's not true! Instead, anything checked in to default between my last revision for rc1 (e64ae8b82672) and 3.4.0 final will by default go into 3.4.1. Only fixes that I cherry-pick into my local branch will go into 3.4.0 rc2 and final. And my local branch will remain private until 3.4.0 final ships! Does it mean that the default branch is open for changes which target 3.4.1? Basically, yes. //arry/ ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On 2/17/2014 6:20 PM, Victor Stinner wrote: 2014-02-17 0:25 GMT+01:00 Larry Hastings la...@hastings.org: You might think that anything you check in to the default branch in Python trunk will go into 3.4.0 rc2, and after that ships, checkins would go into 3.4.0 final. Ho ho ho! That's not true! Instead, anything checked in to default between my last revision for rc1 (e64ae8b82672) and 3.4.0 final will by default go into 3.4.1. Only fixes that I cherry-pick into my local branch will go into 3.4.0 rc2 and final. And my local branch will remain private until 3.4.0 final ships! Does it mean that the default branch is open for changes which target 3.4.1? Presumably. That is what I started doing today. However, the top section of 3.4 News says 3.4.0rc2 rather than 3.4.1. It should be relabeled and a 3.4.0rc2 sections with items actually added to 3.4.0c2 (and those items should not be in the 3.4.1 section. -- Terry Jan Reedy ___ 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
[Python-Dev] Python 3.4: Cherry-picking into rc2 and final
Right now we're in the release candidate phase of 3.4. 3.4.0 rc1 has been released, and the next release will be rc2. You might think that anything you check in to the default branch in Python trunk will go into 3.4.0 rc2, and after that ships, checkins would go into 3.4.0 final. Ho ho ho! That's not true! Instead, anything checked in to default between my last revision for rc1 (e64ae8b82672) and 3.4.0 final will by default go into 3.4.1. Only fixes that I cherry-pick into my local branch will go into 3.4.0 rc2 and final. And my local branch will remain private until 3.4.0 final ships! If you have a Terribly Important Fix That Must Go Into 3.4.0 rc2 or final, please go to the issue tracker and create a new issue with the following attributes: The title should start with 3.4 cherry-pick: followed by the revision id and a short summary example: 3.4 cherry-pick: b328f8ccbccf __getnewargs__ fix The version should be Python 3.4 The assignee should be larry The priority should be release blocker The comment should *also* contain the revision id (the tracker will turn it into a link) I'm also working on automatically publishing the merged/unmerged revision status to a web page. You can see a mock-up here: http://www.midwinter.com/~larry/3.4.merge.status.html The page is marked beta because it doesn't have real data yet--I'm still experimenting with my automation, so I haven't created the real 3.4 local branch yet. Again, just to be crystal-clear: the revisions marked merged on that page are just experiments, they aren't actually merged for 3.4. Once I'm ready for real merging, I'll remove the beta warning. (By the way: on that page, clicking on a revision takes you to the revision web page. Clicking on the first line of the comment expands it to show the complete comment.) Please use your best judgment before asking that a revision be cherry-picked into 3.4.0. Our goal in the release candidate phase is to stabilize Python, and to do that we must stop changing it. Only important interface changes, new features, or bugfixes should be checked in now, and preferably they should be low-risk. Cheers, //arry/ ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
http://bugs.python.org/issue20621 is significant enough to be resulting in a 3.3.5 release - can you make sure the 3.4 fix goes in? I'm not sure how to find the revision number that contains the fix to follow the process you outline above, so I'm just mentioning it here on the issue to make sure it's not missed... Paul On 16 February 2014 23:25, Larry Hastings la...@hastings.org wrote: Right now we're in the release candidate phase of 3.4. 3.4.0 rc1 has been released, and the next release will be rc2. You might think that anything you check in to the default branch in Python trunk will go into 3.4.0 rc2, and after that ships, checkins would go into 3.4.0 final. Ho ho ho! That's not true! Instead, anything checked in to default between my last revision for rc1 (e64ae8b82672) and 3.4.0 final will by default go into 3.4.1. Only fixes that I cherry-pick into my local branch will go into 3.4.0 rc2 and final. And my local branch will remain private until 3.4.0 final ships! If you have a Terribly Important Fix That Must Go Into 3.4.0 rc2 or final, please go to the issue tracker and create a new issue with the following attributes: The title should start with 3.4 cherry-pick: followed by the revision id and a short summary example: 3.4 cherry-pick: b328f8ccbccf __getnewargs__ fix The version should be Python 3.4 The assignee should be larry The priority should be release blocker The comment should *also* contain the revision id (the tracker will turn it into a link) I'm also working on automatically publishing the merged/unmerged revision status to a web page. You can see a mock-up here: http://www.midwinter.com/~larry/3.4.merge.status.html The page is marked beta because it doesn't have real data yet--I'm still experimenting with my automation, so I haven't created the real 3.4 local branch yet. Again, just to be crystal-clear: the revisions marked merged on that page are just experiments, they aren't actually merged for 3.4. Once I'm ready for real merging, I'll remove the beta warning. (By the way: on that page, clicking on a revision takes you to the revision web page. Clicking on the first line of the comment expands it to show the complete comment.) Please use your best judgment before asking that a revision be cherry-picked into 3.4.0. Our goal in the release candidate phase is to stabilize Python, and to do that we must stop changing it. Only important interface changes, new features, or bugfixes should be checked in now, and preferably they should be low-risk. Cheers, /arry ___ 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/p.f.moore%40gmail.com ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
For 3.4.0rc2 the commit to merge from issue20621 is 52ab9e1ff46a. On Sun, Feb 16, 2014 at 3:45 PM, Paul Moore p.f.mo...@gmail.com wrote: http://bugs.python.org/issue20621 is significant enough to be resulting in a 3.3.5 release - can you make sure the 3.4 fix goes in? I'm not sure how to find the revision number that contains the fix to follow the process you outline above, so I'm just mentioning it here on the issue to make sure it's not missed... Paul On 16 February 2014 23:25, Larry Hastings la...@hastings.org wrote: Right now we're in the release candidate phase of 3.4. 3.4.0 rc1 has been released, and the next release will be rc2. You might think that anything you check in to the default branch in Python trunk will go into 3.4.0 rc2, and after that ships, checkins would go into 3.4.0 final. Ho ho ho! That's not true! Instead, anything checked in to default between my last revision for rc1 (e64ae8b82672) and 3.4.0 final will by default go into 3.4.1. Only fixes that I cherry-pick into my local branch will go into 3.4.0 rc2 and final. And my local branch will remain private until 3.4.0 final ships! If you have a Terribly Important Fix That Must Go Into 3.4.0 rc2 or final, please go to the issue tracker and create a new issue with the following attributes: The title should start with 3.4 cherry-pick: followed by the revision id and a short summary example: 3.4 cherry-pick: b328f8ccbccf __getnewargs__ fix The version should be Python 3.4 The assignee should be larry The priority should be release blocker The comment should *also* contain the revision id (the tracker will turn it into a link) I'm also working on automatically publishing the merged/unmerged revision status to a web page. You can see a mock-up here: http://www.midwinter.com/~larry/3.4.merge.status.html The page is marked beta because it doesn't have real data yet--I'm still experimenting with my automation, so I haven't created the real 3.4 local branch yet. Again, just to be crystal-clear: the revisions marked merged on that page are just experiments, they aren't actually merged for 3.4. Once I'm ready for real merging, I'll remove the beta warning. (By the way: on that page, clicking on a revision takes you to the revision web page. Clicking on the first line of the comment expands it to show the complete comment.) Please use your best judgment before asking that a revision be cherry-picked into 3.4.0. Our goal in the release candidate phase is to stabilize Python, and to do that we must stop changing it. Only important interface changes, new features, or bugfixes should be checked in now, and preferably they should be low-risk. Cheers, /arry ___ 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/p.f.moore%40gmail.com ___ 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/greg%40krypto.org ___ 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
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
http://bugs.python.org/issue20651 filed to track this as larry requested. On Sun, Feb 16, 2014 at 7:09 PM, Gregory P. Smith g...@krypto.org wrote: For 3.4.0rc2 the commit to merge from issue20621 is 52ab9e1ff46a. On Sun, Feb 16, 2014 at 3:45 PM, Paul Moore p.f.mo...@gmail.com wrote: http://bugs.python.org/issue20621 is significant enough to be resulting in a 3.3.5 release - can you make sure the 3.4 fix goes in? I'm not sure how to find the revision number that contains the fix to follow the process you outline above, so I'm just mentioning it here on the issue to make sure it's not missed... Paul On 16 February 2014 23:25, Larry Hastings la...@hastings.org wrote: Right now we're in the release candidate phase of 3.4. 3.4.0 rc1 has been released, and the next release will be rc2. You might think that anything you check in to the default branch in Python trunk will go into 3.4.0 rc2, and after that ships, checkins would go into 3.4.0 final. Ho ho ho! That's not true! Instead, anything checked in to default between my last revision for rc1 (e64ae8b82672) and 3.4.0 final will by default go into 3.4.1. Only fixes that I cherry-pick into my local branch will go into 3.4.0 rc2 and final. And my local branch will remain private until 3.4.0 final ships! If you have a Terribly Important Fix That Must Go Into 3.4.0 rc2 or final, please go to the issue tracker and create a new issue with the following attributes: The title should start with 3.4 cherry-pick: followed by the revision id and a short summary example: 3.4 cherry-pick: b328f8ccbccf __getnewargs__ fix The version should be Python 3.4 The assignee should be larry The priority should be release blocker The comment should *also* contain the revision id (the tracker will turn it into a link) I'm also working on automatically publishing the merged/unmerged revision status to a web page. You can see a mock-up here: http://www.midwinter.com/~larry/3.4.merge.status.html The page is marked beta because it doesn't have real data yet--I'm still experimenting with my automation, so I haven't created the real 3.4 local branch yet. Again, just to be crystal-clear: the revisions marked merged on that page are just experiments, they aren't actually merged for 3.4. Once I'm ready for real merging, I'll remove the beta warning. (By the way: on that page, clicking on a revision takes you to the revision web page. Clicking on the first line of the comment expands it to show the complete comment.) Please use your best judgment before asking that a revision be cherry-picked into 3.4.0. Our goal in the release candidate phase is to stabilize Python, and to do that we must stop changing it. Only important interface changes, new features, or bugfixes should be checked in now, and preferably they should be low-risk. Cheers, /arry ___ 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/p.f.moore%40gmail.com ___ 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/greg%40krypto.org ___ 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
